Full List Of Functions Protected By Patchguard

Interesting to see a list. One of the system check/DPC routines that PG actually uses is in that list - ExpTimeRefreshDpcRoutine. There are probably more.

Edit - Yes, they're actually all there.

Nowadays rootkits can bypass KPP by hooking the bug check function so when the kernel is modified in any way (IDT, GDT, etc), it interrupts handling of the 0x109 bug check that would be thrown normally.
 
Patrick said:
Nowadays rootkits can bypass KPP by hooking the bug check function so when the kernel is modified in any way (IDT, GDT, etc), it interrupts handling of the 0x109 bug check that would be thrown normally.
Click to expand...
I raised a similar kind of doubt in my C++ class when I was being taught the Exception Handling and I got the same reply. It is really fascinating to see the creativity behind rootkits and malware.
 
For the functions like nt! ?? ::FNODOBFM::`string'+0x1d1f0, there is a method which will enable you to find the actual function name.
 
x BlueRobot said:
You should also have a look at SEH (Structured Exception Handling) - Structured Exception Handling (Windows)
Click to expand...

Thanks for that. I will take a look at it now.

x BlueRobot said:
For the functions like nt! ?? ::FNODOBFM::`string'+0x1d1f0, there is a method which will enable you to find the actual function name.
Click to expand...
Really?
If you could tell me the method, it would be really helpful since many times it is like that and it is tough to determine what exactly it is if there aren't any functions in the stack above and below such functions.
 
x BlueRobot said:
For the functions like nt! ?? ::FNODOBFM::`string'+0x1d1f0, there is a method which will enable you to find the actual function name.
Click to expand...

Is there? When this happens, to my knowledge, FunctionName+Offset no longer equals FunctionAddress+Offset, therefore the output of information in the debugger isn't correct. In these specific cases, the code is moved to a location (which is random, to my knowledge) and the closest symbolic name is a string in the image. When this happens, the debugger (WinDbg) uses the string as a best guess for the return address on the stack.
 
MSFT might have implemented different code optimization than BBT. Good link, by the way.
 
Is it possible that this same thing occurs when the MS Employees use the private symbol servers as well?

@Patrick - Ew, who is that lady and which anime? Seems like she is drunk with blood mixed with vodka :grin1:
 
Is it possible that this same thing occurs when the MS Employees use the private symbol servers as well?
Click to expand...

I don't think any of us have ever seen a stack containing private MSFT symbols, so ; )

To answer your question though, as far as I know, it only effects public symbols.

@Patrick - Ew, who is that lady and which anime?
Click to expand...

Mistress 9 from Sailor Moon, my favorite anime when I was younger. I've started getting back into anime earlier this year after not watching it for a long time.
 
Patrick said:
I don't think any of us have ever seen a stack containing private MSFT symbols, so ; )

To answer your question though, as far as I know, it only effects public symbols.

@Patrick - Ew, who is that lady and which anime?
Click to expand...

Mistress 9 from Sailor Moon, my favorite anime when I was younger. I've started getting back into anime earlier this year after not watching it for a long time.
Click to expand...
I am stuck with Naruto and Detective Conan. If you haven't watched Death Note, then make sure you watch it ^_^

So, now using the above method, I analysed a dump file for which the stack is given below -
Code: 
1: kd> k
Child-SP          RetAddr           Call Site
ffffd000`239d8a08 [COLOR=#ff0000]fffff800`5940cbd2[/COLOR] nt!KeBugCheckEx
ffffd000`239d8a10 fffff800`592e62b9 nt! ?? ::FNODOBFM::`string'+0x1dd22
ffffd000`239d8ab0 fffff800`593e8c2f nt!MmAccessFault+0x769
ffffd000`239d8c70 [COLOR=#0000ff]fffff800`597dc333[/COLOR] nt!KiPageFault+0x12f
ffffd000`239d8e00 fffff800`59679c39 nt! ?? ::NNGAKEGL::`string'+0x20183
ffffd000`239d9130 fffff800`59677a63 nt!ObpLookupObjectName+0x6b9
ffffd000`239d92b0 fffff801`c547f33a nt!ObOpenObjectByName+0x1e3
ffffd000`239d93e0 ffffe001`00000001 JIUMSLYRBO+0x533a
ffffd000`239d93e8 ffffc000`fac88000 0xffffe001`00000001
ffffd000`239d93f0 00000000`00000000 0xffffc000`fac88000
If I use .fnent on the Red Address -
Code: 
1: kd> .fnent [COLOR=#ff0000]fffff800`5940cbd2[/COLOR]
Debugger function entry 00000022`a87b62b8 for:
(fffff800`593eeeb0)   nt! ?? ::FNODOBFM::`string'+0x1dd22   |  (fffff800`59453eec)   nt!DisplayFilter
BeginAddress      = 00000000`0017e553
EndAddress        = 00000000`0017ed66
UnwindInfoAddress = 00000000`00259450
Unwind info at fffff800`594e7450, 1c bytes
  version 2, flags 4, prolog 0, codes 6
  00: offs 0, unwind op 4, op info d UWOP_SAVE_NONVOL FrameOffset: 60 reg: r13.
  02: offs 0, unwind op 4, op info 6 UWOP_SAVE_NONVOL FrameOffset: 68 reg: rsi.
  04: offs 0, unwind op 4, op info 3 UWOP_SAVE_NONVOL FrameOffset: a8 reg: rbx.
