Well this may be an irrelevant question to this list. I need to reverse an unknown sys file.
Osrlo ader is not able to load the driver. It says driver is not valid. Using some static analysis I found the driverEntry function is not exported.
Are there any tools which I can use to load such drivers.
I tried to use the following code that uses zwloaddriver()
hxxp://hi.baidu.com/219977/item/8e44bff43cf1d509d89e7292
. but did not work.
Can anybody suggest me how to continue futher.
DriverEntry is never an export, it is the entrypoint in the PE image. Snippet from link /dump /all i8042prt.sys
OPTIONAL HEADER VALUES
20B magic # (PE32+)
10.10 linker version
15A00 size of code
5C00 size of initialized data
0 size of uninitialized data
5890 entry point (0000000000015890) <======
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, May 22, 2013 9:59 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] how to load a driver that does not export driverentry
Well this may be an irrelevant question to this list. I need to reverse an unknown sys file.
Osrlo ader is not able to load the driver. It says driver is not valid. Using some static analysis I found the driverEntry function is not exported.
Are there any tools which I can use to load such drivers.
I tried to use the following code that uses zwloaddriver()
hxxp://hi.baidu.com/219977/item/8e44bff43cf1d509d89e7292
. but did not work.
Can anybody suggest me how to continue futher.
Sorry I could not express the problem properly. I am aware that driverentry is entry point in a sys PE file. I opened the file in IDA pro. Usually I see IDA recognizes the driverentry in sys file and shows the subroutine name as driverentry but in this case it just shows as “start”. I think osrloader too is not able to recognize the driverentry. That’s why it fails to load the file.
To the best of my knowledge, the name “DriverEntry” (whether decorated or
not) is not “exported” from the .sys file (which is a DLL, a fact which
surprises many). Instead, there is a “start” address set in the header,
and the linker sets this “start” address to the address of DriverEntry.
For a DLL, it is set to the CRT address where the DLL starts execution
(which eventually calls DllMain). For an app, it is set to “main”, but
note that if you want to be really nasty, you can set it to reference
“MyStart” and it will work just fine, but nobody will be able to make
sense of your code.
joe
Sorry I could not express the problem properly. I am aware that
driverentry is entry point in a sys PE file. I opened the file in IDA pro.
Usually I see IDA recognizes the driverentry in sys file and shows the
subroutine name as driverentry but in this case it just shows as “start”.
I think osrloader too is not able to recognize the driverentry. That’s why
it fails to load the file.
Not to quibble unnecessarily, but for the record, the linker sets the start address to the address of the function named in the linker’s /ENTRY switch, which is no longer DriverEntry.
For a KMDF driver, the value for /ENTRY would be FxDriverEntry. For a WDM driver, this would probably be something like GsDriverEntry.
THESE guys in turn call DriverEntry.
It’s kind of interesting, but by implementing these “pre-processing” routines, the name DriverEntry has effectively been canonized as a required name for your driver’s initial entry point. Before we had things like WDF and stack checking, you COULD call your driver entry point anything you wanted, assuming you set it properly in your SOURCES file. Obviously doing that would be a Very Bad Idea, but…
Perhaps you have an unresolved import. Step through MmLoadSystemImage and see where it falls over.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 23, 2013 9:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] how to load a driver that does not export driverentry
Sorry I could not express the problem properly. I am aware that driverentry is entry point in a sys PE file. I opened the file in IDA pro. Usually I see IDA recognizes the driverentry in sys file and shows the subroutine name as driverentry but in this case it just shows as “start”. I think osrloader too is not able to recognize the driverentry. That’s why it fails to load the file.
On Thu, May 23, 2013 at 9:41 AM, Doron Holan wrote:
> Perhaps you have an unresolved import. Step through MmLoadSystemImage and > see where it falls over. > > d > > -----Original Message----- > From: xxxxx@lists.osr.com [mailto: > xxxxx@lists.osr.com] On Behalf Of > xxxxx@gmail.com > Sent: Thursday, May 23, 2013 9:23 AM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] how to load a driver that does not export driverentry > > Sorry I could not express the problem properly. I am aware that > driverentry is entry point in a sys PE file. I opened the file in IDA pro. > Usually I see IDA recognizes the driverentry in sys file and shows the > subroutine name as driverentry but in this case it just shows as “start”. > I think osrloader too is not able to recognize the driverentry. That’s why > it fails to load the file. > > — > NTDEV is sponsored by OSR > > 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 > > > > > — > NTDEV is sponsored by OSR > > 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 >
Sorry I could not express the problem properly. I am aware that driverentry is entry point in a sys PE file. I opened the file in IDA pro. Usually I see IDA recognizes the driverentry in sys file and shows the subroutine name as driverentry but in this case it just shows as “start”. I think osrloader too is not able to recognize the driverentry. That’s why it fails to load the file.
If you send me the binary by private email, I’ll take a minute to see if
I can pinpoint the issue. I happen to be pretty good at pattern
recognition.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My suggestion on MmLoadSystemImage was to see if something other than import resolution was the problem…d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan (news)
Sent: Thursday, May 23, 2013 9:53 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] how to load a driver that does not export driverentry
or depends.exe
On Thu, May 23, 2013 at 9:41 AM, Doron Holan > wrote: Perhaps you have an unresolved import. Step through MmLoadSystemImage and see where it falls over.
Sorry I could not express the problem properly. I am aware that driverentry is entry point in a sys PE file. I opened the file in IDA pro. Usually I see IDA recognizes the driverentry in sys file and shows the subroutine name as driverentry but in this case it just shows as “start”. I think osrloader too is not able to recognize the driverentry. That’s why it fails to load the file.
Sorry I could not express the problem properly. I am aware that driverentry is entry point in a sys PE file. I opened the file in IDA pro. Usually I see IDA recognizes the driverentry in sys file and shows the subroutine name as driverentry but in this case it just shows as “start”. I think osrloader too is not able to recognize the driverentry. That’s why it fails to load the file.
No, that’s not the issue. There’s nothing wrong with the DriverEntry.
It’s true that there’s no symbol exported for it, but that’s not
required. The entry address is defined in the PE header, and it’s a
valid function.
What operating system are you trying to load this on? It’s a 32-bit
driver, so don’t try to load it on a 64-bit system. Is this a driver
you wrote? There’s a path to the PDB file in here; looks like it was
originally called ssdt.sys.
There are some odd things in the header. The base address is set to
00400000, whereas kernel drivers are usually built with a base address
of 00010000. I don’t know whether the kernel loader requires that or
not. Also, there are 12k bytes of extra crap tacked on to the end of
the .sys file, after the end of the tables.
Beyond that, it doesn’t look unusual to me.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The loader certainly don’t need this info to load a module if it’s PE
intended to load in kernel mode. The chance of loading a kernel mode PE
(except Winload/winresume/osloader and like) to preferred address (w/o
relocation) is less than or equal to that being struck by lightening twice
in once’s life time.
Calvin
On Thu, May 23, 2013 at 11:21 AM, Tim Roberts wrote:
> xxxxx@gmail.com wrote: > > Sorry I could not express the problem properly. I am aware that > driverentry is entry point in a sys PE file. I opened the file in IDA pro. > Usually I see IDA recognizes the driverentry in sys file and shows the > subroutine name as driverentry but in this case it just shows as “start”. > I think osrloader too is not able to recognize the driverentry. That’s why > it fails to load the file. > > No, that’s not the issue. There’s nothing wrong with the DriverEntry. > It’s true that there’s no symbol exported for it, but that’s not > required. The entry address is defined in the PE header, and it’s a > valid function. > > What operating system are you trying to load this on? It’s a 32-bit > driver, so don’t try to load it on a 64-bit system. Is this a driver > you wrote? There’s a path to the PDB file in here; looks like it was > originally called ssdt.sys. > > There are some odd things in the header. The base address is set to > 00400000, whereas kernel drivers are usually built with a base address > of 00010000. I don’t know whether the kernel loader requires that or > not. Also, there are 12k bytes of extra crap tacked on to the end of > the .sys file, after the end of the tables. > > Beyond that, it doesn’t look unusual to me. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > 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 >
The loader certainly don’t need this info to load a module if it’s PE
intended to load in kernel mode. The chance of loading a kernel mode
PE (except Winload/winresume/osloader and like) to preferred address
(w/o relocation) is less than or equal to that being struck by
lightening twice in once’s life time.
Of course not, since those addresses are in user space. However, the
WDK forces the base address to 10000. I don’t know whether that’s just
a convention, or if the kernel loader requires that specific number.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
They of course should not care what is specified in the preferred address.
Let it be 10000, 40000 don’t matter. The loader just uses this value to
compute offset required by base relocation if actual loaded address is
different from preferred address.
For example, the preferred base base in a PE is 10000, in the code section,
it refers to address of 10038, now your actual load base is 0x880ea000,
then you patch the hold with 880ea000+(10038-10000). It’s that simple.
I wrote my own OS a while back that loads PE images hence I knew exactly
what I’m talking about.
Calvin
On Thu, May 23, 2013 at 11:44 AM, Tim Roberts wrote:
> Calvin Guan (news) wrote: > >
> > > > The loader certainly don’t need this info to load a module if it’s PE > > intended to load in kernel mode. The chance of loading a kernel mode > > PE (except Winload/winresume/osloader and like) to preferred address > > (w/o relocation) is less than or equal to that being struck by > > lightening twice in once’s life time. > > Of course not, since those addresses are in user space. However, the > WDK forces the base address to 10000. I don’t know whether that’s just > a convention, or if the kernel loader requires that specific number. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > 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 >
>There are some odd things in the header. The base address is set to
00400000, whereas kernel drivers are usually built with a base address
of 00010000. I don’t know whether the kernel loader requires that or
not.
ive seen a few 0x400000 based sys files
you can search your system32\driver dir with
C:\WINDOWS\system32\drivers>for %i IN (DIR *.sys) DO echo %i >>foo.txt & kd -z %
i -c "!dh %i;q " | grep -i “image base” >> foo.txt
C:\WINDOWS\system32\drivers>grep 400000 -B 1 -A 1 foo.txt
VBoxDrv.sys
00400000 image base
VBoxNetAdp.sys
00400000 image base
VBoxUSBMon.sys
00400000 image base
vdmindvd.sys
VMNetSrv.sys
00400000 image base
volsnap.sys
On 5/23/13, Tim Roberts wrote: > xxxxx@gmail.com wrote: >> Sorry I could not express the problem properly. I am aware that >> driverentry is entry point in a sys PE file. I opened the file in IDA pro. >> Usually I see IDA recognizes the driverentry in sys file and shows the >> subroutine name as driverentry but in this case it just shows as “start”. >> I think osrloader too is not able to recognize the driverentry. That’s why >> it fails to load the file. > > No, that’s not the issue. There’s nothing wrong with the DriverEntry. > It’s true that there’s no symbol exported for it, but that’s not > required. The entry address is defined in the PE header, and it’s a > valid function. > > What operating system are you trying to load this on? It’s a 32-bit > driver, so don’t try to load it on a 64-bit system. Is this a driver > you wrote? There’s a path to the PDB file in here; looks like it was > originally called ssdt.sys. > > There are some odd things in the header. The base address is set to > 00400000, whereas kernel drivers are usually built with a base address > of 00010000. I don’t know whether the kernel loader requires that or > not. Also, there are 12k bytes of extra crap tacked on to the end of > the .sys file, after the end of the tables. > > Beyond that, it doesn’t look unusual to me. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > 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 >
It was for fun and education at my spare time while my labor was cheap and
I don’t have kids and wife.
In my early days as a programmer, most of my coworkers have a degree in CS
while I don’t. I was so clueless while they talked about threading,
scheduling hash, queue, bin-tree. Most of my programming skill are
procedure control based or implementing DSP algorithms. So I figured
writing a hobby OS is a great way to learn OS.
On Thu, May 23, 2013 at 12:34 PM, wrote:
>
> > Like… in your spare time? For fun? :-0 > > I wrote a C# program and thought that was pretty good. But somehow, > that now somehow seems insufficient. > > Peter > OSR > > > — > NTDEV is sponsored by OSR > > 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 >
Anyone who is serious about this business should write an OS, or work deep
inside one. I’ve written one, been part of a team writing another, and
worked inside file systems on a third. There’s nothing quite like writing
context-swap code (or trying to understand it at the lines-of-code level)
to really teach you about an OS! In my case, it was trying to understand
a multicore boot and how it “booted” the other processors. The code
looked “dodgy”, and two of us were trying to figure it out. The other guy
figured it out first. It was code hatt had been “sort-of” running for two
years.
Good for you!
joe
It was for fun and education at my spare time while my labor was cheap and
I don’t have kids and wife.
In my early days as a programmer, most of my coworkers have a degree in CS
while I don’t. I was so clueless while they talked about threading,
scheduling hash, queue, bin-tree. Most of my programming skill are
procedure control based or implementing DSP algorithms. So I figured
writing a hobby OS is a great way to learn OS.
Hi Peter,
I have faced similar issues before in which file is encrypted and it’s difficult to reverse statically .That’s why I wanted to know the technique to debug similar problems.I ll try out by setting breakpoint on MmLoadSystemImage… Thanks for your suggestion
