Sandboxie Support

Note: You'll need the Microsoft Visual C++ 2010 Runtimes for the DLL to work:
x86
x64

Using information from this post

http://www.sandboxie.com/phpbb/viewtopi ... 6778#26778

sbiextra
======

I've created a DLL to block sandboxed processes from accessing information about processes running outside the sandbox, and to prevent them from reading the memory of any process not running in their same sandbox. This is accomplished by hooking several API functions:

- NtOpenProcess
- NtQuerySystemInformation
- NtReadVirtualMemory
- CreateToolhelp32Snapshot
- BlockInput
- InternalGetWindowText
- GetWindowTextA/W
- SendMessageA/W
> WM_GETTEXT

The effects of using this DLL on sandboxed processes are as follows:

- block system-wide enumeration of running processes and threads (includes Toolhelp32 and PSAPI functions)
- block access to unsandboxed processes - cannot open processes, or read their memory
- prevent sandboxed processes from calling the BlockInput function (blocks mouse and keyboard input)
- prevent sandboxed processes from reading window titles or control text

To use it, download the DLL and save it somewhere. Then insert this line in your Sandboxie.ini file under the sandbox you want to use the DLL.

32-bit platforms: 64-bit platforms add both: On x64 platforms, both DLLs and directives should be used. Sandboxie will inject the proper DLL depending on whether the target process is 32-bit or 64-bit.

The DLL will be injected into any process running in the sandbox. That's it!


Optional INI File:
============

To control which of the above functions are hooked in a sandboxed process, copy the provided 'sbiextra.ini' file to the same directory as 'sbiextra.dll'. For each function you want to hook, set the value to 1, for each function you don't want hooked, set the value to 0.

Additionally, the DLL can output some debug information so you can see some of what is going on. To output this information, set the value of 'ShowDebugInfo' to 1. To see the debug output, install and run Dbgview from Sysinternals before starting a sandboxed process.


Test Program:
=============

Also included in the archive is a small test program. First it will attempt a system-wide process snapshot using the Toolhelp32 API, then it will attempt to read 16 bytes from the base address of 'kernel32.dll' from the process whose PID you provide on the command line, and finally it will attempt a process module snapshot of the provided PID using the Toolhelp32 API. To test, run 'injtest.exe' in the sandbox where you're injecting the DLL and provide the PID of a sandboxed or unsandboxed process on the command line. The system snapshot should fail (return a handle of 0xFFFFFFFF). If the target process is unsandboxed, 'injtest.exe' will not be able to read it's memory or take a snapshot. If it is sandboxed, the functions will succeed.

Next it will take a snapshot of all the windows on the system and try to get their titles via three different methods: InternalGetWindowText, GetWindowTextW, and directly via SendMessageW with the WM_GETTEXT message. Most of the window titles should remain blank for all three tests.

sbiextra v1.0.0.17
(md5: 4b1705e8cb98ffddb970b8426bfdc772)
*Requires Sandboxie 3.51 beta or higher.

Oh, forgot to mention, you can see the debug output using DbgView. You will also need the Microsoft VC++ 2008 SP1 runtimes.

Nice work wraithdu, lots of effort. Do you foresee any issues if also running Returnil alongside Sandboxie?

I don't think so. Sandboxie injects my DLL into any sandboxed process. I believe Returnil runs at the filesystem level. If Returnil doesn't conflict with Sandboxie in general, there's nothing about this method that would change that compatibility.

Thank you wraithdu!

I run cmd.exe unsandboxed and then your test program sandboxed and seems like your test is able to read the 16 bytes.

I think I´m not doing anything wrong. Anyone else with same result?

Buster, run DbgView with your test. Do you see my debug output? It should print lots of information about the function pointers, when the ReadProcessMemory function is intercepted, the enumeration of modules in cmd.exe, and whether the call is blocked or allowed.

If you don't see anything, then I suspect you're missing the MS VC++ 2008 SP1 runtimes, and the DLL fails to load when injected, or your INI entry is wrong.

Sample DbgView output:

wraithdu wrote:If you don't see anything, then I suspect you're missing the MS VC++ 2008 SP1 runtimes, and the DLL fails to load when injected

Yeah, very probably I don´t have the runtimes.

Do you know the file names of the required runtimes?

btw... I don´t receive any error message about missed runtimes. Usually they are showed.

Let´s wait until anyone else make a test and comment results.

Running as advertised here on Vista SP1 and XP SP3. I did not have the necessary runtimes, so I used the installer provided at the link in wraithdu's first post. The only problem I ran into was my own fault...I initially forgot to reload the config. Thank you wraithdu for your work.

You won't get any errors about missing runtimes because the DLL is remotely injected. If it fails, it's up to the loading application (Sandboxie) to notify you.

You could also check 'injtest' while runing with Process Explorer to see if the DLL is in fact loaded.

The required runtime is 'msvcr90.dll'. You need to run the installer to properly install these runtimes.

wraithdu: Installing the Microsoft Visual C++ 2008 SP1 Runtimes the DLL will be injected correctly.

You should explain why you created the DLL and what´s its purpose.

tzuk: Only one DLL can be injected. At the moment I don´t have the need of loading 2 or more DLLs but maybe it could be a feature request to consider.

Why did I create it? I was curious from the post about WoW and the Warden client. I still hope that guy tests it, cause I wanna know if Warden freaks out. My other reasons... it was a challenge.

The purpose is pretty clearly stated. It blocks sandboxed processes from using the ReadProcessMemory function (search MSDN) to read the memory of unsandboxed processes. Incidentally it also blocks the EnumProcessModules function (and perhaps others) of PSAPI.dll, since that function internally seems to use ReadProcessMemory.

What is the returnnil option? Another dll plugin?

Umm, no.

www.returnil.com