The Code Project - Three Ways to Inject Your Code into Another Process

전체 패키지 다운로드 - 180 Kb
WinSpy 다운로드 - 20 Kb (데모 응용프로그램)

소개

WinSpy

코드프로젝트에는 이미 몇 개의 패스워드 스파이 튜터리얼이 올라와 있지만 이들은 모두 윈도우즈 훅에 의존하고 있다. 이런 유틸리티를 만드는 다른 방법은 없을까? 방법이 있다. 하지만 이 페이지에서 모든 내용들을 명확히 하기 위해 먼저 문제점들을 리뷰 해보기로 한다.

우리의 응용프로그램에 속하건 안 속하건 어떤 컨트롤의 내용들을 "읽기" 위해서 일반적으로 이 컨트롤에 WM_GETTEXT 메시지를 전송한다. 이것은 하나의 특별한 case를 제외한다면 에디트 컨트롤에도 적용할 수 있다. 에디트 컨트롤이 다른 프로세스에 속하고 ES_PASSWORD 스타일이 설정되어 있다면 이러한 접근법은 실패한다. 패스워드 컨트롤을 "소유하는" 프로세스만이 WM_GETTEXT를 경유하여 그 내용을 얻을 수 있다. 그러므로 우리의 문제점은 아래와 같은 점으로 압축된다. 즉 어떻게 하면

::SendMessage( hPwdEdit, WM_GETTEXT, nMaxChars, psBuffer );

를 다른 프로세스의 주소 공간 내에서 실행시킬 수 있는가 하는 점으로 압축된다.

일반적으로 이 문제를 푸는 방법에는 3가지의 가능성이 있다.

우리의 코드를 DLL에 넣은 후 이 DLL을 windows hooks를 이용하여 원격 프로세스에 map 한다.
우리의 코드를 DLL에 넣고 이 DLL을 CreateRemoteThread와 LoadLibrary 테크닉을 이용하여 원격 프로세스에 map 한다.
독립적인 DLL을 작성하는 대신 WriteProcessMemory를 경유하여 우리의 코드를 원격 프로세스에 직접 복사한 후 CreateRemoteThread를 이용하여 이것을 실행한다. 이 테크닉에 관한 자세한 설명은 여기에서 발견할 수 있다.

I. 윈도우즈 훅

데모 응용프로그램 : HookSpy 와 HookInjEx

윈도우즈 훅의 기본적인 역할은 몇몇 쓰레드의 메시지 트래픽을 모니터 하는 것이다. 일반적으로 아래와 같은 것이 있다.

로컬 훅 : 이것으로는 우리의 프로세스에 속하는 모든 쓰레드의 메시지 트래픽을 모니터 한다.
리모트 훅 : 아래 중 하나가 될 수 있다.
1. thread-specific : 다른 프로세스에 속하는 쓰레드의 메시지 트래픽을 모니터 하기 위해.
2. system-wide : 시스템에서 현재 실행되고 있는 모든 쓰레드들의 메시지 트래픽을 모니터 하기 위해.

훅이 될 쓰레드가 다른 프로세스에 속한다면(위의 case 2a와 2b) 우리의 훅 프로시저는 동적 링크 라이브러리(DLL)에 존재해야 한다. 그러면 시스템이 훅 프로시저를 포함하는 DLL을 훅이 되는 쓰레드의 주소 공간으로 map 한다. 윈도우즈는 훅 프로시저만이 아니라 전체 DLL을 map 한다. 윈도우즈 훅이 다른 프로세스의 주소 공간에 코드를 주입하기 위해 이용될 수 있는 이유도 이 때문이다.

이 문서에서 필자는 더 이상 훅에 대해 언급하고 싶지 않지만(자세한 것은 MSDN에서 SetWindowHookEx API를 참조하기 바람) 다른 문서에서 발견하기 힘들지만 매우 유용한 2개의 힌트를 제공해주겠다.

SetWindowsHookEx에 대한 성공적인 호출 후 시스템은 DLL을 훅이 된 쓰레드의 주소 공간으로 자동으로 map 하지만 반드시 바로 map 하는 것은 아니다. 윈도우즈 훅은 모두 메시지와 관련되므로 DLL은 적절한 이벤트가 발생할 때까지는 사실 상 map 되지 않는다. 예를 들면

여러분이 특정 쓰레드의 모든 nonqueued 메시지들(WH_CALLWNDPROC)을 모니터 하는 훅을 설치했다면 메시지가 (특정 윈도우의) 훅이 되는 쓰레드에 실제로 전송될 때까지 이 DLL은 원격 프로세스에 map 되지 않을 것이다. 다른 말로 표현해서 메시지가 훅이 될 쓰레드에 전송되기 전에 UnhookWindowsHookEx가 호출된다면 DLL은 결코 원격 프로세스에 map 되지 않을 것이다(SetWindowsHookEx에 대한 호출 자체가 성공했을지라도). 바로 mapping이 되도록 하려면 SetWindowsHookEx에 대한 호출 직후에 관련된 쓰레드에 적절한 이벤트를 전송한다.

UnhookWindowsHookEx 호출 후의 DLL의 unmapping에 대한 것도 동일하다. 적절한 이벤트가 발생할 때까지 DLL은 사실 상 unmap 되지 않는다.
훅을 설치할 때 이들은 시스템 전체의 performance에 영향을 미칠 수 있다(특히 system-wide 훅의 경우). 하지만 이런 단점은 메시지 trap 장치로서가 아니라 DLL mapping 메커니즘 목적으로만 thread-specific 훅을 이용한다면 쉽게 극복할 수 있다. 아래의 코드 조각을 참고하라.
```
BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved )
{
    if( ul_reason_for_call == DLL_PROCESS_ATTACH )
    {
        // Increase reference count via LoadLibrary
        char lib_name[MAX_PATH]; 
        ::GetModuleFileName( hModule, lib_name, MAX_PATH );
        ::LoadLibrary( lib_name );

        // Safely remove hook
        ::UnhookWindowsHookEx( g_hHook );
    }    
    return TRUE;
}
```
그런데 무슨 일이 일어났을까? 먼저 우리는 윈도우즈 훅을 경유하여 원격 프로세스에 대해 DLL을 map 했다. 그런 후 이 DLL이 실제로 map이 된 직후에 우리는 이것을 다시 unhook 한다. 정상적으로는 훅이 된 쓰레드에 첫 번째 메시지가 도달하는 순간 이 DLL도 역시 unmap 될 것이다. 트릭으로서 우리는 LoadLibrary를 통해 DLL의 참조 카운트를 증가시킴으로써 이 ummapping을 방지한다.

남은 의문점은 할 일을 다 마친 후 이 DLL을 어떻게 unload 하는가 하는 점이다. 우리는 이미 쓰레드를 unhook 했으므로 UnhookWindowsHookEx는 이런 작업을 하지 않을 것이다. 이 문제는 아래와 같이 함으로써 해결할 수 있다.
- DLL을 unmap 하려고 하기 직전에 다른 훅을 설치한다.
- 원격 쓰레드에 대해 "특수" 메시지를 전송한다.
- 여러분의 훅 프로시저에서 이 메시지를 catch 한다. 이것에 반응해서 FreeLibrary와 UnhookWindowsHookEx를 호출한다.
이제 훅은 원격 프로세스에 대해서 또는 원격 프로세스로부터 mapping/unmapping을 하는 동안에만 이용되므로 "훅이 되는" 쓰레드의 performance에 유의미한 영향을 미치지 않는다. 다른 말로 표현해서 아래에서 언급할 LoadLibrary 테크닉(Section II 참조)보다 대상 프로세스를 덜 간섭하는 DLL mapping 메커니즘을 알아 보았다. 그렇지만 이 해결책은 LoadLibrary 테크닉에 반해 윈NT와 윈9x에 대해 모두 동작한다.

