3

I want having a deep dive into ntdll!NtQueueApcThread seeing what happen after syscall instruction is executed. According to the document(Intel® 64 and IA-32 Architectures Software Developer’s Manual), the syscall instruction using the msr's LSTAR (0xC0000082) as the rip, so I set breakpoint in the nt!KiSystemCall64, which is the address I got by "rdmsr c0000082". But it's not working, my debugger doesn't break. It seems that the syscall inst does not jump to the address stored in the msr.

This is what I have done:

0: kd> 
ntdll!NtQueueApcThread+0x10:
0033:00007ffb`3c32c640 7503            jne     ntdll!NtQueueApcThread+0x15 (00007ffb`3c32c645)
0: kd> 
ntdll!NtQueueApcThread+0x12:
0033:00007ffb`3c32c642 0f05            syscall
0: kd> rdmsr c0000082
msr[c0000082] = fffff802`3681e6c0
0: kd> u fffff802`3681e6c0
nt!KiSystemCall64:
fffff802`3681e6c0 0f01f8          swapgs
fffff802`3681e6c3 654889242510000000 mov   qword ptr gs:[10h],rsp
fffff802`3681e6cc 65488b2425a8010000 mov   rsp,qword ptr gs:[1A8h]
fffff802`3681e6d5 6a2b            push    2Bh
fffff802`3681e6d7 65ff342510000000 push    qword ptr gs:[10h]
fffff802`3681e6df 4153            push    r11
fffff802`3681e6e1 6a33            push    33h
fffff802`3681e6e3 51              push    rcx
0: kd> bp ffff802`3681e6c0
0: kd> t
ntdll!NtQueueApcThread+0x14:
0033:00007ffb`3c32c644 c3              ret

the target system version is Windows10 build 19042

FWTBwAh8
  • 61
  • 5
  • Out of curiosity, where is the document you are referring to? Could you edit the post to clarify it? – Sprite Dec 19 '20 at 07:09
  • @Sprite the document I read is Intel® 64 and IA-32 Architectures Software Developer’s Manual, and you can also find some infomation in this website [osdev-wiki](https://wiki.osdev.org/SYSENTER) – FWTBwAh8 Dec 19 '20 at 12:41
  • Thank you! Also I tried setting a breakpoint at `KiSystemCall64Shadow` and when I clicked "Go" a BSOD occurred. – Sprite Dec 19 '20 at 14:39

1 Answers1

3

After a few day study, I got to know what the problem is. In normal situation, setting a breakpoint in nt!KiSystemCall64 will cause a BSOD, this is because the first three instruction in nt!KiSystemCall64 is setting the kernel stack, which is required by windows kernel debugging mechanism. So the solution is setting the breakoint after the kernel stack is setup

bp nt!KiSystemCall64+0x15

In my situation, setting breakpoint does nothing happend, seems like the breakpoint is not working, I guess it is due to the anti-virus software I installed, which may have hooked some thing. After I uninstalled it, breakpoint is worked.

FWTBwAh8
  • 61
  • 5