KPH [The Hardening] [Project Update]

[jxy-s]

We're updating the kernel driver functionality (KPH). The focus of these changes will include hardening KPH with extra protections and provide more information to be displayed in PH.

Updates and announcements will be posted on the issue page.

If you have questions or feature requests post them here.

[dmex]

Windows 7 and 8 support will be dropped in the next update.

The other KPH updates include:

• Nested Job object support.
• Improved file names for console device handles.
• Improved thread stack walking.
• Improved service logging.
• Improved firewall/network logging.
• Performance improvements.

Some might not be included in the next update but likely included in later updates.

[Biswa96]

If Windows 7 support will be dropped, I would suggest to make a tag/release for that only. We're talking about 100M PCs 😜

[dmex]

@Biswa96

We're talking about 100M

Telemetry shows Windows 7 is only 14% of users and falling:

suggest to make a tag/release for that only

Windows 7/8 might still be supported client-only but driver support won't be continued. If the support for Windows 7 and 8 is dropped then it'll be the same situation as XP and Vista with downloads added to the Legacy Operating Systems:
https://processhacker.sourceforge.io/downloads.php

[MagicAndre1981]

I till use Windows 8.1 as my main system. It is rock stable and not so buggy as hell as Windows 10.

[trparky]

Windows 10 is no less buggy than any other version of Windows.

[diversenok]

I wonder: what is the point of doing a domination check on the protection level if PH cannot pass it? You can merely say that it removes the functionality, yielding Process Hacker useless against malware that somehow toggles process protection on itself. So, perhaps, you're planning to let PH run as a protected process, and KPH Hardening is one of the steps to make sure nobody can misuse this functionality?

[jxy-s]

For the time being, yes. This is to mitigate abuse of PH to disable protected processes. Eventually by some means we plan to give back the functionality to process hacker.

[MPeti1]

I've recently read on an other project that MS is again making it harder to get your drivers signed so that Windows will load it without the user first disabling certain system protections. After that happens, how will you release new updates to the driver?

[DavidXanatos]

Please do not drop windows 7 support, what would be the point of that anyways?
I can't imagine keeping these support would be so much extra maintenance afford.

btw: what are you using for these telemetry?

[DavidXanatos]

I had a look into the recent changes and it seams you have removed the ability to disable client process signature verification all together.
May I suggest to give the user back the option to use the driver in an insecure way if he so chooses by disabling all safety checks except requiring admin or debug privileges by the calling process, if the system is started in test signing mode.

In such scenarios the user could just run an unsigned driver with all safety checks disabled anyways, but that would be work and afford to do, so adding this functionality to the original driver would be very useful for many people.
You would only need to query

    SYSTEM_CODEINTEGRITY_INFORMATION sci = {sizeof(SYSTEM_CODEINTEGRITY_INFORMATION)};
	if(NT_SUCCESS(ZwQuerySystemInformation(/*SystemCodeIntegrityInformation*/ 103, &sci, sizeof(sci), NULL)))

and act accordingly.

Also it would be a nice improvement to add a KernelDbgView functionality to the driver and client process as I did for TE, see: https://github.com/DavidXanatos/TaskExplorer/blob/master/ProcessHacker/XProcessHacker/log.c

[DavidXanatos]

Interesting driver,
is the process termination feature of PH the only thing MSFT has a problem with?
I mean if its the only thing they don't like, may be its worth moving that feature into a separate tool or a plugin with an own unsigned driver?
Also changing the name would be an option, if than all the problems can be avoided.

[dmex]

the only thing MSFT has a problem with

MS refused to discuss anything and have ignored every email so who knows what their problem is.

if its the only thing they don't like

It's not the only thing.... There are recent changes to APIs that block and limit features when the caller isn't taskmgr.exe.

Either way this discussion is offtopic from the KPH updates.

[AzAgarampur]

Can ProcessHacker.exe be signed as PPL via a certificate, and then KProcessHacker use PsGetProcessProtection in IRP_MJ_CREATE to make sure caller is protected? This way no other random caller can use the driver.

[roblabla]

Can ProcessHacker.exe be signed as PPL via a certificate

AFAICT, there are only two kinds of processes that can elevate to PPL:

• Processes signed by microsoft themselves, only for their own binaries
• Processes signed by a certificate contained within an Early-Launch Anti-Malware driver (ELAM), see Protecting Anti-Malware Services.

The former is obviously impossible for ProcessHacker, and the later requires an ELAM driver, which comes with tons of strings attached.

[jxy-s]

I want to provide an update here.

I have been working Microsoft to ensure the next release of System Informer is shipped with a driver that complies with their requests.

I have updated the driver with enhanced mitigations. I have also added some of the suggested functionality here. This is not yet fully complete. It has not been merged into the main repo yet. I will be adding more features to the driver over time.

I will be providing a signed driver to the HVCI team prior to shipping to ensure they are on-board with the changes.

I had previously wanted to target only Windows 10+ with the new driver. I'm pleased to say I will be providing limited support for Windows 7 SP1 through Windows 8.1. However long-term support for those legacy OSes is not happening. Meaning the driver will function on those OSes but is not fully supported/maintained.

