Sandboxie Support

I'll just make one thread for the several things I noticed that don't work as in 3.76, other than Drop Rights still allowing Administrators-only stuff to be accessed (and SBIE2205: SetInformationProcess, etc.). (One thing that unfortunately IS the same is the Firefox+EMET issues; one of the main things I wanted to test 4.01 for. But just returned a few hours ago! That didn't take long. I still didn't post a final update there of EVERY possible combination of things I tried since then, that ultimately made no difference.)


*) Recent Documents won't work? - After all that, it's not working again. Even with Open=*. On the plus side, at least Explorer doesn't accidentally open UNsandboxed with * or Open=$:explorer.exe (or whatever the "dangerous" scenario was).

*) IE 6 usability: Full Screen - It can't unhide the taskbar anymore. In a general sense, is SetWindowPos() being blocked again...?

*) Links from outside the sandbox (e.g. Automatic Updates, ...) that are forced inside a sandbox (for IE 6 at least) don't work. IE opens but doesn't go anywhere.

*) When Firefox gets minimized, if an UNsandboxed window should then be focused, it is not. I think I had this problem with 4t Tray Minimizer adding buttons to the title bar (nothing to do with SBIE). Nothing to do with that now. But, I think it must have to do with how Firefox is drawing its title bar (non-standard?) that seems to alter messages when minimizing? I haven't noticed it with another program yet.

*) An InjectDll= that works fine in 3.76 (basically, the hook example, simple testing) causes "Application failed to initialize" (for forced programs) or, with Run Sandboxed, nothing to happen at all. I didn't try another DLL yet, though I recompiled mine a couple times (surely it's not done wrong?). I haven't seen other InjectDll reports (other than about Buster's tool in .03), so I'm assuming that's all supposed to work the same? Edit: No, Buster's Anti Delete doesn't work either.

Thank you for the summary. I had a feeling I was going to break the SetWindowPos change with version 4 but then forgot to revisit that. Sorry! I'll take a look at this and the other problems you report here.

Hi. I installed beta 4 the newest one this week (first time trying it) and I have a problem with this version as well. My dos console window popups from the applications no longer show anymore on the taskbar and I can't access it to view it or enter commands. The console is running in the taskMGR, but not visible or accessible on the taskbar. The console popups work fine in 3.76.

Haven't looked into the Recent Documents but I think it is caused by the same issue as reported here,

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

Which was caused by filtering on messages going out to Windows Explorer windows was too aggressive (incorrectly).

SetWindowPos, I fixed.

InjectDll, there is an issue here, which I hope I can resolve.

Also, haven't looked into the speed/performance issue yet (from the other topic), but hopefully next week.

Appreciate your patience

DR_LaRRY_PEpPeR wrote:
*) Recent Documents won't work? - After all that, it's not working again. Even with Open=*. On the plus side, at least Explorer doesn't accidentally open UNsandboxed with * or Open=$:explorer.exe (or whatever the "dangerous" scenario was).

*) IE 6 usability: Full Screen - It can't unhide the taskbar anymore. In a general sense, is SetWindowPos() being blocked again...?

*) Links from outside the sandbox (e.g. Automatic Updates, ...) that are forced inside a sandbox (for IE 6 at least) don't work. IE opens but doesn't go anywhere.

*) When Firefox gets minimized, if an UNsandboxed window should then be focused, it is not. I think I had this problem with 4t Tray Minimizer adding buttons to the title bar (nothing to do with SBIE). Nothing to do with that now. But, I think it must have to do with how Firefox is drawing its title bar (non-standard?) that seems to alter messages when minimizing? I haven't noticed it with another program yet.

*) An InjectDll= that works fine in 3.76 (basically, the hook example, simple testing) causes "Application failed to initialize" (for forced programs) or, with Run Sandboxed, nothing to happen at all. I didn't try another DLL yet, though I recompiled mine a couple times (surely it's not done wrong?). I haven't seen other InjectDll reports (other than about Buster's tool in .03), so I'm assuming that's all supposed to work the same? Edit: No, Buster's Anti Delete doesn't work either.

