I will probably release the official version 3.40 in about a week.

I don't plan any more changes in version 3.39, at least nothing drastic, unless there are any extremely urgent problems that I've missed? Feel free to let me know here.

I'd like to say thank you to everyone who has participated in test-driving the new version. I appreciate it.

Well, there's always the issue with Panda Internet Security, although I can't test it myself.

Al the beta's you released were bug free on my computer. Just want to thank you for your dedication to this Great program!

I have just started using Windows 7.
Using the latest beta .23.
I use defensewall 2.56.
If i download anything when sandboxed, then defensewall does not flag the download as untrusted when the files are recovered from the sandbox.

The two programs seem to work perfectly together in XP.

I have tried adding C:\sandboxie to defensewalls untrusted list but still all downloads are not flagged as untrusted once recovered.
Browsers/download managers are also running as untrusted in defensewall.

Tony, the Sandboxie Control problem is a "normal" application, as it is not operating within the sandbox. When it moves files from one location to another, it's just like your Windows Explorer moving files from one location to another. Therefore, I think you should bring this problem to the attention of the developer of DefenseWall rather than to me.

How to capture the changes about register in Sandboxie?

Do you mean something like this?

http://sandboxie.com/phpbb/viewtopic.php?t=6312

I've been down that road too, and Sandboxie and DefenseWall do NOT work perfectly together, even in Windows XP. I discovered several file types, that when recovered out of the sandbox, would come out as "trusted" by DefenseWall.

At this point, you have to ask what you're trying to protect yourself against. I doubt you're truly as "paranoid" as me haha.

For me, one big reason why I wanted DefenseWall's protection was when I recovered anything out of the sandbox. This goes for .jpg, .avi, .mp3, .pdf, .doc, .txt files etc etc. Since Sandboxie doesn't provide system-wide protection, it would not protect anything you recover out of the sandbox (of course). You would then ask: why these file types? They aren't even "executables" right?

Well, now it's time for you to read about direct exploits like that .wmf one and the current .pdf ones. Didier Stevens has even come up with POC exploits that can load dll files (not inject) which can bypass even a classical HIPS. Now these exploits lead to remote execution of "malware code". What is this "malware code"? Well, the code could be used to try to download programs that attempt to trick you into purchasing some rogue software (I think a lot of the .wmf exploits used this). Even more worryingly, the code could be used to destroy files on your computer, including system files that are essential to keeping your OS stable.

So after a lot of thinking and bouncing ideas off experts from the Wilders forum, I switched to LUA + SRP, while integrating Sandboxie into it. To my surprise, I found I could work in LUA perfectly.

So what was so great about this? Well, LUA + SRP alone was enough to block even the incredibly horrible .wmf windows exploit. So I realised that using Sandboxie to contain/block all malware threat-gates (internet-facing applications, USB, CD/DVD drives) and combining it with LUA + SRP would result in a 100% bullet-proof setup (together with a good "security approach" - eg. not running unknown/untrusted executables willy nilly without testing it first in a VM or uploading to virustotal etc).

But then Didier Stevens came up with his POC exploit to load dll files that contained code which could disable SRP. So what was the solution here? Simple. Any newly introduced file on your system should always be opened using a sandboxed explorer.

For me, I always tend to download or transfer things out of the sandbox and on to my real desktop - thus, I have now created a shortcut icon in my Quick Launch that opens a sandboxed explorer desktop with just a single click!

So even Didier Stevens' efforts would fail miserably here. And don't forget that Didier Stevens' exploits are merely POCs that have not been seen in the "real-world".

Regardless, the combination of Sandboxie + LUA + SRP is quite possibly the strongest setup you could create in a Windows XP environment. Combine that with a good "security approach" (including opening any newly introduced file with a sandboxed explorer), and 100% protection (or as close as possible to 100%) is achieved.

Anyway, hope that helps. If you'd like to share why you are using Sandboxie with DefenseWall, please feel free. Tzuk, please feel free to move these posts into another thread. Thanks a lot!

Nice little tool. The browse button doesn't work here tho.

Read the thread to the end.

If it's not too late, I would recommend a change that's been discussed in the forum:
Namely, revising the standard Delete Command - when selecting Eraser.
The standard Sandboxie command is something like this:
"C:\Windows\System32\Eraserl.exe" -folder "%SANDBOX%" -subfolders -method Gutmann -results -queue

I would recommend changing "Gutmann" to "DoD_E"
Gutmann calls for 35 overwrites of the files, while DoD_E calls for 3 overwrites.
-------
The standard Sandboxie command when using SDelete is something like:
"...(path to sdelete)\sdelete.exe" -p 3 -s -q "%SANDBOX%"
and this calls for making 3 overwrites.

I know of no reason why Eraser should use 35 overwrites, but SDelete only 3.

Alright Guest10. What do you think about -resultsonerror instead of just -results ? Or perhaps by now those using EraserL are expecting to see the "delete complete" pop-up and will be concerned if it disappears.

Well, to be consistent with my past recommendations, I've always recommended using '-resultsonerror'.

SDelete takes a different approach from EraserL, in that it will alert the user to errors by default unless the '-q' switch is used - a switch that Sandboxie's command uses, and so do I.
Sandboxie's auto-delete also defaults to a 'quiet' mode, if there's problem with deleting the sandbox.
All things considered, I would still go with '-resultsonerror'.
To me, the fewer windows that open and require clicks, the better.
Especially when that window is just showing me that nothing went wrong.

Maybe wraithdu will add his comments about that particular switch.

On second thought ... Anyone already using EraserL will still have the old command (Gutmann/results) in their configuration file. So any changes to the default command should not have an impact on them and will not cause any surprise. I will mention in the release notes using DoD_E/resultsonerror instead of Gutmann/results. Hopefully that be enough.

True, except that any new sandboxes that they create will not have the same EraserL command.
So they end up with a mix of the old and the new.