Chained info:
BeginAddress      = [B]00000000`0017e47c[/B]
EndAddress        = 00000000`0017e506
UnwindInfoAddress = 00000000`00259428
Unwind info at fffff800`594e7428, 10 bytes
  version 2, flags 4, prolog 0, codes 0
Chained info:
BeginAddress      = [U]00000000`00074800[/U]
EndAddress        = 00000000`00074954
UnwindInfoAddress = 00000000`002592a8
Unwind info at fffff800`594e72a8, 10 bytes
  version 2, flags 0, prolog 16, codes 6
  00: offs 16, unwind op 2, op info d UWOP_ALLOC_SMALL.
  01: offs 12, unwind op 0, op info f UWOP_PUSH_NONVOL reg: r15.
  02: offs 10, unwind op 0, op info e UWOP_PUSH_NONVOL reg: r14.
  03: offs e, unwind op 0, op info c UWOP_PUSH_NONVOL reg: r12.
  04: offs c, unwind op 0, op info 7 UWOP_PUSH_NONVOL reg: rdi.
  05: offs b, unwind op 0, op info 5 UWOP_PUSH_NONVOL reg: rbp.
So, in this case, I got two sections of Chained Info. If I do ln on the beginning address of the first section, I get the below output -
Code: 
1: kd> ln nt+[B]00000000`0017e47c[/B]
(fffff800`593eeeb0)   nt! ?? ::FNODOBFM::`string'+0x1d5cc   |  (fffff800`59453eec)   nt!DisplayFilter
But, if I run the ln on second beginning address, I get the below output which seems to be the missing piece in the stack -
Code: 
1: kd> ln nt+[U]00000000`00074800[/U]
(fffff800`59302800)   nt!MiSystemFault   |  (fffff800`59303404)   nt!MiNoFaultFound
Exact matches:
    nt!MiSystemFault (<no parameter info>)
Any idea, why there might be two sections like these? Also, how do I find a clue on what the function "MiSystemFault" does actually because there doesn't seem to be any documentation available on it : (


-Pranav
 
Last edited:
MiSystemFault is an most likely an undocumented WMI function, assuming MI is the WMI prefix.

Any idea, why there might be two sections like these?
Click to expand...

Good question, I'm not entirely sure. It's the same with my example:

Code: 
0: kd> k
Child-SP          RetAddr           Call Site
fffff880`0c372378 fffff800`02edfc53 nt!KeBugCheckEx
fffff880`0c372380 fffff800`02efe473 nt! ?? ::FNODOBFM::`string'+0x4a13
fffff880`0c3723c0 fffff800`02ebe9c9 nt! ?? ::FNODOBFM::`string'+0x32c3b
fffff880`0c372580 fffff800`0319fe90 nt!MiRemoveMappedView+0xd9
fffff880`0c3726a0 fffff880`04137aef nt!MiUnmapViewOfSection+0x1b0
fffff880`0c372760 fffff880`04132523 dxgmms1!VIDMM_GLOBAL::CloseLocalAllocation+0xa7
fffff880`0c372810 fffff880`04118ecc dxgmms1!VIDMM_GLOBAL::CloseOneAllocation+0x19b
fffff880`0c3728e0 fffff880`0405accc dxgmms1!VidMmCloseAllocation+0x44
fffff880`0c372910 fffff880`0405b3ac dxgkrnl!DXGDEVICE::DestroyAllocations+0x248
fffff880`0c372a00 fffff880`0405a651 dxgkrnl!DXGDEVICE::DestroyResource+0x84
fffff880`0c372a30 fffff880`0406024b dxgkrnl!DXGDEVICE::ProcessTerminationList+0x95
fffff880`0c372a80 fffff960`001a0d32 dxgkrnl!DxgkCreateAllocation+0x40b
fffff880`0c372bb0 fffff800`02e8aad3 win32k!NtGdiDdDDICreateAllocation+0x12
fffff880`0c372be0 00000000`72ca13fa nt!KiSystemServiceCopyEnd+0x13
00000000`000cdc58 00000000`00000000 0x72ca13fa

Code: 
0: kd> .fnent fffff800`02edfc53
Debugger function entry 000000df`96da8968 for:
(fffff800`02ec9820)   nt! ?? ::FNODOBFM::`string'+0x4a13   |  (fffff800`02ec9858)   nt!vDbgPrintExWithPrefixInternal

