반응형


가상 인터뷰 형식을 빌려 저와 책에 대한 소개를 합니다. 그리고 블로그와 책의 독자님들께 받은 질문들에 대한 답변을 정리하였습니다.



- 안녕하세요? 본인 소개를 부탁 드립니다.


안녕하세요~ 리버스 엔지니어 '리버스코어' 입니다.    

대학 시절부터 컴퓨터 프로그래밍에 매력을 느껴 공부를 했던 계기로 IT 에 입문하였구요.

소프트웨어 업체에서 3년 동안 네트워크 솔루션을 개발하였습니다.

그 후 보안회사로 이직하여 그때부터 쭉 악성 코드 분석업무를 하고 있습니다.

몇 년 전부터 리버스 엔지니어링 전문 블로그(ReverseCore.com)를 운영하고 있지요.



- 이번에 리버스 엔지니어링 분야의 책을 쓰셨는데요, 간단한 책 소개를 부탁 드릴께요.


'리버싱 핵심 원리' 라는 소프트웨어 리버스 엔지니어링 입문용 기술 서적입니다.


컨셉은 다음과 같습니다.


1) 쉽게 쉽게 쉽게

2) 기술 동작 원리의 이해

3) 흥미와 도전 욕구를 자극


이를 위하여 방대한 분량(1,020 페이지), 풍부한 그림(889개), 실습 예제 및 관련 파일(114개), 소스 코드(62개)를 제공하였습니다. 



대부분의 리버싱 기술은 기초적인 동작 원리를 이해하고 나면 그 뒤부터는 변형과 응용의 연속입니다. 따라서 원리를 이해하기 위한 개념 설명과 실습 예제 분석에 대부분의 지면을 할당하였습니다. 



그리고 리버스코어 블로그를 운영하면서 받았던 질문 중에서 초보자에게 유용한 질문과 답변들을 추려서 FAQ 형식으로 각 장의 뒤쪽에 배치 했고요. 리버스 엔지니어링을 처음 배울 때의 어려움과 고민에 대한 제 생각을 곳곳에 넣어 두었습니다.



- 책을 쓰게 된 계기가 있으실 것 같은데요.


리버스 엔지니어링이라는 기술을 처음 접한 이후 그 매력에 완전히 빠져 들었습니다.


실행 파일(PE File)의 구조와 프로세스의 동작 원리를 공부한 후 다른 프로그램의 내부 구조와 동작 원리를 파악할 수 있다는 사실에 엄청난 희열을 느꼈지요. 처음에는 악성 코드를 분석하여 악의적인 행위를 파악하는 일을 주로 하였습니다. 다양한 악성 코드의 기발한 리버싱 기법들을 보고 배우면서 정말 즐거웠습니다. 


하지만 이렇게 획기적이고 가능성이 무궁무진한 기술들이 주로 나쁜 의도를 가진 사람들에 의해 악용되고 있었습니다. 즉, 리버싱 기술 자체는 매우 쓸모가 많은데 그걸 나쁘게 사용한 사람들에 의해서 '어둠의 기술'로 저평가 되고 있고 별다른 활용 방안이 없다는 사실이 매우 안타까웠습니다.


그때부터 이 리버스 엔지니어링 기술을 좋은 쪽으로 활용할 수 없을까 궁리하게 되었지요. 그러다가 프로그램의 내부 동작 원리를 '분석'하는 차원을 뛰어 넘어 프로그램에 존재하는 버그를 수정하고, 새로운 기능을 추가하는 '패치' 작업까지 관심이 확대되었습니다. 리버스 엔지니어링 기술이 반드시 IT 산업에 큰 도움을 줄 수 있을 거라는 확신이 들었습니다.


제 나름대로 리버스 엔지니어링 기술을 전파시키고 싶어서 블로그 활동을 시작하였습니다. 그러던 중 많은 분들께서 체계적인 학습 방법에 대해 목말라 한다는 것을 알게 되었죠. 그래서 리버스 엔지니어링 입문용 기술 서적을 써보자고 마음먹게 되었습니다.



- 리버싱 기술을 배우면 뭘 할 수 있는지 얘기해 주시겠어요?

    

다른 프로그램의 내부 구조와 동작 원리를 파악할 수 있습니다.

예를 들어 악성 코드의 동작 원리를 파악하여 감염 경로, 악의적인 행위를 알아내고, 진단 및 치료 방법에 대한 아이디어를  얻을 수 있습니다. 특히 다른 파일을 감염 시켜 실행 파일 형태를 바꿔 버리는 기능을 가진 Virus 류의 악성 코드는 상세한 분석이 이루어져야만 진단과 치료 코드를 작성할 수 있습니다.


프로그램의 버그를 수정하고 새로운 기능을 추가 시킬 수도 있습니다. 

예를 들면 제작자가 업데이트를 중단한 유틸리티의 버그를 수정할 수 도 있고, 자신만의 독창적인 아이디어를 적용해 새로운 기술을 추가 시킬 수 도 있는 것이죠. (실제로 개발 업무를 담당하시는 분들께서 자신들의 프로젝트에 DLL Injection 과 API Hooking 기술을 활용하는데 조언을 구해오시는 경우가 종종 있습니다.)


제가 최초로 패치시킨 유틸리티는 출시된지 오래된 fhred 라는 이름의 hex editor 였습니다. 마우스 휠 스크롤 기능이 없어서 매우 불편했습니다. 그래서 마우스 메시지 후킹 기법을 사용하여 휠 스크롤 기능을 추가시켰습니다. 



