-榮-

디버깅 실습4 - Debug Blocker 동작원리

xii.xxv — Thu, 8 Feb 2024 02:58:35 +0900

1. Debug Blocker

Dubug Blocker 기법은 프로세스가 자기 자신(또는 다른 실행 파일)을 디버깅 모드로 실행하는 기법이다. 이 기법은 다양한 안티 디버깅 기법 중 하나로, 몇몇 PE 프로텍터에서 사용되고 있다.

Debug Bolcker 기법이 적용된 프로세스는 디버거로 동작할 때와 디버기로 동작할 때 각각 다른 코드를 실행하도록 프로그래밍되어 있다.

만약 중요한 코드가 디버기 프로세스에서 실행된다면 그쪽을 디버깅해야 한다. 하지만 디버거-디버기 관계 자체가 안티 디버깅 역할을 하기 때문에 디버기 프로세스의 디버깅이 까다로워진다.

2. 안티 디버깅 특성

Debug Blocker 기법이 안티 디버깅으로 분류되는 이유는 아래와 같다.

● 부모-자식 관계

디버거-디버기 프로세스 관계는 기본적으로 부모-자식 프로세스 관계이다. 이전 실습의 ‘Self-Creation 기법’에서 같은 프로그램이 부모 프로세스로 실행될 때와 자식 프로세스로 실행될 때 다른 동작을 하는 경우 자식 프로세스의 디버깅이 까다로워지는 것을 확인한 적 있다.

● 디버기 프로세스는 다른 디버거에서 디버깅을 할 수 없다.

Windows 운영체제에서는 여러 디버거로 동시에 같은 프로세스를 디버깅할 수 없다. 즉, 자식 프로세스를 디버거를 사용하여 Attach 하는 것이 불가능하다. 디버기 프로세스를 디버깅하고 싶으면 우선 기존 디버거-디버기 관계를 끊어야 한다..

● 디버거 프로세스를 종료하면 디버기 프로세스도 동시에 종료

디버거-디버기 관계를 끊기 위해서 강제로 디버거 프로세스를 종료시키면 동시에 디버기 프로세스도 종료된다.

디버기를 직접 디버깅하자니 연관된 디버거 프로세스 때문에 불가능하고, 그 디버거 프로세스를 종료하자니 디버기 프로세스도 같이 종료되는 어려운 상황에 놓이게 된다.

● 디버거에서 디버기의 코드를 조작

Debug Blocker 기법에서 디버거의 역할은 디버기 프로세스의 실행 분기를 조작하고, 코드를 생성/변경시킨다. 또한 지속적으로 디버기 프로세스의 코드 실행에 영향을 끼친다. 다시 말해 디버거 프로세스 없이 디버기 프로세스만으로는 정상적인 실행이 불가능한 경우가 많다.

● 디버기의 예외(Exception)를 디버거에서 처리

디버거-디버기 관계에서 디버기 프로세스에 발생한 모든 예외는 디버거에서 처리하도록 되어 있다. 가령 디버기 프로세스가 의도적으로 예외(예, Memory Access Violation)를 발생시킬 때, 이 예외가 해결되지 않으면 더 이상 코드를 실행할 수 없다. 이 예외는 디버거 프로세스에서 해결해야 된다..

디버기 프로세스에 예외가 발생하면 실행이 멈추고, 디버거 프로세스가 제어권을 가지게 된다.. 이때 디버거에서는 디버기의 실행 분기를 변경해 버린다. 추가적으로 디버기 프로세스 내의 암호화된 코드를 복호화하거나, 레지스터 혹은 스택에 특정한 값을 입력하는 등의 다양한 작업을 수행하는 경우도 있다.

따라서 리버서는 디버거 프로세스에서 어떻게 예외를 처리하는지 ‘디버거 프로세스를 디버깅’하면서 일일이 확인해야 된다. 그래야 정확한 디버기 프로세스의 실행 코드를 얻을 수 있다.

이러한 사실들이 Debug Blocker 기법을 상당히 까다로운 안티 디버깅 기법으로 만든다.

3. 디버깅 실습

실습 파일(DebugMe4.exe)의 실행 화면을 보면 기능을 대략 짐작할 수 있습니다. 부모 프로세스(Debugger)의 “Parent Process”라는 문자열과 자식 프로세스(Debuggee)의 “Child Process” 메시지 박스를 확인 가능하다.

DebugMe4.exe 실행 화면

● 1차 시도

처음에는 프로그램의 저체 구조를 파악하기 위한 목적으로 간단히 디버깅해 본다.

○ 디버깅 시작 위치 선정

DebugMe4.exe 파일은 Console 시반의 프로그램이므로 디버깅 시작 위치(main() 함수)를 알 수 있다. 프로그램의 핵심적인 코드를 찾아낼 때 사용할 수 있는 또 다른 방법은 ① 프로그램 내에서 사용되는 ‘문자열’을 이용하는 방법과 ② 프로그램에서 호출되는 Win32 API를 예상해서 BP를 설치하는 방법 등이 있다.

○ main()

OllyDbg로 DebugMe4.exe 파일을 열고 main()까지 이동한다.

DebugMe4.exe의 main() 함수

main() 함수 코드는 매우 간단하게 구성되어 있다. ‘ReverseCore:DebugMe4’라는 이름의 뮤텍스(Mutex) 객체를 생성한다.

00401009

CALL DWORD PTR DS:[408004]

; CreateMutexW()

CreateMutexW() API가 정상적으로 리턴되었다면 Last Error를 구해서 B7(ERROR_ALREADY_EXISTS)과 비교한다.

0040102A
00401030

CALL DWORD PTR DS:[40801C]
CMP EAX, 0B7

; GetLastError()

이 코드는 전형적인 Mutex 객체를 이용한 프로세스 중복 실행 체크 코드이다.

즉 DebugMe4.exe 파일이 부모 모드로 처음 실행되면 ‘ReverseCode :DebugMe4’ 이름의 Mutex가 정상적으로 생성되며 Last Error는 0이 될 것이다. 그러나 자식 모드로 실행되면 이미 부모 프로세스에서 생성한 같은 이름의 Mutex 객체가 존재하므로 Last Error는 B7이 될 것이다. 이 원리를 이요하여 DebugMe4.exe 프로세스가 부모 모드인지 자식 모드인지 판별할 수 있다.

00401035
00401037
0040103C
0040103E
0040103F
00401041
00401042

JE SHORT 0040103F
CALL 0040160
XOR EAX, EAX
RETN
LEA EAX, EAX
DB 15
DB 7F

; 0040103F
; 00401060

; Illegal use of register

현재는 부모 모드로 실행 중이므로 결국 401060 함수를 호출한다.

401060 함수는 상당히 큰 규모의 함수이다. 간단히 훑어보며 자식 프로세스를 어떤 식으로 생성하는지 확인해 보자.

401060 함수 내에서 자기 자신(DebugMe4.exe)을 디버그 모드(DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS)로 실행하는 코드를 확인할 수 있다. DebugMe4.exe는 자기 자신을 자식 프로세스로 실행하는데, Debug 모드로 실행시켜서 부모 프로세스는 디버거가 되고, 자식 프로세스는 디버기로 동작하도록 만든다.

CreateProcessW() 호출

※ 1차 시도에서 알아낸 사실

‘ReverseCore:DebugMe4’라는 이름의 Mutex 객체를 이용한 부모/자식 프로세스 구분
부모/자식 프로세스에서 갈라지는 실행 코드(부모 : 401037, 자식 : 40103F)
부모/자식 프로세스의 관계는 디버거/디버기 관계

● 2차 시도

Debug Blocker 기법에서는 보통 자식 프로세스(Debuggee)에서 핵심 코드가 실행된다. 앞에서 확인한 Mutex를 이용한 조건 분기를 조작하여 자식 프로세스 모드에서 실행될 코드를 디버깅해 보자. OllyDbg의 DebugMe4.exe 디버깅을 재실행하고, 401035 주소에 BP를 걸고 실행한다.

우측 Register 창의 ZF(Zero Flag)를 마우스 더블클릭하여 1로 변경한다. 그러면 401035 주소의 JE 명령에 의하여 40103F 주소로 점프한다.

401035 주소의 조건 분기 코드

40103F 주소의 코드를 보면 ILLEGAL INSTRUCTION예외가 발생한다.

0040103F

LEA EAX, EAX

IA32 MANUAL에서 LEA(Load Effective Address) 명령어의 정의를 보면 LEA 명령어의 첫 번째 Operand는 레지스터(r16/r32/r64)이고, 두 번째 Operand는 Memory이다.

LEA(Load Effective Address) 명령어 정의

40103F 주소의 명령어(LEA EAX, EAX)를 보면, 두 번째 Operand에 Memory가 아닌 레지스터(EAX)가 왔기 때문에 Exception이 발생하게 된다. 이러한 잘못된 명령어는 IA32 Opcode Map에 의해 억지로 조합할 수는 있지만 실제로 사용될 수 없다.

자식 프로세스(디버기)에서 4013F 주소의 잘못된 명령어(LEA EAX, EAX)가 실행되면, 예외가 발생하여 부모 프로세스(디버거)에게 제어권이 넘어간다. 제어권을 받은 부모 프로세스에서는 해당 예외를 처리함과 동시에 또 다른 작업을 수행한다.

401041 주소의 명령어를 보면 정상적인 형태의 명령어가 아닌 것을 알 수 있다.(OllyDbg가 해당 코드를 Disassemble하지 못한다.) 아마 제어권을 넘겨받은 부모(디버거) 프로세스에서 해당 코드를 복호화 혹은 다른 주소로 실행 분기를 변경하든지 작업을 할 것으로 예상할 수 있다. 따라서 부모 프로세스(디버거)의 실행 코드를 상세히 분석하는 방법밖에는 없다.

※ 2차 시도에서 알아낸 사실

자식(디버기) 프로세스의 실행 코드에 의도적인 예외 발생 코드 존재
이후 코드는 정상적인 코드로 보이지 않음(암호화된 코드, 데이터 혹은 의미 없는 코드)
부모(디버거)의 실행 코드를 상세히 분석해야 함

● 3차 시도

부모(디버거) 프로세스의 401060 함수를 상세히 디버깅한다. OllyDbg를 재실행하여 40115C까지 재실행한다.

...
0040115C 00401160 00401161 00401165 00401166 00401167 00401168 0040116A 0040116B 0040116C 0040116D 00401174 00401175 00401176	LEA EAX, DWORD PTR SS:[ESP+10] PUSH EAX LEA ECX, DWORD PTR SS:[ESP+24] PUSH ECX PUSH ESI PUSH ESI PUSH 3 PUSH ESI PUSH ESI PUSH ESI LEA EDX, DWORD PTR SS:[ESP+3D8] PUSH EDX PUSH ESI CALL DWORD PTR DS:[40800C]	; -pProcessInfo ; -pStartupInfo ; -CurrentDir ; -pEnvironment ; -CreationFlags = DEBUG_PROCESS \|DEBUG_ONLY_ THIS_PROCESS ; -InheritHandle ; -pThreadSecurity ; -pProcessSecutiry ; -CommandLine ; -ModuleFileName ; CreateProcessW()
...
004011A9 004011AE	PUSH 409A58 CALL 00401345	; ASCII “Parent Process” ; printf()
...
004011C3 004011C5 004011C9 004011CA	PUSH –1 LEA ECX, DWORD PTR SS:[ESP+6C] PUSH ECX CALL DWORD PTR DS:[408024]	; -Timeout ; -pDebugEvent ; WaitForDebugEvent()
...

401176 주소에서 CreateProcessW() API를 호출하여 자기 자신(DebugMe4.exe)을 Debug Mode로 실행시킨다. 그리고 4011CA 주소의 WaitForDebugEvent()를 이용해서 디버기 프로세스로부터 Debug 이벤트가 발생하기를 기다린다.

BOOL WaitForDebugEvent(
[out] LPDEBUG_EVENT lpDebugEvent,
[in] DWORD dwMilliseconds
);

출처 : MSDN

WaitForDebugEvent() API를 호출하면 dwMilliseconds에서 정한 시간 동안 디버기 프로세스의 Debug 이벤트를 기다린다. 예외도 Debug 이벤트의 한 종류이다.

만약 디버기 프로세스에서 예외가 발생하면 WaitForDebugEvent() API가 리턴하고, lpDebugEvent 포인터가 가리키는 DEBUG_EVENT 객체에 해당 예외에 대한 정보가 채워진다.

typedef struct _DEBUG_EVENT {
DWORD dwDebugEventCode;
DWORD dwProcessId;
DWORD dwThreadId;
union {
EXCEPTION_DEBUG_INFO Exception;
CREATE_THREAD_DEBUG_INFO CreateThread;
CREATE_PROCESS_DEBUG_INFO CreateProcessInfo;
EXIT_THREAD_DEBUG_INFO ExitThread;
EXIT_PROCESS_DEBUG_INFO ExitProcess;
LOAD_DLL_DEBUG_INFO LoadDll;
UNLOAD_DLL_DEBUG_INFO UnloadDll;
OUTPUT_DEBUG_STRING_INFO DebugString;
RIP_INFO RipInfo;
} u;
} DEBUG_EVENT, *LPDEBUG_EVENT;

출처 : MSDN

dwDebugEventCode 멤버는 Debug 이벤트의 종류(타입)이다. 9가지의 이벤트가 존재하며, u 멤버는 각각의 Debug 이벤트에 해당하는 구조체가 저장된다(u 멤버는 union이며 9개의 structure를 하나로 묶어버린다).

4011CA 주소까지 디버깅하면 pDebugEvent가 가리키는 주소는 18F9D8이다.

WaitForDebugEvent() API 호출 이전의 DEBUG_EVENT 구조체

WaitForDebugEvent() API 호출을 실행한 후 18F9D8을 보면 dwDebugEventCode 값은 3(CREATE_PROCESS_DEBUG_EVENT)이다.

WaitForDebugEvent() API 호출 이후의 DEBUG_EVENT 구조체

트레이싱을 하다 보면 조건 분기 코드가 나온다. 4011F0 주소의 [ESP+68]은 [18F9D8](dwDebugEventCode)이다. 이 값을 EAX 레지스터에 저장한 후 4011F4 주소에서 1(EXCEPTION_DEBUG_EVENT)과 비교한다. 현재 dwDebugEventCode는 3이므로 4011F7 주소의 JNZ 명령에 의해 4012C0 주소로 점프한다.

dwDebugEventCode 값의 비교를 통한 조건 분기 1

4012C0 주소에서 다시 EAX(dwDebugEventCode) 값을 5(EXIT_PROCESS_DEBUG_EVENT)와 비교한다. 현재 EAX 값은 3이므로 4012C3 주소의 JE 명령어를 그대로 통과한다. 4012D4 주소의 ContinueDebugEvent() API를 호출하면서 실행이 멈춰진 디버기 프로세스를 계속 실행시켜 준다. 그리고 4012F2 주소의 WaitForDebugEvent() API를 호출하여 디버기 프로세스의 Debug 이벤트를 기다리는 상태가 된다. 다시 Debug 이벤트가 발생하면 4011F0 주소로 가게 된다..

dwDebugEventCode 값의 비교를 통한 조건 분기 2

