madshi.net

I 've been reading about the new requirements for kernel drivers on windows 10:

- all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal. Windows 10 will not load new kernel mode drivers which are not signed by the portal.

- the portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.

That is really horrible and expensive!!!!

The thing is that on my tests my madshi driveris working with a recent signature using the standard way (cross certificate) on windows 10 without all of that.

Does anyone knows what is going on???


source:
https://blogs.msdn.microsoft.com/window ... indows-10/

You'll find more information here:

https://blogs.msdn.microsoft.com/window ... sion-1607/

Basically you need EV code signing for SecureBoot compatability with new Windows 10 installations. I'm not happy about these crazy new Microsoft ideas, either, but what can we do?

FWIW, the upcoming madCodeHook 4.0 will have an improved driver which will no longer require you to reconfigure and resign it, every time you recompile the hook dlls. Instead the driver will compare the signatures of the driver and hook dll files, and if they match, the dll will be considered "trusted".

I was about to send you that link..
the news on madCHook 4 are good. The bad thing is:
- Will Microsoft aprove a generic driver that injects code?? Any success case?
- EV certs are VERY expensive!!

there is something I don't understand on this exception:
"Drivers signed with cross-signing certificate issued prior to July 29th 2015, when the initial policy went into place, will continue to be allowed"

You consider they refer to the issuing date of the cross-signing certificate or my personal cert??
Globalsign cross certs are much older that that so it should work I think...

cyberproject wrote:Will Microsoft aprove a generic driver that injects code??

There are various ways to inject DLLs. Some of them are offered by the OS itself, e.g. see AppInit_Dlls. madCodeHook's DLL injection driver is just one more method to inject DLLs. Why would they not approve? Anyway, I don't think they actually perform any tests on the drivers.

cyberproject wrote:You consider they refer to the issuing date of the cross-signing certificate or my personal cert??
Globalsign cross certs are much older that that so it should work I think...

I don't know.

I think they refer to our the certificate, not the cross-signing certificate.
As seen here:
A cross-signed driver using a SHA-1 certificate issued prior to July 29th, 2015 will work on all platforms starting with Windows Vista through Windows 10.
A cross-signed driver using a SHA-1 or SHA-256 certificate issued after July 29th, 2015 is not recommended for Windows 10.

source: https://msdn.microsoft.com/en-us/librar ... igning_FAQ


What is still unclear is if after certificate validation, the cert would still work if correctly timestamped...

so,
no new signed drivers will work on fresh windows 10 w/secure boot unless they were aproved by Microsoft and signed with an EV cert to apply..

If someone was able to get this with Microsoft please let us know!

There's some more information in this (long) thread:

viewtopic.php?f=7&t=28050

thanks, took some thing out of the thread:
- Buying a 50% disc. EV cert
- Testing secureboot on a VM using Hyper-V

I have a crazy idea to avoid all this horrible thing, that many of us may not be willing to do:

- The driver is always the same for everyone, so you could do this Microsoft thing once for all of us with your certificate.
- To avoid malware utilization, you could make the driver work only if it is signed by your costumers, like it is now. Ony that this would be a second signature (signtool.exe with /as option)

what do you think?

thank you

I don't think that would work. I think the Microsoft EV signing must be done last. In any case, I would not be comfortable with signing a driver with my certificate and then make it available to every madCodeHook user.

madshi wrote:There are various ways to inject DLLs. Some of them are offered by the OS itself, e.g. see AppInit_Dlls. madCodeHook's DLL injection driver is just one more method to inject DLLs. Why would they not approve?

Which injection technique does madCodeHook injection driver use to inject a DLL into the user-land process, is it the APC?

madshi wrote:Anyway, I don't think they actually perform any tests on the drivers.

So, you're saying that they don't actually perform any thorough tests on the driver. Since you have to send a compiled driver to the dashboard, they would have to reverse engineer the driver in order to determine what exactly it does. But since there are probably multiple drivers send to the dashboard daily, they don't have the time to do it manually, while the automatic detection isn't good enough to detect a lot of things.

However, if they upgrade the detection techniques in order to detect that madCodeHook is injecting a DLL into the user-mode processes, can they nevertheless mark the certificate as malicious? For example, if we sign the madCodeHook with our own certificate and ship the driver to customers, then some kernel endpoint protection detects it's being used to inject a DLL and marks the driver as malicious, which eventually gets sent to cloud for analysis and after some time gets into the Microsoft's hands. After their team analyzes it manually, they will confirm it's injecting the DLLs into the user-mode processes and blacklist our own certificate (since this is the certificate with which the driver was signed). The end result would be that none of the other things signed by the same certificate will be valid anymore and all of a sudden every product across the world will not be able to work, since the certificate validation/signing will not be valid.

I hope I'm not overly concerned about all this, I would just like to understand things in details.

Injecting a DLL is not a malicious act. Injecting a *malware* DLL is a malicious act. There are even win32 APIs available (like SetWindowsHookEx) which inject DLLs. Or check out "AppInit_Dlls". Microsoft's own "Detours" hooking package also injects DLLs. Most (all?) of the anti-virus products inject their DLLs, too. Some of them are using madCodeHook for that, others have their own DLL injection solution.

madCodeHook 4.0's release version DLL injection technique is based on APCs, but I'll have to go back to the old 3.x injection technique (temporarily) because some anti-virus products like Kaspersky do weird things which result in APCs being executed too early, which results in my APC DLL injection technique crash. I'll work on a different new method for a future 4.x build.

DLL injection only gets a bad reputation because malware authors utilize the technology to raise havoc on a system or online game cheating to get the competitive edge. The actual premise of DLL Injection is benign and is supported by Windows OS directly (SetWindowsHookEx, AppInit_DLLs registry key etc. as Madshi pointed out). DLLs are the fundamental building blocks of the Windows OS and all that is happening is a call to LoadLibrary inside the process you want to enter the address space of (speaking NT solely here). Again, I agree with Madshi here, a DLL's intentions are what we need to analyze when we determine whether something is malicious or not.

--Iconic