리버스코어 ReverseCore

소프트웨어 리버스 엔지니어링이란 응용 프로그램의 내부 구조와 동작 원리를 탐구하는 기술입니다. 

신기한 모험과 흥미로운 도전 과제들로 가득한 리버스 엔지니어링의 길로 들어선 독자 여러분을 환영합니다.

리버싱을 잘 하면 프로그램의 속을 훤히 들여다 볼 수 있습니다. 자신이 만든 프로그램도 아니고 소스 코드조차 없는 상태에서 말이죠. 리버싱 기술을 잘 활용하면 개발/테스트 단계에서 미처 발견하지 못한 버그나 취약점을 파악할 수 있고, 파일이나 메모리를 직접 수정(패치)하여 문제를 해결할 수 있습니다. 그리고 더 나아가서 전혀 새로운 기능을 추가시켜 프로그램의 기능을 향상 시킬 수 도 있습니다. 마치 마법과도 같은 멋진 일을 할 수 있는 것입니다.

리버싱 공부를 시작할 때 거창한 사전 준비 같은 건 필요 없습니다. 

이야기를 하나 들려 드리겠습니다. 제가 수 년간 리버싱 블로그를 운영해 오면서 가장 많이 받은 질문은 “도대체 리버싱을 어떻게 공부해야 하나요?” 였습니다. 여러 가지 경험담과 실패 사례를 분석해본 결과 리버싱 공부를 실패하는 가장 큰 원인은 공부 자체의 분량이나 어려움이 아니었습니다. 오히려 “전 C언어도 모르는데요?”, “어셈블리를 마스터 해야 하나요?”, “저는 OS 구조를 잘 모릅니다”, “디버거를 사용할 줄 몰라요”, “이 많은 것들을 언제 다 공부하고 본격적인 리버싱 공부를 시작하죠?” 와 같은 막연한 두려움과 걱정 때문에 중도에 포기하는 것이 주요한 실패 원인이었습니다.

본격적인 리버싱 공부는 C언어, 어셈블리, OS구조, 디버거 사용법등을 공부한다는 것과 같습니다. 이런 것들을 이미 알고 있는 사람은 리버싱 입문 과정이 필요 없습니다. 이미 리버싱 전문가라는 뜻이니까요. 아직 리버싱에 대해 알고 있는 게 하나도 없다구요? 실망하지 마세요. 오히려 참 좋은 일입니다. 바꿔 말하자면 앞으로 머릿속에 입력될 지식이 많다는 뜻입니다. 지금보다 더 똑똑해지고, 더 가치 있는 사람이 될 테니 참 좋은 일이라고 할 수 있습니다.

이 책은 리버스 엔지니어를 꿈꾸는 리버싱 입문자들과 리버싱 기술에 흥미를 갖고 있는 개발자 등을 위하여 쓰여졌습니다. 

리버싱 기술들을 단순히 공식처럼 외우기만 해서는 필요한 순간에 제대로 응용 할 수 없습니다. 관련 지식을 얻고 내부 동작 원리를 이해하는 것이야말로 가장 중요합니다.  따라서 동작 원리를 설명하고 이해 시키는 데에 주안점을 두었습니다. 그럼 이 책이 왜 리버스 엔지니어링 입문서로 적합한지 제 소개를 곁들여서 설명해보도록 하겠습니다.

첫 째는 개발과 분석 경험입니다. 보통 리버스 엔지니어는 업무 과정에서 전문적인 리버싱 실력뿐만 아니라 어느 정도의 개발 실력도 갖추게 됩니다. 저는 네트워크 어플리케이션 개발자로 일하다가 악성 코드 분석 업무를 맡으면서 리버싱 기술을 익히게 되었습니다. 즉 전문 개발자에서 전문 리버서로  전향한 흔치 않은 케이스입니다. 이 두 기술은 그야말로 찰떡궁합처럼 상호 발전하고 보완하면서 기가 막힌 콤비 플레이를 보여줍니다. 평소에 이 둘을 양 날개에 비유하며 다양한 업무에 활용해 왔습니다. 따라서 자연스럽게 개발과 리버싱이라는 두 가지의 관점으로 프로그램을 분석하게 되었습니다. 이 책의 거의 모든 실습 예제는 리버싱 과정에서 얻은 지식과 노하우를 가지고 제가 직접 개발한 것으로서 군더더기 없이 각 장의 주제만을 집중해서 보여줍니다.

