[Tigzy]

Hello

My idea is to load into kernel memory a dump of atapi.sys to see non patched original IRP adresses.
I tried to make a copy of the file , and to load it with NtLoadDriver, but I got a 0xC000025E (STATUS_PLUGPLAY_NO_DEVICE) error : "You have attempted to load a legacy device driver while its device instance had been disabled."

I guess this is not simple as that...
How could I do to load this driver into memory? Or anyone got an idea on how I can find IRPs adresses?

[EP_X0FF]

Sorry but your idea is hilarious. Use pe loader instead.

[rkhunter]

My idea is to load into kernel memory a dump of atapi.sys to see non patched original IRP adresses.

Probably, you want say "load into kernel memory a clean copy of driver"...

I tried to make a copy of the file , and to load it with NtLoadDriver

What reasons of call NtLoadDriver for that image?

How could I do to load this driver into memory?

ZwCreateFile/ZwReadFile, next loads it as PE for execution.

Or anyone got an idea on how I can find IRPs adresses?

Small length disasm with DriverEntry analyze will help you.

[Tigzy]

Sorry but your idea is hilarious. Use pe loader instead.

Yes, maybe I misunderstood some things. I can understand someone's errors may be funny for some... :D

Probably, you want say "load into kernel memory a clean copy of driver"...

Yes, exactly.

ZwCreateFile/ZwReadFile, next loads it as PE for execution.

Yes, but with this no DRIVER_OBJECT will be created, and so I will not get the corresponding structure to find IRP majors functions.

Small length disasm with DriverEntry analyze will help you.

Yes, I though about it, but the disass engine is really heavy to do...
If I got no choice, I'll try some libs

[EP_X0FF]

Simple pe loader + ldasm. Problem solved.

[rkhunter]

Yes, but with this no DRIVER_OBJECT will be created, and so I will not get the corresponding structure to find IRP majors functions.

For you will have a valuable only major functions table from driver object, others you can copy from the original object.

[Tigzy]

Ok, I believe you.
But I would like to know WHY it's not possible to load a second driver image with different name into kernel memory?
I saw some ARK were loading some "atapi_dump.sys" module. There is a way to do this, no?

@rkhunter: I'm afraid not to understand what you mean... If original object is compromised, what for?

[rkhunter]

I saw some ARK were loading some "atapi_dump.sys" module. There is a way to do this, no?

Actually, this is copy of original driver that system uses in unexpected situations. If you look windbg, it displays it too.

If original object is compromised, what for?

Compromised irp handlers dispatch table you mean...

[EP_X0FF]

Ok, I believe you.
But I would like to know WHY it's not possible to load a second driver image with different name into kernel memory?

Drivers might have initialization routines which can be called from driver entry routine and returning failure status, for example if some resource already exists or allocated, resulting in driver load fault. While custom pe loader will load rw image into memory and virtually rebase it on given address, which will be useful for further ldasm operations.

[Tigzy]

Compromised irp handlers dispatch table you mean...

Yes, the dispatch table of the DRIVER_OBJECT, which holds all the handlers addresses.
For inline hooks in handlers, this is not a problem as I got the original offset, I can read into the module on disk.

http://www.osronline.com/ddkx/kmarch/k112_6jaq.htm

PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION+1]

for example if some resource already exists or allocated, resulting in driver load fault

Ok. So I have no way to simulate a new DRIVER_OBJECT fill in.