좋은향기's 프로그램 블로그

n  API Hooking을 이야기 하다가 갑자기 "PE File Format" ? 다음에 포스트 할 Import Adress Table Hooking을 이해하기 위해서는 꼭 필요한 내용이기 때문이다.

n  Windows OS에서는 실행코드와 데이터를 저장하기 위해 PE라는 포맷을 쓰고 있다. PE 파일은 예전 유닉스 시스템에서의 coff(common object file format)파일 포맷에 뿌리를 둔 포맷으로, Widows NT 개발 당시 여러 CPU플랫폼에서 동일한 파일 포맷으로 실행이 가능하도록 하기 위한 용도로 만들어졌다 하여 PE(Portable Executable) 파일이라는 이름이 붙었다고 한다.

n  하지만 여기서는 PE파일에 대한 자세한 내용을 기술하지 않는다. 정리하기 귀찮기도 하고 잘 정리된 사이트들이 많은 마당에, 더 상세하고 이해하기 쉽게 쓸 자신도 없다. 아래의 URL을 참고하면 PE File Format에 대해 상세한 정보를 얻을 수 있다. (개인적인 의견으로는 PE 파일에 대해 공부하며 검색했던 사이트들 중에 가장 상세하고 이해하기 쉽게 정리되어 있는 포스트이다..)

 참고 URL: http://www.reversecore.com/18

１ Dll Injection
API Hooking기법에 따라 차이는 있겠으나, API Hooking을 위해서는 대상프로세스의 주소 공간안에서의 메모리 조작이 필요하다.
이를 위해 사용되는 방법이 바로 Dll Injection이다. 즉 타겟 프로세스로 하여금 우리가 작성한 Dll을 로드하도록 하고, 해당 프로세스에 로드된 Dll에서 API를 Hooking하는 방식이다.
많이 사용되는 Dll Injection방법으로는 아래의 세가지 방법이 있다.
( Dll Injection은 API Hooking뿐만 아니라, 소스코드가 없는 프로그램에 대한 패치나 구조분석 등에도 사용될 수 있다. )

(1) AppInit_DLLs 레지스트리 이용

1) 개요

① User32.dll은(User32.dll에서 Export한 API를 사용하는 모든 프로그램은) DLL_PROCESS_ATTACH 처리 과정에서 LoadLibrary()함수를 이용하여, 아래 키 값의 “AppInit DLLs” 엔트리에 등록된 모든 Dll을 로드한다. 이러한 동작을 이용하여 우리의 Dll을 다른 프로세스에 Injection 시킨다.

n HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
( AppInit DLLs에는 스페이스(‘ ‘)를 구분자로 하여 여러 개의 Dll을 등록할 수 있다. )

2) 주의 사항

① 하지만 이 방법의 경우, 등록된 dll이 프로세스 생성과정의 전반부에서 로딩되므로, dll 로드과정에서는 kernel32.dll에서 export한 함수만을 안전하게 사용할 수 있다.(하단 URL참조)

② 모든 프로세스에 Injection하기 위해서는 시스템 리부팅이 필요하다. 간혹 이 기능이 동작하기 위해서는 무조건 리부팅이 필요하다고 기술한 문서들이 있는데, 리부팅하지 않더라도 해당 레지스트리에 Dll을 등록한 이후에 생성되는 프로세스는 영향을 받는다.

③ Dll의 Inject 시점을 임의로 조절할 수 없으며, Injection대상 프로세스를 지정할 수도 없다.

④ Dll을 Unload시킬 수 있는 방법이 없다.

⑤ 가급적 이 방법 사용하지 않는 것이 좋을 것 같다.

3) 참고 URL
http://support.microsoft.com/kb/197571

(2) SetWindowsHook()함수 사용

1) 개요
SetWindowsHook() API를 이용하여 특정 HookType에 대해 Hooking을 시도하게 되면, Dll내의 Hook Procedure뿐만 아니라, Dll코드 전체가 대상 프로세스의 메모리공간에 로드 된다. 이러한 특성을 이용하여 다른 프로세스에 Injection한다.