사실 이때 이미 최신 버전의 frhed 에서는 마우스 휠 기능이 지원되고 있었습니다. 제가 가진건 아주 옛날 버전이었던 겁니다. 그냥 최신 버전을 사용하면 되는 거였지요. 


하지만 제가 배운 기술을 활용하여 제 손으로 직접 패치하고 싶었습니다. 결과적으로 이 작업을 계기로 리버스 엔지니어링 기술의 '패치' 활용 가능성에 대해 눈을 뜨게 되었습니다.



- 리버스 엔지니어링 분야의 진로에 대해서 소개해 주시겠어요?


최근에는 국내 기준으로 보안업체, 게임업체, 게임퍼블리싱업체, 대기업/금융업, 국가 행정 부서, 국가 연구 기관 등이 있습니다. 리버스 엔지니어로써 파일을 상세 분석하는 업무를 하시려면 보안업체, 게임업체, 사이버수사대 등을 고려하시면 될 것입니다. 각 업체별로 다양한 업무 직군으로 세분화되기 때문에 사전에 자신이 원하는 분야의 일을 맡을 수 있을지 확인하셔야 겠지요.


참고로 하드웨어 분야(자동차, 모바일, 반도체, 기타)에서는 리버스 엔지니어링의 역사가 오래 되었습니다. 경쟁사에서 신제품을 출시하면 바로 구입하여 상세 분석에 들어갑니다. 치수를 측정하고, 재질을 조사하고, 회로 기판 구조를 파악하는 등의 작업을 하지요. 기구의 설계 관점과 제품의 성능 관점에서 다양한 분석과 테스트가 이루어 집니다. 소위 말해서 벤치 마킹 작업입니다. 


향후 소프트웨어 분야에서도 전문 리버스 엔지니어가 이런 식의 벤치 마킹 업무를 수행하지 않을까 조심스레 예상해 봅니다. 



- 책 얘기로 돌아가서요, 책 출시 후 반응은 어떻습니까?


너무나 감사하게도 반응이 좋습니다. 인상 깊었던 점은 비슷한 시기에 출시된 리버싱, 디지털 포렌직, 해킹 관련 보안 서적들이 골고루 판매 순위 상위권에 자리잡고 있다는 것입니다. 아마 국내에서도 리버싱, 해킹, 보안에 관한 관심이 그만큼 커진게 아닐까 하고 생각해 봅니다. 


기술서적의 저자들은 자신들이 가장 자신있는 부분에 대해서 아주 자세하고 쓰게 됩니다. 따라서 책마다 저자들의 강점과 개성이 녹아있을 수 밖에 없습니다. 앞으로 더 다양한 리버스 엔지니어링 기술 서적들이 출시되어 전반적인 리버싱 기술 수준이 올라가길 희망합니다. 



- 이 책의 장점에 대해서 알려주시죠.


장점으로는 앞에서 소개한 쉬운 설명, 기술 동작 원리의 이해에 초점, 독자의 흥미와 도전 욕구를 자극하는 것입니다. 


추가적인 장점과 특징에 대해 알고 싶으시다면 책의 서문을 참고하시면 될 것 같습니다.


[리버싱 핵심 원리] 서문



- 책의 세부 내용에 대해서 좀 더 구체적으로 알려주실 수 있을까요?


좀 더 정리해서 다음 포스팅에 올릴께요~



- 기술 서적을 집필하면서 여러가지 에피소드가 많았을것 같은데요. 몇 가지만 소개해 주시겠어요?


어쨌든 집필 과정, 에피소드, 시행착오 등에 대해서 한번은 정리하고 싶었는데요. 

이것도 따로 올리는게 좋겠네요... ^^



- 인터뷰에 응해주셔서 감사합니다. 저자님의 향후 계획은 어떠신지요?


"리버싱 핵심 원리"의 AS (질문/답변)를 하면서 계속 지켜보고 싶습니다. 이 책은 제가 쓰긴 했지만 이제 정식으로 출시되어 제 손을 떠나 독자님들의 손으로 보내어졌습니다. 앞으로 독자님들에 의해서 얼마나 흥미진진한 일이 펼쳐지게 될지 저자로서 너무 궁금하고 설레입니다. (마치 책이 살아서 움직이며 자신의 운명을 개척해 나가는 것처럼 생각됩니다. ^^)


그리고 ReverseCore 블로그에 새로운 컨텐츠를 올릴 예정입니다. 일단 hxdhook 연재를 잘 마무리하고, 그 다음에는 64bit API 후킹에 대해 다뤄볼 생각입니다. 그 이후는 바이러스 파일 분석이 될지, 다이알로그 리소스 패치가 될지 아직 결정하지 않았습니다. (둘 다 너무 재미있는 주제입니다~ ^^)



- 마지막으로 리버스 엔지니어를 목표로 열심히 공부하시는 독자분들께 한 말씀 해주세요~


초반에 어려움을 느끼시는 분들께 이야기를 하나 들려드릴께요~ ^^

정지 마찰력(static friction)과 운동 마찰력(kinetic friction)의 얘기입니다.

정지한 물체를 밀어서 움직이게 하려면 처음에는 높은 저항력(정지 마찰력)때문에 힘이 많이 듭니다. 그런데 일단 물체가 '움찔'하고 움직이기 시작하면 그때부터 저항력(운동 마찰력)은 많이 낮아지면서 훨씬 수월하게 밀고 갈 수 있습니다. (주차장에서 차를 밀어본 경험이 있으시다면 금방 이해하실 겁니다. ^^*)

즉, 정지 마찰력 > 운동 마찰력 의 관계가 성립합니다.

Wiki : 마찰력
Google 이미지 검색 : 정지 마찰력