둘 째는 교육 및 발표 경험입니다. 회사에서 고참 직원이 되면서 점점 사내 교육/세미나, 외부 발표 기회가 많아졌습니다. 리버싱 입문자들에게 직접 리버싱 교육을 시키면서 그들의 어려움과 궁금증을 잘 파악할 수 있는 계기가 되었지요. 나름대로 어떻게 하면 쉽게 설명할 수 있을지 고민하면서 자연스레 리버싱 입문자를 위한 교육 노하우를 쌓을 수 있었습니다. 이 경험이 책의 구성, 내용, 예제 등 전반에 걸쳐 큰 영향을 끼쳐서 어려운 리버싱 기술을 비교적 쉽게 이해할 수 있도록 설명할 수 있었습니다.

셋 째는 다양한 커뮤니케이션 경험입니다. 몇 년 전부터 리버싱 전문 블로그를 운영하고 있습니다. 처음에는 제가 보유한 리버싱 기술의 정리 차원에서 가볍게 시작하였습니다. 그런데 방문객들이 조금씩 늘어 나면서 여러 가지 다양한 질문들이 올라오기 시작했습니다. 전 사실 이때 좀 놀랐습니다. 그 동안 우리나라는 리버싱의 불모지라고 여겼었는데 생각보다 많은 사람들이 관심을 보였고 관심 범위가 매우 다양했습니다. 그러면서 시야가 밖으로 넓어지는 계기가 되었습니다. 다른 리버싱 블로그도 방문하고 다양한 사람들의 글과 질문을 접하면서 그들의 관심사를 알 수 있게 되었는데요. 리버싱 입문자들은 체계적인 학습 방법을 알고 싶어 했습니다. 그리고 입문 과정을 지난 사람들은 좀 더 전문적인 리버싱 기술과 내부 동작 원리에 목 말라 하고 있었습니다. 블로그 활동을 어느 정도 한 이후부터는 체계적인 학습도구로서 기술 서적 집필을 고려하게 되었습니다.

결과적으로 저의 이러한 리버싱과 개발, 교육/발표, 다양한 커뮤니케이션 경험을 기반으로 하여 리버싱 입문 서적을 완성하게 되었습니다.

독자 여러분께 이 책을 이용한 리버싱 학습 방법에 대한 팁을 소개해 드리겠습니다.

첫째, 기술 서적은 책꽂이를 예쁘게 장식하는 용도가 아닙니다. 여러분의 기술력을 향상 시키기 위한 하나의 도구입니다. 따라서 책의 중요 부분에 밑줄을 팍팍 긋고, 여백에다가 여러분 자신의 생각과 느낌 등을 적어보시기 바랍니다. 연관된 기술, 주의 사항, 기술의 장단점, 저자와 다른 여러분 자신만의 아이디어 등을 신나게 기록하면서 여러분만의 책으로 만들어 보세요. 이런 리버싱 기술 서적을 한 권씩 독파하다 보면 어느 순간 여러분만의 독자적인 리버싱 세계를 구축하면서 리버싱 전문가가 될 수 있답니다.

둘째, 긍정적이고 여유 있는 마음 자세를 가지세요. 리버싱은 OS 의 가장 밑바닥까지 내려가는 심오한 기술입니다. 공부할 내용이 많고 그 특성상 대부분의 내용이 직접 실습하고 눈으로 확인해야만 이해 되는 경우가 많습니다. 이러한 과정을 긍적적인 마음으로 즐기시기 바랍니다. 그리고 리버싱 공부는 얼마나 머리가 좋은지가 아니라 얼마나 시간을 투자했는지가 더 중요합니다. 조급해 하지 말고 여유 있는 느긋한 마음 자세로 공부를 해나가시기 바랍니다.

셋째, 계속 도전하세요. 리버싱이 잘 안될 때는 멈추지 말고 다양한 방법으로 계속 시도해 보시기 바랍니다. 분명히 해결 방법은 존재합니다. 이미 몇 년 전에 누군가 성공시킨 일입니다. 관련 자료를 검색하고 다양하게 시도하면 자신의 실력도 향상될 뿐 아니라 문제가 해결되었을 때 엄청난 성취감을 느낄 수 있습니다. 이러한 성공 경험이 하나씩 쌓이면서 자신감이 생기고 리버싱 실력은 눈부시게 향상됩니다. 또한 경험을 통해 얻은 자신감은 무의식적으로 업무에 영향을 끼쳐서 일이 잘 풀리는 방향으로 나아가게 합니다.