그런데 언제 이 트릭을 이용해야 할까? 항상 DLL이 원격 프로세스에서 오랜 기간 존재하고(즉 다른 프로세스에 속하는 컨트롤을 subclass 할 경우) 대상 프로세스를 최소한 간섭하고 싶을 때 이용해야 한다. HookSpy에서는 DLL이 잠시 동안(패스워드를 알아내기에 충분할 정도의) 주입되기 때문에 이 트릭을 이용하지 않았다. 이 트릭을 보여주기 위해 필자는 HookInjEx라는 다른 예제를 만들었다. HookInjEx는 DLL을 "explorer.exe"로 map/unmap 하는데 여기에서 이것은 시작 버튼을 subclass 한다. 즉 이것은 시작 버튼의 왼쪽 마우스 클릭과 오른쪽 마우스 클릭을 전환(swap)한다.

HookSpy와 HookInjEx와 이들의 소스는 이 문서의 첫 머리에 있는 다운로드 패키지에서 찾을 수 있을 것이다.

II. CreateRemoteThread와 LoadLibrary 테크닉

데모 응용프로그램 : LibSpy

일반적으로 모든 프로세스는 LoadLibrary API를 이용하여 DLL을 동적으로 로드 할 수 있다. 하지만 어떻게 해야 외부의 프로세스가 이 함수를 호출할 수 있게 할 수 있을까? 해답은 CreateRemoteThread를 이용하는 것이다.

먼저 LoadLibrary와 FreeLibrary API의 함수 선언을 살펴보자.

HINSTANCE LoadLibrary(
  LPCTSTR lpLibFileName   // 라이브러리 모듈의 파일 명의 주소
);

BOOL FreeLibrary(
  HMODULE hLibModule      // 로드 된 라이브러리 모듈에 대한 핸들
);

이제 이들을 CreateRemoteThread에 전달되는 쓰레드 루틴인 ThreadProc의 함수 선언과 비교해보자.

DWORD WINAPI ThreadProc(
  LPVOID lpParameter   // 쓰레드 데이터
);

위에서 볼 수 있듯이 모든 함수들이 동일한 호출 관례를 이용하며 모두 32비트 인자를 받아들인다. 또한 반환되는 값의 크기가 동일하다. 다른 말로 표현해서 우리는 CreateRemoteThread에 대한 쓰레드 루틴으로서 LoadLibrary/FreeLibrary에 대한 포인터를 전달할 수도 있다.

하지만 여기에는 두 가지의 문제가 있다(아래의 CreateRemoteThread에 대한 설명 참조).

CreateRemoteThread의 lpStartAddress 인자는 원격 프로세스에서의 쓰레드 루틴의 시작 주소를 나타내야 한다.
ThreadFunc에 전달되는 인자인 lpParameter가 일반적인 32비트 값으로 해석된다면(FreeLibrary는 이것을 HMODULE로 해석함) 모든 것은 잘 돌아간다. 하지만 lpParameter가 포인터로 해석된다면(LoadLibraryA는 이것을 char 스트링에 대한 포인터로 해석함) 이것은 원격 프로세스의 특정 데이터를 가리켜야 한다.

첫 번째 문제는 사실 자체적으로 해결된다. LoadLibrary와 FreeLibray는 둘 다 kernel32.dll에 존재하는 함수들이다. kernel32는 모든 "정상" 프로세스에서 항상 존재하며 동일한 로드 주소에 있는 것이 보증되므로(부록 A 참조) LoadLibrary/FreeLibray의 주소는 모든 프로세스에서 역시 동일하다. 이것은 원격 프로세스에 유효한 포인터가 전달되는 것을 보증해준다.

두 번째 문제 또한 쉽게 해결된다. 즉 단순하게 WriteProcessMemory를 통하여 원격 프로세스에 DLL 모듈 이름(LoadLibrary에 필요한)을 복사해준다.

그래서 CreateRemoteThread 와 LoadLibrary 테크닉을 이용하려면 아래와 같은 단계를 따른다.

원격 프로세스에 대한 HANDLE을 얻는다(OpenProcess).
원격 프로세스 내에서 DLL 이름을 위한 메모리를 할당한다(VirtualAllocEx).
할당된 메모리에 전체 경로를 포함하는 DLL 이름을 기록한다(WriteProcessMemory).
CreateRemoteThread와 LoadLibrary를 이용하여 원격 프로세스에 여러분의 DLL을 map 한다.
원격 쓰레드가 종료할 때까지 기다린다(WaitForSingleObject). 이것은 LoadLibrary에 대한 호출이 반환할 때까지 기다리는 것이다. 다른 말로 표현해서 이 쓰레드는 우리의 DllMain(DLL_PROCESS_ATTACH라는 reason으로 호출됨)이 반환하는 순간 종료할 것이다.
원격 쓰레드의 탈출 코드를 얻는다(GetExitCodeThread). 이 값은 LoadLibrary에 의해 반환되는 값으로서 우리의 map 된 DLL의 base address(HMODULE)라는 점에 주의하라.
단계 2에서 할당된 메모리를 해제한다(VirtualFreeEx).
CreateRemoteThread와 FreeLibrary를 이용하여 원격 프로세스에서 DLL을 unload 한다. FreeLibrary에 단계 6에서 반환된 HMODULE을 전달한다(CreateRemoteThread의 lpParameter 를 경유하여).
주의 : 여러분의 주입된 DLL이 새로운 쓰레드를 spawn 했다면 이 DLL을 unloading 하기 전에 그들이 종료되었는지를 확인하라.
쓰레드가 종료할 때까지 기다린다(WaitForSingleObject).

또한 작업이 끝났다면 모든 핸들들을 닫는 것을 잊지 말기 바란다. 즉 단계 4와 8에서 생성된 두 개의 쓰레드에 대한 핸들과 단계 1에서 반환된 원격 프로세스에 대한 핸들을 닫는다.

이제 실제로 위의 단계들이 어떤 식으로 구현되었는지를 살펴보기 위해 LibSpy의 소스 일부를 검토해보자. 간단히 하기 위해 에러 처리와 유니코드 지원이 제거되었다.

HANDLE hThread;
char    szLibPath[_MAX_PATH];  // "LibSpy.dll" 모듈의 이름
                               // (전체 경로를 포함!);
void*   pLibRemote;   // szLibPath가 복사될  
                      // 주소(원격 프로세스에서의)
DWORD   hLibModule;   // 로드 된 모듈의 base address(==HMODULE);
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");

// szLibPath 초기화
//...

// 1. szLibPath를 위해 원격 프로세스에 메모리를 할당한다
// 2. 할당된 메모리에 szLibPath를 기록한다
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),
                               MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,
                      sizeof(szLibPath), NULL );


// 원격 프로세스로 "LibSpy.dll"을 로드한다
// (CreateRemoteThread와 LoadLibrary를 이용하여)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
            (LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
                                       "LoadLibraryA" ),
             pLibRemote, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );

// 로드 된 모듈의 핸들을 얻는다
::GetExitCodeThread( hThread, &hLibModule );

// Clean up
::CloseHandle( hThread );
::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );

우리의 SendMessage(실제로 우리가 주입하고 싶어하는 코드)가 DllMain(DLL_PROCESS_ATTACH)에 위치하고 있다고 가정한다면 이것은 이제 이미 실행되었을 것이다. 그러므로 이제 대상 프로세스에서 DLL을 unload 할 시점이다.

// 대상 프로세스에서 "LibSpy.dll"을 unload 한다
// (CreateRemoteThread와 FreeLibrary를 이용하여)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
            (LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
                                       "FreeLibrary" ),
            (void*)hLibModule, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );

// Clean up
::CloseHandle( hThread );

Interprocess Communications

지금까지 우리는 원격 프로세스에 DLL을 주입하는 법에 대해서만 논했다. 하지만 대부분의 상황에서 주입된 DLL은 여러분의 원래의 응용프로그램과 특정 방식으로 통신을 할 필요가 있을 것이다(이제 DLL은 우리의 로컬 응용프로그램이 아니라 특정 원격 프로세스에 map 되었다는 것을 상기하라). 우리의 Password Spy를 예로 들어보자. DLL은 실제 패스워드를 포함하는 컨트롤에 대한 핸들을 알아야 한다. 이 값은 명백히 컴파일 시에 hardcord 될 수가 없다. 마찬가지로 DLL이 일단 패스워드를 얻었다면 이것은 우리가 이 패스워드를 적절히 디스플레이 할 수 있도록 우리의 응용프로그램으로 전송해주어야 한다.