뭐든지 마찬가지라고 생각합니다. 처음에는 힘들지만 일단 시작하고 나면 탄력을 받아 일이 쉬워집니다. "시작이 반이다" 라는 속담은 정말 정확한 표현이었던거죠.

리버스 엔지니어링도 마찬가지입니다. 처음에는 힘들지만 그 정지마찰력 시기를 잘 넘기고 운동마찰력 영역으로 들어가면 속도가 붙고 재미도 생깁니다. 

저도 똑같이 그 과정을 거쳐왔답니다. 그러니 모두들 용기를 내세요~ ^^*


ReverseCore


반응형
반응형

HelloReversing.exex




문자열 패치

목표 달성이 눈앞에 다가왔습니다.

MessageBoxW 호출하는 부분을 찾았으니 이제 "Hello World!" 문자열을 "Hello Reversing!" 으로 패치시킬 차례입니다.

디버깅을 재실행[Ctrl+F2] 시키고, main 함수 시작 부분까지 실행합니다.
(401000 에 BP 를 설정[F2]하고 실행[F9] 하세요. - 이 주소를 2 번째 베이스 캠프라고 하겠습니다.)




문자열을 패치하는 2 가지 방법

가장 쉬운 2 가지 방법을 소개합니다.

  • 문자열 버퍼를 직접 수정
  • 다른 메모리 영역에 새로운 문자열을 생성하여 전달



1) 문자열 버퍼를 직접 수정

MessageBoxW 함수의 전달인자 4092A4 의 메모리 주소 내용("Hello World!\)을 직접 수정해 버리는 것입니다.

메모리 윈도우에서 4092A4 로 갑니다 [Ctrl+G].
그리고 주소를 마우스로 선택한 후 [Ctrl+E] 단축키로 에디트 윈도우를 띄웁니다.


<Fig. 16>


'UNICODE' 항목에 "Hello Reversing!" 을 입력합니다.

변경된 코드는 아래와 같습니다.


<Fig. 17>


명령어는 그대로
이지만 MessageBoxW 함수에 전달되는 파라미터의 내용 자체가 변경되었습니다.
(파라미터의 주소도 그대로 입니다. 주소의 내용이 변경된 것입니다.)

이처럼 문자열 버퍼 내용을 직접 수정하는 방법은 사용하기에 가장 간단한 방법입니다.

* 하지만 기존 문자열 버퍼 크기를 잘 고려해서 수정해야만 프로그램이 에러 없이 잘 동작할 수 있습니다.
  즉, 기존 문자열 버퍼 크기 이상의 문자를 입력할 수 없다는 제약 조건이 있습니다.

변경된 내용을 영구히 보존하려면 파일로 만들어야 합니다.
<Fig. 16> 의 dump 윈도우에서 변경된 내용 ("Hello Reversing!" 문자열)을 선택하여
마우스 우측 버튼의 Copy to executable file 메뉴를 선택하면 아래와 같이 hexa 윈도우가 나타납니다.


<Fig. 18>


다시 마우스 우측 버튼의 Save file 메뉴를 선택하고 파일 이름을 HelloReversing.exe 로 해줍니다.

실행해보면 문자열이 성공적으로 변경되었습니다!


<Fig. 19>




2) 다른 메모리 영역에 새로운 문자열을 생성하여 전달

1) 방법은 MessageBoxW 함수의 파라미터인 문자열 버퍼의 내용을 직접 수정하는 방법이었습니다.

간단하지만 그만큼 단점도 존재합니다.
가령 훨씬 긴 문자열로 수정하고 싶을때 해당 버퍼 크기가 작다면
인접한 다른 메모리 영역을 침범하는 buffer overflow 가 발생할 것입니다.

이럴때 사용할 수 있는 방법이 바로 다른 버퍼 주소를 전달하는 것입니다.
적당한 메모리 주소에 변경하고자 하는 긴 문자열을 적어 놓고
MessageBoxW 함수에게 그 주소를 파라미터로 넘겨주는 것입니다.

즉, 버퍼 자체를 변경하는 것이죠.

아이디어가 좋긴 한데 한가지 고려해야 할 사항은 "메모리 어느 영역에 문자열을 써도 되는가?" 입니다.

자세한 설명은 PE header가상 메모리 구조를 알고 계셔야 하므로 나중에 자세히 다루도록 하고,
여기서는 임의로 적절한 영역을 선택하도록 하겠습니다.

우리가 방법 1) 에서 수정한 버퍼는 408000 ~ 40A000 영역 (.rdata section) 입니다.
이 부분을 다시 dump 윈도우로 살펴보죠. dump 윈도우에서 408000 주소로 갑니다. [Ctrl+G]

스크롤을 밑으로 내리다보면 .rdata section 은 아래와 같이 끝이 납니다.


<Fig. 20>


끝부분에 NULL 로 채워진 영역이 보입니다.

* 이곳은 보통 프로그램에서 사용되지 않는 NULL padding 영역입니다.
  프로그램이 메모리에 로딩될 때 최소 기본 단위(보통 1000)가 있습니다.
  비록 프로그램내에서 메모리를 100 크기만큼만 사용한다고 해도 실제로는 최소 기본 단위인 1000 크기가 잡히는 것입니다.
  (나머지 F00 크기의 사용되지 않는 영역은 그냥 NULL 로 채워집니다.)

이곳을 문자열 버퍼로 사용해서 MessageBoxW 함수에 넘겨주면 좋을 것 같습니다.
끝부분의 적당한 위치 409F50 에 출력하고 싶은 문자열을 써주면 됩니다. [Ctrl+E]


<Fig. 21>


버퍼를 새로 구성하였으니 그 다음에 할 일은 MessageBoxW 함수에게 새로운 버퍼 주소를 전달하는 것입니다.

