Tag Archive for 'stack overflow'

USB Interrupt 전송 Drop에 의한 Stack Overflow

Published
by
admin
on 7월 15, 2009
in Debugging Windows
. 0 Comments

3: kd> !analyze -v
*****************************************
*                        Bugcheck Analysis       
*                                                           
*****************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: f7727d70
Arg3: 00000000
Arg4: 00000000

Debugging Details:
——————

PEB is paged out (Peb.Ldr = 7ffdc00c).  Type “.hh dbgerr001″ for details
PEB is paged out (Peb.Ldr = 7ffdc00c).  Type “.hh dbgerr001″ for details

BUGCHECK_STR:  0×7f_8

TSS:  00000028 — (.tss 0×28)
eax=0000bb40 ebx=b3c91454 ecx=00000000 edx=00000001 esi=b3c91400 edi=0000002d
eip=804e90d6 esp=b3c90f98 ebp=b3c91024 iopl=0         nv up di ng nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010092
nt!KeContextFromKframes+0×10:
804e90d6 53              push    ebx
Resetting default scope

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

PROCESS_NAME:  app.exe

EXCEPTION_RECORD:  b3c91400 — (.exr 0xffffffffb3c91400)
ExceptionAddress: 80503a3f (nt!DebugService+0×0000001b)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 3
   Parameter[0]: 00000001
   Parameter[1]: b3c91530
   Parameter[2]: 0000002d

TRAP_FRAME:  b3c91454 — (.trap 0xffffffffb3c91454)
ErrCode = 00000000
eax=00000001 ebx=ffffffff ecx=b3c91530 edx=0000002d esi=0000002d edi=00000000
eip=80503a40 esp=b3c914c8 ebp=b3c914dc iopl=0         nv up ei pl nz ac pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000217
nt!DebugService+0×1c:
80503a40 5b              pop     ebx
Resetting default scope

LAST_CONTROL_TRANSFER:  from 804fbcef to 804e90d6

STACK_TEXT: 
b3c91024 804fbcef b3c91454 00000000 b3c910fc nt!KeContextFromKframes+0×10
b3c913e4 804e0403 b3c91400 00000000 b3c91454 nt!KiDispatchException+0×82
b3c9144c 804e0b5c b3c914dc 80503a3f badb0d00 nt!CommonDispatchException+0×4d
b3c9144c 80503a40 b3c914dc 80503a3f badb0d00 nt!KiTrap03+0xae
b3c914dc 80503a6f 00000001 b3c91530 0000002d nt!DebugService+0×1c
b3c914f8 80503e97 b3c91518 ffffffff 00000000 nt!DebugPrint+0×1c
b3c9174c 80503ee3 80503ee6 ffffffff 00000000 nt!vDbgPrintExWithPrefix+0×101
b3c91768 b2e8aac0 b2e93360 b2e93320 8550a3d8 nt!DbgPrint+0×1a
WARNING: Stack unwind information not available. Following frames may be wrong.
b3c91788 b2e8a98e b2e93320 89e0cd00 8643bde0 Driver4+0×14ac0
b3c9179c b2e8b9d6 8643bde0 89e0cd00 87dca810 Driver4+0×1498e
b3c917c8 b2e8d382 89e0cd00 8643bde0 8643bebc Driver4+0×159d6
b3c91a08 b2e7baf8 89e0cd00 8643bde0 b3c91a30 Driver4+0×17382
b3c91a58 b4487c29 89e0cd00 8643bde0 87dbe000 Driver4+0×5af8
b3c91a84 b4486d87 89e0cd00 8643bde0 00000000 Driver3+0×7c29
b3c91aa4 b5765796 00000000 87dca810 8a6ccc50 Driver3+0×6d87
b3c91ac0 b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c91b08 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c91b48 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c91b78 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c91b8c bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c91ba0 bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c91bc4 bac60d70 8643bde0 b3c91be4 00000001 Driver2+0×18ac
b3c91bdc 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c91c00 b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c91c1c b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c91c64 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c91ca4 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c91cd4 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c91ce8 bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c91cfc bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c91d20 bac60d70 8643bde0 b3c91d40 00000001 Driver2+0×18ac
b3c91d38 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c91d5c b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c91d78 b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c91dc0 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c91e00 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c91e30 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c91e44 bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c91e58 bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c91e7c bac60d70 8643bde0 b3c91e9c 00000001 Driver2+0×18ac
b3c91e94 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c91eb8 b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c91ed4 b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c91f1c b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c91f5c 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c91f8c b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c91fa0 bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c91fb4 bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c91fd8 bac60d70 8643bde0 b3c91ff8 00000001 Driver2+0×18ac
b3c91ff0 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c92014 b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c92030 b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c92078 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c920b8 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c920e8 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c920fc bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c92110 bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c92134 bac60d70 8643bde0 b3c92154 00000001 Driver2+0×18ac
b3c9214c 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c92170 b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c9218c b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c921d4 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c92214 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c92244 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c92258 bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c9226c bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
b3c92290 bac60d70 8643bde0 b3c922b0 00000001 Driver2+0×18ac
b3c922a8 804e33d9 00000000 8643bde0 87dca810 Driver2+0×1d70
b3c922cc b5765796 00000000 87dca810 8a6ccc50 nt!IopfCallDriver+0×31
b3c922e8 b5766176 89df432c 00000000 8a6ccc50 Driver1+0×9796
b3c92330 b5765c28 89df432c 00000001 87dca801 Driver1+0xa176
b3c92370 804e38ff 00000000 8643bde0 00000000 Driver1+0×9c28
b3c923a0 b4486dd8 8643bde0 89e65958 c0000001 nt!IopfCompleteRequest+0xa2
b3c923b4 bac601fb 8643bde0 8a3d8cf4 c0000056 Driver3+0×6dd8
b3c923c8 bac608ac 8643bde0 89df432c 8a3d8cf4 Driver2+0×11fb
STACK_COMMAND:  .tss 0×28 ; kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    804e33b2-804e33b7  6 bytes - nt!IopfCallDriver
 [ fe 4a 23 8a 42 23:e9 39 39 fa 33 cc ]
    …생략
