Computer_Study

이 문제를 풀어보면서 디컴파일러를 왜 써야 하는지를 알게 되었다. 문제를 보면 다음과 같이 Name, Serial에 입력 됨에 따라 맞냐 틀리냐를 출력한다. 따라서 문제는 다음과 같은 SerialNumber를 줬을때 아이디는 무엇이 되야 하느냐에 해당한다. 비밀번호는 4글자로 p로 끝난다. string을 Correct Wrong을 기반으로 검색하면 위의 함수를 호출하면 position.5E1740에서 step in을 해보면 Name, Serial을 비교하는 값이 나올 것이다. 따라서 이를 분석해보려 했지만 이는 너무 복잡하고 어려워서 실패하였다. 다른 writeup을 보면 IDA를 이용하여 디컴파일해서 이를 분석하여 코드를 짰다. IDA PRO를 구매할 수는 없어서 기드라를 깔아서 진행하였다. 위와 같은..

신기하고 재미있었던 문제인것 같다. 문제는 다음과 같이 그림을 그릴 수 있는 공간을 준다. Check 을 눌러보니 특정 그림이 아니면 틀리는 것같다. 항상 처음 하던 일로 디버거로 열어 Wrong이 출력되는 부분을 확인해 보았다. 조금 위를 보면 FindResurceA function과 로딩 하는 function이 존재한다. 따라서 이를 기반으로 찾아보았다. 다음 과 같이 FindResource 함수는 hModule = 0 lpName = 65 lpType = 18 의 값을 가지고 입력한다. 여기서 막혀서 다른 블로그를 조금 참고 하게되었다. lpName이 65인 것을 가지고 비교할만한 다른 파일을 받지도 않음에도 어떻게 찾을지를 알 수가 없었기 때문이다. PEview를 통해서보면 rsrc부분에 뭔가가 ..

RTL(Return To Library) 실행파일에 링크된 libc의 함수를 PLT, GOT에서 가져와서 호출하여 사용하는 것 PLT와 GOT에서 함수들의 주소를 가져온다. RTL을 처음 접할 수 있는 것은 FTZ level19번 문제였다. https://b1ackhand.tistory.com/138 [FTZ]level19 코드가 매우 짧은걸 볼 수 있다. 너무 짧아서 무엇이 부족한지 몰랐다. 평소대로 환경변수를 이용하여 buffer overflow를 이용하여 풀렸지만 다른 사람들의 풀이를 읽어보고 무엇이 부족한지 알 수 b1ackhand.tistory.com 다음과 같이 system 이나 setreuid 함수가 프로그램 내에서 존재하는 주소를 알아낼 수 있다. 이를 사용하여 메모리를 다음과 같이 설정해..

RELRO RELocation ReadOnly로 메모리에 배치된 데이터의 어느 부분에 ReadOnly 속성을 부여할 지 이다. GOT Overwrite 공격 여부를 위해 확인한다. FullRELRO일 때 사용 불가능하다. SSP(Stack Smash Protection) 버퍼오버플로우를 막기위한장치로 Stack Canary가 있다. NX bit No eXcute bit로 윈도우에서는 DEP(Data Execution Prevention)로 불린다. 메모리상 데이터를 실행불가능하기 설정하여 셸코드를 사용하는것을 힘들게 만드는 것 이를 우회하기 위해서 실행가능 코드를 파편화하여 조합하여 공격한다. ASLR 메모리의 주소를 랜덤화 하는것 PIE Position Independent Executable은 주소 ..

