Yes, but I think it was necessary. CIS probably can not ever stop itself from getting terminated by a kernel-level driver. Unless it somehow could take control of all of those type of drivers and stop them for terminating itself…
I already addressed your flawed premises in each way possible.
And many told you (MAL1 was the last) that your point is totally unwarranted…
Whenever you look inclined to have this topic run in circles for the time being, I still got no reply as to why you were not aware of PID changes…
…whereas you actually got one about the PID question you made before you ever asked 88)
But lo and behold I pointed you to it to got this reply…
You could prove the flaw by answering a simple question, again: Can a process that has been terminated still have a living PID.
A simple yes or no would suffice. Can a terminated process still have a living PID?
Peace.
Yep I guess you don’t mind to have this topic run in run in circles. 
I prefer to have everybody to read the rest of this topic starting from post that answered that question but was not limited to that, I guess they will overlook the fact you didn’t clarify why you weren’t aware of PID changes…
…obviously it would be an unsolved mystery along the likes of why you miss existing repliess and claim you got no reply.
Ok I’m glad you brought that up. What does it mean really. PID changes mean the process is still alive. If it is still, consequently, the process is still doing its job to protect the computer. And it is no wonder that PCflank still reported that my ports were still stealth and regtest was not able to modify any of my registry keys. However, you came along with a scenario completely different from the subject in question.
The Point of this thread was to show that Comodo processes were killed and that Comodo should take urgent action to protect its own processes. I also tested OA free as well as OSS 2009. Among all tested software only OSS 2009 was able to protect its core process that’s a fact, fact based upon testing.
What does a PID chage mean again?: The process was still alive since a dead process cannot have a living PID.
Your problem stem from the fact that you really do not want to admit that a terminated process cannot have a living PID. That should be my last reply to your own posts.
If you want to talk about kernel, drivers and registry please create a different thread where we will exchange our ideas together, please know therefore I’m always up for a good discussion. This is it, no more reply from me to your posts.
Peace.
As I already pointed out it was it was your call to use an application that rely on a kernel driver along with the definite impression that your understanding of the situation rely on semantic but neglect to properly address the kernel driver approaches involved.
You should be aware of what Process hacker developer himself said and anyone else could likely notice your"protection" point is moot and your supposedly “self-protection” kernel driver based test inappropriate.
The above is a blatant example of fallacy and it neglect the obvious fact the core process was indeed terminated.
Whenever you later pleaded for a more “appropriate” term I previously pointed out that your willingness to create your own definition could lead to confusion.
I guess you would have preferred to not have anyone address your premises and related confusion.
Hopefully nobody will carelessly allow a driver because some process is claimed to come “back to life” because drivers can do way more than terminating something “once”.
But if you are really convinced about what you said there would be no point to run in circles as what was already posted would be plenty enough and indeed there would be no need for you to post further replies.
Erm…let me just ask you, Jaki: What do you think a “living PID” is?
Did you check Jaki’s existing replies?
https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/mayday_mayday_this_is_not_a_joke_cis_processes_shutdown-t43832.0.html;msg317750#msg317750
https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/mayday_mayday_this_is_not_a_joke_cis_processes_shutdown-t43832.0.html;msg317770#msg317770
https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/mayday_mayday_this_is_not_a_joke_cis_processes_shutdown-t43832.0.html;msg317773#msg317773
https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/mayday_mayday_this_is_not_a_joke_cis_processes_shutdown-t43832.0.html;msg317811#msg317811
https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/mayday_mayday_this_is_not_a_joke_cis_processes_shutdown-t43832.0.html;msg317817#msg317817
I don’t think those explain what Jaki thinks a “living PID” is. Does it mean that it stays the same even when the process is terminated? I don’t understand what Jaki means by saying that a process is killed and its PID is still alive. Aren’t they the same?
Isn’t that like:
There is someone named Bob Joe Dirt, whose number in a club was "3689287". Someone chopped off his head. A person was standing right next to him the whole time, and when he was killed said to no one in particular, "Look, Bob Joe Dirt is dead! But 3689287 is still alive." And he meant the same person when he said "Bob Joe Dirt" and "3689287". Isn't that, well, crazy?How is this story like the PID problem? Well, aren’t there at least two “things” you can use to identify a process: its name (“cfp.exe”) and its PID (“1964”, for me right now.)? So saying one is killed or not running while the other is not is like my story above.
A “living” PID was my own way to emphasize a point. Since some was repeatedly saying OSS core process was killed; consequently, to bring my own point across I replied that a “dead” process cannot have a “living” PID. In other words if you have a PID attached to your process then that process must be alive therefore, such a process cannot be “dead”. This is basic logic 101 taught at any respectable highschool or college.
The keyword here is "living"as an emphasis in order to bring a contrast to a “dead” process. Thus a dead, killed, or terminated process cannot have a “living” PID. In conclusion, in that context Process Hacker did not terminate OSS 2009 core process.
Peace.
So LaserWraith does the above reply actually provide any confirmation that the process was terminated and restarted with a different pid?
Do you think that the description you quoted from my previous post could allow any misunderstanding in this regard?
Do you think that the same driver based termination approach could not be used to endlessly terminate the core process before it even get to be fully restarted?
If so do you believe it ought to be easily neglected because Process hacker was not specifically developed with that purpose?
Oh ok.
Hmm…from what Endymion said it sounds like OSS 2009 , or whatever “acs.exe” was, was terminated and then restarted. Don’t you only get a new PID once a process is (re)started?
And how did you exactly come to that conclusion, please? Process Hacker terminated the OSS main proces (I do not want to use the term “core” as to not create unnecessary confusion) which is called acs.exe, since the process was terminated, the service/driver part of the program detected that the main process is terminated and re-started it. Windows then assigned the new acs.exe insance a PID (process identity). That alone can prove that OSS “failed” the “test”. There are many ways of guaranteeing that after being terminated (as acs.exe was) the process cannot execute or restart itself afterward (image file Hijacks for ex. as pointed by other members). If Process Hacker had that abality, OSS would not be able to restart itself. And if acs.exe wasn’t restarted, the main functionality of the program would be compromised, for ex. you’d fail PCFlank etc.
In conclusion, as said MANY times over, only way of protecting your process from kernel-mode termination is to deny the driver or app access to the kernel. (which you granted, and labeled it as not relevant).
I’m not sure what the problem is, if it’s lack of technical knowledge or specific understanding as to how Process Hacker and other Kernel mode drivers work… but this thread has been answered multiple times.
OSS was terminated by Process Hacker and restarted itself with a new PID (not dead, not living) just a new PID.
CIS was terminated by Process hacker and did not restart itself. (CIS would have to be relaunched manually to obtain a new PID)
This does not in any way make OSS safer then CIS in a real world malware attack since malware, if they can kill a process once, (Like Process Hacker demonstrated was possible in both cases) would be able to kill it over and over or even prevent your security software from loading a second time.
If Process Hacker had the capability of Terminating and blocking permanently an application from loading like a malware would do then you would see the true results.
A terminated, dead, or killed process cannot restart, in my context not until reboot, when the same event that brought about its termination is still occurring i.e Hacker Process terminator. Therefore, I deduced that we do not have specific word in our human languages to describe what really happened; since OSS 2009 core process was not dead, terminated or killed.
You probably asking yourself how do I know that. Well I went to PCflank and tested my ports and not even for a second they were not stealth. I also used regtest from Ghost Security in order to see whether or not any modification could happen. Well regtest failed there was no registry key modification. In conclusion, not only OSS 2009 defended itself but protectd my computer as well.
CIS 3.10 processes were killed however, CIS did manage to load in kernel and defended my computer. Between CIS 3.10, OA 3.5 free, and OSS 2009. OSS 2009 was the only security software that defended its core process.
Peace.
Lack of technical knowledge?
Peace.
And by the way. I really do not know if you have any logical knowledge left.
What we’re trying to explain to you is that Process Hacker is a TEST. It’s not malware. Process hacker does not go far enough in it’s attack to show you what would truly happen.
OSS could have been restarted by a secondary service. (A reboot is not always necessary)
You have to keep in mind that Process Hacker is only a small part of what malwares today can do. All security apps failed because the purpose of Process Hacker was to terminate the security application once.
Restarted or not, it failed.
A terminated, dead, or killed process cannot restart, in my context not until reboot, when the same event that brought about its termination is still occurring i.e Hacker Process terminator. Therefore, I deduced that we do not have specific word in our human languages to describe what really happened; since OSS 2009 core process was not dead, terminated or killed.Nor has CIS, going by your logic. You just had to start it once more, from the same Win session, since CIS doesn't have that ability to restart itself AFAIK. That doesn't mean its "core" was destroyed/terminated/obliterated whatever you want to call it...
Well I went to PCflank and tested my ports and not even for a second they were not stealth. I also used regtest from Ghost Security in order to see whether or not any modification could happen. Well regtest failed there was no registry key modification.ACS.exe restarted itself after milliseconds, so no wonder...