Stub Code : 사용자가 입력한 코드가 아닌 컴파일러가 임의로 추가시킨 코드이다. 컴파일러 별로 Stub Code 모양이 상이하다.
OllyDbg 기본 명령어
Restart [Ctrl+F2] 다시 처음부터 디버깅 시작
Step Into [F7] 하나의 OP code 실행 (CALL 명령을 만나면, 그 함수 코드 내부로 따라 들어감)
Step over [F8] 하나의 OP code 실행 (CALL 명령을 만나면, 따라 들어가지 않고 그냥 함수 자체를 실행)
Execute til Return [Ctrl+F9] 함수 코드 내에서 RETN 명령어 까지 실행(함수 탈출 목적)
추가적 명령어
Go to [Ctrl+G] 원하는 주소로 이동(코드/메모리를 확인할 때 사용. 실행되는것은 아님)
Execute till Cursor [F4] cursor 위치까지 실행(디버깅하고 싶은 주소까지 바로 갈 수 있음)
Comment [ ; ] Comment 추가
User-defined comment 마우스 우측 메뉴 Search for User-defined comment
Label [ : ] Label 추가
User-defined label 마우스 우측 메뉴 Search for User-defined label
Set/Reset BreakPoint [F2]
Run [F9] 실행(BP가 걸려있으면 그곳에서 실행이 정지됨)
Show the current EIP [ * ] 현재 EIP 위치를 보여줍니다.
Show the previous Cursor [ - ] 직전 커서 위치를 다시 보여줍니다.
Preview CALL/JMP address [Enter] 커서가 CALL/JMP등의 명령어에 위치한다면, 해당 주소를 따라가서 보여줌(실행되는 것이 아님. 간단히 함수 내용을 확인할 때 유용함)
Animate Into [Ctrl+F7] Step Into 명령 반복 화명 표시 됨
Animate Over [Ctrl+F8] Step Over 명령 반복
Trace Into [Ctrl+F11] Step Into 명령 반복 화면 표시 안됨
Trace Over [Ctrl+F12] Step Over 명령 반복
문자열 검색 마우스 우측 메뉴 - Search for - All referenced text strings
코드에서 사용된 API 호출 목록 보기 - All intermodular calls
(Packer/Protector를 사용하여 실행파일을 압축/보호해버리면, 파일 구조가 변경되어 API호출목록이 보이지 않는다.(심지어 디버깅 자체가 어려워짐)
바이트오더링 (빅엔디언 사람이보기에 직관적 / 리틀엔디언 산술 연산과 데이터의 타입이 확장,축소될 때 효율적)
타입 name size 빅 리틀
BYTE b 1 [12] [12]
WORD w 2 [12][34] [34][12]
DWORD dw 4 [12][34][56][78] [78][56][34][12]
스택창에서 마우스 우측 메뉴 Address - Relative to EBP - EBP 기준으로 표시되기 때문에 좀 더 직관적으로 보인다.
어셈블리와 C언어의 포인터 구문 형식
어셈블리 언어 C언어 Type casting
DWORD PTR SS:[EBP-4] *(DWORD *)(EBP-4) DWORD (4바이트)
WORD PTR SS:[EBP-4] *(WORD *)(EBP-4) WORD (2바이트)
BYTE PTR SS:[EBP-4] *(BYTE *)(EBP-4) BYTE
'DWORD PTR'과 'SS:' 안보이게 설정 가능
호출한 쪽(Caller)에서 스택에 저장된 파라미터를 정리하는 것을 'cdecl' 방식이라하고 호출당한 쪽(Callee)에서 스택에 저장된 파라미터를 정리하는 것을 'stdcall' 방식이라고 한다. 이러한 호출 규약을 일컬어 Calling Convention이라고 말한다.
Debugging options - Analysis1 - Show ARGs and LOCALs in procedures 메뉴를 이용하면 로컬 변수와 파라미터 형식으로 표시된다.
TEST : 논리비교 'AND' 연산과 동일하지만 operand 값이 변경되지 않고 EFLAGS 레지스터만 변명됨)
Process Explorer 프로세스들을 Parent/Child의 트리 구조로 표시한다. PID, CPU점유율, 프로세스에 로딩된 DLL 정보나 오픈한 object handle을 표시한다.
프로세스 Suspend/Resume, 종료기능도 있음
fastcall 방식은 기본적으로 함수에 전달하는 파라미터 일부(2개까지)를 스택 메모리가 아닌 레지스터를 이용하여 전달한다는 것이 특징이다. 어떤 함수의 파라미터가 4개라면, 앞의 두개의 파라미터는 각각 ECX, EDX파라미터를 이용하여 전달합니다.
Search for - All intermodular calls 명령을 사용하면 프로그램에 사용되는 API 호출 목록이 나타납니다.
Set breakpoint on every call to rtcMsgBox 메뉴를 선택하면 rtcMsgBox를 호출하는 모든 코드에 BP가 설치된다.
PE파일의 종류
실행 계열 EXE, SCR 드라이버 계열 SYS, VXD 라이브러리 계열 DLL, OCX, CPL, DRV 오브젝트 파일 계열 OBJ
PE파일이 메모리에 로딩되는 모습
PE헤더의 구성
DOS Header - PE헤더의 앞부분에는 기존 DOS EXE Header를 확장시킨 IMAGE_DOS_HEADER구조체가 존재한다.
그중 e_magic : DOS signature와 e_lfanew : NT header의 옵셋을 표시 가 중요하다.
DOS Stub의 존재 여부는 옵션이며 코드와 데이터의 혼합으로 이루어져 있다.
32비트 Windows OS에서는 이쪽 명령어가 실행되지 않는다.(PE파일로 인식하기 때문에) 하지만 DOS 환경에서 실행하거나 DOS용 디버거를 이용해서 실행하면 실행된다.(한마디로 DOS EXE 파일로 인식한다. 이들은 PE File Format을 모르기 때문에.)
IMAGE_NT_HEADERS 구조체는 3개의 멤버로 되어 있는데 1번째 시그니처와 File Header와 Optional Header 구조체 멤버가 있습니다.
우선 IMAGE_FILE_HEADER는 4가지 멤버가 중요하다 1.Machine 2.NumberOfSections 3.SizeOfOptionalHeader(이 값을 보고 IMAGE_OPTIONAL_HEADER32 구조체 크기 인식, PE32+경우 64구조체를 사용) 4.Characteristics(파일의 속성을 나타내는 값으로, 실행가능 한지 OR DLL 파일인지 등의 정보들이 bit OR 형식으로 조합됩니다.
다음으로 PE헤더 구조체 중에서 가장 크기가 큰 IMAGE_OPTIONAL_HEADER32이다. 멤버 값이 파일실행에 필수적이라 잘못 세팅되면 파일이 정상 실행 X
1.Magic 2.AddressOfEntryPoint는 EP의 RVA 값을 가지고 있다. 프로그램에서 최초로 실행되는 코드의 시작 주소로, 매우 중요한 값
3.ImageBase PE파일이 로딩되는 시작 주소를 나타낸다.
4.SectionAlignment 메모리에서 섹션의 최소단위, FileAlignment 파일에서 섹션의 최소단위
5.SizeOfImage PE파일이 메모리에 로딩되었을 때 가상 메모리에서 PE Image가 차지하는 크기
6.SizeOfHeader PE헤더의 전체 크기를 나타냅니다. 이 값 역시 FileAlignment의 배수여야한다.
7.Subsystem 값에 따라 시스템 드라이버 파일(*.sys)인지 일반 실행(*.exe, *.dll)인지 구분할 수 있다.
8.NumberOfRvaAndSizes 마지막 멤버인 DataDirectory 배열의 개수를 나타냅니다.
9.DataDirectory는 IMAGE_DATA_DIRECTORY 구조체의 배열로, 배열의 각 항목마다 정의된 값을 가집니다.
RVA(Relative Virtual Address) < - > RAW(file offset) 변환 작업 중요
RAW(파일에서의 주소) - PointerToRawData(파일에서 섹션의 시작주소) = RVA(메모리에서의 주소) - VA(메모리에서의 섹션의 시작주소)
Packer 일반 PE파일을 실행 압축 파일로 만들어 주는 유틸리티
UPX 파일 트레이싱 루프를 만나면 역할을 살펴보고 탈출한다.
DLL 로딩 방식
Explicit Linking 프로그램에서 사용되는 순간에 로딩하고 사용이 끝나면 메모리에서 해제되는 방법
Implicit Linking 프로그램 시작할 때 로딩되어 프로그램 종료할 때 메모리에서 해제되는 방법
IAT(Import Address Table)은 후자의 링킹 방식을 사용 Windows OS에서 사용
쓰이는 이유 DLL Relocation때문이다. DLL은 PE헤더에 명시된 ImageBase에 로딩된다는 보장이 없다. 반면에 process 생성 주체가 되는 EXE파일은 자신만의 가상 메모리 공간을 가지기 때문에 보장이 있다. windows 시스템 dll은 고유한 이미지베이스를 가지고 있어서 리로케이션 발생 x
INT(Import Name Table) 임포트하는 함수의 정보가 담긴 구조체 포인터 배열이다.
EAT는 라이브러리 파일에서 제공하는 함수를 다른 프로그램에서 가져다 사용할 수 있도록 해주는 핵심 메커니즘이다.
PE 재배치 작업의 기본 동작 원리
프로그램에서 하드코딩된 주소 위치를 찾는다. -> 값을 읽은 후 ImageBase만큼 뺀다.(VA->RVA) -> 실제 로딩 주소를 더한다.(RVA->VA)
.reloc섹션 수동으로 제거하기
1. .reloc 섹션 헤더 정리 (헥스에디터를 이용해서 0으로 덮어줌)
2. .reloc 섹션 제거 (섹션을 물리적으로 제거 HxD의 'Delete' 기능을 이용하면 편리)
3. IMAGE_FILE_HEADER 수정 (Number of Sections 항목에서 -1 해줌 섹션이 하나 줄었기 때문에)
4. IMAGE_OPTIONAL_HEADER 수정 (Size of Image 값에 이미지 크기를 수정해야함)
UPack은 두 번째 섹션에 압축된 원본 데이터가 존재하고, 이 데이터를 디코딩 루프를 돌면서 첫 번째 섹션에 압축해제 합니다.
UPACK은 IMAGE_DOS_HEADER의 e_lfanew 멤버에 값을 변경해 IMAGE_NT_HEADERS의 시작위치를 당겨 MZ헤더와 PE헤더의 겹쳐쓴다.
그리고 헤더 안에 디코딩 코드를 삽입하기 위해 IMAGE_FILE_HEADER.SizeOfOptionalHeader의 값을 변경한다. 이 값을 늘리면 IMAGE_SECTION_HEADER는 IMAGE_OPTIONAL_HEADER과의 사이 공간이 늘어나도 디코딩 코드를 추가할 수 있다.
IMAGE_OPTIONAL_HEADER.NumberOfRvaAndSizes 값을 변경해 IMAGE_DATA_DIRECTORY 구조체 배열의 원소 개수를 변경한다. 정상적인 파일은 10개의 배열 개수를 갖는다. Upack에서는 A개로 변경하고 역시 남게되는 하나의 배열에 자신의 코드를 덮는다.
섹션과 헤더를 겹쳐쓰고 IMAGE_SECTION_HEADER에 정의된 값에 따라 같은 파일 이미지를 가지고 각각 다른 위치와 다른 크기의 메모리 이미지를 만들 수 있다.
헤더영역의 RVA와 RAW 값은 동일하다.
섹션 시작의 파일 옵셋을 가리키는 PointerToRawData 값은 FileAlignment의 배수가 되어야하는데 PointerToRawData가 10이므로 강제로 배수를 맞춰 0으로 인식한다. 이것이 바로 UPack파일이 실행은 되지만 PE 관련 유틸에서 에러가 발생했던 이유이다.
인라인 패치
Assemble [Space] 명령과 'Edit' [Ctrl+E] 명령을 이용하여 인라인 패치를 진행한다.
REP(Repeat String)
ECX 레지스터를 카운터로 사용해서 문자열 관련 명령을 ECX>0인 동안 반복한다.
한번 진행될 때마다 ECX 레지스터값이 -1 된다.
MOVS(Move String)
Source에서 Destination으로 데이터를 복사한다.
ex) REP MOVS destination, source
패치코드 끼워넣고 적당한 JMP문 패치
훅 (정보를 엿보거나 가로챔)
Windows 운영체제는 GUI를 제공하고, 이는 Event Driven 방식으로 동작한다. 키보드/마우스를 이용하여 메뉴 선택, 버튼 선택, 창 변경, 이동 모두 이벤트이다. 이벤트가 발생할때 OS는 미리 정의된 메세지를 해당 응용 프로그램에 통보한다.
ex) 키보드 입력 이벤트 메세지인 WM_KEYDOWN 메세지가 [OS message queue]에 추가되고 OS는 어느 응용프로그램에서 이벤트가 발생했는지 파악하고 큐에서 메세지를 꺼네 해당 응용 프로그램에 메세지 큐에 추가한다. 응용프로그램은 메세지큐를 모니터링 하고 있다가 추가된 게 확인되면 Event handler를 호출한다. 훅을 여러개 설치해 순서대로 호출되는 체인도 가능
Break on new module 옵션 디버기 프로세스에 새로운 DLL이 로딩될때 자동으로 디버깅을 멈추는 옵션
시스템 자원은 OS가 직접 관리한다.(안정성, 보안, 효율, 기타)
이럴 때 사용자 애플리케이션은 시스템 커널에게 요청해 MS에서 제공한 Win32 API를 이용하는데 API 함수 없이는 어떤 의미 있는 프로그램도 만들 수 없다.(프로세스, 스레드, 메모리, 파일, 네트워크, 레지스트리, 그래픽, 사운드, 기타 시스템 자원에 접근)
실제 어플리케이션 코드를 실행하기 위해 많은 시스템 라이브러리가 로딩된다.
ex) notepad.exe에서 c:/abc.txt라는 파일을 열고자 하면 msvcrt!fopen() API를 호출한다. 후에
-msvcrt!fopen()
kernel32!CreatFileW()
ntdll!ZwCreateFile()
ntdll!KiFastSystemCall()
SYSENTER
-> 커널 모드 진입 이런 과정으로 타고 내려간다.
후킹 API 호출 과정은 사용자가 DLL 인젝션 기술로 hook.dll을 프로세스 메모리 공간에 침투시키고 Kernel32!CreateFile() API가 호출될 때마다 hook!MyCreateFile()이 먼저 호출되어 사용자와 커널 사이에 return, call을 주고 받는다.
API 후킹 부분은 IAT, 프로세스 메모리에 매핑된 시스템 라이브러리에서 실제 API 주소를 찾아 직접 수정, EAT가 있다.