4011F0~4011F7 주소의 명령어를 보면, 이 루프는 디버기로부터 EXCEPTION_DEBUG_EVENT(1) 예외를 기다리는 것을 알 수 있다. 이 경우를 집중적으로 분석하자. 가장 간단한 방법은 4011FD에 BP를 설치하고 실행하는 것이다. 루프는 디버기의 EXCEPTION_DEBUG_EVENT(1)가 발생했을 때 4011FD 주소에 정확히 멈출 것이다. 또 다른 방법은 4011FD에 Conditional Log Break Point[SHIFT+F4]를 설치하여 사용자 로그를 출력하고 조건에 따라 실행을 멈추도록 할 수 있다.

● 4차 시도

OllyDbg의 CLBP(Conditional Log Break Point) 기능을 이용하여 4011F0~4012FA 루프의 동작 흐름을 살펴보자.

우선 디버기로부터 발생하는 모든 Debug 이벤트를 출력해 보자. OllyDbg를 재실행해서 Go To Expression[CTRL+G] 명령으로 4011F0 주소로 이동한다.

4011F0 주소로 이동

4011F0 주소에 커서를 위치한 후 Conditional Log Break Point[SHIFT+F4] 명령을 내린다.

Condition 항목에 필요한 조건을 입력 (생략 가능)
Explanation과 Expression 항목에는 Log 창에 출력하고 싶은 내용 입력
Pause program 항목은 언제까지 실행할지 선택
Log value of expression 항목은 어떤 상황에 로그를 출력할지를 선택
- Pause program 항목은 ‘Never’ 옵션을 지정하여
프로그램이 끝날 때까지 실행되도록 하였고, Log
value of expression 항목은 ‘Alway’ 옵션을 지정하여
주어진 조건과 상관없이 항상 로그를 출력

CLBP가 설치되면 해당 주소는 분홍색으로 표시되어 일반적인 BP의 붉은색과 구분된다. 그리고 Breakpoints 창의 ‘Active’ 항목에 ‘Explanation’에 기록한 내용이 표시된다.

4011F0 주소에 설치된 Conditional Log Break Point

이 상태로 OllyDbg에 실행 명령을 내리면 DebugMe4.exe가 정상적으로 실행되면서 로그를 출력한다. 출력된 로그를 보면 디버기 프로세스에서 총 3회의 EXCEPTION_DEBUG_EVENT(1)가 발생한 것을 알 수 있다. (로그의 대부분은 LOAD_DL_DEBUG_EVENT(6)이다.)

실행 로그

● 5차 시도

EXCEPTION_DEBUG_EVENT(1)의 경우를 집중적으로 디버깅한다. OllDbg를 재실행하고 4011F0 주소에 설치된 CLBP를 수정한다. ‘Pause program’ 항목을 ‘On condition’ 옵션으로 변경하여 조건에 맞는 경우 프로그램 실행을 멈추도록 한다. 그리고 ‘Log value of expression’ 항목 역시 ‘On condition’ 옵션으로 변경하여 조건에 맞는 경우만 로그를 출력하도록 한다.

○ System Break Point

OllyDbg에서 실행 명령을 내리면 dwDebugEventCode = 1(EXCEPTION_DEBUG_EVENT)의 경우에 4011F0 주소에서 멈추게 된다. 4011FD 주소까지 트레이싱한다.

ExceptionCode 비교

사용되는 메모리는 다음과 같다.

[ESP+68] = [18F9D8] = DEBUG_EVENT.dwDebugEventCode
[ESP+74] = [18F9E4] = DEBUG_EVENT.EXCEPTION_DEBUG_INFO.EXCEPTION_RECODE.ExceptionCode
[ESP+80] = [18F9F0] = DEBUG_EVENT.EXCEPTION_DEBUG_INFO.EXCEPTION_RECODE.ExceptionAddress

현재 디버거 프로세스는 77A0114C(ExceptionAddress) 주소에서 80000003(ExceptionCode - “EXCEPTION_BREAKPOINT”) 예외가 발생했다는 의미이다. 77A0114C 주소의 명령어를 따라가 보면, ntdll.dll 모듈의 ‘System Break Point’인 것을 알 수 있다. 즉, 프로그램을 디버기 모드로 실행시킬 때 무조건 발생하는 예외이다.

System Break Point

typedef struct _EXCEPTION_DEBUG_INFO {
EXCEPTION_RECORD ExceptionRecord;
DWORD dwFirstChance;
} EXCEPTION_DEBUG_INFO, *LPEXCEPTION_DEBUG_INFO;

typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode;
DWORD ExceptionFlags;
struct _EXCEPTION_RECORD *ExceptionRecord;
PVOID ExceptionAddress;
DWORD NumberParameters;
ULONG_PTR ExceptionInformation
[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD;

출처 : MSDN

○ EXCEPTION_ILLEGAL_INSTRUCTION (1)

4011F0 주소에서 다시 실행이 멈춘다. ExceptionCode = C000001D(EXCEPTION_ILLEGAL_INSTRUCTION)이고, ExceptionAddress = 40103F이다. 40103F는 2차 시도에서 확인한 ‘LEA EAX, EAX’명령어가 위치한 주소이다.

40103F 주소에서 EXCEPTION_ILLEGAL_INSTRUCTION 예외 발생

4011F0 주소의 루프에는 3개의 조건 분기 코드가 있다.

004011F0
004011F4
004011F7
004011FD

00401205
0040120B
00401212

00401217
0040121D
...

MOV EAX, DWORD PTR SS:[ESP+68]
CMP EAX, 1
JNZ 004012C0
CMP DWORD PTR SS:[ESP+74], C000001D

JNZ 004012C5
MOV EAX, DWORD PTR SS;[ESP+80]
CMP EAX, 40103F

JNZ 00401299
MOV EAX, DWORD PTR SS:[ESP+10]

; 1) dwDebugEventCode==1

; 2) ExceptionCode == C000001D

;3) ExceptionAddress == 40103F

3가지 조건이 모두 만족되면 40121D 주소의 코드를 실행한다.

첫 번째 EXCEPTION_ILLEGAL_INSTRUCTION 예외가 발생했을 때, 40121D 주소의 코드가 실행되는 것을 확인했다. 따라서 디버기 프로세스의 예외를 처리해서 재실행하는 코드가 나타날 것이라 생각된다.

○ EXCEPTION_ILLEGAL_INSTRUCTION (2)

세 번째 EXCEPTION_DEBUG_EVENT는 401048 주소에서 나타난다. ExceptionCode는 이전과 마찬가지로 EXCEPTION_ILLEGAL_INSTRUCTION이다. 세 번의 조건 분기로 인해 401299 주소로 점프한다. 즉, 두 번째 EXCEPTION_ILLEGAL_INSTRUCTION이 발생하였을 때 401299 주소의 코드가 실행된다는 것을 알 수 있다.

401048 주소에서 EXCEPTION_ILLEGAL_INSTRUCTION 예외 발생

이 상태에서 OllyDbg의 실행[F9]을 하면 자식 프로세스의 메시지 박스가 나타나며 정상적으로 실행되는 것을 확인할 수 있다.

※ 5차 시도에서 알아낸 사실

디버기 프로세스에서 두 번의 EXCEPTION_ILLEGAL_INSTRUCTION 예외가 발생
EXCEPTION_ILLEGAL_INSTRUCTION 예외가 발생한 경우 디버거 프로세스의 40121D, 401299 주소의 코드가 실행

● 6차 시도

DebugMe4.exe의 핵심 코드(40121D, 401299)를 디버깅한다.

○ 40121D (첫 번째 예외)

40121D 주소의 코드를 디버깅해 보자. 401233 주소의 ReadProcessMemory() API 호출 코드는 디버기 프로세스의 401041 주소에서 14바이트 크기만큼 읽어오는 명령이다.

ReadProcessMemory() API 호출

401041 주소의 첫 번째 EXCEPTION_ILLEGAL_INSTRUCTION 예외가 발생하는 40103F 주소 명령(LEA EAX, EAX)바로 다음 주소이다.

ReadProcessMemory() API의 pBaseAddress

ReadProcessMemory() API 호출을 넘기면 ReadProcessMemory() API에서 읽어온 Byte들을 7F와 XOR하는 코드를 발견할 수 있다. 이 XOR은 XOR 디코딩 루프(Decoding Loop)로, 401041~401054 주소를 디코딩하여 정상적인 코드로 변환하는 역할을 한다.

Decidong Loop

Decodeing Code

디코딩 루프에서 디코딩된 코드를 WriteProcessMemory() API를 사용하여 401041~401054 주소에 덮어쓴다. 디버기 프로세스 입장에서는 암호화된 주소영역이 디버거에 의해 복호화된 것이다.

WriteProcessMemory() API

이후에는 메인 Thread의 Context 구조체를 읽어와서 EIP를 변경하는 코드를 확인할 수 있다. 이로 인해 디버기 프로세스의 40103F 주소의 에서 발생한 EXCEPTION_ILLEGAL_INST-RUCTION 예외가 해결된다. (40103F 주소의 LEA EAX, EAX의 명령어는 2byte)

디버기 프로세스의 EIP 변경

변경한 EIP를 SetThreadProcess() API 호출하여 적용한다. 4012D4 주소의 ContinueDebugEvent() API를 호출하여 실행이 중지된 디버기 프로세스를 다시 실행되도록 한다. 이후 4012F2 주소의 WaitForDebugEvent() API를 다시 호출하여 디버기 프로세스의 Debug 이벤트를 기다린다.

40121D 실행 코드 흐름

1. Generate Exception(디버기)

디버기 프로세스의 40103F 주소에서 EXCEPTION_IELLAGER_INSTRUCTION 예외가 발생한다. 이 순간 디버기 프로세스는 실행이 중지되고, 디버거 프로세스에게 제어가 넘어온다.(정확히는 디버거 프로세스에서 호출한 WaitForDebugEvent() API가 리턴된다.)

2. Decoding Loop(디버거)

디버거는 디버기 프로세스의 401041~401054 메모리 영역을 읽어 들여XOR(7F) 명령으로 디코딩한다. 그리고 디코딩된 실제 코드를 디버기 프로세스의 동일한 메모리 영역에 덮어쓴다.

3.Change EIP(디버거)

디버기의 코드 실행 주소(EIP)를 변경(40103F->401041)한다.

4. Countinue Debuggee(디버거)

40103F의 예외를 처리했으므로 디버기 프로세스를 실행하고, 다시 디버거는 디버기의 예외를 기다리는 ‘대기’ 모드로 전환된다.

○ 401299 (두 번째 예외)

두 번째 EXCEPTION_ILLEGAL_INSTRUCTION 예외는 401048에서 발생한다. 401299 주소에서는 401048의 2byte 명령어를 변경(8DC0(LEA EAX, EAX) -> 681C(PUSH XXXX))하는 WriteProcessMemory() API를 호출한다.

WriteProcessMemory() API

이 2byte가 수정되며 그 이후의 명령어도 정상적으로 해석되고, EXCEPTION_ILLEGAL_INSTRUCTION 예외도 해결된다.

401299 실행 코드 흐름

1. Generate Exception(디버기)

디버기 프로세스의 401048 주소에서 EXCEPTION_ILLEGAL_INSTRUCTION 예외가 발생한다.

2. Code Patch(디버거)

디버기 프로세스의 401048~401049 메모리 영역에 ‘681C’를 덮어쓴다.

3. Countinue Debuggee(디버거)

예외가 처리되었으므로 디버기 프로세스를 실행시킨다. 그리고 디버거를 다시 ‘대기’ 모드로 전환한다.

4. 마무리

Debug Blocker 기법은 상당히 까다로운 기법이다. 아주 단순한 형태로 구현된 DebugMe4.-exe파일도 디버깅 설명이 길다. 디버거-디버기 관계를 강제로 끊고 OllyDbg로 Attach 시킨다는 개념만 이해하면 큰 문제없이 디버깅할 수 있을 것이다.

디버깅 실습3 - PE Image Switching 개념 및 동작 원리

xii.xxv — Wed, 31 Jan 2024 20:15:30 +0900

1. PE Image

‘PE Image’(혹은 Process Image나 Image라고 함)란 간단히 말해 ‘PE 파일이 프로세스 메모리에 매핑(mapping)된 모습’이라고 할 수 있다.

PE 파일(notepad.exe)을 프로세스로 실행시키면 그 프로세스의 가상 메모리는 아래 그림과 같은 형태가 된다. 즉, OS는 프로세스를 위한 가상 메모리를 생성하고, USER 메모리 영역에 notepad.exe 파일을 매핑시킨다. 그리고 notepad.exe에 사용되는 Import DLL 파일들(kernel32.dll, user32.dll, gui32.dll 등)을 차례대로 매핑시킨다. 이때, 프로세스의 USER 메모리에 매핑된 Notepad.exe 영역을 (notepad.exe 파일에 대한) PE Image라고 표현한다.

PE 파일과 프로세스 관계

실제 PE 파일과 PE Image 사이에는 형태적으로 아래의 그림과 같이 파이가 발생하는데, 이것은 일반적으로 PE 파일은 File Alignment와 Section Alignment가 다르고, 각 섹션에서의 Raw Data Size와 Virtual Size가 다르기 때문이다.

PE 파일 프로세스 메모리에 매핑된 PE Image

2. PE Image Switching

PE Image Switching은 다른 프로세스를 실행한 후 가상 메모리의 PE Image를 자신의 것과 바꿔버리는 기법이다. 정확히는 어떤 프로세스(A.exe)를 SUSPEND 모드로 실행한 후 전혀 다른 PE 파일(B.exe)의 PE Image를 매핑시켜 A.exe 프로세스 메모리 공간에서 실행하는 기법이다.

PE Image Switching 개념도

PE Image를 변경하면 프로세스 이름은 원본 그래도 A.exe이지만 실제 프로세스 메모리에 매핑된 PE Image는 B.exe이기 때문에 원본(A.exe)과는 전혀 다른 동작을 한다.

이 경우, A.exe를 겉모습만 남아있는 ‘껍데기’ 프로세스라고 말할 수 있고, B.exe를 실제로 실행되는 ‘알맹이’ 프로세스라고 말할 수 있다.

이러한 기법은 PE 프로텍터에서 안티 디버깅으로 쓰이기도 하고, 악성코드에서 정상 프로세스로 위장하고자 할 때 사용된다.

3. 디버깅 실습

- 실행 화면

간단한 예제 파일들(fake.exe, real.exe, DebugMe3.exe)로 확인해 보자.

fake.exe 파일의 실행 화면을 보면 CUI(Console User Interface) 기반의 프로그램인 것을 알 수 있다.

fake.exe 실행 화면

real.exe 파일은 실행 화면은 다이얼로그에 간단한 문자열을 출력하는 GUI(Graphic User Interface) 기반의 프로그램이다.

real.exe 실행 화면

fake.exe와 real.exe 파일은 서로 다른 사용자 환경을 가지고 있다. PE Image Switching 기법을 이용하면 fake.exe를 껍데기 프로세스로 real.exe를 알맹이 프로세스로 실행시킬 수 있다.

DebugMe3.exe 실행 화면

Process hacker로 fake.exe 프로세스를 확인하면 실행되는 프로세스의 이름은 fake.exe이지만 실제로는 real.exe 프로세스가 실행되는 것을 확인할 수 있다.

