Sandboxie Plus 1.0.1

I looked into it yesterday, even disabling the box update entirely, the result was still a fiew 0,xx % being burned all the time inside the Qt libraries
Its expected to be a plus issue only as classic does not use Qt.

 

Any plans to port SandMan to Qt 6?

 

David, thanks for looking at it again. FWIW I have seen Qt bases programs stay at 0% even when idling in a foreground window. Maybe some plus background activities can be achieved without going through Qt?

 

The rule of thumb is the newer the framework the more unnececery CPU usage it causes, or else the CPU manufactures would go bankrupt.
So I don't think that moving to Qt6 will help here at all

 

https://user-images.githubusercontent.com/3890945/105014988-575cb680-5a41-11eb-90d5-d942d28184b2.png

This build introduced a new major feature, system call hooking for win32k syscalls, it is used only for a hand full of calls currently, and is currently not working for 32 bit applications running on a 64 bit host, that limitation is being worked on.

This feature resolves the Hardware Acceleration issues with Chromium based browsers, it can be enabled like this:

https://user-images.githubusercontent.com/3890945/145731058-d3ee73ad-3e6a-48f2-9b00-29d99b53b1e0.png



Changelog
Added

• added mechanism to hook Win32 system calls on windows 10 and later, this should resolve the issue with Chromium HW acceleration
  -- Note: this mechanism does not, yet, work for 32 bit applications running under WoW64
  -- to enable it, add "EnableWin32kHooks=y" to the global ini section, this feature is highly experimental (!)
  -- the hooks will be automatically applied to Chromium GPU processes
  -- to force Win32k hooks for all processes in a selected box add "AlwaysUseWin32kHooks=program.exe,y" #1261 #1395

Fixed

• fixed bug in GetVersionExW making "OverrideOsBuild=..." not working #605 #1426
• fixed issue with some UTF-8 characters when used in the ini file
• fixed isolation issue with Virtual Network Editor #1102

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

 

Hi @DavidXanatos Issue #1395 is actually my post that someone must have kindly copied over to Github (I do not have an account on Github). I see you've marked it as closed and fixed in this build, however the issue is not fixed.
I have downloaded 1.0.3 & altered my global settings with all three Sandboxing feaures ticked in the Advanced config as per the diagram, then I rebooted.
With those new features ticked, Edge on Windows 11 will not load at all. It simply loads a white window, both with and without HW acceleration enabled. If I untick the options, I can load Edge (as long as HW acceleration is enabled), but the "Find On Page" search bar remains invisible.

I'm not sure if you missed my reply on your other post about this fix, but I did mention there the workarounds didn't work, with this exact result, and that Edge is completely unusable under Sandboxie on Windows 11 with the fix enabled.

I see you've noted that the fix won't work in 32bit applications on WoW64. Edge says it is 64bit in the about section, but strangely the executable and all the files for Edge are located in my Program Files (x86) folder. The computer is 64bit.

I'm conscious that not many are running Windows 11 at this point, and it's only one aspect of Edge that doesn't work with Sandboxie. So no worries if you haven't the time or wish to pursue a fix. I can always use another browser if I want to use the "Find" feature, and my preference is actually to run Edge with HW acceleration enabled, so it's not bother to me if it won't load with HW acceleration disabled. The point of my post is just to let you know that the issue isn't fixed and perhaps shouldn't be closed.

 

I did not realize that issue was yours, on my win 11 test system I could reproduce the missing search box and with the 1.0.3 build ant that options enabled the search box is displayed properly.

Does the status column for your edge says "Running" or "Running *32" if the later its a 32 bit process if the former than its 64 bit, despite the location under program files x86.

Have you tried running msedge in a box in compartment mode?

 

Just to confirm the new build works for EdgeChome and Brave on my 11th gen with "EnableWin32kHooks=y" in the global ini. I am curious and would be interested to know how the new hook and "AnonymousLogon=n" appear little related yet both could solve the x64 hw-acceleration problems on some 11th gen. Many thanks again

 

Ah that's so strange it worked for you with that setting. I literally get a white window with a yellow border. Not even an "x" to close it. I have to do that by deleting the contents of the sandbox.

It says "Running". Also in Edge settings it clearly says 64bit by the version number. Not quite sure why it decided to install itself in my x86 folder.

No, I couldn't try that compartment box, as the option is actually greyed out on my Sandboxie settings. By the description it looks like the security is a little less, so I probably wouldn't be keen to use it in that one anyway.

EDIT!!! IGNORE THE ABOVE! I decided to go nuclear and uninstall Sandboxie including my ini file. I went through Programme files, App data and the Registry looking for all traces of Sandboxie and was impressed to find no remnants at all. I rebooted and then installed Sandboxie. The only changes I made to the default settings was to enable Immediate Recovery, Autodeletion, and I ticked those 3 experimental settings in the global settings that provide the fix for this issue. Then I rebooted again. Whaddya know! Edge now loads properly and the "Find on Page" search bar works!!! I've re-enabled Drop Rights now and that still works with the fix too.

