Closed ghost closed 2 years ago
Microsoft changed something regarding drivers in the latest updates of Windows 11
They've banned our digital signature/revoked our certificate in the latest Windows update.
That seems like an awfully targeted attack. Is there anything that can be done at the moment? Perhaps compiling the code and/or signing the driver manually?
Microsoft is no stranger to actively trying to thwart this project, so its nothing new for them.
It seems justified from Microsoft's end since they're close to releasing the new Task Manager and most likely want to squash competition.
"New" is a generous way of putting it, it's more like a fresh coat of paint and a new efficiency mode for Task Manager and that's yer lot.
That seems like an awfully targeted attack. Is there anything that can be done at the moment? Perhaps compiling the code and/or signing the driver manually?
That's not how driver signing works unfortunately and a new cert is expensive and will likely just get revoked again
can we manually trust the certificate or install it in the trusted store so that the driver loads. of course, this will be applicable to people with administrative privileges.
@Masamune3210 You can create a certificate to sign a driver for use on your own machine, this is what I meant by "signing the driver manually".
"You can create your own certificate to sign your driver with during development and testing"
The user signing the driver kinda defeats the purpose of the signature, which is to validate that the driver hasn't been tampered with. But I see your point
You can create a certificate to sign a driver for use on your own machine, this is what I meant by "signing the driver manually".
Microsoft is testing updates on the Windows 11 insider branch that currently prevent developers/security researchers from compiling the driver source and debugging it with test signing. If you're trying to compile the source-code and debug the driver with self-signed test certificates then you need to change this string to bypass those checks: https://github.com/processhacker/processhacker/blob/3e80de2bd64f70b7ec4bde085eea81c3e0f3ff77/KProcessHacker/resource.rc#L23
Its stupid that this is even an issue, there is literally nothing malicious about this program, Microsoft is just being as strong arm-y and "its fine until we say its not" as ever.....
It's worse that this is parroted by AV companies that mark this as potentially unwanted software which throws up "scary" alerts and might even quarantine it. Some AV companies even have designations that literally have the program name as the virus type.
I feel like Microsoft/etc can't get past the stigma of the "hacker" name. I think this is more likely than ProcessHacker competing with a program from their bought-out subsidiary Sysinternals. They don't make any money from ProcessExplorer existing or being used instead of ProcessHacker. There's already an entire thread about the program name, so I'll leave that there.
I can't even imagine where to go to shine meaningful light about this unwarranted discrimination. I feel like it would take some social media giant like LTT/GN/J2C(Youtube channels) to make Microsoft even blink at this issue. (would EFF care about something like this?) Then they still wouldn't even care. We could argue that this is an anti-trust issue, but Microsoft could argue it's several other things.
The error message I get when I try and run with kernel driver includes the line "A certificate was explictly revoked by its issuer"
This has been occuring from a couple builds before 22557 through 22579
Yup, the message has since been updated on my end as well.
My ESET lovingly refers to it as an Unsafe Program. It is the lowest category at least.
A certificate was explictly revoked by its issuer
This is a fake error code. The certificate has not been revoked. Microsoft returns that "error" when encountering drivers with this original filename in the version resource:
The name has since been changed so future versions won't encounter these fake error codes (at least until Microsoft update their illegal blocklist again).
You can create a certificate to sign a driver for use on your own machine, this is what I meant by "signing the driver manually".
So if we want to use the kernel driver we have to do the above?
The name has since been changed so future versions won't encounter these fake error codes (at least until Microsoft update their illegal blocklist again).
I'm on 3.0.4801 (078a905) and the driver name is still the same and being blocked. It looks like you addressed this in commit 22e1f53 but file name is the same.
Obviously you can't be expected to get a new certificate every time Microsoft decides to update their blacklist. I wonder where the blacklist is stored..
Thank you for all your hard work and this amazing tool!
at least until Microsoft update their illegal blocklist again
any idea where this check is? i want to patch this check, load kprocesshacker.sys, then unpatch the check to prevent triggering patchguard
1) Open regedit
2) Navigate to HKLM\System\CurrentControlSet\Control\CI\Config\
3) Create a new DWORD named VulnerableDriverBlocklistEnable
and set to 0
4) Reboot
thank you!
- Open regedit
- Navigate to
HKLM\System\CurrentControlSet\Control\CI\Config\
- Create a new DWORD named
VulnerableDriverBlocklistEnable
and set to0
- Reboot
It seems to work for the first time, but once I reboot, I get this:
@itsmeboy0
No idea. Something is wrong with your machine. Something is probably hooking the kernel and returning invalid error codes.
Really? I tried the stable version, and it works just fine.
@itsmeboy0
Yes. This works for everyone else so it's either your security software or malware.
Fixed: I installed processhacker-nightly
from Scoop. I switched to using the installer, and it now works. So maybe it's how Scoop installs processhacker that makes it not work? Can you confirm this?
Yes. This works for everyone else so it's either your security software or malware.
This is only partially true, if you have HypervisorEnforcedCodeIntegrity enabled this registry key is ignored. This can be checked in winload!OslpLoadRevocationLists.
the last nightly of Process Hacker seems to be "banned" in 22621.457
Does not work when Core Isolation is enabled.
This is really shitty behaviour on MS side.
This is really shitty behaviour on MS side.
Only the MS has the right to put anal probes into your PC. Welcome to half eaten apple club.
Hi, I found a fix for my system. Because I used NTLITE to create a windows install without windows defender, I'm not able to turn of the memory integrity setting from the GUI. instead I did this to fix the problem:
open regedit: and browse to "Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity "
and changed the DWORD "Enabled" from 1 to 0
Might want to keep a eye on that for a bit. Defender tends to see any system modification done outside of the GUI as tampering and will sneakily revert it seemingly at random times
Is there anything that could be done about this? How could Microsoft get away with this? Microsoft's monopoly must end. Windows is becoming so awful.
Is turning this option off:
the same as the fix:
- Open regedit
- Navigate to
HKLM\System\CurrentControlSet\Control\CI\Config\
- Create a new DWORD named
VulnerableDriverBlocklistEnable
and set to0
- Reboot
Brief description of your issue
When enabling the kernel-mode driver Process Hacker informs me that it was unable to load the driver service, as the service in question has apparently been removed and PH is unable to install it, even with cli commands, this also happens with sandboxie, so it's likely that Microsoft changed something regarding drivers in the latest updates of Windows 11.
Steps to reproduce (optional)
Install latest updates from the dev channel on Windows 11. Enable kernel-mode driver
Expected behavior (optional)
The kernel-mode driver should work as it did on previous versions.
Actual behavior (optional)
As stated, the process is unable to be created and thus this function won't work.
Environment (optional)