PE Image Switching 기법으로 실행된 fake.exe

4. 구체적인 동작 원리

OllyDbg로 실행 파라미터(fake.exe real.exe)를 입력하여 DebugMe3.exe를 연다.

OllyDbg의 File \ Open 메뉴

main() 함수 위치로 이동한다.

main() 함수

main() 함수에서 중요한 내용만 추리면 아래의 내용과 같다.

main()
00401000 00401001 00401003 00401006 ... 00401063 ... 00401079 0040107A 0040107E 0040107F 00401081 00401083 00401085 00401087 00401089 0040108B 0040108C 0040108E ... 004010B2 ... 004010D1 ... 004010F0 004010F1 ... 00401116 00401118 00401119 ... 00401149 0040114B 0040114C	PUSH EBP MOV EBP, ESP AND ESP, FFFFFFF8 SUB ESP, 5C CALL 00401150 PUSH EAX LEA ECX, DWORD PTR SS:[ESP+24] PUSH ECX PUSH 0 PUSH 0 PUSH 4 PUSH 0 PUSH 0 PUSH 0 PUSH EDX PUSH 0 CALL DWORD PTR DS:[40900C] CALL 004011D0 CALL 00401320 PUSH ECX CALL DWORD PTR DS:[409038] PUSH –1 PUSH EDX CALL DWORD PTR DS:[409010] MOV ESP, EBP POP EBP RETN	; SubFunc_1() ; -pProcessInfo = 0018FEE8 ; -pStartupInfo = 0018FEF8 ; -CurrentDir = NULL ; -pEnvironment = NULL ; -CreationFlags = CREATE_SUSPENED ; -InheritHandles = FALSE ; -pThreadSecurity = NULL ; -pProcessSecurity = NULL ; -CommandLine = “fake.exe” ; -ModuleFileName = NULL ;CreateProcessW() ; SubFunc_2() ; SubFunc_3() ; -hThread = 00000034(widnow) ; ResumeThread() ; -Timeout = INFINITE ; -hObject = 00000038(window) ; WaitForSinfleObject()

위의 내용을 기반으로 코드 흐름도를 그려보면 아래의 그림과 같다.

main() 함수의 코드 흐름

- SubFunc_1()

SubFunc_1() 함수 내부의 주요 코드를 추리면 아래와 같다.

코드의 내용은 real.exe 파일을 통째로 메모리에 읽어 들이고 있으며, 메모리에 파일 내용을 저장한 뒤 main() 함수로 돌아간다. real.exe 파일이 저장된 메모리 주소를 MEM_FILE_REAL이라고 부르겠다.

SubFunc_1()
00401150 00401151 00401153 00401154 00401155 00401157 0040115C 0040115E 00401160 00401162 00401167 00401168 0040116F	PUSH EBP MOV EBP, ESP PUSH ECX PUSH ESI PUSH 0 PUSH 80 PUSH 3 PUSH 0 PUSH 1 PUSH 80000000 PUSH EAX MOV DWORD PTR SS:[EBP-4], 0 CALL DWORD PTR DS:[409020]	; -hTemplateFile = NULL ; -Attributes = NORMAL ; -Mode = OPEN_EXISTING ; -pSecurity = NULL ; -ShareMode = FILE_SHARE_READ ; -Access = GENERIC_READ ; -FileName = “real.exe” ; CreateFileW()
...
00401185 00401187 00401188 0040118E 00401190 00401191	PUSH 0 PUSH ESI CALL DWORD PTR DS:[409004] MOV EBX, EAX PUSH EBX CALL 00401624	; -pFileSizeHigh = NULL ; -hFile ; GetFileSize() ; -bufsize = A000 (40960) ; new()
...
004011A6 004011A8 004011AB 004011AC 004011AD 004011AE 004011AF 004011B5 004011B6	PUSH 0 LEA ECX, DWORD PRT SS:[EBP-4] PUSH ECX PUSH EBX PUSH EDI PUSH ESI CALL DWORD PTR DS:[40901C] PUSH ESI CALL DWORD PTR DS:[409030]	; -pOverlapped = NULL ; -pBytesRead = 0018FECC ; -ByteToRead = A000 (40960) ; -Buffer = 00392EF8 ; -hFile = 00000030 (window) ; ReadFile() ; -hObject = 00000030 (window) ; CloseHandle()
...
004011C4	RETN

- CreateProcess(“fake.exe”, CREATE_SUSPENDED)

fake.exe 프로세스를 SUSPEND 모드로 생성하는 함수이다. SUSPEND 모드로 생성하는 이유는 프로세스 실행을 멈춘 상태에서 메모리를 조작하기 위함이다.

00401079
0040107A
0040107E
0040107F
00401081
00401083
00401085
00401087
00401089
0040108B
0040108C
0040108E

PUSH EAX
LEA ECX, DWORD PTR SS:[ESP+24]
PUSH ECX
PUSH 0
PUSH 0
PUSH 4
PUSH 0
PUSH 0
PUSH 0
PUSH EDX
PUSH 0
CALL DWORD PTR DS:[40900C]

; -pProcessInfo = 0013FEE8

; -pStartupInfo = 0013FEF8
; -CurrentDir = NULL
; -pEnvironment = NULL
; -CreationFlags = CREATE_SUSPENED
; -InheritHandles = FALSE
; -pThreadSecurity = NULL
; -pProcessSecurity = NULL
; -CommandLine = “fake.exe”
; -ModuleFileName = NULL
; CreateProcessW()

- SubFunc_2()

SubFunc_2() 함수 내부의 주요 코드를 추리면 아래와 같으며, 이 코드가 PE Image Switching 기법의 핵심이다.

SubFunc_2()
004011D0 004011D1	PUSH EBP MOV EBP, ESP
...
0040120C 0040120D 0040120E 00401218	PUSH ECX PUSH EDX MOV DWORD PTR SS:[EBP-2D0], 10007 CALL DWORD PTR DS:[409000]	; -pContext ; -hThread ; GetThreadContext()
...
00401246 0040124C 0040124E 00401250 00401252 00401258 00401259 0040125C 0040125D 0040125E	MOV ECX, DWORD PTR SS:[EBP-22C] MOV EDX, DWORD PTR DS:[ESI] PUSH 0 PUSH 4 LEA EAX, DWORD PTR SS:[EBP=2D4] PUSH EAX ADD ECX, 8 PUSH ECX PUSH EDX CALL DWORD PTR DS:[409018]	; CONTEXT.Ebx = address of PEB ; -pBytesRead = NULL ; -pBytesToRead = 4 ; -Buffer ; -pBaseAddress = PEB.ImageBase ; -hProcess ; ReadProcessMemory()
...
0040128C 0040128F 00401293 00401297 0040129D	MOV EAX, DWORD PTR DS:[EDI+3C] MOV ECX, DWORD PTR DS:[EAX+EDI+34] LEA EAX, DWORD PTR DS:[EAX+EDI+34] CMP ECX, DWORD PTR SS:[EBP-2D4] JNZ SHORT 004012EA	; EDI = MEM_FILE_REAL = Address of IDH ; [EDI+3C] = IDH.e_lfanew ; EAX+EDI = Address of INH ; EAX+EDI+34 = INH.IOH.ImageBase ; ECX = ImageBase of real.exe ; [EBP-2D4] = ImageBase of fake.exe
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; case 1 : ImageBase of real.exe == ImageBase of fake.exe
0040129F 004012A4 004012A9 004012AF 004012B0 004012B6 004012BC 004012BE 004012BF 004012C0	PUSH 40B258 PUSH 40B270 CALL DWORD PTR DS:[409014] PUSH EAX CALL DWORD PTR DS:[409028] MOV EDX, DWORD PTR SS:[EBP-2D4] MOV DCX, DWORD PTR DS:[ESI] PUSH EDX PUSH ECX CALL EAX	; -Name = “ZwUnmapViewOfSection” ; --pModule = “ntdll.dll” ; --GetModuleHandleW() ; -hModule ; GetProcAddress() ; -ProcHandle = Process Handle of fake.exe ; -BaseAddress = ImageBase of fake.exe ; ZwUnmapViewOfSection()
... ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; case 2 : ImageBase of real.exe != ImageBase of fake.exe
004012EA 004012F0 004012F2 004012F4 004012F5 004012F7 004012FA 004012FB 004012FC	MOV EDX, DWORD PTR SS:[EBP-22C] PUSH 0 PUSH 4 PUSH EAX MOV EAX, DWORD PTR DS:[ESI] ADD EDX, 8 PUSH EDX PUSH EAX CALL DWORD PTR DS:[409034]	; Address of PEB (“fake.exe”) ; -pBytesWritten = NULL ; -BytesToWrite = 4 ; -Buffer = ImageBase of “real.exe” ; -Address = PEB.ImageBase ; -hProcess ; WriteProcessMemory()
...
00401311 00401313 00401314	MOV ESP, EBP POP EBP RETN

● fake.exe 프로세스의 실제 매핑 주소 구하기

401218 주소에서 GetTjreadContext() API를 호출하여 fake.exe 프로세스의 메인 스레드 컨텍스트(CONTEXT)를 구한다.

0040120C
0040120D
0040120E
00401218

PUSH ECX
PUSH EDX
MOV DWORD PTR SS:[EBP-2D0], 10007
CALL DWORD PTR DS:[409000]

; -pContext
; -hThread

; GetThreadContext()

fake.exe 프로세스의 메인 스레드 컨텍스트를 구하는 이유는 PEB를 구하기 위해서이다. 프로세스의 실제 매핑 주소는 PEB.ImageBase 멤버에 저장되어 있어서 ReadProcessMemory() API를 호출하여 fake.exe 프로세스의 매핑 주소를 구한다.

00401246
0040124C
0040124E
00401250
00401252
00401258
00401259
0040125C
0040125D
0040125E

MOV ECX, DWORD PTR SS:[EBP-22C]
MOV EDX, DWORD PTR DS:[ESI]
PUSH 0
PUSH 4
LEA EAX, DWORD PTR SS:[EBP=2D4]
PUSH EAX
ADD ECX, 8
PUSH ECX
PUSH EDX
CALL DWORD PTR DS:[409018]

; CONTEXT.Ebx = address of PEB

; -pBytesRead = NULL
; -pBytesToRead = 4

; -Buffer

; -pBaseAddress = PEB.ImageBase
; -hProcess
; ReadProcessMemory()

● real.exe 파일의 ImageBase 구하기

40128C와 40128F 주소의 명령들은 real.exe 파일의 PE 헤더 정보를 읽어서 ImageBase를 구하는 코드이다.

EDI 레지스터 값은 MEM_FILE_REAL 주소로, SubFunc_1()에서 할당받은 메모리 시작 주소이며, real.exe 파일의 내용이 저장되어 있다. 즉, EDI는 real.exe의 PE 헤더를 가리킨다.. 따라서 EDI+3C가 의미하는 것은 IMAGE_DOS_HEADER 구조체의 e_lfanew 멤버이다.

0040128C

MOV EAX, DWORD PTR DS:[EDI+3C]

; EDI = MEM_FILE_REAL = Address of IDH
; [EDI+3C] = IDH.e_lfanew

EAX+EDI = IDH.e_lfanew + Start of PE = IMAGE_NT_HEADERS 구조체가 시작 주소, EAX+EDI+34 = IMAGE_OPTIONAL_HEADER.ImageBase가 멤버를 의미한다.

0040128F

MOV ECX, DWORD PTR DS:[EAX+EDI+34]

; EAX+EDI = Address of INH
; EAX+EDI+34 = INH.IOH.ImageBase

● 비교 : ImageBase of fake.exe & ImageBase of real.exe

fake.exe 프로세스의 실제 매핑 주소와 real.exe 파일의 ImageBase 값을 비교한다.

두 ImageBase 값의 일치 여부에 따라 실행 분기가 달라진다.

00401297

0040129D

CMP ECX, DWORD PTR SS:[EBP-2D4]

JNZ SHORT 004012EA

; ECX = ImageBase of real.exe
; [EBP-2D4] = ImageBase of fake.exe

◎ ImageBase가 같은 경우

이 경우 real.exe의 PE Image가 매핑되려는 주소 400000에 이미 fake.exe의 PE Image가 매칭되어 있다. 그대로 real.exe를 매칭시키면 충돌이 발생하기 때문에 먼저 fake.exe의 PE Image를 언매핑 해야 한다.

ImageBase가 같은 경우

004012BE
004012BF
004012C0

PUSH EDX
PUSH ECX
CALL EAX

; -ProcHandle = Process Handle of fake.exe
; -BaseAddress = ImageBase of fake.exe
; ZwUnmapViewOfSection()

ZwUnmapViewOfSection() API

NTSYSAPI NTSTATUS ZwUnmapViewOfSection(
[in] HANDLE ProcessHandle,
[in, optional] PVOID BaseAddress
);

출처 : MSDN

◎ ImageBase가 다른 경우

fake.exe 프로세스의 가상 메모리 공간에 real.exe의 PE Image를 위해 필요한 공간을 할당하고 real.exe를 매핑시키면 된다. 그리고 fake.exe 프로세스의 PE Image의 주소가 real.exe의 매핑 주소라는 것을 PEB의 ImageBase 멤버를 변경해서 알려줘야 된다.

ImageBase가 다를 경우

004012EA
004012F0
004012F2
004012F4
004012F5
004012F7
004012FA
004012FB
004012FC

MOV EDX, DWORD PTR SS:[EBP-22C]
PUSH 0
PUSH 4
PUSH EAX
MOV EAX, DWORD PTR DS:[ESI]
ADD EDX, 8
PUSH EDX
PUSH EAX
CALL DWORD PTR DS:[409034]

; Address of PEB (“fake.exe”)
; -pBytesWritten = NULL
; -BytesToWrite = 4
; -Buffer = ImageBase of “real.exe”

; -Address = PEB.ImageBase
; -hProcess
; WriteProcessMemory()

- SubFunc_3()

이 함수에서는 real.exe 파일을 fake.exe프로세스에 매핑시키는 코드를 가지고 있다.

매핑은 매핑할 위치에 가상 메모리를 할당하여, fake.exe 프로세스의 PE Header와 PE Section 위치에 real.exe의 PE 정보를 쓴다. 이후 EP를 변경하면 fake.exe 프로세스의 PE Image를 기존의 ‘fake.exe’에서 ‘real.exe’로 변경하는 작업이 완료된다.

● real.exe의 PE Image를 위한 메모리 할당

트레이싱 하다 보면 VirtualAllocEx() API 함수 호출 코드를 만난다. 이 함수의 파라미터에서 할당받고자 하는 메모리의 시작주소(Arg2 = 00400000 ; real.exe의 ImageBase)와 할당받을 메모리 크기(Arg3 = 0000A000 ; real.exe의 SizeOfImage)를 확인할 수 있다. 즉, 이 함수는 fake.exe 프로세스에 real.exe의 PE Image를 위한 메모리 공간을 할당받기 위한 것이다.

VirtualAllocEx() 호출 : real.exe의 PE Image 메모리 할당

● PE Header Mapping & PE Section Mapping

WriteProcessMemory() API를 이용하여 real.exe의 PE 헤더를 VirtualAllocEx() API로 할당받은 메모리 영역에 쓰고 있다.

PE Header 매핑

