본문 바로가기
디버그

SDT 훅과 클럽박스 InLine Hook의 취약점

by WeZZ 2009. 2. 3.

나의 SDT Hook


f3cd50f0 Wezz!HookedNtReadVirtualMemory
f3cd5230 Wezz!HookedNtWriteVirtualMemory



위 두 함수를 SSDT Hooking을 해 놓았다.
위 훅한 두 주소를 보자.


Wezz!HookedNtReadVirtualMemory:
f3cd50f0 8bff            mov     edi,edi
f3cd50f2 55              push    ebp
f3cd50f3 8bec            mov     ebp,esp
f3cd50f5 83ec10          sub     esp,10h
f3cd50f8 c745f4220000c0  mov     dword ptr [ebp-0Ch],0C0000022h
f3cd50ff c745f000000000  mov     dword ptr [ebp-10h],0


Wezz!HookedNtWriteVirtualMemory:
f3cd5230 8bff            mov     edi,edi
f3cd5232 55              push    ebp
f3cd5233 8bec            mov     ebp,esp
f3cd5235 83ec10          sub     esp,10h
f3cd5238 c745f4220000c0  mov     dword ptr [ebp-0Ch],0C0000022h
f3cd523f c745f000000000  mov     dword ptr [ebp-10h],0



우리가 훅 한 함수이다. 



이제 클럽박스를 실행해 보자.

f3bba000 f3bbdb00   NOWMEMDF NOWMEMDF.sys Thu Nov 13 12:45:56 2008 (491BA2F4)

이제 클럽박스의 보안 모듈인 NOWMEMDF.sys가 로드되었다.
그 후 우리가 훅한 NtReadVirtualMemory , NtWriteVirtualMemory의 함수 포인터를 다시 보자.



Wezz!HookedNtReadVirtualMemory:
f3cd50f0 e93f683d92      jmp     860ab934
f3cd50f5 83ec10          sub     esp,10h
f3cd50f8 c745f4220000c0  mov     dword ptr [ebp-0Ch],0C0000022h
f3cd50ff c745f000000000  mov     dword ptr [ebp-10h],0
f3cd5106 c745f800000000  mov     dword ptr [ebp-8],0
f3cd510d c745fc00000000  mov     dword ptr [ebp-4],0



Wezz!HookedNtWriteVirtualMemory:
f3cd5230 e91faa3d92      jmp     860afc54
f3cd5235 83ec10          sub     esp,10h
f3cd5238 c745f4220000c0  mov     dword ptr [ebp-0Ch],0C0000022h
f3cd523f c745f000000000  mov     dword ptr [ebp-10h],0
f3cd5246 c745f800000000  mov     dword ptr [ebp-8],0
f3cd524d c745fc00000000  mov     dword ptr [ebp-4],0



.. 우리가 훅한 두 함수의 포인터의 다섯바이트를 Inline hook 해버렸다...ㅠ
그러면 클럽박스녀석은 우리 다섯바이트를 가지고 감시나 Restore 할때 반드시 문제가 생길 것이다.
나의 Wezz 모듈이 먼저 내려가 버린다면 말이다..
흠 그럼 해보자.


kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: f3cd50f0, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f3bbb2e9, address which referenced memory
Debugging Details:
------------------

READ_ADDRESS:  f3cd50f0
CURRENT_IRQL:  2
FAULTING_IP:
NOWMEMDF+12e9
f3bbb2e9 66f3a7          repe cmps word ptr [esi],word ptr es:[edi]
DEFAULT_BUCKET_ID:  DRIVER_FAULT
BUGCHECK_STR:  0xD1
PROCESS_NAME:  Idle
TRAP_FRAME:  805526d4 -- (.trap 0xffffffff805526d4)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000003 edx=d5a5cfe0 esi=f3cd50f0 edi=860ab928
eip=f3bbb2e9 esp=80552748 ebp=80552750 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
NOWMEMDF+0x12e9:
f3bbb2e9 66f3a7          repe cmps word ptr [esi],word ptr es:[edi]
Resetting default scope
LAST_CONTROL_TRANSFER:  from 805348e7 to 804e5b25
STACK_TEXT: 
80552288 805348e7 00000003 805525e4 00000000 nt!RtlpBreakWithStatusInstruction
805522d4 805353be 00000003 f3cd50f0 f3bbb2e9 nt!KiBugCheckDebugBreak+0x19
805526b4 804e4158 0000000a f3cd50f0 00000002 nt!KeBugCheck2+0x574
805526b4 f3bbb2e9 0000000a f3cd50f0 00000002 nt!KiTrap0E+0x233
WARNING: Stack unwind information not available. Following frames may be wrong.
80552750 f3bba8fd 860ab920 f3bba842 8055278c NOWMEMDF+0x12e9
80552880 804de928 8055b580 8055b320 ffdff000 NOWMEMDF+0x8fd
805528ac 804de179 8055b980 00000000 00007e89 nt!KiTimerExpiration+0xaf
805528d0 804de0ed 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
805528d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND:  kb
FOLLOWUP_IP:
NOWMEMDF+12e9
f3bbb2e9 66f3a7          repe cmps word ptr [esi],word ptr es:[edi]
SYMBOL_STACK_INDEX:  4
SYMBOL_NAME:  NOWMEMDF+12e9
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: NOWMEMDF
IMAGE_NAME:  NOWMEMDF.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  491ba2f4
FAILURE_BUCKET_ID:  0xD1_NOWMEMDF+12e9
BUCKET_ID:  0xD1_NOWMEMDF+12e9
Followup: MachineOwner







역시나 작열 해주셨다...ㅎㅎㅎ
이제 트랩해주고. 보면



kd> .trap 0xffffffff805526d4
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000003 edx=d5a5cfe0 esi=f3cd50f0 edi=860ab928
eip=f3bbb2e9 esp=80552748 ebp=80552750 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
NOWMEMDF+0x12e9:
f3bbb2e9 66f3a7          repe cmps word ptr [esi],word ptr es:[edi]


edi와 esi의 주소를 비교 하려고 한다.

esi의 주소를 보자.   esi=f3cd50f0
어디서 많이 본 주소 같지 않은가..

그렇다 위에 우리가 SSDT 후킹한 메모리 포인터이다.
그럼 edi의 내용을 보자.

860ab928 e9 3f 68 3d 92 83 00 00 6a a5 bb f3 eb 20 6e 6f 77 63 6f 6d 5f 73 6f  .?h=....j.... nowcom_so
860ab93f 6c 75 74 69 6f 6e 5f 64 65 76 65 6c 6f 70 6d 65 6e 74 5f 74 65 61 6d  lution_development_team
860ab956 e9 0f ec b0 6d 8b ff 55 8b ec

e9 3f 68 3d 92 83
NOWMEMDF.sys가 lnline 후킹한 함수 주소이다.

repe cmps word ptr [esi],word ptr es:[edi]

그럼 이제 결론으로..
이제 왜 블루를 봐야만 하는지 알수 있을 것이다.
이미 언로드된 Wezz의 ReadVirtualMemory의 f3cd50f0를 비교하는 과정에서 죽은 것이다.
(e9 3f 68 3d 92 를 저장해 놓고 ,  실제 f3cd50f0의 5바이트를 비교하는 부분..일 듯)


아마 NOWMEMDF.sys은 누가 자신의 메모리를 건드는지 체크하는 루틴이 있는 것이다.



휴....호환 테스트는 너무 어렵구나..











관련글

티스토리툴바