반응형

ollydbg plugin dlls.zip
0.06MB

 

lordpe.zip
0.43MB
PE.Tools.v1.9.762.2018.7z
0.48MB

 

주제

- Packers and protectors : an introduction

- 패커와 프로텍터 - 입문

 

순서는 아래와 같이 진행한다.

- UnPackMe_CrypKeySDK5.7
- UnPackMe_EZIP1.0
- UnPackMe_eXPressor1.3.0.1Pk
- UnPackMe_MEW1.1
- UnPackMe_NsPack3.5
- UnPackMe_NoNamePacker.d.out
- UnPackMe_Exe32Pack1.42
- UnPackMe_Fusion4.0.00.c

 

 

패킹은 실행 파일을 압축하는  행위로써 "압축 해제 코드"(압축된 코드를 해제하고, 해제된 코드를 실행하는 코드)를 원래 코드 앞에 붙이게 된다.

 

압축 해제 코드는 독립적으로 실행되는 파일인데, 일반 사용자는 패킹되거나 언패킹 된 코드를 실행하기 위해 추가적인 행동은 하지 않아도 된다.

 

실행 압축은 실행 파일을 압축하고, 압축된 코드를 압축 해제 코드와 함께 한 개의 실행 파일에 넣는 것이다.

 

실행 압축된 파일을 실행하면 원본 코드에 대한 압축 해제를 진행한 뒤, 해제된 코드를 실행하게 된다.

 

실행된 결과는 압축이 된 파일과 안된 파일이 동일해야만 한다.

 

실행 압축을 했을 때 아래와 같은 현상이 발생한다.

- 파일 시스템에서 좀 더 작은 공간을 차지한다.(코드의 사이즈가 작아진다.)

- 파일 시스템에서 메모리에 실행 파일을 전송하기까지 시간이 적어진다.(코드의 사이즈가 작기 때문에)

- 메모리에서 파일을 실행하기 위해 시간이 좀 더 필요해진다.(압축 해제할 시간이 필요하다.)

 

실행 압축은 일종의 실행 파일 속성이 변화된 것으로써 압축된 코드가 실행 파일 자체를 의미하게 된다.

 

즉, 패커/실행 압축은 프로그램을 팩(포장)하거나 압축을 한 뒤 압축 해제 코드와 대상 프로그램이 원래 상태처럼 실행되기 위해 언패킹 하는 명령어와 언 패킹된 코드를 로딩하는 명령어를 추가 작성하므로 언패킹 명령어의 제일 끝 부분은 원래 코드를 불러오게 하는 명령어가 존재할 것이다.

 

패킹된 파일(프로그램)은 아래와 같은 장점이 존재한다.

- 물리적인 파일 사이즈가 일반적으로 더 작아진다.

- 패킹된 파일은 초보 리버서를 힘들게 한다(패치를 위해 언패킹을 해야 하기 때문이다.)

 

패킹된 파일(프로그램)은 아래와 같은 단점이 존재한다.

- 원본 코드가 실행되기 전에 언패킹 코드가 먼저 실행되어야 하므로 실행 시간이 조금 더 길어진다.

- 안티 바이러스 쪽 분야와 관련해서 문제가 발생한다.

 

대부분 패커의 주 단점이 바로 안티 바이러스 쪽인데, 패킹 된 파일은 안티 바이러스에서 탐지하기가 힘들어진다.

- 일반적인 패턴 매칭 탐지 불가(원본 코드가 난독화 된다.)

- 검사 시간 느려짐(언패킹 코드 실행)

- 악성 코드가 자주 사용한다.

 

대부분 패커들의 가장 큰 약점은, 원래 코드를 실행하기 위해 특정 루틴에서 언패킹이 진행되고, 언패킹이 되면 디스크에 덤프가 가능한데, 덤프된 파일(프로그램)은 언패킹된 상태이기 때문에 분석하기가 편해진다.

 

프로텍터란 패커에서 파생된 개념으로써, 리버싱에 대해 조금 더 많은 방어적 기법을 포함하고 있는 것이다.

 

당연히 리버싱을 할 때는 더 어려워지지만 몇 가지 문제가 발생한다.

- 패커는 코드 사이즈를 줄이지만, 프로텍터는 코드 사이즈를 증가시킨다.(안티 리버싱 기법 포함)

- 패커에 비해 실행 속도가 더 느려진다.