175 errors : !nt (804e33b2-80507724)

MODULE_NAME: Driver3

IMAGE_NAME:  Driver3.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5c23df

FOLLOWUP_NAME:  MachineOwner

MEMORY_CORRUPTOR:  PATCH_Driver3

FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_PATCH_Driver3

BUCKET_ID:  MEMORY_CORRUPTION_PATCH_Driver3

Followup: MachineOwner
———
보시는 그대로 Stack Overflow 입니다.( Stack Overflow 분석은 이곳을 참고하세요.) 특징적인 부분은 IofCallDriver를 후킹했다는 점입니다.
그럼 왜 Stack Overflow가 발생한것인가 한번 찾아보죠.

이러한 Stack의 경우 반복적인 부분을 유심히 관찰하는게 정말 중요합니다. Driver3+0×6dd8에서 호출한 IopfCompleteRequest 호출도중 Driver1+0×9c28가 호출됐다는 점에서 Completion Routine임을 추정할 수 있습니다. 문제는 이 Completion Routine은 다시 IopfCallDriver( Hooking Function이아닌 그냥 일반 호출 처럼 보이는 이유는 Bypass 되었다고 가정하시면 됩니다. Stack 구성에 대한 이야기는 다음에 또 얘기 하도록 하겠습니다.)를 호출한다는 점입니다. 그렇다면 왜 이렇게 구성이 되었을까?

IopfCallDriver가 후킹되었고 그 내부에서 IopfCompleteRequest를 호출했다는 점을 볼때 해당 I/O을 Drop 하는 목적임을 알 수 있습니다. 즉 다음 Stack으로 해당 I/O를 전달하지 않게 하기 위한 것이지요. 위의 Stack을 볼때 해당 I/O가 Drop 당했을 경우 또는 원하는 Data를 얻지 못할 경우를 대비해 Driver1 드라이버의 개발자는 다시 Irp를 전달하도록 드라이버를 구성하였음을 알 수 있습니다. 이러한 현상이 반복되면서 Stack Overflow는 발생하게 됩니다.

IopfCallDriver를 Hooking한 이유는 I/O Drop이 목적이라면 Driver1 드라이버는 왜 Completion Routine에서 Irp재 전송하는가 !!
그 해답은 Usb Data 전송 방식에 있습니다.

USB에는 크게 4가지 전송방식이 있습니다.

- Control
- Bulk
- Interrupt
- Isochronous

여기서 사용한 방식, 즉 Irp에 Urb를 담아 I/O를 전달하고 그 I/O가 비동기 적으로 Completion 될때 데이터를 받아오고 그리고 그 Data 값에 따라서 Completion Routine에서 재요청 또는 완료를 시도하는 방식, 바로 Bulk Or Interrupt 방식입니다.

