VoodooShield/Cyberlock

Cool, thank you for letting us know! It seems that they like VS, they wrote a pretty good review about it!

http://translate.google.com/transla...w.avlab.pl/page/voodooshield_recenzja&act=url

 

Hi.

No problem.

Thank You for your answer.

PM sent with the eMail and receipt number.

Thanks.

 

Thank you, you are good to go! Please check your PM!

 

Oh the other article, which is way too vague. They didn't even compare Vista's UAC, which only gives you prompts for system programs and settings that 7 skips by default. Until it actually proves anything (like they actually bypass UAC by running with full privileges), it's just FUD. I was only suggesting silence of the prompts for compatibility and laziness.

You mean a major shift to accepting UAC? I'm afraid I can't produce statistics, but generally people get used to things over time, especially after learning why it's not so bad. Frankly, I was one of the first to disable UAC (migrated from XP to 7 in 2009) being misinformed of its reputation, and then I gradually accepted it after a long period of lower setting.

https://www.wilderssecurity.com/newreply.php?do=newreply&p=2249808
Shouldn't be an issue in the new version anyways, so can we drop this?

 

In case anyone is interested, I found a very interesting threat on UAC. It is pretty much the same discussion we were having here. Good points on both sides! https://www.wilderssecurity.com/showthread.php?t=317697

 

Good point, VS 2.0 will work perfectly with UAC, and we will give you a lifetime subscription . Actually, you can turn UAC ON with VS, and it works just fine... the only issue we have is that it has a hard time getting the paths of a certain few executables. We have a method in place that resolves this issue, but it is just better to always have the full path of the executable if possible, so we recommend keeping UAC OFF. I realize that the word "Replacement" is not the perfect word to describe VS, but it was my intention to replace UAC. If there is a better way to describe this, please let me know, we will change it.

Believe me, I know exactly what you are saying about UAC, but I gave up on it years ago because I have removed hundreds, and maybe thousands of viruses that flew right past it. And what is the point of elevating privileges if it doesn't ultimately stop unwanted software / malware? Please do not answer that, it is a rhetorical question .

I will say this, and it is kind of corny, but I will say it anyway. A lot of times when people describe VS, they use words like "I LOVE VS". I can honestly say that I have never heard anyone say that the love UAC, usually it is quite the opposite.

But thank you for the thought provoking conversation! It was very interesting. We still all need to meet and Vegas, WITHOUT computers .

 

The path comparison can be a problem, any user of the PC can rename a bad file to a whitelisted file and execute the file without issues... Browser exploits can do this in specific situations, file hash comparison is needed in my opinion.

UAC is disabled by VS when it is installed, if a user rename a bad file to a whitelisted file and UAC is disabled, the executed file has full rights! Please enable it.

 

I have a feeling you're using the wrong smiley . Anyways, I believe "alternative" is a better word, heck you can include the adjective "better" as well.

I tend to focus on more than just the malware, whoops answered it .

Well, people hate change, especially into something that nags. Microsoft should probably add a better whitelisting component to it instead of Task Scheduler/Services/Drivers/System bypasses.

Indeed.

 

I am not an expert but think you are right.
Dan should check the impact of a new feature on VS responsivity.

 

Dan, could you please make a public beta before releasing final 2.0?
That way there are greater chances we would trace and eliminate most of the bugs.

 

This is must be a bug:

After installation VS blocked the prompt for Administrator's elevation (I wanted to add hashes for VS in AppLocker). And my PC happen to be in a deadlock - I couldn't uninstall the VS without the prompt for Admin elevation. So only Eaz-Fix rescued my PC - I reverted to the snapshot (in Eaz-Fix) before VS installation.

 

I am not sure I completely understand your concerns with this issue, so I would like to explore it more. I do not think that anyone would intentionally rename a file that is either malware or unknown to something that is on their whitelist. If you can explain this a little more, it will help us understand this potential issue a little better.

We can definitely add hash comparison in the next version as an extra verification... especially if there is a non executable browser exploit that can rename a file to something on the whitelist. I have never heard of such a thing, but that does not mean it does not exist. If you find one, please let us know, we will implement this asap. If it is an executable browser exploit, VS will block it from renaming the file. Besides, the exploit would have to know the path and filename of a whitelisted item.

 

I am using the wink smiley, just like I always do . I like "Better Alternative", we might use that if that is OK with you! In all fairness, Microsoft did not have an issue with "UAC Replacement" when they approved VS for the Microsoft App Store.