이후 섹션의 개수만큼 루프를 돌면서 fake.exe 섹션 위치에 real.exe 섹션을 쓴다 이 작업을 마치면 real.exe 파일은 fake.exe 프로세스의 400000(real.exe의 ImageBase) 주소에 완전히 매핑된다.

PE Section 매핑

● EP 변경

현재 fake.exe 프로세스는 SUSPEND 모드로 생성된 상태이다. SUSPEND 모드로 생성된 프로세스가 Resume되면, 가장 먼저 ntdll!RtlUserThreadStart() API(CONTEXT.Eip)를 실행하고, 결국 리턴 값인 EP(Entry Point) 주소(CONTEXT.Eax)로 이동된다. 따라서 fake.exe 프로세스의 PE Image를 ‘real.exe’로 변경했으므로 CONTEXT.Eax를 real.exe의 EP 주소(401060)으로 변경해야 정상 실행이 된다.

SetThreadContext()

- ResumeThread()

마지막으로 ResumeThread()를 호출하여 fake.exe 프로세스를 Resume 시킨다.

; Resume Thread
004010F0 004010F1	PUSH ECX CALL DWORD PTR DS:[409038]	; -hThread = 00000034 (widnow) ; ResumeThread()

real.exe의 PE Image를 가진 fake.exe 프로세스의 실행이 재개된다.

PE Image가 real.exe로 변경된 fake.exe 프로세스

5. 마무리

실습 예제 파일의 디버깅을 통해 PE Image Switching 기법의 동작 원리를 살펴보았다. 이 동작 원리에서는 DebugMe3.exe를 디버깅한 것이다. 디버깅 기법으로 따지면 일반적인 응용 프로그램 디버깅과 다를 게 없다. 리버서 입장에서는 PE Image Switching 기법의 동작 원리도 중요하지만, 그 기법이 적용된 프로세스를 디버깅하는 것에 더 관심이 있을 것이다.

디버깅 실습2 - Self-Creation (JIT 디버깅)

xii.xxv — Tue, 16 Jan 2024 02:29:26 +0900

1. Self-Creation

실행 중에 자기 자신을 자식(Child) 프로세스로 생성시키는 것을 Self-Creation이라고 한다.

Self-Creation 기법

이 파일들은 같은 실행 파일이면서 부모(Parent)로 실행될 때와 자식으로 실행될 때 서로 다르게 동작한다. 즉, 하나의 실행 파일에 두 가지 실행 경로가 존재하는 것이다.

Self-Creation 동작 화면

- 동작 원리

Self-Creation 기법의 동작 원리는 아래 그림과 같다.

Self-Creation 기법 동작 원리

● Create Child Process (SUSPEND mode)

부모 프로세스가 실행되면 main() 함수가 호출되고, main()에서 SUSPEND 모드로 자식 프로세스를 생성한다.

SUSPEND 모드로 생성되면, Import DLL들은 로딩되지만 메인 스레드(Main Thread)가 멈춘 상태가 된다.(‘스레드를 재운다’라고 표현)
메인 스레드는 프로세스가 생성될 때 기본적으로 생성되는 스레드로, EP 코드를 실행시키는 가장 중요한 역할을 수행한다.

따라서 SUSPEND 모드로 실행된 프로세스는 메인 스레드가 멈추면서 EP 코드가 실행되지 못하고 아무런 동작을 하지 못하는 상태가 된다.

● Change EIP

외부의 프로세스의 스레드가 실행할 코드 주소를 임의로 변경하는 것은 디버거-디버기 관계에서 가능하며, 부모 프로세스와 자식 프로세스는 디버거-디버기 관계이다. 디버거는 Debugging API를 이용하여 디버기 프로세스의 코드 실행 위치를 맘대로 변경할 수 있다. 부모 프로세스는 현재 멈춰있는 자식 프로세스의 메인 스레드의 컨텍스트(Context)를 얻어서 EIP 멤버를 원하는 주소 값으로 변경한 후 적용하면 된다.

자식 프로세스의 메인 스레드는 PROCESS_INFORMATION 구조체의 hThread 멤버이다. GetThreadContext() API에 hThread 핸들을 입력하면 스레드 컨텍스트(CONTEXT) 구조체를 얻어낼 수 있다.

PROCESS_INFORMATION 구조체 정의

typedef struct _PROCESS_INFORMATION {
HANDLE hProcess;
HANDLE hThread;
DWORD dwProcessId;
DWORD dwThreadId;
} PROCESS_INFORMATION, *PPROCESS_INFORMATION, *LPPROCESS_INFORMATION;

출처 : MSDN

EIP는 CONTEXT 구조체의 Eip 멤버이다(EIP 레지스터 의미). 이 값을 ChildProc()함수 주소로 변경하면 된다.

[ctx.Eip = (DWORD)ChildProc;]

WOW64_CONTEXT 구조체 정의

typedef struct _WOW64_CONTEXT {
DWORD ContextFlags;
DWORD Dr0; //04h
DWORD Dr1; //08h
   DWORD Dr2;    //0Ch
   DWORD Dr3;    //10h
   DWORD Dr6;    //14h
   DWORD Dr7;    //18h

   WOW64_FLOATING_SAVE_AREA FloatSave;

   DWORD SegGs;    //88h
   DWORD SegFs;      //90h
   DWORD SegEs; //94h
   DWORD SegDs; //98h

   DWORD Edi; //9Ch
   DWORD Esi; //A0h
   DWORD Ebx;    //A4h
   DWORD Edx;    //A8h
   DWORD Ecx;    //ACh
   DWORD Eax;    //B0h

   DWORD Ebp;    //B4h
   DWORD Eip;       //B8h
   DWORD SegCs; //BCh
   DWORD EFlags; //C0h
   DWORD Esp;    //C4h
   DWORD SegSs; //C8h

   BYTE ExtendedRegisters[WOW64_MAXIMUM_SUPPORTED_EXTENSION];
} WOW64_CONTEXT;

출처 : MSDN

그리고 SetThreadContext() API를 호출하여 새로 변경된 CONTEXT 구조체를 자식 프로세스의 메인 스레드에 세팅하고 ResumeThread() API를 호출하면 자식 프로세스의 메인 스레드가 깨어나면서 변경된 EIP(=실행할 코드 주소=ChildProc())를 실행한다. 스레드 컨텍스트를 변경하는 것이 핵심이다.

● Resum Main Thread

자식 프로세스의 멈춰져 있는 메인 스레드를 실행(‘스레드를 깨운다’라고 표현)

이제 메인 스레드는 변경시킨 코드 주소를 실행한다.

2. 디버깅 실습

- 고려 사항

Self-Creation 기법의 디버깅에서 고려할 사항은 디버깅 중에 개로 생성되는 자식 프로세스를 어떻게 시작 시점부터 디버깅할 수 있는지이다.

부모 프로세스를 디버깅하여 자식 프로세스의 EP가 어느 주소로 변경되는지를 확인
‘무한 루프 설치 방법’ 또는 JIT(Jump-In-Time) 디버깅 방법 사용

SUSPEND 프로세스
Q. 실습 예제에서는 SUSPEND 모드로 자식 프로세스를 생성시키고, 메인 스레드의 EIP를 변경시키는 방식이 사용되었다. 부모 프로세스를 디버깅 중 자식 프로세스가 생성된 순간 다른 디버거로 Attach하면 안 되나?

A. 디버거는 Suspended 프로세스를 Attach할 수 없다. 디버거의 Attach 대상 프로세스 목록에 아예 나타나지 않을 것이며, 메인 스레드가 깨어난 상태(Resume)가 되어야 목록에서 확인될 것이다.

- JIT 디버깅

JIT(Jump-In-Time) 디버깅은 실행 중인 프로세스에 예외(Exception)가 발생했을 때 OS에서 자동으로 지정된 디버거를 실행하여 해당 프로세스에 Attach해주는 것이다.

JIT 디버깅은 주로 애플리케이션 개발 과정에서 사용되며, Visual C++을 JIT 디버거로 설정하여 예외가 발생한 소스코드를 직접 확인하는 데 사용된다(소스코드를 가지고 있는 경우).

● JIT 디버거 설정

OllyDbg에는 ‘Options - Just-in-debugging’ 메뉴에 자신을 JIT 디버거로 등록시키는 기능이 있다.

Just-in-time debugging 메뉴

이후 다이얼로그에서 ‘Make OllyDbg just-in-time debugger’ 선택

Just-in-time 디버깅 다이얼로드 설정 전/후

OllyDbg는 JIT 디버거로 등록되었으며, 현재 시스템에서 설정된 JIT 디버거는 아래 레지스트리의 키에서 확인 가능하다.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

64bit 환경에서는 JIT 설정이 안 된다. 32bit 환경에서 실습 진행하는 것을 추천

OllyDbg JIT 설정 시 regedit (64bit / 32bit)

- 실습 예제 파일(DebugMe2.exe) 디버깅

실습 예제 파일의 디버깅 목표는 자식 프로세스의 (새로운)EP 코드로부터 정확히 디버깅을 하는 것이다.

Self-Creation 기법은 자기 자신을 자식 프로세스로 실행하면서 시작되는 코드(EP code) 위치를 변경하기에 먼저 부모 프로세스를 디버깅하여 자식 프로세스의 시작 코드 주소를 얻어야 한다. 그리고 JIT 디버깅 방법으로 자식 프로세스를 디버깅하면 된다.

● 부모 프로세스 디버깅

OllyDbg로 DebugMe2.exe를 열어 main() 함수까지 진행한다.

JIT 디버거로 등록된 OllyDbg

트레이싱을 하다 보면 CreateProcess() API 호출 코드(401102)가 보이는데 이 코드가 실행되면 SUSPEND 모드의 자식 프로세스가 생성된다.

CreateProcess() 호출 코드 및 파라미터 값

디버깅을 진행하면 GetThreadContext()/SetThreadContext() API 호출 코드가 나타난다. 이 코드에서 자식 프로세스의 메인 스레드 컨텍스트(CONTEXT) 구조체를 구하여 CONTEXT.Eip 값을 ChildProc() 주소로 변경한다.

CONTEXT 구조체의 시작 주소는 GetThreadContext()/SetThreadContex() API의 두 번째 파라미터를 확인하면 알 수 있다.

CONTEXT 구조체의 시작 주소(18FA68)에서 B8h만큼 떨어진 곳에 EIP(18FA68+B8h=18FB20)가 존재한다. EIP 변경 주소는 401186주소에서 401000인 것을 확인할 수 있다.

CONTEXT.Eip 변경 코드

이후는 ResumeThread(pi.hThread) API를 호출하여 자식 프로세스의 메인 스레드를 시작시키고, WaitForSingleObject(pi.hProcess, INFINITE) API를 호출하여 자식 프로세스가 종료할 때까지 기다리는 상태가 된다.

ResumeThread(pi.hThread) API 호출

WaitForSingleObjevt(pi.hProcess, INFINITE) API 호출

● 자식 프로세스 디버깅

Stud_PE 유틸리티를 이용하여 401000 주소(VA : Virtual Address)를 파일 옵셋(Offset)으로 변환하면 400이 나온다.

Stud_PE 유틸리티의 RVA <=> RAW 기능

HxD 유틸리티로 파일 옵셋 400 위치의 한 바이트를 0xCC로 변경(원본 값 : 0x6A)한 후 저장한다.

HxD 유틸리티로 400 파일 옵셋 값을 0xCC로 변경

0xCC는 INT3 명령어(Break Point)를 의미한다. 즉, 파일 옵셋 0x400(VA의 401000)의 0xCC 코드가 실행되면, EXCEPTION_BREAKPOINT 예외가 발생하게 된다.

예외 발생 다이얼로그

현재 시스템에 JIT 디버거가 등록되어 있으므로 ‘Debug’를 선택하면 등록된 디버거에 Attach되어 해당 부분부터 디버깅이 가능하다.

0xCC가 설치된 ChildProc() 함수

401000 주소의 0xCC를 원래 코드(0x6A)로 되돌린다.

원본 코드(0x6A)로 변경

이제 전상 코드 상태에서 디버깅을 진행하면 된다.

원본 ChildProc() 함수

3. 마무리

JIT 디버깅의 기본 개념은 서비스 디버깅의 ‘무한 루프 설치’ 방법과 매우 유사하다.

유용한 디버깅 기법들이므로 까다로운 프로세스의 디버깅에 사용하면 좋다.

리버싱 핵심원리 - 디버깅 실습2_업로드용.pdf

0.61MB

문자열 인코딩 개념 정리- ASCII / ANSI / EUC-KR / CP949 / UNICODE / UTF-8

xii.xxv — Wed, 10 Jan 2024 20:00:03 +0900

1. ASCII (American Standard Code for Information Interchange)

ASCII는 최초의 문자열 인코딩
7bit로 구성
영어를 위한 문자, 숫자, 특수문자, 기호 등 128개 문자를 표현 (2^7 == 128)
영어를 위한 문자(American Standard Code)이기 때문에 다른 언어는 표현이 불가능

2. ANSI (American National Standard Institute)

ANSI는 ASCII의 확장판 느낌으로 영어 이외의 다른 언어를 지원할 목적으로 만들어짐
8bit로 256개의 문자를 표현
앞의 7bit는 ASCII와 동일하며, 뒤의 1bit로 다른 언어의 문자표를 의미
각 언어별로 Code 값을 가짐 - CodePage
ANSI = ASCII(7bit) + CodePage(1bit)

3. EUC-KR (Extended Unix Code-Korea)

한글 지원을 위해 유닉스 계열에서 나온 완성형 코드 조합
완성형 코드 - 완성된 문자 하나하나에 코드 번호를 부여한 것
반대의 개념, 조합형 코드 - 자음과 모음 각각에 코드 번호를 부여하여 초성, 중성, 종성을 조합하여 하나의 문자를 나타내는 방식
2Byte로 하나의 문자를 표현
한글 단어 2350자만 사전순으로 배열하여 모든 한글 단어를 표현하기에 역부족

4. CP949 (Code Page 949)

한글 지원을 위해 윈도우즈 계열에서 나온 환장 완성형 코드 조합
2Byte로 하나의 문자를 표현
EUC-KR이 사용하지 않는 나머지 바이트열을 활용하여 대부분의 한글 단어를 표현 가능
EUC-KR의 확장이므로 호환되며, EUC-KR에서 표현되지 않는 문자는 조합하여 표현
949는 한국 페이지 번호를 의미
MS949, Windows-949라 부르기도 함
윈도우 메모장에서 ANSI 인코딩으로 저장하면 CP949 방식에 의해 인코딩 된다.

◎ UNICODE
- 전 세계의 모든 문자를 컴퓨터에서 일관되게 표현할 수 있도록 고안된 코드 조합
- 전 세계의 기기들이 통일된 인코딩 방식을 사용할 수 있도록 하기 위해 고안
- 2byte 숫자로 1:1 매핑시키는 ‘방식’
(유니코드를 표현하는 여러 가지 인코딩 방식들이 존재)
- UTF-8, UTF-16, UTF-32 등은 유니코드 기반의 문자들을 바이트열에 인코딩하는 방식

유니코드는 전 세계 문자들 각각에 맵핑된 코드들을 담고 있는 거대한 표이며, UTF-8 등의 인코딩 방식은 그러한 유니코드 표를 바탕으로 문자들을 바이트열에 표현하는 방식이라 생각