아래 코드를 보면 Urb에 Header에 URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER( 0×00000009 ) 값을 넣어주는 코드를 확인 할 수 있습니다.
3: kd> ub Driver1+0×9796 L30
Driver1+0×96df:
b57656df b89a0000c0      mov     eax,0C000009Ah
b57656e4 e9c0000000      jmp     Driver1+0×97a9 (b57657a9)
b57656e9 8b45fc          mov     eax,dword ptr [ebp-4]
b57656ec 89868c000000    mov     dword ptr [esi+8Ch],eax
b57656f2 8b868c000000    mov     eax,dword ptr [esi+8Ch]
b57656f8 33d2            xor     edx,edx
b57656fa f775fc          div     eax,dword ptr [ebp-4]
b57656fd 0faf45fc        imul    eax,dword ptr [ebp-4]
b5765701 89868c000000    mov     dword ptr [esi+8Ch],eax
b5765707 8b462c          mov     eax,dword ptr [esi+2Ch]
b576570a 6a01            push    1
b576570c 66c740020900    mov     word ptr [eax+2],9
b5765712 8b462c          mov     eax,dword ptr [esi+2Ch]
b5765715 66c7004800      mov     word ptr [eax],48h
b576571a 8b87b8000000    mov     eax,dword ptr [edi+0B8h]
b5765720 8b4e2c          mov     ecx,dword ptr [esi+2Ch]
b5765723 8b440318        mov     eax,dword ptr [ebx+eax+18h]
b5765727 5b              pop     ebx
b5765728 894110          mov     dword ptr [ecx+10h],eax
b576572b 8b462c          mov     eax,dword ptr [esi+2Ch]
b576572e 8b8e8c000000    mov     ecx,dword ptr [esi+8Ch]
b5765734 68a05976b5      push    offset Driver1+0×99a0 (b57659a0)
b5765739 894818          mov     dword ptr [eax+18h],ecx
b576573c 8b462c          mov     eax,dword ptr [esi+2Ch]
b576573f 83602000        and     dword ptr [eax+20h],0
b5765743 8b462c          mov     eax,dword ptr [esi+2Ch]
b5765746 8b8e94000000    mov     ecx,dword ptr [esi+94h]
b576574c 89481c          mov     dword ptr [eax+1Ch],ecx
b576574f 8b462c          mov     eax,dword ptr [esi+2Ch]
b5765752 c7401402000000  mov     dword ptr [eax+14h],2
b5765759 8b462c          mov     eax,dword ptr [esi+2Ch]
b576575c 83602400        and     dword ptr [eax+24h],0
b5765760 ff762c          push    dword ptr [esi+2Ch]
b5765763 895e0c          mov     dword ptr [esi+0Ch],ebx
b5765766 ff7634          push    dword ptr [esi+34h]
b5765769 56              push    esi
b576576a e85b0e0000      call    Driver1+0xa5ca (b57665ca)
b576576f 8b8714010000    mov     eax,dword ptr [edi+114h]
b5765775 8b4d24          mov     ecx,dword ptr [ebp+24h]
b5765778 8d44080c        lea     eax,[eax+ecx+0Ch]
b576577c 50              push    eax
b576577d 56              push    esi
b576577e ff7518          push    dword ptr [ebp+18h]
b5765781 57              push    edi
b5765782 e829000000      call    Driver1+0×97b0 (b57657b0)
b5765787 8b5634          mov     edx,dword ptr [esi+34h]
b576578a 8b8fa4000000    mov     ecx,dword ptr [edi+0A4h]
b5765790 ff1558c375b5    call    dword ptr [Driver1+0x358 (b575c358)] // IopfCallDriver

Enjoy Debugging

Stack Overflow and Bugcheck 7F ( UNEXPECTED_KERNEL_MODE_TRAP )

Published
by
admin
on 9월 22, 2008
in Debugging Windows
. 0 Comments

일반적으로 Stack overflow가 발생한 Bugcheck의 크개 아래와 같은 2가지 종류가 있습니다.

1. UNEXPECTED_KERNEL_MODE_TRAP (7F), PANIC_STACK_SWITCH(2B)
2. KMODE_EXCEPTION_NOT_HANDLED(1E), SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(7E), KERNEL_MODE_EXCEPTION_NOT_HANDLED(8E)

첫 번째 경우는 개발자의 Code상의 문제로 실제 Stack Overflow가 발생한 경우 이고 두번째 경우는 Exception Trap이 발생 하면 Trap 데이터를 Stack에 저장하다가 발생하는 경우입니다. 물론 첫번째 경우도 두번째 경우와 같은 현상이 발생하기 때문에 EXCEPTION_DOUBLE_FAULT이 Parameter에 나타납니다.

Windows 커널의 Thread Stack의 경우는 각 Platform 별로 각각 일정한 제한을 가지게 됩니다. ( DPC는 예외임 DPC의 경우는 Platform에 할당된 DPC Stack을 사용하기 때문 )

1. x86 - 12K
2. x64 - 24K
3. IA64 - 32K

이러한 Platform 별 Stack의 Size는 최소한의 크기이기 때문에 위에 설명한 Exception들은 종종 많이들 발생하곤합니다. 간단한 예로 File System의 경우 Special APC가 Delivery 되어 재귀 호출이 발생하는 경우라던지 또는 NDIS Stack에 여러개의 Filter Driver가 올라와 발생하는 경우 가 대표적이지요.

이론은 이정도로 마무리하고 실전에서 발생한 예를 한가지 보도록 하죠.

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
Arg2: 89316130
Arg3: 00000000
Arg4: 00000000

