I was reading that kpp (patchguard) was a big problem for Sandboxie. They were providing sandbox features on usermode level. Now, after 'experimental protection' it is providing full level of protection. So, my question is: How do they do that?
A forum for reverse engineering, OS internals and malware analysis
This subforum is about development. What have you done already before asking this question which is subject of answer through googling?
Ring0 - the source of inspiration
I forgot to add, I am looking for a way of extended access control, that is able to give me information for example about NtAllocateVirtualMemory calls. I want to monitor few things and I saw that sandboxie is doing aomething like this. So, my question is how. I am unable to find any callback called when a process allocates memory in another.
So? And what you have done already?
Ring0 - the source of inspiration
I've looked deeper and saw that Sandboxie is using documented ways to work alongside with PatchGuard.
They are hooking IRPs using Minifilter drivers and HDD access using Filesystem Filter Drivers. For registry, they are using Cm* APIs. Nothing unexpected. There is also a big amout of usermode hooks which transfer execution to SbieDll.dll.
I thought, they were bypassing patchguard, because of some posts related to patchguard bypassing to work with Sandboxie on their forums. That's good, I didn't know that there are a lot of filtering apis in nt kernel.
They are hooking IRPs using Minifilter drivers and HDD access using Filesystem Filter Drivers. For registry, they are using Cm* APIs. Nothing unexpected. There is also a big amout of usermode hooks which transfer execution to SbieDll.dll.
I thought, they were bypassing patchguard, because of some posts related to patchguard bypassing to work with Sandboxie on their forums. That's good, I didn't know that there are a lot of filtering apis in nt kernel.
tzuk were using shadow ssdt hooks in earlier experimental builds, but with windows 8 patch guard he was forced to switch to the running sandboxed process in untrusted IL with anonymous user token. SBIEDLL is a virtualization compatibility layer which makes sandbox transparent to the sandboxed application. For everything else he is using documented filters/callbacks. In the end Invincea killed this software.
Ring0 - the source of inspiration
EP_X0FF wrote:tzuk were using shadow ssdt hooks in earlier experimental builds, but with windows 8 patch guard he was forced to switch to the running sandboxed process in untrusted IL with anonymous user token. SBIEDLL is a virtualization compatibility layer which makes sandbox transparent to the sandboxed application. For everything else he is using documented filters/callbacks. In the end Invincea killed this software.100% agreeded.
When Ronen used to run the project, he fixed compatibility issues pretty fast. I do not remember any important issue (a Windows update breaking Sandboxie, a browser like IE, FireFox, Chrome not working, ...) being unsolved for more than a few days.
Since Invicea took over the project there are many bug reports unsolved, without any reply in the thread where user comments the issue. You can see users reporting problems with IE and Chrome pretty often. A shame.
Even more... in a movement I cant not explain, Invincea has Sandboxie´s main developer giving support in the forum instead having him working full time on the code.
Have you ever heard of any serious company having their main developers giving support at forum like simple support guys from India?
I think the key to all this mess was the switch from 3.x to 4.x. Version 3 was pretty stable and had been fine tuned very much. Version 4 introduced many, many problems. In fact, in order to solve many compatibility issues Ronen had to suggest the usage of "OpenWinClass=*" feature. The problem was the use of that thing was breaking Sandboxie and opening a security breach, so he was forced to tell that feature should be used only with trusted programs. That was not a real solution because the slogan of Sandboxie is "Trust No Program".
Ironic that the coder of a security program telling you to trust no program give as only solution to get programs running under Sandboxie to use a feature than could be used only with trusted programs. :lol:
I do not think it was coincidence Ronen sold Sandboxie to Invincea after he moved to 4.x. My guess is Ronen knew 4.x would be a pain in the ass to support.
IIRC even SBIE 3.x had issues on Windows XP x64 (no service packs - in my tests). This may have had something to do with WOW64's early foundation which was introduced in Windows XP 64-bit but I can't say for sure. I do agree that since the program was sold to Invincea it contains more bugs and user support isn't as solid as it used to be. I can live without SBIE however, it's not something I use daily. I'm also not a fan of software that needs to hook/redirect APIs in order to "sandbox" an application, but this is just my opinion. If I need to run something questionable I'll stick to using VM
Accept nothing less than STATUS_SUCCESS
Windows XP x64 was not supported by Sandboxie.
@Buster_BSA,
Maybe it was never "officially" supported but it can definitely run on Windows XP x64 given the right build, no hacks required. Using old VM snapshot with SBIE v3.01 x64. On newer setups it likely restricts installing on XP and only supports Vista or better. See below
SBIE_XP_64.PNG (431.61 KiB) Viewed 501 times
Best Regards,
Brock
Maybe it was never "officially" supported but it can definitely run on Windows XP x64 given the right build, no hacks required. Using old VM snapshot with SBIE v3.01 x64. On newer setups it likely restricts installing on XP and only supports Vista or better. See below
Brock
Accept nothing less than STATUS_SUCCESS