VoodooShield/Cyberlock

so i think the self protection must recognize the situation, and maybe ask for a confirmation. shouldn't be hard to do :

1- if process x is blocked from accessing service.exe and gui.exe is terminated = auto-lockdown
2- if only gui is terminated = prompt user (with maybe password) = if no answer or wrong password = lockdown, if answered or correct psw = no lock.

it is the only way i can think of to make it workable without annoyance; maybe others can give you ideas.

and goodnight lol

 

I think what Dan wants is similar to that of Advanced Disinfection Technology of Kaspersky. KL's ADT blocks all program launches until it finishes its job and the system is restarted. I got this from here: https://malwaretips.com/threads/kas...nly-no-ksn-ransomware-test.67685/#post-589342

So, "locking the system when attacked" is not entirely new. If KL did a good job, it's absolutely possible for VS to implement this as perfectly as possible.

 

No, I do not know Dan very well, I've only just started using VoodoShield on my system.

No, this does not happen for me. When VoodoShield.exe and VoodoShieldService.exe are running, I can get rid of the service for VSScanner.sys without a problem and then there is no more protection on the system for monitoring the processes (obviously). This makes it useless for VoodoShield.exe and VoodoShieldService.exe to be running in the first place, because they will never have anything to scan or show for, the protection will be all gone...

All of these problems could have been avoided if you had put in the time to actually research the topic of self-defense properly, and used a secure and reliable approach. In fact, there are plenty of details within this thread which it appears you have ignored, which demonstrate how you can implement exactly what you're looking for. Why you have ignored and gone for an approach like this is a mystery to me.

Anyway, I look forward to the upcoming beta releases. Hopefully you will overcome this situation.

 

If you use a secure and reliable approach, the same one that top AV vendors are all using (yes, they all more or less use the same methods), it won't matter if malware is trying over and over again. It will keep failing and will make absolutely no progress.

If you use a secure, reliable and documented method such as ObRegisterCallbacks, and make sure to register it for both handle creation and duplication for PsProcessType and PsThreadType, then your processes will be protected against termination (and the threads within the process). The only way of bypassing it would be through loading a device driver.

 

could not have said it better myself, well put

 

Has anyone tried 355beta3? Any issues?

Personally I had not experienced any issues with 354 / 355, but did revert back to 353 for a while on Dan's advice. I am currently on 355beta2.

 

Did I say right ON? No, I meant write ON. Never mind. Major discussion, very interesting.

Is anyone with v.3.55 beta 2 installing the 3 beta in post 15040 even if the 2 is working exactly as intended? Rather not push my luck.

 

Just rebooted from install over the top with v3.55 beta3, and it is OK, for me, it seems.

Some info from the log:

[03-22-2017 21:10:32] [DEBUG] - DriverCommunicationService:disconnect
[03-22-2017 21:10:32] [DEBUG] - DriverCommunicationService::Exit main loop
[03-22-2017 21:10:32] [DEBUG] - DriverCommunicationService:disconnected
[03-22-2017 21:10:32] [DEBUG] - DriverCommunicationService::Client disconnected
[03-22-2017 21:11:08] [INFO ] - User Log Initialized
[03-22-2017 21:11:08] [INFO ] - Snapshot file Initialized
[03-22-2017 21:11:08] [INFO ] - Service started
[03-22-2017 21:11:08] [INFO ] - Driver communication service started
[03-22-2017 21:11:11] [DEBUG] - DriverCommunicationService::Connect 10 threads
[03-22-2017 21:11:11] [DEBUG] - DriverCommunicationService::Enter main loop
[03-22-2017 21:14:18] [DEBUG] - DriverCommunicationService::Client disconnected
[03-22-2017 21:14:18] [ERROR] - VoodooShield has entered self-protection mode. | C:\Program Files\VoodooShield\Notify.exe | C:\Program Files\VoodooShield\VoodooShieldService.exe | True | False
[03-22-2017 21:14:21] [ERROR] - VoodooShield has entered self-protection mode. | C:\Program Files\ReCrypt\ReHIPS\DesktopTools32.exe | C:\Program Files\ReCrypt\ReHIPS\HIPSAgent64.exe | True | False
[03-22-2017 21:15:33] [INFO ] - User Log Initialized
[03-22-2017 21:15:33] [INFO ] - Snapshot file Initialized
[03-22-2017 21:15:33] [INFO ] - Service started
[03-22-2017 21:15:33] [INFO ] - Driver communication service started
[03-22-2017 21:18:10] [DEBUG] - DriverCommunicationService::Connect 10 threads
[03-22-2017 21:18:10] [DEBUG] - DriverCommunicationService::Enter main loop

 

