반응형

어플리케이션 후킹(Application Hooking) 설계(디자인)에 대한 설명입니다. 후킹 방법을 결정하고, 검증하는 과정을 보여드립니다. 



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


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


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


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


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



메시지 후킹 기법 검증


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


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


* 참고 


GUI 관련 API 를 호출하면 GUI 작업 처리를 할 수 있기 때문에 마치 윈도우 메시지를 사용하지 않고도 작업이 가능한 것처럼 생각될 수도 있습니다. 그러나 실제로는 API 내부에서 윈도우 메시지를 보내는 것입니다. 일반적인 GUI 작업은 메시지 기반으로 동작한다는 것을 기억하시기 바랍니다.


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


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



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


* 참고


윈도우 메시지 확인에 있어서 Spy++ 은 최고의 유틸리티입니다. 기본 동작 원리는 윈도우 메시지 후킹입니다. 모니터링 대상 프로세스에 DLL 을 인젝션 시켜서 사용자가 원하는 메시지를 모니터링 합니다. Spy++ 은 Microsoft Visual Studio 패키지에 포함된 유틸리티 입니다. 


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 항목들의 의미>


* 참고


Spy++ 에서 보여주는 상태바 윈도우의 정보는 나중에 메시지 후킹을 구현할 때 좋은 참고자료가 됩니다.


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


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



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


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


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



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


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


<00001> 001B0362 S message:0x040A [User-defined:WM_USER+10] wParam:00000000 lParam:0012FA84

<00002> 001B0362 R message:0x040A [User-defined:WM_USER+10] lResult:00000001


<00003> 001B0362 P WM_PAINT hdc:00000000


<00004> 001B0362 S message:0x0401 [User-defined:WM_USER+1] wParam:00000000 lParam:01A06768

<00005> 001B0362 S   WM_PAINT hdc:00000000

<00006> 001B0362 S     WM_ERASEBKGND hdc:33010BC2

<00007> 001B0362 R     WM_ERASEBKGND fErased:True

<00008> 001B0362 R   WM_PAINT

<00009> 001B0362 R message:0x0401 [User-defined:WM_USER+1] lResult:00000001


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 이 가리키는 주소를 확인해보면 앞에서 추론한 내용이 맞는지 알 수 있겠지요.


* 참고


WM_PAINT 는 윈도우를 다시 그릴 때 발생되고, WM_ERASEBKGND 는 윈도우 배경을 지울 때 발생됩니다. WM_USER (0x400) 이후부터는 사용자 정의 메시지로서 프로그래머가 마음대로 지정해서 사용할 수 있습니다. 물론 메시지를 받는 윈도우 프로시저에서 사용자 정의 메시지를 잘 처리할 수 있도록 구현해야 합니다. 해당 메시지에 대한 더 자세한 설명은 MSDN 을 참고하시기 바랍니다.



디버깅


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 변환하여 표시해 주면 목표를 완수 할 수 있을 것 같습니다.


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


* 참고


사실 제가 처음 떠올렸던 아이디어는 단순한 마우스 메시지 후킹이었습니다. HxD.exe 상태바의 문자열이 바뀌려면 먼저 마우스로 커서 위치를 바꿔줘야 했으니 마우스 훅 프로시저에서 상태바의 문자열을 읽고 쓸 수 있지 않을까 하고 말이죠. 그러나 조금 더 생각해보니 좋은 아이디어가 아니라서 접었습니다. 이유는 키보드로도 커서 위치를 바꿀 수 있으니 키보드 메시지도 후킹 해야 할 테고, 상태바 윈도우가 다시 그려져야 하는 모든 상황(윈도우 이동, 윈도우가 가려졌다가 다시 나타나기, HxD 에서 다른 파일 열기, 기타)을 고려했을 때 후킹해야 할 메시지가 많아 질 것 같았기 때문입니다. 

따라서 덮어놓고 후킹을 시도하기보다는 먼저 차분히 생각을 정리해보고, 아이디어를 검증하는 단계가 매우 중요하다고 볼 수 있겠습니다.




ReverseCore

반응형
반응형


리버싱 기술을 이용하면 기존 어플리케이션의 버그를 수정하거나, 새로운 기능을 추가시킬 수 있습니다. 간단한 실습 예제를 통하여 동작원리를 소개하도록 하겠습니다.





리버싱 기술의 활용



