Hello,
I would like to load my driver from memory (in a buffer) without using the filesystem.
I search many time but I can’t find a way. Can you help me ?
Thanks,
Ok, stupid question time ? It was on the disk before it was in memory right? Seems the simplest solution would be to allow the system to do what the system does best; load a device driver.
However, given you really do have a viable reason for doing this, check the WDK for manually loading a driver. Last time I looked at this was 2003/2004 and we quickly decided it was beyond stupid to do it that way.
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 2, 2012, at 4:07 AM, xxxxx@hotmail.com wrote:
Hello,
I would like to load my driver from memory (in a buffer) without using the filesystem.
I search many time but I can’t find a way. Can you help me ?Thanks,
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> Ok, stupid question time ? It was on the disk before it was in memory right?
Seems the simplest solution would be to allow the system to do what the system
does best; load a device driver.
My driver comme from the network.
On 3/2/2012 10:40 AM, xxxxx@hotmail.com wrote:
> Ok, stupid question time ? It was on the disk before it was in memory right?
> Seems the simplest solution would be to allow the system to do what the system
> does best; load a device driver.
My driver comme from the network.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Are you running at kernel mode or user mode? I’m assuming user-mode due to you
using the network. Is quickly writing the driver out to a file (perhaps write to
a hidden and system file) not an option due to some other reason rather than an
optimization? I don’t see any proper APIs for doing this, so if there was a way,
I’m sure it would break platform independence.
-Brandon
As has been pointed out you need it to disk. I should also point out
that a number of malicious drivers attempt to load from memory, so one
has to wonder what your driver is doing.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> Hello,
>
> I would like to load my driver from memory (in a buffer) without using the filesystem.
> I search many time but I can’t find a way. Can you help me ?
>
> Thanks,
Yes I’m under user mode.
It’s for a distributed solution and I would like my user cannot recover the file for confidential reason.
So there are no solution for do that without use the file system ?
If you keep the file open the user can’t remove it. So you can write it
to a file and still protect it.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> Yes I’m under user mode.
> It’s for a distributed solution and I would like my user cannot recover the file for confidential reason.
> So there are no solution for do that without use the file system ?
> If you keep the file open the user can’t remove it. So you can write it
to a file and still protect it.
Yes but with forensic an other method I prefere to not put my file on FS.
On 3/2/2012 11:37 AM, xxxxx@hotmail.com wrote:
> If you keep the file open the user can’t remove it. So you can write it
> to a file and still protect it.
Yes but with forensic an other method I prefere to not put my file on FS.
What you’re doing sounds insanely sketchy. Running a driver over a network. As
there’s no way to do integrity checking on this, it sounds very viable that it’s
not for production. Sounds quite malicious. I’m sorry, but given the evidence I
have seen, I’m no longer interested in helping you.
-Brandon
So you want to create a completely unsupported, undocumented way of
loading your driver, with the strong possibility of crashing the system.
You can with proper handling make this secure, and scrub the disk
afterwards such that no one can care.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:
> > If you keep the file open the user can’t remove it. So you can write it
> > to a file and still protect it.
>
> Yes but with forensic an other method I prefere to not put my file on FS.
Even if you load it from memory your user can take a full kernel dump and reconstruct the image.
d
debt from my phone
From: xxxxx@hotmail.com
Sent: 3/2/2012 8:00 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Load driver from memory
Yes I’m under user mode.
It’s for a distributed solution and I would like my user cannot recover the file for confidential reason.
So there are no solution for do that without use the file system ?
NTDEV is sponsored by OSR
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
On 02/03/2012 16:37, xxxxx@hotmail.com wrote:
Yes but with forensic an other method I prefere to not put my file on FS.
Why not load the driver from an encrypted filesystem like TrueCrypt (or
Bitlocker)?
You create the volume as an encrypted file on disk, mount it into the
device namespace and then you should be able to load the driver from the
volume.
–
Bruce Cran
> Even if you load it from memory your user can take a full kernel dump and
reconstruct the image.
Oh yes, it’s true…
Or throw a WFP filter into the system and grab your driver hot and fresh off of the internet, or redirecting you to theirs …
Gary Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net
On Mar 2, 2012, at 10:37 AM, xxxxx@hotmail.com wrote:
> If you keep the file open the user can’t remove it. So you can write it
> to a file and still protect it.Yes but with forensic an other method I prefere to not put my file on FS.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
So given that, make sure the driver file is ACLed properly and use the normal path
d
debt from my phone
From: xxxxx@hotmail.com
Sent: 3/2/2012 8:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Load driver from memory
Even if you load it from memory your user can take a full kernel dump and
reconstruct the image.
Oh yes, it’s true…
NTDEV is sponsored by OSR
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
xxxxx@hotmail.com wrote:
Yes I’m under user mode.
It’s for a distributed solution and I would like my user cannot recover the file for confidential reason.
So there are no solution for do that without use the file system ?
No. And remember, once it’s in memory, they can force a blue screen and
recover the entire contents of your driver from the dump. You can’t
stop a dedicated attacker.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> > Yes but with forensic an other method I prefere to not put my file on FS.
In fact, seems to be an indirect way of saying “I am writing a piece of malware”…
Anton Bassov
Does anyone remember the original IBM PCs? The ones that were made by
IBM? None of them had “reset” buttons. Why? I asked this question at
the IBM booth at COMDEX (does anyone remember COMDEX? ) and he explained
to me, as if I were a simpleton, that “If we include a reset button,
people will be able to steal software”. So total cluelessness is nothing
new, and from time to time some naive programmer who is as totally
clueless as that long-forgotten IBM engineer comes up with Yet Another Way
To Make My Software Secure. Until we have CPU chips that run encrypted
code streams, doing the decode with a private key during the instruction
fetch cycle, software can be trivially reverse-engineered. Like any
security system, if you can access and examine the plaintext document,
encryption is a waste of time and effort. And silly ideas like “loading a
driver from memory” will continue to appear, in spite of the numerous
obvious failures in design that generate these ideas. What is sad is that
they never think two steps ahead, and all of the good attacks (which will
obviously work) are three steps ahead. Two steps ahead are a large set of
attacks that will almost certainly succeed; three steps ahead are the
attacks that can’t posibly fail.
So if it is malware, the OP deserves to fail, and if it is merely valuable
IP then the OP needs to be warned that such silly ideas are a waste of
time and effort, and will provide no meaningful protection.
joe
> Even if you load it from memory your user can take a full kernel dump
> and
> reconstruct the image.
Oh yes, it’s true…
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Any plaintext code can be reverse-engineered. How is it that you have
missed this screamingly obvious fact?
joe
Yes I’m under user mode.
It’s for a distributed solution and I would like my user cannot recover
the file for confidential reason.
So there are no solution for do that without use the file system ?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@flounder.com wrote:
… Until we have CPU chips that run encrypted
code streams, doing the decode with a private key during the instruction
fetch cycle, software can be trivially reverse-engineered.
And for better or for worse, we are likely to have exactly that
technology within the year.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.