stack crash?

This phenomenon is first observed when I tried the NtReadFile test last week, sometimes when the postNtReadFile is called, the handle value, buffer address and buffer size got from the stack is quite different from values got in preNtReadFile. I didn’t pay much attention to this problem that time, but, when I tried to debug the NtSecureConnectPort API with WinDBG today, this phenomenon appeared again. So I did a further study on it.

First, I set a break point at nt!NtSecureConnectPort:

kd> bp nt!NtSecureConnectPort
kd> bl
 0 e 80599128     0001 (0001) nt!NtSecureConnectPort
kd> g
Breakpoint 0 hit
nt!NtSecureConnectPort:
80599128 6884000000      push    84h
kd> r esp
esp=f5f3ed14
kd> dd esp
f5f3ed14  805999b8 001532f0 00aef5c8 00aef5d0
f5f3ed24  00000000 00000000 00000000 00000000

Then I set a break point at the return address 0x80599b8:

kd> bp 805999b8
kd> g
Breakpoint 1 hit
nt!NtConnectPort+0x24:
805999b8 5d              pop     ebp

But this time when I tried to view the stack information, it seems that the stack has been crashed:

kd> r esp
esp=f5f3ed3c
kd> dd f5f3ed14
f5f3ed14  ffffffff 00000030 f5f3ed64 00aef5b8
f5f3ed24  80599994 f5f3ed3c 00000000 805999b9
f5f3ed34  00000008 00000246 f5f3ed64 8053d648

This is so strange. So I set a write break point at the place where the handle pointer is saved:

kd> ba w 4 f5f3ed18
kd> g
Breakpoint 2 hit
nt!KiTrap03+0xf:
8053e703 bb30000000      mov     ebx,30h

I don’t know what nt!KiTrap03 is, and there is no useful call stack information. Luckily, the Google result leaded me to this book, which told me this function is the interrupt handler for int 3. So I followed the book’s guide.

kd> dds esp esp+100
f5f3ed18  00150030
f5f3ed1c  f5f3ed64
f5f3ed20  00aef5b8
f5f3ed24  80599994 nt!NtConnectPort
f5f3ed28  f5f3ed3c
f5f3ed2c  00000000
f5f3ed30  805999b9 nt!NtConnectPort+0x25
f5f3ed34  00000008
f5f3ed38  00000246
f5f3ed3c  f5f3ed64
f5f3ed40  8053d648 nt!KiFastCallEntry+0xf8
...

Still didn’t get much useful information. However, one interesting thing caught my sight: the original call stack is like following when NtSecureConnectPort is called.

kd> k
ChildEBP RetAddr  
f5f3ed10 805999b8 nt!NtSecureConnectPort
f5f3ed3c 8053d648 nt!NtConnectPort+0x24
f5f3ed3c 7c90e514 nt!KiFastCallEntry+0xf8
00aef58c 7c90d05a ntdll!KiFastSystemCallRet
00aef644 7c91150e ntdll!NtConnectPort+0xc
00aef6b8 77ea19ef ntdll!RtlpAllocateDebugInfo+0x49

This means the NtSecureConnectPort is not directly called by KiFastCallEntry, the system service dispatcher, but is called by NtConnectPort. So I checked the disassembled code of NtConnectPort.

nt!NtConnectPort:
80599994 8bff            mov     edi,edi
80599996 55              push    ebp
80599997 8bec            mov     ebp,esp
80599999 ff7524          push    dword ptr [ebp+24h]
8059999c ff7520          push    dword ptr [ebp+20h]
8059999f ff751c          push    dword ptr [ebp+1Ch]
805999a2 ff7518          push    dword ptr [ebp+18h]
805999a5 6a00            push    0
805999a7 ff7514          push    dword ptr [ebp+14h]
805999aa ff7510          push    dword ptr [ebp+10h]
805999ad ff750c          push    dword ptr [ebp+0Ch]
805999b0 ff7508          push    dword ptr [ebp+8]
805999b3 e870f7ffff      call    nt!NtSecureConnectPort (80599128)
805999b8 5d              pop     ebp
805999b9 c22000          ret     20h

So this system service really doesn’t do much things besides calls NtSecureConnectPort which requires one more parameter, ServerSid. So I checked the stack when NtSecureConnectPort returns.

kd> g
Breakpoint 1 hit
nt!NtConnectPort+0x24:
805999b8 5d              pop     ebp
kd> dd esp
f5f3ed3c  f5f3ed64 8053d648 001532f0 00aef5c8
f5f3ed4c  00aef5d0 00000000 00000000 00000000
f5f3ed5c  00aef5f8 00aef5e0 00aef6b8 7c90e514

Compares with the stack when NtSecureConnectPort is called, these values seems to be fine.

Conclusion

Although I still didn’t figure out why the stack is crashed, at least I know this phenomenon seems only appears when a system service is called directly inside the kernel. When NtSecureConnectPort is called directly by KiFastCallEntry, the stack is fine when it returns. This won’t happen when we use SSDT hook like the original Windows version Sebek. But if we switch to use kernel inline hook to improve the invisibility, we are very likely to have the same problem.

And the solution for Qebek is simple — collects the parameter values in the precall callback function and store them in the user_data (the new break point framework, will be introduced in another post).