Skip navigation links
IT services and product development
Menu
TwoLogs
IT services and product development

SandboxieReflector - version 12.3.19

Introduction

SandboxieReflector was created by Carl Colijn, TwoLogs, primarily to scratch my own itch.  It is a user-contributed utility for use with the excellent Windows security application Sandboxie; check it out if you haven't already!  It is available free of charge; you can download the installation zip file from the links below;

Current version

Older versions

!Warning!

SandboxieReflector could, in the hands of unknowledgeable persons, make your Sandboxie totally ineffective.  Please only use this product if you know what you're doing and if you can assess the risks and are willing to accept them!

Introduction

SandboxieReflector is a small application that lets you reflect some pre-specified commands (via a command line) into a designated sandbox, even from inside another sandbox.  This can be most useful if certain actions inside one sandbox must be executed inside another one.  Concrete examples of this are e.g.:

Activate applications in other sandboxes
You have two sandboxes; one for your e-mail application and one for your browser.  You now receive an e-mail with a link in it which you want to visit.  But you want to run the browser in it's own designated sandbox.  For better overall security reasons, Sandboxie however will run the browser in the sandbox of your e-mail application.  This will result in the e-mail application's sandbox being "polluted" with e.g. the Internet cache of that browsing session.
Start an application installed in one sandbox from another sandbox
You have installed application X in it's own sandbox.  Application X is thus not known to any applications outside of that sandbox.  To start application X, you can use Sandboxie's "Start.exe" functionality, but again, if this is called from inside another sandbox Sandboxie will want to run application X in the sandbox you are currently in.  Needless to say, application X is not known there so you're out of luck.
Route file associations to a specific sandbox
You have installed application X in it's own sandbox, and this application has registered it's own file associations.  These associations are only known inside that sandbox.  So even if you would export them to the registry outside of the sandbox, Explorer would be unable to start the target application, since it is not present outside of it's sandbox.

How it all works

To pass commands out of a sandbox, SandboxieReflector is made of two cooperating applications - the "Reflector" and the "Effectuator".  The Reflector is started inside of a sandbox, and needs to be given the command to execute via the command line.  The Reflector then passes it's command line arguments via the pipe named "SandboxieReflectorCommands" unmodified to the Effectuator.  The Effectuator examines the command line arguments given, links it to pre-defined profiles, and if all matches up it executes the correct command in the correct sandbox.

Since this kind of functionality could in essence be a giant breach in Sandboxie's security, the actual commands are specified in pre-defined profiles to keep the level of security as high as possible.  These profiles must be specified by you in the settings file (which should be placed outside of the reach of any sandbox's influence, to keep bad actors out).  With this set-up any malicious forces will only be able to run these pre-defined commands, and then only if they know the names you have given to the profiles as well.

Usage

Installation is simple - just reserve a folder for SandboxieReflector anywhere on your system, copy over all files found in this archive, and run the executables from there.  SandboxieReflector doesn't modify any registry keys or files, so an uninstall is as simple as deleting it's folder.

The Effectuator needs to be running for Reflectors to be able to contact it.  You can start the Effectuator by running it with the /s command line option; this will put it in the notification area.  If you use SandboxieReflector regularly, consider creating a shortcut to it in your "Program Files\Startup" start menu with this switch in it.

Since the Reflector needs to be able to communicate with the Effectuator, you need to open up the used communication channel in any sandbox you want to use the Reflector in.  This is done by adding the line

OpenPipePath=Reflector.exe,\Device\NamedPipe\SandboxieReflectorCommands

to that sandbox' configuration (or to the [GlobalSettings] section to enable it for all sandboxes).

The command line issued to a Reflector is passed on verbatim to the Effectuator.  There are currently two types of commands supported (both not case sensitive);

/quit
Quits the Effectuator.
/exec <execution profile name> [/p <param name> [<value 1> [<value 2> [...]]]]
Executes the given profile, optionally specifying the given parameters(s).  The Reflector call needs to specify exactly the same parameters as are used in the corresponding profile.  Parameters may be specified without a value to erase them from the final command started by the Effectuator.  If more than one value needs to be specified for a parameter, let them follow each other in the argument list; all arguments are added as values up to the next switch.  Therefore values cannot start with a "/" character.

For the Effectuator to run, you need to create the settings file first.  This settings file should be named "SandboxieReflector.ini", and should be placed next to the "Effectuator.exe" file.