Debugging Details:
——————

PEB is paged out (Peb.Ldr = 7ffdb00c). Type “.hh dbgerr001″ for details
PEB is paged out (Peb.Ldr = 7ffdb00c). Type “.hh dbgerr001″ for details

BUGCHECK_STR: 0×7f_8

TSS: 00000028 — (.tss 0×28)
eax=9fcbe414 ebx=00000000 ecx=9fcbe488 edx=00000000 esi=9fcbe49c edi=9fcbe49c
eip=826700d6 esp=9fcbdf9c ebp=9fcbe3f0 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!_woutput_l+0×1b:
826700d6 57 push edi
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: spoolsv.exe

CURRENT_IRQL: ba

LAST_CONTROL_TRANSFER: from 82670b50 to 826700d6

STACK_TEXT:
9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b
9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b
9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18
9fcbe474 83137056 9fcbe49c 000000c8 8313a924 volmgr!StringCbPrintfW+0×3a
9fcbe568 83139c95 87269960 84eaea30 84eaea30 volmgr!VmpQueryDeviceName+0×46
9fcbe5a0 826ff053 872698a8 84eaec08 00000000 volmgr!VmDeviceControl+0×237
9fcbe5b8 8899a640 9fcbe5d8 8899a7d7 872690a0 nt!IofCallDriver+0×63
9fcbe5c0 8899a7d7 872690a0 84eaea30 84eaec08 fvevol!FveFilterSkip+0×1e
9fcbe5d8 826ff053 872690a0 84eaea30 00000000 fvevol!FveFilterDeviceControl+0×18d
9fcbe5f0 8896c81f 9fcbe654 88979d58 8741b020 nt!IofCallDriver+0×63
9fcbe5f8 88979d58 8741b020 84eaea30 84eaea30 ecache!EcDispatchPassthrough+0×43
9fcbe654 826ff053 8741b020 84eaea30 84eaec2c ecache!EcDispatchDeviceControl+0×3e
9fcbe66c 88947470 00000000 8741c020 00000000 nt!IofCallDriver+0×63
9fcbe690 826ff053 84eaec08 84eaea30 9e27cdb0 volsnap!VolSnapDeviceControl+0×42
9fcbe6a8 831ab472 00000000 85cdec48 00000000 nt!IofCallDriver+0×63
9fcbe784 831ab7a4 00cdec48 9fcbe7ec 9fcbe7b8 mountmgr!QueryDeviceInformation+0×2a2
9fcbe7c4 831af2e0 85cdec48 9fcbe7ec 00000000 mountmgr!FindDeviceInfo+0×3a
9fcbe80c 831b3858 85cdec48 b0ac4b70 00000103 mountmgr!MountMgrQueryDosVolumePath+0×6c
9fcbe828 826ff053 85cdec64 b0ac4be0 00000200 mountmgr!MountMgrDeviceControl+0×8c
9fcbe840 82803038 9fcbf0d4 0000002e 9fcbf1c4 nt!IofCallDriver+0×63
9fcbf0a4 b3ceb5e3 872698a8 9fcbf0cc b5a78048 nt!IoVolumeDeviceToDosName+0×145
WARNING: Stack unwind information not available. Following frames may be wrong.
9fcbf1a4 b3ceb7c6 9fcbf1c4 00000068 9fcbf438 NpIdsVt+0×65e3
9fcbf420 b3ceb83d 00000704 9fcbf438 0000000b NpIdsVt+0×67c6
9fcbf694 b3ce8d1e 00000704 b5a78048 9fcbf734 NpIdsVt+0×683d
9fcbf6bc 833b6409 9fcbf9a8 00000000 b0da3538 NpIdsVt+0×3d1e
9fcbf704 833b604f 00000004 9fcbf9a8 9fcbf880 NETIO!ProcessCallout+0×10e
9fcbf774 833b61e9 00000004 9fcbf9a8 9fcbf880 NETIO!ArbitrateAndEnforce+0xaa
9fcbf858 88668410 00000004 9fcbf9a8 9fcbf880 NETIO!KfdClassify+0×16f
9fcbf9c0 88664dc9 97c31094 9fcbfd2c 87ff1ba0 tcpip!ShimIpPacketOutV4+0×15b
9fcbf9f4 88668599 00000000 97c31094 9fcbfd2c tcpip!IppInspectLocalPacketsOut+0×5c
9fcbfaf8 88663c48 9fcbfc88 87ff13f8 9fcbfc88 tcpip!Ipv4pFragmentPacketHelper+0×12d
9fcbfb34 8866399b 886c8c68 00000000 00000000 tcpip!IppFragmentPackets+0xbd
9fcbfb6c 8866578b 886c8c68 97d020c0 616c7049 tcpip!IppDispatchSendPacketHelper+0×252
9fcbfc0c 88664bff 00cbfc88 00000000 8f1f5938 tcpip!IppPacketizeDatagrams+0×8fd
9fcbfd6c 8865dcab 00000000 00000004 886c8c68 tcpip!IppSendDatagramsCommon+0×5f9
9fcbfd8c 8865eb19 8624bed0 9fcbfe88 8ffa0a50 tcpip!IpNlpSendDatagrams+0×4b
9fcbffd4 8d4dfcf2 8ffb0020 8623f8c0 8ffa0a50 tcpip!UdpSendMessages+0xc07
9fcc001c 8d4e79be 92d75de0 8ffa0a00 92c90078 tdx!TdxSendDatagramTransportAddress+0×206
9fcc0038 826ff053 87dbca10 8ffa0a50 8ffa0b2c tdx!TdxTdiDispatchInternalDeviceControl+0×5c
9fcc0050 8d505723 00000000 af3c32e8 b2262d90 nt!IofCallDriver+0×63
9fcc0064 8d4f5b30 af3c32e8 b0be4e58 ffffffff SYMTDI!isManualStart+0×253
9fcc0080 8d5084fc 8ea15af8 b2262d90 000000c8 SYMTDI!DbgTrace+0×900
9fcc00a0 8d4f5de7 b0be4e58 8ffa0a50 af3c32e8 SYMTDI!DisconnectTCPSession+0×1c6c
9fcc00e4 8d505d22 af3c32e8 9fcc0108 9fcc0178 SYMTDI!DbgTrace+0xbb7
9fcc010c 8d505dba 87f59020 8ffa0a50 9fcc0134 SYMTDI!isManualStart+0×852
9fcc011c 826ff053 87f59020 8ffa0a50 b0d59480 SYMTDI!isManualStart+0×8ea
9fcc0134 8de0e8bf 87fc3d78 953b92c0 8de28e84 nt!IofCallDriver+0×63
9fcc0150 8de0e72f 00000000 87fc3e74 00000032 netbt!TdiSendDatagram+0×14e
9fcc0194 8de0e5c5 87fc3d78 c0a800ff 00000032 netbt!UdpSendDatagram+0×14c
9fcc01dc 8de12ed1 87fc3d78 b0a831e8 0057fed0 netbt!SendNameServiceRequest+0×2a1
9fcc0228 8de12adf b0b14aec 87751b48 000002ee netbt!QueryNameOnNet+0×376
9fcc026c 8de0a5bb b0b14aec 87ffe990 8de0994a netbt!FindNameOrQuery+0×463
9fcc02dc 8de0b093 00000000 00000000 87ffebb8 netbt!NbtConnectCommon+0×79c
9fcc02fc 8de0ae4b 9fcc0324 8f9ad200 a914d2cc netbt!NbtConnect+0×114
9fcc034c 8de086d2 87ffe990 92d4e1b0 a914d2b0 netbt!NTConnect+0×1a2
9fcc0368 826ff053 e0ffe990 92d4e268 00000000 netbt!NbtDispatchInternalCtrl+0×16d
9fcc0380 8de2aa64 8de28440 a914d2b0 92d4e1b0 nt!IofCallDriver+0×63
9fcc0398 8de0ae09 00000000 92d4e1b0 00000000 netbt!DelayedNbtProcessConnect+0×100
9fcc03e8 8de086d2 87ffe990 00000000 8f1fb7c0 netbt!NTConnect+0×160
9fcc0404 826ff053 e0ffe990 8f1fb878 87f48c08 netbt!NbtDispatchInternalCtrl+0×16d
9fcc041c 8f9a3081 97d4c150 97d4c164 a9a9b770 nt!IofCallDriver+0×63
9fcc0464 8f9a286f 00000103 00000003 97d4c150 mrxsmb!RxTdiInitiateAsynchronousConnect+0×1e8
9fcc047c 8f9b010f 01a9b770 1056c34d 00000000 mrxsmb!RxCeInitiateConnectRequest+0×38
9fcc04dc 8f9afc30 87eb63d8 00000000 a9a9b770 mrxsmb!RxCeBuildConnectionOverMultipleTransports+0×266
9fcc0524 8f9af557 af21b458 00000000 b0b7b05c mrxsmb!VctEstablishConnection+0×2dd
9fcc0560 8f9a3491 b0b7b010 b0b7b010 b0b7b0cc mrxsmb!SmbCeEstablishNegotiatedConnection+0×112
9fcc058c 8f9af8f2 b0b7b010 92db8398 92db83a8 mrxsmb!SmbCepEstablishServerConnection+0×54
9fcc05b4 8f9af67a 00000000 9fcc05dc 8df51a1e mrxsmb!SmbCeCreateSrvCall+0×19e
9fcc05c0 8df51a1e a9bffcc0 84f11878 8df43188 mrxsmb!MRxSmbCreateSrvCall+0×23
9fcc05dc 8df53eb6 87eb6570 b23d8718 a9bffcc0 rdbss!RxConstructSrvCall+0xe2
9fcc0650 8df54186 b2287488 b23d8718 9fcc0778 rdbss!RxFindOrCreateConnections+0×819
9fcc0698 8df46c6d b2287488 b23d8718 9fcc0778 rdbss!RxConstructVirtualNetRoot+0×68
9fcc074c 8df5345b b2287488 b23d8718 9fcc0778 rdbss!RxFindOrConstructVirtualNetRoot+0×492
9fcc0794 8df5367f b2287401 8df53521 b2287488 rdbss!RxPrefixClaim+0×18c
9fcc07b4 8df2d8e7 b2287488 0000ec23 12380e95 rdbss!RxCommonDevFCBIoCtl+0×15e
STACK_COMMAND: .tss 0×28 ; kb

