Thanks. ;D
Peace.
You haven’t been helpful either. You should clarify how allowing a kernel driver to operate should have been an appropriate way of testing any protection/defense.
Moreover since your methodology implied allowing a kernel driver please let everybody know if you would be willing to test OSS “protection” against a malicious kernel rootkit.
My premise is really simple. Process Hacker did not terminate OSS core process. However, such a fact was not even the point of the thread. My intention was to urge or even beseech Comodo to better protect CIS own processes. Driver this and kernel that or manual manipulation of registry this and that were irrelevant terms to my test. I just wanted to know what security suite would be able to withstand the brunt assault of Process Hacker in its quest for process termination.
Peace.
I don’t want to get in to this “debate” but I have just a little note:
I remember terminating both CIS 3.5 processes a few months ago with ProcessHacker.
Thanks for being part of the debate ;D LaserWraith. And That is exactly my point and the purpose of this thread. I wanted to urge Commodo to fix this problem of process termination. If such a problem has been in existence since CIS 3.5 and now CIS 3.10 is our daily bread 
then my question is what is Comodo is doing about it?
Peace.
I admit I know next to nothing about this but…could be (almost?) impossible to keep a kernel driver from terminating processes?
The whole approach you used amounts to “begging the question” as it implicitly assume that Process hacker driver should have been allowed which defy any meaningful protection/defense approach whereas Process hacker developer (wj32) himself commented about a previous PH termination test to prevent such misunderstandings from occurring.
Moreover your premise is fundamentally flawed as it implicitly assume that kernel drivers would play nice as much Process hacker did.
Your conclusion is flawed as well since it would be pointless to implement something (“back to life” restart) that would be meaningful only for the limited span of the test you carried but pointless against active malicious kernel drivers.
If not for a “fraud” or “advertisement” scenario, it won’t make any sense to purposely make a safe vulnerable to attacks because there is a “back to life” insurance refund…
With all your kernel this and driver that, you just cannot provide an answer to a simple question, even after repeated pleas from me. Can a dead, killed, or terminated process has a living PID? Can it?
Peace.
Personally I won’t care much for CIS being terminated, as CIS, as a hole can’t be killed with brute force. If you kill a CIS process, CIS will make it harder for the applications trying to run.
And no a dead process cannot have a PID.
btw whats OSS?
Process hacker terminated or killed OSS. OSS restarted itself once it saw the failure. In the context of testing with Process hacker OSS merely restarted itself automatically which essentially fooled the test.
In a real life situation a kernel mode driver could much like Process hacker terminate/kill OSS, as soon as OSS tries to restart itself the driver could then kill it again or prevent the software from reloading into memory. This is what a real malware would do to completely cripple OSS. Since Process hacker’s job is merely to test it doesn’t go as far as a malware would.
As mentioned already if OSS got a new PID and restarted itself in a real life situation this would not work against a malware threat. In a testing environment using Process hacker’s task (as I understand it) was to kill the application once, not permanently. Succeeding in doing this once proves that other malware, programmed to do so could kill permanently OSS or other and any security program using a kernel mode driver.
CIS “could” add the automatic restart but this would not make it any safer since Kernel mode drivers essentially cannot be stopped.
Yes, so I guess the only defense is to prevent a kernel driver from loading in the first place, which D+ does.
Jaki whenever I could be interested to run around in circles at your leisure just for the sake of confirming what else is on your mind, IMHO it took already too much to have you confirm that the pid was changed when you were willing to claim that Outpost 2009 was not terminated
Sure I noticed your “plead” for a new more appropriate term though it come at no surprise as I already got the impression your understanding of the situation rely on semantic but neglect to properly address the kernel driver approaches involved.
Well then I rest my case. In can only imagine that you either do not know the answer or you do not want to formulate an answer. Anyway I’m still going to ask you again: Can a dead, killed, terminated process have a living PID?
Peace.
How could something a process that is not running have a PID? It might get one when it starts but I doubt it has one when it isn’t running…
A process can be killed and then be reborn with a new PID. A killed process loses it’s PID. A new process gains a new one. I’m not sure why you’re stuck on this question.
Process Hacker only cares about the first (for testing purposes). In a real world situation where a malware was attacking your security app, the malware would not stop terminating at the first try. Although the automatic restart is useful in testing it does not work in the real world.
CIS adding this feature to make it seem like you’re safer wouldn’t do a thing.
Well I really wish so, in order to have everybody acknowledge your whole approach and remember it next time they read your posts elsewhere on these forums.
Such continuous and consistent effort wouldn’t pass unnoticed for sure 
PS:I replied to that PID question already, actually before you asked and so thoroughly that you apparently didn’t notice (check the FYI line 
) whenever you look inclined to have this topic run in circles for the time being, I got no reply as to why you were not aware of PID changes… 88)
Maybe I missed it or was I just running in circles when you provided an answer to the question I asked you: Can a dead, killed or terminated process have a living PID? Please provide an aswer if you can and also it is OK if you do not know.
Peace.
Oh well I already provided more than a simple answer, you won’t mind if anyone could read that post and verify you claim that the question is actually unanswered, wouldn’t you?
I guess along with the reply contained in the FYI line of that post they could also appreciate your subsequent replies.
Why do you keep asking that? There are been many answers but you just ignore them.