Are you building your own PPL implementation in the driver?

[DavidXanatos]

I browsed a bit through the new driver code and it looks to me as if you are making your own Protected Process mechanism, just with black jack and hookxxx ... or how that saying goes :D
So MSFT did not want to allow you using the windows built in once?
I would have thought anti malware tools can get signed to use that mechanisms protection.
Any ETA when a first test build of PI will be available ?

[Masamune3210]

Microsoft has for the longest had issues with Process Hacker, its probably not exactly surprising that even after a name change that things might still not exactly be on eye to eye at least yet

[jxy-s]

So MSFT did not want to allow you using the windows built in once?
I would have thought anti malware tools can get signed to use that mechanisms protection.

Microsoft PPL has some major drawbacks/limitations for us. I believe our solution is better suited for the goals of the project overall. Here are a few reasons:

• We support third-party plugins. With the caveat of, without appropriate signing, access to the driver is restricted. In order for PPL to support third-party plugins, plugins would have to go through the same authenticode signing process of which is embedded in the ELAM driver. Given this, it would be impractical to support and make the project unapproachable for third-party plugin development. This also opens up our plugins to be given access to PPL processes, which isn't something I (and I'm sure Microsoft) would want. Our solution enables:
  • Us to deliver first-party plugins with full access to the driver.
  • Others to load third-party plugins with the driver in a restricted/limited state.
  • Developers to generate their own key pair and plugins with full access to the driver (requires re-signing of the driver, obviously).
• PPL's configuration around access to the protected processes involves baked-in restrictions on access to the process and across process boundaries. Most egregiously (for us) it prevents termination of the processes. This is intentional by Microsoft for the security of the system. For our purposes it is unnecessary. We wish to give users ownership over their machine and processes under our protection are not protected to the same degree.
• I think, in some areas, we do a better job than PPL. And we have full control over our solution, so we're able to adjust to the landscape as necessary.

Any ETA when a first test build of PI will be available ?

No ETA yet but we are making meaningful progress.

[DavidXanatos]

Ok cool... sooo... then will PI be able to kill MSFT PPL processes?

[jxy-s]

No, we won't support that out-of-the-gate. Perhaps we can restore that capability in the future but not in the near future.