Looks like something must have gone a little awry with the process of upgrading from Win 10 to 11, or perhaps when doing an update and choosing to overwrite the installation at some point (I've overwritten many builds).

In Task Manager my Sandboxed Edge does still show in Background Processes instead of the Apps section, which is a little strange. Your hunch that the task manager issue was unrelated must be right.

 

JFYI: Unfortunately, Microsoft has always installed the Edge browser automatically under "Program Files (x86)", regardless of whether it's the 32-bit or 64-bit version. It's funny that Microsoft doesn't follow its own guidelines...

 

Its grayed out because you don't have a supporter cert, but you can create a new box with that preset for testing.

 

Good news!! I think we were typing at the same time. See the Edit I made to the post!

 

Yes rather ironic eh. MS is annoying me today. I've had that stupid telemetry pop up eight times today (the "Help us make search better for you" one). Can't get rid of it unless I select either "Got it" or "Manage settings". Either one immediately re-enables the setting to send search results to MS. So I disable it again again again again. Got a suggestion to try from eleven forums which involves altering a flag in Edge, which I'll have a look at tomorrow.

 

Sandboxie's primary method of process isolation replaces the normal process token with a heavily restricted token that does not have the right to do pretty much anything. Doing so Sandboxie basically breaks most things, and than has to repair them with workarounds. There are 3 ways of doing that:
One is to let a secure broker (sbiesvc) to do the operation on the calling processes behalf.
The second is to ask a secure broker to set the permissions on some object to be accessible by the sandboxed process despite its heavily restricted token.
Third is to hook syscalls and direct them through a custom interface provided by the driver (sbiedrv) the driver having all the power of the kernel then for the duration of the syscall sets the calling threads impersonation token to a substantially less restricted version of the original process token, and then clears the impersonation before returning the control flow to the user mode code. Here any redirected syscall can be inspected and denied it if it found it may violate a sandbox security boundary.

Method 1 is used in rare cases, as its a lot of work to add such custom workarounds.
Method 2 is used for all desktop related stuff (win32k.sys), so user32.dll, gdi32.dll and such, when a process is created and tries to connect to the desktop it is granted the permission to do so despite the token used.
and Method 3 is used for all other (ntoskrnl.exe) ntdll.dll operations.

So the assumption is that once a process was granted access to the desktop all win32k.sys related operations will succeed, unfortunately it seams that some GdiDdDDI* functions still don't work for a process with a restricted token, this breaks for example chrome's HW acceleration.

When you set "AnonymousLogon=n" this makes the heavily restricted token no longer having the Anonymous SID but retaining the SID of the user which started the process. This seams to be enough of privilege for the GdiDdDDI* functions to operate.

The new win32k hook feature employs Method 3 also to syscalls directed to win32k.sys so the GdiDdDDI* functions see the substantially less restricted token and work as well.

This is currently done only for GdiDdDDI* syscalls and only when running a native application i.e. it does not work for 32 bit applications on a 64 bit system (a.k.a. WoW64).

There are significant technical hurdles to make this work with WoW64 as in contrary to the ntdll.dll, the relevant functions are not exported from wow64win.dll and hence can not be easily hooked.

 

David, thanks for the detailed explanation, I will take time to understand. Appreciated

@DavidXanatos: In terms of security, is the new win32k hook better, worse or the same as AnonymousLogon=n?

 

How can I donate outside of Patreon; personal reasons? PayPal fine if only I can get recipient details.

 

PayPal Donate button here -> https://sandboxie-plus.com/
Patreon page here -> https://www.patreon.com/DavidXanatos
btw ~ Patreon works okay, for me.

 

There is a paypal donation button on my homepage. Why do you need recipient details? I'm not a charitative organization so donations to me are not tax deductible, unfortunately.

 

Cool. Installed Plus 1.0.3 to box Firefox and likewise back to 0% when system is idle. Nice.

 

good news everyone, after inspecting the wow64win.dll I could device a simple enough parser that based on the sys call numbers found in win32u.dll allows to find the unreported function entry points and allow to use win32k hooks with 32 bit applications under wow64

 

Did a clean install and everything works good!

Sandboxie Classic 5.55.3 (64 bit)
Windows 10 (64 bit)

Programs sandboxed:
Firefox 95.0 (64 bit)
Thunderbird 91.4.0 (64 bit)
Microsoft Edge 96.0.1054.53 (64 bit)

 

Clever cookie! That's great news. Really pleased with how well 1.0.3 is running on this machine. The UI is looking awesome and is really user-friendly. Took just a few mins to add in all my old Sandboxes for my different apps using the "duplicate sandbox" feature.

 

The button just takes me to the PayPal homepage and no option to make payment. I'm not looking for a tax deduction, just want to contribute. I may be missing something, but I have kept trying over a number of months. and I was able to make a donation using PayPal from a link for a browser extension yesterday, so its not an issue with my PayPal account.