컴알못에서 컴잘알까지

Reversing.kr의 문제 WindowsKernel입니다. 커널 디버깅을 요구하는 문제지만 저는 정적 분석으로 해결했습니다. 커널 분석으로도 풀어봐야겠습니다. WindowKernel.exe 파일과 WinKer.sys 파일이 있습니다. WindowKernel.exe 파일을 실행시켜보면, 원래는 입력하는 칸이 뜨는데 윈도우 10과 제 vmware 윈도우 7에서는 에러가 뜨네요. IDA로 분석하겠습니다. Check 버튼을 누르면 입력받은 값을 기준으로 WinKer.sys가 로드되며 통신을 합니다. 결과값이 1일 경우에 "Correct!"를 반환합니다. 이제 WinKer.sys 파일을 분석해보겠습니다. READ_PORT_UCHAR이라는 함수를 통해서 키보드 스캔 코드를 읽어옵니다. 호출 순서는 DriverE..

Hackerschool FTZ의 Level 20 풀이입니다. 배열의 길이는 80인데 fgets 함수로 입력받는 길이는 79네요. 그렇다면 버퍼 오버플로우 공격을 할 수 없습니다. 그런데 printf 함수에서 %s 를 사용하지 않고 문자열을 출력했습니다. 그래서 FSB, 즉 포맷 스트링 버그를 이용해서 풀 수 있을 것 같습니다. 포맷 스트링 중에 %n이 있는데 %n은 쓰인 총 바이트 수를 지정할 정수형 포인터를 출력할 때 쓰는 것입니다. 그리고 이번에는 버퍼 주소 대신 함수가 끝나고 실행하는 소멸자 .dtors를 이용할 것입니다. 먼저 .dtors의 주소를 알아보겠습니다. .dtros가 끝날 때 호출하는 명령을 저장한 주소는 0x0849598입니다. 이번에는 쉘코드를 환경변수에 등록하고 주소를 알아내겠습니..

Hackerschool FTZ의 Level 19 풀이입니다. 18번 코드와 비교하면 너무나도 짧네요.. ㅋㅋ 하지만 자세히 보면 setreuid 함수가 없습니다. level 20의 uid를 'cat /etc/passwd | grep level20' 명령어로 확인해보니 3100이 나왔습니다. 그러니 기존의 쉘코드 앞에 setreuid(3100,3100);를 추가하면 될 것 같습니다. buf부터 ret까지의 거리는 0x100000000+4-0xffffffd8=44이므로 44입니다. 그럼 이제 setreuid(3100,3100);를 추가한 쉘코드를 환경변수에 등록하고 주소를 알아내겠습니다. 이제 공격 코드를 만들어서 넣어주면.. Password : we are just regular guys

Hackerschool FTZ의 Level 18 풀이입니다. 이번에는 코드가 엄청나게 깁니다.. shellout 함수를 실행시키면 될 것 같습니다. 그러려면 check 값을 0xdeadbeef로 만들어야 하는데 check에 값을 입력하는 부분이 없습니다. 그러므로 char string[100]; 보다 더 작은 주소에 있는 check에 접근하기 위해서 case 0x08: count--; printf("\b \b"); break; default: string[count] = x; count++; break; 위 코드를 이용해서 0x08로 4byte 뒤로 이동해서 check에 값을 넣어주면 됩니다. Password : swimming in pink

Hackerschool FTZ의 Level 17 풀이입니다. 16번 문제와 유사하지만 이번에는 shell 함수가 보이지 않습니다. 직접 shell을 실행시켜주는 코드를 작성해야 할 것 같습니다. 16번 문제와 shell 함수가 없다는 것만 빼고는 똑같기에 이번에도 40개의 문자를 앞에 넣어주면 됩니다. 이제 직접 쉘코드를 환경변수로 등록하고 shell 코드의 주소를 알아보겠습니다. 이제 공격 코드를 작성해서 넣어주면.. Password : why did you do it

