The unofficial Shadow Defender Support Thread.

A lot of users have been talking about SD not having MBR protection for some time now. If Tony adds it then I would hope he would make it an optional security mechanism that can be enabled by ticking a box within SD or something similar. I already have MBR protection since I use Appguard. It would probably cause system instability or even make ones machine unbootable if they tried to use two at the same time. I also wouldn't see any reason to even try.

 

I believe that the following link provides pretty good evidence to validate what Space Ghost has suggested. In fact this is a recent video using the latest SD version (1.2.0.370). Unfortuantely the video is not in English so for those of us who only read English it's impossible to fully understand what is happening. Nevertheless, the gist of the testing and the conclusions are pretty obvious.

-http://www.youtube.com/watch?v=VTLuTjufQkU-

The only thing that I couldn't determine was if this was conducted on a real or virtual system.

Wendi

 

You beat me to it Wendi lol I just got done watching that video, and was about to post it myself. I love the music theme for the video! The video played at a fast speed so it was difficult to catch all the fine details of the test. The test was conducted in a VM instead of an actual normal environment in which one would encounter the malware. It looks like Tony has some work to do. Also the test was conducted with the latest version of SD 1.2.0.370. I'm not sure if it is as secure as V1.1.0.325 or possibly even more secure since .370 just very recently was released. Wish I could get my test machines out of storage! Thanks for the post Wendi!

 

Hi there,

The same tester has videos on Youtube of some older SD versions (including 325) which result in the very same findings. He (she?) also has tested various other LV systems (including the very latest Deep Freeze) and they all fail at least one of the malware tests. So it seems that what The Shadow tells us in post #2204 is correct (unfortunately)!

Wendi

 

I was hoping for Ichito to come back and offer us a better insight, since he is from Poland...

 

Dear CyberMan969,

Below is what Space Ghost said in the post #2210, which you have missed it:

 

Thanks man, I actually saw that screenshot and judging from his next post it looks like he did the test himself. I have sent him a PM, asking for the sample.

On my own VMware tests with Win7 host and XP guest, SD v325 failed on two samples. I then tried the same samples with the Win7 host and the exact same cloned Win7 as guest and SD flushed both samples succesfully with no remnants. I then re-tested both samples on three real (meaning non-VM) Win7 testbeds with identical software configurations as the Win7 guest image I used before, and SD again succeeded to undo both samples. I didn't try the samples on a real XP system.

I have already posted all this on the previous page after Cruise asked me about it, you must have missed it. I actually ran the same series of tests twice to make sure it wasn't a fluke, and had identical results: On Win7 host/WinXP Guest SD failed to contain the samples, on Win7 for both host and guest SD killed them both, and on three real Win7 systems it also killed them both.

Because of this I came into the logical conclusion that antimalware testing within a VM can vary depending on the combination of host/guest operating systems, and because of this such testing cannot be 100% reliable. It would be great if we could find an executable sample of Sinowal (or a malicious web address that contains it) so Tony can test it himself.

BTW here's a decent analysis of a Sinowal variant:

http://www.saferbytes.it/2012/06/06...nd-it-always-brings-some-new-clever-features/

 

Hi, it seems that even if SD have no MBR protection it does better job than MBRGuard module from AG does. Have a look on another test against the same rootkits. It was tested by the same person as SD earlier.
http://www.youtube.com/watch?v=0StHhSmQwxA

Sorry for my English it is not my strenght

 

Thanks for sharing artoor! We get the gist of it, but it would be great if the people that do those tests could actually include an English translation so the rest of the world can be able to fully grasp what's going on.

 

Thinking about the nasties which may be able to penetrate Shadow Mode (I agree that the jury is still out on that because of VM testing), it would be absolutely terrific if SD provided the ability to 'Drop Rights' (like SBIE). That would totally secure Shadow Mode in 'nailing down' malware protection!

TS

 

I agree. But as SD can't enforce 'Drop Rights' restrictions, that's why I use AppGuard in conjunction with Shadow Defender for system-wide protection.

 

Dear Cyberman969,

No, I didn't miss it. For your tests to be conclusive, it should be run on all real operating systems, just not Win 7 x86 or Win 7 x64.

