This isn’t technically driver related but close enough because of the signing issues.
A couple of years ago, MSFT released module code integrity to prevent injections into protected processes, mainly Edge.
“Starting with EdgeHTML 13, Microsoft Edge defends the user’s browsing experience by blocking injection of DLLs into the browser unless they are Windows components or signed device drivers. DLLs that are either Microsoft-signed, or WHQL-signed, will be allowed to load, and all others will be blocked. “Microsoft-signed” allows for Edge components, Windows components, and other Microsoft-supplied features to be loaded. WHQL (Windows Hardware Quality Lab) signed DLLs are device drivers for things like the webcam, some of which need to run in-process in Edge to work. For ordinary use, users should not notice any difference in Microsoft Edge.”
https://blogs.windows.com/msedgedev/2015/11/17/microsoft-edge-module-code-integrity/
While some may not like dll injections, there are legitimate purposes for the capability (security, testing and automation, instrumentation, shims, etc). There’s a reason MSFT released Detours after all. Anyway, during some testing today the debugger broke with this.
/******************************************************************
- This break indicates this binary is not signed correctly: \Device\HarddiskVolume1\mydll.dll
- and does not meet the system policy.
- The binary was attempted to be loaded in the process: \Device\HarddiskVolume1\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorsvw.exe
- This is not a failure in CI, but a problem with the failing binary.
- Please contact the binary owner for getting the binary correctly signed.
/******************************************************************
Even though our dll is EV signed because mscorsvw.exe is a protected process it can’t load. Not that mscorsvw needs to be injected by our dll (I plan to add it to our exemptions list) but if MSFT is going to implement these restrictions I would hope that they would still offer a way for legitimate purpose such as attestation signing via DevPortal.
So my question is anyone aware of plans to have a process for non device driver DLLs like there is for drivers or LSA plugins? CI is a few years old and if nothing has come out yet my guess is no but wanted to ask the community anyway. The real issue will be if MSFT expands the list of protected processes because it’s going to make solutions have to find hacks or use other techniques like reflective loading.