- 안티 바이러스에서 탐지하기 더 어려워진다.(원본 코드를 보기 위해 언패킹 작업 필요, 커스텀 패커 탐지 불가, 미탐 및 오탐 발생)

 

위의 이론들을 안 뒤 패킹된 파일을 디버거에 올리면 EP는 실제 EP가 아닐 것이다.

 

실제 EP는 패커/프로텍터의 EP로 변경되기 때문에 이러한 파일에 대해서는 실제 EP를 OEP(Original Entry Point) 라고 한다.

 

패커/프로텍터가 적용된 파일은 언패킹 루틴을 포함하고 있는데, 언패킹이 되고 나면 OEP로 흐름이 분기 될 것이다.

분기가 된 상태에서 덤프를 시키면 패킹 되기 전의 파일을 얻을 수 있지만, 문제는 언패킹이다.

언패킹을 해주는 언패커가 존재하긴 하지만 보통은 구하기가 힘들기 때문에 매뉴얼 언패킹을 진행해야 하는데, 매뉴얼 언패킹에는 아래와 같은 방법들이 있다.

- Trace Code(그냥 하나하나 코드를 분석한다.)

- ESP 레지스터 사용

- 실행 압축 루틴에서 생성된 예외 처리(Exception) 사용

 


UnPackMe_CrypKeySDK5.7 분석 및 언패킹

 

 

x32dbg에서 UnPackMe_CrypKeySDK5.7 파일을 열면 위와 같이 EP 코드가 나오는데

 

일반적인 바이너리 파일들처럼 함수 프롤로그가 있지 않고 함수를 호출한다.

 

46B6F9 주소에 ret 명령이 있는데

이 명령어 바로 직전에 46B014 주소에 있는 데이터에 해당하는 주소 4271B0(BaseAddress + 271B0)으로 점프한다.

 

언패킹 전
언패킹 후

 

4271B0 주소로 이동하면 위와 같이 나오는데 OEP로 추정된다.

 

이유는 F8 키와 F9 키를 이용해 4271B0 주소로 가면 위와 같이 언패킹되어 원래의 코드가 보이기 때문이고

 

 

보통 OEP 주소는 .text(code) 섹션에 위치하게 되는데, 4271B0 주소는 코드 섹션에 위치하기 때문이다.

 

 

dump 기능을 사용하기 위해 ollydbg에서 열어준다.

 

그러면 위의 Entry Point Alert 메세지 창이 뜨는데 무시해주면 된다.

 

46B6F9 주소에 BP를 걸고 F9 키를 누른 뒤 F8 키를 눌러 46B014 주소에 있는 데이터에 해당하는 주소로 점프하여 OEP 부분으로 간다.

 

 

그러면 위와 같이 뜨는데 Ctrl + A 키를 눌러주면

 

 

위와 같이 코드가 제대로 보일 것이다.

 

 

디스어셈블리 창에서 오른쪽 마우스 -> Dump debugged process를 클릭한다.

 

 

그럼 위와 같이 dump 창이 뜬다.

 

이 dump 창을 이용하면 현재 디버거에 로딩된 바이너리 상태를 새로운 파일로 저장할 수 있게 해준다.

 

dump 창을 띄우면 위와 같이 뜨는데 대부분 자동으로 세팅되어 있지만, 가끔 modify: EP 부분이 다를 수 있어서 직접 수정해야 할 때도 있다.

 

그리고 제일 하단에 Rebuild Import 체크 박스가 기본적으로는 체크되어 있을텐데 지금은 체크를 해제한다.

 

그 후 오른쪽에 있는 dump 버튼을 누르면

 

 

위와 같이 저장할 수 있게 창이 뜬다.

 

파일 이름을 작성하고 저장하면 언패킹 된 파일이 생성될 것이다.

 

 

덤프한 뒤 저장한 파일을 ollydbg에 올리면 위와 같이 바로 OEP 부분으로 로드된다.

 

 

바이너리를 덤프하고 Ollydbg에 올렸을 때 OEP로 바로 이동되지만

 

필수적이진 않지만 사이즈를 줄이기 위해 몇 가지 추가적인 작업이 필요하다.

 

LordPE 프로그램을 켜면 위와 같은데, 덤프 후 IAT 손상과 관련하여 복구해주는 툴이다.

 

오른쪽 버튼들 중 PE Editor 버튼을 눌러준다.

 

 

그리고 dump 뜬 파일을 선택해준다.

 

 

그러면 위와 같이 창이 뜬다.

 