다행히도 이런 상황을 처리하는 많은 방법들이 있다. 몇 가지만 열거해보면 File Mapping, WM_COPYDATA, 클립보드 그리고 때때로는 매우 편한 #pragma data_seg 등이 있다. 이들 테크닉은 MSDN(Interprocess Communications 참조)이나 다른 튜터리얼에 잘 문서화되어 있으므로 여기서는 특별히 언급하지 않을 것이다. 어쨌든 필자는 LibSpy 예제에서 오직 #pragma data_seg만 이용했다.

LibSpy와 이것의 소스는 이 문서의 첫 머리에 있는 다운로드 패키지에서 찾을 수 있을 것이다.

III. CreateRemoteThread와 WriteProcessMemory 테크닉

데모 응용프로그램 : WinSpy

다른 프로세스의 주소 공간에 특정 코드를 복사한 후 이 프로세스의 컨텍스트 내에서 실행하는 또 다른 방법은 원격 쓰레드와 WriteProcessMemory API를 이용하는 방법이다. 독립적인 DLL을 작성하는 대신 우리는 코드를 원격 프로세스에 직접 복사한 후(WriteProcessMemory를 이용하여) CreateRemoteThread를 이용하여 이것을 실행한다.

먼저 CreateRemoteThread의 함수 선언을 살펴보자.

HANDLE CreateRemoteThread(
  HANDLE hProcess,        // 쓰레드를 생성하고자 하는 프로세스에 대한 핸들
  LPSECURITY_ATTRIBUTES lpThreadAttributes,  // 보안 속성에 대한 포인터
  DWORD dwStackSize,      // 초기의 쓰레드 스택 크기. 바이트 단위
  LPTHREAD_START_ROUTINE lpStartAddress,     // 쓰레드 함수에 대한 포인터
  LPVOID lpParameter,     // 새 쓰레드를 위한 인자
  DWORD dwCreationFlags,  // 생성 플랙
  LPDWORD lpThreadId      // 반환되는 쓰레드 식별자에 대한 포인터
);

이것을 CreateThread(MSDN)의 함수 선언과 비교해보면 아래와 같은 차이점을 알 수 있을 것이다.

CreateRemoteThread에는 hProcess 인자가 추가적으로 있다. 이것은 쓰레드가 생성될 프로세스에 대한 핸들이다.
CreateRemoteThread에서 lpStartAddress 인자는 원격 프로세스 주소 공간에서의 쓰레드의 시작 주소를 나타낸다. 이 함수는 원격 프로세스에 존재해야 하므로 단순하게 로컬 ThreadFunc에 대한 포인터를 전달할 수가 없다. 먼저 원격 프로세스에 이 코드를 복사해야 한다.
동일하게 lpParameter가 가리키는 데이터는 원격 프로세스에 존재해야 하므로 이것 역시 복사해주어야 한다.

이제 이 테크닉을 정리해보면 아래와 같다.

원격 프로세스에 대한 HANDLE을 얻는다(OpenProces).
주입될 데이터를 위해 원격 프로세스의 주소 공간에 메모리를 할당한다(VirtualAllocEx).
할당된 메모리에 초기화된 INJDATA 구조체의 복사본을 기록한다(WriteProcessMemory).
주입될 코드를 위해 원격 프로세스의 주소 공간에 메모리를 할당한다.
할당된 메모리에 ThreadFunc의 복사본을 기록한다.
CreateRemoteThread를 이용하여 ThreadFunc의 원격 복사본을 시작한다.
원격 쓰레드가 종료할 때까지 기다린다(WaitForSingleObject).
원격 프로세스에서 결과를 얻는다(ReadProcessMemory 또는 GetExitCodeThread).
단계 2와 4에서 할당되었던 메모리를 해제한다(VirtualFreeEx).
단계 6과 1에서 얻었던 핸들들을 닫는다(CloseHandle).

ThreadFunc가 지켜야 할 추가적인 주의사항

ThreadFunc는 kernel32.dll과 user32.dll에 없는 함수들을 호출해서는 안 된다. kernel32와 user32만이 프로세스에 존재할 경우(user32는 모든 윈32 프로세스에 map 되는 것은 아니라는 것에 주의) 로컬 프로세스와 대상 프로세스 모두에서 동일한 로드 주소에 있다는 것이 보증된다(부록 A 참조). 다른 라이브러리에 있는 함수들이 필요할 경우 주입된 코드에 LoadLibrary와 GetProcAddress의 주소를 전달하여 주입된 코드가 나머지 일을 자체적으로 처리하게 한다. 어떤 이유론가 문제의 DLL이 이미 대상 프로세스에 map 되어 있다면 LoadLibrary 대신 GetModuleHandle을 이용할 수도 있다.
마찬가지로 ThreadFunc 내에서 여러분 자신의 서브루틴을 호출하고 싶다면 각 루틴을 원격 프로세스에 개별적으로 복사한 후 INJDATA를 통하여 이들의 주소를 ThreadFunc에게 제공해준다.
정적 string들을 전혀 이용하지 않는다. 그 보다는 모든 string들을 INJDATA를 통하여 ThreadFunc에 전달한다. 그 이유는 컴파일러가 모든 정적 string들을 실행 파일의 ".data" 섹션에 집어 넣고 코드에는 오직 reference(=포인터)만이 남기 때문이다. 그 결과 원격 프로세스에 있는 ThreadFunc의 복사본은 존재하지 않는 무엇인가(적어도 주소 공간에 없는)를 가리킬 것이다.
/GZ 컴파일러 스위치를 제거한다. 이것은 디버그 빌드의 경우 기본적으로 설정된다(부록 B 참조).
ThreadFunc와 AfterThreadFunc를 static으로 선언하거나 증분 링크(incremental linking)을 사용하지 않는다(부록 C 참조).
ThreadFunc의 지역 변수는 한 페이지(4kb)보다 작아야 한다(부록 D 참조). 디버그 빌드에서는 이용할 수 있는 4kb 중 약 10바이트 정도가 내부 변수들을 위해 이용된다는 점에 주의하라.

3개보다 많은 case 문을 가진 switch 블록이 있다면 아래와 같은 식으로 분할한다.

switch( expression ) {
    case constant1: statement1; goto END;
    case constant2: statement2; goto END;
    case constant3: statement2; goto END;
}
switch( expression ) {
    case constant4: statement4; goto END;
    case constant5: statement5; goto END;
    case constant6: statement6; goto END;
}
END:

또는 if-else if 시퀀스로 수정한다(부록 E 참조).

이 규칙을 지키지 않는다면 거의 확실하게 대상 프로세스가 crash 할 것이다. 대상 프로세스에서의 작업이 여러분의 프로세스에서와 같이 동일한 주소에서 일어난다고 가정해서는 안 된다는 것을 분명히 기억해야 한다(부록 F 참조).

GetWindowTextRemote(A/W)

"원격" 에디트 컨트롤에서 패스워드를 얻기 위해 필요한 모든 기능들은 GetWindowTextRemot(A/W)에 캡슐화 되어 있다.

int GetWindowTextRemoteA( HANDLE hProcess, HWND hWnd, LPSTR  lpString );
int GetWindowTextRemoteW( HANDLE hProcess, HWND hWnd, LPWSTR lpString );

인자들

hProcess: 에디트 컨트롤이 속해 있는 프로세스에 대한 핸들
hWnd: 패스워드를 포함하는 에디트 컨트롤에 대한 핸들
lpString: 텍스트를 얻기 위한 버퍼에 대한 포인터

반환 값

반환 값은 복사된 문자들의 수이다.

GetWindowTextRemote가 어떻게 작동하는 지를 보기 위해 이제 소스의 몇몇 부분(특히 주입되는 데이터와 코드)을 살펴보자. 반복하지만 간단하게 하기 위해 유이코드 지원이 제거되었다.

INJDATA

typedef LRESULT     (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);

typedef struct {    
    HWND hwnd;                    // 에디트 컨트롤에 대한 핸들
    SENDMESSAGE  fnSendMessage;   // user32!SendMessageA에 대한 포인터

    char psText[128];    // 패스워드를 수신하기 위한 버퍼
} INJDATA;