그러기 위해서는 코드를 수정해야 하는데,
이번에는 Code 윈도우에서 Assemble 명령을 사용해서 코드를 수정해 보겠습니다.

아래 그림처럼 cursor 를 401007 주소위치에 놓고 Assemble 명령(단축키 [Space])을 내리면
아래와 같은 Assemble 윈도우가 나타납니다.


<Fig. 22>


새로운 버퍼주소인 409F50 을 입력합니다.

* 디버깅의 강력한 기능중의 하나가 바로 위와 같이 실행중인 프로세스의 코드를 동적으로 패치 시킬 수 있다는 것입니다.

* 향후 실습해 볼 crackme 샘플에서 serial key 검사 코드를 건너뛰는 방법도 코드를 동적으로 패치하는 것입니다.

OllyDbg 에서 MessageBoxW 함수를 실행하면 결과는 <Fig. 19> 와 같습니다.

그런데 위 수정된 코드를 파일로 만들면 제대로 동작하지 않을 것입니다.
이유는 409F50 메모리 주소 때문입니다.

실행 파일이 메모리에 로딩되어 프로세스로써 실행될 때 그대로 1:1 로 로딩되는 것이 아니라,
어떤 규칙에 의해서 올라가게 되며, 보통은 파일과 메모리가 1:1 로 매칭 되지도 않습니다.

즉, 메모리 409F50 에 대응되는 파일 offset 이 존재하지 않는 것이죠.

방법 2)를 파일로 저장하기 위해서는 아래 2가지 방법중에 하나를 사용하시면 됩니다.

  • PE header 를 분석하여 파일에 존재하지만 프로그램에서 사용되지 않는 공간을 버퍼영역으로 선정
  • 파일 끝을 버퍼 영역 만큼 확장하고, PE header 를 수정하여 그 부분을 메모리에 로딩시킴


역시 PE header 를 알아야 하기에 여기서는 설명을 생략하였습니다.

* 앞으로 작성하게 될 PE header 강좌도 기대해 주세요~



배운내용

- OllyDbg 기초 사용법

Step Into [F7] : 하나의 OP code 실행 (CALL 명령을 만나면, 그 함수 코드 내부로 따라 들어감.)
Step Over [F8] : 하나의 OP code 실행 (CALL 명령을 만나면, 따라 들어가지 않고 그냥 함수자체를 실행함.)
Execute till Return [Ctrl+F9] : 함수 코드 내에서 RETN 명령어 까지 실행 (함수 탈출 목적)
Restart [Ctrl+F2] : 다시 처음부터 디버깅 시작. (디버깅 당하는 프로세스를 종료하고 재실행 시킴.)
Go to [Ctrl+G] : 원하는 주소를 찾아감. (코드를 확인할 때 사용. 실행되는 것은 아님.)
Execute till Cursor [F4] : cursor 위치까지 실행함 (디버깅 하고 싶은 주소까지 바로 갈 수 있음.)
Comment [;] : Comment 추가
User Defined Comments [마우스 우측 메뉴 -> Search for -> User defined Comment] : 사용자가 입력한 comment 목록 보기
Set/Reset BreakPoint [F2] : BP 설정/해제
Run [F9] : 실행 (BP 가 걸려있으면 그곳에서 실행이 정지됨.)
All referenced text strings [마우스 우측 메뉴 -> Search for -> All referenced text strings] : 코드에서 참조되는 문자열 보기
All intermodular calls [마우스 우측 메뉴 -> Search for -> All intermodular calls] : 코드에서 호출되는 모든 API 함수 보기
Name in all modules [마우스 우측 메뉴 -> Search for -> Name in all modules] : 모든 API 함수 보기
Edit data [Ctrl+E] : 메모리 수정
Assemble [Space] : Assembly 코드 작성
Copy to executable file [마우스 우측 메뉴 -> Copy to executable file] : 파일의 복사본 생성 (변경사항 반영됨)

- Assembly 기초 명령어

CALL XXXX : XXXX 주소의 함수를 호출
JMP XXXX : XXXX 주소로 점프
PUSH XXXX : 스택에 XXXX 저장
RETN : 스택에 저장된 복귀주소로 점프

- 프로세스 data/code 패치 방법

OllyDbg 의 ‘Edit data’와’Assemble’기능 이용

- 용어

VA (Virtual Address) : 프로세스내의 가상 메모리
OP code (OPeration code) : CPU 명령어 (byte code)
PE (Portable Executable) : Windows 실행 파일(EXE, DLL, SYS)




배워야할 내용

Virtual memory
PE header
Stack frame
OP code (advanced)
OllyDbg (advanced)



Epilogue

여기까지 따라 오시느라고 수고 하셨습니다.

위에 나온 모든 내용을 한번에 이해하기는 어렵습니다.
2 ~ 3번 반복해서 읽고, 직접 실습해 보시기 바랍니다.

C 프로그래밍에서 Hello World! 는 가장 간단한 프로그램이었습니다.
마찬가지로 Hello World! 디버깅 또한 가장 간단한 디버깅입니다.

Hello World! 를 시작으로 C 프로그래밍을 정복하셨듯이 디버깅 역시 정복하시기 바랍니다.

리버싱에서 디버깅이 차지하는 비중은 매우 큽니다. 또한 가장 재미있습니다.

부디 제 글이 디버깅의 재미를 조금이나마 전달해 드렸으면 좋겠습니다.

감사합니다.

반응형
반응형

원하는 코드를 빨리 찾아내는 4가지 방법

