Reading digital signature of self from DriverEntry of boot start driver...

Hello,

I have a digitally signed mini-filter that is configured to load as a boot start driver.

From DriverEntry of this mini-filter, I want to read the digital signature that is stored in the driver binary file.

I see that, the digital signature is not mapped in the address space at the time DriverEntry is called.

I tried to open the self (mini-filter driver file) from DriverEntry, however, that failed since file systems are probably not initialized at that point.

Is there any alternate way to read the digital signature of the self?

Thanks.
-Prasad

A mini-filter can not be configured to load as a boot start since it depends on filter manager which can’t be loaded as a boot start.

Well, that’s not true. Filter manager is a boot start driver and our mini-filter indeed loads as a boot start driver and loads fine.

Thanks.
-Prasad

Absolutely wrong.

<xyz.sun.ok> wrote in message news:xxxxx@ntfsd…
>A mini-filter can not be configured to load as a boot start since it depends on filter manager which can’t be loaded as a boot start.
></xyz.sun.ok>

There is an undocumented callback SeRegisterImageVerificationCallback that gets called when a driver image is loaded. For it to work though, you would have to have a second driver load before the one you actually want verified. I’ve only read about it, never implemented, so I can’t provide any more help than this.

Thanks Paul for the pointer!

However, this probably may not work for me. Basically it becomes a chicken-n-egg problem. If I use second driver then I would need to read digital signature for that driver and then I have the same issue.

IoRegisterBootDriverCallback seems to be providing similar information.

Thanks.
-Prasad

> IoRegisterBootDriverCallback seems to be providing similar information.

I am not sure abou that. IoRegisterBootDriverCallback is supposed to be used by ELAM (Early Launch Anti-Malware) drivers to be able to check boot drivers for malware. ELAM drivers have special requirements, described here:
http://msdn.microsoft.com/en-us/library/windows/hardware/dn265159(v=vs.85).aspx

L.

Do you think the bcrypt interface would be of any help ?
There is also the undocumented CI.DLL kernel DLL that might be interesting to look at.

Hello,

I explored further on this using an ELAM, however BDCB_IMAGE_INFORMATION does not contain the complete signature block. See https://msdn.microsoft.com/en-us/library/windows/hardware/hh406359(v=vs.85).aspx

When the ELAM loads, I could see that all boot drivers are mapped (not initialized yet) in memory, however, signature block is not mapped for any of those drivers.

I am pretty sure that the information in BDCB_IMAGE_INFORMATION is populated from signature blocks. However, there seems to be a deliberate effort to not keep signature blocks mapped? It probably reads it in memory, creates BDCB_IMAGE_INFORMATION structure and then releases the memory to be reused. I attempted to search signature blocks in virtual memory and found some of its traces, however, it was kind of partially overwritten memory.

Other option that worked for me is to defer reading the signature in a reinitialization routine that I register using IoRegisterBootDriverReinitialization from DriverEntry. This works and I am able to read self binary from the reinit routine. Probably, by the time, reinit routine is called, file systems are initialized and hence it works that way. However, doing it from a reinit is too late for my use case.

On other note, I am wondering, how does antimalware vendor do the scans using just the information provided in BDCB_IMAGE_INFORMATION? This information seems pretty limited and doesn’t even provide access to the loaded image of the module rest apart signature block?

Any insight would be greatly useful!

Thanks.
-Prasad