as popularity of Avast rise and word about this nice antivirus existance spread - there will be soon viruses and trojans capable to easily terminate and prevent restart of Avast services / processes …
and because there are already (at market) working methods to protect own service / process from being terminated by another service / process … but in actual stage this forces customer to buy another software to protect avast processes / services …
so i’m going to ask when will be this feature implement to Avast?
as in my eyes it’s very close to critical feature …
In Pro version the configurations and providers stopping could be protected by password.
In Home version, please give a try to Proccess Guard, a freeware than can protect avast service (ashserv.exe). You can find it here.
I am afraqid the the password protection of the resident providers is rather meant as protection against users, not against viruses (and I think it’s present in the Home version as well).
As for the original question - if the virus has enough rights, there is no way to protect the antivirus with 100% reliability.
Like Igor said above, if some malware gets activated, ie. past avast shield, it’s too late.
I doubt if even a ProcessGuard could stop all true EXE-viruses, and Malware with process-killing abilities often have Keylogger functions as well, so your system would be compromised and should be reinstalled from scratch.
Process Kill command is the highest level of OS command and its performed instantly without any thinking of problems after doing this.
As the command name says,the process is killed not stopped,thus there is no waiting for program/process to respond with the quit/stop command but terminating it instantly,so there is very hard to create protection for this.
It can be protected by attaching other process actively to the one we want to protect,but you can easily terminate second one and you have access to the first one again.
I’m not sure…
ProcessGuard protects agains the following terminating methods:
DLL/Code Injection: The attacking process ‘injects’ a DLL or code into the memory space of another process, allowing the attacking process to remain alive in the context of an existing process. This stealthy trick is starting to be used more frequently by remote access trojans, and can also be used to alter the behaviour of programs. Injected code can also easily terminate its host process, providing another option for process termination. Firewall leaktests often use this technique to bypass firewalls, usually by injecting a DLL into an application that’s generally trusted by firewalls (such as Internet Explorer).
Process Termination via EIP Modification: The attacking process suspends all threads in the target process and sets the value of the EIP register for each thread to the address of the ExitProcess function in kernel32.dll before allowing the threads to resume, causing the process to terminate.
Process Termination via CreateRemoteThread: The attacking process creates a new thread in the target process which has a start address set to the address of the ExitProcess function in kernel32.dll, causing the process to terminate.
Process Termination via TerminateThread: The attacking process enumerates all threads in the target process and calls the TerminateThread function in kernel32.dll on each thread, causing the process to terminate when its last thread is terminated.
Process Suspension via SuspendThread: The attacking process enumerates all threads in the target process and calls the SuspendThread function in kernel32.dll on each thread, causing the process to freeze.
Process Suspension/Termination via DebugActiveProcess: The attacking process attaches to the target process as a debugger by using the DebugActiveProcess function in kernel32.dll, allowing the attacking process to both suspend and terminate the target process.
Process Termination via Window Close Messages: The attacking process sends Window Close messages (such as WM_CLOSE, SC_CLOSE, WM_DESTROY) to all windows in the target process. This attack only works against applications that have windows but don’t have any message handlers for the Window Close class of messages.
Process Termination via EndTask: The attacking process locates a top-level (parent) window in the target process and sends its handle (identifier) to the EndTask function in user32.dll. This attack only works against applications that have windows.
DiamondCS Process Guard easily prevents all of these attacks, because all of these process vs. process attacks have one thing in common - the attacking process has to open the target process to gain access to it before it can do anything with it, such as terminate it. DiamondCS Process Guard intervenes at this early stage by preventing the attacking process from accessing any protected processes (or any of their threads).
I know this list is impressive, but
a) really protection against EXE or COM ? Can’t see this, please point me
b) Imho nothing helps against a dedicated attack, when a keylogger gets the admin password
You guys are both right… I mean, it’s certainly true that programs like ProcessGuard aren’t (and cannot) be perfect. There are infinite ways to do the attack, provided the code runs under admin accounts.
On the other hand, a decent protection may be useful. Most today’s virus writers are no experts and cracking these things would often be beyond their capabilities…
