Load software driver from user memory

My question is twofold:

Part One:

I was wondering if there is a way to run a software driver from a memory buffer. This buffer could be populated in a number of ways (decrypting an encrypted blob from a resource in a launching executable, or by reading the encrypted blob from a socket.)

I would *strongly* prefer that the decrypted driver not touch the disk. It seems easy enough to drop the decrypted driver to disk and load it.

Part Two:

Assuming there is a way to do this, is there a way to detect of someone else does it?

Also, Is there a good way to monitor calls to VirtualAlloc filtering out calls that do not set the PAGE_EXECUTE bit?

To speed things along:

Yes, I have valid reasons for wanting to do this.
No, I am not a hacker.
No, I am not developing malware.

I can see where such a thing could go terribly wrong in SOOOOOO many ways…

(Time to grab my popcorn bucket and enjoy this thread!)

xxxxx@hexiscyber.com wrote:

From: xxxxx@hexiscyber.com
To: “Windows System Software Devs Interest List”
Subject: [ntdev] Load software driver from user memory
Date: Wed, 29 Oct 2014 13:12:25 -0400 (EDT)

My question is twofold:

Part One:

I was wondering if there is a way to run a software driver from a memory buffer. This buffer could be populated in a number of ways (decrypting an encrypted blob from a resource in a launching executable, or by reading the encrypted blob from a socket.)

I would strongly prefer that the decrypted driver not touch the disk. It seems easy enough to drop the decrypted driver to disk and load it.

Part Two:

Assuming there is a way to do this, is there a way to detect of someone else does it?

Also, Is there a good way to monitor calls to VirtualAlloc filtering out calls that do not set the PAGE_EXECUTE bit?

To speed things along:

Yes, I have valid reasons for wanting to do this.
No, I am not a hacker.
No, I am not developing malware.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Dup thread

You need to have administrative privileges on the box. You need to write the driver file into a file opened with all sharing enabled, and flags DELETE_ON_CLOSE and FILE_ATTRIBUTE_TEMPORARY. After the driver loads (by the service manager) close the handle. This doesn’t give you guarantee the file will not be committed to disk, but will make it less likely.

Indeed - the point is to not have it go wrong.

So basing things on methods I have used in the past to run exe’s and dll’s from memory I can take things right up to the point of the DriverEntry. (Basically parse the PE, fix up the import table, VirtualAlloc, and call an entry point.) At that last I run into a brick wall.

sc does it… hey - maybe I can trace that. Hmm.

So, you know, like… inject malware into a running system.

That should be no problem.

Peter
OSR
@OSRDrivers

sc doesn’t run a driver from memory. It calls some kernel service to load the driver from a file into kernel address space.

Sigh, you know like, because malware would never do this from disk. But then again, this sort of chicanery is what I am trying to prevent.

One would hope that signature verification would prevent some of the possible malfeasance from such a method. Unless such a method would totally bypass the verification step.

However what I am thinking at the moment is to create a file mapping of sufficient size in the swap file, map a view of that, drop the unencrypted driver there, set up a registry key to point to the driver (how? I have a HANDLE not a file name… hmm), call NtLoadDriver (MmLoadSystemImage ?), in DriverEntry map to nonpageable memory, delete the registry entry, then unmap the view (maybe zeroize it first). If that works then driver is deployed, running, and never touched the file system.

It touches the disk, however since it “hidden” in the swap file I can live with that for now.

@Alex - I realize that… which is the genesis of the entire question. Much like I can load an exe or dll from memory by basically emulating the functionality of the loader - such must be (strike that… IS) possible for drivers. After all, sc does it… it just loads it from disk first rather than from a socket or resource. Which brings me to part 2 - detecting if someone else is performing such shenanigans.

> Which brings me to part 2 - detecting if someone else is performing such shenanigans.

Whoever else is performing such shenanigans can detect if someone is detecting such shenanigans. As long as you assume that you cannot drop in an undetectable module from nowhere, anybody else can do that. It’s a game that cannot be won, other than by solving the halting problem. Which is unsolvable.

You have an unusual and security-critical task that you want to perform, that requires significant Windows kernel-level knowledge, and that is subject to a number of constraints.

If you’re well-intentioned, and I believe you are… at least you appear to be posting from an established domain and not GMAIL… then you should recognize that this is an engineering consulting assignment and not something amenable to random discussion on an internet forum.

Peter
OSR
@OSRDrivers