www.reversecore.com

☞ 어셈블리 언어를 이용한 Code Injection (2)

☞ 어셈블리 언어를 이용한 Code Injection (3)

notepad.exe 디버깅

CodeInjection2.exe

notepad.exe 프로세스에 어셈블리 언어로 제작한 코드를 인젝션 시키고 디버깅을 해보도록 하겠습니다.

Code Injection 기법의 디버깅 방법은 아래 링크를 참고하시기 바랍니다.

☞ Code Injection 기법 (3)

위의 글에서 소개된 방법에 따라 notepad.exe 에 인젝션된 코드를 OllyDbg 로 보면 아래 그림과 같습니다.

<Fig. 1>

* 참고

위 코드의 시작 주소(2D0000)는 사용자 환경에 따라서 틀려집니다.

위 코드를 자세히 디버깅 해보겠습니다.

# Stack Frame 생성

002D0000 55 PUSH EBP ; # ThreadProc()

002D0001 8BEC MOV EBP,ESP

전형적인 스택 프레임 생성 명령어 입니다. 이 명령어가 낯 설은 분들께서는 이 기회에 "55 8BEC" 하고 외워두시는 것도 좋습니다.

스택 프레임을 생성하는 이유는 이후에 나오는 명령어들이 스택에 문자열들을 집어넣는 기법을 사용하기 때문에 위 ThreadProc() 함수가 종료될 때 스택을 깨끗이 정리하기 위해서입니다.

# THREAD_PARAM 구조체 포인터

002D0003 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8]

스택 프레임이 생성된 이후에 [EBP+8] 이 의미하는 것은 함수로 넘어온 첫 번째 파라미터 입니다. 이 경우에는 THREAD_PARAM 구조체 포인터가 될 것입니다.

아래에 THREAD_PARAM 구조체를 표시하였습니다. 구조체의 멤버는 2개의 함수 포인터인데 각각 “LoadLibraryA” 와 “GetProcAddress()” 의 포인터가 저장됩니다. (누가 이 포인터를 구해서 저장시켜 줬을까요? 네, 지난 강좌에서 소개한 CodeInjection2.exe 프로그램에서 구해서 notepad.exe 에 인젝션 시킨 후 스레드 실행할 때 파라미터로 넣어주었죠.)

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

} THREAD_PARAM, *PTHREAD_PARAM;

위 2D0003 주소의 MOV ESI, DWORD PTR SS:[EBP+8] 명령어를 실행한 이후에 ESI 레지스터에 저장된 주소를 따라가서 확인해 보겠습니다.

<Fig. 2>

ESI 에 280000 주소가 저장되었으며 이 주소는 CodeInjection2.exe 에서 THREAD_PARAM 구조체를 위해 notepad.exe 프로세스 메모리 공간에 할당한 메모리 버퍼의 주소입니다.

* 참고

THREAD_PARAM 구조체 주소(2D0000)는 사용자 환경에 따라서 틀려집니다.

<Fig. 2> 의 메모리 윈도우를 보면 280000 주소에 두 개의 4 byte 값들이 저장된 걸 확인할 수 있습니다. 저 값들이 "LoadLibraryA" 와 "GetProcAddress" API 함수의 시작 주소일 것입니다. 좀 더 직관적으로 확인하기 위해서 OllyDbg 메모리 윈도우의 보기 옵션을 변경해 보겠습니다.

메모리 윈도우에 커서를 위치시킨 후 마우스 우측 메뉴의 "Long – Address" 항목을 선택해 주시기 바랍니다.

<Fig. 3>

위 메뉴 항목을 선택하면 OllyDbg 의 메모리 윈도우는 아래 그림과 같이 표시 형식이 변경됩니다.

<Fig. 4>

주소가 훨씬 더 직관적으로 표시되지요? 또한 친절하게 Comment 에 각 주소에 해당되는 API 이름을 표시해 주고 있습니다.

# "user32.dll" 문자열

002D0006 68 6C6C0000 PUSH 6C6C ; “\0\0ll”

002D000B 68 33322E64 PUSH 642E3233 ; “d.23”

002D0010 68 75736572 PUSH 72657375 ; “resu”

위 코드는 스택(Stack)에 문자열을 저장하는 기법입니다. 스택에 직접 접근할 수 있는 Assembly 프로그래밍 언어에서만 가능한 독특한 기법이지요.

2D0006 주소의 PUSH 6C6C 명령어는 스택에 00006C6C 값을 저장하라는 뜻입니다. 6C 는 ASCII 로 'l' 이지요. 즉, 이 명령은 "\0\0ll" 문자열을 스택에 집어 넣는 것입니다.

그 밑의 2D000B 와 2D0010 주소의 PUSH 명령어도 각각 "d.23" 문자열과 "resu" 문자열을 입력하는 명령어 입니다.

x86 CPU 의 Little Endian 표기법과 스택의 거꾸로 자라는 특성 때문에 문자열을 뒤집어서 입력하는 것을 주의 깊게 보시기 바랍니다. 이것은 디버깅할 때 잘 알고 계셔야 하는 내용입니다.

2D0010 주소까지 디버깅 한 후 스택을 보면 아래 그림과 같습니다.

<Fig. 5>

이와 같은 PUSH 명령어를 이용하여 원하는 문자열을 스택에 입력할 수 있습니다. 또한 Code Injection 할 때 문자열 데이터를 따로 인젝션 하지 않고 코드에 포함시켜서 코드만 인젝션 시킬 수 있습니다.

* 참고

- 문자열 데이타를 코드에 포함시키는 방법은 한가지가 더 있으며, 뒤에서 따로 소개합니다.

- 32 bit OS 에서 PUSH 명령어는 한번에 최대 4 byte 크기의 데이터만 스택에 저장이 가능합니다.

# "user32.dll" 문자열 파라미터 입력

002D0015 54 PUSH ESP

LoadLibraryA() API 는 파라미터로 로딩시킬 DLL 파일 이름 문자열 주소를 받습니다.

HMODULE WINAPI LoadLibrary(

__in LPCTSTR lpFileName

);

* 출처 : http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx

위 <Fig. 5> 를 보시면 현재 ESP 의 값은 219FCD4 이며 이것은 "user32.dll" 문자열의 시작 주소입니다. 따라서 2D0015 주소의 PUSH ESP 명령어는 "user32.dll" 문자열 주소(219FCD4)를 스택에 입력하는 명령입니다. (아래 그림 참고)

<Fig. 6>

# LoadLibraryA("user32.dll") 호출

002D0016 FF16 CALL DWORD PTR DS:[ESI] ; kernel32.LoadLibraryA

ESI 레지스터는 <Fig. 4> 에서 보다시피 280000 값을 가지며 이 주소에는 LoadLibraryA() API 의 시작 주소(772C2864)가 저장되어 있습니다. 아래 그림을 봐주시기 바랍니다.

<Fig. 7>

어셈블리 언어의 메모리 참조 문법이 생소하신 분들께서는 이번 기회에 확실히 익혀 두시기 바랍니다. 아래와 같은 간단한 전개식을 사용하면 쉽게 이해하실 수 있습니다. ([ ] 는 C 언어의 포인터 참조와 같은 개념입니다.)

[ESI] = [280000] = 772C2864 (address of kernel32.LoadLibraryA)

2D0016 주소의 CALL DWORD PTR DS:[ESI] 명령어를 실행하면 LoadLibraryA() API 가 호출되면서 파라미터로 입력된 "user32.dll" 이 로딩됩니다. notepad.exe 프로세스는 실행될 때 이미 user32.dll 를 로딩하였으므로 그 로딩 주소만 리턴합니다.

<Fig. 8>

함수의 리턴값은 EAX 에 저장되므로 위 <Fig. 8> 을 보시면 EAX = 778E0000 이 저장되었습니다.

OllyDbg 메뉴의 "View – Executable modules [ALT + E]" 항목을 선택하시면 아래 그림과 같이 프로세스 메모리에 로딩된 DLL 을 확인 할 수 있습니다.

<Fig. 9>

위 그림에서 user32.dll 의 로딩 주소가 778E0000 임을 확인 할 수 있습니다.

# "MessageBoxA" 문자열

002D0018 68 6F784100 PUSH 41786F ; “\0Axo”

002D001D 68 61676542 PUSH 42656761 ; “Bega”

002D0022 68 4D657373 PUSH 7373654D ; “sseM”

역시 PUSH 명령어를 이용해서 문자열 "MessageBoxA" 를 스택에 입력하는 명령어 입니다. (위의 "user32.dll" 문자열 입력과 동일합니다.)

2D0022 주소의 PUSH 명령까지 디버깅을 하고 나면 아래 그림과 같이 스택에 "MessageBoxA" 문자열이 저장됩니다.

<Fig. 10>

# GetProcAddress(hMod, "MessageBoxA") 호출

002D0027 54 PUSH ESP ; - “MessageBoxA”

002D0028 50 PUSH EAX ; - hMod (778E0000)

002D0029 FF56 04 CALL DWORD PTR DS:[ESI+4] ; kernel32.GetProcAddress

현재 ESP 의 값은 0219FCC8 입니다. (<Fig. 10> 참고) 따라서 2D0027 주소의 PUSH ESP 명령어는 "MessageBoxA" 문자열 주소(0219FCC8) 를 스택에 입력하는 명령입니다. (이 문자열 주소는 2D0029 주소에서 호출되는 GetProcAddress() API 의 2nd 파라미터로 사용됩니다.)

그리고 현재 EAX 의 값은 778E0000 입니다. 이는 user32.dll 모듈의 로딩 주소이지요. (<Fig. 8> 참고) 따라서 2D0029 주소의 PUSH EAX 명령어는 user32.dll 의 시작 주소(hMod)를 스택에 입력하는 명령입니다. (이 문자열 주소는 2D0029 주소에서 호출되는 GetProcAddress() API 의 1st 파라미터로 사용됩니다.)

여기까지 디버깅을 진행한 후 스택의 모습은 아래 그림과 같습니다.

<Fig. 11>

ESI 레지스터의 값은 280000 입니다. 따라서 [ESI+4] 의 전개식은 다음과 같습니다. (<Fig. 4>, <Fig. 7> 참고)

[ESI+4] = [280004] = 772C1837 (address of kernel32.GetProcAddress)

따라서 2D0029 주소의 CALL DWORD PTR DS:[ESI+4] 명령어는 GetProcAddress(778E0000, "MessageBoxA") API 를 호출하는 것입니다. 이 CALL 명령어를 실행하면 user32.MessageBoxA() API 시작 주소가 EAX 레지스터에 저장됩니다. (사용자 환경에 따라서 이 주소는 틀려집니다. 제 경우에는 EAX = 7793EA71 입니다.)

<Fig. 12>

(분량이 많아 다음 강좌에 이어서 하겠습니다.)

어셈블리 언어를 이용한 Code Injection (3)

reversecore — Wed, 30 Jun 2010 20:02:54 +0900

어셈블리(Assembly) 언어로 생성한 코드를 가지고 Injector 를 만들어 보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ 어셈블리 언어를 이용한 Code Injection (2)

ThreadProc() 함수의 Binary 코드 얻기

asmtest_patch.exe

지난 강좌에서 생성한 asmtest_patch.exe 파일을 OllyDbg 로 열어 보겠습니다. 우리가 프로그래밍한 ThreadProc() 의 주소는 401000 입니다. 메모리 윈도우에서 401000 주소로 갑니다.

<Fig. 1>

ThreadProc() 함수는 401000 ~ 401061 의 주소 영역입니다. 위 그림과 같이 이 영역을 선택하신 후 마우스 우측 메뉴의 "Copy - To file" 항목을 선택하시기 바랍니다. (아래 그림 참고)

<Fig. 2>

이렇게 저장한 파일을 텍스트 에디터로 열어보겠습니다. (GVIM 또는 AcroEdit 추천합니다.)

<Fig. 3>

위 텍스트 파일의 내용은 Hex 값으로 표현된 ThreadProc() 함수로써, IA-32 OpCode (Operation Code) 명령어 입니다. 이 내용은 곧 상대방 프로세스에 인젝션 시킬 코드가 되는 것입니다.

위 텍스트 파일을 아래와 같이 편집합니다. 불필요한 부분을 제거하고 모든 바이트마다 "0x" 표시를 붙여주고 ',' 로 연결합니다. 텍스트 에디터의 편집 기능(열 선택, 문자열 변경)을 적절히 사용하시면 편리합니다.

<Fig. 4>

위 그림에서 편집된 텍스트 내용을 보면 마치 C 언어의 BYTE 배열처럼 보이지 않습니까? 이게 바로 인젝션 시킬 코드 버퍼입니다. (아래 설명되는 CodeInjection2.cpp 파일에서 사용됩니다.)

편집된 텍스트 파일을 첨부합니다.

RVA.txt

CodeInjection2.cpp

CodeInjection2.cpp

Injector 프로그램의 소스 코드입니다. 위에서 텍스트 에디터로 만든 코드 버퍼는 아래 소스에서 g_InjectionCode 배열에 사용되었습니다.

* 참고!

아래 소스코드는 MS Visual C++ 2008 Express Edition 에서 개발되었으며, Windows 7 32bit 환경에서 테스트 되었습니다. 또한 설명의 편의를 위하여 리턴 값 체크와 에러 처리 코드는 생략되었습니다. 원본 소스 코드는 위에 첨부된 CodeInjection2.cpp 파일을 참고하시기 바랍니다.

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

} THREAD_PARAM, *PTHREAD_PARAM;

// ThreadProc()

BYTE g_InjectionCode[] =

{

0x55, 0x8B, 0xEC, 0x8B, 0x75, 0x08, 0x68, 0x6C, 0x6C, 0x00,

0x00, 0x68, 0x33, 0x32, 0x2E, 0x64, 0x68, 0x75, 0x73, 0x65,

0x72, 0x54, 0xFF, 0x16, 0x68, 0x6F, 0x78, 0x41, 0x00, 0x68,

0x61, 0x67, 0x65, 0x42, 0x68, 0x4D, 0x65, 0x73, 0x73, 0x54,

0x50, 0xFF, 0x56, 0x04, 0x6A, 0x00, 0xE8, 0x0C, 0x00, 0x00,

0x00, 0x52, 0x65, 0x76, 0x65, 0x72, 0x73, 0x65, 0x43, 0x6F,

0x72, 0x65, 0x00, 0xE8, 0x14, 0x00, 0x00, 0x00, 0x77, 0x77,

0x77, 0x2E, 0x72, 0x65, 0x76, 0x65, 0x72, 0x73, 0x65, 0x63,

0x6F, 0x72, 0x65, 0x2E, 0x63, 0x6F, 0x6D, 0x00, 0x6A, 0x00,

0xFF, 0xD0, 0x33, 0xC0, 0x8B, 0xE5, 0x5D, 0xC3

};

// ThreadProc()

004010ED 55 PUSH EBP

004010EE 8BEC MOV EBP,ESP

004010F0 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8]

004010F3 68 6C6C0000 PUSH 6C6C

004010F8 68 33322E64 PUSH 642E3233

004010FD 68 75736572 PUSH 72657375

00401102 54 PUSH ESP

00401103 FF16 CALL DWORD PTR DS:[ESI]

00401105 68 6F784100 PUSH 41786F

0040110A 68 61676542 PUSH 42656761

0040110F 68 4D657373 PUSH 7373654D

00401114 54 PUSH ESP

00401115 50 PUSH EAX

00401116 FF56 04 CALL DWORD PTR DS:[ESI+4]

00401119 6A 00 PUSH 0

0040111B E8 0C000000 CALL 0040112C

00401120 <ASCII>

0040112C E8 14000000 CALL 00401145

00401131 <ASCII>

00401145 6A 00 PUSH 0

00401147 FFD0 CALL EAX

00401149 33C0 XOR EAX,EAX

0040114B 8BE5 MOV ESP,EBP

0040114D 5D POP EBP

0040114E C3 RETN

BOOL InjectCode(DWORD dwPID)