What else should we focus on besides malware / unwanted changes to your computer?

Yes, I agree, Microsoft should add a better whitelisting component, they should consider adding VoodooShield .

 

Yes, I think we are covered with path comparison, but if there is an issue like netbook0tr suggests, we definitely need to add hash comparison.

The goal is to make VS bulletproof, however impossible that sounds! As far as we know, nothing has ever bypassed VS, but that does not mean that 3 developers from KC thought of everything!

If it is possible for a non executable browser exploit to change the filename / path of an item, we need to include hash comparison. We will probably add it anyway, it never hurts to be extra cautious.

 

ABSOLUTELY!!! The main reason we never ran the engine as a service is that it makes a lot more changes to your computer than the current version of VS. The current version of VS makes absolute minimal changes to the system, and is extremely lightweight. The installation of VS 1.09 basically does the following:

1. Turns off one of the UAC features
2. Creates a startup item in the registry
3. Copies the VS program files to the Program Files directory (while creating the Program Files\VoodooShield directory)
4. Creates a shortcut to VS on your desktop

We figured that if we kept it simple and did not create a service or make any serious changes to the system, while offering superior protection, then everyone would be better off.

 

This is really odd... can you please explain in detail what actually happened? VS should not block a prompt for Administrator's elevation. If there is a bug, we need to fix it asap... this is the first we have heard of this.

Did you reboot after the VS installation? If you did not reboot, that is the only conceivable way this possibly could have occurred. If this is the case, we can force a reboot after installation... we just wanted to make it optional for the user. But it really should not have happened anyway, since VS does not block Administrator elevation... I am assuming you mean UAC. Please let us know, if there is a bug we will fix it asap! Thank you!

Edit: Just a thought, there might be some kind of conflict between AppLocker and VS. Anyway, please let us know and we will figure it out!

 

1. Here are the details of the message I get when trying to edit the whitelist:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ComponentModel.Win32Exception: Class not registered
at System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
at VoodooShield.Settings. (Object , EventArgs )
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6400 (Win8RTMGDR.050727-6400)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
VoodooShield
Assembly Version: 0.94.0.0
Win32 Version: 0.94.0.0
CodeBase: file:///C:/Program%20Files/VoodooShield/VoodooShield.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.6387 (Win8RTM.050727-6300)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6401 (Win8RTMGDR.050727-6400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6402 (Win8RTMGDR.050727-6400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6401 (Win8RTMGDR.050727-6400)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6387 (Win8RTM.050727-6300)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Runtime.Remoting/2.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6387 (Win8RTM.050727-6300)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6387 (Win8RTM.050727-6300)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Deployment
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.6387 (Win8RTM.050727-6300)
CodeBase: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Deployment/2.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


This happens every time I try to edit the whitelist.

2. The cmd problem happens even though I am in SMART mode.

Are you going to fix these bugs?

 

Thank you for letting us know! Do you mean when you click on the "Edit Whitelist" button? If so, that should be an easy fix.

Can you please give us more details on the CMD problem you are having?

 

Yes, when I click on the Edit Whitelist button, that happens every time.

The cmd problem occurs intermittently. I get an Allow or Block message. When I click Allow, the DOS prompt appears pointing to the VoodooShield program folder.

 

Thank you for letting us know, we should have that fixed today sometime.

Do you happen to know what program is triggering the dos command that VS is blocking?

You can turn off blacklisting of the CMD in Settings / Tweaks, but obviously it is best to leave it blacklisted if possible.

 

Ok, I think I tracked down the problem, and it should be fixed in VS 1.09.4. Please download the current version and let us know if it fixes the issue!

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

BTW, if the Edit Whitelist button does not create the error, but does not work either, it means there is an issue with your Default Web Browser settings. So if that is the case, you might try to reset them. Just a thought!

 

@J_L',

I also included your suggestion on the wording in 1.09.4. I like it, thank you for the suggestion!

http://voodooshield.com/Images/UAC.PNG

 

Yes, I mean UAC.
Yes, I rebooted after the VS installation.
I think it's something between VS and CIS or AppLocker. I have the snapshot in EazFix. Soon I'll reboot in it and check again.

 

Ok, thank you for letting us know. I think sometimes when there are too many security products on a computer, they can start to conflict with each other. Please let us know what you find out!

 

Dan, is VS going to auto-update to 1.09.04?
I have just tried to make manual update but VS reports that I have the latest version....