5-1. UTF-8 (Unicode Transformation Format - 8bit)

유니코드를 위한 가변 길이 문자 인코딩(멀티바이트) 방식 중 하나
ANSI의 단점 보완을 목적으로 만들어짐
멀티바이트 개념을 사용하여 하나의 Character Set에 거의 모든 문자를 넣음
ANSI는 다국어를 지원하기 위해 CodePage 정보를 미리 알고 있어야 한다.
멀티바이트란 표현해야 하는 문자에 따라 글자 크기를 가변으로 변경하여 사용하는 것
멀티바이트(1~4bytes)로 최대 1,112,064자를 표현 가능
ANSI는 고정바이트(1byte) 형태로 최대 256자 표현 가능
첫 128자는 ASCII 코드 값으로 ANSI와 UTF-8이 동일
영어를 사용할 경우 1byte만 사용, 중동지역 언어 또는 많은 유럽 언어가 2bytes, 한국 중국, 일본 등 동아시아권 언어는 3bytes이상을 사용

5-2. UTF-16

16bit 기반으로 저장하는 UTF-8의 변형
자주 사용하는 문자는 2byte, 그렇지 않은 문자는 4byte로 표현
한글의 경우, UTF-16으로 저장하면 2bytes면 되어 용량의 이점이 있다.
UTF-8로 저장하면 3bytes가 필요
경우에 따라서는 2bytes 이상을 사용할 경우도 있어 큰 이점은 아니다.
Byte Ordering을 고려함에 따른 복잡성 증대와 ANSI와 호환이 안 되는 단점이 있다.
Byte Ordering은 데이터가 저장되는 순서로, Rettle Endian과 Big Endian 방식이 있다.

5-3 UTF-32

모든 문자를 4byte의 고정 길이로 인코딩
코드 변형 규칙이나 가변 길이에 대한 특별한 고려를 하고 싶지 않을 때, 일관성 있고 단순한 방식으로 문자열을 처리할 수 있다는 장점
하나의 문자를 저장하는데 너무 많은 저장 공간이 사용되고 Byte Ordering을 고려함해야 하는 문제가 있어 자주 사용되지 않는다.

Advanced 안티 디버깅

xii.xxv — Wed, 10 Jan 2024 15:29:18 +0900

1. 가비지 코드

의미 없는 코드를 대량으로 추가시켜 디버깅을 힘들게 만드는 기법

중간 중간에 진짜 의미 있는 고드를 섞어 버리거나 다른 안티 디버깅 기법을 혼합해서 사용하면 디버깅이 매우 힘들다.

정교하고 복잡한 형태의 가비지 코드는 수많은 조건 분기와 끝없이 이어지는 함수 호출로 인하여 건너뛰기도 쉽지 않다.

2. Breaking Code Alignment

IA32-Instruction을 잘 이해한 상태에서 정교하게 어셈블리 프로그래밍을 하면, 디버거의 디스어셈블 과정에 혼란을 줄 수 있다.

즉, 디스어셈블리 코드가 깨진 것처럼 보인다.

코드 사이에 (정교하게 계산된) 불필요한 코드를 삽입시켜 디스어셈블리 코드의 가독성을 떨어뜨리는 것이 ‘Breaking Code Alignment’ 기법

사람이 파악하기 어렵게 뒤죽박죽 섞어 놓은 코드를 난도화 코드(Obfuscated Code)

가비지 코드와 Breaking Code Alignment 기법을 잘 조합하여 사용하면 훌륭한 Obfuscated Code를 생성할 수 있다.

3. Encryption / Decryption

암호화/복호화 기법은 프로그램의 코드와 데이터를 숨기기 위해 패커/프로텍터에서 자주 사용되는 기법

정상적인 코드를 암호화시키는 행위를 인코딩(Encoding), 암호화된 코드를 복호화시키는 행위를 디코딩(Decoding)이라고 한다.

-1. 간단한 디코딩 코드

디코딩의 경우 프로그램 내에서 복호화 과정을 완료해야 정산적인 코드가 나타난다.

안티 덤프 기법의 하나로써 복호화한 정상 코드를 실행시킨 이후에 다시 암호화하는 기법이 있다. 실행 중인 프로세스의 메모리 코드를 덤프해도 암호화된 코드만 보이게 된다.

-2. 복잡한 디코딩 코드

복잡한 디코딩 코드의 경우 가비지 코드가 포함되는 등의 형태로 복잡한 디코딩 코드가 이루어진다.

트레이싱을 하다 보면 패턴이 눈에 들어오고 이 코드가 디코딩 루프라는 것을 알게 되면서 유효 명령어를 뽑아낼 수 있다.

-3. 특수한 경우 - 코드 재조합

어떤 프로텍터들은 코드의 가독성을 떨어뜨리고 트레이싱을 어렵게 하기 위해서 실행코드를 실시간으로 재조합하는 경우가 있다.

코드 실행 직전 코드에서 레지스리에 접근하여 SUB/ADD/XOR 등의 명령어를 사용하여 이후의 코드를 변경한다. 변경된 코드. 즉, 새로운 코드를 재생성하여 실행한다.

다른 장점은 사용자가 만약 디코딩되는 위치에 software BP를 설치했을 때, 실행 에러를 발생킨다. (BP가 설치된 영역은 CC로 패치가 되어 전혀 다른 계산 결과가 나오기 때문 - OllyDbg의 경우, Software BP가 설치된 주소의 내용을 보호해서 새로운 값으로 쓰지 못하게 한다.)

4. Stolen Bytes(Remove OEP)

원본 코드의 일부(주로 OEP코드)를 패커/프로텍터가 생성한 메모리 영역으로 옮겨서 실행

장점은 프로세스 메모리 덤프 시 OEP 코드의 일부분이 없어 정상 실행 불가(Anti-Dump 기법)

Stolen Bytes가 적용된 파일을 다른 패커/프로텍터로 압축 시 리버서에게 혼란을 준다. (언팩의 성공여부를 의심하게 됨)

프로텍터의 종류에 따라 다양한 형태의 실행이 존재한다. Stolen Bytes 실행 후 메모리에서 제거하는 경우도 있다.(메모리 할당 - Stolen Bytes 코드 복호화 - 실행 - 메모리 해제)

5. API 리다이렉션(Redirection)

디버깅 시 흐름을 대략적으로 빨리 파악할 수 있는 좋은 방법은 주요 Win32 API(파일, 레지스트리, 프로세스, 네트워크 등)에 BP를 설치하는 것

BP 설치 후 실행하면 BP를 설치한 API가 호출된 후 멈춘다. 이때 스택에는 리턴주소가 저장되어 그 주소부터 디버깅을 하면 효과적으로 핵심 코드에 다가갈 수 있다.

이런 디버깅 노하우를 회피하는 기법이 API Redirection이다.

프로텍터는 주요 API들의 전체코드 혹은 일부를 다른 메모리 영역으로 복사 그리고 보호 대상 프로그램의 코드를 분석하여 해당 API를 호출하는 코드를 패치시켜 자신이 복사해둔 API코드가 실행되도록 한다. 따라서 원본 API 주소에 BP를 설치해도 소용이 없다.(추가적인 Anti-Dump기법)

- 다른 메모리로 복사해 둔 코드는 같은 결국 같은 API를 가리킨다.(dll파일의 API 주소를 가리킴)

또한 Opcode ‘FF15’로 간접호출을 하던 원래완 다르게 ‘8E’로 직접호출을 하면서 남은 1바이트가 뒤로 밀리게 된다.(Breaking Code Alignment 기법이 이루어짐)

※ ASProtect의 난독화 코드 생성기에 의해서 그때그때 새로운 가비지 코드가 생성돼서 주소로 이동할 때마다 코드의 모양이 달라진다. 이렇게 같은 결과를 내는 다른 모양의 코드를 다형성 코드(Polymorphic Code)라고 한다.

API Redirction 기법은 구조상 API Hooking과 비슷한 면이 많다. 둘의 차이점은 목적. API Redirection은 디버깅을 어렵게 만드는 것이 목적이고, API 후킹은 API 호출 전/후에 추가적인 기능을 제공하는 것이 목적

6. Debug Blocker(Self Debugging)

자신을 디버깅 모드로 실행시키는 기법

동일한 프로세스를 부모/자식 구조로 실행하는 것으로 디버거/디버기 관계가 되는 것

파일이 실행되면 자신의 실행 파일을 찾아서 DEBUG 모드로 실행

자기 자신을 자식 프로세스로 실행시키는 Self Creating 기법의 발전 형태.
Self Creating 기법에서 실제 원본 코드의 실행은 자식 프로세스에서 담당, 부모 프로세스는 자식 프로세스의 생성, 메모리(코드/데이터) 변경, EP 주소 변경 등의 작업을 수행
→ 부모 프로세스만을 디버깅해서는 OEP로 갈 수 없다.
→ 디버거를 자식 프로세스에 Attach시키는 디버깅 방법으로 무력화된다는 단점이 있으며, 이 단점을 보완한 것이 Debug Blocker 기법이다.

Debug Blocker 기법의 장점은 두 가지(목적 관점에서)

1. 디버깅 방지

실제 원본 코드를 실행하는 자식 프로세는 이미 디버깅 중이므로 원칙적으로 다른 디버거를 Attach할 수 없다. (디버깅하는 방법은 디버깅 실습 참고)

2. 자식(Debuggee) 프로세스를 제어(Control) 할 수 있다.

디버거-디버기 관계에서 디버거는 막강한 권한을 가지고 있다. 즉, 디버기 프로세스의 예외를 처리하고 실행 흐름을 제어하는 등의 작업을 수행할 수 있다. 이로 인해 디버깅이 까다로워진다.

→ 디버기에 발생항 예외에 대한 우선 처리권은 디버거에게 있다. 따라서 자식(Debuggee) 프로세스를 디버깅하기 위해서는 기존 디버거의 연결을 끊어야 하는데, 그러면 자식 프로세스는 정상적인 실행이 불가능해진다.

Debug Blocker 기법에서 발전된 ‘Nanomite’ 기법
1. 디버기 프로세스의 내부 코드에서 Jcc 명령어를 전부 INT3(0xCC) 명령어(SWBP) 또는 기타 예외를 발생시키는 코드로 패치한다.
2. 패치시킨 Jcc 명령어의 실제 주소 위치와 점프할 주소를 디버거 내부에 테이블 형태로 가지고 있다가 기버기에서 패치된 명령이 실행되면 예외가 발생하여 디버거에게 제어권이 넘어오면, 예외가 발생한 주소를 이용해 테이블에서 점프해야 할 주소를 얻어서 디버기에게 알려준다.

‘Nanomite’ 기법을 제대로 디버깅하기 위해서는 패치된 코드를 원본과 똑같이 복구시켜야 된다.
일일이 수작업하기에는 너무 힘들기에 복구 작업의 많은 부분을 자동화해야 된다. 어느 정도의 프로그래밍 센스와 노하우가 필요하며 따라서 디버깅 난이도가 매우 높다.

Dynamic 안티 디버깅

xii.xxv — Wed, 10 Jan 2024 15:13:45 +0900

내부 코드와 데이터를 리버싱으로부터 감추고 보호하는 것이 목적으로, PE 프로텍터들에서 많이 사용된다.

원본 프로그램의 핵심 알고리즘을 보호하기 위해 사용

디버거로 프로그램을 실행할 수 있을지언정 원본 프로그램의 핵심 코드(OEP)를 트레이싱으로 찾지 못하도록 방해

1. 예외(Exception)

안티 디버깅의 단골 메뉴

예외가 발생하면 일반 실행은 SEH(Structured Exception Handling) 메커니즘에 의해 처리되고, 디버깅 중이면 디버거가 예외 처리를 담당한다. 이 특징을 이용해서 정상 실행 경우와 디버깅당하는 경우를 판별해서 서로 다른 동작을 수행할 수 있는 안티 디버깅 기법.

-1. SEH(Structured Exception Handling)

SEH의 대표적인 예외

EXCEPTION_DATATYPE_MISALIGNMRNT
EXCEPTION_BREAKPOINT
EXCEPTION_SINGLE_STEP
EXCEPTION_ACCESS_BIOLATION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_ILLEGAL_INSTRTUCTION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_ARRAY_BOUNDS_EXCEEDED
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLR_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERATION
EXCEPTION_FLT_STACK_CHECK
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_INT_DIVIDE_BY_ZERO
EXCEPTION_INT_OVERFLOW
EXCPETION_PRIV_INSTRUCTION
EXCEPTION_STACK_OVERFLOW

(0x80000002)
(0x80000003)
(0x80000004)
(0xC0000005)
(0xC0000006)
(0xC000001D)
(0xC0000025)
(0xC0000026)
(0xC000008C)
(0xC000008D)
(0xC000008E)
(0xC000008F)
(0xC0000090)
(0xC0000091)
(0xC0000092)
(0xC0000093)
(0xC0000094)
(0xC0000095)
(0xC0000096)
(0xC00000FD)

가장 대표적인 예외는 BP(Break Point)

SEH에 Static 안티 디버깅을 삽입하여 프로그래밍 디버깅 중인지를 판단해 EIP를 변경하는 코드로 실행된다.

SS:[ESP+C] : SEH+C == 세 번째 파라미터 CONTEXT *pContext 구조체 포인터

DS:[EAX+B8] : pContext→Eip

회피 방법 - 디버거 프로그램의 INT3 예외를 무시하고 자체 SEH에서 처리되도록 옵션 설정

가끔 INT3 명령어를 트레이싱 중 디버거가 꼬이면서 비정상 종료가 되는 경우가 있다. 이 때는 SEH와 정상실행코드(SEH에서 지정해준 EIP)에 BP 설치 후 실행하면 된다.

- 디버깅 실전에서 매우 자주 사용된다.

-2. SetUnhandledExceptionFilter()

SEH에서 예외 처리가 되지 않았거나 등록된 SEH가 없을 경우, kernel32!UnhandledExceptionFilter() API가 호출된다. 이 함수 내부에서 Top Level Exception Filter(혹은 Last Exception Filter)라 불리는 시스템의 마지막 예외처리기를 실행 (마지막 예외처리기는 ‘작동이 중지되었습니다.’ 경고창을 띄운 후 종료)

kernel32!UnhandledExceptionFilter() 내부에서 Static 안티 디버깅 기법인 ntdll!NtQueryInformaionProcess(ProcessDebugPort) API를 호출하여 디버깅 여부 판별

→일반 실행이면 시스템 예외처리기에 넘기고, 디버깅 중이면 디버거에게 넘긴다.

SetUnhandledExceptionFilter() API

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter(
[in] LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
);

출처 : MSDN

kernel32!SetUnhandledExceptionFilter() API를 이용하면 시스템의 마지막 예외처리기(Top Level Exception Filter)를 변경할 수 있다.

lpTopLevelExceptionFilter 파라미터에 새로운 Top Level Exception Filter 함수 주소를 넘기면 된다.(SetUnhandledExceptionFilter() API의 파라미터/리턴값은 이전 Last Exception Filter 함수 주소)

안티 디버깅 기법은 고의로 예외를 발생시켜 새로 등록한 Last Exception Filter 내에서 일반 실행과 디버깅 실행을 판단하여 EIP 값을 변경 시킨다.