2) 함수 원형

3) 구현

① Hook Handle공유

n SetWindowsHook()호출을 통해 리턴되는 HHOOK 타입의 핸들은, Hooking 대상 메시지(?)를 Hook체인으로 전달하기 위해, 모든 Dll 인스턴스들이 공유해야 한다. 이를 위해 shared속성을 갖는 섹션에 선언한다.

(3) CreateRemoteThread()

1) 개요
CreateRemoteThread()를 이용하여 이미 존재하는 프로세스내에 원격스레드를 생성하고, 이 원격스레드의 시작 함수로 Kernel32.dll의 LoadLibrary()의 주소를, 파라미터로 우리가 로드하려하는 hookDll의 파일명(혹은 FullPath)를 전달한다.
이 방법은 CreateRemoteThread()의 4번째 인자인lpStartAddress와 LoadLibrary()의 함수원형이 같다는 점에서 유효하다.( 엄밀히 말하자면 같지는 않지만, 4byte의 인자와 4byte의 리턴값을 취한다는 점에서 동일하게 취급할 수 있다.)

2) 함수원형

3) 구현

① 전술한 내용을 이용하여 CreateRemoteThread()를 호출하려면 4번재 파라미터로 , 타겟프로세스 내에서의 LoadLibrary() 함수의 주소를 구하여 넘겨주어야 한다. 하지만 아시다시피 각 프로세스는 별도의 메모리 공간을 가지고 있다.

n Kernel32.dll, ntdll.dll, user32.dll등의 시스템 dll들은 중복되지 않는 고유의 Address를 갖으므로, Dll Injection을 시도하는 프로세스에서 구한 Address는 타겟 프로세스에서도 유효하다.( Windows System Dll들은 로딩시 Relocation을 피하기 위해 고유의 BaseAddress를 가지고 있다 )

② CreateRemoteThread()의 다섯번째 인자인 lpParameter에는 우리가 로드할 Dll의 이름을 넘겨주어야 한다. 하지만 파라미터로 전달해야하는 hookDll의 파일명을 Dll Injection을 시도하는 프로세스의 주소로 넘겨주어서는 의미가 없다. 각각의 프로세스는 고유의 메모공간을 가지므로, Dll Injection을 시도하는 프로세스의 주소는 타겟 프로세스에서 유효하지 않다.

n 이를 위해 타겟 프로세스에 메모리 공간을 할당하고, 그 메모리에 우리의 hookDll의 이름을 적어주어야 하는데 다음의 함수들을 사용해서 구현할 수 있다.

4) 기타

① CreateRemoteThread()를 이용해 Injection시킨 Dll은 아래와 같은 절차로 Unload시킬 수 도 있다.

n Injection 후 GetExitCodeThread()를 통해 LoadLibray()가 리턴한 값(모듈핸들)을 보관

n LoadLibrary()를 리모트 프로세스에서 실행시킨 것과 마찬가지 방법으로 FreeLibrary()를 실행(FreeLibrary역시 4바이트의 인자를 가지며, 4바이트의 값을 리턴한다)

② Vista이상의 경우 다른 세션에 존재하는 프로세스를 대상으로 CreateRemoteThread()를 호출할 경우, 실패한다( lasterror: NOT_ENOUGH_MEMORY) 세션별로 Injection 프로세스를 띄워주면 되겠지만 용이치 않을 경우, ntdll!NTCreateThreadEx()를 사용하면 된다고 한다.(Vista이상의 OS만 유효함)

