Question regarding Sandboxed programs that attempt to delete
Question regarding Sandboxed programs that attempt to delete
Hi all,
I was wondering if there is a feature someplace that I have overlooked that preserves files that are targetted by the sandboxed program for deletion?
IE: whatever the file creates, if it tries to delete it later, the "deleted" file should go to a recycle bin or something in the sandbox. I wish to preserve all files created during the sandboxed programs run. Including any files the host program tries to purge.
I was wondering if there is a feature someplace that I have overlooked that preserves files that are targetted by the sandboxed program for deletion?
IE: whatever the file creates, if it tries to delete it later, the "deleted" file should go to a recycle bin or something in the sandbox. I wish to preserve all files created during the sandboxed programs run. Including any files the host program tries to purge.
Damn, I was the one who posted as HappyUser as I was away from my home computer at the time...
The reason I wanted the feature is the same as yours Buster. I have gone so far as to tell sandboxie that my entire documents and settings folder is available for quickrecovery upon something trying to delete. When testing a malware sample the other night, I wasn't able to capture one of the temporary executables it drops, short of manually extracting the installer myself. Sandboxie showed the file as available for recovery, but when I tried, no file found recovered. Strange too, it would bring back others.
Anyway... It does allow me to pick a folder I can recover too. Maybe tzuk could add a box we could check for autorecover, and store the "deleted" files in the folder we picked previously?
That would accomplish our needs of preservation I suspect. As we both know the installers are using temp folders from documents and settings trees.
The reason I wanted the feature is the same as yours Buster. I have gone so far as to tell sandboxie that my entire documents and settings folder is available for quickrecovery upon something trying to delete. When testing a malware sample the other night, I wasn't able to capture one of the temporary executables it drops, short of manually extracting the installer myself. Sandboxie showed the file as available for recovery, but when I tried, no file found recovered. Strange too, it would bring back others.
Anyway... It does allow me to pick a folder I can recover too. Maybe tzuk could add a box we could check for autorecover, and store the "deleted" files in the folder we picked previously?
That would accomplish our needs of preservation I suspect. As we both know the installers are using temp folders from documents and settings trees.
Everything is so different, yet I am the same...
I don't see Sandboxie as a malware research tool, so I'm not going to add features that are dedicated to malware research. Buster, I've already mentioned the InjectDll setting which would let you inject DLLs into sandboxed programs. All you need is to write a small DLL that hooks DeleteFile and prevent the deletion. Maybe you and guys can team up and figure out how to do that.
tzuk
I understand you didn´t code Sandboxie as a malware research tool but it can be used for that purpose as I use it for other tasks. I didn´t insist in the feature because almost nobody else seemed interested on it.tzuk wrote:I don't see Sandboxie as a malware research tool, so I'm not going to add features that are dedicated to malware research. Buster, I've already mentioned the InjectDll setting which would let you inject DLLs into sandboxed programs. All you need is to write a small DLL that hooks DeleteFile and prevent the deletion. Maybe you and guys can team up and figure out how to do that.
I was researching the InjectDll but I was unable to do it. The DLL I coded uses a system hook which is not compatible with Sandboxie.
Personally I would not hook DeleteFile but NtSetInformationFile and then I would check if FileInformationClass is equal to FileDispositionInformation.
If anyone has any idea of how to code such DLL I´m open to collaborate with him to make it.
But indeed it is used for that. As I see it, it's a perfect fit, though I'm not campaigning for a function to allow placement of deleted files/sessions.tzuk wrote:I don't see Sandboxie as a malware research tool
I'm new to Sandboxie, so I may not even understand what raid and Buster are getting at. Nevertheless, I know many who use Sandboxie for their malware "surfing" to rate sites (a la WOT and SA). My compliments, tzuk.
BJ
Ultimately, the only protection against phishing, forged Web pages, downloading malware, and other threats is the technology located between the user's ears.
Ultimately, the only protection against phishing, forged Web pages, downloading malware, and other threats is the technology located between the user's ears.
Sample DLL:
Note the use of SbieDll_Hook to hook APIs, along with InjectDll, this makes it very easy for you to focus on the interception logic and not the boilerplate of injecting DLLs and rewriting APIs. But you have to run the program sandboxed, otherwise none of that works.
Now let's say you compile this into c:\temp\inj.dll, so you add a DefaultBox setting,
Refresh configuration, start a sandboxed command prompt, type "del somefile.txt", you'll get a message box and the file will not be deleted.
Code: Select all
#include <windows.h>
//
typedef void *(*P_SbieDll_Hook)(const char *ApiName, void *ApiFunc, void *NewFunc);
typedef BOOL (*P_DeleteFileW)(const WCHAR *Path);
//
static P_DeleteFileW pDeleteFileW = NULL;
//
static BOOL MyDeleteFileW(const WCHAR *Path)
{
const WCHAR *dot = wcsrchr(Path, L'.');
if (dot && _wcsicmp(dot, L".txt") == 0) {
MessageBoxW(NULL, Path, L"Intercepted", MB_OK);
SetLastError(0);
return TRUE;
} else
return pDeleteFileW(Path);
}
//
BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
if (dwReason == DLL_PROCESS_ATTACH) {
MessageBoxW(NULL, L"Started", L"InjDll", MB_OK);
}
if (dwReason == DLL_PROCESS_ATTACH) {
HMODULE SbieDll = GetModuleHandleW(L"SbieDll.dll");
P_SbieDll_Hook SbieDll_Hook = (P_SbieDll_Hook)
GetProcAddress(SbieDll, "_SbieDll_Hook@12");
HMODULE Kernel32 = GetModuleHandleW(L"Kernel32.dll");
pDeleteFileW = (P_DeleteFileW)
GetProcAddress(Kernel32, "DeleteFileW");
pDeleteFileW = SbieDll_Hook("DeleteFile",
pDeleteFileW,
MyDeleteFileW);
}
return TRUE;
}
Now let's say you compile this into c:\temp\inj.dll, so you add a DefaultBox setting,
Code: Select all
InjectDll=c:\temp\inj.dll
Last edited by tzuk on Wed Sep 24, 2008 7:02 am, edited 1 time in total.
tzuk
It does work for me. I've revised the source above to include another MessageBox which appears as soon as the DLL is injected into the process. You can get my compiled DLL here:
http://www.sandboxie.com/Inj.dll
I compile with the Windows DDK compiler.
http://www.sandboxie.com/Inj.dll
I compile with the Windows DDK compiler.
tzuk
It almost does what I want.tzuk wrote:Ha, I guess the build tool knows its stuff. Glad the DLL is working, I'd like to hear that you got it doing what you want and that you can take back your feature request.
Do you know if it´s possible to know (if yes, some code would be of help) what´s the file name that made the DeleteFile call?
Who is online
Users browsing this forum: No registered users and 1 guest