Will Plugins-Extra be migrated over / supported

[AltF5]

Will https://github.com/processhacker/plugins-extra be migrated as optional components?

Chiefly the Terminator plugin is of excellent use.

[dmex]

No.

[AltF5]

Any more details why not, especially “simple” ones like Terminator just from user mode with the various techniques?
I see PhTerminateProcessAlternative was added recently, but it isn't called anywhere? -- ec12f8b

There are other valuable ones in there too which wouldn’t be consider overstepping… maybe they could go into plugins itself

[ionescu007]

There's some good ones like the FirmwarePlugin and probably a few others which should get moved over, yes.

[jxy-s]

We are likely deprecating plugins-extra in favor of promoting the useful ones to plugins and integrating the ones that make sense to with "core" functionality.

[DavidXanatos]

Will there be any 3rd party plugin facility in future? I mean if you are going to presumably run PH as a PPL than loading any 3rd party code would be a no go.
I guess you could go with a plugin container process which would use some IPC mechanism to communicate with the main process and allow plugins to use safe functions while thoroughly protecting the unsafe once.
But here I guess any sort of UI integration would be quite a hustle.

[jxy-s]

We plan to support plugins and will restrict protected APIs. Plugins that need enhanced functionality will need to be considered for the main binary.

[AltF5]

May I ask the intent behind PhTerminateProcessAlternative being added recently, but it not called anywhere? -- ec12f8b

Is this going to be the “first line of defense / attempt” at process termination, and then if it doesn’t in some timeout then call the existing implementation?

My goto PluginsExtra is Terminator 🔫💪🏼

[jxy-s]

There is a link in the source that explains it :).

This injects a call to RtlExitUserProcess into the process to try to do a "clean" exit of the process. This is less aggressive than calling to terminate the process as it gives an opportunity for the application to save state.

[AltF5]

I did read the 1999 article (sure would be cool to rewind time and be a dev then), but I noticed it’s not called anywhere.

I went ahead and tested it out in a private build of Terminator in Plugin-Extra and see it functions like / similarly to the TP2 remote thread injection already.

I was just curious why this is being placed in the SystemInformer specifically and not plug-in or Terminator itself?

I Noticed: While useful and more graceful, [Nt]TerminateProcess is still “more” successful from a lower IL process (Medium) against a higher IL process (High), such as if SI isn’t run elevated, because the typical way can usually allow process opening with Process_Terminate. But this/these techniques required Create_Thread which is usually not granted to a lower IL caller against a higher IL target.

Just some thoughts.

But I was curious the intention / direction or if it was just experimental. I won’t @ the author of it to avoid that aforementioned spamming we talked about in the other thread, but it certainly wouldn’t replace the defacto process termination, unless it was attempted first, and if the process failed to be opened, then it falls back to the current NtTerminateProcess ability.

[jxy-s]

Both dmex and I worked together on deciding if we should put this in PH. We decided to put it in for now, as reference, for future work. That's why it isn't called anywhere.

We are likely to port the termination functionality from the plugin into the main binary.

It is likely that not all of the ways to terminate are going to be ported over from the plugin. The majority of them are just "party tricks" and provide little value outside of just testing how certain applications react to being terminated in different ways.

[AltF5]

It’s certainly good for debugging purposes against processes that try to avoid being killable 👍🏼 (At least in the days before PPL)

If you do decide to, perhaps it’s simply another Terminate By > next to Terminate [Tree] context mention (instead of being buried under Misc).

I think the first half of the methods are useful. Some could be combined into 1 like with PostMessage WM_Close, Quit, etc. Driver-assisted ones could be enabled based on if the driver was loaded.
Perhaps the ones to drop are handle and memory corruption based ones.