INJDATA는 원격 프로세스에 주입되는 데이터 구조체이다. 하지만 그러기 전에 이 구조체의 SendMessageA에 대한 포인터는 우리의 응용프로그램에서 초기화되어야 한다. 여기에서의 트릭은 user32.dll은 (존재할 경우!) 모든 프로세스에서 항상 동일한 주소에 map 된다는 것을 이용하는 것이다. 그러므로 SendMessageA의 주소도 항상 동일하다. 이것은 원격 프로세스로 유효한 포인터가 전달되는 것을 보증해준다.

ThreadFunc

static DWORD WINAPI ThreadFunc (INJDATA *pData) 
{
    pData->fnSendMessage( pData->hwnd, WM_GETTEXT,    // Get password
                          sizeof(pData->psText),
                          (LPARAM)pData->psText );  
    return 0;
}

// 이 함수는 ThreadFunc 뒤의 메모리 주소 위치를 표시해준다.
// int cbCodeSize = (PBYTE) AfterThreadFunc - (PBYTE) ThreadFunc.
static void AfterThreadFunc (void)
{
}

ThradFunc은 원격 쓰레드에 의해 실행되는 코드이다. 흥미로운 점은 아래와 같다.

ThreadFunc의 코드 크기를 계산하기 위해 AfterThreadFunc가 어떻게 이용되는 지에 대해 주목하라. 일반적으로 이것은 최선의 아이디어는 아니다. 왜냐하면 링커가 여러분의 함수들의 순서를 마음대로 바꿀 수 있기 때문이다(즉 이것은 ThreadFunc를 AfterThreadFunc뒤에 위치하게 할 수도 있음). 하지만 우리의 WinSpy처럼 작은 프로젝트에서는 여러분의 함수들의 순서가 보존될 것이라는 것을 거의 확신할 수 있다. 필요하다면 확실히 하기 위해 /ORDER 링커 옵션을 이용할 수도 있을 것이다. 더 좋은 방법은 디스어셈블러로 ThreadFunc의 크기를 측정하는 것이다.

이 테크닉으로 원격 컨트롤을 subclass 하는 법

데모 응용프로그램 : InjectEx

이제 조금 더 복잡한 문제 즉 이 테크닉으로 다른 프로세스에 속하는 컨트롤을 subclass 하는 방법에 대해 설명하기로 한다.

먼저 이 작업을 완수하기 위해 여러분은 원격 프로세스에 아래의 두 개의 함수를 복사해야 한다.

ThreadFunc : SetWindowLong을 통하여 원격 프로세스에 있는 컨트롤을 실제로 subclass 한다
NewProc : subclass 된 컨트롤의 새 윈도우 프로시저

하지만 주요 문제는 원격 NewProc에 데이터를 어떻게 전달하는가 하는 점이다. NewProc은 콜백 함수이며 특별한 가이드라인을 따라야 하므로 우리는 이 함수에 인자로서 INJDATA에 대한 포인터를 단순하게 전달할 수가 없다. 다행히도 이 문제를 해결하는 다른 방법들이 있는데(필자는 2개를 발견했음) 이들은 모두 어셈블리 언어에 의존한다. 그래서 지금까지는 어셈블리와 관련된 것을 부록에 넣었었는데 이것 없이는 더 이상 논의를 진행할 수가 없었다.

해결책 1

아래의 그림을 보기 바란다.

The virtual address space

원격 프로세스에서 NewProc 바로 직전에 INJDATA가 위치한다는 점에 주목하라. 이런 방식에 의해 NewProc은 원격 프로세스 주소 공간에서의 INJDATA의 메모리 위치를 컴파일 시에 알게 된다. 더 정확하게는 이것은 자신의 위치에 상대적인 INJDATA의 주소를 안다. 그리고 사실 상 이것은 우리가 필요로 하는 모든 것이다. 이제 NewProc은 아래와 같을 것이다.

static LRESULT CALLBACK NewProc(
  HWND hwnd,       // 윈도우에 대한 핸들
  UINT uMsg,       // 메시지 식별자
  WPARAM wParam,   // 첫 번째 메시지 인자
  LPARAM lParam )  // 두 번째 메시지 인자
{
    INJDATA* pData = (INJDATA*) NewProc;  // pData는 NewProc을 가리킨다;
    pData--;              // 이제 pData는 INJDATA를 가리킨다;
                          // 원격 프로세스에서 INJDATA는 NewProc 바로 직전에 있다는 것을 상기하라;

    //-----------------------------
    // subclassing 코드가 여기에 온다
    // ........
    //-----------------------------

    // 원래의 윈도우 프로시저를 호출한다;
    // (원격)ThreadFunc에 의해 fnOldProc(SetWindowLong에 의해 반환되는)가     
    // 초기화되고 (원격)INJDATA에 저장된다;
    return pData->fnCallWindowProc( pData->fnOldProc, 
                                    hwnd,uMsg,wParam,lParam );
}

하지만 여기에는 아직 문제가 있다. 첫 번째 줄을 보기 바란다.

INJDATA* pData = (INJDATA*) NewProc;

이런 방식으로는 hardcode 된 값(우리의 프로세스에서의 원본 NewProc의 메모리 위치)이 pData에 들어갈 것이다. 이것은 전혀 우리가 원하는 바가 아니다. 우리가 원하는 것은 현재의 NewProc의 위치가 어떻던 간에 원격 프로세스로 실제적으로 옮겨진 "현재의" NewProc의 복사본의 메모리 위치이다. 다른 말로 표현해서 우리는 일종의 "this 포인터"를 필요로 한다.

C/C++에서는 이 문제를 해결할 방법이 없지만 인라인 어셈블리를 이용하면 이 문제를 해결할 수 있다. 수정된 NewProc을 살펴보자.

static LRESULT CALLBACK NewProc(
  HWND hwnd,      // 윈도우에 대한 핸들
  UINT uMsg,      // 메시지 식별자
  WPARAM wParam,  // 첫 번째 메시지 인자
  LPARAM lParam ) // 두 번째 메시지 인자
{
    // INJDATA 구조체의 위치를 계산한다;
    // 원격 프로세스에서 INJDATA는 NewProc 바로 직전에 위치한다는 것을 기억하라;
    INJDATA* pData;
    _asm {
        call    dummy
dummy:
        pop     ecx         // <- ECX는 현재의 EIP 값을 가진다
        sub     ecx, 9      // <- ECX는 NewProc의 주소 값을 가진다
        mov     pData, ecx
    }
    pData--;

    //-----------------------------
    // subclassing 코드가 여기에 온다
    // ........
    //-----------------------------

    // 원래의 윈도우 프로시저를 호출한다
    return pData->fnCallWindowProc( pData->fnOldProc, 
                                    hwnd,uMsg,wParam,lParam );
}

이제 무슨 일이 일어났을까? 거의 모든 프로세서는 실행될 다음 명령어코드의 메모리 위치를 가리키는 특수 레지스터를 가지고 있다. 이것이 소위 32비트 인텔 프로세서와 AMD 프로세서에서 EIP로 표기되는 instruction pointer이다. EIP는 특수 레지스터이므로 범용 레지스터들(EAX, EBX 등)과 같이 프로그래밍적으로 접근할 수가 없다. 다른 말로 표현하면 EIP를 address 하고 이것의 내용을 명시적으로 읽거나 변경할 수 있는 OpCode가 없다. 그렇지만 그럼에도 불구하고 EIP는 JMP, CALL과 RET과 같은 명령어코드에 의해 암묵적으로 변경(그리고 계속 변경)할 수 있다. 예를 들어 서브루틴 CALL/RET 메커니즘이 32비트 인텔 프로세서와 AMD 프로세스에서 어떻게 작동하는지를 살펴보기로 하자.

여러분이 서브루틴을 호출할 때(CALL을 경유하여) EIP에 서브루틴의 주소가 로드 된다. 하지만 EIP가 수정되기 직전에 이것의 기존 값이 자동적으로 스택에 push 된다(후에 되돌아가는 instruction pointer로 이용하기 위해). 서브루틴의 끝에서 RET 명령어코드는 스택의 꼭대기에서 pop을 하여 이 값을 EIP로 넣어준다.