[AltF5]

Only the person that helped revise Windows Internals books into edition 6 & 7. Alex is awesome and one of the best Security Researchers and OS devs, in the likes of a hybrid between James Forshaw and Mark Russinovich

https://twitter.com/aionescu/status/1536494552105766912

It’s in great hands.

I don’t want to @ mention those persons here since they consider doing so as spam to @ the code maintainers directly If they haven’t commented. But they have been involved here for years prior.

I highly recommend you follow him on twitter and also the other person he mentioned in that tweet: yarden

Twitter is good for the latest and greatest Sec news. Dmex (Stephen) doesn’t have a twitter but there is @ ProcessHacker which may or may not be run by him… there is also a newly created @ SystemInformer probably by Alex. If you don’t already follow jxy and diversenok on twitter then I’d recommend them as well for the latest news 🗞 when announced

Regarding wj32 he’s unfortunately no longer involved at least since 2017/2018 or so and dmex is his successor.

Regarding what happened, here’s a humorous, but confirmed true, take on the “order of operations”
https://twitter.com/gabriellandau/status/1536730125886267393

Regarding MS’ involvement: only as involved as getting a WHQL-signed driver. Things are already less malware like by getting away from the “hacker” perspective and renaming a lot, but to avoid having people enable TestSigning mode a signed driver will make things more legit. Note it wont be an ELAM-signed driver (Early Launch Anti Malware) which could make PH PPL (Protected Process, only terminate or or accessible from other PPLs).

Disclaimer: I’m a power user, and not associated with the core maintainers, other than DM communication with them on twitter (for those that have it)

[DavidXanatos]

IMHO this is a very promising development, I'm quite optimistic for a bright future of this project.
Just the name sounds a bit boring, but then finding a new unique name for a task manager is not that easy, all the good once were taken decades ago. And to clean up with the bad hacker image it probably needed to sound as harmless as possible. System Spy sounds suspicious, already, anything with hacker is a no go, etc....
But it might have been a better choice to call it System Insider, Informer sounds so very STASI like LOL. On the other hand System informer really does what it says it does, it snitches on the system to the user LOL.

[jxy-s]

@dmex and I will continue to maintain and run the project. We're not going anywhere :).

[AltF5]

Trust me “Insider” is not less evoking than “hacker”. Arguably more red flagy 🚩

[MPeti1]

Thank you all for the responses, this sounds pretty good! keep up the good work! :)

[jxy-s]

I've posted a pull request for this work (#1320). Not all the improvements we've wanted to make have been implemented. Those will come in future work.

[jxy-s]

I had previously wanted to target only Windows 10+ with the new driver. I'm pleased to say I will be providing limited support for Windows 7 SP1 through Windows 8.1. However long-term support for those legacy OSes is not happening. Meaning the driver will function on those OSes but is not fully supported/maintained.

Turns out that signing a driver to support Win7 is going to be logistically impossible for us right now. Due to these signing restrictions and telemetry indicating that a miniscule number of users are on legacy OSes or use 32bit. We are only going to release for x64 and AMD64 Win10 and above.

That said, I'm going to keep the code which supports the legacy OSes in the repo for the time being. So those using or doing research on those OSes may build and use the driver themselves.

For reference:
https://techcommunity.microsoft.com/t5/windows-hardware-certification/changes-to-driver-publication-for-windows-7-sp1-windows-server/ba-p/2459992
https://techcommunity.microsoft.com/t5/windows-hardware-certification/changes-to-driver-signing-for-windows-7-windows-server-2008-r2/ba-p/2460039
This new process is only for HCK drivers, which we are not, and will end in January anyway.

[Masamune3210]

Besides, I don't believe windows 7 support is any meaningful amount of extra work, at least that's what I learned form over 2 years of Sandboxie development.

Sure, that's because Sandboxie is an older program that was written back in the day when Windows 7 was new. If you were to decide to do a new, from the ground up, version of Sandboxie, I imagine you're going to be in for a headache and a half.

Guess what Process hacker is also quite old, so just leave the win 7 code in and keep supporting it till kingdom comes.

Time is not a infinite commodity and the longer code sits around, the more time it takes and the harder it gets to work around. If you want to keep support, nobody is stopping you from just not updating to the new version if one comes out that drops support. Or, even better, if you see the value in keeping support, the project is open source, feel free to contribute help to keep the support

[DavidXanatos]

@Masamune3210 the header of the relevant fiel says its auto generated, but o cant find the tool online so the devs have a tool that makes extracting the relevant offsets easy, hence my request for them to provide the offsets for windows 7 and 8.1. If they prefer to make the tool public that would be even better.

[dmex]

@jxy-s could you provide the KPH_DYN_CONFIGURATION for windows 7 x64 and 8.1 x64 please.

It's been here since the first release?

systeminformer/kphlib/kphdyn.xml

