Sandboxie-Plus v1.7.0, v1.7.0c

This build enables shadow stack for the SbieDll.dll improving on security on systems with gen11 Intel and Ryzen 5000 AMD CPUs.
As this required a change in the entry-point hooking scheme, compatibility should be thoroughly tested.
Further more a couple missing hooks have been added to improve on compatibility.
This build restructures the Box options a bit and adds a hole new page allowing to control the file migration behavior as well as adding a couple SBIE messages to indicate file migration operations which may cause compatibility issues.
Last but not least with this build it is possible to define file checker triggers to for example invoke a script to run a virus scan on a file before it is allowed to be recovered.

Note: as this is a pre-release the installers are not signed, only the driver is.

Download: https://github.com/sandboxie-plus/Sandboxie/releases/tag/v1.7.0

Changelog
Added

• added OnFileRecovery trigger allowing to check files before recovering them #2202
• added more presets to sandbox options
  -- Note: these can only be changed when the box is empty
• added new file migration option page with additional settings
• added SBIE2113/SBIE2114/SBIE2115 message to indicate when files are not migrated due to presets

changed

• moved SeparateUserFolders checkbox from global settings to per box options

fixed

• resolved SbieDll.dll incompatibility with shadow stack and enabled /CETCOMPAT for SbieDll.dll #2559
• added missing registry hooks to improve compatibility with newer applications
• fixed permission issue with registry entries in privacy mode boxes

 

Same question!
An example command to use virustotal to check files before recovering would be appreciated. Thanks.

 

You can set it for example to something like this:

Code:

OnFileRecovery=powershell -exec bypass -nop -File %SbieHome%\CheckFile.ps1 -bin

%SbieHome% is a placeholder for your installation directory so it evaluates usually to "C:\Program Files\Sandboxie-Plus"

CheckFile.ps1

Code:

param ($bin)
$sigcheck="C:\Tools\sc\sigcheck64.exe" -vt -vs -accepteula $bin
if(-not ($sigcheck -like "*   0/*")){
    Write-Output $sigcheck
    exit 1
}
exit 0

and copy sigcheck64.exe to "C:\Tools\sc"
sigcheck is a sysinternals tool that can be downloaded for free form microsoft: https://learn.microsoft.com/en-us/sysinternals/downloads/sigcheck

 

Thank you for this example. Will give it a try.

In the meantime, sandman just crashed with v1.7.0.
I have emailed you the dump file.

 

I just found there were nearly 20 dmp files generated within a few minutes.
I had emailed you just one. I'd be happy to send you all of them if you like.

 

This is not a real crash, i added a new exception handler and it seams its a bit over achiving also triggering on cought exceptions, ups, 1.7.0a with a fix will be out sortly

 

I edited all paths to D:\SbiePlus (my portable sbie folder), and
copied sigcheck64.exe and checkfile.ps1 to the same directory.
While recovering a file for download, an informational ribbon
pops up and the file is recovered to my desired location

 

I have updated the installers please re download and re install to solve the sandman issue, or use the live updater in the preview channel to get 1.7.0a

 

OK, well since Smart Screen had a problem w/first 1.7.0, went ahead and installed the "a" over the top. Didn't experience any "crash" yet with the prev. but felt better about over-writing that build.

So, we'll see how it goes.

 

1.7.0b uploaded with a bunch more fixes

 

sandman crash with v1.7.0b (also with v1.7.0a)
when implementing "maintenance=>stop all"

Clicking 'OK' proceeds successfully with operation.
Would you like me to email you the dump file?

 

v1.70b: More sbie messages (that I have not seen before) when I rebooted my machine:


EDIT:
Re-downloaded from link in first post (instead of sbie live) and rebooted.
No sandman crash so far, and no sbie messages as in attachment above.

 

well the blue box protects your data form being accessed by sandboxed programs, so whatever setting you make unsandboxed will not be seen by the sandboxed programs.
You will need to set the right file or registry paths to "Normal" in order to be readable by a sandboxed process. Probably something in AppData/local/....

 

@stapp
Probably, for some users, the sidebar is turned on by default.

On my regular system, it's on by default. (to test it (unsandboxed): rename "%LocalAppData%\Microsoft\Edge\User Data" "User Data_BAK")

On my VM system, it's off by default.

 

I'm asking for be sure. Did you rename "User Data" folder before opening unsandboxed Edge? So it can create new defaults like BlueBox.

 

1. Let's say you renamed "User Data" to "User Data_BAK"
2. When you open Edge unsandboxed it will create new "User Data" folder.
3. Close Edge (Make sure no other msedge.exe's are running because of Startup Boost)
4. Rename newly created "User Data" to "User Data_test"
5. Copy "User Data_BAK" as "User Data"
6. When you copy the "User Data_BAK" folder as "User Data", the settings should be restored.

 

Can anyone here reproduce this issue: https://github.com/sandboxie-plus/Sandboxie/issues/2588