3

I have an Avast antivirus and it has a process "AvastSvc.exe". If I try to end/kill that process in Windows Task Manager, then a windows with the following messages appears: "Unable to Terminate Process", "The operation could not be completed.", "Access is denied". Trying to end some system Windows processes (like winlogon.exe) may feature the same behaviour (although once I managed to kill winlogon.exe and got my machine hanged!).

I want my application (possibly, converted to a service) behave in the same way. How can I do this?

Disable Windows Task Manager so he cant kill my process is a similar question which has many interesting answers, but they don't seem to feature the technique which is used by the above antivirus and results in "Unable to Terminate Process" message.

http://forums.codeguru.com/showthread.php?t=503337 has a solution on how to prevent stopping a service (eg, via services.msc console), but I need preventing ending/killing its process in Task Manager.

I am writing the app in C++/winapi, no CLR/.Net, under Windows 7.

UPDATE on permissions: Antivirus process AvastSvc.exe is owned by "system" account. However, I have other processes owned by "system" account, and they are killable and antivirus is not. Also, I compared executable permissions and owners of antivirus process and ones of killable processes, and I don't see any difference.

UPDATE on user control and purpose of the software: The software functionality is somewhere between that of system and business software. The nature of the software requires it to run on a permanent basis. The application itself will have a "turn off" action, and we want to encourage users to use it and discourage them from killing the process (it's similar to what antiviruses do). I understand that it's not possible to completely prevent users from killing it, but I want to make it harder. This question is specifically about the way described above ("Unable to Terminate Process") which some services (like Avast) use to prevent killing their processes. It is sufficient for me to achieve just the same behavior. Also, users will be able to just uninstall the software if they don't like it/don't need it anymore.

Community
  • 1
  • 1
user444214
  • 183
  • 2
  • 7
  • remind me never to use any software you produce. so who do you work for again? :-D – Tim Abell May 07 '15 at 18:03
  • 1
    possible duplicate of [Prevent user process from being killed with "End Process" from Process Explorer](http://stackoverflow.com/questions/6185975/prevent-user-process-from-being-killed-with-end-process-from-process-explorer) – Harry Johnston Aug 11 '15 at 07:40

3 Answers3

6

This is not achieved through code (well, it might be for critical Windows system processes, but you are [probably] not writing components of the operating system), but rather through access permissions.

You can demonstrate this by elevating to Administrator and then attempting to kill Avast's process. It should succeed this time. Alternatively, you can take ownership of the executable (and possibly the folder in which it resides), then try to kill the process. Again, it should be successful.

Windows does not allow applications to exert more power over the computer than the user. If you own the machine and have the appropriate permissions, you can do anything you want, including terminating a running process. Thankfully, there is no way for you, as a developer, to block this.

The user is always in ultimate control. Attempting to create an alternative situation is a battle that virus and other malware developers fight—and lose—regularly. Since I'm not interested in helping anyone write malware, that's all I'm going to say about that.

And other than writing malware, I can't imagine what the motivation for this "feature" in an application would be in the first place. If you're simply trying to prevent regular users from killing a process that is critical to a business system, then you should just demote the privileges of the standard user accounts so that they will not be able to tamper with such things. As such, this is probably a job for Group Policy, rather than code.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • 1) I made some updates to my question. 2) I don't actually know if it's done in code or somewhere else. 3) "demote the privileges of the standard user accounts" : we will not have access to users machines and we don't want them to make additional changes to their computers. Users will download an installer, and install it like they do it with antivirus. – user444214 May 08 '12 at 10:46
  • Ah, so not your machine. Then indeed you've no business or right to commandeer it for your own purposes, regardless of the motivation. Your very intent is indistinguishable from malware and the only legitimate scenario for you to guarantee it persists is to run it on your own hardware and give theirs (non-persisting) remote access. – HonoredMule Apr 15 '17 at 20:08
  • There are scenarios not satisfied by this approach (such as administering tests online and needing to monitor the testee's computer activity) that are aguably legitimate. However they are far less important than preserving the integrity of basic security models, for which the first responsibility is upholding the computer owner's (legal) intentions far above all others. And regarding the particular scenario I presented, I've turned down a job before over that very sort of (surprise) interviewing step. I seriously doubt your scenario presents higher stakes than that. – HonoredMule Apr 15 '17 at 20:13
1

I found that the function ProtectProcess() supplied in Prevent user process from being killed with "End Process" from Process Explorer results exactly in the effect I was looking for.

Community
  • 1
  • 1
user444214
  • 183
  • 2
  • 7
0
  1. Hide your process by removing it from the eprocess structure
  2. Issue persistent I/O requests that cannot be cancelled or completed by other processes
  3. Create threads to debug your own process
  4. Create separate process/es from memory that monitors the main process and re-starts it from memory once terminated by another process
Ritche
  • 1