Basic RCE L09

---

09.exe 파일이 주어진다.

일단 실행해보자.

확인을 누르면

파일을 찾을 수 없다는 메시지가 뜬다.

올리디버거로 열어봤다.

많이 봤던 00401000이 아니라 004071F0이 EP로 잡혔다.

그 곳에는 PUSHAD가 있다.

PUSHAD는 레지스터 백업용으로 쓰는 명령어로, 범용 레지스터 값들을 스택에 쌓는다는 의미이다.

왠지 패킹되어 있을 듯한 느낌이 드니 PEiD로 검증해보자.

UPX로 패킹되어 있다고 한다.

바로 UPX 언패킹을 진행하고 파일을 다시 실행시켜봤다.

오류가 뜬다..

문제에서 언급된 'stolenbyte' 때문일 것이다.

언패킹한 09.exe를 우선 올리 디버거로 열어보자.

'NOP NOP NOP ...' 이 부분이 아마 훔쳐진 바이트일 것 같다.

자세히보면 0040100E의 코멘트 부분에서 MessageBoxA 함수를 호출한다.

그런데 그 위 인자 부분이 조금 이상하다.

위 사진들은 같은 파일의 다른 MessageBoxA 함수들이다.

아래 msdn에서 자세히 볼 수 있겠지만 MessageBoxA()의 인자는

hWnd: 이 메시지 박스를 소유할 윈도우의 핸들 값

lpText: 메시지 창에 출력할 문장

lpCaption: 메시지 창 표시줄에 출력할 문자열

uType: 아이콘/버튼의 종류

이렇게 총 4개다.

MessageBoxA function (winuser.h) - Win32 apps

unpack_09

그런데 uType 인자 하나밖에 보이지 않는다. 

우린 이 위에 들어갈 인자 3개를 더 찾으면 된다.

 

다시 언패킹 되기 전의 09.exe 파일로 돌아가보자.

코드의 거의 끝부분, 00407387에서 'JMP 09.0040100C'를 찾을 수 있다.

09

이 부분은 아래 사진과 같이 우리가 언패킹한 파일의 EP와 같다. 

저 부분(00407387)에서 점프하여 넘어오는 듯 하다.

 

다시 언패킹되기 전 사진을 보면, 0040736E부터 00407375까지 3개의 PUSH 코드를 볼 수 있다.

JMP 전인 이 세개의 코드 위치 상, 저 부분이 훔쳐진 인자 3개일 가능성이 매우 크다.

그 이유는 'POPAD' 바로 밑에 있기 때문이다. 

가장 처음 파일을 올리디버거로 열었을 때 봤던 'PUSHAD'를 기억할 것이다.

POPAD는 PUSA로 스택에 넣은 값들을 다시 레지스터에 채우는 역할을 한다.

 

저 부분의 헥스 값을 찾으려면, 선택 후 Follow in Dump를 통해 볼 수 있다.

6A 00 68 00 20 40 00 68 12 20 40 00

언패킹된 파일에서 본 NOP의 개수와도 동일하다.

 

그럼, 00407387에 BP를 걸고 F9로 실행한뒤, BP에 오면 F8을 누르자.

예상대로 아까봤던 MessageBoxA의 마지막 인자 부분으로 이동했다.

스크롤을 위로 올려보면 NOP 부분이 있는데 우린 지금부터, 이 곳에 'stolenbyte'를 패치할 것이다.

같은 방법으로 Hex Dump 창에서의 위치를 찾아보면 '00401000' 딱 맞는 OEP를 찾을 수 있다.

 

그리고 이곳에 stolenbyte를 넣자.

수정된 상태다.

MessageBoxA 함수에 대한 인자가 정상적으로 들어있다.

 

답은 찾았지만 올리 덤프를 사용해 마무리하자.

중요한 점은 EP의 Modify값을 100C에서 1000으로 바꾸고 Dump 해주어야 한다.

 

플래그는 아까 찾은 stolenbyte!