BeginAddress      = 00000000`000c3bb0
EndAddress        = 00000000`000c3c64
UnwindInfoAddress = 00000000`001bfa64

Unwind info at fffff800`02fdba64, 1c bytes
  version 1, flags 4, prolog 0, codes 6
  00: offs 0, unwind op 4, op info 7    UWOP_SAVE_NONVOL FrameOffset: 30 reg: rdi.
  02: offs 0, unwind op 4, op info 6    UWOP_SAVE_NONVOL FrameOffset: 48 reg: rsi.
  04: offs 0, unwind op 4, op info 3    UWOP_SAVE_NONVOL FrameOffset: 40 reg: rbx.

Chained info:
BeginAddress      = 00000000`000953f0
EndAddress        = 00000000`0009543b
UnwindInfoAddress = 00000000`001b65d8

Unwind info at fffff800`02fd25d8, 6 bytes
  version 1, flags 0, prolog 4, codes 1
  00: offs 4, unwind op 2, op info 6    UWOP_ALLOC_SMALL.

Code: 
0: kd> ln nt+000953f0
(fffff800`02eb13f0)   nt!MiLocateWsle   |  (fffff800`02eb1540)   nt!MiResolveProtoPteFault
Exact matches:
    nt!MiLocateWsle (<no parameter info>)

I suppose you'll just run the list nearest symbol command on the beginaddress field values until you find the one with the 'Exact matches:', and then that's the right one.
 
Wmi is the WMI prefix, and I'm assuming that the M = Memory Management and the i = internal. Internal in terms of publicly undocumented, and since the function is only reserved for system use. There's also Ki which is another private prefix.
 
Pranav, do you still have the dump file? I would like to test if the string is resolved across different debugger versions.
 
Patrick said:
MiSystemFault is an most likely an undocumented WMI function, assuming MI is the WMI prefix.
Click to expand...

x BlueRobot said:
Wmi is the WMI prefix, and I'm assuming that the M = Memory Management and the i = internal. Internal in terms of publicly undocumented, and since the function is only reserved for system use. There's also Ki which is another private prefix.
Click to expand...

The Mi prefix is as Harry stated, it's an undocumented private function. Ki stands for Kernel Internal and it private, therefore, almost entirely undocumented.
 
Last edited:
blueelvis said:
x BlueRobot said:
Pranav, do you still have the dump file? I would like to test if the string is resolved across different debugger versions.
Click to expand...

Yup, I have the dump with me. Here is the link -
https://onedrive.live.com/redir?resid=AE6D306EA85A8E10!4706&authkey=!AAyyEc-ajZrykOY&ithint=file,dmp

So, the function KeBugcheck() , has a suffix of K meaning Kernel and E meaning it is external and documented, right?

-Pranav
Click to expand...

Ke just means Kernel, it's mostly documented, yes.
 
You mean prefix, suffix denotes a common ending of a word; sorry I'm being a grammar Nazi :p

Thanks for the dump file!
 
x BlueRobot said:
You mean prefix, suffix denotes a common ending of a word; sorry I'm being a grammar Nazi :p

Thanks for the dump file!
Click to expand...

How did I miss that? I'm usually the one who corrects grammar.
 
You must log in or register to reply here.

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top