zesrever의 지식펌프

들어가면서
제스리버입니다. 제가 강의를 좀 많이 하는 편인데요, PE 포맷을 가르칠 일이 있어서 어떻게 가르칠까 고민하다가  레고 생각이 번뜩 떠오르더군요. 그래서 code만 가진 상태에서 헤더를 만들어 가져다 붙이고 섹션 테이블을 만들어 붙이고 필요한 섹션도 붙이고 하는 식으로 실험을 해보았습니다. 실제 소스 코드를 가지고 설명하는 것에 비해 노가다성은 짙은 반면, PE 포맷에만 집중할 수 있어서 프로그램이 약간 약하신 분들도 그리 어렵지 않게 PE 포맷에 대해서 이해하실 수 있을 것 같습니다. 그래서 "조립하면서 배우는 PE"라는  제목의 연재물을 통해 지식을 나눠보고자 합니다. PE 포맷을 공부하시다가 중도에 포기하신 경험이 있으신 분들, 이제 막 리버싱에 대해 공부를 시작하시는 분들에게 도움이 되었으면 하는 바램입니다.

실행 파일 포맷을 왜 배워야 하는가?
리버스 엔지니어링의 관점에서 말씀을 드리자면, 다음과 같은 4가지 이유때문에 그렇습니다.
- 매뉴얼 언패킹 시 IAT를 리빌딩 하려면 실행 파일에 대한 지식이 필요합니다.
  물론 ImpRec등 자동으로 리빌딩을 해주는 툴이 있기는 하지만, 자동화된 툴은 언제나
  문제점을 가지고 있습니다. 사람이 할 수 있는 일들의 대부분은 빠르게 처리하겠지만
  모든 것을 처리해 주는 것은 아니죠. 늘 강조하는 이야기입니다만,실력을 쌓고 싶다면
  수작업이 귀찮아 질 때 또는 최소한 원리라도 이해하고 툴을 사용해야 합니다. 처음부터
  원리도 모른채 툴만 사용하는 것은  "나 바보 만들어 주세요"랑 다를 바 없다고 생각합니다.
  ^^;

- 안티 리버싱 테크닉을 이해하고 우회하기 위해서 필요합니다.
  안티 리버싱 테크닉 중에는 TLS callback 과 같이 PE 파일 포맷과 관련된 단순하면서도
  효과적인 방법들이 더러 존재합니다. 이러한 안티 리버싱을 기법을 습득하는데 실행
  파일 포맷에 대한 전반적인 지식이 필요한 것은 아닙니다. 하지만 PE에 대해서 익숙하면
  어렵지 않게 이해할 수 있겠죠.

- 코드 패치를 하기위해서는 실행 파일에 대한 지식이 필요합니다.
  리버싱을 하다보면 가끔 기존의 실행 파일에 코드를 추가하거나 하는 경우가 있는데
  이런 경우에도 마찬가지로 PE 포맷에 대한 지식이 필요합니다.

- 링커나 컴파일러를 제대로 이해하고 사용하기 위해서는 파일 포맷에 대한 지식이
  필요합니다.
  링커나 컴파일러가 제공하는 상당수의 옵션은 실행 파일과 밀접한 연관을 가지고 있습니다.
  초보 프로그래머들은 대부분 컴파일러나 링커를 효과적으로 사용하지 못하는데,
  바로 그 이유가 실행 파일 포맷을 제대로 이해하고 있지 못하기 때문입니다.

이러 이러한 이유로 실행 파일 포맷을 공부해야 합니다. 사실 주변의 많은 분들이 실행 파일 포맷에 대해 어려워하고 겁을 많이 먹는데, 사실 내용이 많다 뿐이지 어렵거나 복잡한 것은 아닙니다. 더구나 처음 공부할 때는 PE 파일 포맷에 대해서 완벽하게 알 필요도 없구요. 아뭏든 이번 기회에 같이 공부해보도록 하죠. ^^;