V3.55 beta3 running clean and green on my Win 7pro x64 for several hours so far, several reboots etc.

 

same here but i did notice that some third party applications would not start after first boot until i shutdown VS. once i shut it down the applications immediatly opened and now start normally when i reboot. i suppose they were whitlisted now but not sure why they weren't allowed to run but also weren't technically blocked by VS with warnings.

 

I honestly like it this way and it's no big deal to do a reboot to get back your system. Also this doesn't happen unless to are trying to shut down VS's processes otherwise it works as it should.

 

Right! And again I like the new lock Down Feature and you only have to do a reboot to get your system back. Again Dan is following the theme of VS as a Computer Lock.

 

Installed v3.55 beta 3 over the top of beta 2. Restart seemed a bit sluggish, shutting down and booting up.

Though that could be a coincidence, I definitely concur with @Tarnak's observation here: https://www.wilderssecurity.com/threads/voodooshield.313706/page-602#post-2661489

VS CPU usage went up to nearly 50% on booting and took some 5 minutes to settle down. Could be that it's a one-time issue, will have to monitor that.
Noticed that with beta2 also, don't recall that it existed before that.

 

I'm not saying that it's the same, but the "locking the system while being attacked" is similar. VS' planned self-protection already implies that the system may be attacked. So, when VS is attempted to be disabled by an unknown app (malicious), there is clear indication that something bad might happen to the system. Locking the computer, then, is a viable solution, just like what ADT does.

 

I could not of said it any better. Now for users like Peter and others maybe a setting to disable the self protection but add a message to "do it at your own risk". I'm not saying that us Security Guru's would get infected but for the common/enterprise users well....

 

Like I said above Peter.

 

I totally agree with what you said. But Dan is accommodating the possibility of targeted attacks on VS' users. So, I think, as a developer, Dan just wants to cover all bases. Targeted or not, the user must be protected.

 

I think you should continue on the path you're taking Dan...Perhaps it will work, perhaps not, at any rate it shows your commitment to continually enhance an already superb security software that is user friendly

 

I think that "user friendly" is the important bit here. I'm sure Dan knows what he is doing and let's all hope that he can resolve this satisfactorily. However I agree with Peter that the last thing the average user wants is to suddenly find his system locked up unexpectedly. It is far more likely that users will try to shut VS down inappropriately using Task Manager than they will be subject to a targeted attack against VS on their machine.

 

Well, it IS panic-inducing when your machine suddenly locks and it's correlated with a specific software. Regardless, there were methods like these posted to get around it, you're saying this is inappropriate? And with great respect to EIS, a total mess of my operating system requiring a complete Windows reinstall is more reason to move on than a temporary lock up you can work around.

This new Self Protect feature is very welcome and wanted. It's also seeming to be a challenge, like any major software change. You vent and move on, hopefully to the next build.

 

This is a good idea in my opinion, I think the problem is that Dan isn't aware of how to execute his own code while the termination request is calling but before allowing it to proceed. All the details on how he can protect the processes have already been given in the past few days on this thread. Using methods previously mentioned (some with more extensive detail provided by other members) he could prevent the termination of his processes in a reliable, secure and less-irritating manner, without requiring a "lock down" feature, but also add support for the good idea you've just suggested. If I recall right, Avast used to show a UAC-like alert before their protection was being shut down (it dimmed the screen too).

Alternatively, he could replace the mechanism with a new one which does as it is currently, but instead of "locking down" the system it would obtain the process ID of the caller process trying to attack the VoodoShield process', and if that caller process is not genuinely belonging to Windows (e.g. TaskMgr.exe, other system processes), he could terminate the caller process. This means that the system does not end up going into a "lock down" mode which it seems many people dislike, but the actual attacker target is terminated from memory (and/or also blacklisted from being executed until further user interaction from within the GUI).

Could be a nice implementation... if implemented correctly of course.