Best regards,

 

Dearest Cruise,

Many thanks for the above information.

Best regards,

Mohamed

 

But it does not make sense to ask, or expect anyone to test every system in existence any more than it makes sense to insist that a developer test their software on every possible computer configuration. This would be an impossible task.

 

I don't get why folks expect one program to do it all. Given the speed with which things change, not just the malware itself but the OSs and programs as well, its a rapidly moving target. In protecting your home each security measure you take reduces the risk you face. Install good locks and you reduce the risk of a break-in. Put lights around the house and clear brush and shrubbery from around the windows and you reduce it more. Get a dog and the risk is further reduced, install an alarm system and again the risk goes down, etc etc. But none of this guarantees that you will never have a break-in. Likewise, no program is bullet proof, no system can be completely secure (heck, banks and even gov military systems have been successfully attacked). The best you can do is reduce your risk by adding various layers of protection and being smart about what you do and where you go on the net (etc). Doing this will give you a decent level of protection against most attacks but thats the best you can do.

 

Thanks for the link artoor! I just finished watching the video. I don't know exactly how important these results could be. You have to disable Appguard's protection except for the MBR protection module in order to conduct the test. AG is designed to block code from ever executing in the first place. Does the malware samples tested only use the MRB to infect the user's machine? If not then those test wouldn't mean much.

 

I've translated into English the most important part, but as you can see there can be some mistakes

Indeed we don't know it, but as AG user is able to turn security off excluding MBRGuard, it seems that MBRGuard should deny writting to MBR, that is my reflection. But as I'm not advanced user in this kind of software I'm rather listening to you for you know much more than I know.

Kind regards,
Artur

 

I totally agree, multi-layered protection is always the best policy. In the event that some malware has somehow managed to bypass everything else, I still have a full clean system backup which includes the system disk's boot sector, along with startup media that allows me to restore on a new disk even if my original disk kicks the bucket.

The only thing that this "final solution" doesn't work on is rootkits that actually attack the computer's BIOS chip itself; but such malware are ultra-rare. You got more chance of winning the lottery or get hit by lightning, than catching one of those bugs. Of course older computers are more vunerable to such attacks than new computers with secure boot UEFI chips.

The drop rights idea sounds good for SD. The only problem I can think of is that some software installations in Shadow Mode may not work if drop rights is activated.

 

true

 

+1 for droprights for SD , if not id actually have to go and buy appguard just for the drop rights funtion , lols, hell add a password protected rightclick menu to allow certain programs to install.like commit right click that allows password protected changes on the fly , and i do hope some of these mentioned issues get fixed soon as well as possible mbr protection if required thou not sure since as said mbrguard hasnt been tested with SD yet and if its of any use , my aero issue with commit right click has been already noticed by tony as well , lots of work to do to get back in the game

 

That's the whole idea! But I am suggesting that it be implemented in SD as an optional selection (as in SBIE), so if one needs/wants to run with Admin privileges just don't enable Drop Rights (but of course that leaves you more vulnerable!). In any case I strongly advocate (and use) a layered security scheme!

 

I agree, it has to be an optional selection. This would be ideal for my usage as I frequently use Shadow Mode to test programs that don't require reboots.

 

I think that the Drop Rights option suggested by The Shadow is right-on because (from what I've read) all sophisticated rootkits/trojans require Administrative privileges to run.

If you agree CyberMan, I believe that you, sdmod, and other influential members of this forum should campaign (via email to Tony) for this option!

 

For people using SD for security, something like Drop Rights would be great as most programs are not allowed to install.

I remember you had a problem using SBIE in your computer in the past, perhaps you like to try the beta version or the new stable version when it gets released (under Shadow Defender) to see if SBIE and your system get along better.

On my computers, SBIE and SD get along very well.

@Wendy, Sandboxie doesn't allow drivers to install in a sandbox, regardless of whether you are using Drop Rights or not. So, rootkits and their drivers wont install sandboxed.

Bo

 

And, for the above reason the software are not tested in real system but in virtual environment.

Therefore, one should not just test in one real system and claim that it applies to all real systems, neither one should knock down the virtual environment for testing.