Lines 244 to 321 in 018b5c1

	<data name="6.1.7601.22730">
	<field value="6" name="MajorVersion"/>
	<field value="1" name="MinorVersion"/>
	<field value="1" name="ServicePackMajor"/>
	<field value="18519" name="RevisionMin"/>
	<field value="18519" name="RevisionMax"/>
	<field value="0x14" name="EgeGuid"/>
	<field value="0x200" name="EpObjectTable"/>
	<field value="0x20" name="EreGuidEntry"/>
	<field value="0x10" name="OtName"/>
	<field value="0x28" name="OtIndex"/>
	<field value="2" name="CiVersion"/>
	<field value="0x10" name="AlpcCommunicationInfo"/>
	<field value="0x18" name="AlpcOwnerProcess"/>
	<field value="0x0" name="AlpcConnectionPort"/>
	<field value="0x8" name="AlpcServerCommunicationPort"/>
	<field value="0x10" name="AlpcClientCommunicationPort"/>
	<field value="0x28" name="AlpcHandleTable"/>
	<field value="0x10" name="AlpcHandleTableLock"/>
	<field value="0xd0" name="AlpcAttributes"/>
	<field value="0x0" name="AlpcAttributesFlags"/>
	<field value="0x38" name="AlpcPortContext"/>
	<field value="0x168" name="AlpcSequenceNo"/>
	<field value="0x16c" name="AlpcState"/>
	</data>
	<data name="6.1.7601.18519">
	<field value="6" name="MajorVersion"/>
	<field value="1" name="MinorVersion"/>
	<field value="1" name="ServicePackMajor"/>
	<field value="18519" name="RevisionMin"/>
	<field value="18519" name="RevisionMax"/>
	<field value="0x14" name="EgeGuid"/>
	<field value="0x200" name="EpObjectTable"/>
	<field value="0x10" name="EreGuidEntry"/>
	<field value="0x10" name="OtName"/>
	<field value="0x28" name="OtIndex"/>
	<field value="2" name="CiVersion"/>
	<field value="0x10" name="AlpcCommunicationInfo"/>
	<field value="0x18" name="AlpcOwnerProcess"/>
	<field value="0x0" name="AlpcConnectionPort"/>
	<field value="0x8" name="AlpcServerCommunicationPort"/>
	<field value="0x10" name="AlpcClientCommunicationPort"/>
	<field value="0x28" name="AlpcHandleTable"/>
	<field value="0x10" name="AlpcHandleTableLock"/>
	<field value="0xd0" name="AlpcAttributes"/>
	<field value="0x0" name="AlpcAttributesFlags"/>
	<field value="0x38" name="AlpcPortContext"/>
	<field value="0x168" name="AlpcSequenceNo"/>
	<field value="0x16c" name="AlpcState"/>
	</data>
	<data name="6.1.7601 - 6.1.7601.18519">
	<field value="6" name="MajorVersion"/>
	<field value="1" name="MinorVersion"/>
	<field value="1" name="ServicePackMajor"/>
	<field value="18519" name="RevisionMax"/>
	<field value="0x14" name="EgeGuid"/>
	<field value="0x200" name="EpObjectTable"/>
	<field value="0x10" name="EreGuidEntry"/>
	<field value="0x10" name="OtName"/>
	<field value="0x28" name="OtIndex"/>
	<field value="1" name="CiVersion"/>
	<field value="0x10" name="AlpcCommunicationInfo"/>
	<field value="0x18" name="AlpcOwnerProcess"/>
	<field value="0x0" name="AlpcConnectionPort"/>
	<field value="0x8" name="AlpcServerCommunicationPort"/>
	<field value="0x10" name="AlpcClientCommunicationPort"/>
	<field value="0x28" name="AlpcHandleTable"/>
	<field value="0x10" name="AlpcHandleTableLock"/>
	<field value="0xd0" name="AlpcAttributes"/>
	<field value="0x0" name="AlpcAttributesFlags"/>
	<field value="0x38" name="AlpcPortContext"/>
	<field value="0x168" name="AlpcSequenceNo"/>
	<field value="0x16c" name="AlpcState"/>
	</data>
	</arch>

the header of the relevant fiel says its auto generated, but o cant find the tool online so the devs have a tool that makes extracting the relevant offsets easy

There is no automatic extraction. All offsets are copied manually from windbg into that XML file then we execute CustomBuildTool.exe -dyndata to load the XML and generate the header:

systeminformer/tools/CustomBuildTool/Program.cs

Lines 38 to 41 in 018b5c1

	else if (ProgramArgs.ContainsKey("-dyndata"))
	{
	Build.BuildDynamicHeaderFiles();
	}

If they prefer to make the tool public that would be even better.

Everything is public?

[DavidXanatos]

Thanks, somehow id not find that, thanks for pointing out, LOL

[i486]

@DavidXanatos,

I'm curious if your method could apply to Nvidia drivers. They're still rolling out new Windows 7 drivers without signatures. Us Windows 7 users are left with either using TESTSIGNING or signing them ourselves with custom certs. Maybe it's time to give Nvidia a heads-up about this, haha.

Apologies for going off-topic.