{

HMODULE hMod = NULL;

THREAD_PARAM param = {0,};

HANDLE hProcess = NULL;

HANDLE hThread = NULL;

LPVOID pRemoteBuf[2] = {0,};

hMod = GetModuleHandleA("kernel32.dll");

// set THREAD_PARAM

param.pFunc[0] = GetProcAddress(hMod, "LoadLibraryA");

param.pFunc[1] = GetProcAddress(hMod, "GetProcAddress");

// Open Process

hProcess = OpenProcess(PROCESS_ALL_ACCESS,

FALSE,

dwPID);

// Allocation for THREAD_PARAM

pRemoteBuf[0] = VirtualAllocEx(hProcess,

NULL,

sizeof(THREAD_PARAM),

MEM_COMMIT,

PAGE_READWRITE);

WriteProcessMemory(hProcess,

pRemoteBuf[0],

(LPVOID)&param,

sizeof(THREAD_PARAM),

NULL);

// Allocation for g_InjectionCode

pRemoteBuf[1] = VirtualAllocEx(hProcess,

NULL,

sizeof(g_InjectionCode),

MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

WriteProcessMemory(hProcess,

pRemoteBuf[1],

(LPVOID)&g_InjectionCode,

sizeof(g_InjectionCode),

NULL);

hThread = CreateRemoteThread(hProcess,

NULL,

(LPTHREAD_START_ROUTINE)pRemoteBuf[1],

pRemoteBuf[0],

NULL);

WaitForSingleObject(hThread, INFINITE);

CloseHandle(hThread);

CloseHandle(hProcess);

return TRUE;

}

<코드 1>

위의 코드와 지난번 CodeInjection.cpp 의 코드와의 가장 큰 차이점은 인젝션 시키는 코드 내에 필요한 문자열 데이터를 같이 포함시킨 것입니다.

따라서 _THREAD_PARAM 구조체에서 문자열 멤버가 사라졌습니다. 그리고 기존 C로 된 ThreadProc() 함수 대신 <Fig. 4> 의 OpCode 버퍼(g_InjectionCode)가 사용됩니다. (이 OpCode 버퍼를 생성하기 위해 OllyDbg 의 “Assembly” 명령을 사용했던 것을 기억하시죠?)

조금 더 정교하게 프로그래밍을 했다면 _THREAD_PARAM 구조체조차 필요 없도록 만들 수도 있습니다. 세부적인 구현 방법은 어디까지나 구현하는 사람의 마음입니다.

중요한 것은 어셈블리 프로그래밍을 통해서 생성된 OpCode 버퍼를 Injector 소스코드에 사용하여 상대방 프로세스에 인젝션 시킨다는 것입니다.

예전에 설명 드린 CodeInjection.cpp 소스 코드와 비교해서 보시면 차이점을 더 명확히 이해할 수 있을 것입니다. (위 <코드 1> 의 세부 설명은 생략합니다. Code Injection 의 구현 방법에 대해서는 밑의 링크된 설명을 참고하시기 바랍니다.)

☞ 참고 : Code Injection 기법 (2)

다음 강좌에서 실제로 상대방 프로세스에 인젝션 시킨 후 디버깅을 하면서 저 어셈블리 코드가 어떤 의미를 가지고 있는지 알아보도록 하겠습니다.

☞ 어셈블리 언어를 이용한 Code Injection (4)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

어셈블리 언어를 이용한 Code Injection (2)

reversecore — Mon, 28 Jun 2010 23:00:45 +0900

지난 강좌에 이어지는 내용입니다.

☞ 어셈블리 언어를 이용한 Code Injection (2)

ThreadProc()

Assembly 언어로 ThreadProc() 함수를 만들겠습니다. 지난 강좌에서 C 로 만든 ThreadProc() 과의 차이점은 Code 사이에 필요한 Data(문자열)를 포함 시키는 것입니다.

각자 아래 그림과 같이 입력해 주시기 바랍니다. 각 Assembly 명령어에 대한 설명은 뒤쪽에서 하겠습니다. (“Fill with NOP’s” 옵션은 uncheck 해주시고, 오타가 나면 그 주소에 가서 다시 입력하시면 됩니다.)

<Fig. 5>

40102E 주소의 CALL 0040103F 명령어까지 잘 입력하셨나요? 그 다음에는 문자열을 입력합니다. Assemble 윈도우를 닫아주세요. OllyDbg의 코드 윈도우에서 401033 주소에 커서를 위치시킨 후 아래 그림과 같이 "Edit" 명령(단축키 : [Ctrl+E])을 내려줍니다.

<Fig. 6>

위 그림의 Edit 윈도우에서 "ASCII" 항목에 "ReverseCore" 를 입력합니다. 문자열은 반드시 NULL 로 끝나야 하므로 "HEX" 항목에서 00 값을 추가해 줍니다. ("Keep size" 옵션은 uncheck 로 해주세요.)

이와 같이 입력한 후 OllyDbg 에서 코드를 보면 아래 그림과 같습니다.

<Fig. 7>

위 그림에서 푸른색으로 반전된 영역이 바로 "ReverseCore" 문자열 영역입니다. 매우 이상한 명령어로 표시된 것을 볼 수 있습니다. 이렇게 표시되는 이유는 OllyDbg 의 Disassembler 가 문자열을 IA-32 명령어로 잘 못 해석한 것입니다. 이것은 어디까지나 Code 위치에 문자열을 입력한 저의 잘못(?)이지 OllyDbg 의 Disassembler 의 문제는 아닙니다.

* 참고

디버깅을 할 때 이와 같은 상황을 종종 부딪히게 됩니다. 또한 이를 이용한 Anti-Debugging 기법도 있습니다. 향후 Anti-Debugging 에 대해서 설명할 때 소개해 드리겠습니다.

위 <Fig. 7> 화면처럼 문자열을 선택한 상태에서 "Analysis" 명령(단축키 : Ctrl+A)을 내려보겠습니다.

* 참고

OllyDbg 의 “Analysis” 명령은 코드를 다시 해석하라는 명령입니다. 주로 Unpack 된 코드를 재 해석할 때 많이 사용하게 됩니다.

<Fig. 8>

위 그림은 Analysis 명령이 수행된 이후에 코드의 모습입니다. 401033 주소의 "ReverseCore" 문자열은 잘 보입니다만, 401000 주소 이후의 명령어들은 잘 못 해석이 되었습니다. (OllyDbg 2.0 에서도 코드와 데이터를 100% 정확히 구별해서 보여주지는 못합니다. 사실 이게 문자열인지 명령어인지 판단하기 어렵습니다.)

위 <Fig. 8> 은 코드를 보기 어려우므로 마우스 우측 메뉴의 "Analysis – Remove analysis from module" 명령을 사용하여 코드를 원래대로 되돌립니다.

<Fig. 9>

위 Remove analysis 명령을 사용하면 다시 위의 <Fig. 7> 과 같은 형태의 코드로 보이게 됩니다.

이제 401033 주소의 "ReverseCore" 문자열 뒤의 40103F 주소부터 다시 입력할 차례입니다. (<Fig. 7>, <Fig. 8> 의 40102E 주소의 CALL 40103F 명령어 참고)

<Fig. 10>

그리고 401044 주소에 문자열("www.reversecore.com")을 입력합니다. (마지막에 NULL 입력을 잊지 마시구요.)

<Fig. 11>

401058 주소부터 아래와 같이 명령어를 입력합니다.

<Fig. 12>

이것으로써 ThreadProc() 코드 입력이 모두 완료되었습니다. 아래 그림에 전체 코드가 나타나 있으니 각자 오타를 점검해보시기 바랍니다.

<Fig. 13>

* 참고

401033, 401044 주소의 내용은 명령어가 아니고 문자열입니다. OllyDbg 에서 문자열을 명령어로 인식하여 이상하게 표시하고 있습니다.

Save File

위에서 생성한 코드를 잘 저장합니다. OllyDbg 의 코드 윈도우에서 마우스 우측 버튼 메뉴 중 "Copy to executable \ All modifications" 를 선택합니다. (아래 그림 참고)

<Fig. 14>

아래 그림과 같이 확인 메시지 창이 뜹니다. "Copy all" 을 선택해 주세요.

<Fig. 15>

마지막으로 변경 내용을 보여주는 창이 나타납니다. 마우스 우측 메뉴의 "Save file" 항목을 선택합니다. (아래 그림 참고)

<Fig. 16>

이후에 나타나는 파일 저장 다이알로그에서 적당한 파일 이름(asmtest_patch.exe)을 적어준 후 저장합니다.

asmtest_patch.exe

다음 강좌에서 asmtest_patch.exe 의 어셈블리 코드를 이용해서 Injector 를 만들어 보도록 하겠습니다.

* 참고 : 새롭게 소개된 OllyDbg 명령어

Assemble [Space]

Analysis [Ctrl+A]

New origin here [Ctrl+Gray *]

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

어셈블리 언어를 이용한 Code Injection (1)

reversecore — Sun, 27 Jun 2010 17:23:55 +0900

어셈블리(Assembly) 프로그래밍 언어를 이용하여 Code Injection 기법에 사용되는 코드를 생성해 보도록 하겠습니다.

Code Injection 관련 내용은 아래 강좌를 참고하시기 바랍니다.

☞ Code Injection 기법 (1)

☞ Code Injection 기법 (2)

☞ Code Injection 기법 (3)

Goal

이번 강좌에서는 OllyDbg 의 Assemble 기능을 이용하여 Assembly 언어로 인젝션 시킬 코드(ThreadProc() 함수)를 만들어 보도록 하겠습니다. Assembly 언어는 C 언어보다 훨씬 더 자유로운 (정형화 되지 않은) 코드를 생성할 수 있습니다. (예: 스택(Stack), 레지스터(Register) 를 직접 access 가능) 그리고 CodeInjection.cpp 소스코드를 수정하여 Assembly 언어로 제작된 ThreadProc() 함수를 notepad.exe 프로세스에 인젝션 시켜보도록 하겠습니다.

이전 강좌에서 설명 드린 (C 언어로 생성된) ThreadProc() 과 어떤 차이점이 있는지 잘 살펴보시기 바랍니다.

Assembly 프로그래밍

C/C++ 언어의 대표적인 개발 툴은 MicroSoft Visual C++ 와 Borland C++ Builder 입니다.

Assembly 언어에도 MASM(MicroSoft Macro Assembler), TASM(Borland Turbo Assembler), FASM(Flat Assembler) 등의 개발 툴(Assembler)이 있습니다.

참고로 저는 C/C++ 언어는 MS Visual C++ 로 개발하고 Assembly 언어는 MASM 으로 개발합니다. 특히 MASM 은 다양한 Macro 함수와 라이브러리를 지원하기 때문에 거의 C 언어와 비슷한 수준으로 편리하게 프로그래밍을 할 수 있습니다.

Assembly 프로그래밍을 정식으로 하시려면 MASM 을 설치하고 프로그래밍 하시면 됩니다. 또는 Visual C++ 와 같은 C 언어 개발 툴에서 인라인 어셈블리(Inline Assembly)를 사용할 수 도 있습니다. 이런 방식은 개발자에게 잘 어울리는 방식입니다.

우리는 모두 리버서(Reverser)이기 때문에 이번 강좌에서는 리버서에게 좀 더 잘 어울리는 방법을 소개하겠습니다. 바로 OllyDbg 에서 지원하는 "Assemble" 기능을 이용해서 프로그래밍을 하는 것입니다.

* 참고

OllyDbg 의 "Assemble" 기능은 간단한 Assembly 프로그래밍을 지원하는데, 이는 리버싱에 매우 유용하게 사용됩니다. (디버깅하면서 코드를 이리저리 수정할 일이 많기 때문이지요.)

OllyDbg 의 "Assemble" 명령

OllyDbg 의 “Assemble” 명령어를 이용하여 Assembly 프로그래밍을 해보겠습니다.

asmtest.exe

위에 첨부된 asmtest.exe 실행 파일을 OllyDbg 로 열어보겠습니다. (asmtest.exe 는 Assembly 프로그래밍 테스트 용도로 제작된 -아무런 기능이 없는- 실행 파일입니다.)

<Fig. 1>

위 그림과 같이 코드 섹션의 맨 윗부분(401000)을 봐주시기 바랍니다. OllyDbg 의 새로운 명령어를 소개해 드리겠습니다. 바로 EIP 를 원하는 주소로 바꿔버리는 기능입니다.

OllyDbg 의 코드 윈도우에서 401000 주소에 커서를 위치시킨 후 마우스 우측 메뉴의 "New origin here [Ctrl+Gray*]" 항목을 선택해 주세요.

<Fig. 2>

아래 그림과 같이 EIP는 401000 주소로 변하게 됩니다.

<Fig. 3>

위 EIP 변경 기능은 디버깅에 유용하게 사용될 수 있으므로 잘 기억해 두시기 바랍니다.

* 참고!

"New origin here" 기능은 단순히 EIP 만 바꿔버리는 것이기 때문에 직접 디버깅을 해서 그 주소로 가는 것과는 틀립니다. 레지스터와 스택의 내용은 전혀 바뀌지 않기 때문입니다.

이제 401000 주소에서 "Assemble" 명령(단축키 : [Space])을 내리면 아래 그림과 같은 Assemble 입력 창이 나타납니다.

<Fig. 4>

이제부터 OllyDbg 에서 간단한 Assembly 프로그래밍을 할 수 있게 되었습니다.

* 참고

위 <Fig. 4> 에서 "Fill with NOP’s" 항목은 uncheck 해주시기 바랍니다. OllyDbg 의 Assemble 명령은 해당 주소에 사용자 코드를 입력하는 것입니다. 만약 이 항목이 check 되어 있으면 기존의 코드 보다 짧은 길이의 코드를 입력했을 때 남은 길이만큼 NOP (No Operation) 명령어를 채워 넣어서 전체적인 Code Alignment 를 맞춰주게 됩니다. 이번 강좌에서는 설명의 편의를 위해서 uncheck 상태로 진행하도록 하겠습니다.

(내용이 많아 다음 강좌에 이어서 하겠습니다.)

Code Injection 기법 (3)

reversecore — Thu, 24 Jun 2010 10:43:46 +0900

Code Injection 기법에 의해서 인젝션된 코드를 디버깅 하는 방법에 대해서 알아보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ Code Injection 기법 (1)

☞ Code Injection 기법 (2)

Code Injection 디버깅 실습

CodeInjection.exe

1. notepad.exe 디버깅

OllyDbg 를 이용하여 notepad.exe 파일의 디버깅을 시작합니다. 아래 그림과 같이 실행[F9] 버튼을 선택해서 notepad.exe 를 "Running" 상태로 만들어주세요.

<Fig. 1>

2. OllyDbg 옵션 변경

Code Injection 은 상대방 프로세스에 새로운 스레드를 생성하는 기법이므로 아래와 같이 OllyDbg 의 옵션을 변경하면 인젝션된 스레드 코드 시작부터 디버깅이 가능합니다.

<Fig. 2>

이제부터 notepad.exe 프로세스에서 스레드가 생성된다면 해당 스레드 함수 시작코드에서 멈추게 됩니다.

3. CodeInjection.exe 실행

Process Explorer 를 이용하여 notepad.exe 프로세스의 PID 를 구합니다.

<Fig. 3>

PID 값을 실행 파라미터로 하여 CodeInjection.exe 를 실행합니다.

<Fig. 4>

4. 스레드 시작 코드

CodeInjection.exe 프로세스가 실행되어 코드 인젝션이 성공하면 아래 그림과 같이 인젝션된 스레드 코드 시작 위치에서 디버깅이 멈추게 됩니다.

<Fig. 5>

주의 하실점은 디버깅이 멈춘 것이지 EIP 가 이곳으로 세팅된 것이 아닙니다.

위 그림의 150000 주소에 BP 를 설치한 후 실행[F9] 시켜 주세요. 실행 제어가 정확히 BP 설치 주소(150000)에 멈추게 되고 이제부터 펀안하게 디버깅을 진행하시면 됩니다.

* 참고!

실행 환경에 따라서 위 주소는 다르게 표시될 수 있습니다.

OllyDbg 의 편리한 기능을 이용하여 인젝션된 코드를 디버깅 하는 방법에 대해서 살펴보았습니다.

다음 강좌에는 C 언어가 아닌 Assembly 언어를 이용해서 인젝션 코드를 만들어 보도록 하겠습니다. 많이 기대해 주세요~

☞ DLL Injection – 다른 프로세스에 침투하기 (1)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Code Injection 기법 (2)

reversecore — Wed, 23 Jun 2010 00:15:20 +0900

Code Injection 실습 예제인 CodeInjection.exe 의 소스 코드(CodeInjection.cpp)를 살펴보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ Code Injection 기법 (1)

CodeInjection.cpp

CodeInjection.zip

* 참고!

CodeInjection.cpp 는 Visual C++ 2008 Express Edition 으로 개발되었으며 Windows 7 32bit 환경에서 테스트 되었습니다. 또한 Visual C++ 의 코드 최적화 기능을 사용하지 않고 빌드 하였습니다. (/Od)

아래 소개되는 코드들은 설명의 편의를 위하여 에러 처리 부분을 생략하였습니다. 완전한 코드는 첨부된 CodeInjection.cpp 파일을 참고하시기 바랍니다.

main()

먼저 main() 함수를 살펴 보겠습니다.

int main(int argc, char *argv[])

{

DWORD dwPID = 0;

if( argc != 2 )

{

printf("\n USAGE : %s <pid>\n", argv[0]);

return 1;

}

// code injection

dwPID = (DWORD)atol(argv[1]);

InjectCode(dwPID);

return 0;

}

<코드 1 – main() 함수>

main() 함수의 역할은 InjectCode() 함수를 호출하는 것입니다. 이때 함수 파라미터로 상대방 프로세스의 PID 값을 넘겨줍니다.

ThreadProc()

이제 상대방 프로세스에 인젝션 시킬 코드(스레드 함수)를 살펴보겠습니다.

// Thread Parameter

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

char szBuf[4][128]; // "user32.dll", "MessageBoxA",

// "www.reversecore.com", "ReverseCore"

} THREAD_PARAM, *PTHREAD_PARAM;

// LoadLibraryA()

typedef HMODULE (WINAPI *PFLOADLIBRARYA)

(

LPCSTR lpLibFileName

);

// GetProcAddress()

typedef FARPROC (WINAPI *PFGETPROCADDRESS)

(

HMODULE hModule,

LPCSTR lpProcName

);

// MessageBoxA()

typedef int (WINAPI *PFMESSAGEBOXA)

(

HWND hWnd,

LPCSTR lpText,

LPCSTR lpCaption,

UINT uType

);

// Thread Procedure

DWORD WINAPI ThreadProc(LPVOID lParam)

{

PTHREAD_PARAM pParam = (PTHREAD_PARAM)lParam;

HMODULE hMod = NULL;

FARPROC pFunc = NULL;

// LoadLibrary(“user32.dll”)

// pParam->pFunc[0] = kernel32!LoadLibraryA()

// pParam->szBuf[0] = “user32.dll”

hMod = ((PFLOADLIBRARYA)pParam->pFunc[0])(pParam->szBuf[0]);

// GetProcAddress(“MessageBoxA”)

// pParam->pFunc[1] = kernel32!GetProcAddress()

// pParam->szBuf[1] = “MessageBoxA”

pFunc = (FARPROC)((PFGETPROCADDRESS)pParam->pFunc[1])(hMod, pParam->szBuf[1]);

// MessageBoxA(NULL, “www.reversecore.com”, “ReverseCore”, MB_OK)

// pParam->pFunc[1] = kernel32!GetProcAddress()

// pParam->szBuf[1] = “MessageBoxA”

((PFMESSAGEBOXA)pFunc)(NULL, pParam->szBuf[2], pParam->szBuf[3], MB_OK);

return 0;

}

<코드 2 – ThreadProc() 함수>

위 코드에서 실제로 인젝션 되는 부분은 ThreadProc() 함수입니다. 그 위의 typedef 문은 C 언어 문법을 위한 것이므로 인젝션 시킬 필요가 없습니다.

ThreadProc() 의 코드는 함수 포인터를 많이 사용해서 얼핏 복잡하게 보이지만 사실 내용은 아래와 같이 간단합니다.

hMod = LoadLibraryA(“user32.dll”);

pFunc = GetProcAddress(hMod, “MessageBoxA”);

pFunc(“www.reversecore.com”, “ReverseCore”);