이 책을 통하여 독자 분들의 위시 리스트가 하나씩 이루어 지고, 리버싱 기술이 다양한 IT 분야에서 널리 활용되기를 바랍니다. 감사합니다.

이 승 원

www.reversecore.com

reversecore@gmail.com

(2021.07.08) github.com 에도 제 계정을 생성하여 소스코드 및 실습예제를 올렸습니다. github 에 익숙하신 분들께서는 이곳을 이용하시면 됩니다. https://github.com/reversecore/book

 

1. 소스 코드 (ver 1.0.2)

 

* 36   [4쇄에서 수정됨]

간단히 MessageBoxW 함수의 RETN 명령까지 실행[Ctrl+F9]한 다음, RETN 명령도 실행[F7]하면, 리턴 주소 401014로 갈 수 있습니다.

=> MessageBoxW() 함수의 RETN 명령어에 BP 를 설치[F2]한 후 실행[F9]합니다. 도중에 메시지박스가 나타나면 [확인]을 선택합니다. 그리고 RETN 명령어에서 디버깅이 멈추면 StepInto[F7]/StepOut[F8] 명령으로 리턴 주소 401014로 갈 수 있습니다.

* 85   [2쇄에서 수정됨]

14장에서 EAX는 => 4장에서 EAX는

* 152   [2쇄에서 수정됨]

Line nunbers => Line numbers

바이트 of machine => Bytes of machine

마지막으로 IMAGE_FILE_HAEDER => 마지막으로 IMAGE_FILE_HEADER

* 157   [2쇄에서 수정됨]

빨간색으로 표시한 EXPORT => EXPORT

* 161   [2쇄에서 수정됨]

<코드 13.10>

Section is writeable => Section is writable

* 164   [4쇄에서 수정됨]

각각의 RVA를 계산해보세요 => 각각의 RAW(File Offset)를 계산해보세요

* 164   [2쇄에서 수정됨]

<그림 13.9>

<File> 에서 Section(".text") 생략됨

* 165   [4쇄에서 수정됨]

Q3. RVA = ABA8일 때 File Offset = ?

A2. 해당 RVA 값이 속해 있는 => A3. 해당 RVA 값이 속해 있는

* 170   [2쇄에서 수정됨]

<그림 13.11 IAT>

이 테이블은 PE 로더를 덮어씁니다. => 이 테이블은 PE 로더에 의해서 덮어써집니다.

* 178   [4쇄에서 수정됨]

표 13.8 notepad.exe 파일의 DataDirectory 배열  =>  표 13.8 kernel32.dll 파일의 DataDirectory 배열

* 178   [2쇄에서 수정됨]

<코드 13.14>

address of functino name string array => address of function name string array

* 179   [4쇄에서 수정됨]

<표 13.9 내부>

Ordinal 주소 배열 => Ordinal 배열

* 181   [2쇄에서 수정됨]

앞서 소개한 코드 13.15의 => 앞서 소개한 GetProcAddress() 동작 원리의

* 182   [2쇄에서 수정됨]

RVA:4424 -> RVA:3824 => RVA:4424 -> RAW:3824

* 183   [2쇄에서 수정됨]

RVA:2654 -> RVA:1A54 => RVA:2654 -> RAW:1A54

* 188   [2쇄에서 수정됨]

1000d(400h)바이트라면 => 1000d(3E8h)바이트라면

* 200   [2쇄에서 수정됨]

그림 14.13은 => 그림 14.3은

* 201   [2쇄에서 수정됨]

실실행되는 순간에 => 실행되는 순간에

* 207   [2쇄에서 수정됨]

EDI 레지스터가 가리키는 => EDX 레지스터가 가리키는

* 211   [2쇄에서 수정됨]

그림 15.4가 바로 OEP로 => 그림 15.9가 바로 OEP로 

* 215   [4쇄에서 수정됨]

<그림 16.1>  TEXT.EXE  => TEST.EXE

* 223   [4쇄에서 수정됨]

VirtualSize(1000) + Offset(420) = 1420(RVA)  =>  VirtualAddress(1000) + Offset(420) = 1420(RVA)

* 249   [4쇄에서 수정됨]

<그림 18.18>

