반응형


DOS Header


Microsoft 는 PE 파일 포멧을 만들때 당시에 널리 사용되던 DOS 파일에 대한 하위 호환성을 고려해서 만들었습니다.
그 결과로 PE header 의 제일 앞부분에는 기존 DOS EXE header 를 확장시킨 IMAGE_DOS_HEADER 구조체가 존재합니다.

typedef struct _IMAGE_DOS_HEADER {     
    WORD   e_magic;          // DOS signature : 4D5A ("MZ")
    WORD   e_cblp;                    
    WORD   e_cp;                      
    WORD   e_crlc;                    
    WORD   e_cparhdr;                 
    WORD   e_minalloc;                
    WORD   e_maxalloc;                
    WORD   e_ss;                      
    WORD   e_sp;                      
    WORD   e_csum;                    
    WORD   e_ip;                      
    WORD   e_cs;                      
    WORD   e_lfarlc;                  
    WORD   e_ovno;                    
    WORD   e_res[4];                  
    WORD   e_oemid;                   
    WORD   e_oeminfo;                 
    WORD   e_res2[10];                  
    LONG   e_lfanew;         // offset to NT header 
  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

* 출처 : Microsoft 의 Visual C++ 에서 제공하는 winnt.h


<IMAGE_DOS_HEADER>

IMAGE_DOS_HEADER 구조체의 크기는 40h 입니다.
이 구조체에서 꼭 알아둬야 할 중요한 멤버는 e_magic 과 e_lfanew 입니다.

  • e_magic : DOS signature (4D5A => ASCII 값 "MZ")
  • e_lfanew : NT header 의 옵셋을 표시 (가변적인 값을 가짐)

모든 PE 파일은 시작 부분(e_magic)에 DOS signature ("MZ") 가 존재하고,
e_lfanew 값이 가리키는 위치에 NT header 구조체가 존재해야 합니다.
(NT header 구조체의 이름은 IMAGE_NT_HEADERS 이며 나중에 소개됩니다.)


* 'MZ' 는 Microsoft 에서 DOS 실행파일을 설계한 Mark Zbikowski 라는 사람의 이니셜입니다.
  (출처 : http://en.wikipedia.org/wiki/Mark_Zbikowski)

notepad.exe 를 hex editor 로 열어서 IMAGE_DOS_HEADER 구조체를 확인해 보겠습니다.


과연 PE 스펙에 맞게 파일 시작 2 byte 는 4D5A 이며, e_lfanew 값은 000000E0 입니다. (E0000000 이 아닙니다.)
(참고 : Intel 계열 PC 는 자료를 역순으로 저장합니다. 이것을 Little Endian 표기법이라고 합니다.)

시험삼아 이 값들을 변경한 후 저장해서 실행해 보세요.
정상 실행되지 않을 것입니다. (PE 스펙에 따라서 더 이상 PE 파일이 아니거든요.)



DOS Stub


DOS Header 밑에는 DOS Stub 이 존재합니다.
DOS Stub 의 존재여부는 옵션이며 크기도 일정하지 않습니다. 
(DOS Stub 은 없어도 파일 실행에는 문제가 없습니다.)

DOS Stub 은 코드와 데이타의 혼합으로 이루어져 있으며, 아래 그림에 notepad.exe 의 DOS Stub 이 나타나 있습니다.


위 그림에서 붉은색으로 표시된 부분은 16 bit 어셈블리 명령어 입니다.
32 bit 윈도우즈에서는 이쪽 명령어가 실행되지 않습니다. (PE 파일로 인식하기 때문에 아예 이쪽 코드를 무시하지요.) 

DOS 환경에서 실행하거나, DOS 용 디버거 (debug.exe) 를 이용해서 실행할 수 있습니다.
(DOS EXE 파일로 인식합니다. 이들은 PE 파일 포멧을 모르니까요...)

콘솔 윈도우(cmd.exe)를 띄워서 아래와 같이 명령을 입력합니다.

C:\WINDOWS>debug notepad.exe
-u
0D1E:0000 0E        PUSH    CS
0D1E:0001 1F        POP     DS
0D1E:0002 BA0E00    MOV     DX,000E   ; DX = 0E : "This program cannot be run in DOS mode"
0D1E:0005 B409      MOV     AH,09
0D1E:0007 CD21      INT     21        ; AH = 09 : WriteString()
0D1E:0009 B8014C    MOV     AX,4C01
0D1E:000C CD21      INT     21        ; AX = 4C01 : Exit()

코드는 매우 간단합니다. 문자열을 출력하고 종료해버리지요.

즉, notepad.exe 는 32 bit 용 PE 파일이지만, MS-DOS 호환 모드를 가지고 있어서
DOS 환경에서 실행하면 "This program cannot be run in DOS mode" 문자열을 출력하고 종료합니다.

이 특성을 잘 이용하면 하나의 실행(EXE) 파일에 DOS 와 Windows 에서 모두 실행 가능한 파일을 만들 수도 있습니다.
실제로 세계적인 보안업체 McAfee 에서 무료로 배포했던 scan.exe 라는 파일이 이와 같은 특징을 가지고 있었습니다.
(DOS 환경에서는 16 bit DOS 용 코드가, Windows 환경에서는 32 bit Windows 코드가 각각 실행됨.)

앞에서 말씀드린대로 DOS Stub 은 옵션이기 때문에, 개발 도구에서 지원해 줘야 합니다.
(VB, VC++, Delphi 등은 DOS Stub 을 기본 지원합니다.)


(continue)

반응형
반응형


Introduction


Windows 운영체제의 PE(Portable Executable) File Format 에 대해서 아주 상세히 공부해 보도록 하겠습니다.

PE format 을 공부하면서 Windows 운영체제의 가장 핵심적인 부분인
Process, Memory, DLL 등에 대한 내용을 같이 정리할 수 있습니다.



PE(Portable Executable) File Format


PE 파일의 종류는 아래와 같습니다.

  • 실행 파일 계열 : EXE, SCR
  • 라이브러리 계열 : DLL, OCX
  • 드라이버 계열 : SYS
  • 오브젝트 파일 계열 : OBJ

엄밀히 얘기하면 OBJ(오브젝트) 파일을 제외한 모든 파일들은 실행 가능한 파일 입니다.

DLL, SYS 파일등은 쉘(Explorer.exe) 에서 직접 실행 할 수는 없지만,
다른 형태의 방법(디버거, 서비스, 기타)을 이용하여 실행이 가능한 파일들입니다.

* PE 공식 스펙 에는 컴파일 결과물인 OBJ(오브젝트) 파일도 PE 파일로 간주합니다.
  하지만 OBJ 파일 자체로는 어떠한 형태의 실행도 불가능하므로 리버싱에서 관심을 가질 필요는 없습니다.


간단한 설명을 위해서 노트패드(notepad.exe) 파일을 hex editor 를 이용해서 열어보겠습니다.


<Fig. 1>

<Fig. 1> 은 notepad.exe 파일의 시작 부분이며, PE 파일의 헤더 (PE header) 부분입니다.

바로 이 PE header 에 notepad.exe 파일이 실행되기 위해 필요한 모든 정보가 적혀있습니다.

어떻게 메모리에 적재되고, 어디서부터 실행되어야 하며, 실행에 필요한 DLL 들은 어떤것들이 있고,
필요한 stack/heap 메모리의 크기를 얼마로 할지 등등...


수 많은 정보들이 PE header 에 구조체 형식으로 저장되어 있습니다.

즉, PE File Format 을 공부한다는 것은 PE header 구조체를 공부한다는 것과 같은 말입니다.



Basic Structure


일반적인 PE 파일의 기본 구조입니다. (notepad.exe)


<Fig. 2>

<Fig. 2> 는 notepad.exe 파일이 메모리에 적재(loading 또는 mapping)될 때의 모습을 나타낸 그림입니다.
많은 내용을 함축하고 있는데요, 하나씩 살펴보겠습니다.


  • DOS header 부터 Section header 까지를 PE Header, 그 밑의 Section 들을 합쳐서 PE Body 라고 합니다.

  • 파일에서는 offset 으로, 메모리에서는 VA(Virtual Address) 로 위치를 표현합니다.

  • 파일이 메모리에 로딩되면 모양이 달라집니다. (Section 의 크기, 위치 등)

  • 파일의 내용은 보통 코드(".text" 섹션), 데이타(".data" 섹션), 리소스(".rsrc") 섹션에 나뉘어서 저장됩니다.
    반드시 그런것은 아니며 개발도구(VB/VC++/Delphi/etc)와 빌드 옵션에 따라서
    섹션의 이름, 크기, 개수, 저장내용 등은 틀려집니다. 중요한 것은 섹션이 나뉘어서 저장 된다는 것입니다.

  • Section Header 에 각 Section 에 대한 파일/메모리에서의 크기, 위치, 속성 등이 정의 되어 있습니다.

  • PE Header 의 끝부분과 각 Section 들의 끝에는 NULL padding 이라고 불리우는 영역이 존재합니다.
    컴퓨터에서 파일, 메모리, 네트워크 패킷 등을 처리할 때 효율을 높이기 위해 최소 기본 단위 개념을 사용하는데,
    PE 파일에도 같은 개념이 적용된 것입니다.

  • 파일/메모리에서 섹션의 시작위치는 각 파일/메모리의 최소 기본 단위의 배수에 해당하는 위치여야 하고,
    빈 공간은 NULL 로 채워버립니다. (<Fig. 2> 를 보면 각 섹션의 시작이 이쁘게 딱딱 끊어지는 걸 볼 수 있습니다.)



VA & RVA



VA (Virtual Address) 는 프로세스 가상 메모리의 절대 주소를 말하며,
RVA (Relative Virtual Address) 는 어느 기준위치(ImageBase) 에서부터의 상대 주소를 말합니다.

VA 와 RVA 의 관계는 아래 식과 같습니다.

RVA + ImageBase = VA

PE header 내의 많은 정보는 RVA 형태로 된 것들이 많습니다.
그 이유는 PE 파일(주로 DLL)이 프로세스 가상 메모리의 특정 위치에 로딩되는 순간
이미 그 위치에 다른 PE 파일(DLL) 이 로딩 되어 있을 수 있습니다.

그럴때는 재배치(Relocation) 과정을 통해서 비어 있는 다른 위치에 로딩되어야 하는데,
만약 PE header 정보들이 VA (Virtual Address - 절대주소) 로 되어 있다면 정상적인 엑세스가 이루어지지 않을것입니다.

정보들이 RVA (Relative Virtual Address - 상대주소) 로 되어 있으면 Relocation 이 발생해도
기준위치에 대한 상대주소는 변하지 않기 때문에 아무런 문제없이 원하는 정보에 엑세스 할 수 있을 것입니다.




이어지는 강좌에서 PE Header 구조체를 하나씩 상세히 살펴보도록 하겠습니다.



(continue)



반응형
반응형

"무료 온라인 바이러스/악성 소프트웨어 검사 서비스"

새로운 파일을 접했을 때 그 파일이 악성 파일인지 검사해 보는 것은 매우 중요한 일입니다.
자칫하면 OS 를 재설치 해야 하는 상황이 벌어질 수 도 있기 때문이지요.

쉽고 간단하게 악성 파일 여부를 검사해주는 무료 서비스가 있습니다.

전세계 유명 Anti-Virus & Anti-Spyware 제품을 사용하여 악성 파일을 검사해주는 virustotal 입니다.
www.virustotal.com (한국어 서비스도 제공됩니다!)

홈페이지에 소개된 글을 보면 아래와 같은 특징이 있습니다.

  • 무료이며, 독립된 서비스입니다.
  • 여러 회사의 안티바이러스 엔진을 사용합니다.
  • 바이러스 정의를 실시간으로 자동 업데이트합니다.
  • 어떤 바이러스에 걸렸는지 알려드립니다.
  • 실시간으로 전세계적인 통계를 만들어냅니다.



웹, 이메일, 전용 프로그램 등을 통해서 검사를 원하는 파일을 전송할 수 있습니다.
제가 가진 유틸리티 중에서 해킹에 종종 사용되는 파일을 올려보겠습니다.


이미 검사한 파일이라고 나타납니다.
마지막 검사 날짜는 2008.11.09 일이고, 결과는 36개 제품 중에서 15개 제품이 악성 이라고 판별했군요.

[지금 다시 검사하기] 버튼을 눌러서 오늘 날짜의 최신 제품으로 검사를 해보도록 하겠습니다.
약간의 기다림 후에 아래와 같은 결과 화면이 나타납니다. (너무 길어서 그림을 축소 하였습니다.)


현재 시점에도 많은 제품에서 진단을 하고 있습니다. (not a virus 라는 진단명이 재미있군요.)

이처럼 세계 유명 보안 업체의 제품을 이용하여 간편하게 악성 파일 여부를 검사할 수 있다는 것이 최대 장점입니다.

새로운 파일을 분석하기 전에 virustotal 을 이용하는 습관을 들여보세요.

검사 결과 악성 파일로 의심된다면 중요한 컴퓨터에서 분석하지 마시고,
분석용 테스트 컴퓨터 (또는 Virtual Machine) 에서 분석을 진행하세요.

모두들 안전한 PC 생활을 하시기 바랍니다. ^^



반응형

'tool' 카테고리의 다른 글

PEView.exe  (21) 2013.01.27
HxD.exe 기능 추가!  (12) 2012.06.14
리버싱 현업에서 사용되는 디버거(Debugger)들  (33) 2010.09.29
InjDll.exe – DLL Injection/Ejection 전용 도구  (43) 2010.03.15
Process Explorer - 최고의 작업 관리자  (1) 2009.05.03
www.google.com  (2) 2009.03.06
반응형

#0. prologue

분야를 막론하고 기술자(특히 엔지니어)들은 자신만의 작업환경과 손에 익은 도구(장비)가 있습니다.

기술자(특히 엔지니어) 란 특정 업무를 위해서 필요한 도구를 아주 능숙하게 다룰 줄 아는 사람들입니다.

같은 도구를 사용하더라도 기술자의 능력에 따라서 전혀 다른 결과를 보여줍니다.
(더 나아가서 필요한 도구를 직접 만들어 내기도 합니다.)

또한 기술자들은 각자 자신만의 도구를 가지고 있으며
한번 손에 익힌 도구를 되도록 오래 쓰고 왠만해서는 바꾸려 하지 않습니다.
(바꿀 때도 될 수 있으면 같은 회사의 후속 제품으로 바꾸려고 하지요.)

남의 도구, 남의 작업환경에서 일을 하면 아무래도 불편하다고 생각합니다.

즉, 자신만의 작업환경과 자신만의 도구가 갖춰져야 그 기술자의 진정한 실력이 100% 발휘 된다고 할 수 있습니다.



#1. Reverse Code Engineer (Reverser)

리버서들은 어떨까요?

리버서도 역시 IT 엔지니어 범주에 들어가기 때문에 위에서 언급한 일반적인 기술자의 성향과 다를 바가 없습니다.

리버싱을 하기 위한 도구의 종류만도 수십 가지가 넘으며, 각 종류별로 다양한 제품들이 존재합니다.
또한 IT 분야의 특성상 계속해서 새로운 도구가 개발되고 있습니다.

도구의 종류만도 아래와 같이 매우 많습니다. (언급하지 못한 것도 많을 것입니다.)

disassembler
debugger - PE, script, etc
development tool - assembly, C/C++, etc
editor(viewer) - text, hex, resource, retistry, string, PE, etc
monitoring tool - process, file, registry, network, message, etc
memory dump
classifier
calculator - hex, binary
compare tool - text, hex
packer/unpacker
encoder/decoder
virtual machine
decompiler - VB, Delphi, etc
emulator
...



#2. 좋은 분석 도구 선택의 5 가지 기준

아래에 ReverseCore 만의 도구 선택 기준(가이드)을 제시합니다. (참고만 하세요~)


첫째, 도구 개수를 최소화시킨다.

남들이 쓴다고 해서 기능을 알지도 못하는 도구를 잔뜩 가지고 있어봐야 도움이 되지 않습니다.
자신에게 필요한 도구만을 각 종류별로 하나씩만 사용하는 것이 좋습니다.

자신의 실력에 맞는 것만을 고르고 차츰 하나씩 늘려나가시면 됩니다.

또한 중복된 기능의 도구들은 하나로 정리하는 것이 좋습니다.


둘째, 도구는 기능이 단순하고 사용방법이 편리한 것이 좋다.

실력이 늘어날 수록 사용해야 할 도구의 개수도 늘어납니다.
기능이 단순하고 인터페이스가 직관적일 수록 사용하기에 편리합니다.

여기서 기능이 단순하다는 말은 리버싱 도구치고는 단순하다는 말입니다.
(Windows 의 계산기, 메모장 수준을 생각하시면 안됩니다. ^^)

따라서 아무리 단순한 리버싱 도구를 하나 익히는 데만도 어느 정도 시간이 필요합니다.


셋째, 기능을 철저히 익힌다.

아무리 좋은 도구라도 사용할 줄 모르면 무용지물 입니다.

자신이 이미 가지고 있는 도구에서 제공되는 기능인데도,
그걸 알지 못하고 다른 도구를 찾는 분들이 많습니다.

일단 도구를 선택한 후에는 제공되는 메뉴얼을 한번 정독해보시는 것이 좋습니다.
자주 사용하는 기능의 단축키 정도는 외워 두시면 작업이 훨씬 수월합니다.
(단축키를 잘 쓰면 확실히 자타공인 전문가처럼 느껴집니다.)


넷째, 꾸준히 업데이트 한다.

리버싱도 IT 범주에 속하기 때문에 기술 발전 속도가 매우 빠릅니다.

새로운 기술에 대응하기 위해 도구들도 빠르게 변화하기 때문에
사용하는 도구의 업데이트는 매우 중요한 일입니다.

따라서 꾸준히 업데이트를 지원하는 도구를 선택하는 것이 좋습니다.


다섯째, 도구의 핵심 동작 원리를 이해한다.

도구를 더 잘 사용하기 위해서 동작 원리를 이해하는 것이 좋습니다.
더 나아가 테스트용 프로토타입을 만들 수 있다면 금상첨화 입니다.

이 부분을 간과하시는 분들이 매우 많습니다.
하지만 높은 수준의 리버싱 실력을 쌓기 위해서는 필수적인 사항입니다.

예를 들어 debugger 의 동작원리를 이해하고 있으면,
anti-debugging 기법을 잘 회피할 수 있습니다.

원리를 이해하지 못하고 도구에만 의존하면,
간단한 트릭도 해결하지 못하고 다른 도구를 찾아 나서야 합니다.
소위 말하는 "도구의 노예"가 되는 것이지요. (이것만은 꼭 경계해야 겠습니다.)



#3. epilogue

debug.exe 라는 프로그램을 아시나요?
MS-DOS 시절부터 존재하던 16-bit debugger 입니다. (XP 에도 존재합니다.)

커맨드 창에서 debug.exe 를 실행하고 '?' 명령으로 도움말을 보겠습니다.


위에 보이는 명령어가 전부입니다.

단순하지요?

제가 아는 어떤 분이 debug.exe 로 16 bit DOS 프로그램을 분석하시는 걸 본 적이 있습니다.

뭔가를 실행시키더니 키보드를 다다다다 두들기면서 화면이 번쩍 번쩍 넘어가는데,
바로 옆에서 지켜보면서도 무슨 작업을 하는지 도저히 알 수 없었습니다.
(눈이 그분의 작업 속도를 따라가지 못한 거죠.)

처음에는 실행되는 프로그램이 debug.exe 인지 조차도 몰랐었습니다.
(전 그때 당시 이미 debug.exe 를 한달 정도 써본 경험이 있었음에도 불구하고 말이죠.)

그리고는 다 됐다면서 결과를 넘겨 주시더군요.
그때 그분이 사용하신 프로그램이 debug.exe 라는 걸 알고 충격에 휩쌓였었죠.

'저 단순한 debug.exe 만으로 이 일을 이렇게 빨리 해냈단 말인가?' 하고 말이죠.

그 이후로 제가 어떤 도구를 고를 때 나름대로의 기준을 세우게 되었습니다.

그리고 하나의 깨달음을 얻었습니다.

"평범한 도구라도 극한까지 연마하면 천하에 다시 없는 비범한 도구가 된다."

마치 무림고수(武林高手)가 수련에 수련을 거듭해서 검(劍)을 버리고
결국에는 초(草)/목(木)/죽(竹)/석(石)을 모두 검처럼 사용할 수 있듯이 말이죠.


여러분은 어떻게 생각하시나요? ^^


반응형
반응형


Reverse Code Engineering 을 하는데 가장 필요한 것 2 가지만 선택하라고 한다면,
첫째는 열정 이고, 둘째는 Google 을 선택하겠습니다.

사실 무슨 일을 하던지 열정이 가장 중요하고
그 다음으로는 구체적인 작업 진행 방법에 대한 정보의 수집인데,
역시 최고의 검색엔진 google 이 가장 유용하다고 할 수 있습니다.


<Fig. 1>

국내 포탈 사이트에서 제공하는 웹 페이지 검색 기능은 좀 기초적인 수준입니다.
반면에 세계 최고의 검색 엔진 google 은 원하는 정보를 거의 정확하게 찾아줍니다.

Reverse Code Engineering 분야는 해외에서 각광받는 분야이기 때문에
초중급 리버서들에게 필요한 모든 정보들이 이미 웹 사이트에 잘 정리되어 있다고 볼 수 있습니다.
(즉, 내가 지금 하고 있는 일들은 이미 누군가가 해본 후 잘 정리까지 해뒀다고 생각하시면 됩니다.)

단 하나의 걸림돌은 외국어 (특히 영어) 인데요, 이것은 SW 엔지니어의 숙명이라고 생각합니다.
무조건 영어를 잘하기 위해서 노력하지 않으면 안됩니다.

* 요즘은 중국에서 리버싱 관련 사이트들이 굉장히 많아 졌으며, 새로운 리버싱 강국으로 떠오르고 있습니다.
  영어외에도 중국어를 잘 익혀놓는다면 리버싱에 많은 도움이 될 것입니다.


이제부터 google 을 이용해서 리버싱에 필요한 정보, 강좌, 유틸리티 등을 얻고 맘껏 공부하시기 바랍니다.
반응형

'tool' 카테고리의 다른 글

PEView.exe  (21) 2013.01.27
HxD.exe 기능 추가!  (12) 2012.06.14
리버싱 현업에서 사용되는 디버거(Debugger)들  (33) 2010.09.29
InjDll.exe – DLL Injection/Ejection 전용 도구  (43) 2010.03.15
Process Explorer - 최고의 작업 관리자  (1) 2009.05.03
www.virustotal.com  (3) 2009.03.20

+ Recent posts