리버싱 기술이 꼭 다른 프로그램을 분석하는 용도로만 사용되는 것은 아닙니다. 약간의 아이디어와 끈기만 있다면 여기서 조금 더 나아가 개발자들이 시도하지 않는 방법으로 작업을 진행할 수 있답니다. '개발 관점' 에서는 어렵게 보이는 문제이지만 오히려 '리버싱 관점' 에서는 쉽게 해결할 수 있는 경우도 있습니다.


* 참고


어플리케이션에 추가 기능을 삽입하는 것은 마치 "API Hooking - 계산기, 한글을 배우다. (1)" 와 비슷한 맥락의 작업 이라고 볼 수 있습니다.


자신이 개발하지 않은 (소스 코드를 가지고 있지 않은) 다른 어플리케이션의 버그 수정이나 전혀 새로운 기능 추가 같은 작업이 바로 그 좋은 예입니다. 이러한 작업의 핵심기술은 "Debugging""Injection" 그리고 "Hooking" 입니다. 또한 어셈블리 언어, PE File Format 등의 지식도 매우 중요합니다.


1) Debugging 


디버깅 기술은 매우 다양하게 사용됩니다. 먼저 작업 설계 단계에서 문제를 파악하고 해결 아이디어를 검증하고 구체화 시키는데 필수적으로 사용됩니다. 구현 단계에서 단위 모듈을 검증하는데에도 사용되고, 마지막 테스트와 버그 파악에 빠져서는 안되는 가장 중요한 기술입니다.


2) Injection


다른 프로세스를 수정하려면 일단 그 프로세스 메모리 영역으로 침투해야 합니다. 이게 바로 인젝션 기술의 역할입니다. 일단 프로세스 메모리에 침투하기만 하면 절반은 성공이라고 볼 수 있습니다.


3) Hooking


기존 코드와 다르게 동작시키려면 후킹 기술을 사용하면 됩니다. 기존에 있던 코드의 흐름을 변경시켜 사용하지 못하게 할 수 도 있고, 새로운 코드를 추가하여 전혀 다르게 동작시킬 수 도 있습니다. 


이제 간단한 실습 예제를 분석하면서 "기존 응용프로그램에 새로운 기능을 추가시키는 방법" 에 대해서 알아보도록 하겠습니다. 제가 아이디어를 내고 구체화 시키고 검증하는 과정, 그리고 실제로 구현하면서 부딪쳤던 문제들과 해결 과정에 대해 자세히 보여드릴 겁니다. 향후 여러분께서 리버싱 기술을 실무에 적용하실 때 작은 도움이 될 것입니다.




실습 프로그램 - HxD.exe 




<그림 1 - HxD.exe>


위 그림은 제가 평소 애용하는 헥스 에디터 HxD.exe 의 실행 화면입니다. dummy32.dll 라는 이름의 PE 파일을 열고 있네요. 


문득 "화면 좌측 하단의 Offset 표시 영역에 RVA 를 계산해서 같이 표시해 주면 어떨까?" 라는 아이디어가 떠올랐습니다. 아이디어의 유용성 여부를 떠나서 일단 재미있어 보였고, 어플리케이션 기능 추가라는 주제에 잘 맞을거 같다는 생각이 들었습니다.


여러차례 시도 끝에 결국 아래와 같이 성공할 수 있었습니다.



<그림 2 - PE 파일의 RVA 표시 기능이 추가된 HxD.exe>


먼저 Offset 과 RVA 를 동시에 표시하기 위해 status bar 의 좌측 하단 영역의 길이를 조금 늘렸습니다. 그리고 글씨를 출력하는 API 를 후킹하기 위한 hxdhook.dll 을 인젝션 시켰습니다. 또한 Offset <-> RVA 변환 계산 모듈 PEInfo.dll 을 로딩하여 계산을 수행하도록 만들었습니다. 이제 HxD.exe 에서 PE 파일을 열고 커서 위치가 변할 때마다 해당 파일 Offset 과 RVA 가 자동으로 표시됩니다.


다음 포스트에서 구체적인 작업 내용과 동작 원리에 대해 알아보도록 하겠습니다.



* 참고


위 실습 예제 파일은 "HxD.exe 기능 추가" 페이지에서 다운 받으실 수 있습니다.




ReverseCore


반응형
반응형

안녕하세요. ReverseCore 입니다. 

