mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 15:25:59 +03:00
[GH-ISSUE #81] Persistence : Preventing users from terminating xRat process. #33
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#33
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @vigneshkarthisan on GitHub (May 5, 2015).
Original GitHub issue: https://github.com/quasar/Quasar/issues/81
Just came across some website with this snippet of code. Actually it was in C++. I made use of this with PInvoke.
Calling
ProtectProcess()makes the process critical. A critical process cannot be terminated. When a user with admin rights terminates it, it either shows an alert "Access Denied" or else the system crashes causing a BSOD(Blue Screen of Death).Not sure whether this code will work with systems running Windows 8 or later, I'm on vacation. So I couldn't get a chance to test it.
Just call
RevertProtection()to revert back to normal.Can be invoked from any part of code. Mr. @MaxXor or anyone else interested, Please try this code out bcoz I don't have a PC nearby with VS2013 installed.
@yankejustin commented on GitHub (May 5, 2015):
How does this react to the client crashing? Perhaps we should add this after fixing some of the issues that may still crash the client. :)
@vigneshkarthisan commented on GitHub (May 5, 2015):
Yep. What about creating a new branch and try this out ?
@yankejustin commented on GitHub (May 5, 2015):
I am up for it. I need to get on my main computer which I can't do until later tonight. After a meeting at work, I certainly would be up to booting up a VM and seeing how stable the client is.
As I just wanted to mention again (mainly for others that may try it): Because the client still likely has issues that cause the client to crash, this could also make these unfortunate client crashes turn into something disastrous.
@vigneshkarthisan commented on GitHub (May 5, 2015):
Which time zone do you live in?
@yankejustin commented on GitHub (May 5, 2015):
I live in the U.S. (EDT)
@MaxXor commented on GitHub (May 6, 2015):
We need to be sure the client is really stable before we add this.
@vigneshkarthisan commented on GitHub (May 6, 2015):
Just make sure that this issue is not closed until we implement the feature in a separate branch.
@yankejustin commented on GitHub (May 6, 2015):
How does this react to lower permissions? Can a client with "Normal" privileges do this?
@vigneshkarthisan commented on GitHub (May 6, 2015):
I think it won't. But we can develop app logic to activate Persistence after the first attempt by the user to terminate the process. We can gain Admin rights one time(using the trick already implemented) and install xRAT client as a windows service so as to make sure that every time the PC boots, xRAT will be started with Admin privileges.
@yankejustin commented on GitHub (May 19, 2015):
@MaxXor I messed with this a bit on a virtual machine and it gets ugly really fast. You're one mistake from blowing your arm off... I don't think we should add this...
@ghost commented on GitHub (May 26, 2015):
Shall we start working on solutions for persistence?
@MaxXor commented on GitHub (May 26, 2015):
No, not with this kind of persistence. Maybe we should add a startup persistence which checks every 20min if the startup registry key has been removed and add it then again.
@rabbitsmith commented on GitHub (May 26, 2015):
what if client.exe is terminated
@ghost commented on GitHub (May 26, 2015):
@MaxXor, right. Making a process critical will be really bad for this. I've looked into solutions for process persistence as far as making a process restart itself, etc... and it doesn't look like there will a be a good solution for this. Start-up persistence, on the other hand, would be viable. It wouldn't prevent users from being able to 'suspend process -> delete registry value -> terminate process' but it would be a start.
@MaxXor commented on GitHub (May 26, 2015):
@rabbitsmith Then we can't do anything as the process stopped. :c But this form of Process protection is not so good, like @yankejustin https://github.com/MaxXor/xRAT/issues/81#issuecomment-103280791 said.
@d3agle Yes, it's a start that doesn't hurt. :)
@rabbitsmith commented on GitHub (May 26, 2015):
what about @vigneshkarthisan 's idea of a windows service
@MaxXor commented on GitHub (May 26, 2015):
@rabbitsmith That's possible indeed. I like this idea.
@rabbitsmith commented on GitHub (May 26, 2015):
one drawback though. starting from win 8, task manager shows process started as a service and clicking end task would kill the service
@MaxXor commented on GitHub (May 26, 2015):
It's okay I think. But with a Windows service xRAT starts up whenever the computer is booted, not when just when the user signs in.
@rabbitsmith commented on GitHub (May 26, 2015):
well when you are free try renaming client.exe to something like winlogon, svchost , csrss.exe and check whether it is immune to end process
@rabbitsmith commented on GitHub (May 26, 2015):
http://www.rohitab.com/discuss/topic/36910-process-protect/
@yankejustin commented on GitHub (May 26, 2015):
How about basic DLL hijacking?The sound of a Windows Service is quite alluring. It would be a bit of a pain modifying how we update, disconnect, or uninstall the client. I think that, other than those potential pains, it should be rather easy.
@abdullah2993 commented on GitHub (Jul 18, 2015):
we could subscribe to UnhandledException event and then use RevertProtection() so that it doesn't effect thesystem in case of an application crash?
@yankejustin commented on GitHub (Jul 19, 2015):
@Abdullah2993 I could forcibly close the Client easily by calling
Process.Kill(). Internally, it is very likely that the program will consequently throw an error as a result of the termination. The above method could not effectively differentiate between accidental unhandled Exceptions in the Client and ones intended to close the program, because they really have the end result of closing the program.@abdullah2993 commented on GitHub (Jul 19, 2015):
@yankejustin we could call RevertProtection() every time we want to close the program or the program is being closed due to an unhandled exception?
@yankejustin commented on GitHub (Jul 19, 2015):
@Abdullah2993 But what would we need to do so? Another program to monitor the Client? How else could we do it?
@MaxXor commented on GitHub (Jul 19, 2015):
We're not going to implement this kind of persistence, but we'll add running the client as windows service.