자신이 원하는 코드를 빨리 찾아내기 위해서는 여러가지 자신만의 노하우가 있습니다.
여기서는 가장 기본이 되면서 가장 유용한 4가지 방법을 소개합니다.

  • 코드 실행 방법
  • 문자열 검색 방법
  • API 검색 방법 (1) - 호출 코드에 BP
  • API 검색 방법 (2) - API 코드에 직접 BP


0) 이미 아는 사실

4가지 방법을 소개하기 전에 먼저 한번 생각을 해봅시다.

우리는 HelloWorld.exe 프로그램이 "Hello World!" 메시지 박스를 출력한다는 것을 이미 알고 있습니다.
물론 우리가 코드를 만들었기 때문이지만, 이 경우에는 그냥 실행만 해봐도 누구나 알 수 있는 것입니다.

C 언어 개발자들이라면 MessageBox 계열 함수가 머릿속에 떠오를 것입니다.

이렇게 프로그램의 기능이 명확한 경우는 그냥 실행만 해봐도 내부 구조를 대략적으로 추측할 수 있습니다.
(물론 개발/분석 경험이 요구됩니다.)



1) 코드 실행 방법

우리가 원하는 코드main() 함수내의 MessageBox() 함수 호출 코드 입니다.
OllyDbg 디버거로 HelloWorld.exe 를 디버깅하면 어느 순간 자동으로 메시지 박스를 띄워 주는데요,
디버깅을 해나가다 보면 언젠가 main() 함수내의 MessageBox() 함수가 실행되어 "Hello World!"  메시지박스가 출력되겠지요?

이것이 코드 실행 방법의 원리입니다.
기능이 명확한 경우에 소스 코드를 실행해 가면서 찾아가는 것입니다.
코드 크기가 작고 기능이 명확한 경우에 사용할 수 있습니다.
코드 크기가 크고 복잡한 경우에는 적절하지 않습니다.

OllyDbg 와 콘솔 윈도우를 적절한 크기로 조정하여 동시에 살펴 볼 수 있도록 하세요.

베이스 캠프(40104F)에서부터 명령어를 한줄한줄 실행[F8]해 봅니다.
어느 순간 "Hello World!" 메시지 박스가 출력 되어 있을 것입니다.
몇 번 반복해 보시면 특정 함수를 호출 한 이후에 메시지 박스가 나타나는 것을 파악할 수 있습니다.

바로 그 함수가 main() 함수입니다.


<Fig. 7>

즉 <Fig. 7> 의 401145 주소에 있는 CALL 명령어가 호출하는 주소 401000 로 가보면 [F7]
그곳이 바로 우리가 찾는 main() 함수 코드 영역입니다.


<Fig. 8>

"Hello World!" 문자열과 MessageBoxW() 함수 호출 코드가 보이시죠?
정확히 찾아왔습니다.

* VC++ 2008 Express Edition 을 사용하면 기본 문자열은 UNICODE 가 되고,
   문자열 처리 API 함수들도 전부 W(ide) character 계열의 함수로 변경됩니다.




2) 문자열 검색 방법

All referenced text strings : 마우스 우측 메뉴 -> Search for -> All referenced text strings

C 언어를 처음 배울때 문자열은 코드와 다른 영역에 저장된다라고 배웠습니다.
즉, 어딘가에 "Hello World!" 문자열이 저장되어 있을꺼란 얘기입니다.

프로그램내의 문자열을 확인할 수 있는 여러가지 방법이 있습니다만 여기서는 OllyDbg 기능을 설명드리겠습니다.

OllyDbg 가 디버깅할 프로그램을 로딩할 때 나름대로 분석과정을 거치게 되는데요,
코드를 좍~ 훑어서 참조되는 문자열호출되는 API 들을 뽑아내서 따로 목록으로 정리를 해놓습니다.

'All referenced text strings' 명령을 사용하면 아래와 같은 윈도우가 뜨면서 코드에서 참조되는 문자열들을 보여줍니다.


<Fig. 9>

OllyDbg 는 "401007 주소의 PUSH 004092A4 명령이 있는데, 이 명령에서 참조되는 4092A4 주소에는 'Hello World!' 문자열이 존재합니다." 라고 말하고 있는 것이죠.

문자열을 더블 클릭하면 main() 함수의 MessageBoxW() 호출 코드로 갈 수 있습니다.

참고로 메모리상에 있는 문자열의 확인을 위하여 OllyDbg 덤프 윈도우에서 Go to[Ctrl+G] 명령을 써보겠습니다.
(포커스를 덤프 윈도우에 놓고 단축키 명령 [Ctrl+G] 을 내려주세요.)


<Fig. 10>

"Hello World!\n" 문자열과 그 뒤의 NULL 들이 보이시죠?
(VC++ 2008 에서는 static 문자열을 UNICODE 로 저장한다고 아까 설명하였습니다.)
 
"Hello World!" 문자열 대신 "Reversing!" 문자열을 쓸 수 있는 공간이 충분히 존재하는군요.
(우리의 목표를 기억하시죠? 문자열을 패치시킬 것입니다.)

또 한가지 중요한 내용은 4092A4 라는 주소입니다.
지금까지 본 코드의 주소 401XXX 와는 다른 영역입니다.
HelloWorld.exe 프로세스에서 409XXX 주소는 프로그램에서 사용되는 데이타가 저장되는 영역입니다.

코드와 데이타가 파일에서 어떻게 저장되고 메모리에 어떻게 올라가는지
원리를 자세히 배우려면 PE header 를 공부해야 합니다.
(PE header 는 처음에 설명할 내용이 너무 많아서 나중에 따로 정리하여 올리도록 하겠습니다.)