책 원고 작성을 완료하였습니다.

모든 컨텐츠 작성을 마치고 자체 퇴고(8회)를 완료하였습니다.

이제 출판사에 넘겨줄 수 있겠네요. ^^~



<퇴고 작업을 도와준 아이패드>


분량


8섹션, 61챕터, A4 기준 1000 페이지 입니다.
885 개의 이미지와 65 개의 소스파일이 담겨있습니다.
책 이름도 결정 하였습니다. (나중에 공개할 께요~ ^^)


내용


기존 블로그의 내용 60% + 새로운 컨텐츠 40% 로 구성하였습니다.

블로그에 있는 내용들은 Windows XP + Visual C++ 6.0/2008 환경에서 작업했었습니다. 이를 최신 Windows 7 32bit + Visual C++ 2010 환경으로 재작업을 하였구요. 컨텐츠들의 순서 조정에 많은 고민을 하였습니다.

새로 추가된 내용들은 아래와 같습니다.


64 bit Computing / Debugging
고급 리버싱 (TLS, TEB, PEB, SEH, IA-32 Instruction 해석)
Anti-Debugging (Static, Dynamic, Advanced)
디버깅 실습 (Service, Self-Creation, PEImageSwitching, DebugBlocker)
 



일정


2010년 5월 1일 책을 쓰기로 마음 먹고 2011년 12월 3일 원고를 마감하였네요. 원고 작업만 19 개월 소요되었군요. (블로그 시작한날인 2009년 2월부터 따져보면 벌써 약 33 개월이 지났네요.)

아직까지는 제 인생 최대의 프로젝트라고 말할 수 있겠습니다. ^^

2011년 6월말쯤 8장 마지막 챕터를 끝내고 책에 뭐 빼먹은게 없나 살펴보니, 문득 제가 애초에 기획했던 모든 컨텐츠 작성을 끝냈다는 사실을 깨달았습니다.

약간 멍~ 했죠. 조금 재충전을 하고 퇴고 작업에 들어갔습니다. 노트북으로 들고 다니며 보는데 한계가 있어서 문서를 출력해서 보다가 분량이 너무 많아서 힘들었습니다. 그래서 아이패드에 문서를 전부 입력하고 PDF Viewer 앱과 터치펜으로 퇴고 작업을 했습니다. (퍼포먼스가 확 향상되더군요.) 약 5 개월간의 기나긴 퇴고 작업 끝에 드디어 원고를 탈고 할 수 있었습니다.

마침 아내가 아기와 외출한 시간(12월 3일 토요일 오후 6시)에 제가 계획한 8 단계 퇴고작업의 마지막 작업을 끝마칠 수 있었네요. 


소감


일단 기분이 몹시 좋습니다. 몸과 마음이 날아갈듯 하네요. ^^ 
마치 오랜 여행을 마치고 집에 돌아온 느낌이 드네요. 기쁜 마음에 이렇게 블로그에 글을 올려 봅니다. 


# 작업 속도

책을 쓸 때는 생각보다 작업 속도가 너무 느려서 도대체 언제쯤 책이 완성될 수 있을까 싶었습니다. 하루에 그림 하나 또는 캡쳐 두개 정도 밖에 못 할 때도 많았거든요. 하지만 그런 날들이 하루 이틀 쌓이니까 어느 순간부터는 "내가 언제 이렇게 많은 일을 했지?" 라는 생각이 들면서 목표 지점이 희미하게나마 보이기 시작했습니다. 


# 재작업

책을 쓰면서 가장 힘들었던 순간은 이미 한번 쓴 글을 두번 세번 다시 쓸 때 였습니다. 독자분들께 최신의 리버싱 경험을 드리기 위해 개발도구를 Visual C++ 2010 으로 바꾸고 작업환경을 Windows 7 으로 바꾸었습니다. 그러다보니 기존 문서를 그에 맞게 다시 캡쳐하고 변경된 주소를 찾아 고치는 작업들이 많았습니다. 지금와서 뒤돌아보니 그런 작업들이 가장 기억에 많이 남습니다. 


# 슬럼프

10 여회의 크고 작은 슬럼프를 경험하였습니다. 수많은 재작업과 검증, 생각대로 나오지 않는 글쓰기, 예상보다 훨씬 오래 걸리는 시간, 개인적인 외부 요인 등으로 인해서 글을 쓰지도 못하고 글쓰기 자체가 싫어지는 상황이 몇 번 닥쳤었죠. 스트레스가 쌓인 겁니다.