<코드 2> 의 주석을 참조하시면 ThreadProc() 의 코드는 쉽게 이해가 가실 것입니다.

중요한 것은 ThreadProc() 코드의 개념입니다.

Code Injection 기법의 핵심은 독립 실행 코드를 인젝션 시키는 것입니다.

그러기 위해서 코드와 (코드에서 참조하는) 데이터를 같이 인젝션 시키는 것입니다. 그리고 인젝션 시키는 코드에서 역시 인젝션 시킨 데이터를 정확히 참조할 수 있도록 해야 합니다.

위 ThreadProc() 함수를 보시면 직접 API 를 호출 하지 않습니다. 또한 문자열도 직접 정의해서 사용하지 않습니다. 전부 스레드 파라미터로 넘어온 THREAD_PARAM 구조체에서 가져다 사용하고 있습니다.

만약 일반적인 프로그램이라면 ThreadProc() 의 코드는 아래와 같이 간단히 작성할 수 있습니다.

DWORD WINAPI ThreadProc(LPVOID lParam)

{

MessageBoxA(NULL, "www.reversecore.com", "ReverseCore", MB_OK);

return 0;

}

<코드 3 – 일반적인 프로그램에서의 ThreadProc()>

위 <코드 3>을 빌드하여 생성된 파일을 디버거로 보면 아래 그림과 같습니다.

<Fig. 1>

위 그림의 코드(10001000 ~ 10001018 영역)를 다른 프로세스에 그대로 인젝션 시킨다면 정상적으로 실행되지 않습니다. 그 이유는 코드에서 사용되는 10009290, 1000929C, 100080F0 주소의 내용이 상대방 프로세스에는 없기 때문입니다.

따라서 저 주소에 해당하는 문자열과 API 주소를 같이 인젝션 시켜야 합니다. 또한 <Fig. 1>의 코드 역시 그 인젝션된 데이터의 주소를 정확히 참조하도록 프로그래밍 되어야 합니다.

이와 같은 조건을 만족시키기 위해서 <코드 2> 의 ThreadProc() 함수는 THREAD_PARAM 구조체를 이용해서 2 개의 API 주소와 4 개의 문자열 데이터를 받아들입니다. 2 개의 API 는 바로 “LoadLibraryA()” 와 “GetProcAddress()” 입니다. 이 2 개의 API 만 있으면 모든 라이브러리의 함수를 호출 할 수 있습니다.

* 참고 사항

1. 위 실습 예제의 경우에 LoadLibraryA() 와 GetProcAddress() 의 주소 말고 MessageBoxA() 의 주소를 직접 전달하여 사용해도 됩니다. 하지만 정석은 LoadLibraryA() 와 GetProcAddress() 만을 전달한 후 이를 이용해서 필요한 DLL 을 로딩시켜 원하는 함수 주소를 직접 구하는 것입니다. 이 방식의 장점은 해당 라이브러리를 프로세스에 정확히 로딩시킨다는 것입니다. 가령 notepad.exe 프로세스에 윈도우 소켓 API 인 ws2_32!connect() 의 주소를 넘겨주면 에러가 발생할 것입니다. (notepad.exe 에 기본적으로 ws2_32.dll 이 로딩되지 않았으니까요.)

2. 대부분의 유저 모드 프로세스는 kernel32.dll 을 로딩하므로 LoadLibraryA(), GetProcAddress() 의 주소를 직접 넘기는 것은 크게 무리가 없습니다. 단, kernel32.dll 을 로딩하지 않는 시스템 프로세스(예: smss.exe)도 있으니 사전에 꼭 확인하시기 바랍니다.

3. Kernel32.dll 같은 시스템 라이브러리는 OS 가 부팅되어 있는 상태에서는 모든 프로세스에서 동일한 주소에 로딩되어 있습니다. OS 버전이 틀리거나 재부팅(Vista, 7 의 경우)을 하거나 하면 같은 모듈이라도 로딩 주소는 틀려집니다.

위 <코드 2> 의 내용을 디버거로 살펴보면 아래 그림과 같습니다.

<Fig. 2>

위의 <Fig. 2> 의 코드를 보시면 모든 중요한 데이터는 스레드 파라미터인 pParam 으로 받아서 사용하는 것을 알 수 있습니다. 즉, <Fig. 2> 의 ThreadProc() 함수는 독립 실행 코드라고 말 할 수 있습니다. 위의 <Fig. 2> 와 앞에서 소개한 <Fig. 1> 를 비교해 보시면 그 차이점을 확인하실 수 있습니다.

* 참고!

Visual C++ 2008 Express Edition 에서 프로젝트의 [Release/Debug] 모드와 [최적화] 옵션에 따라서 CodeInjection.cpp 파일은 <Fig. 2> 와는 다른 형태로 빌드 될 수 있습니다. 위 실습 예제는 Release 모드에서 최적화 옵션 사용 안함(/Od)으로 빌드 하였습니다.

InjectCode()

아래는 Code Injection 기법의 핵심인 InjectCode() 함수입니다.

BOOL InjectCode(DWORD dwPID)

{

HMODULE hMod = NULL;

THREAD_PARAM param = {0,};

HANDLE hProcess = NULL;

HANDLE hThread = NULL;

LPVOID pRemoteBuf[2] = {0,};

DWORD dwSize = 0;

hMod = GetModuleHandleA("kernel32.dll");

// set THREAD_PARAM

param.pFunc[0] = GetProcAddress(hMod, "LoadLibraryA");

param.pFunc[1] = GetProcAddress(hMod, "GetProcAddress");

strcpy_s(param.szBuf[0], "user32.dll");

strcpy_s(param.szBuf[1], "MessageBoxA");

strcpy_s(param.szBuf[2], "www.reversecore.com");

strcpy_s(param.szBuf[3], "ReverseCore");

// Open Process

hProcess = OpenProcess(PROCESS_ALL_ACCESS, // dwDesiredAccess

FALSE, // bInheritHandle

dwPID); // dwProcessId

// Allocation for THREAD_PARAM

dwSize = sizeof(THREAD_PARAM);

pRemoteBuf[0] = VirtualAllocEx(hProcess, // hProcess

NULL, // lpAddress

dwSize, // dwSize

MEM_COMMIT, // flAllocationType

PAGE_READWRITE); // flProtect

WriteProcessMemory(hProcess, // hProcess

pRemoteBuf[0], // lpBaseAddress

(LPVOID)&param, // lpBuffer

dwSize, // nSize

NULL); // [out] lpNumberOfBytesWritten

// Allocation for ThreadProc()

dwSize = (DWORD)InjectCode - (DWORD)ThreadProc;

pRemoteBuf[1] = VirtualAllocEx(hProcess, // hProcess

NULL, // lpAddress

dwSize, // dwSize

MEM_COMMIT, // flAllocationType

PAGE_EXECUTE_READWRITE); // flProtect

WriteProcessMemory(hProcess, // hProcess

pRemoteBuf[1], // lpBaseAddress

(LPVOID)ThreadProc, // lpBuffer

dwSize, // nSize

NULL); // [out] lpNumberOfBytesWritten

hThread = CreateRemoteThread(hProcess, // hProcess

NULL, // lpThreadAttributes

0, // dwStackSize

(LPTHREAD_START_ROUTINE)pRemoteBuf[1],

pRemoteBuf[0], // lpParameter

0, // dwCreationFlags

NULL); // lpThreadId

WaitForSingleObject(hThread, INFINITE);

CloseHandle(hThread);

CloseHandle(hProcess);

return TRUE;

}

<코드 4 - InjectCode() 함수>

위 코드는 DLL Injection 코드와 매우 유사합니다.

InjectCode() 함수의 앞 부분은 THREAD_PARAM 구조체 변수를 세팅하고 있습니다. 이 값들은 상대방 프로세스에 인젝션 되어 ThreadProc() 스레드 함수에 파라미터로 전달될 것입니다.

* 참고!

Windows 7 에서 모든 프로세스에 로딩된 kernel32.dll 의 주소가 동일하므로 CodeInjection.exe 프로세스에서 구한 API(“LoadLibraryA”, “GetProcAddress”) 주소와 notepad.exe 프로세스에서 구한 API(“LoadLibraryA”, “GetProcAddress”) 주소가 서로 동일하다는 것을 기억하시기 바랍니다.

그리고 API 함수 호출이 이어지는데요, 핵심 API 함수들의 호출 흐름만 살펴보면 아래와 같습니다.

OpenProcess()

// data : THREAD_PARAM

VirtualAllocEx()

WriteProcessMemory()

// code : ThreadProc()

VirtualAllocEx()

WriteProcessMemory()

CreateRemoteThread()

위 코드의 핵심은 상대방 프로세스에 data 와 code 를 각각 메모리 할당하고 인젝션 시켜 준다는 것입니다.

마지막으로 CreateRemoteThread() API 를 이용해서 원격 스레드를 실행시킵니다.

+---+

이로써 Code Injection 기법을 이용한 실습 예제 소스코드에 대한 설명을 마치도록 하겠습니다.

설명의 편의성을 위하여 매우 기초적인 실습 예제를 소개하였습니다. Code Injection 의 개념을 이해하시는데 어려움이 없을 거라 생각됩니다. 위 개념을 이해하셨다면 다양한 아이디어로 자신만의 Code Injection 기법을 연습해 보시기 바랍니다

* 참고!

제가 Code Injection 기법을 구현할 때 인젝션 시킬 코드 부분은 어셈블리 언어로 프로그래밍 합니다. 복잡한 것은 MASM 을 사용하고, 간단한 것은 OllyDbg 의 “Assemble” 명령을 사용합니다. (단축키 [Space]) 이렇게 만들어진 Hex 코드 버퍼를 위 InjectCode() 함수 내에서 상대방 프로세스에 인젝션 시켜줍니다. 이러한 방법은 좀 더 직관적인 인젝션 코드를 만드는데 도움이 됩니다. Code Injection 마지막 강좌에서 간단히 실습해보도록 하겠습니다.

다음 강좌에서는 Code Injection 기법을 디버깅 하는 방법에 대해서 알아보도록 하겠습니다.

☞ Code Injection 기법 (3)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Code Injection 기법 (1)

reversecore — Tue, 22 Jun 2010 00:25:44 +0900

Code Injection 기법에 대해 설명하고 실습 예제를 분석하겠습니다. DLL Injection 기법과 어떻게 다른지 비교 분석해보겠습니다.

* 본문 내용을 편하게 읽기 위해서는 아래의 배경지식이 필요합니다.

☞ DLL Injection in Windows 7 (1)

Code Injection

Code Injection 이란 상대방 프로세스에 독립 실행 코드를 삽입한 후 실행 시키는 기법입니다. 일반적으로 CreateRemoteThread() API 를 이용하여 원격 스레드 형태로 실행 시키므로 Thread Injection 이라고도 얘기합니다.

아래 그림은 Code Injection 의 개념을 보여주고 있습니다.

<Fig. 1>

인젝션 대상이 되는 target.exe 프로세스에 코드와 데이터를 삽입합니다. 이때 코드의 형식은 스레드 프로시져(Thread Procedure) 형식으로 해주고, 코드에서 사용되는 데이터는 스레드의 파라미터로 전달해 주면 됩니다. 즉, 코드와 데이터를 각각 인젝션 시켜주는 것입니다.

이와 같이 개념은 간단한데, 구현에 있어서 주의해야 할 내용이 있습니다. Code Injection 구현의 주의 사항에 대해서 DLL Injection 과 비교하여 설명 드리겠습니다.

☞ 참고 : DLL Injection – 다른 프로세스에 침투하기 (1)

DLL Injection vs Code Injection

아래와 같이 간단한 코드가 있습니다. 코드의 내용은 윈도우 메시지 박스를 출력하는 것입니다.

DWORD WINAPI ThreadProc(LPVOID lParam)

{

MessageBoxA(NULL, "www.reversecore.com", "ReverseCore", MB_OK);

return 0;

}

DLL Injection 기법이라면 위 코드를 DLL 파일 형태로 만든 후 다른 프로세스에 인젝션 시키면 됩니다.

OllyDbg 를 실행시켜 위 ThreadProc() 코드 영역을 살펴보겠습니다.

<Fig. 2>

위 그림의 코드에서 사용되는 주소를 주목하시기 바랍니다.

먼저 10001002 주소의 PUSH 10009290 명령어와 그 밑의 PUSH 1000929C 명령어에 사용된 10009290, 1000929C 주소를 보겠습니다. 이 명령어들은 MessageBoxA() API 에 사용될 문자열(“ReverseCore”, “www.reversecore.com”) 주소를 스택에 저장시킵니다.

<Fig. 3>

위 그림을 보시면 이 문자열들의 주소(10009290, 1000929C)는 DLL의 데이터 섹션 영역에 위치합니다.

이번에는 <Fig. 2> 에서 1000100E 주소의 CALL DWORD PTR DS:[100080F0] 명령어에 사용된 100080F0 주소를 보겠습니다. 참고로 이 CALL 명령어는 바로 user32!MessageBoxA() API 호출 명령입니다.

<Fig. 4>

위 그림에서 100080F0 주소는 바로 DLL 의 IAT(Import Address Table) 영역임을 알 수 있습니다. (그 위로 다른 API 들의 주소를 확인 할 수 있습니다.)

이와 같이 DLL 의 코드에서 사용되는 모든 데이터는 DLL 의 데이터 영역에 위치합니다.

따라서 DLL Injection 기법으로 DLL 을 통째로 상대방 프로세스 메모리에 삽입시키면 코드와 데이터가 같이 메모리에 존재하기 때문에 코드는 정상적으로 실행될 수 있습니다.

Code Injection 은 필요한 코드(<Fig. 2>)를 인젝션 시키는 것입니다. 하지만 코드에서 사용되는 데이터(<Fig. 3>, <Fig. 4>) 도 같이 인젝션 시켜줘야 정상적으로 코드의 실행이 가능해집니다. (또한 인젝션된 데이터의 주소를 코드에서 잘 알아볼 수 있도록 프로그래밍 해야 합니다.)

이러한 이유 때문에 DLL Injection 기법 보다 고려할 사항이 좀 더 많습니다.

아래의 실습 예제 코드를 보시면 더 확실히 파악하실 수 있습니다.

코드 인젝션을 사용하는 이유

코드 인젝션은 DLL 인젝션과 비교하여 기능은 비슷하면서 고려해야 할 사항은 더 많기 때문에 사용하기 불편하게 느껴질 수 있습니다. 과연 코드 인젝션의 장점은 무엇일까요?

1) 메모리를 적게 차지한다.

아주 작은 크기의 코드와 데이터를 인젝션 할 때는 DLL 로 만들어서 인젝션 시킬 필요가 없습니다. 간단히 코드 인젝션으로 구현하면 DLL 인젝션과 같은 기능을 제공하면서 메모리를 훨씬 적게 차지합니다.

2) 흔적을 찾기 어렵다.

DLL 인젝션은 해당 프로세스 메모리에 흔적을 남기기 때문에 간단히 인젝션 여부를 알 수 있습니다. 하지만 Code 인젝션은 쉽게 흔적을 남기지 않습니다. (물론 이 역시 알아낼 수 있는 방법이 있습니다.) 이 특징 때문에 악성코드에서도 코드 인젝션을 많이 사용합니다.

3) 기타

별도의 DLL 파일 없이 Code Injector 프로그램만 있으면 됩니다. 또한 처음에는 생소하지만 일단 익숙해 지게 되면 아주 쉽고 편리하게 구현이 가능합니다.

간단히 정리하면 DLL Injection 은 규모가 크고 복잡한 일을 수행할 때 사용하고, Code Injection 은 규모가 작고 간단한 일을 수행할 때 사용합니다.

실습 예제(CodeInjection.exe)

CodeInjection.exe

실습 예제는 notepad.exe 프로세스에 간단한 코드를 인젝션 시켜서 메시지 박스를 출력하는 내용입니다.

* 참고!

CodeInjection.exe 는 Visual C++ 2008 Express Edition 으로 개발되었으며 Windows 7 32bit 환경에서 테스트 되었습니다.

#1. notepad.exe 실행

notepad.exe 를 실행 시킨 후 Process Explorer 를 이용하여 notepad.exe 프로세스의 PID 를 확인합니다.

<Fig. 5>

제 테스트 환경에서 notepad.exe 의 PID 는 1896 입니다.

#2. CodeInjection.exe 실행

첨부된 CodeInjection.exe 파일을 실행시킵니다. 이때 실행 파라미터로 앞에서 구한 notepad.exe 의 PID 값을 입력합니다.

<Fig. 6>

#3. 메시지 박스 확인

<Fig. 7>

메시지 박스가 notepad.exe 윈도우의 밑에 깔려 있으므로 확인 하실 때 주의하시기 바랍니다.

다음 강좌에서 실습 예제의 소스 코드를 보면서 어떻게 구현되었는지 자세히 확인해 보도록 하겠습니다.

☞ Code Injection 기법 (2)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (4)

reversecore — Mon, 17 May 2010 01:29:58 +0900

Global API Hooking 예제 코드를 분석하면서 해당 기술에 대한 이해를 돕습니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

☞ Advanced Global API Hooking – IE 접속 제어 (3)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

전체 소스 코드는 아래 첨부된 파일을 참고하시기 바랍니다.

redirect.cpp

주요 함수에 대해 설명 드리겠습니다. 설명의 편의를 위해서 에러 처리 관련 코드는 제거하였습니다. 에러 처리 코드가 포함된 원본 함수의 전체 코드는 첨부된 파일에서 확인하시기 바랍니다.

DllMain()

먼저 DllMain() 함수를 살펴보겠습니다.

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)

{

char szCurProc[MAX_PATH] = {0,};

char *p = NULL;

switch( fdwReason )

{

case DLL_PROCESS_ATTACH :

GetModuleFileName(NULL, szCurProc, MAX_PATH);

p = strrchr(szCurProc, '\\');

if( (p != NULL) && !_stricmp(p+1, "iexplore.exe") )

{

// wininet!InternetConnectW() API 를 후킹 하기 전에

// 미리 wininet.dll 을 로딩 시킴

LoadLibrary("wininet.dll");

}

// hook

hook_by_code("ntdll.dll", "ZwResumeThread",

(PROC)NewZwResumeThread, g_pZWRT);

hook_by_code("wininet.dll", "InternetConnectW",

(PROC)NewInternetConnectW, g_pICW);

break;

case DLL_PROCESS_DETACH :

// unhook

unhook_by_code("ntdll.dll", "ZwResumeThread",

g_pZWRT);

unhook_by_code("wininet.dll", "InternetConnectW",

g_pICW);

break;

}

return TRUE;

}

