Fail to load Madshi drivers in Windows 10 anniversary

[mahtovivek741]

We are using madCodeHook version 3.1.13

I have Madshi divers which i am using for the system level injection, these drivers are not getting loaded in case of Windows 10 Anniversary or version 1607.

As per this version Microsoft signature would be required by Win10 to load kernel-mode drivers in the SECURE BOOT mode. To get that signature, you have to sign a submission using an Extended Validation (EV) Code Signing Certificate and upload your driver package to the Microsoft SysDev portal. You do not need to run or pass any Microsoft certification, logo, or compatibility tests. You just need to sign your driver appropriately, agree to some conditions, and submit your package to Microsoft via SysDev for signature. This procedure is called “attestation signing” because when you upload you declare (that is “attest”) that you’ve tested the driver, will monitor sysdev for driver problems, and will fix any issues that are reported.

I have done all the above procedure and and still my drivers are not being loaded.

[madshi]

The same drivers load fine in other OSs? And they load fine if you disable Secure Boot?

madCodeHook itself doesn't really have any special requirements. If the OS is happy, then madCodeHook is happy. So if the driver doesn't load, it must be a problem with the OS not being happy with the driver file somehow, which is most likely due to the signature. It's pretty hard for me to diagnose such problems. How can we find out what exactly the OS is unhappy with?

[mahtovivek741]

The drivers are working fine with the other OSs, and it works fine if i disable the secure boot. Actually i m doing this in a Hyper-V and i have tried installing it through code and .inf as well, but in both cases when i try to install it i get error `193`(Not a valid win32 application).

I ran the command msinfo32 on the system and found out the following Device Guard properties...

Device Guard Required Security Properties - Base Virtualization Support,Secure Boot
Device Guard Available Security Properties - Base Virtualization Support,Secure Boot,DMA Potection,UEFI Code Readonly
Device Guard Security Services Configured - Credential Guard,Hypervisor enforced code intergity
Device Guard Security Services Running - Credential Guard,Hypervisor enforced code intergity

As i figured out that the issue is not with the signing of the drivers,so i don't seem to understand what's exactly the OS is unhappy with?

[madshi]

If the problem only occurs with Secure Boot enabled, then it very much *does* look like a signature problem. But I'm not really a big expert on what the OS might be happy or unhappy with. This is also not really a problem that is specific to madCodeHook. You would probably have the same problem with any other driver, too.

I wish I knew how to solve this problem, but I really don't. I don't really have any more information about this than you have. I think your best bet is to contact either Microsoft or your certificate provider, and ask them why the OS doesn't like the driver.

If you want to double check if the problem is specific to the madCodeHook driver or not, you can try one of the many CodeProject projects which deal with drivers, e.g. a quick google search showed me these:

https://www.codeproject.com/Articles/60 ... ce-Drivers
https://www.codeproject.com/Articles/20 ... -execution

What I can say is that there are a couple of madCodeHook users who I know have it working with Secure Boot enabled. So it seems unlikely to me that it could be a madCodeHook specific problem.

[mahtovivek741]

Well after further analysis, I see that the problem is with the driver when the device guard is enabled. If I disable the device guard and then try to load the drivers, in that case they are loaded successfully. So drivers can be loaded in the Secure Boot mode, but only when Device guard is disabled.
So what can be done to load the drivers if Device guard is enabled in the secure boot mode, as I double checked the signature, the issue is not with the signing.

[madshi]

Ah, that's interesting. It's possible that the Device Guard has some additional requirements. I'm working on a new official madCodeHook version, which should be released very soon now (maybe in 1-2 days or so). This build will have improved drivers which pass all the latest Microsoft "special" tests. There's a chance the new driver will satisfy whatever Device Guard requires - if it's really not signing related.

[mahtovivek741]

So i guess that these drivers are tested in the Secure Boot mode with device guard enabled?

[madshi]

I haven't personally tested them with Device Guard, but they passed the Microsoft HLK tests, and a big customer of mine tested with with Credential Guard and the new drivers worked.

[mahtovivek741]

Is this going to be the 4.x release or 3.x? We are still currently using 3.x and it will take us a longer cycle to change to 4.x.

[madshi]

It will be for both 3.x and 4.x. But at some point in the near future I'm going to stop updating 3.x.

[mahtovivek741]

Is it available now, the new MadCodeHook that works fine with Device Guard ? I wanted to test on my test machine wherein driver installation is getting failed if Device guard is enabled on win 10 machine.

[madshi]

Just uploaded the new official build here:

http://madshi.net/madCollection.exe (installer 2.8.4.0)

[mahtovivek741]

Thanks... I tested with the new drivers, they working properly when device guard is enabled and EV signing was not required.

[madshi]

Glad to hear that!

[GeoffJohnson]

HI,

Do you have any further detail on the HLK changes. We've been passing the HLK test with version 4.0.2 for a while now and have had Microsoft sign the driver.

Thanks.