제가 새벽에 일어나 글을 쓰는 책상이 있는데요, 어느 순간에는 그쪽을 쳐다보기도 싫어지더군요. 그리고 저녁에는 퇴근 후 글을 쓰러 찾아가는 도서관이 있습니다. 한때는 그쪽으로 발길이 도저히 떨어지지 않는 날도 많았습니다.

다행인것은 그때마다 제 자신이 슬럼프 상황인걸 인식하고 극복하려고 노력했다는 것입니다.


# 응원

가끔 블로그에 방문해서 댓글에 답변도 달아드리고 제 책을 응원하는 글을 보면서 힘을 얻곤 했습니다. 그리고 부모님, 아내, 친구들, 회사 동료들까지 많은 분들께서 관심을 가져주시고 격려를 해주셨습니다.

이 자리를 빌어서 모든 분들께 감사 드립니다.

그리고 제가 좋아하는 독서도 많이 하고 사람들과 많이 어울려 다니면서 다시 용기를 얻어서 작업을 이어나갈 수 있었습니다. 그러다 결국 여기까지 올 수 있었구요.

"포기하기 전까지 실패란 없다. 시행착오가 있을 뿐이다. 시행착오를 거듭하다보면 언젠가 결국 성공하게 된다."

위 명언을 계속 새기면서 포기하지 않고 꾸준히 작업했더니 결국 원고가 완성되었습니다.


# 앞으로...

출판사와의 일정이 잡히면 블로그에 다시 공지해 드리겠습니다.

원고 작업을 한번 성공하니 자신감이 충만해 지는게 느껴집니다. 이번에 많은 경험과 시행착오를 겪어보니 두 번째 책도 금방 쓸 수 있을 것 같은 기분입니다. (2 탄을 기획 중인데요. 구체적으로 정리되면 알려드릴께요~)


다시 한번 모든 분들께 감사 드립니다. ^^~


ReverseCore
반응형
반응형

"리버싱 공부를 어떻게 시작해야 할지 모르겠어요. 도와주세요." 라는 질문을 종종 받곤 합니다. 제가 블로그 활동을 하는 이유는 우리나라의 리버싱 기술 수준을 향상시키고, 리버싱 기술을 널리 전파하는데 작은 힘을 보태는 것입니다. 특히 리버싱에 처음 입문하시는 분들께 길잡이 역할을 할 수 있다면 더이상 바랄게 없습니다.

과연 어떻게 하면 리버싱을 잘 할 수 있을지 제 생각을 얘기해 드리겠습니다.



1. 모든 공부에는 "목표"가 있어야 합니다.


"리버싱 전문가가 되기 위해", "취직을 위해", "흥미를 위해", "해커가 되기 위해" 등의 자신만의 목표가 필요합니다. 이러한 목표가 없으면 힘든 공부를 지속하기 어렵습니다. (도중 포기할 확률이 높아진다는 뜻입니다.) 목표는 여러분들에게 방향을 제시합니다. 그 목표를 향해 한발 한발 전진하시기 바랍니다.


2. "긍정적인 마인드"를 가지세요. 


잘못된 편견을 가지신 분들이 많이 계십니다.

- "저는 C 언어도 모르는데요... 리버싱을 할 수 있을까요?"  --->>> 물론이죠.
- "저는 어셈블리를 해본적이 없는데요... 리버싱을 못 하겠지요?" --->>> 천만에요. 잘 하실 수 있습니다.
- "저는 윈도우즈 구조를 전혀 모르는데요... 그래도 리버싱을 할 수 있을까요?" --->>> 무지 잘하게 되실 겁니다.

바로 위와 같이 "저는 XXX 를 모르는데요" 라던지 "저는 YYY 를 해본적이 없는데요" 라는 말은 리버싱을 공부할 때 전혀 의미없는 말입니다. 이런 말은 지레 겁을 먹게 만들고, 도전 의식을 꺾어버립니다. 시도조차 못해보고 포기하게 만드는 부정적인 말입니다. 오히려 "XXX 를 모르기 때문에 배우고 싶다" 라고 긍정적인 생각을 해보시기 바랍니다.