DllMain() 함수의 핵심 기능은 ntdll!ZwResumeThread() 와 wininet!InternetConnectW() API 의 hook/unhook 입니다.

한가지 특이한 코드는 실행 프로세스 이름이 iexplorer.exe 인 경우 wininet.dll 을 로딩 시키는 코드입니다. iexplore.exe 프로세스가 정상적으로 실행되면 기본적으로 wininet.dll 을 로딩하고 있는데 왜 굳이 추가적으로 로딩을 시키는 걸까요? 그 이유는 Global API Hooking 때문입니다.

ntdll!ZwResumeThread() 를 이용한 API 후킹은 해당 프로세스의 메인 스레드가 시작되기 전에 제

어를 가로채기 때문에 우리가 후킹하려는 wininet.dll 모듈이 아직 로딩되어 있지 않는 상황이 발생할 수 있습니다. 이를 방지 하기 위해서 iexplore.exe 프로세스인 경우 wininet!InternetConnectW() API 를 후킹하기 전에 무조건 wininet.dll 을 로딩시키는 것입니다.

NewInternetConnectW()

wininet!InternetConnectW() 의 후킹 함수인 NewInternetConnectW() 함수에 대한 설명입니다. 이 함수는 IE 의 접속 주소를 모니터링 하면서 특정 사이트에 접속을 시도할 때 원하는 사이트로 접속을 돌리는 역할을 수행합니다.

HINTERNET WINAPI NewInternetConnectW

(

HINTERNET hInternet,

LPCWSTR lpszServerName,

INTERNET_PORT nServerPort,

LPCTSTR lpszUsername,

LPCTSTR lpszPassword,

DWORD dwService,

DWORD dwFlags,

DWORD_PTR dwContext

)

{

HINTERNET hInt = NULL;

FARPROC pFunc = NULL;

HMODULE hMod = NULL;

// unhook

unhook_by_code("wininet.dll", "InternetConnectW", g_pICW);

// call original API

hMod = GetModuleHandle("wininet.dll");

pFunc = GetProcAddress(hMod, "InternetConnectW");

if( !_wcsicmp(lpszServerName, L"www.naver.com") ||

!_wcsicmp(lpszServerName, L"www.daum.net") ||

!_wcsicmp(lpszServerName, L"www.nate.com") ||

!_wcsicmp(lpszServerName, L"www.yahoo.com") )

{

hInt = ((PFINTERNETCONNECTW)pFunc)(hInternet,

L"www.reversecore.com",

nServerPort,

lpszUsername,

lpszPassword,

dwService,

dwFlags,

dwContext);

}

else

{

hInt = ((PFINTERNETCONNECTW)pFunc)(hInternet,

lpszServerName,

nServerPort,

lpszUsername,

lpszPassword,

dwService,

dwFlags,

dwContext);

}

// hook

!hook_by_code("wininet.dll", "InternetConnectW",

(PROC)NewInternetConnectW, g_pICW;

return hInt;

}

위 함수의 코드는 매우 단순합니다. 함수의 2 번째 파라미터인 lpszServerName 문자열이 바로 접속 주소입니다. 이 접속주소를 모니터링 하여 우리나라 4 대 포탈 사이트(Naver, Daum, Nate, Yahoo)인 경우, 제 블로그(ReverseCore)로 연결을 바꿔버립니다.

hook_by_code() / unhook_by_code() 에 대한 설명은 아래 포스트를 참고하시기 바랍니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

NewZwResumeThread()

ntdll!ZwResumeThread() 의 후킹 함수인 NewZwResumeThread() 함수입니다.

NTSTATUS WINAPI NewZwResumeThread(HANDLE ThreadHandle, PULONG SuspendCount)

{

NTSTATUS status, statusThread;

FARPROC pFunc = NULL, pFuncThread = NULL;

DWORD dwPID = 0;

static DWORD dwPrevPID = 0;

THREAD_BASIC_INFORMATION tbi;

HMODULE hMod = NULL;

char szModPath[MAX_PATH] = {0,};

// call ntdll!ZwQueryInformationThread()

hMod = GetModuleHandle("ntdll.dll");

pFuncThread = GetProcAddress(hMod, "ZwQueryInformationThread");

statusThread = ((PFZWQUERYINFORMATIONTHREAD)pFuncThread)

(ThreadHandle, 0, &tbi, sizeof(tbi), NULL);

// Dll Injection to the new child process

dwPID = (DWORD)tbi.ClientId.UniqueProcess;

if ( (dwPID != GetCurrentProcessId()) && (dwPID != dwPrevPID) )

{

dwPrevPID = dwPID;

// change privilege

SetPrivilege(SE_DEBUG_NAME, TRUE);

// get injection dll path

GetModuleFileName(GetModuleHandle(STR_MODULE_NAME),

szModPath,

MAX_PATH);

// call InjectDll()

InjectDll(dwPID, szModPath);

}

// unhook

unhook_by_code("ntdll.dll", "ZwResumeThread", g_pZWRT);

// call ntdll!ZwResumeThread()

pFunc = GetProcAddress(hMod, "ZwResumeThread");

status = ((PFZWRESUMETHREAD)pFunc)(ThreadHandle, SuspendCount);

// hook

hook_by_code("ntdll.dll", "ZwResumeThread",

(PROC)NewZwResumeThread, g_pZWRT);

return status;

}

NewResumeThread() 함수의 첫 번째 파라미터는 resume 시킬 스레드의 ThreadHandle 입니다. 지난번 설명에서 이 스레드는 바로 자식 프로세스의 메인 스레드라고 설명 드렸습니다.

☞ 참고 : Advanced Global API Hooking – IE 접속 제어 (3)

따라서 NewResumeThread() 함수 초반부의 ZwQueryInformationThread() API 를 호출하는 이유는 바로 ThreadHandle 이 가리키는 스레드(자식 프로세스의 스레드) 가 소속된 자식 프로세스의 PID 를 얻기 위함입니다.

이렇게 ThreadHandle 파라미터를 이용하여 (지금 막 생성된) 자식 프로세스의 PID 를 얻어 내었습니다. 이 PID 를 이용하여 redirect.dll (후킹 DLL) 을 인젝션 시켜 줍니다. 해당 자식 프로세스는 메인 스레드가 실행되기도 전에 이미 redirect.dll 이 인젝션 되면서 자동으로 API 후킹이 걸리게 됩니다.

마지막으로 ntdll!ZwResumeThread() API 를 정상적으로 호출하여 자식 프로세스의 메인 스레드를 resume 시킵니다. 이제 자식 프로세스는 API 가 후킹된 채로 정상 실행됩니다.

High-Level API Hooking vs Low-Level API Hooking

위의 ntdll!ZwResumeThread() API 후킹 방법은 단순히 kernel32!CreateProcess() API 를 후킹하는 것보다 더 강력하고 편리한 방법입니다. 왜냐하면 CreateProcess() 는 내부적으로 CreateProcessInternal() 을 호출합니다. 만약 프로그램에서 CreateProcessInternal() 을 직접 호출한다면 정상적인 후킹이 되지 않습니다. (차라리 CreateProcessInternal() 을 후킹하는 것이 더 좋은 방법입니다. – 좋은 방법을 가르쳐 주신 iwillhackyou 님께 감사드립니다.)

이런 식으로 Low-Level API (ntdll.dll 에서 제공되는 API) 를 후킹할수록 더 강력합니다. 하지만 대부분의 Low-Level API 들은 undocumented 되어 있으며, OS 버전에 따라 변경될 가능성이 존재합니다. 반면에 High-Level API (kernel32.dll 레벨 - documented) 들은 변경될 가능성이 없고 잘 문서화 되어 있기 때문에 안정적인 후킹이 가능합니다. 대신에 후킹 성능이 좀 떨어집니다.

따라서 High-Level API 후킹과 Low-Level API 후킹은 서로 일장 일단이 있기 때문에 상황에 맞게 적절히 선택하여 구현하시는 것이 현명한 방법입니다.

+---+

다음 강좌는 Code Injection 을 통한 API 후킹에 대한 내용입니다. 지금까지는 DLL 을 인젝션 시켜서 API 후킹을 진행하였지만, 짤막한 코드를 삽입시켜 동일한 기능을 구현하는 것입니다. DLL Injection 방법과 많은 차이점이 있으며, 이 또한 흥미로운 주제가 될 것입니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (3)

reversecore — Fri, 07 May 2010 00:26:16 +0900

Global API Hooking 예제를 실습하겠습니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

실습 예제 – IE 접속 제어

redirect.dll

InjDll.exe

# 실습 내용

IE 프로세스의 특정 API 를 후킹 하여 국내 4 대 포탈 사이트(Naver, Daum, Nate, Yahoo)에 접속 시도할 때 www.reversecore.com 주소로 연결 시켜버립니다. 또한 IE 의 탭이 새로 생성되면서 동시에 프로세스가 추가되는 경우를 대비해서 Global API Hooking 기법을 사용하였습니다.

API 후킹은 redirect.dll 을 인젝션 시켜서 구현합니다. redirect.dll 은 아래 2 개의 API 를 후킹합니다.

wininet!InternetConnectW() - IE 프로세스의 접속 주소를 제어하기 위해 후킹

ntdll!ZwResumeThread() – Global API Hooking 구현을 위해 후킹

* Global API Hooking 에 대한 자세한 설명은 아래 글을 참고하세요.

☞ Advanced Global API Hooking – IE 접속 제어 (4)

#1. IE 실행

실습을 위해서 먼저 IE 를 실행시켜 주시기 바랍니다. 그리고 Process Explorer 를 이용하여 현재 실행중인 IE 프로세스의 구조를 살펴 보겠습니다.

<Fig. 1>

위 그림을 보시면 IE 프로세스는 부모-자식 관계로 실행되는 것을 알 수 있습니다. 부모 프로세스만 ntdll!ZwResumeThread() API 를 후킹해도 이후부터 생성되는 모든 IE 프로세스들은 자동으로 후킹됩니다.

#2. DLL Injection

redirect.dll 파일을 IE 프로세스(iexplore.exe) 에 인젝션 시킵니다.

<Fig. 2>

Process Explorer 를 이용해서 IE 프로세스에 redirect.dll 파일이 정상적으로 인젝션 되었는지 확인합니다.

<Fig. 3 >

#3. 새로운 탭 생성

IE 에서 새로운 탭을 생성합니다.

<Fig. 4>

Process Explorer 를 이용해서 새로 생긴 탭과 연결된 프로세스(PID:3136)에 redirect.dll 이 제대로 인젝션 되었는지 확인합니다.

<Fig. 5>

ntdll!ZwResumeThread() API 후킹을 통한 Global API Hooking 이 성공하였습니다.

#4. 포탈 사이트 접속

IE 의 아무 탭에서 국내 4 대 포탈 사이트에 접속을 시도해 보세요.

www.naver.com

www.daum.net

www.nate.com

www.yahoo.com

<Fig. 6>

위 그림에서처럼 주소는 naver 지만 실제로는 ReverseCore 사이트가 연결되었습니다.

#5. DLL Ejection

IE 프로세스에서 redirect.dll 을 내려보겠습니다.

<Fig. 7>

Process Explorer 를 이용하여 redirect.dll 가 정상적으로 ejection 되었는지 확인합니다.

<Fig. 8>

이제 다시 naver 에 접속해보면 이제는 정상적으로 접속하는 것을 확인하실 수 있습니다.

<Fig. 9>

#6. 추가 실습

위에 소개된 InjDll.exe 와 redirect.dll 파일을 이용해서 각자 좀 더 실습을 많이 해보시기 바랍니다. Global API Hooking 기법에 대한 개념을 확실히 이해하실 수 있으실 것입니다.

- 전체 프로세스 후킹

- explorer.exe 만 후킹 (이후 IE 실행)

+---+

실습 내용이 길어진 관계로 redirect.dll 파일의 소스 코드 설명은 다음 강좌에 하겠습니다. (조금 빨리 올리겠습니다.)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (2)

reversecore — Sun, 25 Apr 2010 23:40:59 +0900

Global API Hooking 에 대한 기본 개념을 정리합니다. 또한 ntdll!ZwResumeThread() API 의 후킹을 통한 Global API Hooking 기법의 원리를 살펴봅니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

Global API Hooking

Global API Hooking 에 대해서 다시 한번 간단히 정리하고 넘어가겠습니다.

지금까지의 강좌를 통해서 우리는 특정 프로세스에 대해 원하는 API 의 후킹을 간단하게 구현할 수 있게 되었습니다.

* 참고

☞ API Hooking – 계산기, 한글을 배우다 (1)

☞ API Hooking – ‘스텔스’ 프로세스 (1)

#1. 일반적인 API Hooking

일반적인 API 후킹의 문제는 후킹을 원하는 프로세스가 생성될 때마다 매번 API 후킹을 해줘야 한다는 것입니다. 아래 그림은 DLL Injection 기법을 이용한 일반적인 API Hooking 을 표현한 것입니다.

<Fig. 1>

위 그림에서 후킹 대상 프로세스는 Test.exe(PID:2492) 입니다. InjDll.exe 프로그램을 이용해서 Hook.dll 을 Test.exe 프로세스에 인젝션 시켜서 원하는 API 를 후킹 하였습니다. (1)

그런데 이후에 또 다른 Test.exe(PID:3796) 프로세스가 생성되었다면 이 프로세스에도 역시 Hook.dll 을 인젝션 시켜줘야 (PID:3796 프로세스에 대한) 정상적인 API 후킹이 이루어 질 것입니다. (2)

즉, 후킹 대상 프로세스가 새로 생성 될 때마다 계속해서 수동으로 API 후킹을 시켜야 합니다.

#2. Global API Hooking

이번에는 Global API Hooking 을 살펴보도록 하겠습니다.

<Fig. 2>

InjDll.exe 는 Windows 운영체제의 기본 쉘(Shell) 인 Explorer.exe 프로세스에 gHook.dll 을 인젝션 시킵니다. (후킹하고자 하는 Test.exe 가 아닌, Test.exe 를 실행시켜주는 프로세스인 Explorer.exe 를 후킹한다는 것이 핵심입니다.)

gHook.dll 은 <Fig. 1> 의 Hook.dll 의 기능에다가 자식 프로세스 생성에 관련된 API 를 후킹하여 자식 프로세스를 생성할 때마다 자신(gHook.dll)을 인젝션 시키는 기능을 가지고 있습니다. (위 <Fig. 2> 참조)

따라서 Windows 쉘인 Explorer.exe 프로세스에 gHook.dll 을 한번 인젝션 시켜놓으면 그 이후 Explorer.exe 에서 생성되는 모든 자식 프로세스들에게 자동으로 gHook.dll 이 인젝션 됩니다.

이것이 자동 API Hooking 의 기본 개념이며, 이를 시스템에 실행중인 모든 프로세스를 대상으로 확장한 것이 바로 Global API Hooking 입니다.

* 참고!

Explorer.exe 외에 다른 프로세스들도 자식 프로세스를 생성할 수 있습니다. 따라서 원칙적으로 Global API Hooking 을 완벽히 구현하려면 현재 실행중인 모든 프로세스들을 후킹 해야 합니다.

하지만 시스템 안정성과 불필요한 오버헤드를 막기 위해 작업 내용에 따라서 특정 프로세스만 후킹 하는 경우도 있습니다. (제가 실습 예제로 준비한 IE 후킹이 대표적인 경우입니다.)

이상으로 Global API Hooking 개념에 대해서 정리해 보았습니다.

이제부터 어떤 API 를 후킹해야 Global API Hooking 을 쉽게 구현할 수 있는지 알아보도록 하겠습니다.

ntdll!ZeResumeThread() API

자식 프로세스를 생성하는 API 에 대해서 생각해 보도록 하겠습니다.

프로세스를 생성하는 API 는 단연 kernel32!CreateProcess() API 가 대표적입니다.

* 참고 – kernel32!CreateProcess() API 를 이용한 Global API Hooking 방법

☞ API Hooking – ‘스텔스’ 프로세스 (4)

CreateProcess() API 의 디버깅을 위하여 다음과 같이 간단한 프로그램을 만들어 보겠습니다.

// cptest.cpp

#include "windows.h"

#include "tchar.h"

void main()

{

STARTUPINFO si = {0,};

PROCESS_INFORMATION pi = {0,};

TCHAR szCmd[MAX_PATH] = {0,};

si.cb = sizeof(STARTUPINFO);

_tcscpy(szCmd, L"notepad.exe");

if( !CreateProcess(NULL, // lpApplicationName

szCmd, // lpCommandLine

NULL, // lpProcessAttributes

NULL, // lpThreadAttributes

FALSE, // bInheritHandles

NORMAL_PRIORITY_CLASS, // dwCreationFlags

NULL, // lpEnvironment

NULL, // lpCurrentDirectory

&si, // lpStartupInfo

&pi) ) // lpProcessInformation

return;

if( pi.hProcess != NULL )

CloseHandle(pi.hProcess);

}

위 코드로 빌드 시킨 프로그램입니다.

cptest.exe

cptest.exe 를 디버깅 해보면 프로세스 생성과 관련된 API 들의 호출 흐름을 알 수 있습니다.

아래 그림은 cptest.exe 의 kernel32!CreateProcessW() 호출 코드입니다.

* 참고 : CreateProcessW 는 CreateProcess 의 Wide Character (유니코드)버전입니다.

<Fig. 3>

kernel32!CreateProcessW() 내부로 따라 들어가면 아래 그림과 같이 kernel32!CreateProcessInternalW() 호출 코드를 볼 수 있습니다.

<Fig. 4>

위 그림에서 아래쪽의 스택 메모리를 보시면 <Fig. 3> 의 스택(함수 파라미터)이 거의 동일하게 넘어온걸 알 수 있습니다.

kernel32!CreateProcessInternalW() 내부로 들어가 보겠습니다.

<Fig. 5>

kernel32!CreateProcessInternalW() 는 상당히 큰 함수입니다. 아래로 쭉 스크롤을 내리면 아래 그림과 같이 ntdll!ZwCreateProcess() 를 호출하는 코드가 나타납니다.

<Fig. 6>

위 그림에서 아래쪽의 스택을 보시면 <Fig. 4> 에서의 스택과는 많이 다른 형태인 것을 알 수 있습니다. 2번째 파라미터(Arg2)는 어떤 구조체 인데 왼쪽의 Hex dump 창을 보시면 구조체 멤버 중에 12F950 주소의 12FD38(“notepad”) 문자열 주소를 확인 하실 수 있습니다. (<Fig. 3> 스택 참조)

Ntdll!ZwCreateUserProcess() 가 호출되면 자식 프로세스가 SUSPEND 모드로 실행됩니다.

<Fig. 7>

notepad.exe 프로세스는 생성되었지만 아직 EP 코드가 실행되지 않은 상태입니다.

<Fig. 6> 코드에서 계속 아래로 진행하면 ntdll!ZwResumeThread() API 호출 코드가 나타납니다.

<Fig. 8>

ntdll!ZwResumeThread() 는 함수 이름 그대로 스레드를 RESUME 시켜줍니다. 이 스레드가 바로 자식 프로세스(notepad.exe) 의 메인 스레드입니다. 따라서 이 API 가 호출되면 비로소 자식 프로세스의 EP 코드가 실행됩니다.

<Fig. 9>

지금까지의 API 호출 흐름을 정리하면 아래와 같습니다.

kernel32!CreateProcessW

kernel32!CreateProcessInternalW

ntdll!ZwCreateUserProcess // 프로세스 생성됨 (메인 스레드는 suspend 상태)

ntdll!ZwResumeThread // 메인 스레드 resume 시킴 (프로세스 실행됨)

자식 프로세스 생성에 있어서 가장 마지막에 호출되는 API 가 바로 ntdll!ZwResumeThread() 입니다. 따라서 우리는 이 API 를 후킹함으로써 자식 프로세스의 EP 코드가 실행되기 직전에 제어를 가로챈 후 원하는 API 를 후킹시킬 수 있습니다.

ntdll!ZwResumeThread() 는 undocumented API 이며, 함수 정의는 아래와 같습니다.

NTSTATUS NtResumeThread(

IN HANDLE ThreadHandle,

OUT PULONG SuspendCount OPTIONAL

);

* 출처

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtResumeThread.html

* 참고

User Mode 에서 ntdll!ZwResumeThread() API 와 ntdll!NtResumeThread() API 는 동일합니다.

위에서 소개한 4 개의 API (CreateProcessW, CreateProcessInternalW, ZwCreateUserProcess, ZwResumeThread) 중에서 어떤걸 후킹해도 Global API Hooking 이 가능합니다.

다만 상위에 위치한 CreateProcessW() 함수를 후킹하면 특정 경우(CreateProcessInternalW 를 직접 호출하는 경우)에 후킹이 되지 않을 수 있습니다. 따라서 CreateProcessInternalW() 이하를 후킹하는 것이 더 좋은 방법입니다. (각자 장단점이 있을 수 있으므로 모두 연습해 두시는 것이 좋을 것 같습니다.)

다음 시간에는 Global 후킹 실습을 한 후 실제 코드를 살펴보도록 하겠습니다.

☞ Advanced Global API Hooking – IE 접속 제어 (3)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (1)

reversecore — Mon, 29 Mar 2010 20:38:13 +0900

좀 더 고급스러운 Global API Hooking 방법에 대해서 알아보겠습니다.

실습 예제로는 IE(Internet Explorer) 를 후킹하여 특정 사이트로 향하는 접속을 우회시켜 제 블로그로 접속하도록 만들겠습니다.

본 내용은 지난 번에 설명한 Global API Hooking 강좌에 추가되는 내용입니다.

Global API Hooking 의 개념에 대해서는 아래 강좌를 참고하여 주시기 바랍니다.

☞ 참고 : API Hooking – Stealth 프로세스 (2)

☞ 참고 : API Hooking – Stealth 프로세스 (4)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 x86 & IE 8 에서 테스트 되었습니다.

실습 예제

실습 목표는 IE 프로세스의 API 를 후킹하여 특정 사이트로 향하는 접속을 다른 사이트로 우회시키는 것입니다. 주소 창에 직접 입력을 하던, 링크를 클릭하던 제가 막아놓은 사이트에는 접속하지 못하도록 만드는 것입니다. (유해 사이트 차단 기능을 생각 하시면 이해하시기 쉬울 것입니다.)

* 참고!

유해 사이트 차단 기능 자체로 보면 사실 방화벽 차원에서 지원해주는 것이 훨씬 효과적입니다. 어디까지나 실습을 위한 예제이므로 실제 제품에 위 기능을 염두에 두신다면 이점을 고려하시기 바랍니다.

wininet!InternetConnect()

API Hooking 에서 가장 핵심적인 사항은 바로 후킹 대상 API 를 선정하는 것입니다.

이 부분은 사실 개개인의 노하우가 필요한 부분입니다. 개발 경험 혹은 API 후킹 경험이 많을수록 유리합니다. (요즘은 구글링으로 대부분 해결이 가능하지요.)

작업 전에 간단히 예상을 해보자면 소켓 라이브러리(ws2_32.dll) 혹은 MS 에서 제공하는 인터넷 관련 라이브러리(wininet.dll, winhttp.dll) 들을 후킹 하면 될 것 같습니다. (후자 쪽이 훨씬 수월한 작업이 되겠지요.)

IE 를 실행 시켜서 간단히 분석해 보도록 하겠습니다.

먼저 Process Explorer 를 이용하여 로딩된 DLL 들을 살펴보도록 하겠습니다.

<Fig. 1>

다행히 IE 에서는 ws2_32.dll 뿐만 아니라 Wininet.dll 도 같이 로딩하고 있습니다.

Wininet.dll 에서 제공하는 API 중에 InternetConnect() 라는 API 가 있습니다. 함수 이름 그대로 어떤 웹사이트에 접속하려고 할 때 사용하는 API 입니다.

HINTERNET InternetConnect(

__in HINTERNET hInternet,

__in LPCTSTR lpszServerName, // 접속 URL

__in INTERNET_PORT nServerPort,

__in LPCTSTR lpszUsername,

__in LPCTSTR lpszPassword,

__in DWORD dwService,

__in DWORD dwFlags,

__in DWORD_PTR dwContext

);

* 출처 : http://msdn.microsoft.com/en-us/library/aa384363(VS.85).aspx

OllyDbg 를 IE 프로세스(PID : 3484 = D9Ch)에 attach 시킨 후 wininet!InternetConnectW() API 에 BP 를 설치하겠습니다. (InternetConnectW() API 는 InternetConnect() 의 Wide Character 버전입니다.)

<Fig. 2>

이 상태에서 IE 주소 창에 접속하려는 사이트의 주소를 입력해 보겠습니다.

<Fig. 3>

위에서 설치한 BP 에 걸렸습니다. 이 때 프로세스의 스택 메모리를 살펴보겠습니다.

<Fig. 4>

스택의 정보를 보면 접속 주소(lpszServerName)는 www.google.com 이라는 것을 알 수 있습니다.

시험 삼아 이 주소를 한번 조작해 볼까요?

<Fig. 5>

위 그림과 같이 "www.google.com" 문자열을 "www.reversecore.com" 문자열로 변경합니다.

* 주의!

위 주소들은 모두 UNICODE 문자열이므로 마지막에 2 byte NULL (0000) 로 끝나야 합니다. (HEX 창에서 문자열 끝에 00 00 을 입력하시면 됩니다.)

위와 같이 접속 주소를 수정한 후 디버거를 실행 시킵니다. 아마 wininet!InternetConnectW() 에 설치된 BP 에서 계속 멈출 것입니다. 이는 보통 하나의 웹사이트가 여러 개의 링크 주소로 이루어져 있기 때문입니다. BP 를 제거 후 계속 실행 해 주세요. (스택 조작은 최초 InternetConnectW() 호출에서 한번만 하시면 됩니다.)

결과적으로 IE 는 아래 그림과 같이 (원래 의도했던) www.google.com 이 아닌 (변경된) www.reversecore.com 주소로 접속하게 됩니다.

<Fig. 6>

따라서 wininet!InternetConnectW() 를 후킹 한 후 lpszServerName 파라미터를 조작하면 IE 접속을 제어할 수 있게 됩니다.

원리는 매우 간단하지요. 다행히 IE 에서 wininet.dll 를 사용하기 때문에 쉽게 API 후킹할 수 있었습니다. 여기까지는 일반적인 API Hooking 방법과 동일합니다.

하지만 실제 구현에 있어서 한가지 중요한 고려사항이 있습니다.

바로 IE 8 의 독특한 프로세스 구조 때문에 Global API Hooking 기법을 써야 한다는 것입니다.

IE 프로세스 구조

IE 를 새롭게 실행 한 후 탭(tab) 을 여러 개 띄워서 각각 다른 사이트에 접속해 보겠습니다.

<Fig. 7>

Process Explorer 를 이용하여 IE 프로세스 구조를 살펴보겠습니다.

<Fig. 8>

위 <Fig. 7> 과 <Fig. 8> 을 보시면 IE 에 7 개의 탭이 띄워져 있고, IE 프로세스(iexplore.exe)는 총 5 개 실행되고 있습니다. 그리고 iexplore.exe 프로세스(PID:3784)는 나머지 iexplore.exe 프로세스들과 부모-자식 관계를 형성하고 있습니다.

IE 프로세스 구조를 봤을 때 IE 어플리케이션은 부모에 해당되는 메인 프로세스(PID:3784)가 각 탭들에 해당되는 자식 프로세스들을 관리하는 구조라고 볼 수 있습니다.

IE 7 부터 탭 개념을 도입하면서 위와 같은 프로세스 구조로 변경되었는데요, 이 방식의 장점은 탭 별로 독립적인 프로세스로 동작하기 때문에 하나의 탭 에서 오류가 발생하더라도 나머지 탭들과 부모 프로세스(IE 본체)에게는 영향을 끼치지 않는다는 것입니다. (최신 웹 브라우저들에서 사용되는 방법입니다.)

이와 같이 IE 프로그램은 각 탭에 해당하는 자식 iexplore.exe 프로세스가 실제 접속을 담당하므로 탭 프로세스가 생성되는 순간에 (해당 프로세스의) API 를 자동으로 후킹할 수 있어야 합니다. 즉, Global API Hooking 방법으로 구현되어야 한다는 뜻입니다. 그렇지 않다면 새로운 탭으로 접속하는 경우에는 후킹이 되지 않을 것이기 때문이지요.

지난 번에 Global API Hooking 을 구현하기 위하여 kernel32!CreateProcess() API 를 후킹하는 방법에 대해서 소개하였습니다. 하지만 CreateProcess() API 를 후킹하는 방법에는 약간의 제한 사항이 있다는 것도 같이 설명 드렸습니다.

☞ 참고 : API Hooking – Stealth 프로세스 (4)

이번 포스트의 목적은 CreateProcess() API 의 후킹을 통한 Global API Hooking 방법의 불편함을 없애고 좀 더 안정적이고 편리한 방법으로 Global API Hooking 을 구현하는데 있습니다.

그 방법이란 바로 ntdll!ZwResumeThread() API 를 후킹하여 프로세스가 생성된 후 메인 스레드가 resume 될 때 원하는 API 를 후킹하는 방법입니다.

글이 길어진 관계로 다음 시간에 ntdll!ZwResumeThread() API 의 후킹을 통한 Global API Hooking 방법에 대해 자세히 설명하도록 하겠습니다.

☞ DLL Injection – 다른 프로세스에 침투하기 (1)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

InjDll.exe – DLL Injection/Ejection 전용 도구

reversecore — Mon, 15 Mar 2010 00:23:57 +0900

제가 개발한 InjDll.exe 프로그램을 소개합니다.

이 프로그램을 이용해서 원하는 DLL 을 대상 프로세스에 Injection/Ejection 시킬 수 있습니다.

DLL Injection 에 관련된 설명을 아래 링크를 참조하세요.

☞ DLL Injection in Windows 7

InjDll.exe (Ver 1.0.0)

제 블로그 study 에서 자주 소개되는 프로그램입니다.

소스를 조금 다듬고 기능을 추가시켜서 정식 버전(1.0.0)으로 배포합니다.

InjDll.exe

이 프로그램은 공개용이며, 자유롭게 사용하실 수 있습니다.

* 주의!

기본적으로 Windows 2000 이상만 지원합니다. (Windows 7, XP 에서 테스트 되었습니다.)

Windows 9X 계열에서는 사용하실 수 없습니다.

사용방법은 아래와 같습니다.

InjDll.exe <procname|pid|*> <-i|-e> <dll path>

<procname|pid|*>
procname Process name (ex: explorer.exe, notepad.exe, etc)
pid Process ID

<-i|-e>
-i Injection Mode

-e Ejection Mode

<dll path> DLL File Path (relative or full)

사용 예

dummy.dll

- PID 2840 프로세스에게 dummy.dll 파일을 Injection 시킬 때

- IE 프로세스에게 dummy.dll 파일을 Injection 시킬 때

- 모든 프로세스에게 dummy.dll 파일을 Injection 시킬 때

Ejection 은 –i 대신 –e 를 사용하면 됩니다.

InjDll.exe (Ver 1.1.1)

InjDll.exe 가 버전업 되었습니다. (2010.10.29)

추가/변경 사항

1. 64bit 지원

InjDll64.exe 를 이용하여 64bit 프로세스에 64bit DLL 파일을 인젝션 시킬 수 있습니다.

* 64bit 프로세스에 DLL Injection 을 하기 위해서는 Injector(InjDll64.exe) & DLL 파일이 모두 64bit(PE32+) 이어야 합니다.

2. <dll path> 의 "상대 경로" 지원

아래와 같이 Dll 파일 위치를 상대 경로로 입력할 수 있습니다.

InjDll32.exe notepad.exe -i dummy32.dll
InjDll32.exe calc.exe -i ..\hook.dll
...

주의사항

1) 원격 스레드를 실행시켜 LoadLibrary() 를 호출하는 방식이므로 대상 프로세스에 kernel32.dll 이 로딩되어 있지 않다면 Injection/Ejection 작업은 실패합니다.