FOLLOWUP_IP:
volmgr!StringCbPrintfW+3a
83131038 83c410 add esp,10h

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: volmgr!StringCbPrintfW+3a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: volmgr

IMAGE_NAME: volmgr.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47918f7f

FAILURE_BUCKET_ID: 0×7f_8_volmgr!StringCbPrintfW+3a

BUCKET_ID: 0×7f_8_volmgr!StringCbPrintfW+3a

Followup: MachineOwner
———

일단 2개의 3th Part Driver를 확인 할 수 있습니다.  그리고 UNEXPECTED_KERNEL_MODE_TRAP (7f)과 EXCEPTION_DOUBLE_FAULT가 보여지는것으로 Stack Overflow의 전형적인 모습이라는것을 알 수 있죠 .

2: kd> kvnf 100
# Memory ChildEBP RetAddr Args to Child
00 00000000 826700d6 00000000 00000000 00000000 nt!KiTrap08+0x75 (FPO: TSS 28:0)
01 9fcbe3f0 9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b (FPO: [Non-Fpo])
02 44 9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b (FPO: [Non-Fpo])
03 1c 9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18 (FPO: [Non-Fpo])
04 24 9fcbe474 83137056 9fcbe49c 000000c8 8313a924 volmgr!StringCbPrintfW+0×3a (FPO: [Non-Fpo])
05 f4 9fcbe568 83139c95 87269960 84eaea30 84eaea30 volmgr!VmpQueryDeviceName+0×46 (FPO: [Non-Fpo])
06 38 9fcbe5a0 826ff053 872698a8 84eaec08 00000000 volmgr!VmDeviceControl+0×237 (FPO: [Non-Fpo])
07 18 9fcbe5b8 8899a640 9fcbe5d8 8899a7d7 872690a0 nt!IofCallDriver+0×63
08 8 9fcbe5c0 8899a7d7 872690a0 84eaea30 84eaec08 fvevol!FveFilterSkip+0×1e (FPO: [Non-Fpo])
09 18 9fcbe5d8 826ff053 872690a0 84eaea30 00000000 fvevol!FveFilterDeviceControl+0×18d (FPO: [Non-Fpo])
0a 18 9fcbe5f0 8896c81f 9fcbe654 88979d58 8741b020 nt!IofCallDriver+0×63
0b 8 9fcbe5f8 88979d58 8741b020 84eaea30 84eaea30 ecache!EcDispatchPassthrough+0×43 (FPO: [Non-Fpo])
0c 5c 9fcbe654 826ff053 8741b020 84eaea30 84eaec2c ecache!EcDispatchDeviceControl+0×3e (FPO: [Non-Fpo])
0d 18 9fcbe66c 88947470 00000000 8741c020 00000000 nt!IofCallDriver+0×63
0e 24 9fcbe690 826ff053 84eaec08 84eaea30 9e27cdb0 volsnap!VolSnapDeviceControl+0×42 (FPO: [Non-Fpo])
0f 18 9fcbe6a8 831ab472 00000000 85cdec48 00000000 nt!IofCallDriver+0×63
10 dc 9fcbe784 831ab7a4 00cdec48 9fcbe7ec 9fcbe7b8 mountmgr!QueryDeviceInformation+0×2a2 (FPO: [Non-Fpo])
11 40 9fcbe7c4 831af2e0 85cdec48 9fcbe7ec 00000000 mountmgr!FindDeviceInfo+0×3a (FPO: [Non-Fpo])
12 48 9fcbe80c 831b3858 85cdec48 b0ac4b70 00000103 mountmgr!MountMgrQueryDosVolumePath+0×6c (FPO: [Non-Fpo])
13 1c 9fcbe828 826ff053 85cdec64 b0ac4be0 00000200 mountmgr!MountMgrDeviceControl+0×8c (FPO: [Non-Fpo])
14 18 9fcbe840 82803038 9fcbf0d4 0000002e 9fcbf1c4 nt!IofCallDriver+0×63
15 864 9fcbf0a4 b3ceb5e3 872698a8 9fcbf0cc b5a78048 nt!IoVolumeDeviceToDosName+0×145
WARNING: Stack unwind information not available. Following frames may be wrong.
16 100 9fcbf1a4 b3ceb7c6 9fcbf1c4 00000068 9fcbf438 NpIdsVt+0×65e3
17 27c 9fcbf420 b3ceb83d 00000704 9fcbf438 0000000b NpIdsVt+0×67c6
18 274 9fcbf694 b3ce8d1e 00000704 b5a78048 9fcbf734 NpIdsVt+0×683d
19 28 9fcbf6bc 833b6409 9fcbf9a8 00000000 b0da3538 NpIdsVt+0×3d1e
1a 48 9fcbf704 833b604f 00000004 9fcbf9a8 9fcbf880 NETIO!ProcessCallout+0×10e (FPO: [Non-Fpo])
1b 70 9fcbf774 833b61e9 00000004 9fcbf9a8 9fcbf880 NETIO!ArbitrateAndEnforce+0xaa (FPO: [Non-Fpo])
1c e4 9fcbf858 88668410 00000004 9fcbf9a8 9fcbf880 NETIO!KfdClassify+0×16f (FPO: [Non-Fpo])
1d 168 9fcbf9c0 88664dc9 97c31094 9fcbfd2c 87ff1ba0 tcpip!ShimIpPacketOutV4+0×15b (FPO: [Non-Fpo])
1e 34 9fcbf9f4 88668599 00000000 97c31094 9fcbfd2c tcpip!IppInspectLocalPacketsOut+0×5c (FPO: [Non-Fpo])
1f 104 9fcbfaf8 88663c48 9fcbfc88 87ff13f8 9fcbfc88 tcpip!Ipv4pFragmentPacketHelper+0×12d (FPO: [Non-Fpo])
20 3c 9fcbfb34 8866399b 886c8c68 00000000 00000000 tcpip!IppFragmentPackets+0xbd (FPO: [Non-Fpo])
21 38 9fcbfb6c 8866578b 886c8c68 97d020c0 616c7049 tcpip!IppDispatchSendPacketHelper+0×252 (FPO: [Non-Fpo])
22 a0 9fcbfc0c 88664bff 00cbfc88 00000000 8f1f5938 tcpip!IppPacketizeDatagrams+0×8fd (FPO: [Non-Fpo])
23 160 9fcbfd6c 8865dcab 00000000 00000004 886c8c68 tcpip!IppSendDatagramsCommon+0×5f9 (FPO: [Non-Fpo])
24 20 9fcbfd8c 8865eb19 8624bed0 9fcbfe88 8ffa0a50 tcpip!IpNlpSendDatagrams+0×4b (FPO: [Non-Fpo])
25 248 9fcbffd4 8d4dfcf2 8ffb0020 8623f8c0 8ffa0a50 tcpip!UdpSendMessages+0xc07 (FPO: [Non-Fpo])
26 48 9fcc001c 8d4e79be 92d75de0 8ffa0a00 92c90078 tdx!TdxSendDatagramTransportAddress+0×206 (FPO: [Non-Fpo])
27 1c 9fcc0038 826ff053 87dbca10 8ffa0a50 8ffa0b2c tdx!TdxTdiDispatchInternalDeviceControl+0×5c (FPO: [Non-Fpo])
28 18 9fcc0050 8d505723 00000000 af3c32e8 b2262d90 nt!IofCallDriver+0×63
29 14 9fcc0064 8d4f5b30 af3c32e8 b0be4e58 ffffffff SYMTDI!isManualStart+0×253
2a 1c 9fcc0080 8d5084fc 8ea15af8 b2262d90 000000c8 SYMTDI!DbgTrace+0×900
2b 20 9fcc00a0 8d4f5de7 b0be4e58 8ffa0a50 af3c32e8 SYMTDI!DisconnectTCPSession+0×1c6c
2c 44 9fcc00e4 8d505d22 af3c32e8 9fcc0108 9fcc0178 SYMTDI!DbgTrace+0xbb7
2d 28 9fcc010c 8d505dba 87f59020 8ffa0a50 9fcc0134 SYMTDI!isManualStart+0×852
2e 10 9fcc011c 826ff053 87f59020 8ffa0a50 b0d59480 SYMTDI!isManualStart+0×8ea
2f 18 9fcc0134 8de0e8bf 87fc3d78 953b92c0 8de28e84 nt!IofCallDriver+0×63
30 1c 9fcc0150 8de0e72f 00000000 87fc3e74 00000032 netbt!TdiSendDatagram+0×14e (FPO: [Non-Fpo])
31 44 9fcc0194 8de0e5c5 87fc3d78 c0a800ff 00000032 netbt!UdpSendDatagram+0×14c (FPO: [Non-Fpo])
32 48 9fcc01dc 8de12ed1 87fc3d78 b0a831e8 0057fed0 netbt!SendNameServiceRequest+0×2a1 (FPO: [Non-Fpo])
33 4c 9fcc0228 8de12adf b0b14aec 87751b48 000002ee netbt!QueryNameOnNet+0×376 (FPO: [Non-Fpo])
34 44 9fcc026c 8de0a5bb b0b14aec 87ffe990 8de0994a netbt!FindNameOrQuery+0×463 (FPO: [Non-Fpo])
35 70 9fcc02dc 8de0b093 00000000 00000000 87ffebb8 netbt!NbtConnectCommon+0×79c (FPO: [Non-Fpo])
…생략