배워야 할 가짓수를 따지자면 수십 가지가 넘을 것입니다. 리버싱 초보자가 그걸 처음부터 다 배워야 할까요? 너무 힘들겠지요. 지겨워질 겁니다.

그냥 새로운 내용이 튀어 나올때마다 다 해결하고 넘어가려고 하지 마시고 일단 맘에 묻어두시고 계속 진행하시는 것이 중요합니다. 반복 학습 하는 과정에서 한가지씩 차츰 차츰 배워나가시면 됩니다.

예를 들어 "XOR EAX, EAX" 의 의미는 디버깅을 몇 번 해보시면 저절로 체감하게 되는 내용입니다. 처음 볼때나 낯설고 흥미롭지요. 하지만 100번 봤다고 생각해 보세요. 그냥 당연하게 받아들이게 됩니다. 오히려 같은 의미의 "MOV EAX, 0" 명령어가 이상하게 보일겁니다. XOR EAX, EAX 를 왜 안썼을까 하고 말이죠.


3. "재미"를 느끼셔야 합니다.


초보일수록 더더욱 리버싱 과정에서의 재미를 찾으셔야 합니다. 어렵고 지겨운데 어떻게 계속 해나갈 수 있겠습니까? 리버싱이 재밌고, 하나씩 모르는 걸 배워나가고, 내가 맘먹은대로 프로그램을 패치시키는 이런 과정에서 재미를 찾으셔야 하지요.

사람은 재미있는 일이라면 남들이 아무리 말려도 스스로 하게 되어있답니다.


4. "검색"을 생활화 하셔야 합니다.


"검색하면 9할은 나온다" <- 제가 어디서 읽은 후 맘속에 담아둔 명언 입니다. 특히 리버싱 기술은 수많은 검색을 통한 지식 습득이 필수적입니다. 역사가 짧고 관련 전문가도 적고 관련 서적도 거의 없다시피 하니까요. 일단 믿고 검색해 보시기 바랍니다. 반드시 원하시는 내용을 찾을 수 있으실 겁니다.


5. 제일 중요한건 "실천"입니다.


"Just Do It" 아시죠~

뭔가를 이루고는 싶은데... 맘을 먹으셨으면... 행동을 하셔야죠... 그것도 지금 당장 하는겁니다...

제 블로그에 있는 HelloWorld 부터 무작정 따라해보는 겁니다. 당연히 처음에는 하나도 아는게 없지요. 모든게 낯설게 느껴집니다. (특히 어셈블리 명령어는 거의 외계 언어로 보이죠.)

첫 목표는 디버거를 이용해서 main() 함수를 찾아가는 겁니다. 디버거에 일단 익숙해 지기 위해서 메뉴도 하나씩 건드려 보고요. tracing(StepIn[F7], StepOut[F8] 명령어를 이용) 을 마구 해보는 겁니다. 차츰 감이 오다가 결국 main() 을 찾게 됩니다. C 소스 코드와 Disasembly 코드의 차이도 확인해 보시구요. 시작은 성공하신 겁니다! 출발이 좋군요. ^^

그다음 간단한 crackme, patchme, unpackme 등을 찾아서 해보시구요.

흔히 볼 수 있는 메모장, 계산기등을 패치해봅니다. (아주 간단히 말이죠. 가령 기능을 막아본다던지 하는 그런 정도로요.) 그 후 차츰차츰 대상을 넓혀 가시는 겁니다.


6. "느긋한 마음"을 가지세요.


리버싱 초보자가 가장 걸리기 쉬운 병이 바로 "조급증" 입니다. 빨리 성과를 내고는 싶은데 공부가 만만치는 않고 실력은 제자리에서 맴돌고 있습니다. 자신이 얼마나 모르는 것인지, 제대로 가긴 하는 건지 너무 답답합니다. 어셈블리, 윈도우즈 내부구조, PE 파일 포멧, API 후킹 등 뭐 하나 쉬운게 없습니다. 어셈블리 한가지만 봐도 어디까지 공부를 해야 하는지 알 수 가 없지요. 이럴때 마음이 급해지고 목표를 잃어 버리게 됩니다. 

제가 해드리는 얘기를 잘 읽어 보시기 바랍니다.

世界最强 大韓民國 