Hackerschool FTZ의 Level 16 풀이입니다. void 형 call 변수에 들어가 있는 printit 함수를 shell 함수로 바꿔주면 될듯합니다. 0xfffffff0 - 0xfffffc8 = 40이므로 40개의 문자 뒤에 shell 함수의 시작 주소를 넣어주면 될 것 같습니다. shell 함수의 시작주소는 0x080484d0 이제 공격 코드를 만들어서 넣어주면.. Password : king poetic

Hackerschool FTZ의 Level 15 풀이입니다. 14번 문제와 거의 같지만 check 변수가 포인트 변수라서 check 포인트 변수에 있는 값이 가르키는 메모리 주소에 0xdeadbeef를 넣어줘야 합니다. gdb로 디버깅 해보니 14번 문제와 같게 buf와 check 사이의 거리가 40으로 같습니다. 0xdeadbeef 값이 존재하는 주소를 찾기 위해서 0x080484b0 주소부터 메모리들을 출력해보았더니, 0x08048b2 주소에 저장되어있는 것을 확인했습니다. 이제 공격 코드를 만들어서 넣어주면... Password : about to cause mass

Hackerschool FTZ의 Level 14 풀이입니다. if 문의 조건만 충족시켜주면 친절하게도 쉘까지 실행시켜주네요. buf와 check 사이의 거리를 알면 될 것 같습니다. 0xfffffff0 - 0xffffffc8 = 40 40개의 값과 0xdeadbeef를 리틀엔디안 방식으로 넣어주면 될 겁니다. Password : guess what

Hackerschool FTZ의 Level 13 풀이입니다. 버퍼 오버플로우를 일으켜야 하는데 i 값을 보존시키면서 쉘코드를 삽입해야 할 것 같습니다, main 함수를 분석해보니 변수 i의 값을 보존시켜야만 한다는 것만 제외하면, 기존의 문제와 같게 strcpy 함수를 이용해서 버퍼 오버플로우 공격을 해야 하네요. 입력받은 값을 0xfffffbe8부터 붙였는데 0xfffffff4가 변수 i 값입니다. 0xfffffff4 - 0xfffffbe8 = 1036 그러므로 1036개의 값 뒤에 변수 i의 값을 넣고 ebp-4 까지 덮어 씌어주기 위해 12byte를 더 쓰고 RET과 더미 크기만큼인 4byte, 그리고 공격 코드를 넣어주는 방식으로 쉘코드를 작성하면 될 것 같습니다. 변수 i 값과 버퍼값을 비교하는..

Hackerschool FTZ의 Level 12 풀이입니다. level 11과 굉장이 비슷하지만 입력받는 함수가 다르네요. 입력을 strcpy가 아닌 gets로 받아서 main 함수의 인자로 넘겨 줄 수 없어서 입력 대기 상태에서 입력해주어야 합니다. 먼저 버퍼의 크기를 알아내 보겠습니다. 0x08048473과 0x08048479에서 264와 8, 총 272를 빼주고 있습니다. 메모리 구조는 다음과 같습니다. [Buffer(256)][dummy(8)][SFP(4)][RET(4)] level 11과 같은 메모리 구조로 되어 있네요. 이제 버퍼를 저장하는 주소를 찾아보겠습니다. 버퍼가 저장되는 주소는 0xbfffdfc0이네요. gets는 입력 대기 상태에서 값을 입력받으므로 위처럼 공격 코드를 괄호로 묶어주..

Hackerschool FTZ의 Level 11 풀이입니다. 버퍼 오버플로우 기법에 대해서 공부를 한 뒤 풀었습니다. attackme 파일의 소스코드로 보입니다. strcpy 함수에서 문자열 길이 검사를 하지 않아서 오버플로우 취약점이 발생합니다. printf 함수에서 포맷 스트링 버그 취약점도 있네요. 이번에는 버퍼 오버플로우 취약점을 이용해서 풀어보겠습니다. attackme를 실행시키니 입력한 숫자를 다시 똑같이 출력해줍니다. gdb를 사용해서 분석해보겠습니다. 0x08048473과 0x08048479에서 264와 8, 총 272를 빼주고 있습니다. 메모리 구조는 다음과 같을 것입니다. [Buffer(256)][dummy(8)][SFP(4)][RET(4)] 그렇다면 공겨코드는 25바이트 쉘코드를 사용..