01014000 => 01015000

* 253  (3쇄오류) [4쇄에서 수정됨]

3쇄에서 <그림 18.24> 이 완전 잘 못 되었습니다. 아래 그림이 정확합니다.

* 273   [4쇄에서 수정됨]

OEP(40120.)로 갑니다. => OEP(40121E)로 갑니다.

OR

OEP(40120E)로 갑니다. => OEP(40121E)로 갑니다.

* 277   [4쇄에서 수정됨]

<그림 20.13> 에서 "momory" => "memory"

* 281   [2쇄에서 수정됨]

JMP OEP(40120E) 명령을 => JMP OEP(40121E) 명령을

* 296   [4쇄에서 수정됨]

<코드 21.2> 내부의 KeyboardProc() 함수 내부 if ( nCode = 0 ) => if ( nCode >= 0 )

* 301   [4쇄에서 수정됨]

401006 주소에서 LoadLibrary(KeyHook.dl) => 401006 주소에서 LoadLibrary("KeyHook.dll")

* 322   [4쇄에서 수정됨]

메모리에 szDllName 크기만큼 => 메모리에 szDllPath 크기만큼 

* 384  [4쇄에서 수정됨]

그림 27.2 오류!

<그림 27.2 ThreadProc()>

* 422   [3쇄에서 수정됨]

ESI 레지스터는 그림 28.28에서 보다시피 => ESI 레지스터는 그림 28.31에서 보다시피

* 423   [3쇄에서 수정됨]

함수의 리턴 값은 EAX에 저장되므로 위 그림을 보면 => 함수의 리턴 값은 EAX에 저장되므로 그림 28.32을 보면 

* 502   [3쇄에서 수정됨]

보기 옵션을 'Integer Address'로 변경하면 => 보기 옵션을 'Long - Address'로 변경하면

* 523   [2쇄에서 수정됨]

XXXXXXXX = (DWORD)pfnNew - (DWORD)pfnOrg - 5 => // XXXXXXXX = (DWORD)pfnNew - (DWORD)pfnOrg - 5

dwAddress = (DWORD)pfnNew-(DWORD)pfnOrg 5 => dwAddress = (DWORD)pfnNew - (DWORD)pfnOrg - 5

* 573   [4쇄에서 수정됨]

NewInternetConnetcW() 함수의 코드 => NewInternetConnectW() 함수의 코드

* 615   [4쇄에서 수정됨]

<그림 38.1> 우측 하단의 "이 테이블은 PE 로더를 덮어씁니다." 설명이 잘못되었습니다.

"이 테이블은 PE 로더에 의해 덮어써집니다." 가 맞습니다.

* 647   [4쇄에서 수정됨]

<코드 45.1 ASLR.cpp>

#include "studio.h" => #include "stdio.h"

* 691   [2쇄에서 수정됨]

<코드 45.5 TlsTest.cpp>

#include windows.h => #include <windows.h>

* 772   [2쇄에서 수정됨]

Vol. 2B -> Vol 2C   (Intel Manual 이 업데이트 되었습니다.)

저도 오늘 갑자기 편집자님의 메일을 받고 알게 되었네요~ @@~

예약판매 페이지가 떴습니다. ^^

[리버싱 핵심 원리 : 악성 코드 분석가의 리버싱 이야기]

이승원 저

인사이트(Insight)

마음의 준비 없이 갑자기 전해 들은 소식이라... 저도 좀 놀랐습니다...

드디어 나오다니요... 지금 기분을 어떻게 말로 설명할 수 가 없네요~~~ ㅎㅎㅎ

관심 가져 주시고 응원해 주신 모든 분들께 감사드립니다. ^^~

후킹 방법 결정 - 무엇을? 어떻게? 후킹 할 것인가?

우리의 목표는 [HxD.exe 프로그램에서 PE 파일을 열었을 때 상태바의 "Offset: XXXX" 문자열에 "RVA: YYYY" 문자열을 추가하기]  입니다.

기존 어플리케이션에 어떤 기능을 추가(혹은 수정) 하려고 마음을 먹었다면 그 다음에는 구체적인 방법에 대해 고민을 해야 합니다. 즉, 후킹 설계 과정으로 들어가야 합니다.

윈도우즈 OS의 대표적인 후킹 기법은 "메시지 후킹(Message Hooking)" 과 "API 후킹(API Hooking)" 입니다. 둘 중에서 목표 달성에 더 적합하고 구현이 편리한 방법을 사용하는 것이 좋을 것입니다.