어떻게 공부해야 하는가?
외국의 많은 해커들은 그 유명한 Matt Pietrek의 문서를 많이 언급합니다. PE에 대한 최초(?)의 문서이었던 데다가 워낙 유명하신 분이 쓰신 글이기 때문이죠. 물론 내용도 좋습니다. 하지만 사실 Matt Pietrek님이 쓰신 문서만으로 공부하기에는 많이 시간이 걸리는 것이 사실입니다. 한국은 실정이 좀 다릅니다. 영문으로 번역해도 공전의 히트를 칠 만한 아주 좋은 책이 있기 때문입니다. 앞으로 이 글을 써나가면서도 자주 참조 할 것 같습니다. 국내에서 출간된 기술서 중 드물게보는 명서 중 하나로 이호동님께서 저술하신 "Windows 시스템 실행파일의 구조와 원리"라는 책이 있습니다. 국내에 이런 책이 있다는 것은 축복입니다. 깊은 지식을 원하는 분들께 강력 추천합니다.

"Do It Yourself" 정신은 리버서에게 아주 중요하다고 생각합니다. 위에서 언급한 책은 시간을 많이 단축하는데 도움이 되겠지만 앉아서 책만 읽는다면 사실 완전히 자기의 지식으로 만들기에는 뭔가 부족함이 느껴질 겁니다. PE 파일 포맷을 연구하는데 가장 좋은 방법은 "실행 파일 분석기"를 직접 제작하는 것이라는 의견에 대해 저 역시 전적으로 공감합니다. 허나... 불행하게도 프로그래밍에 어려움을 느끼는 분들이 많은 것 같습니다. 프로그래밍은 언젠가는 넘어야 할 산이라 도전해 보는 것이 바람직하겠지만 PE 파일 포맷에 대해 궁금해 죽겠는데, 예제 코드를 이해하기에는 좀 어렵고 그렇다고 프로그래밍 공부를 처음부터 다시하자니 시간은 없고 하시는 분들에게는 참 답답할 일이죠. 이럴때는 그냥 부딪혀 보는게 최선입니다. 뭐 손해 볼 것 있습니까? 분석하다가 실패한다고 해서 누가 뭐라하겠습니까? 분석하는 과정을 즐기면 결과로 얻어지는 지식은 하나의 작은 선물에 지나지 않습니다. 여러분들도 그러한 쾌감을 못 잊어서 계속 공부하시는 것이 아니신지요?  예전에 라디오 하나쯤은 부서보셨을 것 같은데, 그 경험을 살려 실행 파일을 분해한다음 하나씩 조립하는 방법으로 공부해보죠. 본 연재물은 앞서 언급한 대로 그렇게 구성되어 있습니다. 다소간 프로그래밍 실력이 부족하더라도 PE 포맷을 이해하시는데는 큰 어려움이 없을 거라 생각합니다. (부족한 프로그래밍 실력은 시간을 두고 계속 만회하셔야 합니다. 이런 식의 방법에도 한계라는 것은 존재하니까요...뭐 별거 있습니까? 그냥 한번 해보는 거죠.)

준비물
일단 가장 큰 무기는 Hex 에디터입니다. PE를 공부하는데 있어 라디오 부수고 조립할 때 있어 드라이버 같은 역할을 해 줄 녀석입니다. 저는 WinHex를 사용합니다. 가급적 WinHex를 사용해 보시길 권장해 드립니다. UltraEditor같은 녀석들과 죽마고우시라면 그것도 괜찮습니다. 드라이버야 자기 손에 맞으면 그 뿐이죠.

간단한 PE파일 분석기가 필요합니다. 다들 비슷비슷해서 특별히 권장할 만한 것은 없습니다. 쓰시던 것 있으시면 그걸로 하시고 아니면 PE explorer나 LordPE, Stud PE 같은 툴 사용하시면 됩니다.

그 다음으로는 큰 노트와 필기구가 필요하겠군요. 그림 그리기 편하게 큰 노트를 구입하시는 것이 좋겠습니다. 아니면 집에 굴러다니는 쓰다 남은 노트라도...