2) 접근 권한이 제한된 (보호받는) 프로세스나 Anti-Injection 기법이 적용된 프로세스 들에게도 역시 Injection/Ejection 작업은 실패합니다.

3) 원칙적으로 Injection 을 N 번 시켰을 때 Ejection 도 같은 횟수로 호출해 줘야 해당 DLL 이 제대로 unloading 됩니다.

Bugs

사용하시다가 버그가 발견된다면 댓글로 알려주시면 감사하겠습니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

DLL Injection in Windows 7 (3)

reversecore — Tue, 23 Feb 2010 01:36:56 +0900

Windows 7 (& Vista) 에 맞는 InjectDll.exe 를 개발하고 소스 코드를 살펴보겠습니다.

이전 포스트에서 이어지는 내용입니다.

☞ DLL Injection in Windows 7 (1)

☞ DLL Injection in Windows 7 (2)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition SP1 으로 개발 되었으며, Windows 7 (32bit) & XP SP3 (32bit) 환경에서 테스트 되었습니다.

지난 내용 정리

시작하기 전에 먼저 지난 시간에 소개해 드린 내용을 짧게 정리해 보겠습니다.

Windows 7 (or Vista) 에서는 Session 관리 정책이 변경됨에 따라서 kernel32!CreateRemoteThread() API 내부 구현이 변경되었습니다.

☞ 참고 : Session in Windows 7

그 결과 CreateRemoteThread() 를 사용한 DLL Injection 기술이 Windows 7 (or Vista) 의 서비스 프로세스(Session 0) 에게는 정상적으로 동작하지 않습니다.

Kernel32!CreateRemoteThread() 를 디버깅 한 결과 원인은 API 내부에서 리모트 스레드를 생성할 때 suspend 모드로 생성하는데, 만약 리모트 프로세스가 Session 0 라면 resume 시키지 않고 그냥 에러를 리턴하기 때문이었습니다.

* 참고!

리모트 스레드를 생성할 때 일단 suspend 모드로 생성시킨 후 resume 시키는 구현 방법은 예전 XP 때부터 사용되던 방식입니다.

Kernel32!CreateRemoteThread() API 내부에서 호출되는 ntdll!ZwCreateThreadEx() API 의 파라미터를 조작 하거나 에러 조건 분기를 강제로 변경하면 정상적으로 리모트 스레드가 생성되면서 DLL Injection 이 성공하는 것을 확인 하였습니다.

InjectDll.exe

Windows 7 에서는 kernel32!CreateRemoteThread() 를 호출하는 것보다는 ntdll!ZwCreateThreadEx() API 를 직접 호출하는 것이 더 좋은 방법임을 알게 되었습니다.

☞ 참고 : 비스타에서 CreateRemoteThread 를 이용하여 dll 인젝션하기

* 주의!

ntdll!ZwCreateThreadEx() API 는 Vista 이후부터 추가된 API 이므로 XP 이하에서는 계속 CreateRemoteThread() 를 사용해야 합니다.

새로 알게 된 지식을 바탕으로 InjectDll.exe 프로그램을 새롭게 만들었습니다.

InjectDll.cpp

새롭게 프로그래밍한 InjectDll() 함수를 살펴보겠습니다.

typedef DWORD (WINAPI *PFNTCREATETHREADEX)

(

PHANDLE ThreadHandle,

ACCESS_MASK DesiredAccess,

LPVOID ObjectAttributes,

HANDLE ProcessHandle,

LPTHREAD_START_ROUTINE lpStartAddress,

LPVOID lpParameter,

BOOL CreateSuspended,

DWORD dwStackSize,

DWORD dw1,

DWORD dw2,

LPVOID Unknown

);

BOOL IsVistaOrLater()

{

OSVERSIONINFO osvi;

ZeroMemory(&osvi, sizeof(OSVERSIONINFO));

osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

GetVersionEx(&osvi);

// 커널 버전이 6 이상인지 확인!

if( osvi.dwMajorVersion >= 6 )

return TRUE;

return FALSE;

}