회피 방법 - SetUnhandledExceptionFilter() API를 이용한 안티 디버깅 기법은 Static & Dynamic 기법이 혼합된 형태이다.

1. Static 기법인 kernel32!UnhandledExceptionFilter() 내부에 호출되는 ntdll!ZwQueryInformationProcess() API를 (API 후킹 등의 방법으로) 무력화한다.

2. SetUnhandledExceptionFilter() API 호출에 의해 등록된 Exception Filter를 따라가서 정상 실행인 경우 어느 주소로 분기하는지 확인

2. Timing Check

트레이싱을 할 때 일반 실행보다 오래 걸리는 특성을 활용한 안티 디버깅 기법으로 실행 시간의 차이를 측정하여 디버깅 여부를 판별하는 기법

Timing Check 기법은 단순한 원리에 단순한 회피 기법을 가지고 있지만 보통 다른 안티 디버깅 기법들과 같이 사용되며 회피하는 것이 까다로울 수 있다.(특히 코드가 명확하게 눈에 보이지 않는 경우)

안티 에뮬레이팅(Anti-Emulation) 기법으로도 많이 사용된다. 에뮬레이터로 실행하면 일반 실행의 속도보다 훨씬 느리게 실행되기 때문에

시간 간격 측정 방법

1. Counter based method

RDTSC
kernel32!QueryPerformanceCounter
kernel32!GetTickCount()

2. Time based method

timeGetTime()
_ftime()

CPU의 (Counter)를 이용하는 방법과 시스템의 실제 시간(Time)을 이용하는 두 가지 방법이 있다.

-1. RDTSC(Read Timp Stamp Counter)

x86 CPU에는 TSC(Time Stamp Counter)라는 64비트 레지스터가 존재

CPU는 매 순간 Clock Cycle을 카운트하여 TSC에 저장

RDTSC(ReaD Time Stamp Counter)는 그 TSC의 값을 EDX:EAX 형식으로 읽어오는 어셈블리 명령어 (상위 32bit - EDX, 하위 32bit - EAX)

회피 방법 -

1. 트레이싱하지 말고 RUN으로 해당 코드 넘기기 (BP 설치 후 RUN))

2. 두 번째 RDTSC 결과 값(EDX:EAX) 조작 (첫 번째 값과 비슷하게 조작하여 CMP 넘기기)

3. 조건 분기 명령어(CMP/Jcc) 실행을 조작 (Flags 값을 강제로 변경)

Jcc 명령어는 CF(Carry Flag)와 ZF(Zero Flag)의 영행을 받는다.

JA 명령어는 CF와 ZF가 모두 0인 경우 점프

4. 커널 드라이버를 이용하여 RDTSC 명령을 무력화 (커널 모드 드라이버를 이용해 원천젓으로 무력화시킬 수 있다. Olly Advanced PlugIn에 이러한 기능이 탑재되어 있다.)

실제로는 RDTSC 명령어나 CMP/Jcc 조건 분기 명령어들이 눈에 잘 보이지 않도록 교묘히 배치한다. 또한 다른 안티 디버깅(SEH, Static Method) 기법들과 조합되어 매우 강력한 힘을 발휘

3. Trap Flag

Trap Flag(TF)란 EFLAGS 레지스터의 9번째(Index 8) 비트

-1. Single Step

TF를 1로 세팅하면 CPU는 Sing Step 모드로 변경

CPU는 Single Step 모드에서 하나의 명령어를 실행 후 EXCEPTION_SINGLE_STEP 예외를 발생

이후 TF는 자동으로 최기화(0)

EXCEPTION_SINGLE_STEP 예외는 SEH 기법과 결합하여 디버거를 탐지하는 안티 디버깅 기법으로 사용

회피 방법 - EXCEPTION_SINGLE_STEP 예외를 디버기에서 직접 처리하도록 OllyDbg의 옵션을 변경 (EXCEPTION_SINGLE_STEP 예외 무시)

-2. INT 2D

INT 2D는 본래 커널 모드에서 작동하는 Break Point 예외를 발생시키는 명령어로 유저 모드에서도 예외를 발생시킨다.

디버깅 실행의 경우 무시하고 넘어간다.

INT 2D 명령어 디버깅 시 특징
1. 1바이트 무시
- 디버깅 모드에서 INT 2D를 실행(혹은 StepInto/StepOver)하면 다음 명령어의 첫 바이트는 무시되고, 그다음 바이트부터 새로운 명령어로 인식하여 실행 → 전혀 다른 명령어를 실행하는 셈
- INT 2D 기반의 안티 디버깅 기법은 일종의 Obfuscated Code 효과를 보여준다.
- 이런 식의 Code Byte Ordering을 변경해서 프로그램의 코드를 혼란스럽게 만드는 것은 Code Obfuscating 기법이라고 하며, Dynamic 안티 디버깅 기법으로 자주 사용된다.
2. BP까지 그대로 실행
- INT 2D 명령을 Trace하면, 그 다음 명령어 시작에서 멈추지 않는다.
- OllyDbg만의 특징이며, 디버거 별로 동작이 조금씩 다르게 나타난다.
- INT 2D 실행 과정에서 발생한 Code Byte Ordering이 깨지는 문제때문(일종의 버그)

회피 방법 - 실전에서는 SEH를 반드시 따라가서 코드를 한 줄씩 디버깅해야 하는 경우가 있다.

TF를 사용하여 SEH로 쉽게 가는 방법
1.   EXCEPTION_SINFLE_STEP 예외를 무시하는 디버거 옵션 설정
2.   SEH에 BP 설치
3.   INT 2D 명령어 실행 전에 TF를 1로 세팅 (Single Step 예외를 사용)
4.   두 번 Trace (kernel 명령어이기 때문에 User 모드 디버거에서는 정상적인 명령으로 인식되지 않음)
5.   SEH의 BP에 멈추고, TF = 0으로 변경됨

4. 0xCC Detection

Software BP(0xCC) 탐지

BP는 Opcode의 0xCC로 사용되지만, 프로세스 메모리의 코드 영역에서 단순히 0xCC를 검색하기에는 Displacement, Immediate, 데이터, 주소 등으로 사용될 수 있기 때문에 정확성이 매우 떨어진다.

-1. API Break Point

원하는 기능만 빠르게 디버깅하는 방법 중 하나는 해당 프로그램이 사용할 만한 API에 BP를 설치 후 실행하는 것이다. 만약 해당 BP에서 멈추면 저장된 복귀 주소(Return Address)를 확인해서 복귀 주소로 따라가 그 부분을 디버깅하는 식 → 디버깅 범위를 줄일 수 있다.

이와 같은 API에 설치된 BP를 확인해서 디버깅을 판단 (API 코드의 첫 바이트가 CC인지 검사)

리버서가 관심을 가지는 API 리스트
[프로세스]
CreateProcess CreateThread EunmProcesses CreateToolhelp32Snapshot ShellExecuteA	CreateProcessAsUser GetThreadContext EnumProcessModules Process32First WinExec	CreateRemoteThread SetThreadContext OpenProcess Process32Next TerminateProcess
[메모리]
ReadProcessMemory VirtualAllocEx VirtualQuery	WriteProcessMemory VirtualProtect VirtualQueryEx	VirtualAlloc VirtualProtectEx
[파일]
CreateFile CopyFile MeveFile FindNextFile GetSystemDirectory SetFilePointer MapViewOfFileEx _write _tell	ReadFile CreateDirectory MoveFileEx GetFileSize GetFileAttributes CreateFileMapping UnmapViewOfFile _read	WriteFile DeleteFile FindFirstFile GetWindowsDirectory SetFileAttributes MapViewOfFile _open _lseek
[레지스트리]
RegCreateKeyEx RegEnumKeyEx RegSetValueEx	RegDeleteKey RegQueryValueEx	RegDeleteValue RegSetValue
[네트워크]
WSAStartup closedocket htons recv HttpSendRequst InternetConnet InternetOpenUrl	socket getservbyname connet send HttpQueryInfo InternetGetConnetedState InternetReadFile	inet_addr gethostbybname inet_htoa HttpOpenRequest InternetCloseHandle InernetOpen URLDownloadToFile
[기타]
OpenProcessToken OpenSCManager ControlService SetServiceStatus OpenMutex GetProcAddress OutputDebugString	LookupPrivilegeValue CreateService DeleteService QueryServiceStatusEx FindWindow GetModuleFileNameA ...	AdjustTokenPrivileges OpenService RegisterServiceCtrlHandler CreateMutex LoadLibrary GetCommandLine

회피 방법 - 코드의 첫 바이트를 피해서 중간쯤 BP를 설치한다.

-2. Checksum 비교

특정 코드 영역의 Checksum 값을 비교

1byte라도 변경되면 바뀌는 Checksum 특징을 이용하여 특정 코드 내에서 CC 패치가 되었을 때 변경된 Checksum을 기존의 Checksum과 비교하여 디버깅 여부 판단

코드 버퍼에 대한 Checksum을 구하는 방법은 다양하다. 해당 메모리 영역이 기존과 동일한지 여부만 체크하면 되므로 다양한 알고리즘을 적용할 수 있다. 일반적으로 속도가 빠르고 충돌이 적은 CRC32(Cyclic Redundancy Check)를 많이 사용

회피 방법 - 원론적으로 CRC 계산 영역에 BP를 걸지 않거나 패치를 하지 않으면 무력화된다. → 디버깅이 어려워지므로 안티 디버깅의 노림수. 가장 좋은 방법은 CRC 비교 구문 패치.

but, 교묘하게 코드를 숨기고 수십~수백 개의 Checksum 비교 코드가 존재한다면, 디버깅하기 매우 까다롭다.

Static 안티 디버깅

xii.xxv — Wed, 10 Jan 2024 14:52:48 +0900

디버거 탐지, 디버깅 환경 탐지, 디버거 강제 분리

많은 static 안티 디버깅은 OS 의존성을 가지고 있다.

1. PEB

현재 프로세스의 디버깅 여부 판단에 사용.

PEB 구조체 정보 이용

+0x002 BeingDebugged
+0x00C Ldr
+0x018 ProcessHeap
+0x068 NtGlobalFlag

BeingDebugged - 디버깅 여부를 표시하는 Flag

Ldr, ProcessHeap, NtGlobalFlag - 디버깅 프로세스의 독특한 힙(Heap) 메모리 특성과 관련

TEB.ProsessEnvironmentBlock (+ 0x30) == PEB

PEB 구조체구하는법
바로 PEB 구하기
           MOV EAX, DWORD PTR FS:[0x30];                       FS:[0x30]=address of PEB
TEB 주소를 구하고 ProcessEnvironmentBlock(+0x30) 이용하기
           MOV EAX, DWORD PTR FS:[0x18];                       FS:[0x18]= address of TEB
           MOU EAX, DWORD PTR DS: [EAX+0x30]; DS:[eax+0x30]=address of PEB

-1. BeingDebugged (+0x2) - IsDebuggerPresent()

디버깅 중일 때 1(TRUE)로 세팅 / 일반실행의 경우 0(false)으로 세팅

회피 방법 - OllyDbg의 edit 명령어를 사용하여 PEB.BeingDebugged 값을 0(FALSE)으로 변경

-2. Ldr (+0xC)

디버깅 프로세스는 힙(Heap) 메모리에 디버기가 디버기라는 것을 표기한다.

이때, 눈에 띄는 특징은 힙 메모리의 사용되지 않는 영역을 0xFEEEFEEE 값으로 채운다.

PEB.Ldr은 _PEB_LDR_DATA 구조체 포인터

_PEB_LDR_DATA 구조체는 힙 메모리 영역에 생성 따라서 이 영역을 스캔(Scan)하면 쉽게 알 수 있다.

회피 방법 - 0xFEEEFEEE로 채워진 영역을 NULL로 덮어 씌운다.

but, XP이하에서만 동작, Attach의 경우 힙 메모리 특성이 나타나지 않는다.

-3. ProcessHeap (+0x18) - GetProcessHeap()

Heap 구조체 포인터

Heap 구조체 중 Flags(+0xC)와 Force Flags(+0x10)은 디버깅 중 특정한 값으로 세팅

회피 방법 - Heap.Flags = 2, Heap.ForceFlags = 0으로 세팅 (defulat 값으로 세팅)

but, XP에서만 효과, 7에선 없어진 특성이며 Attach의 경우 이 특성이 나타나지 않는다.

-4. NtGlobalFlag(+0x68)

디버깅 중이면 0x70으로 세팅

회피 방법 - PEB.NtGrobalFlag = 0으로 세팅 (defualt 값으로 세팅)

but, Attach의 경우 변하지 않는다.

2. NtQueryInformationProcess()

ntdll!NtQueryInformationProcess() API로 프로세스의 다양한 정보를 얻을 수 있으며, 그중 디버깅 관련 정보가 포함되어 있다.

NtQueryInformationProcess() API
- 지정된 프로세스에 대한 정보를 검색

__kernel_entry NTSTATUS NtQueryInformationProcess(
[in] HANDLE ProcessHandle,
[in] PROCESSINFOCLASS ProcessInformationClass,
[out] PVOID ProcessInformation,
[in] ULONG ProcessInformationLength,
[out, optional] PULONG ReturnLength
);

출처 : MSDN

NtQueryInformationProcess()의 두 번째 파라미터 PROCESSINFOCLASS ProcessInformaionClass에 해당 정보가 세팅된다.

PROCESSINFOCLASS는 열거형(enum)으로 여러 가지 정보를 찾을 수 있고, 그중 디버거 탐지에 사용되는 것은 ProcessDebugPort(0x7), ProcessDebugObjectHandle(0x1E), ProcessDebugFlags(0x1F)

-1. ProcessDebugPort(0x7)

디버깅 중일 때는 Debug Port가 할당된다.

ProcessInformationClass 파라미터에 ProcessDebugProt(0x7)을 입력하면 Debug Port를 얻을 수 있다.

dwDebugPort에 디버깅 중이면 0xFFFFFFFF, 아니면 0이 세팅된다.

CheckRemoteDebugPresent() API는 IsDebuggerPresent() API와 비슷하게 디버깅 여부를 판별

차이점은 CheckRemoteDebugPresent()의 경우 다른 프로세스의 디버깅 여부까지 판단

CheckRemoteDebugPresent()의 내부에서 NtQueryInformationProcess(ProcessDebugPort) API를 사용 중이다.중이다.

-2. ProcessDebugObjectHandle(0x1E)

프로세스가 디버깅될 때 Debug Object가 생성

ProcessDebugObjectHandle(0x1E)을 입력하면, Debug Object Handle을 얻을 수 있다.

디버깅 중이면 Debug Object Handle의 값이 존재할 것이고, 아니면 NULL

-3. ProcessDebugFlags(0x1F)

디버깅 중이면 Debug Flags 값이 0, 아니면 1

3. NtQuerySystemInformation()

디버깅 환경을 체크 - 현재 OS가 Debug Mode로 부팅되었는지 판단

(디버깅을 당하는지 체크하는 것은 직접적인 디버거 탐지 방법 / 디버깅 환경을 체크하는 것은 간접적인 디버거 탐지 방법)

ntdll!NtQyerySystemInformation() API는 현재 동작 중이 OS 시스템에 대한 다양한 정보를 구할 수 있는 시스템 함수