오른쪽에 있는 버튼들 중에서 Sections 버튼을 누른다.

 

 

그러면 위와 같이 섹션 정보들이 적힌 창이 뜨게 된다.

 

그런데 위의 사진을 참고하면 "Have", "a nice", "day!" 섹션이 존재한다.

 

해당 섹션은 언패킹 되면서 포함된 섹션이라 딱히 필요 없는 섹션으로 실제 바이너리에는 필요가 없다.

 

위와 같이 실제로는 필요없는 섹션이 존재하면 파일의 사이즈만 커지기 때문에 용량을 줄이기 위해 섹션 하나 하나 지워준다.

 

 

제거하고자 하는 섹션을 선택 후 오른쪽 마우스를 누르면 메뉴들이 뜨는데, wipe section header 메뉴를 선택해주면 섹션이 제거된다.

 

"Have", "a nice", "day!" 섹션 총 3개를 지워준 후 창을 닫아준다.

 

 

그럼 위의 창으로 돌아가고 OK 버튼을 누른다.

 

 

그러면 위의 창으로 돌아가고 Rebuild PE 버튼을 눌러준다.

 

저장할 파일 이름을 정해주면

 

 

위와 같이 창이 뜨는데 위의 사진에 있는 문구를 참고하면 파일의 사이즈가 91%나 줄여졌다고 한다.

 


UnPackMe_EZIP1.0 분석 및 언패킹

(Scylla 플러그인을 사용하여 덤프, Ollydump로 덤프 후 PE Tools 사용하여 IAT 복구)

 

일반적으로 언패킹 할 때 여러 방법 중 하나는 패커는 언젠가 OEP로 분기되어야 하는 것을 이용하는 것이다.

 

OEP로 분기된다는 것은 ESP 레지스터와 관계가 있는데, 이 ESP 레지스터를 이용해서 언패킹 하는 것을 ESP Trick이라고 한다.

 

 

파일을 x32dbg에 올리면 위와 같이 11개의 jmp 문이 EP 코드에 있다.

 

F8 키를 눌러 4682DC 주소로 점프한다.

 

 

4682DC 주소로 점프하면 위와 같은데 F8 키를 한 번 더 눌러 4692DC 주소의 push ebp 명령을 실행하면 위에서와 같이

EBP 레지스터의 값은 19FF84이고, ESP 레지스터의 값은 19FF74이다.

 

 

 

ESP 레지스터를 선택 후 오른쪽 마우스를 누른 후 "덤프에서 따라가기"를 눌러 덤프에서 19FF74 주소로 이동한다.

 

 

위와 같이 19FF74 주소에 있는 "0019FF84" 4byte 데이터를 드래그 한 후 오른쪽 마우스를 눌러 하드웨어 BP를 건다.

 

중단점 -> 하드웨어, 엑세스 -> Word 

 

 

F9 키를 누르면 위와 같이 468688 주소에서 멈추고, 디버거 맨 아래에 메세지를 보면 하드웨어 브레이크 포인트가 결렸다고 한다.

 

468688 주소에서의 명령어는 jmp eax인데, eax에는 4271B0 주소가 담겨있다.

 

4271B0 주소가 OEP 주소인 것 같다.

 

 

F8 키를 눌러 eax에 담긴 주소로 점프하면 위와 같이 4271B0 주소로 점프한다.

 

이 상태에서 dump를 뜨는데 이번에는 ollydbg에서 진행한 것이 아니므로 x32dbg의 덤프 플러그인을 이용한다.

 

 

이 상태에서 Ctrl + i 키를 누르면 위와 같이 Scylla 창이 뜬다.

 

따로 OEP 값을 설정하지 않아도 현재 EIP가 가리키는 값으로 자동 설정되어 있다.

 

그리고 IAT Autosearch 버튼을 누른다.

 

 

그러면 위와 같이 뜬다.

 

확인 버튼을 누른 후

 

 

Get Imports 버튼을 누르면 위와 같이 Imports 정보들이 창에 뜨게 된다.

 

그리고 나서 Dump 버튼을 눌러 덤프한 파일을 저장한다.

 

 

그러면 위와 같이 UnPackMe_EZIP1.0_dump 파일이 생성된다.

 

 

Scylla에서 Fix Dump 버튼을 눌러 덤프한 파일인 UnPackMe_EZIP1.0_dump 파일을 불러온다.

 

그러면 위와 같이 UnPackMe_EZIP1.0_dump_SCY.exe 파일이 생성되는데 이 파일이 최종적인 실행파일이다.

 