이제 여러분은 CALL과 RET에 의해 EIP가 어떻게 변경되는지를 알았는데 그러면 현재 값은 어떻게 얻을 수 있을까?
아마 CALL이 스택에 EIP를 push 한다는 것을 기억할 것이다. 그러므로 현재의 값을 얻기 위해 "dummy 함수"를 호출한 직후 스택에서 바로 pop을 한다. 이제 우리의 컴파일 된 NewProc에서의 전체 트릭에 대해 설명하겠다.

 Address   OpCode/Params   Decoded instruction
--------------------------------------------------
:00401000  55              push ebp            ; NewProc의 엔트리 포인트
:00401001  8BEC            mov ebp, esp
:00401003  51              push ecx
:00401004  E800000000      call 00401009       ; *a*    dummy 호출
:00401009  59              pop ecx             ; *b*
:0040100A  83E909          sub ecx, 00000009   ; *c*
:0040100D  894DFC          mov [ebp-04], ecx   ; mov pData, ECX
:00401010  8B45FC          mov eax, [ebp-04]
:00401013  83E814          sub eax, 00000014   ; pData--;
.....
.....
:0040102D  8BE5            mov esp, ebp
:0040102F  5D              pop ebp
:00401030  C21000          ret 0010

dummy 함수 호출. 이것은 단순히 다음 명령어코드로 jump 하며 스택에 EIP를 push 한다.
스택의 값을 ECX로 pop 한다. 이 값은 역시 정확히 "pop ECX" 명령어코드의 주소이다.
NewProc의 entry point와 "pop ECX" 명령어코드 사이의 "거리"가 9바이트라는 것에 주목하라. 그래서 NewProc의 주소를 계산하기 위해 ECX에서 9를 뺀다.

이런 방식에 의해 NewProc은 자신이 실제 어떤 위치로 옮겨졌는지에 관계없이 항상 자신의 주소를 계산할 수 있다. 하지만 여러분이 컴파일러/링커 옵션을 바꾸면 NewProc의 entry point와 "pop ECX" 명령어코드 사이의 거리가 바뀔 수도 있다는 점에 유의하라. 그리고 릴리즈 빌드와 디버그 빌드 사이에서도 역시 다르다. 하지만 중요한 것은 그럼에도 불구하고 여러분이 컴파일 시에 정확한 값을 알고 있다는 점이다.

먼저 우리의 함수를 컴파일 한다.
디스어셈블러로 정확한 거리를 알아낸다.
마지막으로 정확한 거리 값을 가지고 다시 컴파일 한다.

이것은 InjectEx에서 이용된 해결책이다. InjectEx는 HookInjEx와 유사하게 시작 버튼의 왼쪽, 오른쪽 마우스 클릭을 전환(swap).

해결책 2

원격 프로세스 주소 공간에서 NewProc 바로 앞에 INJDATA를 위치하게 하는 방법은 우리의 문제를 해결하는 유일한 방법은 아니다. 아래의 다른 방식의 NewProc을 살펴보자.

static LRESULT CALLBACK NewProc(
  HWND hwnd,      // 윈도우에 대한 핸들
  UINT uMsg,      // 메시지 식별자
  WPARAM wParam,  // 첫 번째 메시지 인자
  LPARAM lParam ) // 두 번째 메시지 인자
{
    INJDATA* pData = 0xA0B0C0D0;    // dummy 값

    //-----------------------------
    // subclassing 코드가 여기에 온다
    // ........
    //-----------------------------

    // 원래의 윈도우 프로시저를 호출한다
    return pData->fnCallWindowProc( pData->fnOldProc, 
                                    hwnd,uMsg,wParam,lParam );
}

여기에서 0xA0B0C0D0는 단순히 원격 프로세스 주소 공간에서의 INJDATA의 실제(절대!) 주소를 위한 placeholder이다. 이 주소는 컴파일 시에는 알 수 없다는 것을 상기하기 바란다. 하지만 VirtualAllocEx(INJDATA를 위한)에 대한 호출이 이루어진 직후에는 원격 프로세스에서의 INJDATA의 위치를 알게 된다.

우리의 NewProc은 아래와 같은 식으로 컴파일 될 것이다.

 Address   OpCode/Params     Decoded instruction
--------------------------------------------------
:00401000  55                push ebp
:00401001  8BEC              mov ebp, esp
:00401003  C745FCD0C0B0A0    mov [ebp-04], A0B0C0D0
:0040100A  ...
....
....
:0040102D  8BE5              mov esp, ebp
:0040102F  5D                pop ebp
:00401030  C21000            ret 0010

그러므로 컴파일 된 코드(16진 값으로)는 다음과 같을 것이다 : 558BECC745FCD0C0B0A0......8BE55DC21000.

이제 아래와 같이 진행하면 될 것이다.

대상 프로세스에 INJDATA, ThreadFunc와 NewProc을 복사한다.

NewProc의 코드를 변경하여 pData가 INJDATA의 실제 주소를 가리키게 한다.
예를 들어 대상 프로세스에서의 INJDATA의 주소(VirtualAllocEx에 의해 반환된 값)가 0x008a0000이라고 하자. 그러면 우리는 NewProc의 코드를 다음과 같이 변경한다.

`558BECC745FCD0C0B0A0......8BE55DC21000`	`<-` 원래의 `NewProc` ¹
`558BECC745FC00008A00......8BE55DC21000`	`<-` `INJDATA`의 실제 주소를 가리키는 변경된 `NewProc`

다른 말로 표현해서 dummy 값인 A0B0C0D0을 INJDATA의 실제 주소로 대체한다. ²

원격 ThreadFunc의 실행을 시작하면 이것이 원격 프로세스에서 컨트롤을 subclass 한다.

¹ 어째서 컴파일 된 코드에서 주소 A0B0C0D0과 008a0000이 역순으로 보이는지 의아해하는 사람이 있을 것이다. 이것은 인텔 프로세서와 AMD 프로세서가 그들의 (멀티 바이트) 데이터를 표현하기 위해 little-endian 표기법을 이용하기 때문이다. 다른 말로 표현해서 숫자의 하위 바이트가 메모리의 가장 낮은 주소에 저장되며 상위 바이트가 가장 높은 주소에 저장된다.
UNIX라는 단어가 4바이트에 저장된다고 가정하자. big-endian 시스템에서는 UNIX라고 저장될 것이다. 반면 little-endian 시스템에서는 XINU로 저장될 것이다.

² 몇몇 (악성) 크랙들은 이와 유사한 방식으로 실행 파일의 코드를 변경한다. 하지만 일단 메모리에 로드 되면 프로그램은 자신의 코드를 변경할 수 없다(코드는 실행 파일의 ".text" 섹션에 존재하는데 여기는 쓰기 금지로 되어 있다). 그럼에도 불구하고 우리는 우리의 원격 NewProc을 변경할 수 있다. 왜냐하면 이 함수는 이전에 PAGE_EXECUTE_READWRITE permission을 가진 메모리 부분에 복사되었기 때문이다.

언제 이 CreateRemoteThread와 WriteProcessMemory 테크닉을 이용하는가?

코드 주입을 위한 CreateRemoteThread와 WriteProcessMemory 테크닉은 다른 방법들과 비교해볼 때 추가적인 DLL을 필요로 하지 않는다는 점에서 좀 더 유연성이 있다. 불행히도 이것은 다른 방법들에 비해 좀 더 복잡하고 좀 더 위험하기도 하다. ThreadFunc에 무엇인가 잘못되면 원격 프로세스가 쉽게 crash 할 수(대부분의 경우 반드시) 있다(부록 F 참조). 원격 ThreadFunc를 디버깅 하는 것은 악몽이 될 수도 있으므로 이 테크닉은 최대 몇 개의 명령어코드를 주입할 때만 이용해야 한다. 많은 코드 조각을 주입하려면 섹션 II와 I에서 설명했던 방법 중 하나를 이용하기 바란다.

반복하건대 WinSpy와 InjectEx와 이들의 소스는 이 문서의 첫 머리에 있는 다운로드 패키지에서 찾을 수 있을 것이다.
　