3) API 검색 방법 (1) - 호출 코드에 BP

All intermodular calls : 마우스 우측 메뉴 -> Search for -> All intermodular calls

Windows 프로그래밍에서 모니터 화면(hardware)에 뭔가를 출력하려면
어쩔 수 없이 Win32 API 를 사용하여 OS 에게 화면출력을 요청해야 합니다.

즉, 프로그램이 화면에 뭔가를 출력했다는 얘기는 프로그램 내부에서 Win32 API 를 사용하였다는 뜻입니다.

그렇다면 프로그램의 기능을 보고 사용되었을법한 Win32 API 호출을 예상하고,
그 부분을 찾을 수 있다면 디버깅이 매우 간편해 질 것입니다.

OllyDbg 에는 디버깅 시작전에 미리 코드를 분석하여 사용되는 API 함수 목록을 뽑아내는 기능이 있습니다.

코드에서 사용된 API 호출 목록만 보고 싶을때는 'All intermodular calls' 명령을 사용하면 됩니다.
아래와 같이 프로그램에서 사용되는 API 함수 호출 목록이 나타납니다.
(OllyDbg 옵션에 따라서 표시되는 모양이 약간 틀려질 수 있습니다.)


<Fig. 11>

<Fig. 11> 에 MessageBoxW 호출 코드가 보이시죠?
역시 더블클릭으로 해당 주소(40100E) 로 갈 수 있습니다.

이런 식으로 코드에서 사용된 API 를 예상할 수 있을때 이 방법을 사용하면 쉽게 원하는 부분을 찾아낼 수 있습니다.

* OllyDbg 가 어떻게 호출되는 API의 이름을 정확히 뽑아올 수 있을까요?
  소스코드를 보고 있는것도 아닌데요.
  이 원리를 이해하기 위해서는 역시 PE header 의 IAT(Import Address Table) 구조를 이해해야 합니다.
  (나중에 따로 설명 하겠습니다.)



4) API 검색 방법 (2) - API 코드에 직접 BP

Name in all modules : 마우스 우측 메뉴 -> Search for -> Name in all modules

모든 실행 파일에 대해서 OllyDbg 가 API 함수 호출 목록을 추출할 수 있는것은 아닙니다.
Packer/Protector 를 사용하여 실행파일을 압축 또는 보호해 버리면,
IAT 구조가 변경되거나 OllyDbg 에서 보이지 않게 됩니다. (심지어는 디버깅 자체가 매우 어려워 집니다.)
* Packer(Run Time Packer)
  실행압축 유틸리티. 실행파일의 코드, 데이타, 리소스 등을 압축시켜 버립니다.
  일반 압축 파일과 다른 점은 실행 압축된 파일 그 자체도 실행파일 이라는 것입니다.
  (나중에 대표적인 packer 를 분석해 보도록 하겠습니다.)

* Protector 
  실행압축 기능외에 파일과 그 프로세스를 보호하려는 목적으로
  anti-debugging, anti-emulating, anti-dump 등의 기능을 추가한 유틸리티 입니다.
  Protector 를 상세 분석하려면 높은 분석 지식이 요구됩니다.
  (굉장히 고급 주제이고 너무 재밌는 내용입니다. 나중에 상세히 분석 해보겠습니다.)


이런 경우에는 프로세스 메모리에 로딩된 DLL 코드에 직접 BP 를 걸어 보는 겁니다.

API 라는 것은 OS 에서 제공한 함수이고, 실제로 API 코드는 %system32% 폴더에 *.dll 파일 내부에 구현되어 있습니다.
(kernel32.dll, user32.dll, gdi32.dll, advapi32.dll, ws2_32.dll 등입니다.)

간단히 말해서 우리가 만든 프로그램이 어떤 의미 있는 일(각종 I/O)을 하려면
반드시 OS 에서 제공된 API 를 사용해서 OS 에게 요청해야 하고,
그 API 가 실제 구현된 시스템 DLL 파일들은 우리 프로그램의 프로세스 메모리에 로딩(정확히는 매핑)되어야 합니다.

OllyDbg 에서 확인해 볼까요. View – Memory 메뉴를 선택해 주세요. (단축키 [Alt+M])


<Fig. 12>

<Fig. 12> 는 HelloWorld.exe 프로세스 메모리의 일부분을 보여주고 있습니다.
빨간색으로 표시된 부분이 바로 시스템 DLL 들이 로딩된 메모리 영역입니다.

* 참고로 MessageBoxW() API 는 USER32.DLL 에 속해 있습니다.

OllyDbg 의 또 다른 기본 해석 기능은 프로세스 실행을 위해서
같이 로딩된 시스템 DLL 파일이 제공하는 모든 API 목록을 보여주는 것입니다.

'Name in all modules' 명령을 사용해 보겠습니다.
나타나는 윈도우에서 'Name' 정렬시키고, MessageBoxW 를 타이핑 하면 자동 검색됩니다.


<Fig. 13>

USER32 모듈에서 Export type 의 MessageBoxW 함수를 선택하세요.
(시스템 환경에 따라 버전이 틀려질 수 있습니다.)

더블 클릭 하시면 아래와 같이 USER32.dll 에 구현된 실제 MessageBoxW 함수가 나타납니다.


<Fig. 14>

주소를 보시면 HelloWorld.exe 에서 사용되는 주소와 확연히 틀리다는걸 아실 수 있습니다.

이곳에 BP 를 설치[F2]하고 실행[F9]해 보겠습니다.

만약 HelloWorld.exe 프로그램에서 MessageBoxW 함수를 호출한다면 결국 이곳에서 실행이 멈추게 될 것입니다.
(간단한 원리 입니다.)