NtQyerySystemInformation() API
- 지정된 시스템 정보를 검색

__kernel_entry NTSTATUS NtQuerySystemInformation(
[in] SYSTEM_INFORMATION_CLASS SystemInformationClass,
[in, out] PVOID SystemInformation,
[in] ULONG SystemInformationLength,
[out, optional] PULONG ReturnLength
);

출처 : MSDN

첫 번째 파라미터인 SYSTEM_INFORMATION_CLASS SystemInformationClass 파라미터에 원하는 시스템 정보를 입력, PVOID SystemInformation 파라미터에 관련 구조체 주소를 넘기면 API가 리턴하며 그 구조체의 관련 정보를 채워준다.

SYSTEMP_INGOTMATION_CLASS는 열거형(enum)으로 SystemInformationClass 파라미터에 SystemKernelDebuggerInformation(0x23)을 입력하면 현재 OS 시스템이 디버그 모드로 부팅되었는지 알 수 있다.

회피방법 - wimdows XP의 경우, boot.ini를 편집(’/debugport=com1 /baudarate=115200 /Debug’ 값 삭제)

windows 7의 경우, cmd에 ‘bcdedit /debug off’ 명령어 입력 후 재부팅

4. NtQueryObject()

디버깅 중 생성되는 DebugObject 타입의 커널 객체의 존재를 확인

ntdll!NtQueryObject() API는 시스템의 다양한 종류의 커널 객체 정보를 구해오는 함수

NtQueryObject() API
- 다양한 종류의 개체 정보를 검색

__kernel_entry NTSYSCALLAPI NTSTATUS NtQueryObject(
[in, optional] HANDLE Handle,
[in] OBJECT_INFORMATION_CLASS ObjectInformationClass,
[out, optional] PVOID ObjectInformation,
[in] ULONG ObjectInformationLength,
[out, optional] PULONG ReturnLength
);

출처 : MSDN

두 번째 파라미터 OBJECT_INFORMATION_CLASS ObjectInformationClass에 원하는 값을 입력하고 API를 호출하면, 세 번째 파라미터 PVOID ObjectInformation에 관련 정보의 구조체 포인터를 리턴

ObjectAllTypeInformation(3) 항목을 이용하여 시스템의 모든 객체 정보를 구하고 그중 DebugObject의 존재 확인

NtQueryObject() API 사용법

커널 객체(Kernel Object) 정보 리스트의 크기 얻기
메모리 할당
커널 객체 정보 리스트 구하기
DebugObject 객체 타입 확인

회피방법 - ZwQueryObject의 호출 부분을 찾아 두 번째 파라미터의 값을 변경하면 해결된다.

5. ZwSetInformationThread()

디버기가 강제로 디버거를 떼어내는(Detach) 기법

스레드에게 정보를 세팅하는 System Native API이다.

ZwSetInformationThread() API
- 스레드의 우선순위를 설정

NTSYSAPI NTSTATUS ZwSetInformationThread(
[in] HANDLE ThreadHandle,
[in] THREADINFOCLASS ThreadInformationClass,
[in] PVOID ThreadInformation,
[in] ULONG ThreadInformationLength
);

출처 : MSDN

첫 번째 파라미터 ThreadHandle에 현재 스레드의 핸들을 넘겨주고, 두 번째 파라미터 ThreadInformationClass에 ThreadHideFormDebugger(0x11) 값을 입력하면 디버거 프로세스가 분리된다. -> 일반 실행의 경우 아무런 영향을 주지 않지만, 디버거 실행인 경우에는 디버거를 종료시킨다.(자신의 프로세스도 같이)

회피 방법 - 두 번째 파라미터 ThreadHideFromDebugger(0x11)을 0으로 변경

ZwSetInformationThread() API의 원리는 Thread가 숨김(Hide) 생태가 되어 디버깅이 불가능해지는 것으로 XP이후로는 DebugActiveProcessStop() API가 추가되었다.

6. DebugActiveProcessStop()

디버거에서 디버깅을 멈추고 싶을 때 호출

Detach 시 주체에 따른 호출 API
디버기가 디버깅 멈추기	ZwSetInformationThread() API
디버거가 디버깅 멈추기	DebugActiveProcessStop() API

7. TLS 콜백 함수

자체로는 안티 디버깅 기법이라고 볼 수 없지만 프로그램의 EntryPoint코드보다 먼저 실행되는 특징 때문에 안티 디버깅에 많이 활용된다.

TLS 콜백 함수 내에서 IsDebuggerPresent() 등의 함수로 간단히 디버깅 여부를 판별하여 프로그램의 실행 여부를 결정할 수 있다.

8. ETC

현재의 시스템이 (일반적인 시스템이 아니라) 리버싱을 위한 전용 시스템이라는 판단으로 실행을 멈추는 것도 좋은 방법이다. 이를 위해서 시스템에서 쉽게 구할 수 있는 일반적인 정보(Process, File, Window, Registry, host name, computer name, user name, Environment Variable 등)들을 활용하는 다양한 안티디버깅 기법들이 존재

대부분의 경우 Win32 API를 이용하여 구현되어 있다.

OllyDbg 창 검색 ←FindWindow()
OllyDbg 프로세스 검색 ← CreateToolhepl32Snapshot()
컴퓨터 이름이 “TEST”, “ANALYSIS” 등의 이름인지 확인 ← GetComputerName()
프로그램 실행 경로를 검사하여 “TEST”, “SAMPLE” 등의 이름인지 확인 ← GetCommandLine()
가상 머신에서 실행 중인지 확인(가상 머신 특유의 프로세스 이름 확인 ← VMWareService.exe, VMWareTray.exe, VMWareUser.exe 등)

회피방법 - FindWindow()에서 찾는 문자열의 주소로 이동하여 Window Class 이름 문자열 버퍼를 NULL로 덮어씌우거나 함수를 실행하지 않도록 JMP로 명령어를 수정, 파라미터로 사용되는 이전 함수의 리턴 값을 NULL로 수정, API 후킹 등의 방법들이 있다.

회피 방법이 어렵지 않아 유명 Protector들은 쓰지 않는다.

하지만 의외로 잘 알려지지 않은 Protector/Packer에서 사용되는 경우가 종종 있다.

디버깅 실습1 - 서비스 (서비스 프로세스 디버깅)

xii.xxv — Wed, 10 Jan 2024 02:59:15 +0900

1. 서비스 프로세스 동작 원리

- 서비스 시스템 개요

서비스(Service) 프로그램은 SCM(Service Control Manager)에 의해서 관리된다. 서비스 애플리케이션이 실행되기 위해서는 시작 명령을 내려줄 수 있는 서비스 제어기(Service Contro-ller)가 필요하다. 서비스 제어기는 SCM에게 서비스 제어를 요청하면 SCM이 서비스 프로그램에게 제어 명령을 전달하고 리턴 값을 돌려받는 구조로 되어있다.

그림1 서비스 시스템 개요

서비스 제어기에서 서비스 프로그램에 직접 명령을 내릴 수 없고, SCM을 통해서 명령을 내려야 된다.

- 서비스 시작 과정

서비스 프로그램의 시작 과정을 간략히 정리해 보면 아래 그림 2와 같다.

그림2 서비스 시작 과정

모든 서비스 프로그램은 외부(서비스 제어기)에서 StartService() API를 호출하면서 시작되며, ‘자동 실행’ 서비스의 경우 SCM에서 StartSevice()를 호출해 준다.

서비스 프로세스 시작 과정

1. 서비스 제어기에서 StartService() 호출
서비스 제어기에서 StartService()를 호출하면 SCM은 해당 서비스 프로세스를 생성한다. 그리고 서비스 프로세스의 EP 코드가 실행된다.

2. 서비스 프로세스에서 StartServiceCtrlDispatcher() 호출
서비스 프로세스 내부에서 StartServiceCtrlDispatcher()가 호출되면 서비스 제어기의 StartService() 함수가 리턴된다. 그리고 SCM은 서비스 프로세스의 서비스 메인 함수 SvcMain()을 호출하여 주소를 등록한다.
(StartService()는 SCM이 StartServiceCtrlDispatcher()로부터 SvcMain()가 성공적으로 생성되었다는 알림을 받으면 반환)

3. 서비스 프로세스에서 SetServiceStatus(SERVICE_RUNNING) 호출
현재는 SERVICE_START_PENFING 상태이다. SvcMain() 내부에서 SetServiceStatus(SERVICE_RUNNING) API를 호출해야 정상적인 서비스 프로세스로서 동작할 수 있다.

서비스 프로그램은 결국 SCM에 의해서 프로세스가 생성되고 SvcMain() 함수로 제어가 넘어오면서 SetServiceStatus(SERVICE_RUNNING) API를 호출해야 정상적인 서비스 프로세스로 동작할 수 있다.

2. 서비스 프로세스의 디버깅 이슈

서비스 프로그램을 정확히 디버깅하려면 SCM에 의해 실행되는 서비스 프로세스에 디버거를 Attach 해서 디버깅을 해야 한다.

- 문제는 SCM

서비스 프로세스 디버깅의 핵심은 서비스 프로세스가 SCM에 의해 실행된다는 것이다.

서비스 프로세스는 SCM에 의해서 실행됨
서비스 핵심 코드는 주로 서비스 메인 함수(SvcMain())에 존재
서비스 메인 함수(SvcMain())는 SCM에 의해서 정상 호출됨

서비스 메인 함수(SvcMain())를 디버깅해야 한다. 디버거로 서비스 프로그램의 실행 파일을 열고 디버깅을 시작하면 서비스 메인 함수가 실행되지 않는다. 따라서 SCM을 통해서 정상 실행된 서비스 프로세스에 Attach해서 디버깅을 해야 한다.

- 디버거로 안 되는 것은 없다.

디버거로 서비스 실행 파일을 열어서 디버깅을 하면 SCM이 서비스 메인 함수를 호출하지 않아 디버깅할 수 없다(SCM에 의한 실행이 아니므로 실행을 못 시킴).
디버거는 디버기 프로세스에 대한 막강한 권한을 가지므로 강제로 디버깅 위치를 서비스 메인 함수로 지정한 후 디버깅을 할 수 있다(예, OllyDbg의 ‘New origin here’). 이 방법으로 서비스 메인 함수를 디버깅해도 큰 무리가 없으며, 간단해서 추천하는 방법이다.
하지만 편법이므로 복잡하게 동작하는 서비스 프로세스의 경우 완벽하게 디버깅할 수 없는 경우도 있다.

- 정석대로

정석은 SCM에 의해 실행된 서비스 프로세스에 디버거를 Attach하여 디버깅하는 방법이다.
문제는 SCM이 서비스를 실행시킨 이후에 Attach를 하면 핵심 코드(서비스 메인 함수)가 이미 실행된 이후라는 점이다. 따라서 SCM이 서비스 프로세스를 생성하고 EP 코드를 실행시키기 직전에 디버거를 Attach해야 한다.

3. 서비스 디버깅 실습

리버싱 핵심 원리의 간단한 실습 파일(DebugMe1.exe)을 설치
(예제 서비스(SvcTest)의 기능은 OutputDebugString() API를 사용한 디버그 문자열 출력)

그림3 서비스 설치 및 SvcTest 서비스 확인

그림4 SvcTest 서비스 속성

그림5 SvcTest 서비스 프로세스(DebugMe1.exe) 및 출력하는 디버그 문자열

- EP 강제 세팅

디버거로 서비스 파일을 직접 열고 디버깅하는 방법
보통 서비스 프로그램의 주요 코드는 서비스 메인(SvcMain()) 함수와 서비스 핸들러(SvcHandler()) 함수에 존재한다. SCM에 의해 실행되지 않고 디버거에 의해서 실행된 서비스 프로세스는 SvcMain()과 SvcHandler()가 호출되지 않는다. 따라서 그 함수들의 주소를 알아내서 그곳으로 디버깅 위치를 옮겨야 된다.

그림6 DebugMe1.exe 파일의 Main()

40106C주소의 StartServiceCtrlDispatcher()를 확인할 수 있다.
EXE 파일 형태의 Windows 서비스 프로그램은 반드시 EP 코드에서 StartServiceCtrlDispatcher() API를 호출하여 서비스 메인 함수 SvcMain()주소를 등록한다. 따라서 이 API를 찾으면 SvcMain()의 주소를 알아낼 수 있다.

DLL 파일 형태의 Windows 서비스의 경우 서비스 메인 함수(기본으로 ServiceMain)를 Export하고, SCM은 그 Export 함수를 실행한다. 따라서 DLL의 경우에는 StartServiceCtrlDispatcher() API를 따로 호출할 필요가 없다.
- 서비스 메인 함수의 이름을 ServiceMain이 아닌 다른 이름으로 지정하고 싶으면 관련 레지스트리에 등록하면 된다.

StartServiceCtrlDispatcher() API의 파라미터 pServiceTable은 SERVICE_TABLE_ENTRY 구조체 포인터이다. 이 구조체에서 서비스의 이름 문자열과 서비스 메인 함수의 주소를 알 수 있다.

SERVICE_TABLE_ENTRY 구조체 정의

typedef struct _SERVICE_TABLE_ENTRYA {
LPSTR lpServiceName; // 서비스 이름
LPSERVICE_MAIN_FUNCTIONA lpServiceProc; // 서비스 메인 함수 주소
} SERVICE_TABLE_ENTRYA, *LPSERVICE_TABLE_ENTRYA;

출처 : MSDN

pServiceTable(18FD24)의 첫 번째 멤버(40A9CC)는 “SvcTest” 문자열이고, 두 번째 멤버(401320)가 SvcMain()함수의 주소이다.

그림7 StartServiceCtrlDispatcher() API의 파라미터 pServiceTable

SvcMain()으로 이동하면 OutputDebugString() API를 사용하여 디버그 문자열을 출력하는 코드를 확인할 수 있다.
이제 디버기 프로세스의 EIP를 SvcMain()으로 변경하여 디버깅하면 된다.

그림8 SvcMain()

- SvcMain()으로 이동하여 디버깅하기 위해서는 ‘New origin here’로 디버기 프로세스의 EIP 값을 SvcMain()의 시작 주소로 변경해야 된다. 이때 EIP 레지스터 외에 다른 것들(스택, EIP를 제외한 레지스터)은 모두 그대로이다.
- SCM으로부터 정상적으로 실행된 서비스 프로세스가 아니기 때문에 일부 서비스 관련 API룰 호출할 때 EXCEPTION이 발생할 수 있다. (예외처리 옵션이나 Plugin 사용)
- 간혹 EP 강제 세팅으로 정확한 디버깅을 할 수 없는 경우가 있다. 이때는 정석(Attach) 방법으로 디버깅해야 된다.

- Attach 방식

SCM을 통해서 정식으로 실행되는 서비스 프로세스를 디버거로 Attach해서 디버깅해야 하는 경우 간단한 디버깅 기법이 사용된다. 디버깅 기법의 작업 흐름을 EP 코드 디버깅 기준으로 간단히 표현하면 아래와 같다.