The SandboxieReflector.ini file is a regular Windows INI file.  It should contain the following section:

  [GlobalSettings]
  SandboxiePath=<Sandboxie's installation path>

The settings are:

SandboxiePath
The installation path of Sandboxie itself.  This setting should typically be set to C:\Program Files\Sandboxie.

Each execution profile section should be noted as follows:

  [ExecProfile_<profile name>]
  Box=<sandbox name>
  UsesDDE=<y|n>
  CmdLine=<command line to run>

The settings are:

Section name
Should start with ExecProfile_, to which the profile's unique name should be added (not case sensitive).
Box
Optional.  The name of the sandbox this profile uses.  May be left empty or missing to run something outside of any sandbox.
UsesDDE
Optional.  Whether the command also uses DDE to accomplish it's task.  See below for an overview of how to handle DDE commands.
CmdLine
The command line to start (inside the above specified sandbox, or outside any sandbox).  You can specify the parameters in the command line by putting their name within "$" signs, like: 
CmdLine=Notepad.exe $file$
The $file$ above will be replaced by the values specified in a mandatory /p file <file path> on the Reflector's command line.  Note that parameter names are not case sensitive.  You can insert a "$" sign by doubling it, like $$.  All values will be enclosed in double quotes for you, so you should not add the quotes yourself in this command line.  If more than one value is specified, they will be seperated with a space.  If the command is not to be run in any sandbox, the main executable's path should be fully specified.

Reflecting DDE commands

Warning: reflecting DDE commands is a much tougher job than reflecting simple command lines.  Be aware that setting this up correctly might prove a nice time sink if you're not sure what you're doing ;)

Each execute profile is represented by a command line.  However, sometimes the command you want to reflect also uses DDE (Dynamic Data Exchange) to work properly.  One such place DDE is sometimes used in conjunction with a command line is in file and protocol associations.  This happens e.g. with .doc files registered by Word 2003, but e.g. FireFox also registers DDE commands with the "http(s)" protocol handlers.  The below explanation describes how to enable DDE commands when sandboxes are involved.  It takes Explorer's use of file associations as an example, though it should also be true for other uses like your e-mail client opening an URL in your browser via a protocol association.  In fact, almost anything being started/opened through ShellExecute should be able to work.

When an application supports DDE for opening files, it can say so when registering it's file association in the registry by adding a "ddeexec" key.  When Explorer is asked to open a file that is registered this way, it first broadcasts a DDE call to all applications to ask them to open it (assuming any responding app will in fact be the correct one).  If no-one responds, then Explorer falls back on the regular command line to start the needed app, and when the app is started it makes a targeted DDE call to it to finalize the opening of the file.  If any of the latter steps fails, Explorer raises an error that it cannot find the requested file, suggesting you have incorrectly spelled it's name (which of course is a misleading message in this situation).

Behind the scenes DDE calls are messages back and forth between the source and target windows.  Thus, when either the source or target application is sandboxed, Sandboxie will rightfully block any message coming from the sandboxed application to protect the rest of the system.  Step one is thus to open up this conversation channel via some OpenWinClass settings in Sandboxie.ini.  For this you need to know the exact window class names of the windows involved; this can be found by using an application like WinSpy++ or by using Sandboxie's Resource Access Monitor and looking for any blocked window classes.

If you have opened up the correct windows, then Explorer should already be able to open a file of the involved type when the app is already running.  When the application is not yet running though, Explorer will now start the Reflector in stead (since we reflected the command line), and then it expects the Reflector to handle the ensuing DDE conversation.  By specifying the "UsesDDE" setting, the Reflector will pass on the DDE initialization calls straight to the just opened application, and from then on Explorer will talk to the correct application again.  You therefore also have to open the window classes relevant for the DDE conversation for the Reflector.

Note that most applications have an option of opening files from the command line, without using DDE.  If setting up the DDE communication doesn't work out for you, then you can most often simply modify the file association to only use a command line.  Note however that this might have other side effects, like multiple instances of the app running, while the app isn't designed to allow this, so use this method at your own risk.

Example

The main reason I created SandboxieReflector is to use it as a launchpad for file associations, where the applications are installed each in their own sandbox.  When you install an app in it's own sandbox, and when the app registers some file associations, those associations are only going to be effective when you open an Explorer instance in that sandbox.  But if you export the relevant file association portions of the registry, re-map the paths and commands to use SandboxieReflector, and then apply the reg file outside of the sandbox, any process (incl. within other sandboxes) can open that file type in the designated sandbox.