SYMTDI Driver는 그렇게 많은 Stack를 사용하지 않고 있군요. 하지만 NtIDSVt의 경우 많은 Stack을 사용하고 있는것을 확인 할 수 있습니다. 특히 NtIDSVt에서 호출한 nt!IoVolumeDeviceToDosName Function이 꽤 큰 Stack 사용하고 있는것을 확인 할 수 있죠. ( 사실 Stack의 뒷부분에 호출되어 운이 없다고도 할 수 있음 )

.tss를 통해서 Last Instruction를 확인해 보도록하죠 .
2: kd> .tss 0x28
eax=9fcbe414 ebx=00000000 ecx=9fcbe488 edx=00000000 esi=9fcbe49c edi=9fcbe49c
eip=826700d6 esp=9fcbdf9c ebp=9fcbe3f0 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!_woutput_l+0x1b:
826700d6 57 push edi

역시 Stack에서 작업을 하고 있군요. Stack Overflow에 대한 확신이 섭니다.
2: kd> !thread
THREAD 84ee6030 Cid 0704.1bc0 Teb: 7ffdc000 Win32Thread: 00000000 RUNNING on processor 2
IRP List:
84eaea30: (0006,01fc) Flags: 00060070 Mdl: 00000000
b0ac4b70: (0006,0094) Flags: 00060070 Mdl: 00000000
b23d8b90: (0006,01d8) Flags: 00000884 Mdl: 00000000
Impersonation token: a08a5030 (Level Impersonation)
DeviceMap 9ec2c868
Owning Process 0 Image: <Unknown>
Attached Process 8806a7c8 Image: spoolsv.exe
Wait Start TickCount 12973 Ticks: 0
Context Switch Count 14
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x76f0dbb0
Stack Init 9fcc1000 Current 9fcc03b8 Base 9fcc1000 Limit 9fcbe000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
ChildEBP RetAddr Args to Child
00000000 826700d6 00000000 00000000 00000000 nt!KiTrap08+0×75 (FPO: TSS 28:0)
9fcbe3f0 82670b50 9fcbe414 8313a924 00000000 nt!_woutput_l+0×1b (FPO: [Non-Fpo])
9fcbe434 82670bb0 9fcbe49c 00000063 8313a924 nt!_vsnwprintf_l+0×7b (FPO: [Non-Fpo])
9fcbe450 83131038 9fcbe49c 00000063 8313a924 nt!_vsnwprintf+0×18 (FPO: [Non-Fpo])
… 생략