n (http://blog.naver.com/rkawk01?Redirect=Log&logNo=70046078078)

n http://code.google.com/p/easyhook-continuing-detours/source/browse/trunk/EasyHook_Specific/RemoteHook/RemoteHooking.cpp?spec=svn9&r=9

ASM Code

* 디버깅할때 자주 보게되는 한눈에 들어오지 않는 asm 코드들을 정리한다.
 

１ DisAsm

２ Asm 코드 작성

프로세스 풀패스구하기

http://www.osronline.com/article.cfm?id=472

What's in a (Process) Name? Obtaining A Useful Name for the Executable Image in a Process
The NT Insider, Vol 13, Issue 4, July - August 2006 | Published: 19-Sep-06| Modified: 19-Sep-06

Over the years developers have needed or wanted to know the name of the image executing in a given process. Traditionally, this was often done using PsGetProcessImageFile Name, which returns the contents of a field in the EPROCESS structure used by the Windows OS to maintain per-process state information.

As we can see from the information in the local debugger session (See Figure 1) the process image file is little more than a field within the EPROCESS structure. Notice that the EPROCESS address is in EBP+8, making it the first - and only - parameter to this function.

Unfortunately, there are some issues with this approach:

·        Though well-known, this function is undocumented.

·        More seriously, the information contained in this field is severely limited. It contains only the first 16 (ASCII) characters of the image file name.

It is actually the second issue that often creates problems for programmers because the name of the image file means essentially nothing. For example, we've seen kernel-mode drivers in the past that validate the name of their service by checking this field. The most egregious case we've seen is when the service was called svchost.exe, which is a common name that is often spoofed.

The Proposal
We suggest a different model for acquiring this information, as shown in Figure 2.

The function itself is fairly straight-forward. It does rely on use of a single undocumented function (ZwQueryInformationProcess), but note that its counterpart (NtQueryInformationProcess) is documented. We need to use the Zw variant in order to use a kernel memory buffer.

The key element is that Windows has always stored the full path name to the executable image in order to provide this information in the auditing subsystem. This API exploits that existing stored path name.

Other Process Names
This function has been implemented to extract the process name for the current process. However, you can use one of the two methods listed below to obtain the process name for a different process:

1. If you have a handle for the process, you can use that value instead of the NtCurrentProcess() macro. (Note that in our experience, we usually have a process object and not a process handle - the two are not interchangeable).

2. If you have an EPROCESS address, you can use KeStackAttachProcess/KeUnstackDetachProcess to attach to the process. This technique is rather heavy-weight, so it may be a good idea to cache the information if you need to perform this operation regularly.

When using the second technique, it is important to note that the name that is returned is a cached name. This cache is not updated if the name of the original file changes after the name is first cached. In other words, if the executable image is renamed, which is typically allowed for a running executable, the name returned will be the name of the original file.

This issue is not unique. We have also observed that some file systems return the original name even after a rename (e.g., the CIFS client implementation does this on Windows XP). Thus, it may require additional processing such as through a file system filter driver to protect against similar events. For example, you may encounter a security product that relies on knowing the specific name of the image.

Alternatives?
There are other options that a driver could also pursue such as registering for process creation/teardown events (PsSetCreateProcessNotifyRoutine) or image loading (PsSetLoadImageNotifyRoutine).

PsSetCreateProcessNotifyRoutine has limitations on the number of drivers that can register using this API. Since there is a fixed size table in the Windows OS, it is possible for this call to fail. When this occurs, a driver needs to ensure it can handle such a failure. PsSetLoadImageNotifyRoutine has the same limitation (fixed size table), but is called for all image loads, not just the original process image. Therefore, it includes drivers, DLLs, executables, etc.

Summary
The bottom line is that all of these approaches provide a useful name because they include the full path name. This is vastly superior to using the short ASCII eye-catching name that is stored in the EPROCESS structure. A word of caution - if you decide to use the debug level name, use it for nothing more than debugging since it is not reliable and cannot be relied on for any sort of security check.

We chose to use the proposed technique because it works in all circumstances and does not rely upon a registration that might potentially fail. In your own driver you might implement both this mechanism and a cache-based mechanism tied to the process creation logic.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"Windows 2000 Support"
Unfortunately, this technique works only for XP and more recent. Windows 2000 doesn't maintain this information and there's no simple way to duplicate this (basically, you have to watch with a file system filter driver for when a file object is created with EXECUTE access and the name used at that point.)

IoCompleteRequest in ReactOS