关于新版本cuckoo hook位置变动的思考

最近跟队友更新monitor版本，发现新版本将Zwxxx的hook位置移到了ntxxx的位置，其实做的是同一件事，为什么要如此？带着疑问我用OD进行了追踪。

WriteFile asm source code from OD(kernel32.dll)

7C810E17 > $ 6A 18 push 0x18 ; WriteFile

7C810E19 . 68 B00E817C push kernel32.7C810EB0

7C810E1E . E8 B316FFFF call kernel32.7C8024D6

7C810E23 . 8B5D 14 mov ebx,dword ptr ss:[ebp+0x14]

7C810E26 . 33C9 xor ecx,ecx

7C810E28 . 3BD9 cmp ebx,ecx

7C810E2A . 74 02 je short kernel32.7C810E2E

7C810E2C . 890B mov dword ptr ds:[ebx],ecx

7C810E2E > 64:A1 1800000>mov eax,dword ptr fs:[0x18]

7C810E34 . 8B40 30 mov eax,dword ptr ds:[eax+0x30]

7C810E37 . 8B7D 08 mov edi,dword ptr ss:[ebp+0x8]

7C810E3A . 83FF F4 cmp edi,-0xC ; Switch (cases FFFFFFF4..FFFFFFF6)

7C810E3D . 0F84 C3D00100 je kernel32.7C82DF06

7C810E43 . 83FF F5 cmp edi,-0xB

7C810E46 . 0F84 AFD00100 je kernel32.7C82DEFB

7C810E4C . 83FF F6 cmp edi,-0xA

7C810E4F . 0F84 ADBC0200 je kernel32.7C83CB02

7C810E55 > 8BC7 mov eax,edi ; Default case of switch 7C810E3A

7C810E57 . 25 03000010 and eax,0x10000003

7C810E5C . 83F8 03 cmp eax,0x3

7C810E5F . 0F84 FCBD0000 je kernel32.7C81CC61

7C810E65 . 8B75 18 mov esi,dword ptr ss:[ebp+0x18]

7C810E68 . 51 push ecx

7C810E69 . 3BF1 cmp esi,ecx

7C810E6B . 0F85 ABD90100 jnz kernel32.7C82E81C

7C810E71 . 51 push ecx

7C810E72 . FF75 10 push dword ptr ss:[ebp+0x10]

7C810E75 . FF75 0C push dword ptr ss:[ebp+0xC]

7C810E78 . 8D45 E0 lea eax,dword ptr ss:[ebp-0x20]

7C810E7B . 50 push eax

7C810E7C . 51 push ecx

7C810E7D . 51 push ecx

7C810E7E . 51 push ecx

7C810E7F . 57 push edi

7C810E80 . FF15 BC11807C call dword ptr ds:[<&ntdll.NtWriteFile>] ; ntdll.ZwWriteFile //here is static address, it's a fn table in kernel32.dll

7C810E86 . 3D 03010000 cmp eax,0x103

7C810E8B . 0F84 A7BC0200 je kernel32.7C83CB38

7C810E91 > 85C0 test eax,eax

7C810E93 . 0F8C 49D00100 jl kernel32.7C82DEE2

7C810E99 . 8B45 E4 mov eax,dword ptr ss:[ebp-0x1C]

7C810E9C . 8903 mov dword ptr ds:[ebx],eax

7C810E9E > 33C0 xor eax,eax

7C810EA0 . 40 inc eax

7C810EA1 > E8 6B16FFFF call kernel32.7C802511

7C810EA6 . C2 1400 retn 0x14

ZwWriteFile source code(ntdll.dll):

7C92DF60 > B8 12010000 mov eax,0x112 ; ZwWriteFile

7C92DF65 BA 0003FE7F mov edx,0x7FFE0300

7C92DF6A FF12 call dword ptr ds:[edx] ; ntdll.KiFastSystemCall

7C92DF6C C2 2400 retn 0x24

fn table(kernel32.dll):

7C80119C > . B0D9927C dd ntdll.ZwReadFile

7C8011A0 > . 50CF927C dd ntdll.ZwAllocateVirtualMemory

7C8011A4 > . D0DE927C dd ntdll.ZwUnlockFile

7C8011A8 > . 80D4927C dd ntdll.ZwLockFile

7C8011AC > . 8F4F937C dd ntdll.RtlAppendUnicodeStringToString

7C8011B0 > . 1A4F937C dd ntdll.RtlAppendUnicodeToString

7C8011B4 > . B94E937C dd ntdll.RtlCopyUnicodeString

7C8011B8 > . 70D3927C dd ntdll.ZwFreeVirtualMemory

7C8011BC > . 60DF927C dd ntdll.ZwWriteFile ; NtWriteFile

7C8011C0 > . 1234937C dd ntdll.RtlCreateUnicodeString

7C8011C4 > . F94F937C dd ntdll.RtlFormatCurrentUserKeyPath

7C8011C8 > . B949937C dd ntdll.RtlGetLongestNtPathLength

7C8011CC > . 80D2927C dd ntdll.ZwDuplicateObject

7C8011D0 > . 40D8927C dd ntdll.ZwQueryKey

7C8011D4 > . 50D2927C dd ntdll.ZwDeleteValueKey

7C8011D8 > . B635937C dd ntdll.RtlEqualString

7C8011DC > . FFEA937C dd ntdll.CsrFreeCaptureBuffer

7C8011E0 > . EE06947C dd ntdll.CsrCaptureMessageString

7C8011E4 > . 58EB937C dd ntdll.CsrAllocateCaptureBuffer

7C8011E8 > . 1D28927C dd ntdll.strncpy

7C8011EC > . 903B957C dd ntdll.RtlCharToInteger

7C8011F0 > . C003937C dd ntdll.RtlUpcaseUnicodeChar

先后顺序是，api->NtApi->ZwApi。

可以看到ZwWritefile是没有好的inlinehook的位置的，直接就进了ntdll.KiFastSystemCall 通过中断跳入ring0，真要hook则，必须在跳回的时候做修复，可能会因此导致hook后程序不稳定。

所以改fntable即方便又稳定，old fn ptr跳回即可调用原来的。坏处是，如果恶意代码直接调用zwxxx，可能会漏掉。hook时必须根据情况单独处理。

当然通过挂起，注入，继续执行的方式也不能保证都能监控，以后还要在ring0做进一步的保护措施。