이 프로그램의 경우 IAT 복구 없이 프로그램을 실행할 수 있다.

 

 

UnPackMe_EZIP1.0_dump_SCY.exe 파일을 x32dbg에 올리면 위와 같이 4271B0 주소로 바로 이동한다.

 

 

PE tools를 이용한 덤프 후 IAT 복구하여 파일 사이즈 줄이기

- 덤프 플러그인이나 프로그램이 덤프에 실패하더라도 PE Tools 프로그램에서는 덤프가 되는 경우가 있다.

 

 

먼저 ollydbg에서 UnPackMe_EZIP1.0.exe 파일을 열어 위에서 x32dbg에서 진행했던 방법으로 진행한 뒤 Ollydump로 덤프를 떠서 dump_UnPackMe_EZIP1.0.exe 파일로 저장한다.

(Ollydump로 덤프를 뜰 때 Rebuild Imports 옵션은 선택 해제 해줘야 한다.)

 

그리고 위와 같이 PE Tools를 실행한 후 위와 같이 Tools -> PE Editor를 선택하거나 Alt + 1 키를 누른다.

 

그리고 dump_UnPackMe_EZIP1.0.exe 파일을 선택한다.

 

 

위와 같이 창이 뜨면 오른쪽에 있는 Sections 버튼을 누른다.

 

 

그러면 위와 같이 섹션 정보창이 띄워진다.

 

위의 섹션들 중 .rdata 섹션이 두 번 포함되어 있다.

 

 

7번째에 있는 .rdata 섹션은 필요없는 섹션이므로 7번을 선택 후 오른쪽 마우스 -> Kill section(from file)를 선택한다.

 

그리고 나서 창을 닫아준 뒤 Option Header 버튼을 클릭하여 헤더 정보 창을 띄운다.

 

 

그러면 위와 같이 창이 뜬다.

 

이대로 OK 버튼을 눌러 꺼도 되지만

 

Base Of Code와 Base Of Data의 값이 잘못 설정되어 있으니 x32dbg에서 참고하여 값을 수정한다.

 

 

code 영역은 401000이고, data 영역은 44B000이다.

 

UnPackMe_EZIP1.0.exe 파일의 ImageBase는 400000이므로 위와 같이 Base Of Code와 Base Of Data의 값을 1000과 4B000으로 수정하고 OK 버튼을 눌러 창을 나간다.

 

 

그리고 위의 창에서 Rebuild PE 메뉴를 선택하여 재빌드한다.

 

 

리빌드가 완료가 된 PE 파일을 보면 이전 PE 파일과 비교해봤을 때 약 9% 정도의 사이즈가 줄어든 것을 확인할 수 있다. 

 


UnPackMe_eXPressor1.3.0.1Pk 분석 및 언패킹

- XP 환경에서 실습하기를 권장한다.

 

 

Ollydbg에 UnPackMe_eXPressor1.3.0.1Pk 파일을 올리면 위와 같이 함수 프롤로그가 보인다.

 

그렇기 때문에 패킹이 되어 있지 않다고 볼 수도 있지만, 실제로는 패킹이 되어 있는 바이너리이다.

 

이 파일도 ESP Trick으로 매뉴얼 언팩을 한다.

 

 

46B72A 주소의 push ebp 명령어가 실행되면 ESP의 값이 처음으로 변경된다.

 

이 상태에서 ESP 레지스터를 선택 후 Follow in Dump을 눌러 덤프창에서 19FF74 주소로 이동한다.

 

19FF74 주소에 있는 데이터 0019FF84를 드래그한 뒤 우클릭 후 Breakpoint -> Hardware, on access -> Dword를 선택하여 하드웨어 BP를 건다.

 

 

그리고 F9 키를 눌러 프로그램을 실행하면 위와 같이 메세지 차이 뜨는데 확인 버튼을 눌러준다.

 

 

그러면 46BDE7 주소에서 멈추게 된다.

 

EAX 레지스터의 주소로 점프하는데 EAX 레지스터에는 4271B0 주소가 담겨있다.

 

 

위와 같이 4271B0 주소로 점프하면 OEP 부분이 나온다.

 

 

OEP로 이동한 상태에서 Ollydump를 이용해 덤프를 하는데 이번에는 Rebuild Import 항목을 체크한 채로 덤프를 뜬다.

 

 