<Fig. 15>


예상대로 MessageBoxW 코드 시작에 설치한 BP 에서 실행이 멈췄습니다.

레지스터(Register) 윈도우의 ESP 값이 12FF68 인데, 이것은 프로세스 스택(Stack)의 주소입니다.

스택 윈도우에서 빨간색으로 표시된 부분을 아래에 자세히 표시했습니다.

Stack
address     Value       Comment
-----------------------------------------------------------------------
0012FF68    00401014    CALL to MessageBoxW from HelloWor.0040100E
                        => MessageBoxW 는 40100E주소에서 호출되었으며,
                                             함수 실행이 종료되면 복귀주소는 401014 이다.

0012FF6C    00000000    hOwner = NULL
0012FF70    004092A4    Text = "Hello World!"
0012FF74    0040927C    Title = "www.reversecore.com"
0012FF78    00000000    Style = MB_OK|MB_APPLMODAL


* 함수 호출과 스택의 동작 원리등은 나중에 "Stack Frame" 설명할 때 더 자세히 보도록 하겠습니다.

ESP 의 값 12FF68 에 있는 복귀 주소 401014 는
HelloWorld.exe 의 main 함수내의 MessageBoxW 함수 호출 바로 다음의 코드입니다.

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

바로 위에 MessageBoxW  함수 호출 코드가 있는 것을 확인할 수 있습니다. (<Fig. 8> 참고)

(continue)

반응형
반응형

HelloWorld.exex

HelloWorld.cpp




Level

초급



Content

"Hello World!" 프로그램을 디버깅 해보고 간단한 패치를 해보도록 하겠습니다.
이를 통하여 디버깅에 대한 감을 잡으실 수 있습니다.



Goal

- 기본적인 디버거 사용방법의 이해
- 간단한 Disassembly code 이해
- 간단한 프로그램 패치(patch)



Tool

Visual C++ 2008 Express Edition
OllyDbg 1.10



Hello World!

모든 C 프로그래머가 최초로 만들어 본 프로그램 Hello World! 를 최초의 디버깅 프로그램으로 결정하였습니다. SW 업계에서의 차지하는 Hello World! 의 의미, 처음 C 를 배울때의 두근거림 그리고 소스 코드의 간결함까지... 이 모든 것이 최초의 디버깅 프로그램으로써 더 할 나위 없이 딱 들어맞는군요.

자신에게 익숙한 C/C++ 개발툴을 이용하여 Hello World! 를 만들어 봅니다.
(Release 모드로 빌드하면 코드가 좀 더 간결해져서 디버깅하기 편합니다.)


<Fig. 1>




디버깅 목표


위에서 만든 HelloWorld.exe 를 실행해보면 당.연.히. "Hello World!" 메시지 박스가 출력될 것입니다. 그냥 디버깅만 하면 재미없으니까 이 문자열을 "Hello Reversing!" 으로 바꾸는걸 목표로 하겠습니다.

그러기 위해서는 먼저 HelloWorld.exe 를 디버깅하여 main() 함수내의 MessageBox() 함수 호출 코드를 찾아야 합니다.

그리고 적절히 해당 문자열 위치를 알아내어 변경시키면 되겠지요.



디버깅 시작

첨부된 HelloWorld.exe 파일을 OllyDbg.exe 로 열어보겠습니다.

* VC++ 도  소스가 있을때 어셈블리 수준의 디버깅이 가능합니다만, 일반적으로는 분석할때 소스가 없으므로 OllyDbg 같은 Win32 전문 디버거를 사용하게 됩니다.


<Fig. 2>


디버깅을 시작하기 전에 간단히
<Fig. 2> 에 보이는 OllyDbg 의 메인 화면 구성에 대해 설명드리겠습니다.

- code :
기본적으로 disassembly code 를 표시하고 각종 comment, label 을 보여주며 코드를 분석하여 loop, jump 위치 등의 정보를 표시한다.
- register : CPU register 값을 실시간으로 표시하며 특정 register 들은 수정도 가능함.
- dump : 프로세스내의 원하는 memory 주소 위치를 hex ASCII 값으로 표시하고 수정도 가능함.
- stack : ESP register 가 가리키는 프로세스 stack memory 를 실시간으로 표시하고 수정도 가능함.

디버거가 멈춘 곳은
EntryPoint(EP) 코드로써 HelloWorld.exe 의 실행 시작 위치(4011A1)입니다. 일단 EP 코드에서 눈에 띄는건 CALL 명령과 그 밑의 JMP 명령입니다.

Address     OP code        Disassembly       comment
----------------------------------------------------------------------------
004011A1    EB A6160000    CALL 0040284C     ; 0040284C (40284C 주소의 함수를 호출
)
004011A6    E9 A4FEFFFF    JMP 0040104F      ; 0040104F (40104F 주소로 점프)

- Address : 프로세스의 가상메모리(Virtual Address:VA) 내의 주소 위치
- OP code : OPeration code 의 줄임말로써 IA32(또는 x86) CPU 명령어
- Disassembly : OP code 를 보기쉽게 디스어셈 해준 코드
- comment : 디버거에서 추가한 주석 (옵션에 따라 약간씩 다르게 보임)

디스어셈 코드를 처음 보신 분들이라도 위 두줄의 코드는 그 의미가 명확합니다.

"40284C 주소의 함수를 호출(CALL)한 후 40104F 주소로 점프(JMP) 하라"

계속 디버깅을 진행해 보겠습니다.
목표는 우리가 작성한 main() 함수내의 MessageBox() 함수 호출을 확인하는 것입니다.



40284C
함수 따라가기