그럼 시작합니다.
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

      [그림 1] 이벤트로그 헤더의 모양1


[그림 2]를 보면서 중요한 몇 몇 필드를 좀 더 살펴보도록 하겠습니다.

오프셋 16~31까지의 16bytes는 이벤트 로그 리페어에 있어 핵심적인 부분입니다. 각각 4bytes의 크기를 가지는 4개의 필드는 아래 그림에서 볼 수 있는 것처럼 "가장 오래된 이벤트 로그의 오프셋","다음 생성할 이벤트 로그의 오프셋","다음 생성할 이벤트 로그의 아이디", "가장 오랜된 이벤트 로그의 아이디"를 의미합니다. [그림 2]에 나타나 있는 데이터에 적용시켜 보면 가장 오래된 즉 가장 먼저 생성된 이벤트 로그의 오프셋은 헤더 바로 뒤에 존재하며(오프셋이 48byte), 새롭게 생성할 이벤트 로그의 오프셋 역시 헤더 바로 뒤에 존재함을 알 수 있습니다. 다시 말해 생성된 로그가 없다는 거죠. 예에서는 새롭게 생성될 이벤트 로그가 바로 최초로 생성되는 로그이며 로그 ID는 1이라는 것도 알 수 있습니다. 

AppEvent.Evt

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

FSC2007 문제 풀이 두번째 글입니다. 첫번째 글은 여기를 참고해 주세요.

(딴지방지 : 빠르게 문제를 풀어야 한다는 목적에 충실한 더 좋은 솔루션이 있음을 저도
 압니다. 이 글은 그냥 많이 배워보자는 목적에서 작성되었습니다. ^^)
 
준비된 파일을 IDA로 열어 엔트리 포인트 부분을 살펴보았습니다. 군데군데 가비지 코드와 코드 퍼뮤테이션 같은 것들이 보입니다.

CODE:00401352 start           proc near
CODE:00401352
CODE:00401352 var_4           = dword ptr -4
CODE:00401352
CODE:00401352 ; FUNCTION CHUNK AT CODE:00401000 SIZE 0000000F BYTES
CODE:00401352
CODE:00401352     xor     ebx, ebx           ;디버거가 탐지된 경우 실행되지 않는
                                             ;부분. 매우 중요한 코드 인듯.
                                             ;일단 스킵
CODE:00401354     push    offset loc_40135A  ;코드 퍼뮤테이션 기법
CODE:00401359     retn                       ;push xxxx/retn => jmp xxxx
CODE:0040135A
CODE:0040135A loc_40135A:                    ; DATA XREF: start+2o

CODE:0040135A     push    eax                ;eax값을 스택에 push
CODE:0040135B     xor     eax, 427108h       ;귀여운 가비지 코드 ^^;
CODE:00401360     sbb     eax, edx           ;귀여운 가비지 코드 ^^;
CODE:00401362     xchg    eax, [esp+0]       ;결국 eax은 원래대로 복원됨
                                             ;따라서 위의 두 명령은 가비지

CODE:00401365     pop     ds:dword_402064    ;너는 뭐냐? 가비지냐?
                                             ;402064번지를 직접 가서 이 번지를
                                             ;참조하는 코드를 보면 여기 말고는
                                             ;없습니다. 일단 가비지인것 같군요.

CODE:0040136B     push    offset loc_401000  ;jmp loc_401000
CODE:00401370     retn
CODE:00401370 start           endp ; sp = -8

결국 엔트리 포인트에서 하는 일은 EBX의 값을 0으로 설정하고 loc_401000으로 점프하는 것입니다.
그럼 401000 번지를 향해 고고.