마치면서

마지막으로 지금까지 설명해왔던 것을 정리해보기로 한다.

	OS	프로세스
I. 훅	윈9x와 윈NT	USER32.DLL¹과 링크하는 프로세스들만
II. CreateRemoteThread와 LoadLibrary	윈NT만²	시스템 서비스⁴를 포함한 모든 프로세스들³
III. CreateRemoteThread와 WriteProcessMemory	윈NT만	시스템 서비스를 포함한 모든 프로세스들

명백히 메시지 큐가 없는 쓰레드는 훅을 걸 수 없다. 그리고 SetWindowsHookEx는 시스템 서비스와는 동작하지 않는다(이들이 USER32.DLL과 링크되어 있다고 하더라도).
윈9x에는 CreateRemoteThread도 VirtualAllocEx도 없다(사실 상 이들은 윈9x에서 emulate 될 수 있는데 이것은 오래 된 옛날 이야기이다).
모든 프로세스 = 모든 윈32 프로세스 + csrss.exe
고유(native)의 응용프로그램들(smss.exe, os2ss.exe, autochk.exe 등)은 윈32 API를 이용하지 않으며 kernel32.dll에 대해서도 링크하지 않는다. 유일한 예외는 윈32 서브시스템 자체인 csrss.exe이다. 이것은 고유(native)의 응용프로그램이지만 이것의 라이브러리(~winsrv.dll) 중 일부는 kernel32.dll을 포함한 윈32 DLL들을 필요로 한다.
시스템 서비스(lsass.exe, services.exe, winlogon.exe 등)나 csrss.exe에 코드를 주입하고 싶다면 원격 프로세스에 대한 핸들을 열기(OpenProcess) 전에 여러분의 프로세스의 권한을 "SeDebugPrivilege"로 설정한다(AdjustTokenPrivileges).

이제 거의 끝났다. 한 가지 더 명심해두어야 할 것이 있다. 여러분의 주입된 코드는 특히 무엇인가 잘못되었을 경우 대상 프로세스를 쉽게 멍청한 상태로 몰아넣는다. 분명히 기억하라. 힘에는 책임이 따른다!

이 문서의 많은 예제들이 패스워드에 관한 것이므로 여러분은 Zhefu Zhang이 쓴 Super Password Spy++를 흥미롭게 생각할 지도 모른다. 거기에서 그는 인터넷 익스플로러 패스워드 필드에서 패스워드를 얻어오는 방법에 대해 설명한다. 더구나 그런 공격들로부터 여러분의 패스워드 컨트롤들을 보호하는 방법에 대해서도 보여준다.

추신 : 문서를 작성하고 출판하는 사람이 받는 유일한 보상이란 그가 받게 되는 feedback이다. 그러므로 이 문서가 유용하다고 생각하면 comment를 남기거나 이 문서를 vote 해주기 바란다(). 그리고 더 중요한 것으로서 무엇인가 잘못되었거나 버그가 있고 이것보다 더 나은 방법이 있다든지 또는 뭔가 명료하지 않은 것이 있다면 필자에게 알려주기 바란다.

감사의 말

먼저 이 "문서"가 처음으로 출판되었던 CodeGuru의 독자 여러분께 감사 드린다. 이 문서가 초기의 1200 단어 정도의 크기에서 현재의 6000 단어의 크기로 커지게 되었던 것은 주로 여러분의 질문들 때문이었다. 하지만 특히 평가할 만한 한 사람만 추린다면 그는 Rado Picha이다. 이 문서의 많은 부분들은 그의 제언과 설명으로부터 도움을 받았다. 마지막으로 영어라는 복병으로부터 필자를 도와주어 이 문서를 좀 더 읽기 쉽게 만들어준 Susan Moore에게 감사 드린다.

부록

A) 어째서 kernel32.dll과 user32.dll은 항상 같은 주소에 map 되는가?

필자의 추정 : 마이크로소프트 프로그래머가 이렇게 하면 유용한 속도 최적화 수단이 될 수 있다고 생각했기 때문에. 그 이유는 아래와 같다.

일반적으로 실행 파일은 ".reloc" 섹션을 포함한 여러 개의 섹션으로 구성되어 있다.

링커가 EXE 파일이나 DLL 파일을 생성할 때 이것은 파일이 메모리의 어디에 map 될 것인지를 가정한다. 이것이 소위 가정된/선호되는 로드/베이스 주소이다. 이미지에서 모든 절대 주소들은 이 링커에 의해 가정된 로드 주소를 기반으로 한다. 어떤 이유로든 이미지가 이 주소로 로드 되지 못할 경우 PE(Portable Executable) 로더는 이미지의 모든 절대 주소들을 fix 해야 한다. 이 때문에 ".reloc" 섹션이 있는 것이다. 이것은 이미지의 모든 위치들에 대한 리스트를 포함하는데 여기에서 링커의 가정된 로드 주소와 실제의 로드 주소간의 차이가 가공될 필요가 있다(어쨌든 컴파일러에 의해 생성되는 대부분의 명령어코드들은 일종의 상대 주소를 이용하므로 생각보다는 그렇게 많지 않은 relocation이 일어난다는 것에 주의하라). 반면 로더가 링커의 가정된 기본 주소로 이미지를 로드 할 수 있다면 ".reloc" 섹션은 완전히 무시된다.

그런데 어째서 kernel32.dll, user32.dll과 이들의 로드 주소들이 이런 스토리에 딱 맞아 떨어질까? 모든 윈32 응용프로그램이 kernel32.dll을 필요로 하고 대부분의 응용프로그램이 user32.dll을 필요로 하므로 이들을 항상 그들(kernel32 and user32)의 선호되는 기본 주소로 mapping 하면 모든 실행 파일들의 로드 시간을 향상할 수 있을 것이기 때문이다. 그러면 로더는 kernel32.dll과 user32.dll의 주소를 전혀(완전히) fix 할 필요가 없을 것이다.

아래의 예제를 제시하면서 이 토론을 마치기로 한다.

특정 App.exe의 이미지 base를 Kernel32(/base:"0x77e80000") 나 user32(/base:"0x77e10000")의 선호되는 base 주소로 설정한다. App.exe가 user32에서 import를 하지 않는다면 단순히 이것을 LoadLibrary 한다. 그런 후 App.exe를 컴파일 하고 이것을 실행해보자. 에러 박스가 튀어나오고("Illegal System DLL Relocation") App.exe의 로드가 실패한다.

왜 그럴까? 프로세스를 생성할 때 윈2000, 윈XP와 윈2003의 로더는 kernel32.dll과 user32.dll(이들의 이름은 로더에 hardcode 되어 있음)이 그들의 선호되는 base에 map 되는지를 체크 한다. 그렇지 못할 경우 하드 에러가 발생한다. 윈NT 4에서는 ole32.dll도 체크 된다. 윈NT 3.51 이하에서는 이런 체크들이 존재하지 않으므로 kernel32.dll과 user32.dll은 어느 위치에나 올 수 있다. 항상 자신의 base 주소에 있어야 하는 유일한 모듈은 ntdll.dll이다. 로더는 이것을 체크 하지 않지만 ntdll.dll이 자신의 base에 없으면 프로세스가 생성될 수 없다.

요약하자면 윈NT 4 이상에서

항상 자신의 base 주소로 map 되는 dll들 : kernel32.dll, user32.dll과 ntdll.dll.
모든 윈32 응용프로그램(+ csrss.exe)에 존재하는 dll들 : kernel32.dll과 ntdll.dll.
고유의 응용프로그램까지도 포함한 모든 프로세스에 존재하는 유일한 dll : ntdll.dll.

B) /GZ 컴파일러 스위치

디버그 빌드에서 /GZ 컴파일러 특성은 기본적으로 켜진다. 우리는 몇몇 에러들을 catch 하기 위해 이것을 이용할 수 있다(자세한 것은 문서를 참조). 그런데 우리의 실행 파일에서 이것은 무엇을 의미하는가?

