Driver Verifier & Kernel Guard

Analyzing one Crash Dump I paid attention on the following stack:

Child-SP RetAddr : Args to Child : Call Site
fffff90cf47e96f0 fffff802092b1876 : ffffb80700000000 ...: nt!KiSwapContext+0x76 fffff90cf47e9830 fffff802092b106b : 0000000000000000 …: nt!KiSwapThread+0x2c6
fffff90cf47e9900 fffff802092aff67 : 0000000000000005 ...: nt!KiCommitThreadWait+0x13b fffff90cf47e99a0 fffff80209ac2ad6 : fffff90c00000005 …: nt!KeWaitForMultipleObjects+0x467
fffff90cf47e9a80 fffff80209ac1ec2 : 0000000000000005 ...: nt!ViKeWaitForMultipleObjectsCommon+0xc2 fffff90cf47e9af0 fffff8020cd58b70 : ffffb98a06831000 …: nt!VerifierKeWaitForMultipleObjects+0x52
fffff90cf47e9b50 fffff80209393e37 : ffffb98a0684d700 ...: MyDrv+0x2a8b70 fffff90cf47e9c10 fffff8020944a116 : ffffdb004c701180 …: nt!PspSystemThreadStartup+0x47
fffff90cf47e9c60 0000000000000000 : fffff90c`f47ea000 …: nt!KiStartSystemThread+0x16

What I know exactly, that MyDrv calls here KeWaitForMultipleObjects().
But we see Driver Verifier APIs between MyDrv and called API!?!

It means, that Verifier really replaces appropriate exports of ntoskernl.exe to intercept interesting APIs.
Open question for me, how Kernel Guard allows these replacement? :slight_smile:

Yes. That’s how a lot of Verifier “stuff” works.

Well, SORT of…

Because Verifier doesn’t “patch” the code in place. MSFT *has* the source code for the OS, right? So… when you call a function that can be verified, that function calls either the *ordinary* version of the function, or the *verifier* version of the function (if verifier is enabled).

HOW this is implemented is depends on the function (and the version of Windows). Sometimes there logical exactly like I describe above. Other times, the call to the appropriate function is through a pointer.

Like most things in operating systems, it’s really MUCH easier than it might first sound.

Peter
OSR
@OSRDrivers

Peter,
thank You for answer!

But I suggest that really Verifier DEOS “patch” the code in place. :slight_smile:
More exactly, I guess that Verifier edits ntoskernel.exe export table.
The code patching is more difficult and not OK, because would redirect internal ntoskernel calls too, which (I guess) does not needed.
Keep 2 copy of ntoskernel code with/without Verivier is bad idea (if I would realize Verifier, I had created dynamic solution…).

If my propose is right, the question is does Kernel Guard patchs ntoskernel export table?
Alternatively, probably Verifier deactivate Kernel Guard?
Or Kernel Guard does not control Export Table?

I need create some tests to check suggestions above, which takes time.
But I dream that it’s known! :)))

The export table remains as is, it is the import resolution at load time that is changed when verifier is on. IOW the image loader in the kernel has explicit knowledge of verifier settings and resolves functions differently based on those settings.

d

Bent from my phone


From: 30501763100n behalf of
Sent: Saturday, September 8, 2018 10:45 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver Verifier & Kernel Guard

Peter,
thank You for answer!

But I suggest that really Verifier DEOS “patch” the code in place. :slight_smile:
More exactly, I guess that Verifier edits ntoskernel.exe export table.
The code patching is more difficult and not OK, because would redirect internal ntoskernel calls too, which (I guess) does not needed.
Keep 2 copy of ntoskernel code with/without Verivier is bad idea (if I would realize Verifier, I had created dynamic solution…).

If my propose is right, the question is does Kernel Guard patchs ntoskernel export table?
Alternatively, probably Verifier deactivate Kernel Guard?
Or Kernel Guard does not control Export Table?

I need create some tests to check suggestions above, which takes time.
But I dream that it’s known! :)))


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Doron,
Thanks!

Yes, edit import table on driver loading is even more correct and easy, then Ntoskernl.exe exports, I forgot about. :slight_smile:

Regards,
MG.