Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Driver Verifier & Kernel Guard

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

Child-SP RetAddr : Args to Child : Call Site
fffff90c`f47e96f0 fffff802`092b1876 : ffffb807`00000000 ...: nt!KiSwapContext+0x76
fffff90c`f47e9830 fffff802`092b106b : 00000000`00000000 ...: nt!KiSwapThread+0x2c6
fffff90c`f47e9900 fffff802`092aff67 : 00000000`00000005 ...: nt!KiCommitThreadWait+0x13b
fffff90c`f47e99a0 fffff802`09ac2ad6 : fffff90c`00000005 ...: nt!KeWaitForMultipleObjects+0x467
fffff90c`f47e9a80 fffff802`09ac1ec2 : 00000000`00000005 ...: nt!ViKeWaitForMultipleObjectsCommon+0xc2
fffff90c`f47e9af0 fffff802`0cd58b70 : ffffb98a`06831000 ...: nt!VerifierKeWaitForMultipleObjects+0x52
fffff90c`f47e9b50 fffff802`09393e37 : ffffb98a`0684d700 ...: MyDrv+0x2a8b70
fffff90c`f47e9c10 fffff802`0944a116 : ffffdb00`4c701180 ...: nt!PspSystemThreadStartup+0x47
fffff90c`f47e9c60 00000000`00000000 : 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? :)

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 6,844
    <quote>
    But we see Driver Verifier APIs between MyDrv and called API!?!
    </quote>

    Yes. That's how a lot of Verifier "stuff" works.

    <quote>
    It means, that Verifier really replaces appropriate exports of ntoskernl.exe to
    intercept interesting APIs.
    </quote>

    Well, SORT of...

    <quote>
    Open question for me, how Kernel Guard allows these replacement?
    </quote>

    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 Viscarola
    OSR
    @OSRDrivers

  • Peter,
    thank You for answer!

    But I suggest that really Verifier DEOS "patch" the code in place. :)
    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! :)))
  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,381
    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. :)
    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:

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

    To unsubscribe, visit the List Server section of OSR Online at
  • Doron,
    Thanks!

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

    Regards,
    MG.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!