일반적으로는 메시지 후킹 기법이 더 간단하고 더 안전하다고 볼 수 있습니다. 대신 경우에 따라(특히 GUI 관련) 더 많은 고려사항이 필요한 경우가 있습니다. 따라서 실전에서는 후킹 설계 단계에서 메시지 후킹 방법이 더 편리할지 확인해 보는 것이 좋습니다.

메시지 후킹 기법 검증

우리 목표에 메시지 후킹 기법이 잘 어울릴지 검증해 보도록 하겠습니다. 

Windows OS 는 어플리케이션 윈도우의 GUI 처리 작업을 위해 윈도우 메시지를 이용합니다. HxD.exe 의 상태바도 일종의 윈도우입니다. 프로그램 내부에서 상태바에 특정 문자열을 쓰기 위해 관련된 윈도우 메시지를 전달할 것입니다. 

HxD.exe 의 상태바에 있는 "Offset: XXXX" 문자열이 변경될 때 상태바 윈도우 프로시저(Window Procedure)에서 처리하는 윈도우 메시지들을 확인해 보겠습니다. 먼저 HxD.exe 프로그램을 실행 하신 후 적당한 PE 파일을 열어 주세요.

그리고 윈도우 메시지를 모니터링 하기 위해 Spy++ 유틸리티를 실행합니다.

<그림 3 - Spy++ 실행화면>

Spy++의 툴바에서 "Log Messages... (Ctrl+M)" 버튼을 선택합니다. (또는 "Spy - Log Messages..." 메뉴를 선택하셔도 됩니다.)

<그림 4 - Log Messages... (Ctrl+M) 툴바 버튼>

Message Options 다이알로그가 나타납니다.

<그림 5 - Message Options 다이알로그>

Windows 탭의 Finder Tool 을 이용할 것입니다. Finder Tool 아이콘을 마우스 버튼을 누른 채로 드래그 하면 마우스 포인터가 과녁 모양으로 바뀝니다. 이 과녁 모양의 마우스 포인터를 HxD 의 상태바 윈도우에 위치시킨 후 마우스 버튼에서 손을 떼면 Spy++ 의 타겟(Target) 윈도우로 설정됩니다. (과녁 모양의 마우스 포인터 밑에 있는 윈도우는 두꺼운 검은색 테두리가 생겨서 잘 알아 볼 수 있습니다.)

<그림 6 - Finder Tool 로 상태바 설정>

이제 Spy++ 의 Message Options 다이알로그의 "Selected Object" 섹션에 지금 선택된 HxD 의 상태바 윈도우에 대한 정보들이 표시됩니다.

<그림 7 - HxD 의 상태바 윈도우 정보>

각 정보들이 나타내는 의미는 <표 1>과 같습니다.

항목	의미	값
Window	윈도우 핸들	001B0362
Text	윈도우 텍스트	Offset: 0
Class	윈도우 클래스 이름	TXmStatusBar
Style	윈도우 스타일	54000100
Rect	윈도우 위치와 크기	(15, 663)-(589, 684) 574x21
Thread ID	윈도우를 생성한 스레드 ID	00000150
Process ID	윈도우가 속한 프로세스 ID	00000F30

<표 1 - Selected Object 항목들의 의미>

윈도우 클래스 이름이 "TXmStatusBar" 인 걸로 봐서 윈도우 기본 상태바(StatusBar)를 서브클래싱(SubClassing) 한 것으로 추정됩니다. 그렇다면 기본 동작은 윈도우 기본 상태바와 비슷할 것이라고 예상해 봅니다.

Message Options 다이알로그의 [확인] 버튼을 선택하면 이제부터 Spy++ 은 HxD 의 상태바 메시지를 모니터링하기 시작 합니다. 시험 삼아서 마우스 포인터를 상태바 위에서 이리저리 이동해 보시기 바랍니다. Spy++ 화면에 마우스 관련 메시지가 많이 나타날 것입니다.

<그림 8 - 마우스 이동 메시지>

Spy++ 의 메시지 캡쳐 옵션을 디폴트인 'ALL' 로 설정하였기 때문에 상태바로 전달되는 모든 메시지가 표시되는 것입니다. 우리가 진짜 궁금한 내용은 상태바에 문자열이 써지는 순간에 어떤 메시지를 받느냐 하는 것입니다. 