/GZ 옵션이 켜졌을 때 컴파일러는 우리의 함수 내에서 ESP 스택 포인터가 변경되지 않았는지 검증하는 함수 호출(모든 함수의 거의 끝에 추가되는)을 포함하여 실행 파일에 존재하는 모든 함수에 대해 추가적인 코드를 추가할 것이다. 그런데 잠깐만. ThreadFunc에 함수 호출이 추가된다고? 그것은 재앙으로 가는 길이다. 이제 ThreadFunc의 원격 복사본은 원격 프로세스에(적어도 같은 주소에) 존재하지 않는 함수를 호출할 것이다.

C) 정적 함수 대 증분 링크(Incremental linking)

Incremental linking은 응용프로그램을 구축할 때 링크 시간을 짧게 하기 위해 이용된다. 정상적으로 링크 된 실행 파일과 incremetal로 링크 된 실행 파일 사이의 차이는 incremental로 링크 된 실행 파일의 경우 각 함수 호출이 링커에 의해 생성되는 추가적인 JMP 명령어코드로 간다는 점이다(static으로 선언된 함수들은 이 규칙에 대해 예외이다). 이들 JMP들은 함수를 참조하는 모든 CALL 명령어코드들을 갱신하지 않고도 링커가 메모리에서 함수들을 이동할 수 있게 해준다. 하지만 문제점을 야기하는 것도 바로 이 JMP이다. 이제 ThreadFunc와 AfterThreadFunc는 실제의 코드 대신에 JMP 명령어코드를 가리킬 것이다. 그래서 아래와 같은 식으로 ThreadFunc의 크기를 계산할 때

const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc);

이것은 사실상 각각 ThreadFunc와 AfterThreadFunc를 가리키는 JMP들 사이의 "거리"를 계산할 것이다(보통 이들은 바로 연이어서 나타날 것이다. 하지만 이것은 고려하지 말라). 이제 우리의 ThreadFunc는 주소 004014C0에 있고 여기에 대한 JMP 명령어코드는 00401020에 있다고 가정하자.

:00401020   jmp  004014C0
 ...
:004014C0   push EBP          ; ThreadFunc의 실제 주소
:004014C1   mov  EBP, ESP
 ...

그러면 아래의 코드는

WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);

원격 프로세스에 실제의 ThreadFunc가 아니라 "JMP 004014C0" 명령어코드(그리고 그 뒤에 오는 cbCodeSize 범위 내의 모든 명령어코드들)를 복사할 것이다. 원격 쓰레드가 실행할 첫 번째 코드는

"JMP 
        004014C0"

일 것이다. 그런데 이것은 원격 쓰레드만이 아니라 전체 프로세스에서도 가장 마지막의 명령어코드들일 것이다.

하지만 이 JMP 명령어코드 "규칙"에는 예외가 있다. 함수가 static으로 선언되면 incremental로 링크되었더라도 함수가 직접 호출될 것이다. 규칙 #4에서 ThreadFunc와 AfterThreadFunc를 static으로 선언하거나 증분 링크(incremental linking)을 사용하지 않는다고 했던 이유는 이 때문이다. (incremental linking의 몇 가지 다른 측면에 관한 것은 Matt Pietrek이 쓴 "Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools" 문서에서 발견할 수 있다)

D) 어째서 우리의 ThreadFunc는 4k의 지역 변수밖에 가지지 못할까?

지역 변수들은 항상 스택에 저장된다. 어떤 함수가 말하자면 256바이트의 지역 변수를 가진다면 함수에 진입할 때(더 정확하게는 함수 프롤로그에서) 스택 포인터가 256만큼 감소한다. 아래의 함수는

void Dummy(void) {
    BYTE var[256];
    var[0] = 0;
    var[1] = 1;
    var[255] = 255;
}

예컨대 아래와 유사하게 컴파일 된다.

:00401000   push ebp
:00401001   mov  ebp, esp
:00401003   sub  esp, 00000100           ; ESP를 필요한 지역 변수들을 위한
                                         ; 공간만큼 변경한다
:00401006   mov  byte ptr [esp], 00      ; var[0] = 0;
:0040100A   mov  byte ptr [esp+01], 01   ; var[1] = 1;
:0040100F   mov  byte ptr [esp+FF], FF   ; var[255] = 255;
:00401017   mov  esp, ebp                ; 스택 포인터를 복원한다
:00401019   pop  ebp
:0040101A   ret

위의 예제에서 스택 포인터(ESP)가 어떤 식으로 변경되었는지에 주목하라. 그런데 함수가 지역 변수로서 4kb 이상을 필요로 한다면 무엇이 달라지는 것일까? 그럴 경우 스택 포인터는 직접적으로 변경되지 않는다. 그보다는 다른 함수(stack probe)가 호출되며 이것이 스택을 적절하게 변경한다. 하지만 이 추가적인 함수 호출은 분명히 우리의 ThreadFunc를 "corrupt" 하게 만든다. 왜냐하면 원격 복사본은 거기에 있지 않은 무엇인가를 호출하려고 할 것이기 때문이다.

문서에서는 stack probe와 /Gs 컴파일러 옵션에 대해 어떤 식으로 언급하고 있는지를 살펴보자.

"/Gssize 옵션은 stack probe를 제어할 수 있는 진보된 특성이다. stack probe는 컴파일러가 모든 함수 호출에 삽입하는 일련의 코드이다. 활성화되었을 경우 stack probe는 관련된 함수의 지역 변수들을 저장하기 위해 필요한 공간의 양만큼을 메모리에서 무해하게 얻어온다.
어떤 함수가 지역 변수들을 위해 size 스택 공간 이상을 필요로 한다면 stack probe가 활성화된다. size의 기본 값은 한 페이지의 크기(80x86 프로세서에서는 4kb)이다. 이 값은 실행 시에 프로그램 스택에 commit 되었던 메모리의 양을 늘리기 위한 윈32와 윈NT 가상 메모리 매니저 사이의 주의 깊게 조절되는 상호 작용을 허용해준다."

몇몇 사람은 위의 문장 "stack probe는 ... 메모리에서 무해하게 얻어온다"는 문장을 의아하게 생각할 것이라고 생각된다. 저들 컴파일로 옵션들(그들의 설명에 따르면!)은 그 이면을 들여다 보고 무엇이 진행되고 있는지를 알 때까지는 때때로 진짜 골치 아프다. 예컨대 어떤 함수가 자신의 지역 변수들을 위해 12kb의 공간을 필요로 한다면 스택의 메모리는 아래와 같은 식으로 "할당"(더 정확하게는 commit)될 것이다.

sub    esp, 0x1000    ; 첫 번째 4kb를 "할당한다"
test  [esp], eax      ; 새 페이지를 commit 하기 위해
                      ; 메모리를 touch 한다(이미 commit 되지 않았다면)
sub    esp, 0x1000    ; 두 번째 4kb를 "할당한다"
test  [esp], eax      ; ...
sub    esp, 0x1000
test  [esp], eax

스택 포인터가 4kb 단위로 어떻게 변경되는지에 주목하고 더 중요한 것으로서 각 스텝 후에 어떤 식으로 스택의 바닥이 "touch" 되는지(test를 통하여)에 대해 주목하기 바란다. 이것은 다른 페이지를 "할당"(committing)하기 전에 스택의 바닥을 포함하는 페이지가 commit 되는 것을 보증해준다.

아래의 내용을 읽어보면

"각각의 새로운 쓰레드는 commit 되고 예약된 메모리로 구성된 자기 자신의 스택 공간을 받는다. 기본 값으로 각 쓰레드는 1Mb의 예약된 메모리와 한 페이지의 commit 된 메모리를 이용한다. 시스템은 필요할 때 예약된 스택 메모리에서 한 페이지 블록을 commit 할 것이다."(MSDN CreateThread > dwStackSize > "Thread Stack Size" 참조).

/Gs에 관한 문서에서 여러분은 여러분의 응용프로그램과 윈도우즈 NT 가상 메모리 매니저 사이에서 주의 깊게 조절되는 상호 작용을 허용해주는 stack probe를 가진다는 말을 했는지가 분명해질 것이다.