위 한자들을 읽어 보세요. "세계최강 대한민국" 입니다. 대부분 정확히 읽으셨을 겁니다. 그렇다면 안보고 정확히 쓸 수도 있으신가요? 아마 안보고 쓰는건 쉽지 않으실 겁니다. ^^ 위 8 글자 중에서 한 두 글자를 모르더라도 주변 글자들을 통해서 전체를 읽어 낼 수 있습니다. 

저를 비롯한 많은 리버서들이 어셈블리 명령어를 100% 자유자재로 구사하지는 못합니다. 몇명은 그래도 어셈블리 프로그래밍이 가능하지만 많은 사람들은 그렇지 못합니다. 마치 위의 한자를 읽을 수만 있고 쓸 수는 없는 것과 비슷한 상황입니다. 그래도 리버싱만 잘해요~ ^^ 명령어를 모르면 찾아 보면 되니까요. 그 정도만 알아도 프로그램의 동작 흐름을 알아낼 수 있습니다. 아마 이런식으로 몇 년이 더 흐르면 지금보다 훨씬 잘하게 되겠지요.

중요한 것은 저와 제가 아는 모든 리버서들도 초보 시절에는 (여러분들과 같이) 다 고만고만한 조건이었다는 것입니다. 꾸준히 하다보니 자연스럽게 어느 정도의 실력이 쌓인 것이지요. 절대로 조급해 하지 않았습니다.

여러분들도 지금 당장 시작해보세요~ 분명히 성과가 나타날 것입니다.

제가 어떻게 장담하냐구요? 저는 사실 구체적인 성공 사례를 알기 때문입니다. 블로그를 운영하면서 많은 분들께 과분한 감사의 메일을 받았습니다. 그 사연들을 읽어보면 감동에 이어 전율이 흐를 때도 있습니다.

- 대학 졸업작품이 단과대 전체 최우수 작품으로 선정되었습니다. (상까지 받으셨다는...)
- 개발 프로젝트에 후킹 기술을 적용해서 쉽게 해결할 수 있었습니다. (유명 회사 개발팀 소속이십니다.)
- XX소프트웨어 멤버십에 합격했습니다. (XX 취직이 보장된다는 그런 곳이라죠.)
- 리버싱 프로젝트("문서 암호화")를 성공시켰습니다. (아마 대학교 동아리 였던걸로 기억합니다.)
- 기타...

이분들께서는 대부분 리버싱 초보셨습니다. 본인들의 불타는 열정으로 엄청난 성취를 이루어 내신 거지요. 따라서 제가 여러분도 할 수 있다고 장담할 수 있는 것이고요.

공부하시다가 모르시는 내용이 있으세요? 질문하세요~ 저도 다른 분들의 생각을 들어보고 같이 고민하는 것을 좋아합니다.

자, 지금 당장 시작하세요~ ^^

ReverseCore
반응형
반응형

리버서들이 가장 많이 사용하는 도구인 디버거(Debugger)에 대해 이야기 해보도록 하겠습니다.


리버싱 현업에서 사용되는 Debugger 들을 간략히 정리해 보겠습니다. 


1. OllyDbg



OllyDbg 는 사용이 편리하고 가볍고 빠른 무료 Debugger 입니다. 도저히 무료라고 보기 힘든 다양한 기능과 많은 Plugin 을 통한 확장성으로 인하여 수 많은 리버서들의 열광적인 지지를 얻고 있습니다. 

OllyDbg 는 리버싱 초보부터 전문가까지 폭넓게 사용되는 가장 인기 있는 디버거입니다.


<그림 1 - OllyDbg>

OllyDbg 의 장점으로는 가볍고 빠르며 상당히 다양한 기능과 많은 옵션을 제공한다는 것입니다. 또한 PlugIn 기능을 통한 확장성을 제공합니다. 가장 사용자가 많고 OllyDbg 를 이용한 리버싱 강좌가 많이 있기 때문에 초보자도 쉽게 배울 수 있습니다. 그리고 무료로 제공된다는 점도 큰 장점입니다.

단점으로는 개인이 혼자서 개발한 거라 업데이트와 후속 제품의 개발 주기가 늦다는 것입니다. 다행히 최근에 OllyDbg 2.0 Final 버전이 릴리즈 되었습니다. 비록 겉모습은 이전 버전과 동일하지만 내부 코드는 완전히 새롭게 프로그래밍 하여 속도와 정확성 등이 크게 향상되었다고 하네요.


2. IDA Pro