덤프 뜬 파일을 저장하고 저장한 파일을 디버거에 열면 위와 같이 바로 OEP 부분이 나온다.

 


UnPackMe_MEW1.1 분석 및 언패킹

 

 

Ollydbg에 UnPackMe_MEW1.1 파일을 올리면 위와 같이 49B339 주소로 프로그램이 분기된다.

 

 

F8 키를 누르면 400154 주소로 점프하는데

 

40015D 주소에서 push eax 명령이 이루어지면서 ESP 값이 변경된다.

 

이를 이용해 ESP Trick으로 매뉴얼 언패킹을 한다.

 

 

40015D 주소의 push 명령을 수행하면 esp 레지스터가 19FF74 주소를 가리키는데 ESP 레지스터를 우클릭 후 Follow in dump 하여 덤프창에서 이동 후

 

004271B0 값 4byte를 드래그 한 뒤 우클릭 -> Breakpoint -> Hardware, on access -> Dword 선택하여 하드웨어 BP를 건다.

 

그리고 F9 키를 누른다.

 

 

그럼 위와 같이 4271B0 주소에서 멈추게 되는데 이 부분이 OEP 부분이다.

 

 

OEP에서 멈춘 상태에서 ollydump를 이용해 Rebuild Import 옵션을 선택한 채로 덤프를 뜬다.

 


UnPackMe_NsPack3.5 분석 및 언패킹

 

 

UnPackMe_NsPack3.5 파일을 ollydbg에 올리면 위와 같이 pushad 명령으로 레지스터 주소값들을 스택에 저장한다.

 

그리고 46D3A5 주소에서 46D3AA 주소의 함수를 호출한다.

 

ESP Trick을 이용해 매뉴얼 언패킹을 진행할 수 있지만, pushad 명령어가 사용되면 당연히 언패킹 루틴이 끝난 후 원래의 레지스터 값들을 스택에서 불러오기 위해 popad 명령어가 사용될 것이다.

 

그렇기 때문에 해당 명령어를 검색해서 언패킹을 진행할 수 있다.

 

 

위와 같이 디스어셈블리 창에서 우클릭 -> Search for -> All commands -> "popad" -> Find

 

 

그러면 위와 같은 창이 뜨는데 현재 EIP가 위치하고 있는 46D3A3 주소의 pushad 명령에 포커싱 되어 있다.

 

그 밑으로 popad 명령이 3개 있는데 이전에 puahad 명령이 총 2개 였기 때문에

 

popad도 수를 맞추어 2개가 수행될 것이다.

 

그러므로 46D615 주소의 popad 주소 부분으로 간다.

 

 

그러면 위와 같이 popad 명령이 총 2번 수행된 후 4271B0 주소로 점프한다.

 

언패킹이 끝난 후 4271B0 주소로 점프하기 전에 멈추도록 46D617 주소에 BP를 걸고 F9 키를 누른 뒤 F8 키를 누른다.

 

 

그러면 위와 같이 OEP 부분으로 오게 된다.

 

 

OEP로 온 상태에서  ollydump를 이용해 Rebuild Import 옵션을 체크한 채로 덤프를 뜬다.

 


UnPackMe_NoNamePacker.d.out 분석 및 언패킹

 

 

모든 레지스터의 값들을 스택에 저장하고 46B066 주소의 함수를 호출한다.

 

 

디버거에 올리지 않고 프로그램을 더블 클릭해 실행하면 위와 같이 메세지 창이 뜬다.

 

 

하지만 디버거에 올린 채 F9 키를 눌러 실행하면 위와 같이 메세지 창은 뜨는데 메세지는 보이지 않는다.

 

이는 디버거를 탐지하고 있어서 메세지가 출력되지 않는다고 추측이 된다.

 

 

다시 코드로 돌아가면 46B086 주소에서 46B35E 주소로 점프한다.

 

 

 

46B35E 주소로 점프 후 F8 키를 계속 눌러 진행하다 보면 46BAFC 주소에서 EDX에 있는 값을 EAX에 담는데 이때 EDX에 있는 값이 IsDebuggerPresent 이다.

 

그리고 46BB1B 주소에서 EAX에 담긴 IsDebuggerPresent() 함수를 호출한다.

 

46BB1B 주소에서 EAX에 담긴 IsDebuggerPresent() 함수를 호출하기 전에 46BB13 주소에서 EAX 레지스터를 or 연산한 뒤 결과값이 0이면 ZF 플래그가 1로 설정되어 JE 명령어를 수행되어 46C0CF 주소로 점프하게 되는데

 