음 재미있는 코드입니다. 결국 JMP loc_40116D랑 같군요.
CODE:00401000 loc_401000:                       ; CODE XREF: start+1Ej
CODE:00401000                                   ; DATA XREF: start+19o
CODE:00401000     push    esp                   ;단순히 스택내 공간 확보가 목적
CODE:00401001     mov     [esp+4+var_4], eax    ;eax 값을 위에서 마련한 스택
                                                ;내 공간에 백업
CODE:00401004     mov     eax, offset loc_40116D
CODE:00401009     xchg    eax, [esp+4+var_4]    ;스택의 top 위치에 40116D저장
CODE:0040100C     retn    0                     ;결국 40116D로 점프


슬슬 귀찮아지기 시작하는 지점입니다. 어쨌든 40116D로 가보겠습니다.

CODE:0040116D loc_40116D:              ; DATA XREF: start-34Eo
CODE:0040116D     push    esp         
CODE:0040116E     mov     [esp], eax
CODE:00401171     mov     eax, offset sub_401186
CODE:00401176     xchg    eax, [esp]    ;스택의 top에 0x401186 저장
                                        ;뒤에 나오는 GetCommandLineA
                                        ;호출 후 복귀 주소입니다.
CODE:00401179     push    esp           
CODE:0040117A     mov     [esp], eax  
CODE:0040117D     mov     eax, offset loc_40137D
CODE:00401182     xchg    eax, [esp]    ;스택에 top에 loc_401037D 저장
CODE:00401185     retn                  ;결국 0x401037D로 점프.. 아띠..장난하나.

ㅠ.ㅠ;; 401037D로 가봅니다.
CODE:0040137D loc_40137D:          ; DATA XREF: CODE:0040117Do
CODE:0040137D     jmp     ds:GetCommandLineA

눈이 반짝반짝~ 뭔가 의미있는 코드인것 같습니다. GetCommandLineA가 호출됩니다. 이 프로그램호출 시 커맨드 라인을 줘야 하나 봅니다. GetCommandLineA를 이용하여 아규먼트를 읽은 다음에는 401186번지로 복귀합니다. 스택의 모양을 잘 그려보세요.  어쨌든 알아둘만한 패턴입니다.(PUSH return주소/JMP 함수시작주소 = CALL 함수 요넘의 변형입니다.)  

GetCommandLineA 호출 후 리턴주소인 0x401186번지로 이동해 보겠습니다. 하하.. 복잡해보이는군요. 이제는 디버거의 도움을 받아야 겠습니다. Ollydbg로 프로그램을 오픈한 후 401186번지에 브레이크 포인트를 설정하고서 실행시킨 다음 한 스텝씩 진행시켜 가며 코드를 분석했습니다. 먼저 00401187번지에서 EDX에 커맨드라인 아규먼트의 시작 주소를 복사해 넣는 것을 확인할 수 있군요. [그림 1]참고.
 

FSC2007_Level2.zip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이올린에 북마크하기

FSC2007 Level 2문제 풀이 첫번재 글 입니다. 풀이 내용이 길어서 2개의 글로 나누어 설명하겠습니다. 문제 파일은 두번째 글에 첨부되어 있습니다.

문제 : Level1과 마찬가지로 이메일 주소를 알아내야 합니다.

먼저 프로그램을 실행시켜 보겠습니다.

                   [그림 1] FSC_Level2.exe 실행 결과

TLS callback 분석
[그림 1]처럼 메시지박스 하나 뜨고는 아무런 이야기도 없군요. -.-;;  음... Level 1보다는 더 문제답게 보입니다. 먼저 PE 헤더 정보를 확인해 보겠습니다. 저는 stud_pe를 이용하였습니다. 뭐 아무거나 상관없습니다. PE 헤더를 살펴보다보니 TLS 섹션이 존재하는 군요. 이러한 경우 TLS callback 함수를 사용하는지 확인해봐야 합니다. TLS callback에 대해서는 여기를 참고하세요.

UPX1:004063BB loc_4063BB:           ; CODE XREF: start+DDj
UPX1:004063BB               popa
UPX1:004063BC
UPX1:004063BC loc_4063BC:           ; DATA XREF: TlsCallback_0+1Ew
UPX1:004063BC               jmp     near ptr word_40135A
UPX1:004063BC start         endp