A simple step-by-step guide for this is:

  • Create a new sandbox
  • Install the new app in that sandbox, and let it associate some file types
  • Make sure something is running in that sandbox (a simple cmd.exe or Sandboxie's own "Run any program" prompt will suffice)
  • Open RegEdt32.exe outside of any sandbox
  • Export the HKEY_USERS\Sandbox_<username>_<sandboxname> registry branch
  • Edit the just exported .reg file, and throw away all but the needed file association stuff
  • Remap any DefaultIcon values to point right into your sandbox store, like e.g.:
    C:\Sandboxie\<username>\<sandboxname>\drive\C\Program Files\NewApp\NewApp.exe,1
  • Add a new execute profile for all unique shell commands to SandboxieReflector's INI file, copying the commandline used in the registry
  • Alter the above CmdLine setting so it uses $file$ where it says %1
  • Modify the shell commands in the .reg file to use:
    "C:\Program Files\SandboxieReflector\Reflector.exe" /exec <profilename> /p file "%1"
  • Import this reg file into the real registry outside of any sandbox
  • Re-start the Effectuator for it to see the changed settings

By now you should be able to open document files for your new app in any sandbox you like, while the new app will always run in it's own sandbox!

Limitations

Recent versions of Windows also introduced two alternative methods for apps to start when opening file associations - the DelegateExecute and DropTarget routes.  These method route the executing through COM.  Opening up the relevant COM ClsID's in Sandboxie might make it all work, but SandboxieReflector has no notion of these two methods.

Support

Since I expect the audience for SandboxieReflector to be above average considering computer literacy, and since I want to somewhat discourage novice users from using this solution for their own good, I have decided to not develop/document it any further.  Also, there are possibly plans to add forcing certain applications to run in certain sandboxes to the core Sandboxie functionality, making any further development of SandboxieReflector a dubious investment.  I have thought about adding DDE proxying support to SandboxieReflector, but since this can be solved by white-listing window classes once Sandboxie supports running apps cross-sandboxed, I'll pass on that as well.

Therefore please do not send me support inquiries, unless they concern potential security breaches I have not noticed, or if you want to suggest some nice (and easy to add) additions.  Also consider voicing your desire for this feature in Sandboxie itself to possibly make the addition come faster ;)

Version history

Version 12.3.19

  • The Effectuator now automatically re-loads the settings file when it changes.

Version 12.3.13

  • Added DDE proxying support so file associations using DDE will also be able to open.

Version 12.3.2

  • Added true parameter passing in stead of using fixed /file Reflector.exe arguments and %1 CmdLine setting placeholders; existing installations can easily be adjusted by replacing %1 in the CmdLine setting by $file$, and adjusting any /file Reflector command line arguments by /p file.

Version 12.2.22

  • Initial release.

Background story

When I needed to re-install the entire OS again on both my dev PC's due to accumulated Win rot, I wanted to start using virtual machines as much as possible due to their benefits;

  • they can be backed up,
  • you can deploy them on more than one PC, and
  • you can take and restore snapshots of their state.

However, virtual machines come with some big disadvantages;

  • they inflict serious memory overhead, making running a few of them simultaneously impossible on my hardware,
  • their files are huge to backup (and they change even if you've only restarted them), making frequent backups impractical, and
  • they allow you to access the files on your drive by virtue of mapping folders as networks shares, but therefore accessing each file requires traveling the network stack (quite a bottleneck when working with large numbers of small files).

Ideally I also wanted to isolate each app in it's own virtual machine to make it easier in the future to throw one away and still keep the rest of my set-up clean and working.  So when I then stumbled upon Sandboxie, I decided the best way to proceed for me would be to install each application in it's own sandbox and forget about virtual machines.  If I stick with the current OS on all my machines, the effects would be:

  • Future re-installs of both the OS and the apps themselves are as pain-free as possible (same as deploying a previous virtual machine),
  • The app installations can easily be backed up to my other PC, so I can continue working there might my main PC croak again one day (same as virtual machine disk files, but now without the overhead of an entire OS),
  • Each app install can be "reverted" easily to a predefined state by just restoring a backup of it's entire sandbox (same as virtual machine snapshots), and
  • I can truly put each app in it's own sandbox (practically impossible with virtual machines).

Sandboxie however posed some (understandable) restrictions on this set-up, so I needed to circumvent them, resulting in SandboxieReflector.

Since this concept can for some people be a very useful addition to Sandboxie as well, I decided to slap on a better GUI, add this documentation and make it freely available.

Happy reflecting!