이제 우리의 ThreadFunc와 4kb 제한에 관한 논점으로 되돌아가자.
비록 우리는 /Gs 옵션으로 stack probe 루틴에 대한 호출을 예방할 수 있지만 그 문서는 우리가 그렇게 하는 것에 대해 경고를 하고 있다. 게다가 그 문서는 #pragma check_stack 지시자를 이용하면 stack probe 기능을 켜가나 끌 수 있다고 말하고 있다. 하지만 이 pragma는 stack probe에 전혀 영향을 미치지 않는 듯하다(그 문서가 잘못 되었든지 필자가 다른 어떤 사실들을 잘못 안 것이겠지만). 어쨌든 CreateRemoteThread와 WriteProcessMemory 테크닉이 작은 코드 조각들을 주입할 때만 이용된다는 것을 상기한다면 우리의 지역 변수는 기껏해야 몇 바이트 이상을 *소모*하지 않을 것이며 거의 4kb 경계에 근접할 일은 없을 것이다.

E) 어째서 필자는 3개보다 많은 case 문을 가진 우리의 switch 블록을 분할해야 했는가?

반복하지만 예제로 설명하는 것이 가장 쉽다. 아래의 함수를 살펴보자.

int Dummy( int arg1 ) 
{
    int ret =0;

    switch( arg1 ) {
    case 1: ret = 1; break;
    case 2: ret = 2; break;
    case 3: ret = 3; break;
    case 4: ret = 0xA0B0; break;
    }
    return ret;
}

이것은 아래와 유사하게 컴파일 될 것이다.

 Address   OpCode/Params    Decoded instruction
--------------------------------------------------
                                             ; arg1 -> ECX
:00401000  8B4C2404         mov ecx, dword ptr [esp+04]
:00401004  33C0             xor eax, eax     ; EAX = 0
:00401006  49               dec ecx          ; ECX --
:00401007  83F903           cmp ecx, 00000003
:0040100A  771E             ja 0040102A

; 테이블의 주소 중 하나로 JMP ***
; ECX는 오프셋을 가진다는 것에 주목하라
:0040100C  FF248D2C104000   jmp dword ptr [4*ecx+0040102C]

:00401013  B801000000       mov eax, 00000001   ; case 1: eax = 1;
:00401018  C3               ret
:00401019  B802000000       mov eax, 00000002   ; case 2: eax = 2;
:0040101E  C3               ret
:0040101F  B803000000       mov eax, 00000003   ; case 3: eax = 3;
:00401024  C3               ret
:00401025  B8B0A00000       mov eax, 0000A0B0   ; case 4: eax = 0xA0B0;
:0040102A  C3               ret
:0040102B  90               nop

; 주소 테이블  ***
:0040102C  13104000         DWORD 00401013   ; case 1로 점프
:00401030  19104000         DWORD 00401019   ; case 2로 점프
:00401034  1F104000         DWORD 0040101F   ; case 3로 점프
:00401038  25104000         DWORD 00401025   ; case 4로 점프

switch-case가 어떻게 구현되는지에 주목하기 바란다.
모든 단일 case 문을 독립적으로 검사하기보다는 주소 테이블이 생성된다. 그런 후 주소 테이블에 대한 오프셋을 간단하게 계산함으로써 올바른 case로 점프한다. 잘 생각해보면 이것은 사실상 기능 개선이라고 할 수 있다. 50개의 case 문을 가진 switch 문을 가지고 있다고 상상해보자. 위의 트릭이 없다면 마지막 case에 도달하기 위해 50개의 CMP와 JMP 명령어코드를 실행해야 한다. 반면 주소 테이블이 있으면 한 번의 테이블 look-up으로 어떠한 case에라도 점프 할 수 있다. 컴퓨터 알고리즘과 time complexity의 용어로 말하자면 우리는 O(2n) 알고리즘을 O(5) 알고리즘으로 대체한 것이다. 여기에서

O는 최악의 경우의 time complexity를 나타낸다.
오프셋을 계산하고 테이블 look-up을 하고 최종적으로 적절한 주소로 점프하기까지 5개의 명령어코드면 충분하다고 가정했다.

그런데 위의 상황은 case 상수들이 연속적으로(1, 2, 3, 4) 주의 깊게 선택되었기 때문에 가능한 것이라고 생각하는 사람도 있을 수 있을 것이다. 다행히도 동일한 해결책이 대부분의 현실 생활의 예제에도 적용될 수 있다는 것이 판명되었다. 단지 오프셋 계산만이 약간 더 복잡해질 뿐이다. 하지만 여기에는 두 가지의 예외가 있다.

3개보다 적은 case 문이 있거나
case 상수들이 서로 전혀 관계가 없다면(예. "case 1", "case 13", "case 50" 과 "case 1000")

결과적인 코드는 모든 단일 case 상수를 CMP와 JMP 명령어코드를 가지고 각각 조사하는 긴 과정을 거친다. 다른 말로 표현해서 결과적인 코드는 우리가 정상적인 if-else if 시퀀스를 이용했을 경우와 본질적으로 동일하다.

흥미로운 점 : 어떤 이유로 상수 표현 식만이 case 문을 동반할 수 있는지 의아하게 생각했던 적이 있다면 그 이유를 이제 알았을 것이다. 주소 테이블을 생성하기 위해 이 값은 명백히 컴파일 시에 알려져야 하기 때문이다.

다시 문제로 되돌아가자!
주소 0040100C의 JMP 명령어코드에 주목하기 바란다. 16진 opcode FF에 대해 인텔의 문서가 뭐라고 했는지를 살펴보자.

Opcode    Instruction    Description
FF /4     JMP r/m32      Jump near, absolute indirect,
                         address given in r/m32

아! 문제의 JMP는 일종의 absolute addressing을 이용한다. 다른 말로 표현해서 operand 중 하나(우리의 경우 0040102C)가 절대 주소를 나타낸다. 더 이상 말할 필요가 있을까? 이제 원격 ThreadFunc는 자신의 switch를 위한 주소 테이블은 0040102C에 있다고 맹목적으로 생각할 것이고 잘못 된 장소로 JMP 하여 효과적으로 원격 프로세스를 crash 할 것이다.

F) 도대체 어째서 원격 프로세스가 crash 하는가?

우리의 원격 프로세스가 crash 된다면 이것은 항상 아래 원인 중 하나에 의해 일어날 것이다.

ThreadFunc 내부에서 존재하지 않는 string을 참조했다.
ThreadFunc의 하나 이상의 명령어코드가 absolute addressing을 이용한다(예로서 Appendix E 참조).
ThreadFunc가 존재하지 않는 함수를 호출했다(이 호출은 컴파일로/링커에 의해 추가되었을 수 있다). 이럴 경우 ThreadFunc를 디스어셈블러로 보면 아래와 같은 것을 볼 수 있을 것이다.
```
:004014C0    push EBP         ; ThreadFunc의 entry point
:004014C1    mov EBP, ESP
 ...
:004014C5    call 0041550     ; 이것은 원격 프로세스를 crash 할 것이다
 ...
:00401502    ret
```
문제의 CALL이 컴파일러에 의해 추가된 것이라면(/GZ와 같은 "금지된" 스위치가 켜져 있었기 때문에) 이것은 ThreadFunc의 시작 부분이나 거의 끝 지점의 어딘가에 위치할 것이다.

어쨌든 CreateRemoteThread와 WriteProcessMemory 테크닉을 이용할 때에는 매우 주의해야 한다. 특히 컴파일러/링커 옵션을 관찰해야 한다. 이들은 우리의 ThreadFunc에 무엇인가를 쉽게 추가할 수 있다.

참고 문서 :

Load Your 32-bit DLL into Another Process's Address Space Using INJLIB by Jeffrey Richter. MSJ May, 1994
HOWTO: Subclass a Window in Windows 95; Microsoft Knowledge Base Article - 125680
Tutorial 24: Windows Hooks by Iczelion
CreateRemoteThread by Felix Kasza
API hooking revealed by Ivo Ivanov
Peering Inside the PE: A Tour of the Win32 Portable Executable File Format by Matt Pietrek, March 1994
Intel Architecture Software Developer's Manual, Volume 2: Instruction Set Reference

문서 history

July 25, 2003: Article published
August 19, 2003: Applied only some minor formatting changes

목차

소개