Shadow Defender Bypassed

Tell me, when using SD, is it enabled during start-up before any other program can get access to the LAN or internet? If something loads before SD is enabled, could it delay the launch of SD until it has performed it's task? That might only be a couple of seconds in real time!

This may or may not bare relevance to these kind of problems, I don't know, but it is an interesting avenue of thought in the security integrity of SD!

 

I've never tried AVG alongside SD so I've no experience of how well AVG and SD work together. The other AVs I tested that worked okay on my system were: Avira, avast!, ESET NOD32, MSE, and WSA. Did you try disabling the AV real-time protection before entering Shadow Mode to see if it makes a difference?

It's not a new behaviour. 1.1.0.325 is the last official version and has been around for a long time now. If you are only seeing this behaviour with the system partition, and not additional partitions, then it is likely that something else that is running is intermittently preventing SD from locking the partition when entering Shadow Mode. You will need to try doing what I suggested in post #16 in order to investigate further.

 

SD doesn't prevent programs from accessing the LAN or the Internet: that's the job of a firewall. The purpose of SD is to freeze the system after entering Shadow Mode, containing subsequent changes within the virtual system and discarding all changes at reboot. SD doesn't prevent malware encountered while in Shadow Mode from running; it contains it within the virtual system, which makes possible a perfect clean-up simply by rebooting.

On my system, the SD tray icon is always the first to appear, which suggests that SD does load very early in the boot process. If the real system has already become compromised while Shadow Mode wasn't enabled though, there is nothing that SD can do to prevent the payload from being delivered as the malware is already running on the real system on equal terms.

If using SD for security rather than for testing of software that doesn't require a reboot, it should be combined with a firewall, AV and/or anti-executable in order to prevent the possibility of data theft.

 

That is interesting. My personal firewall is usually the first icon to appear in my tray—I wonder which would take preference if both were installed?

I was going to ask if SD can be set to load automatically at start up, then realized you would be locked in a permanent cycle as any attempt to change that later would only be recorded in the virtual session and lost at reboot! You would have a permanent virtual OS that could only be changed from a different boot up—assuming SD was installed in the OS partition. I can see its' value as a secure testing environment, rather than a roll back security program, thanks.

 

Yes, this really is the nub of it and what some people see as the principle advantage of SD, security and software testing aside. Some SD users run their system with Shadow Mode permanently enabled during normal operation precisely in order to maintain a static system, only exiting Shadow Mode to apply Windows and other software updates. This trades off some loss of operational convenience for increased system stability and privacy, as no traces of system activity remain after a reboot. Other SD users just enable Shadow Mode on demand, for increased security in high risk situations and/or for software testing.

 

Anything you do within the SD program itself sticks regadless if you are on Shadow Mode or not at the time. For example, if you are already on Shadow Mode with Shadow Mode scheduled to autostart on every reboot and then you open the SD app and disable the scheduling, then on the next reboot Shadow Mode won't be on regardless of the fact that you initiated this change under Shadow Mode. SD in my view is invaluable for parents who can password the program itself, so their kids can't take it out of Shadow Mode themselves.

For people who have problems with processes starting before others, you can easily change this with a startup priority manager like Chameleon:

http://www.chameleon-managers.com/windows-startup-manager/

You can also do it with Winpatrol or by using batch files:

http://www.howtogeek.com/52043/how-to-control-the-order-of-startup-programs-in-windows/

 

I can confirm that i tested & saved a file in SD mode whilst the SD banner was showing, but my C drive was NOT shadowed, even though both C & D were checked to do so, & the file was there on reboot. As i'm aware of this annomally & normally always recheck to ensure it's on or not, it's not something i worry about, as when it's on, it Really is on. Sure it's a concern, & it shouldn't be happening, but as it's so good at what it does, i won't be changing.

*

@ caspian

SD is blocked by my FW, so has Never phoned home, so it can't be that, at least not here.

Good point, i had never thought of that !

How do they do that ?

 

They probably auto-excluded the settings of Shadow Defender.

 

I don't think the administration settings are excluded because any changes to the settings while in Shadow Mode are lost on reboot. What I suspect actually happens at system start-up is that Shadow Defender checks each partition for the existence of its hidden diskpt0.sys file, which only exists while in Shadow Mode, in order to determine which partitions from the previous session to put back into Shadow Mode during the new session.

 

Once going in shadow mode on the fly I got a error message that it didn't successfully go in virtual mods yet my system tray of SD turned blue as if It where in shadow mode.This had only happened once but still a concern.I have SD now to start up in Shadow mode and have not had any further issues.

 

Hi DarkShadow

Have you moved your user files to another disk/partition by any chance? This thing happens to me only in this case, because my user files have been moved to D:. Scheduling both C: and D: to be in Shadow Mode on startup solves this ussue.

 

No and I have only a single partition.

 

It maybe that any changes to parts of the SD preferences while in Shadow mode are held in memory. At shut down the Shadow volumes are ended first, then the preference changes for SD sitting in memory are applied to the real time SD application before also being lost in the shut down process...just a hypothesis!

 

I think it happens the way I indicated in post #34 above. A hidden diskpt0.sys file is created in the root directory of a partition when it first enters Shadow Mode. When a partition exits Shadow Mode, the diskpt0.sys file is deleted from the root directory of the partition. This is easily verified.

At shut-down, the diskpt0.sys file is deleted from each shadowed partition for which the user has requested an exit from Shadow Mode but remains in existence for shadowed partitions for which a request to exit Shadow Mode has not been made. This is how Shadow Defender knows which partitions are to enter Shadow Mode on boot.

 

@ skudo12 & pegr & Flexigav

Thanks for the replies

I guess we still don't know for sure how it's achieved, but however it's accomplished, it Definately works