[서비스 설치]
↓
[파일 패치] EP코드에 무한루프 설치
↓
[서비스 실행] 무한루프에 걸림	←	SCM은 대기 상태 (SERVICE_RUNNING을 기다림)
↓
[Attach] 디버기를 Attach 시킴
↓
[프로세스 패치] EP 코드를 원래대로 복구
↓
[프로세스 패치] EP 코드부터 디버깅	←	서비스 프로세스의 EP 코드부터 디버깅 가능

핵심은 디버거를 Attach시킬 때까지 서비스 프로세스의 중요 코드가 실행되지 못하도록 무한루프에 빠트리는 것이며, 고려할 사항은 Service Start Timeout(기본 30초) 이내에 완료하는 것이다.

SCM은 서비스를 실행시킨 후 일정 시간(Service Start Timeout) 동안 서비스의 상태가 STATUS_RUNNING으로 변경되길 기다린다.
만약 그 시간 내에 서비스의 상태가 변경되지 않는다면, SCM은 ERROR_SERVICE_REQUEST_TIMEOUT 에러를 발생시키고 해당 서비스 프로세스를 종료한다.

1) 서비스 설치

Windows 서비스 파일을 설치한다.

2) Service Start Timeout 시간 증가

서비스 상태를 변경하려면, 서비스 메인 함수 내에 존재하는 SetServiceStatus() API를 호출해야 된다. 하지만 30초 내의 작업은 매우 어려움으로 서비스 상태 변경 전 Service Start Timeout의 시간을 늘려야 된다.

Service Start Timeout 시간 증가
레지스트리 에디터(regedit.exe)를 실행하여 DWORD 값 생성
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control] ServicesPipeTimeout

ServicePipeTimeout은 기본값이 아니므로 생성해야 되며, 값은 밀리세컨드(millisecond)를 의미하며 시스템을 재부팅하면 적용된다.

Service Start Timeout을 늘리는 것은 모든 서비스에 영향을 미치므로 중요한 업무용 컴퓨터가 아닌 디버깅용 테스트 컴퓨터에만 적용하는 걸 권장

그림9 레지스트리에 ServicesPipeTimeout 값 생성

3) 파일 패치: 무한루프 설치

서비스 실행 파일(EXE 혹은 DLL)의 EP(Entry Point) 주소에 무한루프(Infinite Loop) 코드를 덮어씌운다.
Stud_PE 같은 PE 관련 유틸리티를 이용하여 파일의 EP 주소(RVA/RAW)를 확인한다.
Address of Entry Point 가 00001824이다. EP이므로 첫 번째 섹션(.text)이다. 따라서 RAW는 1824 – 1000 + 400 = C24이다.

그림10 PEView로 EP 주소 확인

EP(Entry Point)의 파일 옵셋(File Offset = RAW)이 C24인 것을 확인할 수 있다.

그림11 Stud_PE로 EP 주소 확인

HxD 유틸리티를 이용하여 해당 위치로 이동하면 원본 EP 코드의 첫 바이트를 찾을 수 있다. 이때, 첫 2바이트를 따로 적어두고, 해당 두 바이트를 0xEB, 0xFE로 패치한다.

그림12 HxD: 패치된 EP 코드

OpCode 0xEB는 근거리(Short Distance) JMP 명령어이고 1바이트 크기의 값을 가진다.
이 값은 Signed Value(부호 있는 수)이며 ‘Next EIP와의 상대적인 거리’를 의미한다.

Jump Address = Next EIP(401826) + 0xFE(-2) = 401824

패치된 코드를 OllyDbg로 확인하면 무한루프 명령어(자신의 주소 401824로 점프)를 확인할 수 있다.

그림13 OllyDbg: 패치된 EP 코드

4) 서비스 시작

서비스를 시작하면 서비스 프로세스는 무한루프에 빠져서 CPU 점유율이 100%에 가깝게 상승한다.
오류 1053이 발생하면 그것이 ERROR_SERVICE_REQUEST_TIMEOUT 에러이다. 앞에서 Service Start Timeout의 시간을 늘려서 서비스 프로세스가 종료된 것은 아니므로 계속 진행하면 된다.

5) Attach 디버거

디버거를 Attach 시키면 시스템 라이브러리(ntdll.DbgBreakPoint) 영역에서 멈춘다.

그림14 OllyDbg: Attach된 후 시스템 라이브러리에서 멈춤

6) 프로세스 패치: 무한루프 제거

Ctrl+G 명령으로 프로세스의 EP 주소(VA: 401824)로 이동하여 BP 설치 후 실행한다.
401824 주소에서 ‘Edit’기능을 이용하여 (앞에서 기록해 둔) 원본 코드(0xE8, 0xC0)으로 복원한다.

그림15 EP 코드 복원

7) 디버깅 시작

이제 서비스 메인 함수에서 SetServiceStatus() API를 호출하여 SERVICE_RUNNING 상태로 변경되어야 서비스 프로세스가 정삭적으로 실행된다. (프로세스 시작 과정 3)

그림16 SetServiceStatus() API 호출

SetServiceStatus() API 두 번째 파라미터 구조체의 dwCurrentState가 40134D에서 4(SERVICE_RUNNING)로 세팅되는 것을 확인할 수 있다.

SetServiceStatus() API

BOOL SetServiceStatus(
[in] SERVICE_STATUS_HANDLE hServiceStatus,
[in] LPSERVICE_STATUS lpServiceStatus
);

출처 : MSDN

[in] hServiceStatus - 현재 서비스의 상태 정보 구조에 대한 핸들입니다.
[in] lpServiceStatus - SERVICE_STATUS 구조에 대한 포인터는 호출 서비스에 대한 최신 상태 정보를 포함합니다.

출처 : MSDN

그림17 dwCurrentState 멤버 값

출처 : MSDN

SetServiceStatus(SERVICE_RUNNING) API가 실행되면 해당 서비스가 시작됨으로 변경된 것을 확인할 수 있다.

그림18 SvcTest 서비스 시작됨

따라서 서비스 프로세스 Attach 방식 디버깅을 정리하면 아래와 같다.

[서비스 설치]

↓

[Service Start Timeout 시간 증가]

↓

[파일 패치]
EP코드에 무한루프 설치

↓

[서비스 실행]
무한루프에 걸림

↓

[Attach]
디버기를 Attach 시킴

↓

[프로세스 패치]
EP 코드를 원래대로 복구 (무한루프 제거)

↓

[프로세스 패치]
EP 코드부터 디버깅

4. 마무리

서비스 프로세스의 동작 원리와 디버깅 방법을 정리하였는데, 서비스 동작 원리를 이해하지 못하면 서비스 메인 함수를 정확히 디버깅할 수 없다.
따라서 동작 원리를 이해하는데 중점을 두어야 된다.

리버싱 핵심원리 - 디버깅 실습1_업로드용.pdf

0.76MB

[CodeEngn] Advance RCE L15

xii.xxv — Mon, 19 Apr 2021 18:02:43 +0900

● CodeEngn Advance RCE L15 문제

CodeEngn Advance RCE L15

◎ 파일 실행 화면

[그림 1] 파일 실행 화면 및 Unlock Code Error

Username and Serial Validation으로 넘어가려면 리버싱으로 Unlock Code를 찾아야 되는 것으로 확인됩니다.

◎ 패킹 및 난독화 여부 확인

[그림 2] exeinfo PE

● CodeEngn Advance RCE L15 풀이

[그림 3] 디버거 - x32dbg / 디버기 - 15.exe (Advance RCE L15 실행파일)

현재 모듈에서 호출되는 함수를 찾아보면 없다고 뜹니다. [그림 2]에서 패킹이 없다는 것을 확인했으니 파일이 암호화되어있을 겁니다.

[그림 4] Search for > Current module > Intermodular calls

[그림 3]에서 진행하면, [그림 5]를 걸치면서 코드가 복호화됩니다.

[그림 5] 00401400 코드 복호화 및 00401000 코드 복호화

복호화가 된 최종 결과는 [그림 6]이며, 이 곳이 OEP입니다.

[그림 6] OEP

[그림 6]에서 [Plugins > Scylla]에서 DUMP 파일을 생성합니다.

[그림 7] DUMP

현재 모듈에서 호출되는 함수를 찾아보면 GetDlgItemTextA 함수를 확인할 수 있습니다. 이 함수를 사용하여 프로그램이 입력받은 Unlock Code와 Name, Serial을 입력받는 것으로 추측됩니다. BP를 걸고 실행을 하여 해당 주소로 이동합니다.

[그림 8] Search for > Current module > Intermodular calls

Unlock Code 입력 후 디버거를 보면 CMP eax, 7을 하여 비교하는 것을 확인할 수 있습니다. 즉, Unlock Code는 8자 이상이어야 합니다.

[그림 9] Unlock Code

Unlock Code가 8자 이상이라는 것을 알았으니 실행하여 Name과 Serial을 입력하면 어떤 창이 뜰지 실행해봅시다. [그림 10]처럼 작성하여 Check를 누르면 화면이 꺼집니다. 즉, 제대로 된 실행이 아닌 것 같습니다.

[그림 10] Name, Serial 입력

Unlock Code를 입력받은 후 CALL 4012D2의 내부를 확인하면 입력받은 Code를 사용하여 ECX(10h)와 곱하며 합을 만들어가는 것을 확인할 수 있습니다.

[그림 11] CALL 4012D2 내부

'ABCDABCD'가 입력될 경우 'F0'이 생성되는 것을 확인할 수 있습니다.

[그림 12] CALL 4012D2 결과

CALL 4012D2의 결과를 사용하여 CALL 4012F7 내부에서 [004011C1 ~ 0040123C]까지 XOR을 하는 코드가 있습니다. 이는 [004011C1 ~ 0040123C]가 암호화되어있다는 것이며, CALL 4012D2의 결과와 XOR 하는 것으로 복호화하는 것을 의미합니다.

[그림 13] 4011C1 복호화

[그림 14] 복호화 결과

이후 진행하면 Name과 Serial을 입력받습니다. [그림 15]를 설명하면, 004010F1에서 입력받은 Name을 찾아오고, 1자에서 16자 사이의 길이를 가지는지 확인합니다. 00401135 CALL 4011E8에서 입력받은 Name을 사용하여 Serial을 생성합니다.

[그림 15] Name 및 Serial

CALL 4011E8의 내부를 확인하면 코드가 이상한 것을 볼 수 있습니다. 이 코드는 [그림 14]에서 확인한 XOR 해서 만들어진 코드입니다. 즉, 제대로 복호화 Key가 잘 못되었다는 겁니다.

[그림 16] 잘못된 Key로 복호화된 코드

함수의 프롤로그는 '55h'로 시작합니다. [그림 13]에서 처음 hex 값은 '70h'입니다. '70h'과 XOR 하여 '55h'를 만드는 값은 '25h'입니다. 따라서 코드 복호화 Key는 '25h'가 되어야 합니다.

[그림 17] 70 XOR 55 = 25

Unlock Code를 사용하여 Key를 만들고 난 후 Key의 값을 '25h'로 변경하고 진행합니다.

[그림 18] 코드 복호화 Key 수정

004011E8까지 진행하면 정상적으로 복호화된 코드를 확인할 수 있습니다.

[그림 19] 정상적으로 복호화된 코드

[그림 19]의 CALL 4011C1에서 입력된 Name을 사용하여 Serial을 만드는 Key를 생성합니다. 생성과정은 [그림 11]에서 Unlock Code로 코드 복호화 Key를 생성하는 과정과 같습니다.

[그림 20] Serial을 만드는 Key 생성

CALL 4011C1에서 생성된 Key를 사용하여 Serial을 생성합니다. Serial 생성은 [그림 11]에서 Unlock Code로 코드 복호화 Key를 생성하는 과정과 유사하며, 이후 생성된 값을 16진수로 변환하는 코드가 추가되어있습니다. (Ex. 0Ah -> 41h(A))

[그림 21] Serial 생성

[그림 21]에서 CodeEngn Advance RCE L15의 답 Name(CodeEngn.com)의 Serial을 확인할 수 있습니다.

프로그램의 흐름을 좀 더 살펴보면, Serial이 생성된 후 입력받은 Serial을 찾아와 CALL 401280에서 비교하는 것을 확인할 수 있습니다.

[그림 22] Serial 비교 함수

CALL 401280의 내부는 [그림 23]과 같으며, 입력받은 Serial과 생성된 Serial을 한자씩 비교합니다.

[그림 23] CALL 401280의 내부

+α

[그림 22]에서 입력받은 Serial은 [00403329]에서 찾을 수 있습니다.

[그림 24] 입력받은 Serial

입력받은 Serial이 16Byte보다 많아도 GetDlgItemTextA 함수에서 16Byte까지만 찾아옵니다.

● CodeEngn Advance RCE L15 확인

[그림 25] You hace entered valid valuse!

[CodeEngn] Advance RCE L14

xii.xxv — Fri, 16 Apr 2021 16:27:01 +0900

● CodeEngn Advance RCE L14 문제

CodeEngn Advance RCE L14

◎ 파일 실행 화면

[그림 1] 파일 실행 화면 / 실패 화면 (Name : ABCD , Serial : NH6-0-0091008D0052)

◎ 패킹 및 난독화 여부 확인

[그림 2] exeinfo PE

● CodeEngn Advance RCE L14 분석 및 풀이

[그림 3] 디버거 - OllyDbg / 디버기 - 14.exe (Advance RCE L14 실행파일)

문자열 검색에서 [그림 1] 실패 화면의 "Invalid Registration Code"문자열을 찾으면 성공 문자열과 함께 바로 보입니다.

[그림 4] Search for > All referenced text strings

실패 문자열 주소로 이동하면 성공 문자열과 함께 분기점(0047F448)을 확인할 수 있습니다.

[그림 5] 분기 조건 및 분기점 확인

분기 조건의 파라미터를 확인하면 입력된 Serial의 숫자 부분과 Name으로 생성된 Serial 숫자를 비교하는 것을 확인할 수 있습니다.

분기 조건 앞의 CALL 00404B2C와 CALL 0047F0B8은 각각 입력된 Serial과 입력된 Name을 파라미터로 가집니다.

즉, 앞의 CALL 0047F0B8에서 Name으로 Serial을 만드는 것을 예상할 수 있습니다.

[그림 6] 분기조건 : EAX, EDX 비교

CALL 0047F0B8의 내부를 확인해 보겠습니다.

[그림 7] CALL 0047F0B8 내부

CALL 0047F0B8의 내부에는 Serial을 생성하는 3개의 반복문이 존재합니다.

1. Name의 길이를 늘려주는 반복문

[그림 8] Name의 길이를 늘려줌

2. 1에서 늘린 Name과 문자열(NH KeyGenMe6)의 합을 이어 붙이는 반복문 (1회 반복 결과 : 4byte)

[그림 9] Serial = 1에서 늘린 Name과 문자열(NH KeyGenMe6)의 합

3. 2에서 생성된 Serial의 앞의 12자리를 자르는 반복문

[그림 10] Serial = 2에서 생성된 Serial의 앞에서 12자리

Serial : NH6-0-0091008D0052을 만족하는 Name을 찾으려면 Serial의 숫자 부분에서 문자열을 빼주면 됩니다.

[그림 11] 문자열

[그림 12] 뺄셈

● CodeEngn Advance RCE L14 확인

[그림 12]의 값을 문자로 변환하면 'CE2'입니다.

[그림 13] Name 확인

[그림 14] Registereg Successfully