Discussion in 'sandboxing & virtualization' started by Cutting_Edgetech, Feb 14, 2011.
Thanks so much for the explanation.
Exe Radar Pro is free, although donations are accepted. I feel it is an excellent program
Thanks for your input. It's running very smoothly so far. Can't really tell it's there. But the website says 30 day free trial. $19.99 USD for a lifetime. http://www.novirusthanks.org/products/exe-radar-pro/
I suspect it doesn't need registration, but heck a $20 donation is still a bargain.
I agree. Well worth the cost regardless.
its not free, I tried it and it stopped working at end of trial.
Well, time to purchase SD. Worth every dollar spent, even more...
Are you guys talking about EXE Radar Pro or Shadow Defender?
Shadow Defender is paid, while EXE Radar Pro beta is free.
Version 3.0 is paid. You can find download links for version 3.1 which is free here
Hi Azure Phoenix,
Shadow Defender currently sells for 35 US$
and can be downloaded here
One of the best occasions where I've spent 35 dollars.
Q: upon Shadow Mode .... where does Shadow Defender create a shadow-box.
I've noticed ERP reports.
C:\Windows\SYSTEM32\mountvol.exe | mountvol Z: /d
C:\Windows\system32\conhost.exe | \??\C:\Windows\system32\conhost.exe 0x4
I've changed View Options. I'm not finding vol Z: nor \??
I'm thinking not finding is good,... I can't find so malware can't find but,... should there be a bread crumb to shadow-box disk write cache (not RAM cache).
I can find Sandboxie > C:\Sandbox and ToolWiz > C:\ToolWizTimeFreeze
1)Where do Shadow Mode disk writes go.
Where does Shadow Defender create a shadow-box.
Does Shadow Defender create a shadow cache / are shadow writes random to disk.
Where is the virtual volume.
2) And upon Reboot restore. Are shadow disk writes (not RAM) simply tagged for overwrite.
3) Does Encrypt write cache, apply to disk write cache as well as RAM write cache.
1) There is no sandbox container folder or hidden volume. SD uses a filter driver to intercept disk writes below the level of the Windows file system and redirect changed disk sectors into a write cache within the free space of each shadowed volume.
2) Upon reboot restore, nothing is tagged for overwrite. All that happens is that the free space on each shadowed volume that was used for the write cache is no longer monitored by SD and becomes available as free space again for use by Windows.
3) Encryption of the write cache will apply to the disk write cache.
Maybe also read posts #4402 thru #4407 on page 177 of this thread for further information.
1) Trying to visualize where shadowed volume resides. Trying to interpret ERP events.
2) Okay, disk write cache available as free space again that may be recovered.
3) Encryption will apply only to disk write cache...? I thought Encryption was added same time as RAM cache. So, thinking Encryption applied only to RAM cache...?
Thanks ...re-read posts #4402 thru #4407
Just to confirm, when we activate the RAM Cache, and exceeded the given value, the changes start to be written to the disk cache, right?
1) A shadowed volume is not a physical entity that resides somewhere. It is a logical entity that consists of the virtualized file system and registry that applications see while in Shadow Mode. It is an illusion constructed and maintained by SD from disk sectors that are in their correct physical locations on disk (from the perspective of the Windows file system) and redirected disk sectors in the SD write cache.
2) Exactly. From the perspective of the Windows file system, free space is always just that. Only in Shadow Mode does SD monitor and control how the free space on a shadowed volume is used. When not in Shadow Mode, Windows is free to overwrite any free space that may have been previously assigned to the write cache.
3) If encryption didn't apply to the disk cache, there wouldn't be any point in doing it. The whole point is to prevent the write cache from being readable after exiting Shadow Mode. The alternative to encryption would have been for SD to overwrite the write cache when exiting Shadow Mode. Encryption is more secure because the write cache will not be readable outside of Shadow Mode even if the system crashes while in Shadow Mode.
I have tried this for 2 weeks and bought 5 licenses for my laptops and pc's.That test cruelsister did sold me about safety.
Longer time users have figured this out. I've shadowed all three disks on my system and let Ransomware have at the system. One reboot and all is well.
I'd be interested to know how many people are using Shadow Defender version 184.108.40.2063 and if it is running well for them on their particular operating systems? Any positives or negative comments that people have I can feed back to Tony. My interest is not based on any criticism or bug that I've heard of in this version, I'm just curious. I tend to find that people don't talk much about versions when they are running well...and that is a good thing
I've enjoyed reading the posts on this page.
1) Hmm, "an illusion constructed and maintained by SD". Silly me. I've been trying to squeeze SD into the TTF/SBIE genre. Perhaps the "illusion" is causal to reports re data corruption.
3) Hmm, silly me.... imagined de-cryption upon reboot restore...and imagined memory release left nothing to read nor recover. Yes, there wouldn't be any point.
As always. I'll stand in awe regarding pegr contributions. My apology for my limited grasp. Regards 220.127.116.113
I'm running older version (I got it on giveaway so no update for me or...?) on Win 10 x64 and everything is fine .
I'm still having an old problem with NVT ERP where one list (AlertWhiteList.db) is reset to zero (emptied) after restarting the machine and exiting shadow mode.
Why doesn't this "Tony" guy make an account here to interact with this community himself, it seems strange that sdmod has to act as some sort of proxy to get answers and relay feedback about this software.
I am using 623 on three Win 7 x64 machines. No problems at all.
I am on .623, only have one niggling issue... Internet Download Manager takes longer than usual to append all download split-files together and spit them out to destination directory. It still does it, but takes longer. Due to the increase in time, the other files in queue don't get started or they receive errors. This happens regardless of anything inputted in Exclude or Commit tabs.
Like I said, it's not really an issue since I have SD enveloping D:\ which contained TEMP and SANDBOX. Nothing can run because of SRP, so not really worth worrying about. I didn't want to rely on Exclude and Commit tabs since my primary use of SD is to keep TEMP and SANDBOX in Shadow Mode. I apply common sense when downloading stuff, and check hashes against VirusTotal website before I run, so yeah... no real issue. I ended up creating another partition just for downloads.
This has been a constant for me for many versions. Maybe it has something to do with HDD vs SSD? All in all, just put it out there since @sdmod asked.
Separate names with a comma.