Hex-rays 사의 IDA Pro 는 현재 최고의 Disassembler & Debugger 라고 말할 수 있습니다. 과거에는 Disassembler 성격이 강했으나, 수많은 업데이트를 통해 Debugger 기능 또한 막강해 졌습니다. 

수 많은 다양한 기능들을 설명하는 전문 서적이 따로 존재할 정도로 엄청난 기능을 자랑합니다. 또한 Decompiler Plugin 등을 추가로 장착하면 리버싱이 말할 수 없이 편리해 집니다. 그만큼 가격도 비싸지요.

많은 리버싱 전문가들이 IDA Pro 를 주력으로 삼으면서 리버싱 전문 툴로써의 입지를 탄탄히 굳히고 있습니다.

장점으로는 다 써보지도 못할 정도로 다양한 기능과 충실한 업데이트를 들 수 있습니다. 다만 가격이 비싸고 사용법이 비교적 복잡하며 초기 로딩 시간이 좀 걸린다는 것을 단점으로 들 수 있겠습니다. 


<그림 2 – IDA Pro>


3. WinDbg



WinDbg 는 DOS 시절 16 bit 디버거인 debug.exe 의 Windows 버전입니다. 


<그림 3 – Debug.exe>

콘솔 화면에서 키보드만으로 디버깅을 하는 debug.exe 의 사용자 인터페이스를 그대로 가져왔습니다. 저는 이런 스타일의 프로그램을 매우 좋아하지만 반대로 거부감을 갖는 분들도 상당수 계십니다.

유저 모드 디버깅(User Mode Debugging) 분야에서는 사용자 편리성이 뛰어난 OllyDbg 나 IDA Pro 가 꽉 잡고 있습니다. 따라서 WinDbg 는 주로 커널 모드 디버깅(Kernel Mode Debugging)에 주로 사용됩니다. 전설적인 커널 디버거인 SoftICE 의 후속 제품 개발이 중단된 이후 커널 디버깅 분야에서 사실상 독보적인 존재가 되어 버렸습니다. (경쟁 제품이 없는 상태입니다.)

역사가 오래 된 만큼 기능도 다양하고 사용 방법에 대한 전문 서적이 여러 권 나와 있습니다.


<그림 4 - WinDbg>

장점은 커널 디버깅이 가능하다는 것과 Microsoft 에서 직접 만든 디버거라는 점입니다. 시스템 파일에 대한 심볼(Symbol)을 직접 다운 받을 수 있어서 시스템 내부 구조체(Undocumented 포함) 및 API 에 대한 정보를 얻을 수 있습니다. 또한 Windows OS 의 덤프 파일을 읽어 들여 분석할 수 있기 때문에 시스템 크래쉬(Crash)가 발생했을 때 원인을 분석해 낼 수 있습니다. 

단점으로는 다른 디버거들에 비해 좀 떨어지는 사용자 환경과 편의성을 꼽을 수 있겠습니다. (예를 들어 코드에 직접 주석을 입력할 수 없고, Disassembly 코드에서 호출되는 API 이름도 잘 표시되지 않는 등의 불편함이 있습니다.)

그래도 커널 드라이버 개발과 유지보수에 필수적으로 사용되는 디버거 입니다. 리버싱에서는 커널 드라이버 파일 분석에 주로 사용됩니다. 최근에는 대부분 WinDbg 와 VirtualPC(또는 VMWare) 조합으로 커널 디버깅을 수행합니다. 향후 여러분들의 리버싱 실력이 쌓인 후 커널 드라이버(예: Rootkit) 등을 분석할 때 자주 사용될 것입니다.

+---+

지금까지 리버싱 현업에서 사용되는 대표적인 디버거들에 대해서 간략히 살펴보았습니다.

제 경우에는 유저 모드 디버깅에 OllyDbg 1.10 를 사용하고, 커널 모드 디버깅에는 WinDbg 를 사용합니다.

ReverseCore
반응형

'tool' 카테고리의 다른 글

PEView.exe  (21) 2013.01.27
HxD.exe 기능 추가!  (12) 2012.06.14
InjDll.exe – DLL Injection/Ejection 전용 도구  (43) 2010.03.15
Process Explorer - 최고의 작업 관리자  (1) 2009.05.03
www.virustotal.com  (3) 2009.03.20
www.google.com  (2) 2009.03.06

+ Recent posts