- Step Into [F7] :
하나의 OP code 실행 (CALL 명령을 만나면, 그 함수 코드 내부로 따라 들어감.)
- Step Over [F8] : 하나의 OP code 실행 (CALL 명령을 만나면, 따라 들어가지 않고 그냥 함수자체를 실행함.)
- Execute till Return [Ctrl+F9] :
함수 코드 내에서 RETN 명령어 까지 실행 (함수 탈출 목적)

F7
단축키로 함수 안으로 따라갈 수 있습니다.


<Fig. 3>


위 코드를 얼핏 보아도
Hello World! 에서는 사용된 적 없는 API 들이 호출되고 있습니다.
이곳은 분명 우리가 찾는 main() 함수가 아니겠군요.
이곳은 VC++ 에서 프로그램 실행을 위해서 추가시킨 (우리 소스코드에는 없지만) VC++ stub code 입니다. (각 컴파일러 종류/버전별로 stub code 는 틀려집니다.)
지금은 신경쓰지 말고 우리의 목표 main() 을 찾아 계속 진행해 보겠습니다.

*
주의사항 : 처음에는 Win32 API 함수들(OllyDbg comment 상에서 빨간색 API 함수 호출 부분)은 따라가지 마세요.  너무 헤멜 수 있습니다. Step over[F8] 로 넘어가세요.

4028E1
주소에 RETN 명령어가 있습니다.
(RETN
은 함수의 끝을 나타내며 함수가 호출된 명령어 바로 다음 명령어로 되돌아 갑니다.)

그곳까지 Step over [F8] 하시거나 또는 Execute till Return [Ctrl+F9]로 한방에 가봅니다.

그리고
RETN 명령어를 실행하면[F7/F8] <Fig. 2> 에서 봤던 4011A6 주소로 오게됩니다.
(C
언어에서 함수를 호출하고 리턴하면 그 다음 명령어로 오는 것을 생각하시면 됩니다.)



40104F 따라가기

4011A6
주소의 JMP 0040104F 명령을 실행해서 40104F 로 갑니다.


 <Fig. 4>


<Fig. 3> 보다 좀 더 복잡해 보이는 VC++ stub code 가 나타났습니다
실력 향상을 원하시는 분들은 이 코드에서 Step In/Over 를 사용해서 마구 헤매셔야(?) 합니다
함수 호출을 너무 깊게 따라가서 너무 힘든 상황이라고 생각되시면 아래의 ‘디버거 좀 더 능숙하게 다루기’ 내용을 참고하셔서 다시 디버깅 하시면 됩니다.

* 헤매야 하는 이유
여러분이 초보자이기 때문입니다. ^^ 각 컴파일러/버전별로 stub code 를 눈에 익혀 놓으시면실전에서는 stub code 처럼 보이는 부분은 빠르게 뛰어 넘을 수 있습니다
마치 C언어 처음 배울때 컴파일 에러를 많이 내보고, 에러 메시지를 눈에 익히는 것과 같다고 할 수 있습니다실전에서 같은 에러 메시지가 발생했을때 능숙하게 해결하기 위함이지요.



디버거 좀 더 능숙하게 다루기

- Restart [Ctrl+F2] : 다시 처음부터 디버깅 시작. (디버깅 당하는 프로세스를 종료하고 재실행 시킴.)
- Go to [Ctrl+G] : 원하는 주소를 찾아감. (코드를 확인할 때 사용. 실행되는 것은 아님.)
- Execute till Cursor [F4] : cursor 위치까지 실행함 (디버깅 하고 싶은 주소까지 바로 갈 수 있음.)
- Comment [;] : Comment 추가
- User Defined Comments : 마우스 우측 메뉴 -> Search for -> User defined Comment
- Set/Reset BreakPoint [F2] : BP 설정/해제
- Run [F9] : 실행 (BP 가 걸려있으면 그곳에서 실행이 정지됨.)

디버깅을 재실행[Ctrl+F2] 하시고 [Ctrl+G] 단축키로 40104F 주소로 갑니다
40104F 주소에 커서가 놓여져 있을텐데요, [F4] 단축키로 바로 날라갑니다
이곳(40104F) 베이스 캠프라고 부르겠습니다

베이스 캠프로 가는 또 다른 방법은 BP(Break Point) 를 설정[F2] 하고 실행[F9] 하는 것입니다디버거는 현재 실행위치서부터 프로세스를 실행하다가 BP 가 걸린 곳에서 멈추게 됩니다. (BP 없으면 그대로 계속 실행)

그럼 이번에는 [;] 단축키로 주석을 달아 볼까요?


<Fig. 5>


프로그래밍에서와 마찬가지로 디버깅에서 주석은 매우 중요한데요, 커서 위치를 잠시 다른 곳에 두고 'User Defined Comments' 메뉴를 선택하면 아래와 같이 사용자가 입력한 주석들이 표시됩니다. 


<Fig. 6>


빨간 글씨로 표시된 부분이 커서 위치입니다. 
주석 위치와 겹쳐지면 빨간 글씨만 나타납니다. 
(그래서 커서위치를 잠시 다른 곳에 두시라고 한겁니다.)

해당 주석을 더블 클릭하면 그 주소로 갈 수 있습니다
(OllyDbg 를 종료하더라도 주석은 *.udd 파일에 보관되기 때문에 다음에 다시 볼 수 있습니다.)

이어지는 강좌에서 '원하는 코드를 빨리 찾는 방법' 을 가르쳐 드릴텐데요
나중에라도 베이스 캠프에서부터 API 호출을 제외한 모든 함수 호출을 일일이 따라가[F7] 보시는걸 권장합니다

(continue)

반응형

+ Recent posts