VoodooShield/Cyberlock

I am beta testing another product, which is Process Lasso v6.6.0.85 beta. See PL- New stand-alone log viewer

However, when I manually tried to test a new feature that was introduced with the PL beta, i.e. 'File > Launch the log viewer' I got the following:



Then after having failed to launch this twice, I started to see the flashing VS tray icon, but there was nothing in the VS logs.

So, disabled VS and this time I was able to get PL Log viewer to show, after which I reenabled VS:

 

I have removed VS for the moment due to what appears to be a large gap in protection. My internal drive has 3 partitions: C (system), D (recovery), and E (data). Executables launched from E: are automatically being allowed by VS in the Always-On protection mode without an option to deny. If VS is running in Smart Mode with the protection for user space setting enabled, they are also added to the whitelist.

AppGuard blocks launches from E: as part of its drive-by download protection. I expected VS to do the same as E: is extended user space. It was only when I temporarily disabled AppGuard protection during an install that I noticed this. This problem is not new to version 1.26 and was also occurring with version 1.25.

 

That's no good. Are all the partitions NTFS or do you also have FAT32? I wonder is VS is somehow not recognizing the partition. I have not tried this last build because i'm testing some beta builds of Online Armor right now. If Dan does not release a new build soon then I will go ahead, and test the current build with Online Armor. I just don't like having too many security applications installed when testing for someone because if I run into a problem then it can be difficult to say for sure which security application is causing the problem. It will give me an opportunity to see if OA, and VS play nice together. I have not used them together in over a year. If they run well together without impacting my system performance then I may use them together for a while. I will have lots of options soon because I will have my test machines back in two weeks. I will hook a couple of them up just for beta testing. Unfortunately I don't have room to hook up anymore than 3 of them.

 

Hi, thank you for letting me know. I just tried Process Lasso v6.6.0.85 beta and it worked. I reset my whitelist just to make sure, and it still worked. I am sure that it is a cmd issue, which I am working on that as we speak, along with running the engine as a service.

You might try to update PL again, and include the beta version. It is really odd that it does not work for you but it does for me. You can also check the Do Not Blacklist options in Settings / Tweaks in VS, just to see if one of them is causing the issue. I would be it is the CMD, but who knows. If you figure it out, please let me know, thank you!

 

Thank you for reporting this. I think the operative phrase here is "E: is extended user space". I have always understood the user space to be the user's folders in the Users or Documents and Settings directories. We can easily make it whatever makes the most sense. But if VS is ON, and you try to launch an executable that is not whitelisted from the root of any drive, then we need to fix that. Please let me know, thank you!

 

It is going to be a little while for the next release since I am working on running the engine as a service and finalizing the cmd/msi issue. I would say the absolute earliest would be a week from now, but it might take up to a month or two. I will keep you posted, thank you!

 

The system and data partitions are both NTFS; the recovery partition is FAT32. VS must be recognizing the data partition because it is whitelisting executables located there with the correct path names. As AppGuard and Shadow Mode were both disabled at the time, there is no evidence of interference from any other source that could have affected the outcome.

 

You, misunderstand...I have updated.... but, it wouldn't open that particular new feature. BTW, I am for all intents and purposes always running PL in beta, since the developer is frequently releasing updates.

 

Hi Dan,

I have retested and can confirm that I can also launch executables from the root directory of the E drive without VS preventing it or prompting in the Always-On mode. As regards what constitutes user space, it depends on how the file system is configured. In my case, the My Documents folder and Firefox and Thunderbird profiles are relocated on the E drive, which makes life easier when restoring system images.

IMHO, with the exceptions of the Program Files and Windows folders on the system drive which are allowed by default, VS should operate on a strict default-deny basis in Always-On mode. It defeats the purpose of whitelisting if the whitelist isn't strictly enforced. This should extend to all folders on additional partitions.

