I think we can agree on something beside disagreeing ;D. Do you agree, at least, that OSS protected the system?
Peace.
By the way, I forgot to ask you. Did you perform your own test with OSS 2009 and Process Hacker? I’m guessing, because you told me that the PID changed and I did not realize that. Thank you for bringing that fact up.
Peace.
I would be inclined to agree with anybody who noticed you are convinced that that the “back to life” was a meaningful protection against a kernel driver and that could be the reason you are inclined to praise OSS 2009 ;D
Yes I tested OSS 2009 though I came to a completely different understanding from the one you represented so far. 
It is great that you tested it. Now could you give me a full compte rendu of your testing.
Peace.
I guess it would be more interesting to understand why you wasn’t aware that acs.exe PID changed.
You should be aware that termination tests usually confirm termination using PIDs.
I also disabled permanently acs.exe “back to life” using a reg file but obviously a driver could do it better, few milliseconds after the termination and before the “back to life”
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\acs.exe]
"Debugger"="notepad.exe"
Would an installed driver trigger any alert? nope, it won’t need regedit nor any similar usermode app at all.
Besides it doesn’t really matters in how many ways OSS2009 could be thwarted as long kernel drivers are involved…
Did you manually manipulate the reg or did Process Hacker do it for you? To me, without any manual file manipulation OSS 2009 core process did protect my computer. That’s a FACT PCFlank could attest to as well as regtest. Anyway irrespctive of PID number, the bottom line, to me, is OSS core process was alive and well. At least for my test. Moreover, by emphasizing such a point is by no means praising OSS, I was just pointing facts through comparative testing of different security software such as CIS, OA free and OSS 2009.
PS: Please give a full compte rendu of your test. Thanks.
Peace.
If the PID changed the processes were killed so OSS failed. Endymion hs already told you every little detail. Just accept that no program can provide safe protection once a kernel mode driver is loaded. Unless you don’t understand this, plz EOD…
It failed based upon what? Because the PID changed, well it means nothing. If a process came back then it was not killed. I think the best thing to do is to find some other appropriate word in order to describe such an event. Since English is my third language then I may not be the most qualified person to come up with a new word to that effect.
Wait a minute, I may lobby L’Academie Francaise and ask the immortals to come up with a French word that could eventually ended up in English, some day.
Bottom line: If a process came back to life then it was not killed nor terminated. If such a statement is not true then the word kill or terminate does not have any meaning anymore.
Peace.
If I follow your logic: Am I to understand that If a process has a changed PID then it was killed, so OSS failed. Consequently, am I to presume since the process has a new PID therefore, such a process is still alive and well. If that is true am I also to believe that OSS succeeded. Can a killed or terminated process has a living PID? ;D
Peace.
Jaki, assuming you don’t just fail to understand what everyone is saying, then yes - if you want to protect against processhacker manually killing the process, then OSS works around the issue by restarting itself (though I expect it’s using another running process to do so, or has set the service to restart if failed in Windows).
If you want to defend against malware, then no - OSS hasn’t done that as you haven’t tested attack code using a driver to do the test.
As an interesting example, on a VM, why not install both OSS (first) and then CIS (as it has an option that might simulate what everyone is talking about). Start up and see that both are running - this probably will work. Now, in CIS, open Defense +, Common Tasks, View Active Process List. Go find your OSS core process, right click on it and say Terminate & Block. Now see if it’s still running.
Should anybody has to assume that OSS2009 is considered to pass actual “self protection” tests which don’t involve drivers because it came “back to life”?
This would really bring any available OSS tests under a new perspective… :-La
How this “noteworthy” feature would be called “undeadTM protection”? 88)
Though meaningless against a kernel driver, kudos to OSS for this one-sided “success”…
Undead, did I say that?
Peace.
You know you are a good diplomat I like the way you approach the issue :D. Thanks.
I’m still troubled about one thing though. Can a dead or killed or terminated process has a living PID? ???
Peace.
Or vice versa I could do the same thing for CIS. There are ways that I could do the exact same thing in OSS to CIS as well.
Peace.
No 
But the PID only changes when the process has already been terminated. If it restarts it gets a new one.
In the time frame between the process is killed and then going to be restarted the system is vulnerable and so also OSS. If the malware wants to it could kill OSS then. It’s not “secure”. Once a kernel mode driver is loaded… you should know the rest of the story now :o
Don’t let that bother you. You really brought a new perspective on security softwares as wannabe security developers won’t have to implement termination protection at all even when kernel drivers are not involved…
Apparently all they have carry is a “back to life” restart and it won’t be “termination” anymore…
If you agree to say NO then you validate the bottom line of my premise which was that Process Hacker was not able to terminate OSS core process. That’s all I’m saying. [b]Now the story line about kernel this and kernel that is a whole different subject and such a subject was not even the point of the thread.
The point of the thread was to urge Comodo to better defend CIS own processes, that is all i.e C’est tout.[/b]
Now when you said that the process was terminated and yet it still has a PID then you defied logic as in its entirety. Since a terminated process cannot have a living PID. I really believe that we as human beings do not have in our languages a proper word that can define such an event.
You cannot say that a process was killed, terminated and yet that same process has a living PID. Consequently, based upon logic I can only deduce that such a process was not terminated. If you say that OSS core process was terminated and it still has a living PID well then what language you are talking. Does words have meaning anymore?
Peace.
You have not helped me. You still have not answered the question. Can a killed, dead, terminated process has a living PID.
Peace.
Thanks. ;D
Peace.