마지막으로 !thread Command를 이용해서 Stack Limit 를 확인해 보면 Stack Overflow에 대한 추측을 현실로 바꿀 수 있습니다.  이 Kernel Thread의 경우 9fcbe3f0가 마지막 Child EBP 이므로 nt!_woutput_l의 스택 사용량을 추정하면 Stack Overflow의 발생여부를 확인 할 수 있게되죠.

2: kd> uf nt!_woutput_l
Flow analysis was incomplete, some code may be missing
nt!_woutput_l:
826700bb 8bff mov edi,edi
826700bd 55 push ebp
826700be 8bec mov ebp,esp
826700c0 81ec54040000 sub esp,454h
826700c6 a130b77382 mov eax,dword ptr [nt!__security_cookie (8273b730)]
826700cb 33c5 xor eax,ebp
826700cd 8945fc mov dword ptr [ebp-4],eax
826700d0 8b4508 mov eax,dword ptr [ebp+8]
826700d3 8b4d14 mov ecx,dword ptr [ebp+14h]
826700d6 57 push edi

nt!_woutput_l Function은 Stack을  최소 454h 많큼 사용하는군요. 여분의 Stack이 3f0 만큼 남아 있기 때문에 다음번 push Instruction에서 문제가 발생하게되겠죠.

생각보다 수집이 잘안되는 Dump 이고 간얼적으로 발생하다 보니 재현이 힘든 Dump 입니다만 운좋게 분석한 기회가 생겼내요. 

 이와 비슷한 경우가 있으신 분들은 참고 하시길…