이번 덤프는 BugCheck 0xC5: DRIVER_CORRUPTED_EXPOOL인데 주로 풀 메모리 관련해서 유효하지 않은 주소 영역에 접근했을 때 발생한다.
0xA, 0x50 등과 함께 이런 오류 코드가 발생하면 누군가가 메모리를 손상시켰구나라고 생각하면 대부분 맞다.
기본 분석부터 시작해보자.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_CORRUPTED_EXPOOL (c5)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is
caused by drivers that have corrupted the system pool. Run the driver
verifier against any new (or suspect) drivers, and if that doesn't turn up
the culprit, then use gflags to enable special pool.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 8355a4c1, address which referenced memory
Debugging Details:
------------------
DUMP_CLASS: 1
DUMP_QUALIFIER: 402
BUILD_VERSION_STRING: 7601.18044.x86fre.win7sp1_gdr.130104-1431
SYSTEM_MANUFACTURER: LG Electronics
SYSTEM_PRODUCT_NAME: U460-MFBJL
SYSTEM_SKU: System SKUNumber
SYSTEM_VERSION: 1.0
BIOS_VENDOR: Phoenix Technologies Ltd.
BIOS_VERSION: UNCNSF09
BIOS_DATE: 04/22/2013
BASEBOARD_MANUFACTURER: LG Electronics
BASEBOARD_PRODUCT: U560
BASEBOARD_VERSION: 1.0
DUMP_TYPE: 0
BUGCHECK_P1: 4
BUGCHECK_P2: 2
BUGCHECK_P3: 1
BUGCHECK_P4: ffffffff8355a4c1
BUGCHECK_STR: 0xC5_2
CURRENT_IRQL: 2
FAULTING_IP:
nt!ExAllocatePoolWithTag+4b7
8355a4c1 897004 mov dword ptr [eax+4],esi
CPU_COUNT: 4
CPU_MHZ: 703
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3a
CPU_STEPPING: 9
CPU_MICROCODE: 6,3a,9,0 (F,M,S,R) SIG: 17'00000000 (cache) 17'00000000 (init)
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: explorer.exe
ANALYSIS_SESSION_HOST: PAUL-PC
ANALYSIS_SESSION_TIME: 11-14-2017 10:36:26.0368
ANALYSIS_VERSION: 10.0.10575.567 amd64fre
TRAP_FRAME: b683f62c -- (.trap 0xffffffffb683f62c)
ErrCode = 00000002
eax=00000000 ebx=835706c0 ecx=8b6ac9f0 edx=86b117b0 esi=83570840 edi=835706c4
eip=8355a4c1 esp=b683f6a0 ebp=b683f6e8 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ExAllocatePoolWithTag+0x4b7:
8355a4c1 897004 mov dword ptr [eax+4],esi ds:0023:00000004=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 8355a4c1 to 8347ac7b
STACK_TEXT:
b683f62c 8355a4c1 badb0d00 86b117b0 b683f690 nt!KiTrap0E+0x2cf
b683f6e8 83ba6aa1 00000000 00000040 7843464d nt!ExAllocatePoolWithTag+0x4b7
b683f700 83ba8091 8ae62bf8 8bbdc820 869f1530 fltmgr!ExAllocateFromPagedLookasideList+0x27
b683f718 95224e17 86a2aaf8 00000010 00000010 fltmgr!FltAllocateContext+0xa9
b683f73c 952251b6 8bbdc820 b683f79c 86e48320 MyDrv+0x8e17
b683f758 952252cc 8bbdc820 b683f79c 86e48320 MyDrv+0x91b6
b683f77c 83ba7aeb 8bbdc820 b683f79c b683f7c8 MyDrv+0x92cc
b683f7e8 83baa9f0 b683f82c d39a3dd8 00000000 fltmgr!FltpPerformPreCallbacks+0x34d
b683f800 83bbe1fe b683f82c 83bc1f3c 00000000 fltmgr!FltpPassThroughInternal+0x40
b683f814 83bbe8b7 b683f82c d39a3dd8 86b76f80 fltmgr!FltpCreateInternal+0x24
b683f858 83470c0e 86e1c590 86e0f7e8 8b67de58 fltmgr!FltpCreate+0x2c9
b683f870 b65ddffa 86b76f80 8b67de58 86b76f80 nt!IofCallDriver+0x63
b683f900 83470c0e 8b67de58 d39a3dd8 86b76fdc SomeDrv+0x5ffa
b683f918 836803ee a90c97a7 b683fac0 00000000 nt!IofCallDriver+0x63
b683f9f0 8365fc1e 86d4ae20 85ebb9c8 89a08d20 nt!IopParseDevice+0xee6
b683fa6c 83670030 00000000 b683fac0 00000040 nt!ObpLookupObjectName+0x4fa
b683fac8 83666b0e 081df704 85ebb9c8 00000001 nt!ObOpenObjectByName+0x165
b683fb44 8366cc94 179b0980 00020000 081df704 nt!IopCreateFile+0x673
b683fb8c b65b9725 179b0980 00020000 081df704 nt!NtOpenFile+0x2a
b683fc14 8347789a 179b0980 00020000 081df704 BadDrv+0x1725
b683fc14 775c7094 179b0980 00020000 081df704 nt!KiFastCallEntry+0x12a
081df6d8 775c5ce4 740723ea 179b0980 00020000 ntdll!KiFastSystemCallRet
081df6dc 740723ea 179b0980 00020000 081df704 ntdll!ZwOpenFile+0xc
081df724 74072a9e 081df744 00000000 00020000 ntmarta!I_MartaFileNtOpenFile+0x4d
081df754 74072b79 179b0038 00020000 081df7a8 ntmarta!MartaGetFileParentContext+0x5c
081df7b4 740726fe 179b0038 081df7e0 00000005 ntmarta!MartaGetRightsFromContext+0xd1
081df808 6fca3819 17a823a0 00000001 00000005 ntmarta!AccRewriteGetNamedRights+0x7f
081df844 6fca3f7c 17a823a0 081df86c 00000000 ntshrui!CFolderAclEngine::_GetAcl+0x30
081df874 6fca3f05 17d65814 081df894 6fca316c ntshrui!CFolderAclEngine::_IsItemPrivate+0x63
081df88c 6fca4960 00000000 17d65814 081df8c8 ntshrui!CSmbShareEngine::GetItemSharingStatus+0x1b
081df8b4 6fca4a18 17d65814 17f28478 00659530 ntshrui!CSharingOverlayPrivate::_GetSharingStatus+0x85
081df8d4 76512ca8 00622348 17bafb04 00000010 ntshrui!CSharingOverlayPrivate::IsMemberOf+0x69
081df904 7662fcb4 081df958 00000010 00000064 SHELL32!CFSIconOverlayManager::_GetFileOverlayInfo+0x11a
081df920 76512bae 0062adc0 081df958 00000010 SHELL32!CFSIconOverlayManager::GetFileOverlayInfo+0x1b
081dfb64 76512ab8 040503f8 081dfbe4 00000001 SHELL32!CFSFolder::_GetOverlayInfo+0x10f
081dfb78 7651478b 17dd39c0 040503f8 081dfbe4 SHELL32!CFSFolder::GetOverlayIndex+0x28
081dfba0 765138fe 08db2d04 040503f8 081dfbe4 SHELL32!CDesktopFolder::GetOverlayIndex+0x40
081dfbc0 7014b2d0 08de60f8 040503f8 081dfbe4 SHELL32!CRegFolder::GetOverlayIndex+0x45
081dfbdc 7014b289 ffffffff 040503f8 0f741488 EXPLORERFRAME!CNscOverlayTask::_Extract+0x32
081dfbf4 701108f6 08de60e4 01000000 80000000 EXPLORERFRAME!CNscOverlayTask::InternalResumeRT+0x31
081dfc14 765763bb 0f74149c 7fffffff 08e15488 EXPLORERFRAME!CRunnableTask::Run+0xce
081dfc30 76578c43 081dfc6c 00000000 17a748d0 SHELL32!CShellTask::TT_Run+0x167
081dfc78 76578d77 081dfc90 7627b2b1 08e15488 SHELL32!CShellTaskThread::ThreadProc+0xa3
081dfc80 7627b2b1 08e15488 0902c6f8 081dfd04 SHELL32!CShellTaskThread::s_ThreadProc+0x1b
081dfc90 775ad897 17a748d0 7f78dcce 006287e0 SHLWAPI!ExecuteWorkItemThreadProc+0xe
081dfd04 775b0846 17a748d0 0902c6f8 7f78dfae ntdll!RtlpTpWorkCallback+0x11d
081dfe64 75d6ed6c 006287d8 081dfeb0 775e377b ntdll!TppWorkerThread+0x572
081dfe70 775e377b 006287d8 7f78df7a 00000000 kernel32!BaseThreadInitThunk+0xe
081dfeb0 775e374e 775b03e9 006287d8 00000000 ntdll!__RtlUserThreadStart+0x70
081dfec8 00000000 775b03e9 006287d8 00000000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: d88f93992d675d51da0b6bb80cf72e33554c1a0c
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: c610c8843f28f8a4ba858fe9abfac4088a42a8e1
THREAD_SHA1_HASH_MOD: a1e2774180770312a6efc2e8cf99f51b102d2427
FOLLOWUP_IP:
MyDrv+8e17
95224e17 8945f8 mov dword ptr [ebp-8],eax
FAULT_INSTR_CODE: 33f84589
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: MyDrv+8e17
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: MyDrv
IMAGE_NAME: MyDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5281e1ad
FAILURE_BUCKET_ID: 0xC5_2_MyDrv+8e17
BUCKET_ID: 0xC5_2_MyDrv+8e17
PRIMARY_PROBLEM_CLASS: 0xC5_2_MyDrv+8e17
TARGET_TIME: 2014-02-03T12:10:15.000Z
OSBUILD: 7601
OSSERVICEPACK: 1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x86
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2013-01-05 11:46:00
BUILDDATESTAMP_STR: 130104-1431
BUILDLAB_STR: win7sp1_gdr
BUILDOSVER_STR: 6.1.7601.18044.x86fre.win7sp1_gdr.130104-1431
ANALYSIS_SESSION_ELAPSED_TIME: 186c
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0xc5_2_MyDrv+8e17
FAILURE_ID_HASH: {9dc76993-d915-564c-f684-d2b01a978dd4}
Followup: MachineOwner
---------
!analyze 내용의 콜 스택 아래 부분을 보면 FAILURE_BUCKET_ID: 0xC5_2_MyDrv+8e17 내용이 있다.
이 내용만 보면 MyDrv로 인해 문제가 발생한 것으로 오해하기 쉽다. 앞서 설명했지만 WinDbg에서는 nt 커널 모듈을 제외한 마지막 모듈을 보여주기 때문에 범인이 아닐 가능성도 있다.
물론 MyDrv가 범인일 수도 있기 때문에 철저한 분석을 통해 진짜 범인을 찾아보자.
우선 analyze 에서 시키는 대로 .trap 명령을 통해 문제가 발생한 부분으로 컨텍스트를 설정해보자.
kd> .trap 0xffffffffb683f62c
ErrCode = 00000002
eax=00000000 ebx=835706c0 ecx=8b6ac9f0 edx=86b117b0 esi=83570840 edi=835706c4
eip=8355a4c1 esp=b683f6a0 ebp=b683f6e8 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ExAllocatePoolWithTag+0x4b7:
8355a4c1
897004 mov dword ptr [eax+4],esi
ds:0023:00000004=????????
nt!ExAllocatePoolWithTag+0x4b7 시점에 mov dword ptr [eax+4],esi 명령을 수행하다 eax 가 0이라 eax+4인 00000004 주소에 접근했다.
그리고 00000004는 유효하지 않은 주소여서 문제가 발생했다.
그렇다면 문제 발생 시점의 앞 부분을 분석해서 eax에 0이 설정된 원인을 찾아야 한다.
먼저 kv 명령으로 콜 스택을 확인해서 문제 발생 상황을 살펴보자.
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 b683f6e8 83ba6aa1 00000000 00000040 7843464d nt!ExAllocatePoolWithTag+0x4b7// 2) BSOD 발생
01 b683f700 83ba8091 8ae62bf8 8bbdc820 869f1530 fltmgr!ExAllocateFromPagedLookasideList+0x27 (FPO: [Non-Fpo])
02 b683f718 95224e17 86a2aaf8 00000010 00000010 fltmgr!FltAllocateContext+0xa9 (FPO: [Non-Fpo])
03 b683f73c 952251b6 8bbdc820 b683f79c 86e48320 MyDrv+0x8e17 // 1) 필터매니저에게 컨텍스트 메모리 할당 요청
04 b683f758 952252cc 8bbdc820 b683f79c 86e48320 MyDrv+0x91b6
05 b683f77c 83ba7aeb 8bbdc820 b683f79c b683f7c8 MyDrv+0x92cc
06 b683f7e8 83baa9f0 b683f82c d39a3dd8 00000000 fltmgr!FltpPerformPreCallbacks+0x34d (FPO: [Non-Fpo])
07 b683f800 83bbe1fe b683f82c 83bc1f3c 00000000 fltmgr!FltpPassThroughInternal+0x40 (FPO: [Non-Fpo])
08 b683f814 83bbe8b7 b683f82c d39a3dd8 86b76f80 fltmgr!FltpCreateInternal+0x24 (FPO: [Non-Fpo])
09 b683f858 83470c0e 86e1c590 86e0f7e8 8b67de58 fltmgr!FltpCreate+0x2c9 (FPO: [Non-Fpo])
0a b683f870 b65ddffa 86b76f80 8b67de58 86b76f80 nt!IofCallDriver+0x63
0b b683f900 83470c0e 8b67de58 d39a3dd8 86b76fdc SomeDrv+0x5ffa
0c b683f918 836803ee a90c97a7 b683fac0 00000000 nt!IofCallDriver+0x63
0d b683f9f0 8365fc1e 86d4ae20 85ebb9c8 89a08d20 nt!IopParseDevice+0xee6
0e b683fa6c 83670030 00000000 b683fac0 00000040 nt!ObpLookupObjectName+0x4fa
0f b683fac8 83666b0e 081df704 85ebb9c8 00000001 nt!ObOpenObjectByName+0x165
10 b683fb44 8366cc94 179b0980 00020000 081df704 nt!IopCreateFile+0x673
11 b683fb8c b65b9725 179b0980 00020000 081df704 nt!NtOpenFile+0x2a
12 b683fc14 8347789a 179b0980 00020000 081df704 BadDrv+0x1725
13 b683fc14 775c7094 179b0980 00020000 081df704 nt!KiFastCallEntry+0x12a (FPO: [0,3] TrapFrame @ b683fc34)
... ...
1)번에서 미니필터로 동작 중인 MyDrv가 필터매니저(fltmgr)에게 메모리를 할당 받으려는 과정 중에 문제가 발생했다.
문제가 발생한 함수인 ExAllocatePoolWithTag를 디스어셈블링해서 eax가 손상된 원인을 찾아보자.
kd> u ExAllocatePoolWithTag+0x462 L18
nt!ExAllocatePoolWithTag+0x45d:
8355a467 ff742424 push dword ptr [esp+24h]
8355a46b e8f8efffff call nt!MiAllocatePoolPages (83559468)
8355a470 8bf0 mov esi,eax
8355a472 85f6 test esi,esi
8355a474 0f854e020000 jne nt!ExAllocatePoolWithTag+0x6bd (8355a6c8)
8355a47a ff442418 inc dword ptr [esp+18h]
8355a47e 837c241801 cmp dword ptr [esp+18h],1
8355a483 0f8504020000 jne nt!ExAllocatePoolWithTag+0x682 (8355a68d)
8355a489 f705b4305a8300020000 test dword ptr [nt!ExpPoolFlags (835a30b4)],200h
8355a493 0f84f4010000 je nt!ExAllocatePoolWithTag+0x682 (8355a68d)
8355a499 50 push eax
8355a49a 53 push ebx
8355a49b e8c0110000 call nt!ExDeferredFreePool (8355b660)
8355a4a0 e9e0feffff jmp nt!ExAllocatePoolWithTag+0x37b (8355a385)
8355a4a5 8b0e mov ecx,dword ptr [esi] // 4) ecx에 esi 값을 설정
8355a4a7 8b4104 mov eax,dword ptr [ecx+4]
8355a4aa 3bc6 cmp eax,esi
8355a4ac 0f85c8010000 jne nt!ExAllocatePoolWithTag+0x670 (8355a67a)
8355a4b2 8b5604 mov edx,dword ptr [esi+4]
8355a4b5 3932 cmp dword ptr [edx],esi
8355a4b7 0f85bd010000 jne nt!ExAllocatePoolWithTag+0x670 (8355a67a)
8355a4bd 8b01 mov eax,dword ptr [ecx] // 3) eax에 ecx 값을 설정
8355a4bf 8906 mov dword ptr [esi],eax // 2) esi에 eax 값을 설정
8355a4c1 897004 mov dword ptr [eax+4],esi // 1) eax+4에
esi 값을 설정하다 문제 발생
1)~4) 순서는 분석 흐름으로 실제 문제가 발생한 부분부터 거꾸로 확인한 순서이다. 문제가 발생한 1)번부터 확인해보면 결국 eax는 4)번에서 esi를 통해 ecx로 설정된 값이다.
2)번을 보면 esi에 eax 값을 넣고 있다. 한 번 확인해보자.
kd> r esi
Last set context:
esi=83570840
esi 값인 83570840도 확인해보자.
kd> dd 83570840 L1
83570840
00000000
esi에 0이 설정되어 있다. 3)번에서는 eax에 ecx 값을 넣고 있으니 ecx도 살펴보자.
kd> r ecx
Last set context:
ecx=8b6ac9f0
ecx 값인 8b6ac9f0도 확인해야 한다.
kd> dd 8b6ac9f0 L1
8b6ac9f0
00000000
ecx 역시 0이 설정되어 있다.
마지막으로 4)번에서 ecx를 설정한 esi를 살펴보자.
kd> r esi
Last set context:
esi=83570840
esi에 있는 83570840 값을 이번에는 ln 명령으로 커널의 특정 주소는 아닌지 확인해보자.
kd> ln 83570840
Browse module
Set bu breakpoint
(835706c0) nt!NonPagedPoolDescriptor+0x180
ln 명령으로 확인해보니 esi는 NonPagedPoolDescriptor 영역으로 확인된다. 그렇다면 풀 디스크립터인 esi에서 가져온 ecx 값은 풀 주소일 가능성이 높고, 이 주소를 누군가 0으로 손상시켰을 가능성이 의심된다.
esi 값인 83570840은 NonPagedPoolDescriptor 주소인 835706c0의 + 0x180 위치다. 디스크립터 시작 주소인 835706c0을 POOL_DESCRIPTOR 구조체에 넣어 확인해보자.
kd> dt _POOL_DESCRIPTOR 835706c0
nt!_POOL_DESCRIPTOR
+0x000 PoolType : 0 ( NonPagedPool )
+0x004 PagedLock : _KGUARDED_MUTEX
+0x004 NonPagedLock : 0xb683f6d0
+0x040 RunningAllocs : 0x262521c
+0x044 RunningDeAllocs : 0x25e6553
+0x048 TotalBigPages : 0x3d8c
+0x04c ThreadsProcessingDeferrals : 0
+0x050 TotalBytes : 0x5a47150
+0x080 PoolIndex : 0
+0x0c0 TotalPages : 0x2d28
+0x100 PendingFrees : 0x89895920 -> 0x8ba5a6e0 Void
+0x104 PendingFreeDepth : 6
+0x140 ListHeads : [512] _LIST_ENTRY [ 0x83570800 - 0x83570800 ]
0x140 에는 메모리 풀 주소들이 연결되어 있는 LIST_ENTRY 의 배열이 위치한다.
ecx 값이 디스크립터 시작 주소로부터 +0x180 위치라는 말은 0x140 위치의 ListHeads 필드로부터 +0x40 떨어진 위치라는 의미다. 따라서 계산을 통해 주소를 구할 수 있다.
kd> dt _LIST_ENTRY /v
ntdll!_LIST_ENTRY
struct _LIST_ENTRY, 2 elements, 0x8 bytes
+0x000 Flink : Ptr32 to struct _LIST_ENTRY, 2 elements, 0x8 bytes
+0x004 Blink : Ptr32 to struct _LIST_ENTRY, 2
elements, 0x8 bytes
LIST_ENTRY 의 크기를 확인하기 위해 dt 명령의 /v 옵션을 설정하니 8바이트라고 나온다. 0x40 / 8 = 8 이므로, 512개의 배열 중 8번째 인덱스 위치의 LIST_ENTRY가 ecx다.
ListHeads필드에 [n] 을 사용하면 인덱스로 접근 가능하다.
kd> dt _POOL_DESCRIPTOR 835706c0 ListHeads[8]
nt!_POOL_DESCRIPTOR
+0x140 ListHeads : [8] _LIST_ENTRY [ 0x0 - 0x86b117b0
]
8번째 인덱스를 확인해보니 LIST_ENTRY의 Flink가 정확하게 0 으로 확인된다. 이 값이 ecx에 설정된 것이다. 누군가 Flink 에 설정된 주소 값을 0으로 손상시켰음이 분명하다.
ecx가 문제였음이 확실해졌으니 이제 ecx를 !pool 명령으로 확인해보자.
kd> !pool ecx
Pool page 8b6ac9f0 region is Nonpaged pool
8b6ac808 doesn't look like a valid small pool allocation, checking to see
if the entire page is actually part of a large page allocation...
8b6ac808 is not valid pool. Checking for freed (or corrupt) pool
Bad previous allocation size @8b6ac808, last size was 0
***
*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
***
*** Use !poolval 8b6ac000 for more details.
Pool page [ 8b6ac000 ] is __inVALID.
Analyzing linked list...
Scanning for single bit errors...
None found
풀 헤더가 손상됐다고 나온다. 이런 경우 손상된 주소의 앞 쪽에서 누군가 메모리를 손상시켰을 가능성이 높다.
이제 1000 바이트 정도 앞 쪽 메모리 영역부터 확인해보자.
kd> !pool ecx-1000
Pool page 8b6ab9f0 region is Nonpaged pool
*8b6a0000 : large page allocation, tag is Ddk , size is 0xc808 bytes
Pooltag Ddk : Default for driver allocated memory (user's of ntddk.h)
손상된 풀 헤더의 앞에는 8b6a0000 주소부터 c808 바이트 크기로 할당된 꽤나 큰 라지 풀 영역이 존재한다.
풀 태그는 Ddk로 확인된다. Ddk는 nt 커널의 기본 풀 태그로 메모리 할당시 풀 태그를 지정하지 않으면 모두 이 태그로 할당된다. 따라서 이런 경우 누가 할당한 메모리인지 찾기 어렵다.
왠지 범인을 찾기가 쉽지 않을 것 같은 예감이 든다. 어쨌든 해당 풀의 마지막 부분부터 확인해보자.
kd> db 8b6a0000+c808-20
8b6ac7e8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6a0000 풀의 끝 위치(8b6ac807) ↓
8b6ac7f8 00 00 00 00 00 00 00 00-5c 00 3f 00 3f 00 5c 00 ........\.?.?.\.
↓ 다음 풀 시작 위치(8b6ac808)
8b6ac808 43 00 3a 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 C.:.\.W.i.n.d.o.
8b6ac818 77 00 73 00 5c 00 53 00-79 00 73 00 74 00 65 00 w.s.\.S.y.s.t.e.
8b6ac828 6d 00 33 00 32 00 5c 00-00 00 00 00 00 00 00 00 m.3.2.\.........
8b6ac838 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac848 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac858 00 00
00 00 00 00 00 00-00 00 00 00 00 00 00 00
................
풀 시작 주소인 8b6a0000에 풀 크기인 c808을 더하면 8b6ac808인데, 0x20(32) 바이트 앞부터 확인한 내용이다.
이 Ddk 풀 태그의 라지 풀은 8b6ac808 앞인 8b6ac807 주소까지만 사용 가능하다. 그런데 할당된 영역을 넘어서 "\??\C:\Windows\System32\" 문자열로 덮어 써 버렸다.
이번에는 문제의 ecx 값인 8b6ac9f0까지 다시 확인해보자.
kd> db 8b6a0000+c808-20 L220
8b6ac7e8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac7f8 00 00 00 00 00 00 00 00-5c 00 3f 00 3f 00 5c 00 ........\.?.?.\.
8b6ac808 43 00 3a 00 5c 00 57 00-69 00 6e 00 64 00 6f 00 C.:.\.W.i.n.d.o.
8b6ac818 77 00 73 00 5c 00 53 00-79 00 73 00 74 00 65 00 w.s.\.S.y.s.t.e.
8b6ac828 6d 00 33 00 32 00 5c 00-00 00 00 00 00 00 00 00 m.3.2.\.........
8b6ac838 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac848 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac858 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac868 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac878 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac888 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac898 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8a8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8b8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8c8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8e8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac8f8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac908 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac918 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac928 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac938 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac948 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac958 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac968 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac978 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac988 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac998 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac9a8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac9b8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac9c8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
8b6ac9d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
↓ ecx 주소(8b6ac9f0)
8b6ac9e8 00 00 00 00 00 00 00 00-00 00 00 00 40 08 57 83 ............@.W.
8b6ac9f8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
덮어 쓴 문자열 뒷 부분부터 ecx 부분까지는 전부 0으로 설정되어 있다. 이제야 ecx에 0이 설정된 상황이 이해가 된다. 앞 쪽 라지 풀을 할당한 모듈에서 문자열을 복사하다 뒤에 있는 디스크립터 관련 풀 헤더 영역까지 손상시킨 것이다.
다행히 메모리가 손상된 원인은 확인했지만 큰 난관이 남아있다. 풀 태그가 기본 풀 태그인 Ddk기 때문에 도대체 어떤 모듈이 범인인지 찾기 어렵다.
풀 태그가 없기 때문에 풀 태그 문자열을 가지고 모듈을 찾는 방법은 사용할 수 없기 때문이다.
정작 중요한 범인을 찾지 못해 난감한 상황이 되었다. 이를 어쩐다.
차분하게 분석했던 내용을 다시 살펴보니 이상한 부분이 하나 보인다.
바로 문제를 일으킨 0xc808 바이트 크기의 라지 풀이다.
kd> ?c808
Evaluate expression: 51208 = 0000c808
해당 풀을 할당한 모듈의 입장에서 한 번 생각해 보았다.
무슨 일로 51,208 바이트나 되는 풀을 할당했을까? 이 정도 크기면 뭔가 임시로 할당했다 해제하는 메모리가 아니라 버퍼 같은 용도로 크게 할당해 놓고 주기적으로 사용하는 메모리가 아닐까?
아마도 버퍼 목적의 메모리라면 해당 버퍼 주소를 전역 변수 어딘가에 설정해놓지 않았을까?
이런 생각의 흐름을 통해 다음과 같은 코드를 상상해 보았다.
// 전역 작업 버퍼
PVOID g_pWorkBuffer;
VOID
InitBuffer()
{
// 이렇게 풀 태그를 지정하지 않으면 ‘Ddk’로 할당된다.
g_pWorkBuffer = ExAllocatePool(NonPagedPool, 0xc808);
... ...
}
VOID
SaveString(
IN PWSTR pszString,
IN ULONG cbString
)
{
memcpy(g_pWorkbuffer, pszString, cbString);
... ...
}
g_pWorkBuffer 같은 전역 변수가 있다면 라지 풀의 시작 주소인 8b6a0000 을 할당 받아 갖고 있을 가능성이 있다.
이를 검증하기 위해 모듈에서 풀 태그 문자열을 찾을 때 썼던 방법을 응용해보자. 풀 태그 문자열 대신 풀 주소 값인 8b6a0000을 넣어 보는 것이다.
메모리에 있는 문자열이 아닌 바이트 값을 검색하려면 문자열 검색 옵션인 -a는 설정하지 않아야 한다.
또 한 가지는 8b6a0000을 그대로 입력하면 안 된다. 반대로 한 글자 씩 ‘00 00 6a 8b’로 입력해야 한다. DWORD로 표시되는 8b6a0000 값은 실제 메모리에는 반대로 저장되어 있기 때문이다(이를 리틀 엔디언 방식이라고 한다. 이해가 안 된다면 리틀 엔디언과 빅 엔디언의 차이를 찾아보자).
kd> !for_each_module s @#Base @#End 00 00 6a 8b
6cc3ff72 00 00 6a 8b c1 6c ff ff-ff ff 00 00 00 00 ff ff ..j..l..........
b65be3a4 00 00 6a 8b 26 00 00 00-00
00 00 00 01 00 00 00
..j.&...........
유저 영역 주소인 6cc3ff72를 제외하면 커널 영역 주소로 b65be3a4가 하나 검색된다. 왠지 모르게 등골이 서늘해진다.
정말 예상대로 어떤 모듈의 주소가 맞을까? lmva 명령으로 확인해보자.
kd> lmva b65be3a4
Browse full module list
start end module name
b65b8000 b65c7700 BadDrv (no symbols)
Loaded symbol image file: BadDrv.sys
Image path: \??\C:\Windows\system32\drivers\BadDrv.sys
Image name: BadDrv.sys
Browse all global symbols functions data
Timestamp: Tue Mar 22 11:33:52 2011 (4D880A90)
CheckSum: 0001DB7F
ImageSize: 0000F700
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
와우! 라지 풀의 주소인 8b6a0000이 있는 b65be3a4 값은 b65b8000에 위치한 BadDrv 모듈 내의 주소다. 정말 짜릿한 순간이다.
이번에는 b65be3a4 주소가 정확하게 BadDrv 모듈의 어느 부분인지 살펴보자.
!dh 명령을 모듈 시작 주소와 함께 사용하면 PE 헤더 형식으로 내용을 보여준다.
kd> !dh b65b8000
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
5 number of sections
4D880A90 time date stamp Tue Mar 22 11:33:52 2011
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
10E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
OPTIONAL HEADER VALUES
10B magic #
6.00 linker version
6280 size of code
9200 size of initialized data
0 size of uninitialized data
50B9 address of entry point
280 base of code
----- new -----
00010000 image base
80 section alignment
80 file alignment
1 subsystem (Native)
5.00 operating system version
5.00 image version
1.10 subsystem version
F700 size of image
280 size of headers
1DB7F checksum
00040000 size of stack reserve
00001000 size of stack commit
00100000 size of heap reserve
00001000 size of heap commit
0 DLL characteristics
0 [ 0] address [size] of Export Directory
E600 [ 3C] address [size] of Import Directory
EB80 [ 4A8] address [size] of Resource Directory
0 [ 0] address [size] of Exception Directory
0 [ 0] address [size] of Security Directory
F080 [ 4F8] address [size] of Base Relocation Directory
370 [ 1C] address [size] of Debug Directory
0 [ 0] address [size] of Description Directory
0 [ 0] address [size] of Special Directory
0 [ 0] address [size] of Thread Storage Directory
0 [ 0] address [size] of Load Configuration Directory
0 [ 0] address [size] of Bound Import Directory
280 [ F0] address [size] of Import Address Table Directory
0 [ 0] address [size] of Delay Import Directory
0 [ 0] address [size] of COR20 Header Directory
0 [ 0] address [size] of Reserved Directory
SECTION HEADER #1
.text name
5CFE virtual size
280 virtual address
5D00 size of raw data
280 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
68000020 flags
Code
Not Paged
(no align specified)
Execute Read
Debug Directories(1)
Type Size Address Pointer
cv 94 0 f700 [Debug data not mapped]
SECTION HEADER #2
.data name
8680 virtual size // 데이터 섹션 크기
5F80 virtual address // 데이터 섹션 시작 위치
8680 size of raw data
5F80 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C8000040 flags
Initialized Data
Not Paged
(no align specified)
Read Write
SECTION HEADER #3
INIT name
556 virtual size
E600 virtual address
580 size of raw data
E600 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
E2000020 flags
Code
Discardable
(no align specified)
Execute Read Write
SECTION HEADER #4
.rsrc name
4A8 virtual size
EB80 virtual address
500 size of raw data
EB80 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only
SECTION HEADER #5
.reloc name
61E virtual size
F080 virtual address
680 size of raw data
F080 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only
확인된 내용을 보면 전역 변수들이 위치하는 데이터 섹션(.data)은 b65bdf80부터 b65c6600까지다.
// 데이터 섹션 시작 위치(virtual address)
kd> ?b65b8000 + 5f80
Evaluate expression: -1235492992 = b65bdf80
// 데이터 섹션 크기(virtual size)
kd> ?b65bdf80 + 8680
Evaluate
expression: -1235458560 = b65c6600
데이터 섹션의 범위가 b65bdf80 – b65c6600 이므로 찾은 b65be3a4 값은 정확하게 데이터 섹션 내의 주소다. 예상대로 범인인 라지 풀은 BadDrv 모듈 전역 변수에 설정된 버퍼였던 것이다.
이번 예제도 다른 메모리 손상 이슈와 비슷하게 BadDrv 모듈에서 전역 버퍼로 할당한 메모리를 잘못 관리하여 뒷 부분 메모리까지 손상시킨 것이 원인으로 밝혀졌다.
이런 예제를 분석할 때면 어려운 퍼즐을 푸는 것 같은 스릴을 느낀다.
이번 분석의 교훈은 답이 보이지 않을 때는 범인의 입장에서 생각해보자이다. 숨겨진 퍼즐의 답을 찾을 수 있을 것이다.
'Dump Analysis' 카테고리의 다른 글
| [0x133] DPC_WATCHDOG_VIOLATION (0) | 2018.07.29 |
|---|---|
| [0xC5] 해제 리스트 손상 (0) | 2018.07.19 |
| [0x1A] 페이지 손상 (0) | 2018.07.12 |
| [0x50] 해제된 핸들 (0) | 2018.07.09 |
| [0x50] 숨겨진 콜 스택 (0) | 2018.07.07 |
이번 덤프는 BugCheck 0x1A: MEMORY_MANAGEMENT다.
0x1A는 커널에서 메모리 주소를 관리하는 과정 중에 문제가 생기면 발생한다. 다양한 원인이 있을 수 있는데, 예를 들어 메모리 관리자가 특정 메모리 주소를 변환하려고 페이지 테이블 엔트리(PTE)를 참조할 때 엔트리 손상이 감지되면 이 오류 코드를 발생시킨다.
대부분 커널 내부 코드에서 발생하기 때문에 분석 자체가 굉장히 어렵고 불가능한 경우도 많다. 물론 시작도 안하고 포기할 수는 없으니 일단 시작해보자.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 00041287, An illegal page fault occurred while holding working set
synchronization.
Parameter 2 contains the referenced virtual address.
Arg2: 34333231
Arg3: 00000000
Arg4: 00000000
Debugging Details:
------------------
BUGCHECK_STR: 0x1a_41287
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: WerFault.exe
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
TRAP_FRAME: aa9ff594 -- (.trap 0xffffffffaa9ff594)
ErrCode = 00000000
eax=34333231 ebx=85c5c000 ecx=29a00000 edx=0f349000 esi=00000000 edi=831a7100
eip=830d8f0f esp=aa9ff608 ebp=aa9ff618 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!MiAllocateAccessLog+0x54:
830d8f0f 3930 cmp dword ptr [eax],esi
ds:0023:34333231=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 8307ca78 to 830c99ad
STACK_TEXT:
aa9ff57c 8307ca78 00000000 34333231 00000000 nt!MmAccessFault+0x104
aa9ff57c 830d8f0f 00000000 34333231 00000000 nt!KiTrap0E+0xdc
aa9ff618 830c111e c0699800 84a94e2c 842f4804 nt!MiAllocateAccessLog+0x54
aa9ff664 830c7907 c0699800 00000000 85a9b630 nt!MiLogPageAccess+0x40
aa9ff8d4 8326b0c4 d3300000 cdf693f0 00000000 nt!MmUnmapViewInSystemCache+0x1c1
aa9ff90c 830c97b5 85a9b630 85e8f5a8 00000000 nt!CcUnmapVacb+0x18c
aa9ff94c 830c76ff 01e8f5a8 831a7400 00000001 nt!CcUnmapVacbArray+0x292
aa9ff96c 830c7d9c 831a7400 00000000 85e8f5a8 nt!CcUnmapAndPurge+0x2e
aa9ff988 830c7514 00000001 85de1f80 00000000 nt!CcDeleteSharedCacheMap+0x82
aa9ff9bc 830e74a6 aa9ff9ec 812c5e91 01000000 nt!CcWriteBehind+0x715
aa9ffa1c 83261c3f 87d9af80 00000000 00000000 nt!CcWaitForUninitializeCacheMap+0x15e
aa9ffb3c 832613c9 aa9ffb90 00000007 00000000 nt!MmCreateSection+0x339
aa9ffbb0 936eef93 0010d600 00000007 00000000 nt!NtCreateSection+0x16e
aa9ffc10 83079896 0010d600 00000007 00000000 SomeDrv+0xdf93
aa9ffc10 76df70f4 0010d600 00000007 00000000 nt!KiSystemServicePostCall
0010d720 00000000 00000000 00000000 00000000 0x76df70f4
STACK_COMMAND: kb
FOLLOWUP_IP:
SomeDrv+df93
936eef93 8bf0 mov esi,eax
SYMBOL_STACK_INDEX: d
SYMBOL_NAME: SomeDrv+df93
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: SomeDrv
IMAGE_NAME: SomeDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 53268cfa
FAILURE_BUCKET_ID: 0x1a_41287_SomeDrv+df93
BUCKET_ID: 0x1a_41287_SomeDrv+df93
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x1a_41287_SomeDrv+df93
FAILURE_ID_HASH: {385bcdbd-2174-4449-cfff-dcc030b0a015}
Followup: MachineOwner
---------
오류 코드 0x1A만 보면 마음이 무겁다. 분석도 어렵고 고통스러울 뿐 아니라 들인 시간에 비해 소득이 없는 경우가 많기 때문이다.
경험상 커널 자체적인 문제보다 외부 모듈에서 하필 메모리 주소 관리 영역을 깨 버려 발생한 경우가 대부분인데 커널 내부 깊숙한 곳에서 오류가 발생하기 때문에 메모리 손상에 대한 증거가 남아 있지 않는 경우가 많다.
그래도 분석이 가능한 경우도 있으니 BugCode의 파라미터 정보부터 살펴보자.
Arg1: 00041287, An illegal page fault occurred while holding working set synchronization. Parameter 2 contains the referenced virtual address.
Arg2:
34333231
Arg1 값은 세부 오류 코드로 다양한 값이 존재하는데 도움말(F1)의 검색 탭에서 Bug Check 0x1A 로 검색하면 이 파라미터 값이 의미하는 바를 알 수 있다.
워킹셋 동기화를 잡고 있는 상태에서 접근한 페이지 정보에 문제가 있었는데, Arg2에 문제를 일으킨 주소가 34333231이라고 말해준다.
물론, 분석에 별 도움은 되지 않는다. 단지 34333231이라는 값이 정상적인 주소 값 형태가 아니기 때문에 누군가가 또 메모리를 손상 시켰으리라 의심할 따름이다.
analyze 결과의 아래 FAILURE_BUCKET_ID를 보면 0x1a_41287_SomeDrv+df93이 있다. SomeDrv로 인해 문제가 발생한 것처럼 보여주고 있다.
나는 이 정보도 크게 신뢰하지 않는다. 왜냐하면 WinDbg는 단지 콜 스택에서 nt 커널 모듈을 제외하고 마지막 모듈을 보여주기 때문이다. 당연하게도 메모리 손상 이슈에서는 전혀 다른 모듈이 범인인 경우가 매우 많다.
언제나처럼 .trap 명령을 사용해서 문제가 발생한 부분으로 컨텍스트 정보를 설정해보자.
kd> .trap 0xffffffffaa9ff594
ErrCode = 00000000
eax=34333231 ebx=85c5c000 ecx=29a00000 edx=0f349000 esi=00000000 edi=831a7100
eip=830d8f0f esp=aa9ff608 ebp=aa9ff618 iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!MiAllocateAccessLog+0x54:
830d8f0f 3930 cmp dword ptr [eax],esi
ds:0023:34333231=????????
eax에 있는 34333231 주소가 접근할 수 없는 영역이라 문제가 발생했다고 한다.
이제 kv 명령어로 파라미터를 포함한 콜 스택을 확인해보자.
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 aa9ff618 830c111e c0699800 84a94e2c 842f4804 nt!MiAllocateAccessLog+0x54
01 aa9ff664 830c7907 c0699800 00000000 85a9b630 nt!MiLogPageAccess+0x40
02 aa9ff8d4 8326b0c4 d3300000 cdf693f0 00000000 nt!MmUnmapViewInSystemCache+0x1c1
03 aa9ff90c 830c97b5 85a9b630 85e8f5a8 00000000 nt!CcUnmapVacb+0x18c
04 aa9ff94c 830c76ff 01e8f5a8 831a7400 00000001 nt!CcUnmapVacbArray+0x292
05 aa9ff96c 830c7d9c 831a7400 00000000 85e8f5a8 nt!CcUnmapAndPurge+0x2e
06 aa9ff988 830c7514 00000001 85de1f80 00000000 nt!CcDeleteSharedCacheMap+0x82
07 aa9ff9bc 830e74a6 aa9ff9ec 812c5e91 01000000 nt!CcWriteBehind+0x715
08 aa9ffa1c 83261c3f 87d9af80 00000000 00000000 nt!CcWaitForUninitializeCacheMap+0x15e
09 aa9ffb3c 832613c9 aa9ffb90 00000007 00000000 nt!MmCreateSection+0x339
0a aa9ffbb0 936eef93 0010d600 00000007 00000000 nt!NtCreateSection+0x16e
0b aa9ffc10 83079896 0010d600 00000007 00000000 SomeDrv+0xdf93
0c aa9ffc10 76df70f4 0010d600 00000007 00000000 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ aa9ffc34)
0d 0010d720 00000000 00000000 00000000 00000000
0x76df70f4
정말이지 nt 커널 함수만 잔뜩 있는 이런 콜 스택을 보면 한숨이 절로 나온다.
nt!MiAllocateAccessLog+0x54에서 문제가 발생했으니 여기 안에서 메모리 손상과 관련된 단서가 발견되기를 기대해보자.
다음은 nt!MiAllocateAccessLog+0x54 부분을 디스어셈블링한 내용이다.
kd> u nt!MiAllocateAccessLog L1d
nt!MiAllocateAccessLog:
830d8ebb 8bff mov edi,edi
830d8ebd 55 push ebp
830d8ebe 8bec mov ebp,esp
830d8ec0 51 push ecx
830d8ec1 51 push ecx
830d8ec2 8b0d80b41683 mov ecx,dword ptr [nt!MmAvailablePages(8316b480)]
830d8ec8 b800040000 mov eax,400h
830d8ecd 53 push ebx
830d8ece 56 push esi
830d8ecf 3bc8 cmp ecx,eax
830d8ed1 721d jb nt!MiAllocateAccessLog+0x35 (830d8ef0)
830d8ed3 8b0d00b51683 mov ecx,dword ptr [nt!MmResidentAvailablePages(8316b500)]
830d8ed9 3bc8 cmp ecx,eax
830d8edb 7c13 jl nt!MiAllocateAccessLog+0x35 (830d8ef0)
830d8edd e84badffff call nt!MI_FREE_NON_PAGED_POOL_PAGES_LEFT(830d3c2d)
830d8ee2 c745fc00100000 mov dword ptr [ebp-4],1000h
830d8ee9 3d00080000 cmp eax,800h
830d8eee 7307 jae nt!MiAllocateAccessLog+0x3c (830d8ef7)
830d8ef0 c745fc00020000 mov dword ptr [ebp-4],200h
830d8ef7 8b5f08 mov ebx,dword ptr [edi+8]
830d8efa 33f6 xor esi,esi
830d8efc 3bde cmp ebx,esi
830d8efe 741e je nt!MiAllocateAccessLog+0x63 (830d8f1e)
830d8f00 817dfc00020000 cmp dword ptr [ebp-4],200h
830d8f07 8b03 mov eax,dword ptr [ebx] // 2) ebx eax
830d8f09 7408 je nt!MiAllocateAccessLog+0x58 (830d8f13)
830d8f0b 3bc6 cmp eax,esi
830d8f0d 740f je nt!MiAllocateAccessLog+0x63 (830d8f1e)
830d8f0f 3930 cmp dword ptr [eax],esi // 1) eax에 설정된 값과 esi 를 비교하다 문제 발생
1)번 eax에 있던 값은 34333231이며 유효하지 않은 주소 값이다. cmp dword ptr [eax],esi 명령으로 eax에 있는 34333231 주소에서 값을 읽으려다 문제가 발생했다. eax 레지스터 내용을 확인해보자.
kd> r eax
Last set context:
eax=34333231
kd> dd eax L1
34333231
????????
34333231은 ??로 접근할 수 없는 영역이다. eax에 34333231이 설정된 원인을 찾기 위해 약간 앞 쪽 코드를 살펴보면 2)번에서 ebx를 통해 설정하고 있다.
ebx를 한 번 살펴보자.
kd> r ebx
Last set context:
ebx=85c5c000
kd> dd 85c5c000 L1
85c5c000 34333231
ebx에는 85c5c000 값이 있고 85c5c000에 찾고 있던 34333231 값이 담겨 있다.
85c5c000은 값만 보면 유효한 주소 값 형태로 보인다. 일반적으로 정상적인 주소 값의 경우 xxxxxxx0, xxxxxxx8로 끝난다.
유효한 주소 값은 스택 상의 주소나 동적 할당된 메모리 혹은 모듈 내의 주소인 경우가 많다.
!thread 명령으로 현재 스레드 정보를 보면 문제가 발생한 프로세스 및 현재 스레드의 스택 정보를 알 수 있다.
kd> !thread
THREAD 88eac540 Cid 0d10.0d14 Teb: 7ffdf000 Win32Thread: fd601700 RUNNING on processor 2
Not impersonating
DeviceMap ae1d7a28
Owning Process 890b22a8 Image: WerFault.exe
Attached Process N/A Image: N/A
Wait Start TickCount 6552 Ticks: 0
Context Switch Count 9853 IdealProcessor: 3
UserTime 00:00:00.015
KernelTime 00:00:05.116
Win32 Start Address 0x006f80c7
Stack Init aa9ffed0 Current aa9ff6a8 Base aaa00000 Limit aa9fd000 Call 0
Priority 8 BasePriority 7 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
aa9ff57c 8307ca78 00000000 34333231 00000000 nt!MmAccessFault+0x104
aa9ff57c 830d8f0f 00000000 34333231 00000000 nt!KiTrap0E+0xdc (FPO: [0,0] TrapFrame @ aa9ff594)
aa9ff618 830c111e c0699800 84a94e2c 842f4804 nt!MiAllocateAccessLog+0x54
aa9ff664 830c7907 c0699800 00000000 85a9b630 nt!MiLogPageAccess+0x40
aa9ff8d4 8326b0c4 d3300000 cdf693f0 00000000 nt!MmUnmapViewInSystemCache+0x1c1
aa9ff90c 830c97b5 85a9b630 85e8f5a8 00000000 nt!CcUnmapVacb+0x18c
aa9ff94c 830c76ff 01e8f5a8 831a7400 00000001 nt!CcUnmapVacbArray+0x292
aa9ff96c 830c7d9c 831a7400 00000000 85e8f5a8 nt!CcUnmapAndPurge+0x2e
aa9ff988 830c7514 00000001 85de1f80 00000000 nt!CcDeleteSharedCacheMap+0x82
aa9ff9bc 830e74a6 aa9ff9ec 812c5e91 01000000 nt!CcWriteBehind+0x715
aa9ffa1c 83261c3f 87d9af80 00000000 00000000 nt!CcWaitForUninitializeCacheMap+0x15e
aa9ffb3c 832613c9 aa9ffb90 00000007 00000000 nt!MmCreateSection+0x339
aa9ffbb0 936eef93 0010d600 00000007 00000000 nt!NtCreateSection+0x16e
aa9ffc10 83079896 0010d600 00000007 00000000 SomeDrv+0xdf93
aa9ffc10 76df70f4 0010d600 00000007 00000000 nt!KiSystemServicePostCall (FPO:[0,3] TrapFrame @ aa9ffc34)
0010d720 00000000 00000000 00000000 00000000
0x76df70f4
Stack 주소 영역은 Limit aa9fd000부터 Base aaa00000까지라고 나온다.
또한 lmva 명령으로 모듈 내의 주소인지도 확인 가능하다.
kd> lmva 85c5c000
Browse full module list
start end module name
아무런 출력 결과가 없다. 일치되는 모듈 주소가 없다는 의미다. 그렇다면 동적으로 할당된 메모리 주소일 가능성이 높다.
!pool 명령을 사용해서 확인해보자.
kd> !pool 85c5c000
Pool page 85c5c000 region is Nonpaged pool
*85c5c000 : large page allocation, tag is MmAc, size is 0x1000 bytes
Pooltag
MmAc : Mm access log buffers, Binary : nt!mm
역시나 MmAc 풀 태그로 할당된 Nonpaged 풀이라고 친절하게 알려 준다. 풀 태그 설명을 보니 Mm access log buffers이고, 85c5c000 값은 MiAllocateAccessLog 내에서 사용된 값이니 정상적인 값일 것이다.
그렇다면 ebx에 설정된 85c5c000은 정상이었는데 85c5c000의 값을 누군가 34333231로 덮어 썼을 가능성이 매우 높다.
보통 이런 외부 모듈에 의한 메모리 손상은 주로 다음 2가지 시나리오에 의해 발생한다.
1. 외부 모듈이 메모리 주소 앞쪽 부분부터 문제 발생 위치까지 덮어 썼을 가능성
2. 외부 모듈이 문제 발생 위치만 덮어 썼을 가능성
흔히 1번 시나리오가 발생 빈도도 높고 메모리 앞쪽 부분을 살펴보면 원인을 찾을 가능성도 높다. 반면에 2번 같은 경우에는 증거를 찾기가 무척 어려워 분석이 불가능한 경우가 많다.
희망을 가지고 85c5c000의 앞쪽 메모리를 한 번 살펴보자.
100 bytes 정도 앞의 값을 !pool 명령으로 보면 앞 쪽에 할당된 풀 정보를 함께 확인할 수 있다.
kd> !pool 85c5c000-100
Pool page 85c5bf00 region is Nonpaged pool
85c5b000 size: 270 previous size: 0 (Free ) Irp
85c5b270 size: 8 previous size: 270 (Free) .(..
85c5b278 size: 128 previous size: 8 (Allocated) Ntfi
85c5b3a0 size: 140 previous size: 128 (Allocated) Io Process: 887dfd40
85c5b4e0 size: 10 previous size: 140 (Free) Io
85c5b4f0 size: 28 previous size: 10 (Allocated) ABss
85c5b518 size: b8 previous size: 28 (Allocated) File (Protected)
85c5b5d0 size: 298 previous size: b8 (Allocated) AbcH
85c5b868 size: 118 previous size: 298 (Allocated) AbcH
85c5b980 size: 8 previous size: 118 (Free) Ifs
85c5b988 size: 28 previous size: 8 (Allocated) ABss
85c5b9b0 size: a8 previous size: 28 (Allocated) File (Protected)
85c5ba58 size: 8 previous size: a8 (Free) Ifs
85c5ba60 size: 198 previous size: 8 (Free ) Ifs
*85c5bbf8 size: 408 previous size: 198 (Allocated) *BaDr
Owning
component : Unknown (update pooltag.txt)
85c5bbf8에 BaDr 풀 태그와 함께 408 바이트로 할당된 풀이 보인다. 직감적으로 이 곳에 중요한 단서가 있음이 느껴진다.
db 명령을 통해 BaDr 풀 영역을 확인해보자.
kd> db 85c5bbf8 L408
85c5bbf8 33 00 81 04 42 61 44 72-3b 3b 3b 3b f8 0a 88 01 3...BaDr;;;;....
85c5bc08 f8 0a 88 01 f3 0a 88 01-3b 3b c4 88 3b 88 01 a7 ........;;..;...
85c5bc18 3b 01 d0 ec be 02 3b 3b-02 3b 18 3b 30 3b 04 ee ;.....;;.;.;0;..
85c5bc28 be 02 3b 3b 3b 3b 3b 3b-c8 ed be 02 cc 6f e0 76 ..;;;;;;.....o.v
85c5bc38 3b 3b 3b 3b 3b 3b d0 58-2a c0 65 96 76 d0 58 2a ;;;;;;.X*.e.v.X*
85c5bc48 3b 3b c0 65 96 76 e4 ed-be 02 09 d9 8e 76 c0 65 ;;.e.v.......v.e
85c5bc58 96 76 3b 3b f5 0a 44 76-9d 69 96 a4 58 ee be 02 .v;;..Dv.i..X...
85c5bc68 b5 d5 8e 76 3c 02 3b 1c-ee be 02 34 ee be 02 3b ...v<.;....4...;
85c5bc78 3b 38 ee be 02 30 ee be-02 29 6a 96 a4 fc ee be ;8...0...)j.....
85c5bc88 02 ef be 02 2d 46 3f 76-36 38 b0 0a 88 01 f4 ed ....-F?v68......
85c5bc98 be 02 3b 3b 3b 3b 3b 3b-3b 3b 3b 3b 3b 3b 0c ee ..;;;;;;;;;;;;..
85c5bca8 be 02 30 3b bc ee be 02-22 a0 94 76 51 52 a6 d0 ..0;...."..vQR..
85c5bcb8 fe ff ff ff 3b 3b ab cf-81 01 3c 02 3b b0 0a 88 ....;;....<.;...
85c5bcc8 01 3b 3b 3b 3b 3b 3b 8c-ee be 02 75 45 e5 a6 07 .;;;;;;....uE...
85c5bcd8 3b 20 ef be 02 c0 f7 be-02 3b 3b 3b 3b 3c 02 3b ; .......;;;;<.;
85c5bce8 60 3b e8 ee be 02 20 ef-be 02 c8 96 84 01 5b 76 `;.... .......[v
85c5bcf8 81 01 f8 0a 88 01 6e 3b-c8 96 84 01 60 3b 85 45 ......n;....`;.E
85c5bd08 e5 a6 40 ef be 02 08 e4-83 01 ff ff ff ff 43 d4 ..@...........C.
85c5bd18 81 01 20 ef be 02 dd 45-e5 a6 08 3b 64 ef be 02 .. ....E...;d...
85c5bd28 c0 f7 be 02 0f 3b 3b 3b-20 ef be 02 40 29 88 01 .....;;; ...@)..
85c5bd38 40 29 88 01 30 34 88 01-80 ef be 02 64 ef be 02 @)..04......d...
85c5bd48 b0 0a 88 01 0f 3b 18 89-84 01 e8 83 84 01 1b 3b .....;.........;
85c5bd58 1f 3b 05 3b 01 3b 3c ef-be 02 f8 0a 88 01 f8 89 .;.;.;<.........
85c5bd68 84 01 a0 ef be 02 3b 3b-30 3b 37 3b ed 45 e5 a6 ......;;0;7;.E..
85c5bd78 c4 ff be 02 08 f3 83 01-02 3b 30 53 81 01 80 ef .........;0S....
85c5bd88 be 02 01 3b d0 f0 40 d0-51 81 01 3b 3b b8 ef be ...;..@.Q..;;...
85c5bd98 02 b0 0a 88 01 01 3b 3b-3b d4 ef be 02 0f 3b 0f ......;;;.....;.
85c5bda8 3b 3b 3b 78 0a 88 01 02-3b 10 02 10 02 10 02 10 ;;;x....;.......
85c5bdb8 02 0f 3b 17 3b 3b 8a 76-31 3b 02 03 02 03 20 f4 ..;.;;.v1;.... .
85c5bdc8 be 02 85 9f 20 75 01 3b-07 3b 00 00 00 00 00 00 .... u.;.;......
85c5bdd8 00 00 00 00 00 00 00 00-00 3f 3f 31 3b be 02 3b .........??1;..;
85c5bde8 3b 3b 3b 3b 3b 3b 08 02-0c f2 be 02 3b 08 02 04 ;;;;;;......;...
85c5bdf8 f0 be 02 3b 3b 3b 8a 76-48 02 48 02 48 02 48 02 ...;;;.vH.H.H.H.
85c5be08 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be18 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be28 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be38 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be48 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be58 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be68 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be78 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be88 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5be98 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5bea8 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5beb8 48 02 48 02 48 02 48 02-48 02 48 02 48 02 48 02 H.H.H.H.H.H.H.H.
85c5bec8 48 02 48 02 48 02 02 20-01 02 03 04 05 06 07 08 H.H.H.. ........
85c5bed8 09 0a 0b 0c 0d 0e 0f 10-11 12 13 14 15 16 17 18 ................
85c5bee8 19 1a 1b 1c 1d 1e 1f 20-21 22 23 24 25 26 27 28 ....... !"#$%&'(
85c5bef8 29 2a 2b 2c 2d 2e 2f 30-31 32 33 34 35 36 37 38 )*+,-./012345678
85c5bf08 39 3a 3b 3c 3d 3e 3f 40-41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
85c5bf18 49 4a 4b 4c 4d 4e 4f 50-51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
85c5bf28 59 5a 5b 5c 5d 5e 5f 60-41 42 43 44 45 46 47 48 YZ[\]^_`ABCDEFGH
85c5bf38 49 4a 4b 4c 4d 4e 4f 50-51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
85c5bf48 59 5a 7b 7c 7d 7e 7f 80-20 20 20 20 20 20 20 20 YZ{|}~..
85c5bf58 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf68 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf78 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf88 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf98 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfa8 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfb8 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfc8 20 20 20 20 20 20 ff 20-01 02 03 04 05 06 07 08 . ........
85c5bfd8 09 0a 0b 0c 0d 0e 0f 10-11 12 13 14 15 16 17 18 ................
85c5bfe8 19 1a 1b 1c 1d 1e 1f 20-21 22 23 24 25 26 27 28 ....... !"#$%&'(
(BaDr) 85c5bfff | 85c5c000 (MmAc)
↓ ↓
85c5bff8
29 2a 2b 2c 2d 2e 2f 30-31 32 33 34
35 36 37 3b )*+,-./01234567;
BaDr 풀은 408바이트 크기인 85c5bfff까지만 사용 가능하다. MmAc 풀의 시작 부분이 문제가 발생한85c5c000주소인데 시작 위치를 보면 31 32 33 34 값이 보인다.
이 값을DWORD 크기인 4바이트로 읽으면 34333231이 된다. 바로 유효하지 않았던 그 값이다. 이해가 안 된다면 85c5c000 주소를 db 와 dd 명령으로 확인해보자.
재미있게도 85c5c000 주소에 담긴 31 32 33 34 값을 ASCII 문자열로 읽으면 "1234"다.
.format 명령을 사용하면 문자열 값을 확인할 수 있다.
kd> .formats 31323334
Evaluate expression:
... ...
Chars: 1234
... ...
무엇보다 85c5bee8 주소부터 시작된 문자열 패턴과 85c5bfe8 주소부터 시작된 문자열 패턴이 매우 유사하다.
kd> db 85c5bee8 L120
1) 패턴 1 : BaDr 영역
85c5bee8 19 1a 1b 1c 1d 1e 1f 20-21 22 23 24 25 26 27 28 ....... !"#$%&'(
85c5bef8 29 2a 2b 2c 2d 2e 2f 30-31 32 33 34 35 36 37 38 )*+,-./012345678
85c5bf08 39 3a 3b 3c 3d 3e 3f 40-41 42 43 44 45 46 47 48 9:;<=>?@ABCDEFGH
85c5bf18 49 4a 4b 4c 4d 4e 4f 50-51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
85c5bf28 59 5a 5b 5c 5d 5e 5f 60-41 42 43 44 45 46 47 48 YZ[\]^_`ABCDEFGH
85c5bf38 49 4a 4b 4c 4d 4e 4f 50-51 52 53 54 55 56 57 58 IJKLMNOPQRSTUVWX
85c5bf48 59 5a 7b 7c 7d 7e 7f 80-20 20 20 20 20 20 20 20 YZ{|}~..
85c5bf58 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf68 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf78 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf88 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bf98 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfa8 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfb8 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
85c5bfc8 20 20 20 20 20 20 ff 20-01 02 03 04 05 06 07 08 . ........
85c5bfd8 09 0a 0b 0c 0d 0e 0f 10-11 12 13 14 15 16 17 18 ................
2) 패턴 2 : BaDr 영역
85c5bfe8 19 1a 1b 1c 1d 1e 1f 20-21 22 23 24 25 26 27 28 ....... !"#$%&'(
3) BaDr에서 MmAc로 바뀌는 부분 | => 여기부터는 MmAc 영역
85c5bff8
29 2a 2b 2c 2d 2e 2f 30-31 32 33 34 35
36 37 3b )*+,-./01234567;
1)번 패턴과 2)번 패턴은 "19 1a 1b 1c"로 시작하는 부분부터 "31 32 33 34 35 36 37(1234567)"까지 완전히 동일하다.
그런데 2)번 패턴의 중간 위치인 3)번은 이미 BaDr이 아닌 커널의 MmAc의 풀 영역이다.
즉, 누군가 정해진 버퍼 크기를 넘어 문자열 복사를 해서 BaDr 다음 위치인 MmAc 풀 영역을 손상시켰고, 이후 MiAllocateAccessLog 함수에서 손상된 값에 접근하다 문제가 발생한 것이다.
이런 경우 대부분 BaDr 풀 태그로 메모리를 할당한 모듈이 범인이다.
풀 태그 문자열은 모듈 내에 포함되어 있기 때문에 !for_each_module 명령을 통해 메모리에 로드된 모든 모듈에서 풀 태그 문자열을 검색하는 방법으로 찾을 수 있다.
kd> !for_each_module s -a @#Base @#End BaDr
936fc159 42 61 44 72 83 c0 02 50-57 ff d3 8b f8 85 ff 74 BaDr...PW......t
936fc19e 42 61 44 72 57 ff 15 18-f0 6f 93 8b 45 08 8d 70 BaDrW....o..E..p
... ...
몇 개의 결과가 확인된다. 앞서 lmva 명령을 사용하면 어떤 모듈 주소 영역인지 확인 가능하다고 배웠다. 제일 먼저 출력된 936fc159 주소가 어떤 모듈인지 확인해보자.
kd> lmva 936fc159
Browse full module list
start end module name
936fb000 93746000 BadDrv (deferred)
Image path: \??\C:\Windows\system32\drivers\BadDrv.SYS
Image name: BadDrv.SYS
Browse all global symbols functions data
Timestamp: Fri Feb 07 09:42:37 2014 (52F42BFD)
CheckSum: 000139FD
ImageSize: 0004B000
Translations:
0000.04b0 0000.04e4 0409.04b0 0409.04e4
범인은 BadDrv 모듈이었다. BadDrv 모듈에서 BaDr 풀 태그로 할당된 문자열 버퍼를 할당된 크기 이상으로 사용해서 커널 메모리 영역을 손상시킨 것으로 보인다.
BadDrv 모듈에서 문제의 문자열을 처리하는 곳을 찾아 버그를 수정해주면 이번 문제는 해결될 것이다.
문제 발생 위치는 분석하기 까다로운 곳이었지만 다행히도 메모리 손상 범위나 유형이 복잡하지 않아 원인을 분석할 수 있었다.
이번 예제에서 얻은 교훈은 미리 겁 먹을 필요가 없다는 것이다. 어려워 보이더라도 분석하는 것을 두려워하지 말자.
'Dump Analysis' 카테고리의 다른 글
| [0xC5] 해제 리스트 손상 (0) | 2018.07.19 |
|---|---|
| [0xC5] 풀 헤더 손상 (0) | 2018.07.16 |
| [0x50] 해제된 핸들 (0) | 2018.07.09 |
| [0x50] 숨겨진 콜 스택 (0) | 2018.07.07 |
| [0x50] UNICODE_STRING (0) | 2018.07.05 |
이번 덤프 역시 BugCheck 0x50다. 앞서 덤프와 같이 0x50 은 대부분 다른 모듈이 메모리를 손상시켰거나 정말 유효하지 않은 메모리나 해제된 메모리를 접근할 때 주로 발생한다. 원인에 따라 분석이 불가능한 경우도 많다.
이번에는 동기화와 관련된 주제이므로 약간 어려울 수 있다. 심호흡 한 번하고 차분하게 시작해보자.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: bad0b154, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8058c7b4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000002, (reserved)
Debugging Details:
------------------
DUMP_CLASS: 1
DUMP_QUALIFIER: 401
BUILD_VERSION_STRING: 2600.xpsp_sp3_gdr.120504-1619
SYSTEM_MANUFACTURER: SAMSUNG ELECTRONICS CO., LTD.
SYSTEM_PRODUCT_NAME: 400B4B/400B5B/200B4B/200B5B
SYSTEM_SKU: To be filled by O.E.M.
SYSTEM_VERSION: 04VC
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 04VC.M014.20110811.LDG
BIOS_DATE: 08/11/2011
BASEBOARD_MANUFACTURER: SAMSUNG ELECTRONICS CO., LTD.
BASEBOARD_PRODUCT: 400B4B/400B5B/200B4B/200B5B
BASEBOARD_VERSION: 04VC
DUMP_TYPE: 1
BUGCHECK_P1: ffffffffbad0b154
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff8058c7b4
BUGCHECK_P4: 2
READ_ADDRESS: bad0b154
FAULTING_IP:
nt!ObQueryNameString+9b
8058c7b4 8b88a4000000 mov ecx,dword ptr [eax+0A4h]
MM_INTERNAL_CODE: 2
CPU_COUNT: 4
CPU_MHZ: 9be
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 2a
CPU_STEPPING: 7
CPU_MICROCODE: 6,2a,7,0 (F,M,S,R) SIG: 1A'00000000 (cache) 1A'00000000 (init)
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: EXCEL.EXE
ANALYSIS_SESSION_HOST: PAUL-PC
ANALYSIS_SESSION_TIME: 11-01-2017 11:28:27.0997
ANALYSIS_VERSION: 10.0.10575.567 amd64fre
TRAP_FRAME: a3dd1a04 -- (.trap 0xffffffffa3dd1a04)
ErrCode = 00000000
eax=bad0b0b0 ebx=00000000 ecx=00000000 edx=868edd44 esi=00000000 edi=868edd48
eip=8058c7b4 esp=a3dd1a78 ebp=a3dd1b2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObQueryNameString+0x9b:
8058c7b4 8b88a4000000 mov ecx,dword ptr [eax+0A4h] ds:0023:bad0b154=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 8052b198 to 805396c2
STACK_TEXT:
a3dd199c 8052b198 00000050 bad0b154 00000000 nt!KeBugCheckEx+0x1b
a3dd19ec 804e2956 00000000 bad0b154 00000000 nt!MmAccessFault+0x77e
a3dd19ec 8058c7b4 00000000 bad0b154 00000000 nt!KiTrap0E+0xd0
a3dd1b2c f76487ed 868edd60 86410000 00007fff nt!ObQueryNameString+0x9b
a3dd1b7c f7649841 868edd60 00000000 8639f018 BadDrv+0x17ed
a3dd1bc0 a6728f9c 000009b0 00000000 a3dd1be0 BadDrv+0x2841
a3dd1c00 a672900b 000009b0 a3dd1d64 a50a9740 HookDrv+0x6f9c
a3dd1d58 804df99f 000009b0 00000000 7c93e514 HookDrv+0x700b
a3dd1d58 7c93e514 000009b0 00000000 7c93e514 nt!KiFastCallEntry+0xfc
00000000 00000000 00000000 00000000 00000000 0x7c93e514
STACK_COMMAND: kb
THREAD_SHA1_HASH_MOD_FUNC: 662e78c74f8e63f10fbd8043327f172f7b75bbdc
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: c46449496b9268570a50343287cb531d6153a414
THREAD_SHA1_HASH_MOD: 5ecdf531ba7867e0fd5f6dd6366341b3e5123821
FOLLOWUP_IP:
BadDrv+17ed
f76487ed 85c0 test eax,eax
FAULT_INSTR_CODE: 4d7cc085
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: BadDrv+17ed
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: BadDrv
IMAGE_NAME: BadDrv.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4bb921b6
FAILURE_BUCKET_ID: 0x50_BADMEMREF_BadDrv+17ed
BUCKET_ID: 0x50_BADMEMREF_BadDrv+17ed
PRIMARY_PROBLEM_CLASS: 0x50_BADMEMREF_BadDrv+17ed
TARGET_TIME: 2012-07-13T08:54:52.000Z
OSBUILD: 2600
OSSERVICEPACK: 3000
SERVICEPACK_NUMBER: 3
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x86
OSNAME: Windows XP
OSEDITION: Windows XP WinNt (Service Pack 3) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2012-05-04 22:16:02
BUILDOSVER_STR: 5.1.2600.xpsp_sp3_gdr.120504-1619
ANALYSIS_SESSION_ELAPSED_TIME: 8b2
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0x50_badmemref_BadDrv+17ed
FAILURE_ID_HASH: {aea5e7cf-9e2c-84a6-3525-f1fe4a8eaf29}
Followup: MachineOwner
---------
BugCode 의 파라미터 정보를 보면 다음과 같다.
Arg1: bad0b154, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 8058c7b4, If non-zero, the instruction address which referenced the bad memory
address.
Arg1을 보면 bad0b154 메모리를 참조하는 중에 문제가 발생했는데, Arg2 를 보면 읽기 동작 중 문제가 발생했다고 한다. Arg3에는 문제가 발생한 코드 위치인 8058c7b4 가 담겨 있다.
물론 이것만으로는 더 알 수 없으니 실제 문제가 발생한 부분을 자세히 확인해야 한다.
항상 분석의 시작은 실제 문제가 발생한 부분부터 임을 명심하자.
.trap 명령으로 문제가 발생한 부분을 확인해보자.
kd> .trap 0xffffffffa3dd1a04
ErrCode = 00000000
eax=bad0b0b0 ebx=00000000 ecx=00000000 edx=868edd44 esi=00000000 edi=868edd48
eip=8058c7b4 esp=a3dd1a78 ebp=a3dd1b2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObQueryNameString+0x9b:
8058c7b4
8b88a4000000 mov ecx,dword ptr [eax+0A4h]
ds:0023:bad0b154=????????
nt!ObQueryNameString 함수 수행 중에 mov ecx,dword ptr [eax+0A4h] 코드에서 유효하지 않은 메모리인 bad0b154를 접근해서 문제가 발생했다.
kv 명령어로 파라미터를 포함한 콜 스택을 확인해보자.
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 a3dd1b2c f76487ed 868edd60 86410000 00007fff nt!ObQueryNameString+0x9b (FPO: [Non-Fpo])
01 a3dd1b7c f7649841 868edd60 00000000 8639f018 BadDrv+0x17ed
02 a3dd1bc0 a6728f9c 000009b0 00000000 a3dd1be0 BadDrv+0x2841
03 a3dd1c00 a672900b 000009b0 a3dd1d64 a50a9740 HookDrv+0x6f9c
04 a3dd1d58 804df99f 000009b0 00000000 7c93e514 HookDrv+0x700b
05 a3dd1d58 7c93e514 000009b0 00000000 7c93e514 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a3dd1d64)
06 00000000 00000000 00000000 00000000 00000000
0x7c93e514
BadDrv에서 nt 커널의 ObQueryNameString 함수를 호출하다 문제가 발생했다. 보통은 BadDrv에서 해당 함수 호출시 잘못된 파라미터를 넘겨주었을 가능성이 큰 상황이다.
NTSTATUS ObQueryNameString(
_In_ PVOID Object,
_Out_opt_ POBJECT_NAME_INFORMATION ObjectNameInfo,
_In_ ULONG Length,
_Out_ PULONG ReturnLength
);
MSDN에서 검색해본 함수 원형이다. 이 함수는 입력 받은 오브젝트를 이용해서 오브젝트 이름을 얻는 함수다(예를 들어 특정 파일 오브젝트를 전달하면 해당 파일 오브젝트가 가리키는 파일 경로 문자열을 얻는다). 첫 번째 파라미터인 오브젝트가 의심스럽지만 아직 확신할 수 있는 단계는 아니다.
BadDrv에서 ObQueryNameString 함수 호출시 전달한 오브젝트는 868edd60 이다. kv 명령의 Args to Child 첫 번째 값을 봐도 되고 함수 호출 규약을 이해한다면 ebp 레지스터의 +8 한 값을 봐도 알 수 있다.
kd> dd ebp+8 L1
a3dd1b34 868edd60
문제가 발생한 지점이 nt 커널 내부인 ObQueryNameString 함수이므로 이제 해당 함수 안으로 들어가야한다. 미안하지만 더 집중해서 살펴보자.
kd> u nt!ObQueryNameString L25
nt!ObQueryNameString:
8058c731 6898000000 push 98h
8058c736 68a8015080 push offset nt!ObWatchHandles+0xe4 (805001a8)
8058c73b e86387f5ff call nt!_SEH_prolog (804e4ea3)
8058c740 c745d4010000c0 mov dword ptr [ebp-2Ch],0C0000001h
8058c747 8365c800 and dword ptr [ebp-38h],0
8058c74b 8365d800 and dword ptr [ebp-28h],0
8058c74f c645de01 mov byte ptr [ebp-22h],1
8058c753 c645df00 mov byte ptr [ebp-21h],0
8058c757 8b7d08 mov edi,dword ptr [ebp+8] // 4) edi=ebp+8
8058c75a 83c7e8 add edi,0FFFFFFE8h // 3) edi=edi-0n24
8058c75d 897dc0 mov dword ptr [ebp-40h],edi
8058c760 8a470c mov al,byte ptr [edi+0Ch]
8058c763 84c0 test al,al
8058c765 0f8486040000 je nt!ObQueryNameString+0x36 (8058cbf1)
8058c76b 0fb6c0 movzx eax,al
8058c76e 8bdf mov ebx,edi
8058c770 2bd8 sub ebx,eax
8058c772 85db test ebx,ebx
8058c774 0f843c040000 je nt!ObQueryNameString+0x93 (8058cbb6)
8058c77a 8d530c lea edx,[ebx+0Ch]
8058c77d 8b0a mov ecx,dword ptr [edx]
8058c77f 85c9 test ecx,ecx
8058c781 0f841f390000 je nt!ObQueryNameString+0x63 (805900a6)
8058c787 8d4101 lea eax,[ecx+1]
8058c78a 8bf0 mov esi,eax
8058c78c 8bc1 mov eax,ecx
8058c78e f00fb132 lock cmpxchg dword ptr [edx],esi
8058c792 3bc1 cmp eax,ecx
8058c794 0f852c6d0700 jne nt!ObQueryNameString+0x5d (806034c6)
8058c79a b001 mov al,1
8058c79c 84c0 test al,al
8058c79e 0f8412040000 je nt!ObQueryNameString+0x93 (8058cbb6)
8058c7a4 f6420380 test byte ptr [edx+3],80h
8058c7a8 0f85276d0700 jne nt!ObQueryNameString+0x73 (806034d5)
8058c7ae 895de0 mov dword ptr [ebp-20h],ebx
8058c7b1 8b4708 mov eax,dword ptr [edi+8] // 2) edi=868edd48
8058c7b4 8b88a4000000 mov
ecx,dword ptr [eax+0A4h] // 1) eax=bad0b0b0
1)이 문제가 발생한 곳으로 어디에서 eax 에 bad0b0b0 값을 채웠는지 함수 시작 지점부터 찾아봐야 한다.
2)에서 edi + 8 주소의 값을 eax 에 넣는 코드가 있으므로 edi 값을 찾아보자. 다행히 edi 를 덮어쓰는 코드는 없으므로 r 명령으로 확인 가능하다.
kd> r edi
Last set context:
edi=868edd48
2)에서 mov eax,dowrd ptr [edi+8] 명령을 통해 868edd48 + 8 위치의 값을 eax 에 설정했다.
kd> dd 868edd48+8 L1
868edd50 bad0b0b0
값을 참조하는 dword ptr 명령이 사용됐음을 유의하자. 주소가 아닌 값을 참조하는 명령이므로 868edd50 이 아닌 bad0b0b0을 참조한다. 즉 이 값이 eax에 설정된다.
3) 여기서 원래 edi 값에 ffffffe8을 더한 값(add)으로 edi가 설정됐다. ? 명령으로 알기 쉽게 10진수로 변환해보자.
kd> ? ffffffe8
Evaluate
expression: -24 = ffffffe8
아하, edi에 10진수 -24 를 더한 것이니 결국 edi = edi – 18(0n24)이다.
여기서 18은 10진수 24의 16진수 값을 의미한다.
[참고]
WinDbg 에서는 16진수 표현 방식이 기본값이므로 앞에 0x를 붙이지 않고 표기했다. 기본값은 n 명령어로 변경 가능한데 이 경우 16진수 앞에 붙이는 접두사인 0x 는 생략 가능하다. 다른 진수 사용시에는 명시적으로 진수에 맞는 접두사와 함께 사용해야 한다. 자주
혼동되는 부분이기 때문에 유의하자.
- 16진수 : OO / 0xOO (기본값)
- 10진수 0nOO
- 8진수 0tOO
- 2진수 0y00
4) edi는 ebp + 8 값을 가져와 설정한다. 앞서 ebp + 8(첫 번째 파마리터)은 868edd60 였으므로 이를 토대로 재구성해보자.
4) edi = 868edd60 (ebp+8)
3) edi = 868edd60 - 18
2) eax = poi(868edd48+8)
1) ecx = poi(bad0b0b0+a4)
2)와 1) 에서 사용된 poi는 해당 주소의 값을 얻는 명령이다.
<poi 사용 유무에 따른 결과>
kd> dd 868edd48+8 L1
868edd50 bad0b0b0
kd> dd poi(868edd48+8) L1
1) 에서 bad0b0b0 + a4 를 하면 바로 문제가 발생했던 bad0b154 다!
kd> dd bad0b154 L1
bad0b154 ????????
역시나 bad0b154는 유효하지 않은 메모리 값으로 여기를 접근했으므로 문제가 발생한 것이다.
지금까지 확인된 내용을 쉽게 정리해보면 첫 번째 파라미터 값인 868edd60으로 여러 연산(-18, +8, +a4)을 수행하다 bad0b154 값에 접근한 것이 문제의 원인이다. 그런데 왜 이런 알 수 없는 연산을 한 것일까? 감이 좋은 사람이라면 전달된 값이 어떤 구조체이고 해당 구조체의 필드를 참조하는 연산을 수행한 것임을 눈치 챘을 수도 있다. 보통 저런 숫자를 빼거나 더하는 연산은 구조체를 참조하는 코드인 경우가 많다.
여기까지 잘 따라왔다면 정말 훌륭하다. 자부심을 가져도 좋다. 이제부터는 약간의 윈도우 커널 내부 지식을 필요로 하지만 크게 어렵지는 않다.
앞서 ObQueryNameString 함수 원형을 통해 868edd60 값이 커널의 오브젝트 포인터라는 것은 이미 알고 있다. 윈도우는 프로세스, 스레드, 파일 등 대부분의 자원을 커널 오브젝트라는 것으로 관리하는데 이들 오브젝트에는 공통적으로 오브젝트 헤더가 존재한다. 오브젝트 헤더 구조체는 dt _OBJECT_HEADER 명령으로 확인 가능하다.
kd> dt _OBJECT_HEADER 868edd60-18
nt!_OBJECT_HEADER
+0x000 PointerCount : 0
+0x004 HandleCount : 0
+0x004 NextToFree : (null)
+0x008 Type : 0xbad0b0b0 _OBJECT_TYPE
+0x00c NameInfoOffset : 0x10 ''
+0x00d HandleInfoOffset : 0 ''
+0x00e QuotaInfoOffset : 0 ''
+0x00f Flags : 0xa0 ''
+0x010 ObjectCreateInfo : (null)
+0x010 QuotaBlockCharged : (null)
+0x014 SecurityDescriptor : (null)
+0x018 Body : _QUAD
오브젝트 헤더의 +18 한 필드명이 Body 이다. 예상한 대로 868edd60 는 어떤 오브젝트이고 첫 번째 연산인 -18은 오브젝트 헤더 위치를 구하기 위한 것이었다. 어떤 구조체인지 안 이상 다음은 어렵지 않다. 두 번째 연산인 +8은 Type 필드를 가져오기 위한 연산이었고 이를 통해 0xbad0b0b0 값을 얻은 것이다. Body 에는 어떤 오브젝트 포인터든 올 수 있기 때문에 커널은 이 Type 필드를 통해 오브젝트 유형을 판단한다.
WinDbg가 친절하게도 Type 값은 _OBJECT_TYPE 구조체라고 알려준다. Type 값인 0xbad0b0b0을 dt _OBJECT_TYPE 명령으로 확인하면 마지막 연산인 +a4의 의미를 알 수 있다.
kd> dt _OBJECT_TYPE 0xbad0b0b0
nt!_OBJECT_TYPE
+0x000 Mutex : _ERESOURCE
+0x038 TypeList : _LIST_ENTRY
+0x040 Name : _UNICODE_STRING
+0x048 DefaultObject : ????
+0x04c Index : ??
+0x050 TotalNumberOfObjects : ??
+0x054 TotalNumberOfHandles : ??
+0x058 HighWaterNumberOfObjects : ??
+0x05c HighWaterNumberOfHandles : ??
+0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER
+0x0ac Key : ??
+0x0b0
ObjectLocks : [4] _ERESOURCE
0xbad0b0b0 + a4 위치는 TypeInfo 인 0x060과 Key인 0x0ac의 사이다. TypeInfo 내부의 어떤 필드일 것이다. 하지만 Type 값인 bad0b0b0 은 유효한 메모리가 아니어서 구조체 내부 값들이 ?? 로 표시된다. 여기서는 TypeInfo 구조체의 어떤 필드였는지만 알면 되니 문제되지는 않는다.
kd> dt _OBJECT_TYPE_INITIALIZER
nt!_OBJECT_TYPE_INITIALIZER
+0x000 Length : Uint2B
+0x002 UseDefaultObject : UChar
+0x003 CaseInsensitive : UChar
+0x004 InvalidAttributes : Uint4B
+0x008 GenericMapping : _GENERIC_MAPPING
+0x018 ValidAccessMask : Uint4B
+0x01c SecurityRequired : UChar
+0x01d MaintainHandleCount : UChar
+0x01e MaintainTypeList : UChar
+0x020 PoolType : _POOL_TYPE
+0x024 DefaultPagedPoolCharge : Uint4B
+0x028 DefaultNonPagedPoolCharge : Uint4B
+0x02c DumpProcedure : Ptr32 void
+0x030 OpenProcedure : Ptr32 long
+0x034 CloseProcedure : Ptr32 void
+0x038 DeleteProcedure : Ptr32 void
+0x03c ParseProcedure : Ptr32 long
+0x040 SecurityProcedure : Ptr32 long
+0x044 QueryNameProcedure : Ptr32 long
+0x048 OkayToCloseProcedure : Ptr32 unsigned char
a4에서 TypeInfo 시작 위치인 60을 빼면 44가 나온다. 44는 _OBJECT_TYPE_INITIALIZER의 QueryNameProcedure에 해당한다. 이제 문제가 발생한 상황이 명확해지는 것 같다.
4) 오브젝트를 가져 옴 // edi = 868edd60 (ebp+8)
3) 오브젝트 헤더를 구함 // edi = 868edd60 - 18
2) 헤더에서 오브젝트 타입을 구함 // eax = poi(868edd48+8)
1) 오브젝트 타입의 TypeInfo에서 QueryNameProcedure를 참조 // ecx = poi(bad0b0b0+a4)
문제가 발생한 원인이 밝혀졌다. ObQueryNameString 함수에서 입력 받은 오브젝트로 QueryNameProcedure 함수 포인터를 구하려다 2) 시점에 오브젝트 타입 값이 유효하지 않은 값이라 1) 에서 문제가 발생했다.
이쯤에서 잠시 쉬는 것이 좋겠다. 장시간 분석은 정신 건강에 매우 해롭다.
거의 분석이 끝났지만 왜 이런 상황이 발생했는지는 아직 밝혀지지 않았다.
자! 휴식이 끝났으면 다음 3가지 시나리오를 살펴 보자.
1. 외부에서 이미 잘못된 값을 BadDrv 에 전달했고 BadDrv 는 그대로 ObQueryNameString 함수에 전달했다.
2. 외부에서 정상적인 값을 BadDrv 에 전달했지만 BadDrv 에서 잘못된 값으로 바꿔 ObQueryNameString 함수에 전달했다.
3. 외부에서 정상적인 값을 BadDrv 에 전달했고 BadDrv 도 그대로 ObQueryNameString 함수에 전달했지만 중간에 잘못된 값으로 바뀌었다.
어떤 시나리오가 마음에 드는가? 분석할 때 가장 경계해야 하는 부분은 결론을 정해 놓고 분석에 임하는 것이다. 그럴 경우 자신이 보고 싶은 부분만 보기 때문에 진실을 놓칠 우려가 있다. 그렇기에 나는 이 3가지 시나리오를 모두 검증해볼 것이다.
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
# ChildEBP RetAddr Args to Child
00 a3dd1b2c f76487ed 868edd60 86410000 00007fff nt!ObQueryNameString+0x9b (FPO: [Non-Fpo]) // 4) nt 커널 영역
01 a3dd1b7c f7649841 868edd60 00000000 8639f018 BadDrv+0x17ed // 3) BadDrv 영역
02 a3dd1bc0 a6728f9c 000009b0 00000000 a3dd1be0 BadDrv+0x2841 // 2) BadDrv 영역
03 a3dd1c00 a672900b 000009b0 a3dd1d64 a50a9740 HookDrv+0x6f9c // 1) 여기부터 아래로 외부 영역
04 a3dd1d58 804df99f 000009b0 00000000 7c93e514 HookDrv+0x700b
05 a3dd1d58 7c93e514 000009b0 00000000 7c93e514 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a3dd1d64)
06 00000000 00000000 00000000 00000000 00000000
0x7c93e514
3)번 콜 스택의 첫 번째 파라미터인 868edd60 는 앞서 분석에서 확인된 오브젝트다. 외부 영역인 1)번과 2)번까지 보이는 9b0 값이 3)번에서 오브젝트로 바뀌었으므로 9b0 값을 먼저 확인해야 한다.
3)번의 BadDrv+0x17ed 위치는 ObQueryNameString 함수를 호출한 위치다. BadDrv+0x17ed 함수의 시작 부분을 확인하려면 2)번에서 마지막 함수를 부른 위치를 확인하면 된다.
ub 명령을 통해 2)번 위치에서 함수 호출하는 부분을 살펴보자.
kd> ub BadDrv+0x2841
BadDrv+0x2825:
f7649825 b89a0000c0 mov eax,0C000009Ah
f764982a e9f3000000 jmp BadDrv+0x2922 (f7649922)
f764982f 8d7e18 lea edi,[esi+18h]
f7649832 66c7070100 mov word ptr [edi],1
f7649837 57 push edi
f7649838 53 push ebx
f7649839 ff7508 push dword ptr [ebp+8]
f764983c e8a7eeffff call
BadDrv+0x16e8 (f76486e8)
BadDrv+0x16e8 이 BadDrv+0x17ed 주소가 수행된 함수의 시작 위치다. 시작 위치부터 ObQueryNameString 함수가 호출된 부분까지 확인해보자.
kd> u BadDrv+0x16e8 L4d
BadDrv+0x16e8:
f76486e8 6a18 push 18h
f76486ea 68e8d164f7 push offset BadDrv+0x61e8 (f764d1e8)
f76486ef e8cc3a0000 call BadDrv+0x51c0 (f764c1c0)
f76486f4 33ff xor edi,edi
f76486f6 33f6 xor esi,esi
f76486f8 397d08 cmp dword ptr [ebp+8],edi
f76486fb 0f844f010000 je BadDrv+0x1850 (f7648850)
f7648701 7d0e jge BadDrv+0x1711 (f7648711)
f7648703 ff155cd064f7 call dword ptr [BadDrv+0x605c (f764d05c)]
f7648709 84c0 test al,al
f764870b 0f853f010000 jne BadDrv+0x1850 (f7648850)
f7648711 57 push edi
f7648712 8d45e0 lea eax,[ebp-20h]
f7648715 50 push eax
f7648716 57 push edi
f7648717 57 push edi
f7648718 57 push edi
f7648719 ff7508 push dword ptr [ebp+8] // 1) ebp+8 = Handle
f764871c ff1558d064f7 call dword ptr [BadDrv+0x6058 (f764d058)] // 2) ObReferenceObjectByHandle 함수 호출
f7648722 85c0 test eax,eax
f7648724 0f8526010000 jne BadDrv+0x1850 (f7648850)
f764872a 8b4de0 mov ecx,dword ptr [ebp-20h]
f764872d 8bd9 mov ebx,ecx
f764872f 895d08 mov dword ptr [ebp+8],ebx // 3) ebp+8 = Object로 변경
f7648732 3bcf cmp ecx,edi
f7648734 0f8416010000 je BadDrv+0x1850 (f7648850)
f764873a ff1564d064f7 call dword ptr [BadDrv+0x6064 (f764d064)] // 4) ObfDereferenceObject 함수 호출
f7648740 ff1538d064f7 call dword ptr [BadDrv+0x6038 (f764d038)]
f7648746 c1eb02 shr ebx,2
f7648749 83e37f and ebx,7Fh
f764874c 8bc3 mov eax,ebx
f764874e 6bc038 imul eax,eax,38h
f7648751 8db880ef64f7 lea edi,BadDrv+0x7f80 (f764ef80)[eax]
f7648757 6a01 push 1
f7648759 57 push edi
f764875a ff1534d064f7 call dword ptr [BadDrv+0x6034 (f764d034)]
f7648760 8b049d000c65f7 mov eax,dword ptr BadDrv+0x9c00 (f7650c00)[ebx*4]
f7648767 eb0a jmp BadDrv+0x1773 (f7648773)
f7648769 8b4d08 mov ecx,dword ptr [ebp+8]
f764876c 3908 cmp dword ptr [eax],ecx
f764876e 7407 je BadDrv+0x1777 (f7648777)
f7648770 8b4004 mov eax,dword ptr [eax+4]
f7648773 85c0 test eax,eax
f7648775 75f2 jne BadDrv+0x1769 (f7648769)
f7648777 85c0 test eax,eax
f7648779 742a je BadDrv+0x17a5 (f76487a5)
f764877b 8b7008 mov esi,dword ptr [eax+8]
f764877e 8d0c36 lea ecx,[esi+esi]
f7648781 51 push ecx
f7648782 83c00e add eax,0Eh
f7648785 50 push eax
f7648786 8b5d10 mov ebx,dword ptr [ebp+10h]
f7648789 53 push ebx
f764878a e89b390000 call BadDrv+0x512a (f764c12a)
f764878f 83c40c add esp,0Ch
f7648792 8bcf mov ecx,edi
f7648794 ff152cd064f7 call dword ptr [BadDrv+0x602c (f764d02c)]
f764879a ff1528d064f7 call dword ptr [BadDrv+0x6028 (f764d028)]
f76487a0 e995000000 jmp BadDrv+0x183a (f764883a)
f76487a5 8bcf mov ecx,edi
f76487a7 ff152cd064f7 call dword ptr [BadDrv+0x602c (f764d02c)]
f76487ad ff1528d064f7 call dword ptr [BadDrv+0x6028 (f764d028)]
f76487b3 ff35e0ee64f7 push dword ptr [BadDrv+0x7ee0 (f764eee0)]
f76487b9 ff35e4ee64f7 push dword ptr [BadDrv+0x7ee4 (f764eee4)]
f76487bf 6a00 push 0
f76487c1 ff150cd064f7 call dword ptr [BadDrv+0x600c (f764d00c)]
f76487c7 8bf8 mov edi,eax
f76487c9 85ff test edi,edi
f76487cb 0f8431020000 je BadDrv+0x1a02 (f7648a02)
f76487d1 662137 and word ptr [edi],si
f76487d4 66c74702feff mov word ptr [edi+2],0FFFEh
f76487da 8d45e4 lea eax,[ebp-1Ch]
f76487dd 50 push eax
f76487de 68ff7f0000 push 7FFFh
f76487e3 57 push edi
f76487e4 ff7508 push dword ptr [ebp+8] // 5) ebp+8 = Object
f76487e7
ff1560d064f7 call dword ptr [BadDrv+0x6060 (f764d060)] // 6) nt!ObQueryNameString 함수 호출
1)번에서 첫 번째 파라미터인 ebp+8 을 push 하고 2)번에서 ObReferenceObjectByHandle 함수를 호출하고 있다. ObReferenceObjectByHandle 함수의 원형은 다음과 같다.
NTSTATUS ObReferenceObjectByHandle(
_In_ HANDLE Handle,
_In_ ACCESS_MASK DesiredAccess,
_In_opt_ POBJECT_TYPE ObjectType,
_In_ KPROCESSOR_MODE AccessMode,
_Out_ PVOID *Object,
_Out_opt_ POBJECT_HANDLE_INFORMATION HandleInformation
);
첫 번째 파라미터는 Handle 이다. 즉 9b0 값은 Handle 임을 알 수 있다.
3)번에서는 ebp + 8 값을 ObReferenceObjectByHandle 함수를 호출해서 리턴 받은 Object로 변경한다. 5), 6)번에서는 이 Object로 문제 발생 함수인 ObQueryNameString을 호출한다.
ObReferenceObjectByHandle 함수는 Handle을 가지고 Handle이 가리키는 커널 오브젝트를 얻는 함수다. 참조에 성공하면 대상 커널 오브젝트의 참조 카운트는 1 증가하게 된다.
어쨌든 9b0 값을 !handle 명령으로 확인해보자.
kd> !handle 9b0
Failed to get VAD root
PROCESS 89863020 SessionId: 0 Cid: 12b0 Peb: 7ffdf000 ParentCid: 0e6c
DirBase: 23041000 ObjectTable: e10f9978 HandleCount: 623.
Image: EXCEL.EXE
Handle table at e10f9978 with 623 entries in use
09b0: free handle,
Entry address e1225360, Next Entry 000009d0
역시 9b0은 소유자인 EXCEL.EXE 프로세스의 핸들 테이블에서 해제된 핸들(free handle)이라고 나온다. 해제되어 사용할 수 없는 핸들이라는 의미다. 여기서 1번 시나리오 대로 외부에서 잘못된 핸들을 BadDrv에 전달했군! 이라고 생각했다면 성급한 판단이다.
ObReferenceObjectByHandle 함수 호출이 성공해서 Object인 868edd60 값을 얻었음을 잊지 말자. 함수 호출이 성공했다는 것은 당시에는 유효한 핸들이었다는 의미다. 만약 해제되거나 유효하지 않은 핸들이었다면 ObReferenceObjectByHandle 함수 호출시 STASTUS_INVALID_HANDLE 오류가 리턴되었을 것이고 Object 또한 NULL 이 반환되었을 것이다.
2)번에서 ObReferenceObjectByHandle 함수 호출이 성공했으므로 1번 시나리오는 가능성이 없다.
4)번에서는 ObfDereferenceObject 함수로 ObReferenceObjectByHandle 를 통해 증가시킨 참조 카운트를 다시 원래대로 내려주고 있다.
이후 6)번 ObQueryNameString 함수 호출 부분까지는 Object 값을 변경하는 행위가 보이지 않는다.
“BadDrv는 외부에서 정상적인 Handle 값인 9b0을 받았고 이를 통해 Object 값인 868edd60를 얻어 ObQueryNameString 함수에 전달했다”고 판단하는 데 무리가 없어 보인다. 2번 시나리오인 BadDrv가 잘못된 Object를 ObQueryNameString 에 전달했을 가능성도 낮다.
혹시 분석 초반에 봤던 오브젝트 헤더의 이상한 값 0xbad0b0b0을 기억하는가?
kd> dt _OBJECT_HEADER 868edd60-18
nt!_OBJECT_HEADER
... ...
+0x008 Type : 0xbad0b0b0 _OBJECT_TYPE
... ...
+0x018
Body : _QUAD
Type 에 저장되어 있는 0xbad0b0b0 값은 실은 Object 가 명확하게 해제될 때 커널 내부적으로 기록하는 상태 값이다.
이 부분을 설명하기 위해 현재 분석하고 있는 덤프가 아닌 가상 머신에서 라이브 디버깅을 통해 커널이 0xbad0b0b0 값을 설정하는 순간을 확인해봤다. 분석 중인 덤프에서 확인한 내용이 아니므로 혼동하지 말자.
<라이브 디버깅 환경에서 확인한 0xbad0b0b0 값을 설정하는 부분>
kd> kc
#
00 nt!ObpFreeObject+0x16c
01 nt!ObpRemoveObjectRoutine+0xe8
02 nt!ObfDereferenceObject+0x4c
03 nt!ObpCloseHandleTableEntry+0x155
04 nt!ObpCloseHandle+0x87
05 nt!NtClose+0x1d
06 nt!KiFastCallEntry+0xfc
kd> u nt!ObpFreeObject+a1
nt!ObpFreeObject+0x12f:
8056f68f 3bc3 cmp eax,ebx
8056f691 5f pop edi
8056f692 0f8562680000 jne nt!ObpFreeObject+0x134 (80575efa)
8056f698 8b45f4 mov eax,dword ptr [ebp-0Ch]
8056f69b 3bc3 cmp eax,ebx
8056f69d 0f850f0c0000 jne nt!ObpFreeObject+0x14e (805702b2)
8056f6a3 8b45f0 mov eax,dword ptr [ebp-10h]
8056f6a6 c74608b0b0d0ba mov
dword ptr [esi+8],0BAD0B0B0h
ObFreeObject 라는 함수에서 Object가 해제될 시 오브젝트 헤더의 Type(+8) 위치에 정확하게 bad0b0b0이라는 값을 기록해주고 있다.
따라서 bad0b0b0 값은 해당 Object가 해제되었다는 명백한 증거다.
다시 예제 덤프로 돌아와보자. !handle 정보와 오브젝트 헤더 정보를 통해 Handle 이 해제된 것은 명확하다. 하지만 해제 시점이 애매하다.
이제부터 설명은 덤프에서 확인이 어려운 부분도 포함되어 있다. 나는 3번 시나리오인 “정상적인 Object 값을 ObQueryNameString 함수에 전달했지만 중간에 해제됐을 가능성”이 가장 높다고 본다. 여기에는 동기화 문제가 숨어 있다.
1) 외부(EXCEL) Thread 1에서 정상적인 Handle을 BadDrv에 전달
2) BadDrv에서 전달된 Handle로 ObReferenceObjectByHandle로 Object 획득(참조 카운트 +1)
3) BadDrv에서 ObfDereferenceObject로 Object 참조 카운트 복원(참조 카운트 -1)
a) 외부(EXCEL) Thread 2에서 Handle 해제?
4) BadDrv에서 Object를 이용하여 nt 커널의 ObQueryNameString 함수 호출
b) 외부(EXCEL) Thread 2에서 Handle 해제?
5) ObQueryNameString 함수 내부에서 잘못된 메모리 접근
아마 3)~5)번 사이 a)나 b) 시점에 Handle 해제가 발생했을 것이다. 이렇게 특정한 이유는 3)번에서 ObfDereferenceObject로 Object의 참조 카운트를 돌려놨기 때문이다. 이로 인해 해당 Handle은 언제든 해제될 수 있는 상태가 되었다.
커널에서 Object를 가지고 작업을 수행할 때는 흔히 ObReferenceObjectByHandle 함수를 통해 참조 카운트를 증가시키고 수행한다. 참조 카운트가 증가된 상태에서는 오브젝트가 해제되지 않기 때문이다. 작업이 완료되면 DereferenceObject 류 함수를 통해 참조 카운트를 감소시켜 해제 가능한 상태로 돌려 놓는다. 만약 참조 카운트를 증가시키지 않고 작업할 경우 중간에 작업 중인 오브젝트가 해제되어 문제가 발생할 수 있다.
이렇게 Handle을 Object로 안전하지 않게 참조할 경우 다른 Thread에 의해 해당 Handle 이 해제되면, 골치 아픈 동기화 문제가 발생할 수 있다. 이런 동기화 문제는 이번처럼 덤프 상에서는 결과만 보이므로 제대로 원인이 확인되지 않는 경우가 많다. 하지만 실제로 심심치 않게 발생한다.
드라이버 개발 시 뭔가 Object로 참조해서 사용할 경우 참조 카운트 해제는 Object 사용이 다 끝난 후에 하는 것이 원칙이다.
만약 ObfDereferenceObject를 ObQueryNameString 다음에 했다면 Object 의 참조 카운트가 증가된 상태라 설령 다른 Thread 에서 중간에 Handle 을 해제하더라도 Object가 해제되지 않는다. Object는 ObfDereferenceObject가 호출될 때 비로서 참조 카운트가 내려가면서 해제 가능한 상태가 된다. 그러므로 ObQueryNameString에서 문제도 발생하지 않는다.
현업에서 많은 덤프를 분석하다 보면 이렇게 겉으로만 봐서는 논리적으로 설명이 안 되는 상황이 있는데, 동기화 이슈 관점에서 보면 의외로 답을 찾는 경우가 많았다. 역시나 덤프 내면을 볼 수 있는 상상력이 조금은 필요한 것 같다.
'Dump Analysis' 카테고리의 다른 글
| [0xC5] 풀 헤더 손상 (0) | 2018.07.16 |
|---|---|
| [0x1A] 페이지 손상 (0) | 2018.07.12 |
| [0x50] 숨겨진 콜 스택 (0) | 2018.07.07 |
| [0x50] UNICODE_STRING (0) | 2018.07.05 |
| 필터매니저(fltmgr.sys) 버그? DRAINING ZOMBIED 와 DOE_UNLOAD_PENDING (0) | 2015.01.22 |