CodeEngn Advance RCE의 06번 문제입니다. 남은 군 생활이 며칠인지 구하는 문제네요.. 프로그램을 실행시키고 확인 버튼이나 닫기 버튼을 누르면 숫자가 1씩 계속 올라갑니다. 닫기 버튼을 눌러도 종료되지 않아서 작업 관리자에서 강제로 종료시켜야 했습니다. PEID로 확인해보니 UPX 패킹이 되어 있네요. 언패킹을 해준 뒤 올리디버거로 분석하겠습니다. 안티 디버깅 함수인 IsDebuggerPresent를 만나서 간단하게 우회해주었습니다. IsDebuggerPresent 함수를 우회한 뒤 함수 목록을 보니 아까 안 보였던 MessageBoxW 함수를 찾을 수 있었습니다. 모든 MessageBoxW 함수에 BP를 걸고 실행시켜보겠습니다. 실행시켜보니 45E071에서 브레이크가 걸렸습니다. 스택 ..

CodeEngn Advance RCE의 05번 문제입니다. Serial을 구하는 문제입니다. 프로그램을 실행시키고 아무 값이나 친 뒤 오케이를 누르면 이런 화면이 나타납니다. Visual Basic으로 만들어진 프로그램이네요. 올리디버거로 직접 분석하겠습니다. Visual Basic에서 문자열을 비교해주는 함수인 vbaStrCmp를 찾았습니다. 이곳에 BP를 걸고 실행시켜보겠습니다. EAX에 있는 제가 입력한 값 1234와 ECX에 있는 값인 677345를 비교하고 있습니다. 677345를 프로그램에 인증해보겠습니다. 정답이네요. 코드엔진 사이트에도 인증해보겠습니다. ~

CodeEngn Advance RCE의 04번 문제입니다. 3번 문제와 똑같이 Name이 CodeEngn 일 때의 Serial을 구하라고 하네요. 프로그램을 실행시켜서 시리얼 칸에 아무 값이나 넣어보았더니 실패 문자열이 출력됩니다. 올리디버거로 열어서 분석하겠습니다. 올리디버거 내에서 문자열과 함수 목록이 제대로 보이지 않는 것을 보니 패킹이 되어있는 것으로 보입니다. 한 줄씩 실행시키다 보니 401006이 OEP라는것을 알 수 있었습니다. OEP를 제대로 맞춰주고 덤프를 해주었습니다. strcmp 함수를 이용해서 사용자가 입력한 시리얼값과 어떤 ㅁ값을 비교하고 있습니다. 저 값을 프로그램에 인증해보면.. 정답입니다! 코드엔진 사이트에도 인증해보면.. !!

CodeEngn Advance RCE의 03번 문제입니다. Name이 CodeEngn 일 때의 Serial을 구하라고 하네요. 시리얼 칸에 아무 문자열이나 넣어보니 역시 실패 문자열이 출력됩니다. 올리디버거로 열어서 분석해보겠습니다. 성공 문자열로 보이는 곳으로 가보겠습니다. SEH (Structured Exception Handling)란 Windows OS에서 제공하는 예외처리 방식입니다. 언어 중립적이어서 범용적인 사용이 가능하며, 0으로 나누기나 유효하지 않은 메모리 주소 접근 같은 하드웨어 예외를 알아서 감지하고 처리하도록 도와줍니다. SEH가 있는 것으로 봐서 어떤 예외가 발생하면 이곳으로 분기해서 성공 문자열을 출력해주는 것으로 보이네요. 그럼 이제 실패 문자열이 출력되는 곳으로 가보겠습니다..