KPH Driver signing

[DavidXanatos]

Hello!

I wanted to inquire how is the status on signing a new KPH driver?
Could the signing issues with MSFT mentioned in the #773 discussion be resolved?
If not, I would kindly ask you to elaborate on how the Signature process fails:

1. Is only the KPH driver affected or anything that you try to sign using your account ?
2. Have you tried renaming the driver and removing the word hacker?
3. If that did not help, have you tried removing parts of the functionality to pin point what code portion is caught by some automated mechanism?

I would think that MSFT may mostly object to the ability to kill protected processes, may be it would be worth doping that ability if anything else would pass. For me the most important use cases of the driver is to get information about whats going on deep in the system and not process termination/manipulation.

I'm asking because I have access to an EV cert to and am considering signing a forked driver for my TE, but I'm very worried that might result in MSFT blocking the cert for any future use what would be quite a catastrophe as I need it for sandboxie.

[dmex]

KPH driver affected or anything that you try to sign using your account

I never found out because Microsoft refused to share any information about the failures. They suggested asking random users on their forums:

have you tried removing parts of the functionality

Well Microsoft have told us to remove features from the driver or we'll keep getting banned and won't help with the submissions and there's no guarantee they won't pull the same stunt again even after we make those changes.

There are no published polices or guidance here, they're just making seemly random decisions and using HVCI blocklists to extort changes from third parties when they feel like it.

I would think that MSFT may mostly object to the ability to kill protected processes

That feature is included with both Process Explorer and the Microsoft SAC toolkit. We compete directly with Process Explorer so there's some discussion about why we're blocked/targeted while the exact feature in their software is allowed.

My personal opinion here is that PH is a task manager, terminating processes is what a task manager does, that's the number one primary purpose for a task manager to exist and we're using functions designed for terminating processes the way they're supposed to be used exactly as we should be doing.

A web browser that can't surf the internet isn't a web browser, it's a scam. A task manager that can't terminate processes isn't a task manager, that's a scam. Task managers only terminate, they do not stop or block processes from restarting, even after you've terminated the 'protected process' the kernel driver continues scanning and protecting the machine. That process can restart and continue but instead Microsoft have stopped doing this to give themselves a reason to block third party task managers.

Literally nobody except Microsoft (and malware) has issues with process termination:

The entirely of the "protected process" feature is based on a single byte in the EPROCESS structure that can be patched and modified by everything and everyone without triggering patchguard or any security software and completly block termination for every process - When I previously worked at Electronic Arts on the Origin client between 2011-2016 and BattlEye anti-cheat from 2018-2019 this was an extremely common attack vector that I saw abused thousands of times daily and even today is still a very common attack vector.

Essentially what's happening here is that Microsoft are making task managers more susceptible to attacks patching EPROCESS and attacks injecting code+hooking ntdll functions making us unreliable and abused simply to bolster their security products, the only software on the platform able to terminate processes will be their security products effectively killing the entire market (and sole purpose) for task managers to exist.

Ideally we would preform a signature check on the target process and verify it's for a security product and block termination but Microsoft hasn't exported the functions required for verification and has instead instigated an egregious power grab and shutdown competitors.

Even in the latest discussion with them about #997 they're still not allowing us to implement functions we need to properly check processes and instead demanding the removal of the driver ioctls. They've also never provided any information or assistance that would help defend against attacks because otherwise they have no excuse to continue blocking competitors products... CrowdStrike has been the only company to reach out and provide help here, so for me it's obvious that Microsoft would rather destroy competitors instead of improving the platform to the benefit of everyone.

They've literally been doing everything they can to destroy task managers over the last few years, they'll be coming for your Task Explorer fork of PH soon as well.

[DavidXanatos]

I never found out because Microsoft refused to share any information about the failures. They suggested asking random users on their forums:

Well but can you compile and upload a hello world driver that does not do anything but print a DbgPrint message and get it signed on your account that fails for kph?
Could you please test that and tell us if that works, because if that works it means they did not block your account just something KPH specific.
So for otters with an EV cert it means we could try to sign a fork without worrying about our acc getting blocked.

Well Microsoft have told us to remove features from the driver or we'll keep getting banned and won't help with the submissions and there's no guarantee they won't pull the same stunt again even after we make those changes.

What features did they tell you to remove?

I would think that MSFT may mostly object to the ability to kill protected processes