프로그램을 실행하면 다음과 같다. 숫자를 입력하고 check 버튼을 눌렀을때 프로그램이 종료되어 디버거로 열어보았다. string중 check나 wrong을 출력하는 부분을 검색하여서 해당장소로 간 후 bp를 걸었다. 숫자를 입력하면서 프로그램 돌아가는것을 조사 해 보았다. 숫자 입력된 것을 검색해보니 따로 나오지 않는것으로 보아 입력받은 숫자에 처리를 하는것 같다. 프로그램이 실행되다보면 해당 부분에서 오류를 내뱉는 것을 볼 수 있다. 해당 부분은 eax에 해당하는 메모리에 접근하는데 이 eax 해당 메모리는 입력받은 값에 따라 값이 달라지는걸 유추해 낼 수 있다. 이 eax값은 입력값에서 1을 더하고 후에 뭔가 처리를 해주는데 이를 알아보기위해 FFFFFF를 넣고(1을 더하면 0) 진행해보니 다음과같..

코드가 매우 짧은걸 볼 수 있다. 너무 짧아서 무엇이 부족한지 몰랐다. 평소대로 환경변수를 이용하여 buffer overflow를 이용하여 풀렸지만 다른 사람들의 풀이를 읽어보고 무엇이 부족한지 알 수 있었다. 지금까지 사용해 왔던 shellcode에는 setuid가 포함되어 있었기 때문에 생각하지 못했던 것이다. 문제를 다시보면 setuid가 존재하지않고 system역시 존재하지 않는다. 따라서 이러할때 사용할 수 있는 공격방식으로 RTL(Return to Library)가 존재한다. 자세한 내용은 나중에 따로 다시 정리해 보고자 하지만 간단히 내용을 살펴 보자면 위의 분석한 내용과 같이 setreuid, system 함수는 프로그램이 실행 될때 어딘가의 library에 존재하기 때문에 이를 ret a..

문제 힌트를 보면 다음과 같이 긴 코드가 보인다. 조건을 보면 check 안에 0xdeadbeaf가 있을때 shellcode를 실행해 준다. 그렇게 하기 위해서 입력받은 값에 따라 switch문이 동작하는 것을 볼 수 있다. 취약점은 string[count] = x 부분에서 생긴다 count가 만약 음수라면 자신보다 뒤에있는 변수에 접근 가능하기 때문이다. disas한 부분을 보면 deadbeef와 비교하는 부분은 ebp - 104 string 부분은 ebp - 100 이다. 만일 입력받은 명령어가 0x08 이라면 count-- 되는 점을 이용해서 string[-1], string[-2] 등에 접근할 수 있다. 그리고 이는 check 부분에 해당한다.

이전 문제와 다르게 shell()함수가 없다. 하나의 방법으로 이전에도 소개한 환경변수를 이용한 방법이 있고 실제로 내가 그렇게 해결했다. 다음 방법으로는 버퍼에 쉘코드를 입력하여 주소를 넣는 방식이 있을 것이다.

코드는 다음과 같다. 함수 포인터가 printit 함수를 호출하는데 이를 shell이 호출하게 하면 쉘을 얻을 수 있다. gdb로 분석을 해봤을때 printit의 주소가 80496e8인 것같다. 아마 shell()함수도 주변에 있을듯 하여 이를 찾아보았다. 다음과 같이 검색하여 shell의 위치도 찾을 수 있었다. (python -c 'print "\x90"*40+"\xd0\x84\x04\x08"'; cat) | ./attackme 이전과 같은 방식으로 shell()함수의 위치를 덮어 씌워줬다.

14단계 문제와 같아 보이지만 check이 포인터 변수인 것이 다르다. 포인터 변수로 되어있다는 것은 값이 deadbeef 여야 된다가 아니라 가르키는 주소의 값이 deadbeef 여야 된다는 것이다. gdb로 전과 같이 분석했을 때 deadbeef 를 하드 코딩하여 비교하고 있기 때문에 main 부분의 메모리를 살펴보면 다음과 같이 dead beef가 저장 되어있는 모습을 알 수 있다. (python -c 'print "\x90"*40+"\xb2\x84\x04\x08"';cat) | ./attackme 따라서 다음과 같이 코드를 입력하여 해결 할 수 있다. 이 외에 check 이 들어가는 부분을 환경변수를 이용하여 처리 할 수 도 있다.