RE: RE: Re[2]: best method/approach to secure my driver?

As long as the key data is not pathologically hard to discover in either UM or KM, anyone with a debugger and reasonable skills will compromise the ?security? you add on top of a standard ACL.

By pathologically hard to discover I mean something like the encryption is performed incrementally using keys based on random offsets into your binary. Such a method is entirely reasonable with a handcrafted binary, but totally unsupportable for any commercial product. Even this kind of protection won?t stop a determined attacker for more than a few days.

Sent from Mailhttps: for Windows 10

From: xxxxx@osr.commailto:xxxxx
Sent: June 25, 2017 9:14 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: RE: Re[2]: [ntdev] best method/approach to secure my driver?



Using a pre-shared secret.

This technique works as long as the key isn’t discovered.

Truly locking-down the exchange is tough. Your bat bet is the service SID approach.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

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

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

Use the ELAM model. A hash of the user mode binary is stored in the driver’s binary. When you have an IRP_MJ_CREATE, you fail the request if the issuer’s binary does not match.

You have to run in the context of the issuer to have a reliable PID. A process creation callback can help you build a list of running processes with their PID and image path.

Note that a process creation callback can help the driver know about any running instance of the user binary so that the driver can have a list of running and authorized processes. The filtering within the IRP_MJ_CREATE is then fast and easy.

H. G.