That feature is included with both Process Explorer and the Microsoft SAC toolkit. We compete directly with Process Explorer so there's some discussion about why we're blocked/targeted while the exact feature in their software is allowed.

I have tested Process Explorer and it can not kill all types of protected processes while Process Hacker can kill any type.
Process Explorer can kill "Windows" but not "WinTcb" or "Antimalware", i did not have processes of other types to test with.

And SAC well SAC needs a com port connection or hardware support for Serial over LAN, so its nothing a software attacker on the system could try to exploit

My personal opinion here is that PH is a task manager, terminating processes is what a task manager does, that's the number one primary purpose for a task manager to exist and we're using functions designed for terminating processes the way they're supposed to be used exactly as we should be doing.

A web browser that can't surf the internet isn't a web browser, it's a scam. A task manager that can't terminate processes isn't a task manager, that's a scam.

A hammer of a given size can only hammer in nails up to a given diameter, it cant handle a 1inch wide nail, if its just a 100g hammer. that does not make the hammer a scam it can handle small nails just fine.

So a task manager that can kill everything that is not a protected process is still a task manager, just not a heavy duty tactical assault task manager LOL

.. but instead Microsoft have stopped doing this to give themselves a reason to block third party task managers.

Do you have any insight why MSFT would be against 3rd party Task Managers?

I know that malware that makes its way into the kernel can abuse the EPROCESS structure to make its processes un-killable, but from MSFT's standpoint that should not have happened, and they are trying to prevent this from happening with their even more and more draconian driver signing policies. From their point of view a user mode application should not be able to kill a protected process eider (at least not some types of those) so allowing someone to sign a driver that does that would be like well two wrongs don't make one right.

I mean I also don't let MSFT dictate what's running on my PC in ring 0 and what not, but for the masses MSFT has the absolute monopoly on ring 0 under windows and for all users, that don't turn on testsignign or install efiguard, they have the final say in what goes and what not.

I don't think its realistic to win this and force them to sign a driver with abilities they don't want to allow, I don't know what else aside the PPL termination capability MSFT wanted to be gone but if that was the only request, to be honest, I would just comply with that. I would put not inconveniencing the users over sticking to principles. For the users that can't use the current driver its better to have a castrated driver than no driver at all.

Also if you want to be able to kill at least some types of PPL processes, why not add support for the Process Explorer driver, if it does not have any security, it could be leveraged to so what kph is not longer allowed to, and since its free from MSFT just add a downloaded plugin to PH that download PE extract the driver and use it, or would that be against the PE EULA? I have never read it, LOL!

An other option would be to go with providing a castrated but signed KPH driver for the masses and a fully features but unsigned KPH driver for those that need this, or even better bundle a fork of efiguard that would allow to load a not MSFT signed PKH driver but no other unsigned drivers.

Cheers
David

[DavidXanatos]

I never found out because Microsoft refused to share any information about the failures. They suggested asking random users on their forums:

Well but can you compile and upload a hello world driver that does not do anything but print a DbgPrint message and get it signed on your account that fails for kph?
Could you please test that and tell us if that works, because if that works it means they did not block your account just something KPH specific.
So for otters with an EV cert it means we could try to sign a fork without worrying about our acc getting blocked.

It would be really great to get an answer on this question.

[dmex]

What features did they tell you to remove?

Process termination. We already removed other termination methods years ago but now the official ZwTerminateProcess:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/nf-ntddk-zwterminateprocess

Based on what employees have said on twitter we'll also have to remove coherency checking and paged/nonpaged pool information as they're both reading binary images via the driver.

I have tested Process Explorer and it can not kill all types of protected processes while Process Hacker can kill any type.
Process Explorer can kill "Windows" but not "WinTcb" or "Antimalware", i did not have processes of other types to test with.

PE can kill protected processes via ioctl which we've reported and are waiting for a response from Microsoft.

SAC well SAC needs a com port connection or hardware support for Serial over LAN, so its nothing a software attacker on the system could try to exploit

SoL is enabled by default via SPCR table in the firmware which also enables SAC by default. There is no security here whatsoever and the point is that we're being forced to remove features that Microsoft itself includes with their own products.

task manager that can kill everything that is not a protected process is still a task manager, just not a heavy duty tactical assault task manager LOL

Protected processes include store apps, store games, dosvc (store downloader), WSL and other non-security related processes. It is a significant reduction of functionality compared to what's available with our competitors and Microsoft's own products.

From their point of view a user mode application should not be able to kill a protected process