BOOL MyCreateRemoteThread

(HANDLE hProcess, LPTHREAD_START_ROUTINE pThreadProc, LPVOID pRemoteBuf)

{

HANDLE hThread = NULL;

FARPROC pFunc = NULL;

// OS 가 Vista 이상인지 확인!

if( IsVistaOrLater() ) // Vista, 7, Server2008

{

pFunc = GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtCreateThreadEx");

if( pFunc == NULL )

{

printf("GetProcAddress(\"NtCreateThreadEx\") failed!!! [%d]\n",

GetLastError());

return FALSE;

}

// NtCreateThreadEx() 호출

((PFNTCREATETHREADEX)pFunc)(&hThread,

0x1FFFFF,

NULL,

hProcess,

pThreadProc,

pRemoteBuf,

FALSE,

NULL,

NULL);

if( hThread == NULL )

{

printf("NtCreateThreadEx() failed!!! [%d]\n", GetLastError());

return FALSE;

}

else // 2000, XP, Server2003

{

hThread = CreateRemoteThread(hProcess,

NULL,

pThreadProc,

pRemoteBuf,

NULL);

if( hThread == NULL )

{

printf("CreateRemoteThread() failed!!! [%d]\n", GetLastError());

return FALSE;

}

if( WAIT_FAILED == WaitForSingleObject(hThread, INFINITE) )

{

printf("WaitForSingleObject() failed!!! [%d]\n", GetLastError());

return FALSE;

}

return TRUE;

}

BOOL InjectDll(DWORD dwPID, char *szDllName)

{

HANDLE hProcess = NULL;

LPVOID pRemoteBuf = NULL;

FARPROC pThreadProc = NULL;

DWORD dwBufSize = strlen(szDllName)+1;

if ( !(hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) )

{

printf("OpenProcess(%d) failed!!! [%d]\n",

dwPID, GetLastError());

return FALSE;

}

pRemoteBuf = VirtualAllocEx(hProcess, NULL, dwBufSize,

MEM_COMMIT, PAGE_READWRITE);

WriteProcessMemory(hProcess, pRemoteBuf, (LPVOID)szDllName,

dwBufSize, NULL);

pThreadProc = GetProcAddress(GetModuleHandle(L"kernel32.dll"),

"LoadLibraryA");

if( !MyCreateRemoteThread(hProcess, (LPTHREAD_START_ROUTINE)pThreadProc, pRemoteBuf) )

{

printf("CreateRemoteThread() failed!!! [%d]\n", GetLastError());

return FALSE;

}

VirtualFreeEx(hProcess, pRemoteBuf, 0, MEM_RELEASE);

CloseHandle(hProcess);

return TRUE;

}

InjectDll() 함수의 변경된 사항은 바로 kernel32!CreateRemoteThread() 를 직접 호출하지 않고MyCreateRemoteThread() 사용자 함수를 호출 한다는 것입니다.

MyCreateRemoteThread() 함수 내부에서 OS 버전을 구해서 Vista 이상이라면 ntdll!NtCreateThreadEx() 를 호출하고, XP 이하라면 kernel32!CreateRemoteThread() 를 호출하도록 하였습니다.

간단한 코드이므로 쉽게 이해하실 수 있으실 겁니다.

* 참고!

유저 모드에서 ntdll.dll 라이브러리의 NtCreateThreadEx() 와 ZwCreateThreadEx() API 는 사실 같은 함수입니다. (두 함수의 시작 주소는 동일합니다.) 커널 모드(ntoskrnl.exe) 에서는 두 함수가 서로 틀려집니다. 향후 커널 모드 디버깅을 설명할 때 다시 설명 드리겠습니다. 일단 유저 모드에서는 NtXXX() 와 ZwXXX() 는 같다는 것만 기억해 주시기 바랍니다.

테스트

dummy.dll

InjectDll.exe

dummy.dll 파일은 지난 시간에 사용된 것과 동일한 파일로써 인젝션이 성공하면 디버그 로그를 출력하는 기능을 가지고 있습니다.

테스트를 위해서 적당한 서비스 프로세스를 골라 봅니다.

<Fig. 1>

그리고 아래와 같이 InjectDll.exe 를 실행시켜 주세요.

<Fig. 2>

Process Explorer 로 svchost.exe (PID:612) 를 확인해 보시면 dummy.dll 이 인젝션 되어 있는 걸 확인 하실 수 있습니다.

<Fig. 3>

이제 서비스 프로세스(Session 0) 에도 무리 없이 DLL Injection 을 할 수 있게 되었습니다.

* 참고!

ntdll!NtCreateThreadEx() API 는 undocument API 입니다. 따라서 MicroSoft 에서 사용을 권장하지 않을뿐더러 시스템의 안정성을 보장할 수 없습니다. 제가 테스트 해본 바로는 잘 동작하였지만 언제든지 MS 에서 패치를 시킬 가능성도 있습니다. 따라서 업무용으로 이 방법을 따라 하시는 분들께서는 꼭 이러한 사항을 염두에 두시기 바랍니다.

이상으로 Windows 7 에서 DLL Injection 하는 방법에 대한 설명을 마치도록 하겠습니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

DLL Injection in Windows 7 (2)

reversecore — Sun, 21 Feb 2010 23:02:14 +0900

이전 포스트에서 이어지는 내용입니다.

☞ DLL Injection in Windows 7 (1)

디버깅 2

OllyDbg 를 재실행시켜 InjectDll.exe 의 CreateRemoteThread() 호출 코드까지 옵니다. (아래 그림 참조)

<Fig. 1>

스택에 저장된 CreateRemoteThread() API 의 파라미터를 보겠습니다.

<Fig. 2>

위 그림의 중요 파라미터들에 대한 설명은 다음과 같습니다.

(1) svchost.exe (PID : 3148) 의 프로세스 핸들

(2) kernel32!LoadLibraryA() API 주소

(3) svchost.exe 의 프로세스 메모리에 할당한 버퍼 주소 ("c:\work\dummy.dll")

이제 <Fig. 1> 에서 StepIn (F7) 명령으로 kernel32!CreateRemoteThread() API 내부로 들어가 보겠습니다.

<Fig. 3>

Kernel32!CreateRemoteThread() 는 내부적으로 kernelbase!CreateRemoteThreadEx() 를 호출합니다.

* kernelbase.dll 은 Vista 부터 추가된 DLL 파일로써 kernel32.dll 의 wrapper 역할을 담당합니다.

이때의 스택에 저장된 파라미터를 살펴보겠습니다.

<Fig. 4>

kernelbase!CreateRemoteThreadEx() 의 파라미터들은 kernel32!CreateRemoteThread() 와 거의 동일하고 lpAttributeList 파라미터가 추가되었습니다.

다시 kernelbase!CreateRemoteThreadEx() 코드 내부로 들어갑니다. 스크롤을 조금 내려보면 아래와 같이 ntdll!ZwCreateThreadEx() 호출 코드가 나타납니다.

<Fig. 5>

스택에 저장된 파라미터를 살펴보겠습니다.

<Fig. 6>

파라미터 개수가 더 많아졌습니다. <Fig. 2> 와 <Fig. 6> 을 비교해보면 중요 파라미터 (1) ~ (3) 이 그대로 전달된 것을 확인할 수 있습니다.

ntdll!ZwCreateThreadEx() API 의 내부를 더 파고 들어가면 결국 "SYSENTER" 명령어를 만나서 커널 모드로 진입하게 됩니다. 유저 모드 디버깅으로는 더 이상 진행할 수 없습니다. (커널 모드 디버깅에 대해서는 향후 자세히 설명하도록 하겠습니다.)

사실 kernelbase!CreateRemoteThreadEx() 와 ntdll!ZwCreateThreadEx() 는 모두 Vista 이후에 추가된 API 입니다. (XP 이하에서는 존재하지 않는 API 입니다.)

참고로 XP 에서는 kernel32!CreateRemoteThread() 내부에서 바로 ntdll!ZwCreateThread() 를 호출합니다. XP 와 7 에서 kernel32!CreateRemoteThread() API 의 호출 흐름을 아래 그림에 나타내었습니다.

<Fig. 7>

따라서 새로 추가된 이 API 때문에 Session 0 에서 실행되는 서비스 프로세스들에게 DLL Injection 이 실패한다고 볼 수 있겠습니다.

kernelbase!CreateRemoteThreadEx() 는 kernel32!CreateRemoteThread() 의 wrapper 라고 한다면 문제의 원인은 ntdll!ZwCreateThreadEx() 에 있을 것 같습니다. ntdll!ZwCreateThreadEx() 는 undocumented API 이므로 MSDN 에서는 함수 정의를 찾을 수 없고, Google 검색으로 찾아야 합니다.

typedef struct

{

ULONG Length;

ULONG Unknown1;

ULONG Unknown2;

PULONG Unknown3;

ULONG Unknown4;

ULONG Unknown5;

ULONG Unknown6;

PULONG Unknown7;

ULONG Unknown8;

}UNKNOWN, *PUNKNOWN;

DWORD ZwCreateThreadEx

(

PHANDLE ThreadHandle,

ACCESS_MASK DesiredAccess,

POBJECT_ATTRIBUTES ObjectAttributes,

HANDLE ProcessHandle,

LPTHREAD_START_ROUTINE lpStartAddress,

LPVOID lpParameter,

BOOL CreateSuspended,

DWORD dwStackSize,

DWORD dw1,

DWORD dw2,

PUNKNOWN pUnknown

);

* XP 이하에서는 지원되지 않음

Google 검색을 하던 중에 아래와 같은 글을 발견하였습니다.

☞ 비스타에서 CreateRemoteThread 를 이용하여 dll 인젝션하기

글 내용을 요약하면 Vista 이후의 OS 에서 DLL Injection 을 할 때는 CreateRemoteThread() 대신에 ZwCreateThreadEx() 를 직접 호출하면 잘 된다는 것입니다. 제가 테스트 해보니 Session 에 상관없이 성공하였습니다. (관련 소스는 다음편에서 설명합니다.)

이 방법에서 사용된 파라미터와 <Fig. 6> 의 파라미터를 비교하니 바로 7 번째 파라미터인 CreateSuspended 항목에서 차이를 보였습니다. 즉, ZwCreateThreadEx() 를 직접 호출하여 성공한 경우에는 CreateSuspended 파라미터가 FALSE (0) 인데 반해, CreateRemoteThread() API 내부 에서 호출되는 ZwCreateThreadEx() 호출에서는 CreateSuspended 파라미터가 TRUE (1) 입니다.

* XP 이전부터 CreateRemoteThread() API 의 내부 구현 알고리즘은 일단 suspend 모드로 thread 를 생성한 후 resume 시키는 방법을 사용해 왔습니다. (CreateSuspended = 1)

CreateRemoteThread() 성공 시키는 방법 #1

위와 같이 ZwCrateThreadEx() API 의 CreateSuspended 파라미터의 차이점을 이용한다면 Windows 7 의 서비스 프로세스에 CreateRemoteThread() API 호출도 성공 시킬 수 있을 것 같습니다.

다시 디버깅을 새로 시작하여 위의 <Fig. 5> 까지 진행한 후 스택에 저장된 CreateSuspended 파라미터 값을 1 에서 0 으로 변경합니다.

<Fig. 8>

이 상태로 ZwCreateThreadEx() 호출을 StepOver(F8) 로 넘어가면 아래 그림과 같이 dummy.dll 이 인젝션 됩니다.

<Fig. 9>

DbgView 로 보면 아래 그림과 같이 dummy.dll 의 DllMain() 함수에서 찍은 디버깅 로그가 나타납니다.

<Fig. 10>

CreateRemoteThread() 성공 시키는 방법 #2

kernelbase!CreateRemoteThreadEx() 를 좀 더 디버깅 해보면 몇 가지 사실을 더 알 수 있습니다.

<Fig. 5> 에서 ZwCreateThreadEx() 를 그대로(CreateSuspended 수정 안함 = TRUE) StepOver(F8) 하면 아래 그림과 같이 첫 번째 파라미터 pThreadHandle 에 값이 세팅됩니다.

<Fig. 11>

스레드 핸들이 생성되었다는 말은 스레드가 정상적으로 생성되었다는 얘기입니다. 즉, CreateRemoteThread() 호출에서도 리모트 스레드 "생성"만큼은 성공했다고 볼 수 있습니다.

하지만 이 리모트 스레드가 정상 동작하지 않았던 이유는 이후에 호출될 ntdll!ZwResumeThread() API 가 실패했거나, 아니면 아예 호출되지 못했거나 둘 중의 하나가 될 것입니다. (suspend 모드로 생성하였으니 resume 해줘야 스레드가 정상적으로 실행됩니다.)

디버깅을 더 진행해서 ZwResumeThread() API 호출 부분까지 따라가 보겠습니다. 아래 그림은 kernelbase!CreateRemoteThreadEx() API 코드의 끝 부분입니다.

<Fig. 12>

위 그림을 보시면 758EBD33 주소의 ntdll!CsrClientCallServer() API 가 호출된 이후에 그 아래쪽의 조건 분기 명령어(CMP/JL)에 의해 ZwResumeThread() API 가 호출되지 않고 점프하는 것을 확인할 수 있습니다.

디버거에서 ntdll!CsrClientCallServer() API 호출 후에 저 조건 분기를 조작해서 ZwResumeThread() 를 호출하도록 해주면 DLL Injection 이 성공합니다.

Intel IA-32 Reference 에 의하면 JL 명령어는 SF != OF 인 경우 점프하도록 되어 있으므로 아래 그림과 같이 S Flag 를 마우스 더블 클릭하여 변경합니다.

<Fig. 13>

DLL 인젝션이 정상적으로 되었는지 직접 확인해 보시기 바랍니다.

+---+

지금까지 Windows 7 에서 서비스 프로세스에 DLL Injecion 할 때 kernel32!CreateRemoteThread() API 호출이 왜 실패하는지 알아보았습니다. 또한 kernel32!CreateRemoteThread() API 를 디버깅해서 결국 DLL Injection 이 성공하도록 실습해봤습니다. (디버깅을 이용하는 방법이라서 범용적으로 사용하기에는 불편합니다.)

다음 시간에는 Windows 7 (or Vista) 뿐만 아니라 XP 에서도 범용적으로 사용할 수 있는 InjectDll.exe 를 만들어 보도록 하겠습니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

DLL Injection in Windows 7 (1)

reversecore — Sat, 20 Feb 2010 00:06:27 +0900

Windows 7 (& Vista) 에서 DLL Injection 하는 방법에 대한 설명입니다.

새로 변경된 Session 정책에 의하여 기존 CreateRemoteThread() API 를 이용한 DLL Injection 방법이 일부 프로세스들에게 제대로 동작하지 않습니다. 정확한 증상을 알아보고 문제 발생 원인과 해결 방법에 대하여 알아보도록 하겠습니다.

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition SP1 으로 개발 되었으며, Windows 7 (32bit) & XP SP3 (32bit) 환경에서 테스트 되었습니다.

DLL Injection

예전에 DLL Injection 에 대해서 연재를 한 적이 있습니다.

☞ DLL Injection - 다른 프로세스에 침투하기 (1)

☞ DLL Injection - 다른 프로세스에 침투하기 (2)

☞ DLL Injection - 다른 프로세스에 침투하기 (3)

☞ DLL Injection - 다른 프로세스에 침투하기 (4)

☞ DLL Ejection – 침투시킨 DLL 빼내기

또한 API Hooking 연재를 하면서 DLL Injection 기법을 사용하였습니다.

☞ API Hooking – ‘스텔스’ 프로세스 (1)

☞ API Hooking – ‘스텔스’ 프로세스 (2)

☞ API Hooking – ‘스텔스’ 프로세스 (4)

위에서 소개한 DLL Injection 기법은 CreateRemoteThread() API 를 사용하는 방법으로써 Windows XP, 2000 에서는 아주 정확하게 잘 동작합니다.

하지만 Windows 7 (& Vista) 에서 약간 다르게 동작합니다. 정확하게 말하면 기존 CreateRemoteThread() API 를 이용한 방법으로는 7 (& Vista) 의 서비스(Service) 프로세스에 DLL Injection 이 되지 않습니다.

그 이유는 7 (& Vista) 에서 적용된 Session 관리 정책의 변경 때문입니다. (아래 링크 참고!)

☞ Session in Windows 7

간단한 프로그램을 사용하여 DLL Injection 실패 상황을 재현해 보도록 하겠습니다.

InjectDll.exe & dummy.dll

실습용 파일과 소스 코드입니다.

InjectDll.cpp 소스 코드에서 핵심 함수인 InjectDll() 를 아래에 표시하였습니다.

BOOL InjectDll(DWORD dwPID, char *szDllName)

{

HANDLE hProcess = NULL;

HANDLE hThread = NULL;

LPVOID pRemoteBuf = NULL;

FARPROC pThreadProc = NULL;

DWORD dwBufSize = strlen(szDllName)+1;

if ( !(hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwPID)) )

{

printf("[ERROR] OpenProcess(%d) failed!!! [%d]\n",

dwPID, GetLastError());

return FALSE;

}

pRemoteBuf = VirtualAllocEx(hProcess, NULL, dwBufSize,

MEM_COMMIT, PAGE_READWRITE);

WriteProcessMemory(hProcess, pRemoteBuf, (LPVOID)szDllName,

dwBufSize, NULL);

pThreadProc = GetProcAddress(GetModuleHandle(L"kernel32.dll"),

"LoadLibraryA");

hThread = CreateRemoteThread(hProcess, NULL, 0,

(LPTHREAD_START_ROUTINE)pThreadProc,

pRemoteBuf, 0, NULL);

if( hThread == NULL )

{

printf("[ERROR] CreateRemoteThread() failed!!! [%d]\n", GetLastError());

return FALSE;

}

WaitForSingleObject(hThread, INFINITE);

VirtualFreeEx(hProcess, pRemoteBuf, 0, MEM_RELEASE);

CloseHandle(hThread);

CloseHandle(hProcess);

return TRUE;

}

지금까지 익히 보아오던 DLL Injection 의 전형적인 소스 코드에다가 리턴값 체크를 추가하였습니다.

☞ 참고 : DLL Injection - 다른 프로세스에 침투하기 (2)

그리고 아래는 dummy.dll 파일의 소스 코드(dummy.cpp)입니다.

#include "windows.h"

#include "tchar.h"

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)

