KiFastSystemCall Hook

A little trick I invented to hook syscall made by gamemon.des sometime ago. It only works on Windows XP and above, due to the design of syscall mechanism itself. So how it works? Lets get into some research about syscall mechanism.

As you know NT-based Windows (Windows NT/2k/XP/2k3/Vista) have ring0 and ring3 layer, each of them holds the kernelmode and usermode stuff respectively. Usermode is isolated from kernelmode, means you cannot access kernelmode in anyway from usermode. So in order to communicate with kernelmode, you make a syscall. Processor will transfer control to kernelmode, kernelmode processes your syscall and transfer the control back to usermode again.

Each version of Windows have different syscall mechanism. For Windows 2000 and older, the syscall mechanism is as shown below.

MOV EAX, SyscallNumber ; requested syscall number
LEA EDX, [ESP+4] ; EDX = params...
INT 2Eh ; throw the execution to the KM handler
RET 4*NUMBER_OF_PARAMS ; return

Each syscall number is moved into EAX and invoked through INT 2Eh. In Windows XP and later, the syscall mechanism had changed.

MOV EAX, 101h ; syscall number: NtTerminateProcess
MOV EDX, 7FFE0300h ; EDX = 7FFE0300h
CALL EDX ; call 7FFE0300h
RETN 8

Notice the difference. Instead of INT 2Eh, now it is replaced by CALL EDX which leads us to ntdll.KiFastSystemCall, a tiny stub containing the SYSENTER instruction.

MOV EDX, ESP
SYSENTER
RETN

This is where KiFastSystemCall hook came in. We can install hook on the stub to catch all syscalls made by the process, including undocumented NtUser*, NtGdi* syscalls.

——————————————————————————————-

KiFastSystemCall Hook
http://w14.easy-share.com/3759571.html

user32.__ClientLoadLibrary(x)

Anti SetWindowsHookEx DLL injection made possible Read on.

After spending some time reversing the user32 internals, I discovered this undocumented function. This function is responsible to load the SetWindowsHookEx() registered DLL into your process. This blog will only focus on usermode, where the actual DLL loading takes place.

user32.__ClientLoadLibrary(lpHook)

This function takes only 1 argument, a pointer to an undocumented structure allocated in process stack. It holds the path of the DLL, pointer to notification function and some yet to be known data.

_USERHOOK struct
    unknown_00	DWORD ?	           ; 0x00
    unknown_04	DWORD ?	           ; 0x04
    nCount	DWORD ?	           ; 0x08 numbers of pointer to fix up
    unknown_0C	DWORD ?	           ; 0x0C
    offCbkPtrs	DWORD ?	           ; 0x10 offset to callback pointers
    bFixed	DWORD ?	           ; 0x14 indicates if the pointer is fixed
    lpDLLPath	UNICODE_STRING {}  ; 0x18 DLL path
    lpfnNotify	DWORD ?	           ; 0x20 offset to notification procedure
                                     (called when DLL is injected)
_USERHOOK ends

MSPro is detected by GameGuard rev 1004 through … hotkey

Sometime ago somebody told me MSPro is detected and I put it to test yesterday. Yeah, MSPro gets detected by GameGuard rev 1004 (MapleSEA). Guess what?  MSPro runs fine in-game until I press F10 to activate auto-attack. Poof, I got disconnected. I went back into game with auto-attack still on, my cute little sin kept waving his arm hitting the air. I pressed F10 to turn off auto-attack. This time I get BSOD, aka instant reboot.

So what it means?

• GameGuard is detecting MSPro’s hotkey instead of MSPro itself.
• MSPro’s key input simulating method still works.

I will release another version to cope with this issue, … hopefully soon. Final exam is at the end of the horizon.