We've reported and provided samples for UM processes terminating 'protected' processes without a driver and are waiting for a response from Microsoft.

I know that malware that makes its way into the kernel can abuse the EPROCESS structure to make its processes un-killable, but from MSFT's standpoint that should not have happened, and they are trying to prevent this from happening with their even more and more draconian driver signing policies

The problem isn't just kernel malware.... The primary reason for using a driver is to avoid calling usermode functions which are hooked and blocked by malware - without a driver it's extremely quick and easy to abuse hooking to make every process unkillable and leaves PH unable to terminate any process since we're now vulnerable to injection attacks.

I don't think its realistic to win this and force them to sign a driver with abilities they don't want to allow,

You're saying text editors shouldn't edit text and web browsers shouldn't browse the internet?

No security company has issues with task managers terminating processes except Microsoft... We're using functions included in official Microsoft documentation for process termination (ZwTerminateProcess), the same functions our competitors are using, how they're supposed to be used, for the exact purpose they were designed.

We didn't just add this stuff yesterday and are now upset... We added that function almost 14 years ago per svn/git commit logs and Microsoft products have been using that same function in their products for almost 30 years.... Task managers terminate processes, that's their job and we have a very strong use-case for using functions for process termination considering PH is a task manager designed to terminate processes, unlike a web browser or text editor.

Do you have any insight why MSFT would be against 3rd party Task Managers?

They're using so many undocumented functions and privileges with Task Manager that industry regulators would force the company to provide third parties... Auto-elevation, signature checks, DirectUI, CVChart, EDP-API, SRU-API, NT-API, Kernel32, User32... not to mention ballot screens and options to change the default task manager. Executives and managers were prosecuted and convicted in previous cases so they're trying to make out the project is just some malicious software in an effort to undermine our legitimacy as a competitor and prevent regulators from investigating and prosecuting while also preventing third parties from having the same privileges as their own task manager products.

An other option would be to go with providing a castrated but signed KPH driver for the masses

The current versions of the driver are the castrated versions........ We removed a shit-ton of driver functionality that was included between 2008-2016 to comply with the Windows security model. We also checks for SeDebugPrivilege and signature checking that require administrative privilege - Microsoft doesn't even include those checks with SAC or Process Explorer which can both terminate PPL.

if that works it means they did not block your account

I only bought a 12 month certificate and couldn't sign with it so it was refunded... Microsoft blocked my account during an email conversation in 2018 after claiming our repository was being monitored and I was involved in attacks... I later found out the driver signatures were also added to an internal blocklist after trying to submit to the store and the winget team (#620) leaked details about it.

They've also deleted 5800 or so comments and replies on their forums between 2003-2018 from long before I joined this project that were helping others with all sorts of issues users - they once gave me a glass trophy award for 2009 community contributor for those posts so they're doing their best to erase our existence and pretend that we just appeared yesterday like some malware.

[DavidXanatos]

Protected processes include store apps, store games, dosvc (store downloader), WSL and other non-security related processes.

that is strange on my windows system only a hand full of core system processes are protected, i have never seen a protected store or WSL process.

I don't think its realistic to win this and force them to sign a driver with abilities they don't want to allow,

You're saying text editors shouldn't edit text and web browsers shouldn't browse the internet?

I'm only saying that some fight's you can't win, like this, eider you get some governmental body to win it for you or you just don't win. MSFT has here full control and other than through governmental intervention there is no way to force them.

An other option would be to go with providing a castrated but signed KPH driver for the masses

The current versions of the driver are the castrated versions........ We removed a shit-ton of driver functionality that was included between 2008-2016 to comply with the Windows security model.

So to clarify is the old 3.x driver already castrated? And the 2.xx is the full featured one, or are you talking about the changes since than in order to get a new one signed?

[RossWang]

If we are a company that provides security solutions and claims this is for anti-rootkit, how can Microsoft reject it? We probably need to find a security giant like Trend Micro to support this or even found a security company like PCHunter did.

[ionescu007]

Happy to say the new driver will be EV-signed properly, and we've worked with Microsoft to resolve issues, so will close this now.

[Biswa96]

Just curious. How did you workaround that just by changing name and license?

[ionescu007]

"We've worked with Microsoft to resolve the issues" is what I wrote, not that "just by changing name and license".

[DavidXanatos]

Could you please summarize for me what changes to the driver were required, at some point I'm looking forward to add a properly signed driver to my task explorer as well.