These issues should be fixed in version 4.01.05.

Thanks for the update! The IE Full Screen/unhide taskbar is now working again, and my InjectDll seems to load fine as well. Cool. The other stuff (3 things you quoted) doesn't, unfortunately.

Recent Docs won't work, even with OpenWin=* (but that DID lead me to a discovery about the speed/performance for the other topic!).

And I just noticed something else where minimizing Firefox doesn't refocus an UNsandboxed window. Previously, I only had UNsandboxed windows visible (other sandboxed stuff minimized), but now I just had UNsandboxed on top of sandboxed, and noticed that minimizing Firefox in that case actually refocuses the last (top) sandboxed window instead.


BTW, I know you didn't quote the other stuff, but the other main thing I'm wondering about that still doesn't work as in 3.x is that Drop Rights allows access to Administrators-only files/reg. keys (so it doesn't "drop rights" in that sense). That's not how it's supposed to be, is it? Just wondering since I reported it right away after the first beta. I kinda need that to work. Luckily SRP dropping rights before Forced sandboxing is covering that for now. (But that also doesn't allow Run Sandboxed to work on those programs because of SBIE2205: SetInformationProcess Hmm, actually don't see SBIE2205 now, but still doesn't start: "A device attached to the system is not functioning. (31)" as before.)


I'll post an update in the other topic later/tomorrow, don't think I have time right now. But big improvements(!) and I just now mostly narrowed down the cause of some slowness I'm still seeing.

Well, now my coding/DLL experimentation has led me to discover another issue with 4.01's InjectDll... (BTW, on the InjectDll page, is this an incomplete 3rd sentence: "Inject" means the DLL is ?)

Anyway, since this particular DLL doesn't need any of Sbie* API functions, I figured I'd just try loading my regular "outside the sandbox DLL," after first thinking it was required to use InjectDllMain, etc. (Then I noticed the InjectDll page says "If the DLL exports" InjectDllMain.)

So what happened? Same result as I originally reported. I spent way too much time trying to track this down exactly (ha, when I'm just trying different stuff), since I was getting different results between 4.01.04 and .05/06, with 3 different (similar) DLLs compiled with VC++ Express 2005 and 2010, as well as an MASM32 assembly version. They're all basically the "same" DllMain-wise, so I thought it was some weird compiler mismatch or such, and proceeded to create empty DllMain DLLs via each method to upload a .zip for you to check..... But then I didn't get the same behavior as the previous DLLs! Then to see why that was...

Turns out this is probably a rare situation, the first being that DllMain returns (dwReason != DLL_PROCESS_ATTACH), so FALSE when it's loaded after it's done its thing, so it can unload as not needed anymore. Change that to TRUE and it works.

Except it also CAN work returning FALSE before your changes in .05. The difference I finally found between my differently-compiled DLLs that I thought were "same enough" was not the compiler, but the EXPORT table! (If that's the right term; I don't really know what I'm doing. )

VC++ seems to create NO export table if nothing's exported. MASM32 version also didn't export anything, although it tries to with default "project" files (empty .def file), so I guess an empty export table is OK for Sandboxie 4.01.04. And of course adding:

__declspec(dllexport) void Dummy(void) { }

makes it work too. Nothing allows FALSE to work however since .05.

Does it go without saying that everything works as expected (and out of sandbox) with 3.76? Also, I see 3.76 does unload the DLL when FALSE is returned (if there's no InjectDllMain). .04 when it works with FALSE, leaves the DLL loaded. Hopefully you can make things behave as 3.76!

(I had typed wrong info (can't keep stuff straight in my head) but it looks correct now!)

I'm sorry, I'm probably not going to touch that. Why don't you just return TRUE? I'm sorry, I don't understand why this is an issue.

Hmm, that was a bit unexpected. I just wanted to explain the details, which have changed over the last couple releases, needed to reproduce this DLL loading error in Sandboxie. Error -- I don't consider it simply an "issue" that I'm doing something wrong, etc. I haven't really gone around searching for DLLs to load, so I don't know what else might do that (ret FALSE)... Didier Stevens' LoadDLLViaAppInit (code included), et al. is about all I've looked at. These normal, nothing-to-do-with-a-sandbox AppInit type DLLs I realized could simply be used with InjectDll, if desired, instead of system-wide with AppInit. That is, like I said, after originally thinking that InjectDll's needed to be Sandboxie-specific, with InjectDllMain, Sbie*, etc. So I thought it was great that "normal" DLLs can be used also, but then I ran into this problem!

There seems to be some major DLL loading problems/weirdness in 4.01 (AppCompat Shims/EMET and ExploitShield), so I figure this might be related, and would be fixed when those issues are.


*I* don't understand why this is an issue either when InjectDll with anything seems to work perfect in 3.76. I don't understand why any of that loading code would change with 4.01. (So it's already been "touched.") Isn't it just doing like LoadLibrary in the processes? So I don't get why Sandboxie is interfering or being messed up by that. The code and DLLs are legitimate, no? Why not return TRUE? Because I don't need to like I said -- the DLL doesn't need to stay loaded once it's done what it needs to do. And it's nice that 3.76 even unloads it too (if no InjectDllMain), like Windows.

Are you saying that this is an intentional change in 4.01, not allowing valid DLLs to load, and 3.76 was somehow broken? And remember, returning FALSE did work in 4.01/.02/03/04, so again, it was "touched" in .05 (I know, obviously for the Sandboxie-specific InjectDll failure I reported here). So then the bug was that for FALSE to not fail, it needed an export table (again, if that's the right term). Again, I don't understand that, since if SBIE would just do a normal LoadLibrary and then look for InjectDllMain, if present, there should be no problem, which is what 3.76 seems to do...

If you could go back to the .04 code, fix the need-an-export-table issue, and leave the OP InjectDll fix, that would be pretty good! e.g. functional with valid DLLs. Then the only thing would be that the DLL still remains loaded with FALSE in 4.01, but whatever..... Though it'd be nice to unload it like 3.76.

I guess it's not unexpected, but FWIW an "empty" DLL without an entry point (so nothing to return TRUE) even loads fine. Just "void Dummy(void) { }" compiled with: cl /LD Test.c /link /NOENTRY

The intention of InjectDll is to develop stuff based on Sandboxie, it is not a general DLL injection scheme for random DLLs.

The way SbieDll is injected into a process in the sandbox has changed a lot between version 3.76 and version 4. This is not an change intentional that returning FALSE on an InjectDll should cause the process to fail to load.

Here's a workaround for you, set the AppInit registry key inside the sandbox rather than as a system wide AppInit key.

tzuk wrote:The intention of InjectDll is to develop stuff based on Sandboxie, it is not a general DLL injection scheme for random DLLs.

OK, so my initial thought about it this whole time was correct then? Cool, I just hope that things have some defined/reliable consistency. (I had assumed I'd [have to] create a SBIE-specific DLL anyway...) So can you update the InjectDll page to say something different? What are the requirements for its use? Right now it says it's to inject "some DLL" (what I was doing; very different than what you said). Also, it's suggested InjectDllMain is definitely optional like I said, so what IS there supposed to be for the DLL to meet the "intention of InjectDll" -- there should be a specifically defined standard, right?

It seems it should just error/reject a DLL without InjectDllMain. That should take care of everything?

But then you had just told me to return TRUE from the DLL's entry point, and that would no longer work either if InjectDllMain is required (which I'm not objecting to, it seems the best to "mandate a standard," so if it's done, stick with it!). So not only is an entry point not required at all (when exporting InjectDllMain), you could even go so far as to say there shouldn't be an entry point...?

BTW, again, what does this mean on the InjectDll page:

"Inject" means the DLL is

The way SbieDll is injected into a process in the sandbox has changed a lot between version 3.76 and version 4. This is not an change intentional that returning FALSE on an InjectDll should cause the process to fail to load.

And I don't get that since it seems like a basic thing... Not that I understand much of its operation, obviously, I'm just sayin'.

It's not an intentional change, OK, but it is the "way it should be" now? Even though it just wasn't before 4.01.05? Again, no problem however it is, just looking for a specific STANDARD, as with most computing things.

I could return (dwReason != DLL_PROCESS_ATTACH || GetModuleHandle("SbieDll.dll")) it seems, but I don't really like the idea (just have 2 DLLs #ifdef'd DllMain/InjectDllMain ). Not to mention it breaking if InjectDllMain is required.

Here's a workaround for you, set the AppInit registry key inside the sandbox rather than as a system wide AppInit key.

I already thought about that (but didn't try), but that's a little more work for others to add... Using AutoExec with REG ADD ... with the registry path and file path, I guess. And then there's the problem if there's already a value there, it's overwritten instead of being appended, etc.

I don't want to mess around with the SbieDll/InjectDll injection mechanism too much. Now in version 4 this is tied into the standard Windows DLL loader, as opposed to an emulation of the Windows DLL loader in version 3.76. If this means some esoteric things are not going to work as before, that's a reasonable trade off for me. Hopefully if you return TRUE from the DllMain in your injeted DLL, that should fix the problem.

Well, if it's supposed to be tied into the standard Windows DLL loader, that would suggest to me that it should be MORE likely that this valid behavior (right? Or hmm: DllMain, Return value...) would work (and it DID before .05!), but... Anyway, I'll look at automating the sandboxed AppInit reg. entry with the program or a script (AutoExec), although I still wish we could simply use any DLL with Inject (any updates to the Help page to clarify?), but whatever's cool. I think any other DLLs I have in mind will need to stay loaded, so I'd have to return TRUE for them anyway.



I'll also wanted to ask if the other 3 issues from this topic, that weren't fixed in .05, are still on your list? No hurry of course, although the "minimizing Firefox not refocusing the right window" thing is getting annoying! Just so you didn't forget. Thanks.

I think Windows loader now sees InjectDlls as static import DLLs for the process, so if your InjectDll DllMain returns FALSE, the process will fail to initialize. If this was a simple issue where Sandboxie is checking the return value from DllMain then I would change it. But it's in NTDLL loader code and I can't control it. I could hook DllMain from the loaded InjectDll DLL and make sure it always returns TRUE but it seems too much work for a rather esoteric use case. I'm sorry I have to disappoint you but sometimes I have to make these cost/benefit decisions.

I still plan to look into those other three issues, yes! But regarding the minimize issue, it's not something I see on my system. If I understand correctly you say this only happens with 4t Tray Minimizer?

tzuk wrote:I think Windows loader now sees InjectDlls as static import DLLs for the process, so if your InjectDll DllMain returns FALSE, the process will fail to initialize. If this was a simple issue where Sandboxie is checking the return value from DllMain then I would change it. But it's in NTDLL loader code and I can't control it. I could hook DllMain from the loaded InjectDll DLL and make sure it always returns TRUE but it seems too much work for a rather esoteric use case. I'm sorry I have to disappoint you but sometimes I have to make these cost/benefit decisions.

Ah, I see! (About acting like a static import.) I guess that would explain the MSDN part: "If the return value is FALSE when DllMain is called during process initialization, the process terminates with an error."

No problem, I understand. Sorry to be a pain when trying to understand things!

I still plan to look into those other three issues, yes! But regarding the minimize issue, it's not something I see on my system. If I understand correctly you say this only happens with 4t Tray Minimizer?

No, I also installed Firefox fresh on the clean laptop system, and had the same behavior (at the time of the bug report). I only mentioned 4t Tray Minimizer because I had a similar (or the same) issue when it was adding extra buttons to the title bar (outside of Sandboxie even). I got the impression that Firefox uses some non-standard/custom drawing of the title bar, buttons, whatever (since it can hide the Menu Bar and put the Firefox menu on the title bar)... And that is somehow affecting messages when minimized, or something. Just figured it might be the same type of thing happening with Sandboxie.

To reproduce: Open some other sandboxed window, open something unsandboxed on top/focused, switch to sandboxed Firefox, minimize Firefox, and the most recently focused sandboxed window will get focus instead of the unsandboxed one...