(EDIT: After posting this, I've done some further testing and most executables running from the root directory of the E drive are getting blocked, but not all. All of the executables are allowed to run from sub-folders within the E drive though.)

One small thing I noticed when reinstalling VS 1.26. When I accepted the prompt to turn off Training mode after 10 minutes, the tray icon turned blue even though there were no applications running and no USB device connected. A right-click on the tray icon showed that Training mode was still checked. This is potentially confusing to new users because the GUI is suggesting Training mode, the tray icon colour with no high-risk activity is suggesting Always-On mode, and the reality is that VS is probably operating in the default Smart mode at this point. I manually checked the Smart mode option at which point the tray icon turned red again.

I would have thought that the correct behaviour when accepting a prompt to turn off Training mode should be to return to the previous mode if Training mode was manually engaged, or to set the mode to the default Smart mode on an initial install. The option checked within the GUI should automatically change to reflect the current mode, and the tray icon colour should be set correctly, depending on the operating mode and whether or not there is any high-risk activity.

Kind regards
pegr

 

Update:

I have since been able to open PL "New stand-alone log viewer" with VS in 'Smart' mode. So, whatever caused the hiccup that I reported earlier today has gone.

 

Hi pegr,

Sounds good. So what utility do you use to define the folders for your user space? I think I used to use tweak UI for that, but I have not tried it with Windows 7. Do you just use the registry, or do you use a utility?

Yes, I agree on the windows folders and program files folders. I always assumed that these were protected folders, and they are for Vista and above, but not for XP. Ever since the pcmag review came out, I have been trying to figure out the best method for this, and I think you will like how I changed it in the next version.

I have no idea how those exes are running. You might try to reset your settings and your whitelist. If that does not work, we will see if running the engine as a service fixes your issue.

Yes, I noticed that issue yesterday. VS was in training mode, and for some reason it turned Blue, but was still OFF. If you happen to know what triggered it, please let me know. For me, I was just in training mode and it turned blue after a few minutes. So I am assuming that it has to do with reactivation. But yes, we have to fix this asap, that could be dangerous if people think they are protected and they are not. It will be easy to fix once we know what is triggering it.

I am not sure what you mean by the following, but it sounds good to me, so can you please explain a little better? "I would have thought that the correct behaviour when accepting a prompt to turn off Training mode should be to return to the previous mode if Training mode was manually engaged, or to set the mode to the default Smart mode on an initial install. The option checked within the GUI should automatically change to reflect the current mode, and the tray icon colour should be set correctly, depending on the operating mode and whether or not there is any high-risk activity.
"

V 1.26.5 should return the user to the previous mode after the timer is up in Training or Disable Protection mode. Is that what you mean, or is it not working correctly? Also, I am not sure what you mean by the rest of the sentence, but do you mean that the menu options should change, depending on what mode you are in? It sounds like you are on to something pretty cool, I just do not know exactly what you mean.


Thank you!

 

Yeah, mine is working too. But if you have any problems, please let me know!

 

Hi Dan,

I used an inbuilt feature of the OS to move the My Documents folder, and I used the Firefox and Thunderbird profile managers to move their respective profiles. The point I was making is that user space is anywhere the user keeps their personal stuff. The whole of the additional data partition (drive E) is part of user space where I keep my personal files.

I think you misunderstood what I was getting at. What I was saying was that, apart from the Program Files and Windows folders which are whitelisted by default, all other execution should be explicitly controlled by the whitelist on a default-deny basis in the Always-On mode. In other words, if it isn't on the whitelist, it isn't allowed to automatically run without a prompt. Unfortunately, this isn't currently the case. Any executable (mostly installers and standalone utilities) that I have stored within sub-folders on my data partition can be run without interference from VS in Always-On mode, even though they have never been whitelisted. If I can drop an installer onto my data partition and run it, there has to be a possibility that malware could do the same thing via a drive-by download.

I don't understand it either. I have tried resetting the whitelist and also did a complete fresh install after removing all traces of VS from the system and the cloud. One thing I have seen is that the blocking of executables run from the root of the data partition is inconsistent. Certain executables run some of the time and get blocked some of the time. This makes me wonder if race conditions could be involved. As noted above though, executables launched from sub-folders within the data partition always run without interference.

In my case, the icon didn't turn blue all by itself; it was in response to action I took in accepting the prompt to turn on protection after VS had been in Training mode for 10 minutes after installation. Assuming that VS enables Smart mode by default after installation, the icon shouldn't have turned blue because there was no browser or email client running at the time, and no USB device connected. It is impossible to say whether or not this was the case because Training mode was still checked in the GUI.

When the protection level is turned on by responding to a notification prompt that protection is off, two things should happen automatically. The icon colour should be set correctly and the protection mode check-mark in the GUI should be set correctly without manual user action. We have already discussed the issue of the icon colour not always being correct but there is also an issue with the protection mode being checked incorrectly in the GUI. After an initial install of VS, Training mode is checked and it remains checked even after protection has been enabled by accepting the notification prompt to turn on protection after 10 minutes. The problem is only on the initial install. If the user subsequently manually switches to Training mode then the protection mode checked in the GUI does automatically return to the previous mode after accepting the notification prompt to re-enable protection.

It does return the user to the previous mode - this is working correctly. The issue is Training mode remaining checked in the GUI after protection has been enabled on an initial install of VS. It either means that protection has not been properly enabled, or that the protection mode is displayed incorrectly by the GUI.

Kind regards
pegr

 

Yes, and there are 2 different methods for defining the user space. We can either tell VS that the user space is what windows defines it as by default, which is essentially C:\Users\Dan. Then when the user adjusts the inbuilt feature to move the documents, Windows and VS adjusts accordingly (at least in theory). The other method is to custom define the user space by telling VS "Any folder named Downloads, Documents, etc" are included in the user space. Or we can do a combination of the two. It is simple to adjust VS and define the user space, we just need to figure out the what is most secure and user friendly.

I understand what you are saying, but I am just extremely baffled why VS is not blocking anything on your E drive. It should block everything that is not in Program Files or certain Windows Folders when those settings are checked. I noticed that you use Shadow Defender, and a few people have experienced conflicts with SD and VS. Is there a chance this is causing the issue? I have ran VS on a lot of computers and it always blocks anything that is not on the whitelist or in one of the allowed folders. I really would like to figure out why VS is not blocking these files. Do you have any Custom Allowed Paths setup in VS’s Settings / Custom? What happens if you try to run an non whitelisted exe from the root of the C drive?

That really is odd. The race conditions really only apply if a virus was specifically written to target and kill VS, and even then, it is not easy to do. I have been working on running the engine as a service, and this should fix the issue with race conditions. If not, we can use an alternative kill method, but the other methods might create the windows error messages (I will attach a pic), and may not run quite as smooth. Keep in mind, thousands (probably tens of thousands) of viruses have been tested with VS by many different people, and it has blocked all of them, so I think something else is going on, we just need to figure out what it is.

Ok, I know what is going on. Basically, when I added the new feature where VS remembers your previous mode (when switching to Training or Disable Protection), VS’s previous mode is Training, so it gets confused. I will fix that right now, thank you for letting me know. I found the other issue as well, so we should be good to go on the toggling. These bugs appear whenever we add new features, and we do not notice them until someone reports them, or we notice them. I think the VS toggling feature cool, but it really makes it difficult to get everything just right, but I think we are very close. Thank you for all of your help!

 

Hi Dan a new thing happen to me the last couple of days on boot up VS is not in the tray or desktop but I do see the 2 processes in task manager and I kill the processes then I click the desktop VS Icon to start it again then the the two show up and it did it again so this morning I uninstalled VS and deleted the Whitelist in my online account rebooted and reinstalled so I will let you know if it continues. 1.26.5

Daniel

 

I also had that problem yesterday. For other reasons I went back to my baseline image that did not have VS on it, so had to do a fresh install of VS. Now that problem is gone.

I had been playing around with other programs so that might have messed things up.

 

Yea I think it was just yesterday and this morning but I have not rebooted since the clean reinstall to see if still acting up. Thanks djg05

Daniel

 

Ok, thank you TH and djg05 for letting me know, please let me know if it continues. It is funny that you mention that because I am working on that portion of the code for the service as we speak, since it will be rewritten for the service anyway. So hopefully when I am done it will all work great either way.

 

Here is 1.26.6, it is just a few minor bug fixes, mainly the shield turning blue on first run.

http://voodooshield.com/download/versions/Install VoodooShield.1.26.exe

 

Ok, thanks for keeping us updated. I will be waiting for it's release.

 

Hi Dan,

I've now solved the mystery. It stems from a misunderstanding on my part as to how VS works. What I didn't know is that VS automatically whitelists any folder that contains "Program Files" in the folder name, irrespective of which partition the folder is located on. I had wrongly assumed this applies only to the system partition. On my data partition, I had a subfolder within My Documents called My Program Files where I store program installers, drivers, standalone utilities, etc.

As previously reported, everything was automatically allowed to run from this folder without interference by VS. As an experiment, I tried renaming the folder and every attempt to run an executable from within the renamed folder is now blocked by VS. It appears that the golden rule when using VS is not to create folders on non-system partitions with a folder name containing "Program Files" unless the intention is to whitelist everything within it.

The issue with executables running from the root of the data partition only occurred with certain executables after the executable had previously been allowed to run from the My Program Files subfolder within My Documents so maybe VS just got confused. Since renaming the My Program Files folder, I cannot reproduce any of the issues previously reported.

There are no issues between AppGuard, Shadow Defender, and VoodooShield on my system. I will report back if the situation changes, but so far so there doesn't appear to be any problems running this combination on my system that I am aware of.

Many thanks for your assistance.

Kind regards
pegr

 

That is really cool that you figured it out! We could specify that "C:\Program Files" auto whitelists items instead of "Program Files" if we needed to, we just have to figure out what is most secure and makes sense to the end user. Thank you for letting me know!

 

Installed over latest version and no problems noted so far. Running smoothly here.

 

Recently installed VoodooShield
Great product so far
I have registered vs with the 1yr offer on the site of VS
Keep it up!