{

TCHAR szPath[MAX_PATH] = {0,};

TCHAR szMsg[1024] = {0,};

TCHAR *p = NULL;

switch( fdwReason )

{

case DLL_PROCESS_ATTACH :

GetModuleFileName(NULL, szPath, MAX_PATH);

p = _tcsrchr(szPath, L'\\');

if( p != NULL )

{

_stprintf_s(szMsg, 1024 - sizeof(TCHAR),

L"Injected in %s(%d)",

p + 1, // Process Name

GetCurrentProcessId()); // PID

OutputDebugString(szMsg);

}

break;

}

return TRUE;

}

DllMain() 함수는 아주 간단합니다. dummy.dll 파일이 프로세스에 정상적으로 인젝션 되었다면 디버그 메시지(프로세스 이름, 프로세스 ID)를 출력하는 것입니다.

테스트

Process Explorer 를 실행시킨 후 Session 0 의 svchost.exe (PID : 3148) 프로세스와 Session 1 의notepad.exe(PID : 2172) 프로세스에 각각 dummy.dll 파일을 인젝션 시켜보도록 하겠습니다.

<Fig. 1>

위에서 첨부한 InjectDll.exe 와 dummy.dll 파일을 적당한 폴더에 다운받은 후 아래 그림과 같이 실행합니다.

<Fig. 2>

Session 1 의 notepad.exe (2172) 프로세스에는 정상적으로 인젝션 되었지만, Session 0 의 svchost.exe (3148) 프로세스에는 인젝션이 실패(error code = 8)하였습니다.

Process Explorer 에서 dummy.dll 모듈을 검사해봅니다.

<Fig. 3>

위 그림에서 보시는 것처럼 Session 1 의 notepad.exe (2172) 프로세스에게만 정상적으로 dummy.dll 파일이 인젝션 되었습니다.

디버깅

<Fig. 2> 에서 Session 0 의 svchost.exe (3148) 프로세스에 인젝션 할 때 CreateRemoteThread() API 함수 호출에서 실패하였고, 그 때의 에러 코드는 8 입니다.

OllyDbg 를 이용해서 InjectDll.exe 파일을 디버깅 해보겠습니다.

InjectDll.exe 파일을 파라미터("3148 c:\work\dummy.dll")를 입력해서 Open 합니다.

<Fig. 4>

CreateRemoteThread() API 호출 시에 에러가 발생하는 것을 알았으니, Search for \ All intermodular calls 메뉴를 이용해서 해당 API 호출 코드에 바로 BP 를 설치합니다.

<Fig. 5>

* 참고!

Windows 7 에서 InjectDll.exe 프로세스의 Base Address 는 랜덤하게 변경됩니다.

☞ ASLR(Address Space Layout Randomization)

디버거를 Run 시키면 <Fig. 5> 의 BP 에 멈추게 됩니다.

<Fig. 6>

여기서 그대로 F8 (StepOver) 로 진행하면 아래 그림과 같이 LastErr = ERROR_NOT_ENOUGH_MEMORY (8) 가 찍힙니다.

<Fig. 7>

에러 메시지도 낯설고 아직은 뭐가 문제인지 잘 모르겠군요.

다음에 이어지는 글에서 InjectDll.exe 의 CreateRemoteThread() 를 좀 더 디버깅 해보겠습니다.

☞ DLL Injection in Windows 7 (2)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Session in Windows 7

reversecore — Sun, 14 Feb 2010 14:36:52 +0900

Windows Vista & 7 에서 변경된 Session 관리 정책에 대해서 알아보겠습니다.

Windows 응용 프로그램 개발자라면 (XP 에서 잘 실행되는) 서비스 프로그램이 Vista 혹은 7 에서 정상적으로 동작하지 않는 경험을 해보셨을 것입니다. 이는 주로 사용자와 interactive 하게 동작하는 서비스 프로그램에 해당됩니다. 즉, 사용자 다이알로그를 출력하거나, 사용자 프로그램과 서비스 프로그램간의 메시지 통신 등을 시도할 때 예전(XP) 처럼 잘 되지 않는 것입니다.

그 이유는 7 (혹은 Vista) 에서 적용된 Session 관리 정책이 변경되었기 때문입니다.

Windows 7 에서의 Session 관리 정책 변경은 개발 관점에서도 중요한 일이지만, 리버싱 관점에서도 매우 중요한 사건입니다. 왜냐하면 기존부터 널리 사용되던 CreateRemoteThread() API 를 이용한 DLL Injection 방법이 Windows 7 의 서비스 프로세스들에게는 더 이상 먹히지 않기 때문입니다. (일반 프로세스에게는 아직도 잘 됩니다.)

Session

Session 이란 간단히 말해서 로그온 사용자 환경을 의미합니다.

대부분의 OS 는 동시에 여러 사용자의 로그온을 허가하고 각 로그온에 대해서 독립된 사용자 환경을 제공합니다. Windows 운영체제를 예로 들면 "사용자 전환" 기능으로 로컬 사용자 Session을 생성할 수 있으며, "원격 데스크톱 연결" 기능으로 리모트 사용자 Session을 생성할 수 있습니다.

Process Explorer 의 View 메뉴에서 Session 항목을 선택하면 현재 실행되고 있는 프로세스들이 각각 어떤 Session에 속해있는지 표시해 줍니다.

<Fig. 1>

현재 Session을 확인하기 위해서 “사용자 전환” 기능을 이용하여 2 명의 사용자를 로그온 시켰습니다. 로그온 순서대로 Session ID(0, 1, 2, …)가 부여됩니다.

아래 그림은 Windows 7 에서 실행중인 프로세스와 Session을 나타냅니다.

<Fig. 2>

이번에는 Windows XP 에서 실행중인 프로세스와 Session을 살펴보겠습니다.

<Fig. 3>

* 참고

사용자 로그온을 하면 기본적으로 해당 섹션을 위한 csrss.exe, winlogon.exe, explorer.exe 프로세스가 생성됩니다.

Windows 7 (<Fig. 2>) 과 Windows XP (<Fig. 3>) 사이에는 하나의 큰 차이점이 있습니다. 둘 다 똑같이 두 명의 사용자가 로그인 하였으나 7 에서는 Session이 총 3 개(0, 1, 2) 인 반면에, XP 에서는 Session이 2 개(0, 1) 입니다.

XP 와 7 에서 시스템 프로세스들과 서비스 프로세스들은 Session ID 0 (시스템 Session) 에서 실행됩니다. 둘 간의 차이점은 바로 첫 번째 로그온 사용자의 Session ID 입니다. XP 는 첫 번째 로그온 사용자의 Session ID 가 0 으로 시스템 Session과 같고, 7 은 첫 번째 로그온 사용자의 Session ID 가 1 로 할당 되어 시스템 Session과 다릅니다.

이 작은 차이로 인해 XP 에서 잘 동작하던 기술들이 7 (Vista 포함) 에서는 비정상적으로 실행되게 됩니다.

Session 0 Isolation

Windows 커널 버전 6 이후 부터는 보안 강화를 위하여 첫 번째 로그온 사용자 세션을 1 로 주어서 시스템 세션 0 과 구별되도록 하였습니다.

* Windows 커널 버전에 대한 설명은 아래 링크를 참고하세요.

☞ ASLR(Address Space Layout Randomization)

이렇게 시스템 세션과 사용자 세션을 분리시켜 서로에 대한 상호작용을 없애는 정책으로 인해서 비록 부분적으로 하위 호환 문제가 발생하였지만, 그 대신 시스템 보안이 강화되었습니다.

이러한 정책을 MS 에서는 "Session 0 Isolation" 이라고 부르며, 제가 따로 설명할 필요 없이 아래 Windows Team Blog 링크에 이와 관련된 설명이 아주 자세히 나와 있습니다.

☞ http://windowsteamblog.com/blogs/developers/archive/2009/10/01/session-0-isolation.aspx

개발/리버싱 관점에서 보면 Windows 7 은 여러모로 향상된 기능이 많습니다.

보안 강화

위와 같은 "Session 0 Isolation" 과 지난번에 소개해 드린 "ASLR" 기술 등은 모두 보안 강화를 위해 추가된 기능들인데요, 의도는 좋았지만 실제적인 보안 강화 측면에는 의문이 남습니다.

Session 0 프로세스들이 완전히 분리된 것은 아니기 때문에 Session 1 의 프로세스(예:Process Explorer)에서 Session 0 의 프로세스들을 종료시킬 수 있으며, ReadProcessMemory(), WriteProcessMemory(), VirtualAllocEx() 등의 디버깅 API 들도 정상적으로 동작합니다. (ASLR 기술의 회피 방법도 쉽지요.)

MS 에서 새로운 기술이 추가되고는 있지만 어디까지나 임시 방편에 지나지 않는다고 생각합니다. 당장은 예전에 사용되던 기초적인 해킹 공격들은 막을 수 있겠지만 곧 그에 대응하는 리버싱 기술도 같이 발전하고 있기 때문에 더 새로운 고차원적인 공격 기법들이 나타날 것입니다. 그야말로 창과 방패의 끝없는 싸움이지요.

이런 경우에 방패(MS)쪽이 절대적으로 불리합니다. 왜냐하면 고려해야 할 사항이 너무 많기 때문입니다. 각종 다양한 종류의 응용 프로그램들이 잘 실행되도록 지원해줘야 하구요, 고객의 편의를 위해서 하위 호환을 신경써야 합니다. 또한 수많은 하드웨어들에 대한 지원은 또 어떻구요.

결정적으로 너무나 많은 PC 에서 사용된다는 것이 문제입니다. 사용자가 너무 많기 때문에 공격하는 창(해커)쪽에서는 MS Windows 의 특수 환경(예:MS XP SP3 IE8 사용자) 하나만 노려도 됩니다. 전쟁에 비유를 하자면 전선이 너무 길다고 할까요. 공격자 입장에서는 공격할 곳이 너무 많아서 유리한 반면에 수비자 입장에서는 막을 곳이 너무나 많아지는 것이지요.

Linux, Mac 등에 악성코드가 없는 이유는 사용자가 상대적으로 적기 때문이지 결코 그 운영체제들의 보안성이 월등해서가 아니랍니다.

다음 시간에는 Session 0 Isolation 기술이 적용된 Windows 7 의 서비스 프로세스(Session 0)에게 DLL Injection 을 시키는 방법에 대해서 자세히 알아보겠습니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

질문/답변 코너입니다. (2)

reversecore — Thu, 28 Jan 2010 12:09:57 +0900

질문/답변 코너를 만든 이후로 많은 분들께서 질문을 해주시고, 답변도 도와 주셨습니다.

모든 분들께 정말로 감사를 드립니다.

댓글로 질문/답변을 진행하고 있는데요, 너무 댓글이 길어져서 사용하기 불편해졌습니다.

그래서 새로 추가하였습니다.

이후부터는 이쪽에 질문/답변을 올려주세요~

감사합니다.

* 예전 질문/답변 코너 링크입니다. (원하시는 내용이 있는지 검색해 보세요~)

☞ 질문/답변 코너입니다.

=======================================================

리버스 엔지니어링 분야에 대해 질문이 있으시면 아래의 댓글로 올려주세요. 역시 댓글로 답변을 올려드리겠습니다. 공개하기 어려운 내용은 '비밀글' 에 체크해주세요.

"비도덕적, 불법적" 인 내용은 답변 드릴 수 없음을 이해해 주시기 바랍니다.

댓글, 방명록, 이메일 등으로 많은 분들께서 여러 가지 질문들을 해주십니다.
그중에 정말 좋은 질문들이 많아서 여러분들과 공유하면 좋겠다고 생각하였습니다.

이제부터 저에게 들어오는 모든 질문과 답변들을 이곳으로 모을 것입니다.
앞으로 질문과 답변은 이곳에서 해주세요~

질문에 대한 답변은 저 뿐만 아니라 제 블로그에 오시는 모든 분들께서 하실 수 있습니다.
문제 해결을 위한 방법은 다양합니다. 저 말고도 다른 분들의 답변은 언제나 환영입니다.

"질문은 좋은 것 입니다. 많이 해주세요. ^^ "

* 댓글로 질문하기 어려운 내용들(긴내용, 첨부파일 등)은 제 이메일(reversecore@gmail.com)로 문의해 주세요.

* 제가 사용하는 GMail 은 PE 파일을 첨부하면 전송 거부를 합니다. (압축을 시켜도 그걸 열어서 확인하지요.)
=> 실행 파일을 첨부해서 보내실때는 확장자를 exex, dllx, zipx 등으로 변경해서 보내주세요.

* 댓글이 너무 많이 달리면 제가 질문/답변 빈 포스트를 또 올릴 겁니다. 그쪽으로 계속 질문 댓글 달아주시면 됩니다.

감사합니다.

ReverseCore

실행 파일에서 ".reloc" 섹션 제거하기

reversecore — Wed, 27 Jan 2010 20:43:49 +0900

유틸리티를 이용하여 PE 파일에서 ".reloc" 섹션을 수동으로 제거하는 실습을 합니다.

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition SP1 으로 개발 되었으며, Windows 7 & XP SP3 환경에서 테스트 되었습니다.

여기서 소개되는 실습용 실행 파일은 아래 포스트를 참고하시기 바랍니다.

☞ ASLR(Address Space Layout Randomization)

앞으로 사용될 유틸리티 입니다. (제 블로그에서 몇 번 소개해 드린 적이 있습니다.)

모두 Freeware 이며, 사용하기 편리하며, 매우 안정적입니다.

- PE Viewer

PEView.exe by Wayne J. Radurn

- Hex Editor

HxD by Maël Hörz

".reloc" 섹션

PE Flie 에서 Base Relocation Table 항목은 EXE 파일의 경우 실행에 큰 영향을 끼치지 않습니다. 실제로 제거 후 실행 테스트 해보면 실행이 잘 되거든요. PE Loader 가 로딩 시에 참고는 하되, 없으면 자체적으로 알아서 로딩 시켜주기 때문이지요. 하지만 DLL 파일의 경우 기본적으로 Relocation 을 염두에 둬야 하기 때문에 ".reloc" 섹션을 강제로 제거할 경우 실행이 안 될 수 있습니다.

VC++ 2008 에서 Relocation 섹션의 이름은 일반적으로 ".reloc" 입니다.

".reloc" 섹션이 제거되면 PE 파일 크기가 약간 줄어드는 효과를 볼 수 있습니다. (실제로 이러한 유틸리티도 있습니다.)

".reloc" 섹션은 보통 마지막에 생성되는데 이렇게 마지막에 위치한 (사용되지 않는) 섹션을 제거하는 건 생각보다 어렵지 않습니다. PEView 와 Hex editor 만 가지고도 (수동으로) 충분히 할 수 있습니다.

먼저 PE File Format 에 대한 기억을 끄집어 내보겠습니다.

기억이 가물가물 하시다면 아래 포스트를 참고하세요.

☞ PE(Portable Executable) File Format (1) - PE Header

ASLR.exe

우리가 실습할 파일입니다.

ASLR.exe

실습 파일의 끝에 존재하는 ".reloc" 섹션을 정확히 제거하려면 아래와 같은 4 가지 작업을 해야 합니다.

- ".reloc" 섹션 헤더 정리

- ".reloc" 섹션 제거

- IMAGE_FILE_HEADER 수정

- IMAGE_OPTIONAL_HEADER 수정

하나씩 차례대로 해보겠습니다.

# ".reloc" 섹션 헤더 정리

<Fig. 1>

위 그림을 보시면 ".reloc" 섹션 헤더는 파일의 270 옵셋에서 시작됩니다. (섹션 헤더 크기는 28h)

이 부분을 hex editor 를 이용해서 0 으로 밀어버립니다.

(HxD 의 "Fill selection…" 기능을 이용하시면 편합니다.)

<Fig. 2>

# ".reloc" 섹션 제거

<Fig. 1> 을 보시면 파일에서 ".reloc" 섹션의 시작 옵셋은 C000 입니다. (이곳부터 파일 끝까지 ".reloc" 섹션 영역입니다.)

Hex editor 로 C000 옵셋부터 파일 끝까지 삭제시켜 버립니다.

(HxD 의 "Delete" 기능을 이용하시면 편합니다.)

<Fig. 3>

이로써 ".reloc" 섹션은 물리적으로 제거 되었습니다.

하지만 다른 PE Header 정보들이 아직 수정되지 않아서 정상적으로 실행되지는 않습니다.

이제부터 관련 PE Header 정보를 수정하여 정상 실행되도록 만들어 보겠습니다.

# IMAGE_FILE_HEADER 수정

섹션을 하나 제거했으니 IMAGE_FILE_HEADER \ Number of Sections 항목을 수정해줘야 합니다.

<Fig. 4>

Number of Sections 항목은 파일 옵셋 DE 의 WORD 값입니다. 현재 5 로 되어 있는데요, 섹션이 하나 줄었으므로 이 값을 4 로 바꿔 줍니다.

<Fig. 5>

# IMAGE_OPTIONAL_HEADER 수정

마지막 단계입니다.

".reloc" 섹션이 제거되면서 (프로세스 가상 메모리에서) 섹션 크기 만큼 전체 이미지 크기가 줄어들었습니다. 이미지 크기는 IMAGE_OPTIONAL_HEADER \ Size of Image 값에 명시 되어 있으므로 이를 수정해줘야 합니다.

<Fig. 6>

위 그림을 보시면 현재 Size of Image 값은 11000 입니다. 문제는 얼마 만큼을 빼줘야 정상적으로 실행될지 계산해야 합니다.

<Fig. 1> 에 따르면 ".reloc" 섹션의 VirtualSize 값은 E40 이고, 이를 Section Alignment 에 맞게 확장하면 1000 이 됩니다. (참고로 실습 파일의 Section Alignment 값은 1000 입니다.)

따라서 Size of Image 값을 1000 만큼 빼줘야 하지요.

<Fig. 7>

이제 수정된 ASLR.exe 파일은 정상적으로 실행 될 것입니다.

