Thanks for your support. My intention was to urge Comodo to better protect its own processes. I was not saying that OSS 2009 or OA free 3.5 are better than CIS. I like CIS, that’s the security software that I’m using right now. I also said also even though CIS processes were killed however, I was still protected. Both CIS and OSS 2009 would have been able to protect me if such a test was for example a real event in a non virtual operating system.
I used PCFlank as well as regedit for OA, CIS, And OSS 2009. And only OA free 3.5 did not stealth nor protected my registry key once its processes were killed.
And before I know it, everybody who missed the objective of the thread started to say OSS this OSS that. You could have done this you could have done that. Half protection this Half protection that.
The point we made is that there is no need for CIS to improve it’s self protection since the software protected your computer during your tests. An important part which we explained over and over was related to the fact that Process Hacker is not a malware and that no real world malware would stop at terminating the service once.
This has been answered so many times, post 19 in this thread explains it perfectly and yet here we are at post 164!
Jaki, even though others offer their theories about your thoughts and feelings, they don’t really know you. For someone to criticize you, they are implicitly saying that they are superior to you. And some folks say more directly that they are superior to you. This is just false. I have experienced such treatment before in forums, so I know how it feels.
May I suggest that you review this thread from the beginning. Notice that some persons are helpful in the beginning, and then turn mad. There is hope for these folks because some will become helpful again after they cool down. Notice that other persons are quick to insult you personally and generally have a nasty tone. I suggest to not respond to them. There are enough positive persons in this forum that you will likely get a resolution in spite of the noise from the negative persons.
I have a suspicion about what is happening in D+ to cause your problem scenario. Please answer my previous questions.
As the author of Process Hacker, maybe I should comment on this. I’m a little tired of people going around and killing security software with Process Hacker and then exclaiming “I KILLED MY AV/FW!” on forums. Process Hacker uses a driver to terminate processes. It is completely unrealistic for security software to protect against kernel-mode code - CIS is not alone in being vulnerable to Process Hacker’s process termination. Just because Process Hacker terminates your security software doesn’t mean its poorly designed. Can you terminate CIS with Process Hacker if you’re running as a standard user? Of course not. Can you terminate CIS with Process Hacker if you select “Block” when CIS prompts you about the driver? Of course not.
EDIT: As for OSS, how about this: I modify KProcessHacker so that it hooks process creation and kills the OSS process as soon as it restarts. Happy?
Out of interest, if Process Hacker had kernel access (user allowed by mistake) and had some tweaks in the driver to specifically target CIS, wouldn’t it be possible for it to unhook CIS SSDT hooks or any other safeguards it put in to “Default Deny”, after its main process is terminated (by Process Hacker) thus rendering “Default Deny” useless? I think that it could, since they’re on the same playing field… no?
Thanks.
Yes, it could do that… Again, malware with kernel-mode code can do anything, only limited by the skill of the programmer.
The “Process Termination” right that D+ uses has absolutely no effect on KProcessHacker, since I specifically designed it to bypass almost all hooks. D+ works by hooking system calls, but KProcessHacker doesn’t use NtTerminateProcess to terminate processes :P. Again, it’s unrealistic for D+ to prevent KPH terminating processes for the reasons I have already mentioned.
And finally to Jaki:
You said that if a process is terminated and respawns, it hasn’t actually been killed. That’s just different use of terminology - a process usually means a Windows process object, in which case if you terminate it (and all references to it are closed) the process is dead. Whether or not it respawns is another question. As others have said, it is trivial to implement a driver which detects attempts to respawn your security software and terminate them each time.
Now, you said that CIS should try to protect against drivers like KProcessHacker. But it already does - it prompts you (perhaps not very clearly though) if a program tries to load a driver, and you can deny the action. For CIS to protect against KProcessHacker when it is already loaded is just unrealistic, as everyone else has mentioned. Adding the ability for CIS to respawn is simply a temporary workaround - malware authors may prevent CIS from respawning, as I have already mentioned.
Thanks for confirming my thoughts. (as it was necessary for others to know, for the next part of my post)
Now, about Default Deny. We know that CIS’ Self defense is excellent against user mode kills (as matousec test confirms it), so lets just say that it protects itself from the majority of user mode kills. So, what’s the purpose of Default Deny, having in mind what I said above. For something to terminate CIS’ process(es) it would be much easier if it (malware) had highest privileges (kernel mode) to terminate it. That scenario is likely to be why Default Deny was implemented (malware gaining kernel level access), since it would be a lot lot (^n) easier to kill CIS from kernel mode compared to user mode. Assuming that the user makes the mistake of allowing in the first place, of course, since it couldn’t get kernel access if the user denied driver installation. As confirmed, with a bit of tweaking, that malware could easily unhook CIS kernel protection mechanisms and do as it will (send data, modify resources etc.) after obtaining kernel access. Default Deny also takes place when the user exits the interface (via an available option “Exit” from sys tray), denying any unknown requests for net access (for ex.). My opinion is that, since the user himself requested CIS to exit, why is it still denying stuff… it’s annoying to the user. It’s because CIS can’t differentiate between user and malware, which is an acceptable explanation. For all it knows, malware is trying to exit it.
Instead of the existing approach, I think that it is very important that CIS warns the user (by any means) that driver load could be a very bad thing, especially for unknown applications… If the user fails to realize that, it can’t really protect him/the computer, for reasons noted above (which basically means Default Deny is a waste of (developing) time).
In conclusion, when I’d put user annoyance and inconvenience from Default Deny (CIS denying stuff (legit apps) even after the user exits it) and number of malware capable of terminating CIS after the user erroneously allowed it to obtain the necessary privileges, I’d say user annoyance is more important in the real world and CIS should emphasize more on denying kernel access to unknown applications, since the application (malware) couldn’t do anything in that case.
There are two main ways a program can load a driver. One is by writing to the registry in HKLM\System\CurrentControlSet\Services and then calling NtLoadDriver. The other is by contacting the services controller (services.exe) and telling it to create a service to load the driver. In the first case, D+ correctly reports that a program is attempting to load a driver, and tells you the filename of the driver. The prompt is also in red (I think). In the second case however, D+ only prompts you about registry access (which most people will allow since it comes from services.exe) and then the driver is loaded. This is a HUGE problem with D+ and I hope the developers will fix it.
EDIT: This may also be due to the fact that I removed guard32.dll since it was adding a few MBs of memory usage to every single process…
To everybody who thinks that this thread was about the termination of xyz software or to prove someone wrong by other ways to manipulate a software registry or processes. Then I would like to announce that you are wrong. I would like to request the help of a moderator to move these posts out of this thread since they are out of subject. Some may have problems with the results of a test, well then that’s your own affair.
Moreover, I did not create the thread to display the prowess of process hacker.
PS: PLEASE TAKE YOUR POSTS TO ANOTHER THREAD IF ONE DOES WANT TO STICK TO THE REASON THIS THREAD WAS CREATED.
HOW CHILDISH COULD YOU BE. YOUR POST REMIND OF CHILDREN WHO ARE PICKING ON OTHER CHILDREN SAYING LALA LALA LALA I KILLED OSS PROCESS, LALA LALA LALA I KILLED OSS PROCESS; AND MORE IMPORTANLY THE ALWAYS STICK THEIR TONGUES TO INFURIATE OTHERS.