대충 감이 잡히는 군요. UPX의 경우 별다른 조작을 가하지 않았다면 UPX1이라는 이름의 섹션에 마지막에 존재하는 jmp 명령어로 점프하는 곳이 OEP 입니다. 게다가 위에 POPA 까지보이니 40135A가 OEP라는 것이 거의 맞는 것 같습니다. 하지만 이건 어디까지나 추측일 뿐이고, 실제로 004063BC에 위치한 jmp문이 실행되지 않는다면 이 역시 트릭이겠죠. 디버깅을 통해서 확인해 보겠습니다. 만사불여튼튼... ^^; 매 단계마다 검증 과정을 빼놓는다면 트릭에 빠질 확률이 높습니다.  검증을 위해 004063BC에 브레이크 포인트를 설정한 후 실행시켜 보았습니다. 

       [그림 5]004063BC번지에 브레이크 포인트 설정


두세번 F9(Run)를 누르면 004063BC 번지에 설정한 브레이크 포인트가 히트됨을 알 수 있습니다. 트릭은 아니군요. ^^;

         [그림 6] 004063BC에서 브레이크 포인트 히트

여기까지 정리해보겠습니다. 

* FSC_Level2.exe는 UPX로 패킹한 후 TLS 섹션이 추가되었으며 TLS callback 함수가 존재한다.
* TLS callback 함수는 디버거의 존재 여부에 따라 엔트리 포인트 값을 변경하는 기능을 가지고 있다.
* 디버거가 존재하지 않는 경우의 엔트리 포인트는 00401352번지이다.

UPX로 언패킹 후 엔트리 포인트 수정
음.. 대충 해결 방법이 보이는 군요. 그냥 UPX로 언패킹한 후 엔트리 포인트를 00401352 번지로 변경하면 되겠습니다. 

         [그림 7]UPX를 이용하여 FSC_Level2.exe를 언패킹


Stud_PE를 이용하여 언패킹된 파일을 오픈한 후 엔트리포인트를 0000135A에서 00001352로 번경하였습니다.

                     

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이올린에 북마크하기

어제 동호회 사람들과 워크샵을 다녀온 뒤라 좀 피곤합니다. 간만에 술을 뽀지게 마셔서.. 뒹글뒹글 하던 차에 좀 뒤 늦은 감이 있지만 아는 분이 시간 때우기(?) 좋다고해서 해봤습니다. F-Secure Challenge 공식 사이트에 공개되어 있습니다. 리버싱을 처음 공부하시는 분들은 솔루션 보고 따라해보시는 것도 공부에 도움이 될 듯 싶습니다.

덧붙임 :  이런 챌린지들에 대한 솔루션은 매우 다양합니다. 이 글에서 언급하고 있는 방법보다 더 좋은 방법들이 있을 수도 있겠습니다. Level1의 경우 사실 문제 푸는데는 초보자라 하더라도 1~2분 정도면 충분할 정도로 쉽습니다. 하지만 문제 푸는 것 자체보다는 과정을 이해하시는 것이 더 좋을 것 같아 좀 풀어서 설명합니다. 어차피 시간 지난 문제인데 빨리 풀어내는 방법에 초점을 맞출 필요는 없을 것 같아서요.

Level 1:  제공되는 바이너리에 이메일 주소가 숨겨져 있습니다. 이 이메일 주소를 찾아서 이메일을 보내면 다음 레벨로 가기 위한 방법을 메일로 보내줬답니다.. ^^; 물론 대회는 이미 종료된 관계로 실제 메일을 보내도 응답 메일이 올리는 만무하죠. 이메일만 찾아보면 되겠습니다.


문제로 출제된 프로그램을 실행시켜 보니 아래와 같이 Key를 입력하라고 나옵니다.

              [그림 9] JNZ를 JZ로 변경