현재는 디버깅 중이므로 or 연산 결과 1이 나오게 되고 ZF 플래그가 0으로 설정되어 JE 명령이 수행되지 않아 46C0CF 주소로 점프하지 않는것이다.

 

 

그렇다면 위와 같이 eax의 값을 xor 연산하여 0으로 만들어 조건 분기가 일어나도록 수정한다.

 

 

조건 분기 한 뒤 F8 키를 눌러 진행하다 보면 위와 같이 46C34C ~ 46C355 주소에서 루프를 돌게 된다.

 

그런데 지금은 언패킹 루틴이 모두 종료되었고, 코드 섹션이 정상적인 상태일 것이다.

 

그 이유는 IsDebuggerPresent() 함수가 나왔고, 이 함수가 나왔다는 것은 언패킹이 끝난 후 프로그램이 실행 중이라는 의미이기 때문이다.

 

OEP를 찾아가는 부분에서 계속 무한 로프가 실행되고 있는 것인데

 

그러면 결국 바이너리가 실행되기 위해서 언젠가 코드 섹션으로 접근할 것이므로 이를 이용해 OEP를 찾을 수 있다.

 

 

메모리에서 프로그램의 code 섹션에 F2 키를 눌러 위와 같이 BP를 걸어준다.

 

위와 같이 code 섹션에 BP를 걸면 코드 섹션 첫 번째 주소로 접근하는 순간 프로그램이 멈추게 되는데

 

코드 섹션에 접근한다는 것은 실제 OEP로 분기되었다고 추측할 수도 있다.

 

 

설치한 BP가 있다면 모든 BP를 비활성화 혹은 제거한 뒤 F9 키를 누르면 위와 같이 4271B0 주소에서 멈추게 된다.

 

 

4271B0 주소가 OEP 부분이므로 4271B0 주소로 온 상태에서 Ollydump를 이용해 Rebuild Import 옵션이 체크된 채로 덤프를 뜬다.

 


UnPackMe_Exe32Pack1.42 분석 및 언패킹

 

 

이번 파일의 EP는 뭔가 이상하지만 ESP Trick을 이용해 언패킹한다.

 

 

F8 키를 눌러 417012 주소의 push EBP 명령을 실행한 뒤 ESP에는 19FF74 값이 담기게 되는데

 

ESP 레지스터를 선택한 후 오른쪽 마우스 -> Follow in Dump를 눌러 dump 창에서 19FF74 주소로 이동한다.

 

 

위와 같이 0019FF84 값 4byte를 드래그 한 뒤 오른쪽 마우스 -> Breakpoint -> Hardware, on access -> Dword를 선택하여 하드웨어 BP를 건다.

 

그리고 F9 키를 눌러 실행하다 보면

 

 

위와 같이 40A000 주소로 오게 되는데 이 부분이 OEP라고 한다.

 

Ctrl  + A 키로 재해석 해도 바뀌지 않길래 그냥 이 상태로 덤프를 떠보기로 한다.

 

 

이번에는 ollydump 이용할 때 Rebuild Import 옵션을 해제하고 덤프를 뜬다.

 

 

덤프한 파일을 디버거에서 열면 위와 같이 뜨는데 음... 맞는지 모르겠지만 강좌에서는 여기가 맞다고 한다.

 


UnPackMe_Fusion4.0.00.c 분석 및 언패킹

 

 

46B017 주소로 분기를 한다.

 

이 파일도 ESP Trick을 이용해 언패킹 할 수 있으니 맨 처음으로 ESP 레지스터 값이 변경되는 시점에서 하드웨어 BP를 설치한다.

 

 

ESP 레지스터의 값에 해당하는 19FF74 주소를 dump에서 이동한 뒤 위와 같이 0019FF84 값 4byte를 드래그 한 후 마우스 오른쪽 -> Breakpoint -> Hardware, on access -> Dword 를 선택하여 하드웨어 BP를 건다.

 

 

F9 키를 눌러 실행하면 위와 같이 4271B0 주소에서 멈추는데 위와 같이 안 보이면 Ctrl + a 키를 눌러 재해석하면 된다.

 

이 주소가 OEP 부분이다.

 

 

OEP 부분으로 이동된 상태에서 ollydump를 이용해 Rebuild Import 옵션을 체크 해제해준 후 덤프를 뜬다.

 

 

반응형

+ Recent posts