이와 같이 PEView 와 HxD 만으로 PE 파일을 마음대로 주무를 수 있습니다.

+---+

위 내용과 관련하여 좀 더 실습을 해보고 싶으신 분은 ASLR.exe 파일에 섹션을 하나 더 추가시켜 보시기 바랍니다. 총 6 개의 섹션이 되는 것이지요. 위 내용을 참고하시면 무난히 해내실 수 있습니다.

궁금한 점 있으시면 질문 올려주세요~

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

ASLR(Address Space Layout Randomization)

reversecore — Wed, 27 Jan 2010 15:31:53 +0900

Windows Vista 부터 적용된 ASLR 기술에 대해서 알아보도록 하겠습니다.

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition SP1 으로 개발 되었으며, Windows 7 환경에서 테스트 되었습니다.

Windows Kernel Version

아래 보이는 그림은 Windows OS 별로 각 Kernel Version 을 보여주고 있습니다.

<Fig. 1>

Windows Vista 이후부터 Kernel Version 이 '6' 으로 올라갔습니다. (약 7 년 만에 Major 버전이 올라간 셈이죠.)

여기서 설명 드리는 ASLR 기능은 Windows Vista(Kernel Version 6) 이후부터 지원되는 기능입니다.

ASLR(Address Space Layout Randomization)

ASLR 기술은 PE 파일이 메모리에 로딩될 때 ImageBase 값을 (동적으로 계산하여) 랜덤하게 바꾸는 것입니다. 또한 해당 프로세스의 Stack, Heap 의 시작 주소도 실행될 때마다 랜덤하게 바뀝니다.

즉, EXE 파일이 실행될 때 프로세스 메모리 상의 실제 ImageBase 는 매번 틀려지게 되며, DLL 파일이 최초로 로딩 될 때도 역시 메모리 상의 실제 ImageBase 가 달라집니다.

* DLL 파일은 메모리에 최초로 loading 되면 그 후부터는 다른 프로세스에 매핑(mapping)되는 개념이기 때문에 같은 DLL 파일에 대해서 프로세스 별로 매핑 주소는 동일합니다. (DLL 이 unloading 되면 메모리에서 사라진 것이기 때문에 다음 번 loading 시에는 다른 주소에 올라갈 것입니다.)

* 위와 같은 특성을 생각했을 때 시스템 DLL(ntdll.dll, kernel32.dll, etc) 들은 부팅 시마다 매핑 주소는 틀려지겠지만 일단 부팅되면 모든 프로세스에서 같은 주소에 매핑이 됩니다.

MS 에서 PE 파일의 로딩 방식을 이런 식으로 바꾼 이유가 뭘까요?

바로 "보안을 강화" 하기 위해서 입니다.

Windows OS 보안 취약점(보통 버퍼 오버플로우)들은 보통 특정 OS, 특정 모듈, 특정 버전에서만 동작합니다. 그러한 취약점을 노리는 exploit code 에는 특정 메모리 주소(버퍼 오버플로우)가 하드 코딩 되어있습니다. (기존 OS 에서는 버전에 따라 특정 DLL 이 언제나 정해진 주소에 로딩되기 때문이죠.)

따라서 MS 에서는 OS 보안 취약점을 노리는 exploit code 작성을 어렵게 하기 위해서 이와 같이 ASLR 기술을 만들게 된 것입니다.

Visual C++ 2008 (Express Edition)

모든 실행 파일에 대해서 자동으로 ASLR 기술이 적용되는 것은 아닙니다. 위에서 설명 드린 대로 OS 의 Kernel Version 이 6 이상이어야 하고, 개발도구(예: VC++ 2008)에서 /DYNAMICBASE 옵션을 지원해 줘야 합니다.

일반적으로 MS Visual C++ 을 이용하여 실행(PE) 파일을 생성하면 (기본값으로) EXE 파일의 ImageBase 는 0x00400000 값이 되고, DLL 파일의 ImageBase 는 0x10000000 값이 됩니다. 이건 VC++ 2008 도 마찬가지 입니다.

하지만 아래와 같이 VC++ 2008 의 옵션이 디폴트로 /DYNAMICBASE 로 되어 있기 때문에 ASLR 이 자동으로 적용됩니다.

<Fig. 2>

만약에 ASLR 기능을 원하지 않을 때는 아래 그림과 같이 옵션을 /DYNAMICBASE:NO 로 변경하시면 됩니다.

<Fig. 3>

ASLR.exe

ASLR.exe

ASLR_no.exe

아주 간단한 콘솔 기반 실행 파일을 만들어 보았습니다.

소스코드는 아래와 같습니다.

<Fig. 4>

ASLR.exe 는 /DYNAMICBASE 옵션으로 빌드 하였고, ASLR_no.exe 는 /DYNAMICBASE:NO 옵션으로 빌드 하였습니다.

두 파일을 각각 디버거로 실행 시켜 보겠습니다.

<Fig. 5>

위 그림은 ASLR.exe 파일을 디버거로 실행시킨 화면입니다. EP 코드 주소와 스택 주소를 봐주세요. (여러분의 환경이 VISTA 이상이라면 실행시킬 때마다 랜덤한 주소가 나타날 것입니다.)

<Fig. 6>

위 그림은 ASLR_no.exe 파일을 디버거로 실행시킨 화면입니다. EP 코드 주소와 스택 주소는 우리가 XP 환경에서 익히 보아오던 주소 그대로 입니다.

이 두 파일들을 PEView 로 살펴보면서 서로 비교해보도록 하겠습니다.

# 섹션 정보

<Fig. 7>

<Fig. 7> 에서 왼쪽이 ASLR.exe 파일이고, 오른쪽이 ASLR_no.exe 파일입니다. ASLR.exe 파일에 “.reloc” 섹션이 추가되어 있는걸 보실 수 있습니다. 보통 EXE 파일에는 “.reloc” 섹션이 없는데, ASLR 기능을 지원하는 파일에는 “.reloc” 섹션이 기본으로 생성되는군요. 이 섹션은 PE Loader 가 참고하긴 하지만 EXE 파일의 경우 실행에 필수적인 섹션은 아닙니다. 즉, EXE 파일의 경우 제거해도 되지요. (아래 링크를 참고하세요.)

☞ 실행 파일에서 ".reloc" 섹션 제거 하기

가장 중요한 내용은 아래에 설명 드리는 IMAGE_FILE_HEADER \ Characteristics 값과 IMAGE_OPTIONAL_HEADER \ DLL Characteristics 값입니다.

# IMAGE_FILE_HEADER \ Characteristics

<Fig. 8>

<Fig. 8> 에서 위쪽이 ASLR.exe 파일이고, 아래쪽이 ASLR_no.exe 파일입니다. “.reloc” 섹션을 가지는 ASLR.exe 파일에는 Characteristics 값에 IMAGE_FILE_RELOCS_STRIPPED 플래그(1)가 빠져 있습니다. (ASLR.exe 파일에는 “.reloc” 섹션이 하나 더 있기 때문에 Number of Sections 값이 1 많습니다.)

# IMAGE_OPTIONAL_HEADER \ DLL Characteristics

<Fig. 9>

<Fig. 9> 에서 위쪽이 ASLR.exe 파일이고, 아래쪽이 ASLR_no.exe 파일입니다. ASLR.exe 파일의 IMAGE_OPTIONAL_HEADER \ DLL Characteristics 값에는 IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 플래그(40)가 세팅되어 있습니다. VC++ 2008 에서 /DYNAMICBASE 옵션을 줘서 빌드하면 이 값이 세팅되는 것입니다. (<Fig. 2> 참고)

이제 여러분은 ASLR 기능을 지원하기 위해서 PE Header 에 추가되어야 할 정보가 어떤 것인지 배웠습니다. 이 정보들을 조작하면서 실습을 해보도록 하겠습니다.

ASLR 기능 취소/추가

# ASLR 기능 취소

ASLR.exe 파일을 hex editor 로 수정하여 ASLR 기능을 취소시켜 보겠습니다.

<Fig. 9> 에 나타난 IMAGE_OPTIONAL_HEADER \ DLL Characteristics 값에서 IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 플래그(40) 를 제거해 주면 ASLR 기능이 간단히 취소됩니다.

Hex editor 에서 DLL Characteristics 값을 8140 에서 8100 으로 변경합니다. (136 옵셋의 WORD 값 - <Fig. 9> 참고)

<Fig. 10>

저장 후 디버거로 실행시켜 봅니다.

<Fig. 11>

위 그림과 같이 ASLR 기능이 취소된 걸 확인 하실 수 있습니다.

# ASLR 기능 추가

이번에는 반대로 ASLR_no.exe 파일을 수정하여 ASLR 기능을 추가시켜 보도록 하겠습니다.

IMAGE_OPTIONAL_HEADER \ DLL Characteristics 값에 IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 플래그(40) 를 추가시켜 보겠습니다.

Hex editor 에서 DLL Characteristics 값을 8100 에서 8140 으로 변경합니다. (136 옵셋의 WORD 값 - <Fig. 9> 참고)

<Fig. 12>

사실 이 작업만으로는 부족합니다. 한가지 작업을 더 해줘야 합니다.

IMAGE_FILE_HEADER \ Characteristics 값에 IMAGE_FILE_RELOCS_STRIPPED 플래그(1) 를 제거해줘야 완벽히 ASLR 기능이 동작합니다. (<Fig. 8> 참고)

Hex editor 에서 Characteristics 값을 0103 에서 0102 로 변경합니다. (EE 옵셋의 WORD 값 - <Fig. 8> 참고)

<Fig. 13>

저장 후 디버거로 실행시켜 봅니다.

<Fig. 14>

위 그림과 같이 ASLR 기능이 추가된 걸 확인 하실 수 있습니다.

위 방법을 사용하시면 기존에 사용하시던 유틸리티들도 (직접 hex editor 로 수정하여) ASLR 기능을 추가시킬 수 있습니다. (Vista 이상에서만 동작함)

여기까지가 제가 준비한 ASLR 관련된 내용입니다.

참고적으로 위에서 잠깐 소개되었던 “.reloc” 섹션을 제거하는 방법에 대해서는 아래 포스트를 참고하세요.

☞ 실행 파일에서 ".reloc" 섹션 제거 하기

+---+

저는 XP 에서 (Vista 를 거치지 않고) 7 으로 바로 넘어왔기 때문에 Vista 부터 추가된 ASLR 기능을 몰랐습니다. 제 블로그를 방문해주시는 어떤 분께서 문의해 주신 내용을 보고 공부를 하게 되었지요. 덕분에 새로운 걸 많이 배우게 되어서 너무 기쁩니다.

감사합니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

API Hooking - '스텔스' 프로세스 (4)

reversecore — Sun, 17 Jan 2010 01:56:58 +0900

Global API Hooking 개념과 구현 방법에 대해서 알아보도록 하겠습니다.

본 내용은 이전 포스트에서 이어지는 내용입니다.

* 참고!
모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows XP SP3 & Windows 7 환경에서 테스트 되었습니다.

Global API Hooking

Global API Hooking 이란 1) 현재 실행중인 모든 프로세스와 2) 앞으로 실행될 모든 프로세스에 대해서 API Hooking 을 시키는 것입니다.

지난번에 설명한 예제 프로그램(HideProc.exe, stealth.dll)은 global hooking 이 아닙니다. 위에서 설명한 2) 번 조건이 만족되지 않기 때문입니다.

HideProc.exe 를 실행 하여 notepad.exe 프로세스를 은폐시켜도 이후에 Process Explorer (혹은 task manager) 를 실행시키면 이들 프로세스에서는 notepad.exe 프로세스를 볼 수 있습니다.

그 이유는 HideProc.exe 실행 이후에 생성된 프로세스들에게는 stealth.dll 파일이 (자동으로) 인젝션 되지 않기 때문입니다.

아래 링크를 참조하여 직접 실습해 보세요.

☞ API Hooking – ‘스텔스’ 프로세스 (2)

이러한 문제를 해결하기 위한 다양한 방법이 있을 수 있습니다.
그 중에서 또 다른 API 를 Hooking 하여 Global API Hooking 을 구현하는 방법에 대해서 설명 드리겠습니다.

Kernel32!CreateProcess() API

새로운 프로세스가 생성되려면 kernel32!CreateProcess() API 를 사용해야 합니다. WinExec(), ShellExecute(), system() 등의 API 도 내부적으로는 CreateProcess() 를 호출합니다.

BOOL WINAPI CreateProcess(
__in_opt     LPCTSTR lpApplicationName,
__inout_opt LPTSTR lpCommandLine,
__in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in         BOOL bInheritHandles,
__in         DWORD dwCreationFlags,
__in_opt     LPVOID lpEnvironment,
__in_opt     LPCTSTR lpCurrentDirectory,
__in         LPSTARTUPINFO lpStartupInfo,
__out        LPPROCESS_INFORMATION lpProcessInformation
);

* 출처 : http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx

따라서 현재 실행중인 모든 프로세스에 stealth.dll 을 인젝션 하고, stealth.dll 에서 CreateProcess() API 를 후킹하면 이후 실행되는 프로세스에게도 자동으로 stealth.dll 을 인젝션 시키도록 만들 수 있습니다.

다시 설명 드리면 모든 프로세스는 부모 프로세스에서 (CreateProcess() 를 이용하여) 생성시켜주기 때문에 부모 프로세스의 CreateProcess() API 를 후킹하여 자식 프로세스에게 stealth.dll 을 인젝션 하도록 만들면 됩니다. (보통 부모 프로세스는 explorer.exe 가 될 것입니다.)

어떤가요? 좋은 아이디어 이지요?
이와 같이 Global API Hooking 의 개념은 어렵지 않습니다.

하지만 CreateProcess() API 를 후킹하면 아래와 같이 고려해야 할 사항들이 있습니다.

1) CreateProcess() API 를 후킹할 때는 kernel32!CreateProcessA(), kernel32!CreateProcessW() 두 개의 API 를 각각 후킹해야 합니다. (ASCII 버전과 UniCode 버전)

2) CreateProcessA(), CreateProcessW() 는 각각 내부적으로 CreateProcessInternalA(), CreateProcessInternalW() 를 호출합니다. 실제 MS 제품들 중에서 일부는 CreateProcessInternalA/W 를 직접 호출하기도 하지요. 따라서 좀 더 정확히 Global API Hooking 을 구현하기 위해서는 이 두 함수를 더 후킹해줘야 합니다.

3) 후킹 함수(NewCreateProcess) 는 원본 함수(CreateProcess) 를 호출 한 후 생성된 자식 프로세스에 대해서 API 를 후킹 해야 합니다. 따라서 아주 짧은 시간동안 자식 프로세스가 후킹 되지 않은 채로 실행될 수 있습니다.

많은 리버싱 선배님들에 의하여 kernel32!CreateProcess() 보다 더 후킹하기 좋은 함수가 발견 되었습니다.
바로 ntdll!ZwResumeThread() API 입니다.

NtResumeThread(
IN HANDLE ThreadHandle,
OUT PULONG SuspendCount OPTIONAL
);

* 유저 모드에서는 NtXXX 계열과 ZwXXX 계열은 동일합니다.

* 출처 : http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtResumeThread.html

ZwResumeThread() 는 프로세스가 생성 된 후 메인 스레드 실행 직전에 호출되는 함수입니다. 따라서 이 함수 하나만 후킹하면 자식 프로세스의 코드가 하나도 실행되지 않은 상태에서 API 를 후킹시킬 수 있습니다.

단점은 ZwResumeThread() 는 undocumented API 라서 언제 바뀔지 알 수 없으며, 그만큼 안정성을 보장 할 수 없습니다. 따라서 ZwResumeThread() 같은 undocumented API 를 후킹 할 때는 OS 가 패치되면서 변경될 수 있다는 것을 항상 염두에 두어야 합니다. 하위 버전에서는 잘 되던 후킹이 최신 버전에서는 갑자기 안 되는 일이 많기 때문입니다.

실습

HideProc2.exe

stealth2.dll

* 참고
위 stealth2.dll 는 CreateProcess 후킹 버전입니다.
ZwResumeThread 후킹 버전을 원하시는 분께서는 따로 요청해 주시면 보내드리겠습니다.

실습을 간단히 하기 위해서 은폐 프로세스를 notepad.exe 로 고정하였습니다. 참고하시기 바랍니다.

#1. stealth2.dll 파일 -> %SYSTEM% 폴더에 복사

<Fig. 1>

실행 중인 모든 프로세스에 stealth2.dll 파일을 인젝션 시킬 예정입니다. 따라서 모든 프로세스에서 공통적으로 인식할 수 있는 path 인 %SYSTEM% 폴더에 stealth2.dll 파일을 복사합니다.

#2. HideProc2.exe –hide 실행

<Fig. 2>

기존 HideProc.exe 와 비교해서 실행 파라미터가 변경되었습니다. 은폐 프로세스 이름이notepad.exe 로 하드코딩 되어있습니다.

HideProc2.exe 를 –hide 옵션으로 실행시키면 이제부터 글로벌 후킹이 시작됩니다.

#3. ProcExp.exe & notepad.exe 실행

Process Explorer(혹은 작업관리자) 와 notepad 를 여러 개 실행 해 주세요.

<Fig. 3>

위 그림을 보시면 ProcExp.exe 와 notepad.exe 프로세스가 각각 2개씩 실행되고 있습니다.
하지만 ProcExp.exe 에서는 notepad.exe 프로세스가 은폐되어 있습니다.

추가로 ProcExp.exe 를 몇 개 더 실행해 보시기 바랍니다. 마찬가지로 새로 생성된 ProcExp.exe 프로세스에서도 notepad.exe 프로세스가 은폐되어서 보이지 않을 것입니다.

이것이 바로 Global API Hooking 의 효과입니다.

#4. HideProc2.exe –show 실행

Global API Hooking 을 해제 합니다.

<Fig. 4>

이제 Process Explorer(혹은 작업관리자) 에서 notepad.exe 프로세스가 보일 것입니다.

소스 코드

# HideProc2.cpp

HideProc2.cpp

HideProc2.cpp 는 기존 HideProc.cpp 에서 실행 파라미터를 줄인 것뿐이므로, 기존 설명을 참고하시면 되겠습니다.