[그림 10]은 코드 패치 후 실행 시킨 결과입니다. 역시 동일한 메시지가 출력되는 군요.

FSC2007_Level1.zip

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이올린에 북마크하기

개요
Junk Code(이하 정크 코드)는 Garbage Code(이하 가비지 코드)와는 약간 다른 의미로 사용됩니다. 가비지 코드는 "진짜 코드"를 감추기 위해서 삽입된 무의미한 코드를 일컫는 말로 리버서 즉 사람을 속여 리버싱을 하는 시간을 더디게 하는 것이 주 목적입니다. 반면 정크 코드는 리버싱을 속도를 더디게 할 목적으로 삽입된 코드라는 점을 같지만 디스어셈블러를 속인다는 점이 가비지 코드와 다릅니다. 이번에 다룰 내용은 바로 이 정크 코드와 가비지 코드를 이용한 안티 리버싱 기법입니다.

가비지 코드를 이용한 안티 리버싱 
정크 코드나 가비지 코드는 다분히 트릭의 성격이 강합니다. 별다른 원리라고 부를 만한게 없다는 것이죠. 예제를 보면 금방 이해갈 것이라고 생각합니다. 먼저 가비지 코드부터 살펴보겠습니다. 앞서 이야기한 대로 가비지 코드는 "진짜 코드"를 보호하기 위해 여기저기 맘대로 삽입된 무의미한 코드입니다. 아래의 예를 봐주세요.

보호할 코드 (PEB.IsBeingDebugged를 이용한 디버거 탐지)

  MOV EAX, DWORD PTR FS:[18h]
  MOV EAX,  DWORD PTR DS:[EAX+30h]
  MOVZX EAX, BYTE PTR DS:[EAX+2h]
  TEST EAX, EAX
  JNZ @DebuggerFound

보호할 코드 + 가비지 코드
  XOR EBX, EBX
  MOV EBX, FFEEFFEEh
  SHR EBX, 4
  ADD ESI, EBX
  MOV EAX, DWORD PTR FS:[18h]
  MOV ECX, 3204F83Eh
  SUB ECX, EBX
  PUSH offset @JumpHere
  ADD ECX, ESI
  LEA EDX, [ESI+ECX]
  MOV EAX,  DWORD PTR DS:[EAX+30h]
  RETN
  SHR EDX, 5
  MOV ESI, EDX
 
@JumpHere:
  MOVZX EAX, BYTE PTR DS:[EAX+2h]
  LEA  EBX, [EAX+ECX]
  XOR  ECX, ECX
  TEST EAX, EAX
  PUSH ESI
  LEA  ESI, [ESP+0Ch]
  POP  EDI
  PUSH EAX
  JNZ @DebuggerFound

^^; 숨은 그림 찾기 같지 않습니까? 진짜 코드를 아무런 의미없는 코드 사이에 숨겨놓았습니다. 가비지 코드가 그럴 듯하면 할수록 리버서는 엉뚱한 것을 분석하느라 시간을 보내게 되겠죠. 이런 코드는 분석하는 제너럴한 테크닉은 없습니다. 예제 코드의 경우라면 FS:[18h]의 값이 EAX에 저장되었다는 사실에 주목하여 EAX 위주로 코드를 찾아가다보면 어느 정도 윤곽을 잡을 수 있습니다. 어쨌든 아는 만큼 밖에 안보이는 형태라 리버서들을 괴롭히는 트릭입니다.

Junk Code를 이용한 안티 리버싱
다음 예제코드를 봐주세요.

main()
{
   __asm
  {
      jmp here+1 ;
     here:
      __emit 0xe9     ;__emit은 뒤에 오는 바이트를 그대로 코드에 포함시킬때 사용
                      ;0xe9은 jmp를 나타내는 opcode

     mov eax, 1 ;
 }
}
위 코드는 실제로 하는 일이 mov eax, 1을 수행하는 것입니다. 일단 컴파일 한 다음 디스어셈블러와