Spy++ 툴바의 'Clear Log (Del)' 버튼을 선택하여 지금까지 쌓인 로그를 지워버립니다. 그리고 HxD.exe 의 메인 화면 내의 아무 부분을 마우스로 클릭하시기 바랍니다. 마우스가 선택한 파일의 옵셋을 상태바에 출력하기 위해 메시지가 전달될 것입니다.

<그림 9 - 문자열 출력 메시지>

HxD 메인 윈도우에서 마우스 클릭을 한번 하면 정확히 9개의 메시지 로그가 출력됩니다. (제가 보기 편하게 들여쓰기를 하였습니다.)

1번 로그의 메시지는 WM_USER(0x400)+A 이고 그 때의 lParam 값은 0012FA84 입니다. lParam 값이 마치 스택의 주소를 가리키는 것으로 추정됩니다. 그리고 4번 로그의 메시지는 WM_USER(0x400)+1 이고 lParam 값은 01A06768 입니다. 이 값 또한 메모리 주소를 표시한다고 추정해 볼 수 있겠습니다. 

마우스(또는 키보드)를 이용하여 HxD 메인 윈도우의 커서를 다른 옵셋으로 이동시키면 기본적으로 이와 동일한 9 개의 메시지 로그가 기록됩니다. 그리고 4 번째 로그의 lParam 값은 계속 바뀌는 것을 알 수 있습니다. (아마 동적 할당 메모리로 추정됩니다.)

따라서 상태바 윈도우는 사용자 정의 메시지인 WM_USER+1 또는 WM_USER+A 메시지를 받아서 lParam 이 가리키는 주소의 문자열을 상태바 윈도우에 쓴다고 추정해 볼 수 있겠습니다. 그 중에서도 4번 로그 메시지 WM_USER+1 을 받은 직후 WM_PAINT 와 WM_ERASEBKGND 메시지가 연속해서 나타나는 걸로 봐서는 WM_USER+1 메시지가 상태바 윈도우에 실제 값을 쓰라는 명령으로 보입니다.

디버거를 이용하여 lParam 이 가리키는 주소를 확인해보면 앞에서 추론한 내용이 맞는지 알 수 있겠지요.

디버깅

OllyDbg 를 실행하여 HxD.exe 프로세스에 Attach 시킵니다. 디버거는 ntdll.dll 메모리 영역의 System Break Point 위치에서 멈춥니다. 디버거를 실행[F9] 시켜 줍니다. 

윈도우 메시지를 디버깅 할 때는 주의사항이 있습니다. 그건 바로 디버기 프로세스(HxD.exe)의 윈도우를 가리면 안된다는 것입니다. 즉 OllyDbg 나 Spy++ 윈도우에 의해 HxD 윈도우가 가려졌다가 나타났다가 하게 되면 불필요한 로그가 Spy++ 에 쌓이게 됩니다. (물론 Spy++ 옵션을 고쳐서 모니터링 메시지를 필요한 것 만으로 제한해도 됩니다.) 

작업 편의상 각 윈도우들을 독립적으로 배치 시켜 주시기 바랍니다.

<그림 10 - 윈도우 배치>

다시 Spy++ 의 로그를 깨끗이 지우신 다음 마우스로 HxD 메인 윈도우 아무 곳이나 선택해 주세요. 제 경우에 Spy++ 의 WM_USER+1 로그의 lParam 주소는 01A0BA28 입니다. 

<그림 11 - 새로운 lParam 값>

이 주소를 OllyDbg 의 메모리 윈도우에서 검색해 보겠습니다.

<그림 12 - OllyDbg 에서 확인한 lParam 내용>

HxD 의 상태바에 나타난 것과 동일한 문자열이 ASCII 형태로 표시되어 있습니다. (이 경우에는 운좋게 예상과 잘 맞아서 쉽게 발견할 수 있었습니다.) 이 WM_USER+1 메시지를 후킹해서 lParam 이 가리키는 문자열("Offset: XXXX")을 읽은 후 RAW -> RVA 변환하여 표시해 주면 목표를 완수 할 수 있을 것 같습니다.

결론적으로 메시지 후킹 방법은 우리 목표에 잘 들어맞는 방법입니다. 다음 포스트에서 실제 메시지 후킹을 구현해 보도록 하겠습니다.

ReverseCore