Hi,
I have a driver that returns C000026C (STATUS_DRIVER_UNABLE_TO_LOAD).
The driver file in question looks perfectly valid, I can open it in
different peviewer tools and open it correctly with no warnings in
IDA.Nothing stands out in its PE headers, like file header, optional header,
import and relocation tables etc.
Using gflags, I turned on the “system-wide” and kernel setting for loader
snaps and don’t see any loader info in windbg. I could see loader snaps for
a user mode process/dll though. windbg doc says that loader snaps for
system-wide and kernel settings should show driver loader snaps.
Is anyone able to see loader snaps for a driver successfully using windbg?
Do I need to turn on some additional flags to enable driver loader snaps?
Also, STATUS_DRIVER_UNABLE_TO_LOAD has a very broad meaning. Is there a way
can I can get a specific reason for this error, like, bad import entry #10
.
I first thought too about checksum. Zeroed it. That didn’t help.
If driver is using an resolved import, in most cases it returns
STATUS_DRIVER_ENTRYPOINT_NOT_FOUND(0xC0000263).
Still, I confirmed all imports are resolved.
Its a 32-bit driver. So, no driver signing issues I expect.
One thing I noticed the driver using a file and section alignment of 0x80,
normally they are 0x200 and 0x1000 for the sector and page size
respectively. Could that be the reason? I’m going to check it anyway. All
the offsets in PE, e.g., relocations, PtrToRawData etc. are based on these
unconventional alignments, which appear to follow PE format specifications.
On Thu, Nov 12, 2009 at 9:42 AM, wrote:
> 1. I think that status code can mean that the driver in question has an > invalid checksum, which usually means that it wasn’t linked with /RELEASE. > > Try ‘dumpbin /HEADERS ’ and see what if Checksum==0. > > 2. Running depends is always a good place to start in these cases, as > well, I think. > > 3. I don’t think that 0xC000026C has to do with driver signing, but what > is the target OS? > > > Good luck, > > mm > > > > > > — > 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 >
Did you build this driver or is this some third party binary that you
think just ought to install on your system?
Mark Roddy
On Thu, Nov 12, 2009 at 10:32 AM, chandra97 97 wrote: > I first thought too about checksum. Zeroed it. That didn’t help. > If driver is using an resolved import,?in most cases it > returns?STATUS_DRIVER_ENTRYPOINT_NOT_FOUND(0xC0000263). Still,?I confirmed > all imports are resolved. > Its a 32-bit driver. So, no driver signing issues I expect. > > One thing I noticed the driver using a file and section alignment of 0x80, > normally they are 0x200 and 0x1000 for the sector and page size > respectively. Could that be the reason? I’m going to check it anyway. All > the?offsets in PE, e.g.,?relocations, PtrToRawData etc. are based on these > unconventional alignments, which appear to follow PE format specifications. > > > On Thu, Nov 12, 2009 at 9:42 AM, wrote: >> >> 1. ?I think that status code can mean that the driver in question has an >> invalid checksum, which usually means that it wasn’t linked with /RELEASE. >> >> Try ‘dumpbin /HEADERS ’ and see what if Checksum==0. >> >> 2. ?Running depends is always a good place to start in these cases, as >> well, I think. >> >> 3. ?I don’t think that 0xC000026C has to do with driver signing, but what >> is the target OS? >> >> >> Good luck, >> >> mm >> >> >> >> >> >> — >> 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 > > — 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
All I can say its a packed malware driver that I’m researching.
On Thu, Nov 12, 2009 at 11:17 AM, Mark Roddy wrote:
> Did you build this driver or is this some third party binary that you > think just ought to install on your system? > > Mark Roddy > > > > On Thu, Nov 12, 2009 at 10:32 AM, chandra97 97 > wrote: > > I first thought too about checksum. Zeroed it. That didn’t help. > > If driver is using an resolved import, in most cases it > > returns STATUS_DRIVER_ENTRYPOINT_NOT_FOUND(0xC0000263). Still, I > confirmed > > all imports are resolved. > > Its a 32-bit driver. So, no driver signing issues I expect. > > > > One thing I noticed the driver using a file and section alignment of > 0x80, > > normally they are 0x200 and 0x1000 for the sector and page size > > respectively. Could that be the reason? I’m going to check it anyway. All > > the offsets in PE, e.g., relocations, PtrToRawData etc. are based on > these > > unconventional alignments, which appear to follow PE format > specifications. > > > > > > On Thu, Nov 12, 2009 at 9:42 AM, wrote: > >> > >> 1. I think that status code can mean that the driver in question has an > >> invalid checksum, which usually means that it wasn’t linked with > /RELEASE. > >> > >> Try ‘dumpbin /HEADERS ’ and see what if Checksum==0. > >> > >> 2. Running depends is always a good place to start in these cases, as > >> well, I think. > >> > >> 3. I don’t think that 0xC000026C has to do with driver signing, but > what > >> is the target OS? > >> > >> > >> Good luck, > >> > >> mm > >> > >> > >> > >> > >> > >> — > >> 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 > > > > — 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 > > — > 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 >
Checksum is ignored for user mode exes. That’s why I tried zeroing it out.
Good to know its verified for drivers.
Its a 32-bit machine. Fixing driver checksum using the link command worked.
On Thu, Nov 12, 2009 at 12:40 PM, Tim Roberts wrote:
> Tim Roberts wrote: > > chandra97 97 wrote: > > > >> I first thought too about checksum. Zeroed it. That didn’t help. > >> > > > > You can’t just zero it. The checksum must be correct. The NT-based > > kernels will not load a driver with a checksum failure. > > > > By the way, you can do this: > > editbin /release xxx.sys > > to fix the checksum on a single file. Or, if you prefer: > > link /edit /release xxx.sys > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > 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 >