Status
Not open for further replies.

Deletedmessiah

Level 23
Verified
Content Creator
Can you test those software which needs restart to finish installations in Windows sandbox? I still use 1809 so I can't use it.
ReHIPS is a good alternative. You can't isolate browsers in free version but I think thats overkill anyway. It should isolate other software well which can be exploited. But keep it mind, its very confusing software for non experts at 1st. The most confusing out of all default deny and isolation software I used.
 
When Windows Sandbox was enabled, I couldn't start a VirtualBox VM (e.g., Linux Mint, Windows 10, etc.). I kept getting the same error.
You do not have to use VirtualBox when you have access to Hyper-V, which is enterprise-grade VM software. It is backed by the same CPU technology that VirtualBox will use.

So...why you first post sounds like unfair advertisment of MS solution and anti-advertisment for 3-party competitors?
On the matter of unfair, why should developers keep changing things to make Sandboxie convenient? No one forced Sandboxie to use the design they are using and the documentation for Intel VT-x and AMD SVM technologies are public and openly available, so no one is preventing Sandboxie from doing what needs to be done in order for it to use a viable future-proof design.

I do not care if it sounds like an unfair advertisement - I am not telling you to buy anything, I am not spreading lies about Sandboxie and I am not forcing you to interact with this topic.

ReHIPS does not use any rootkit-technologies (no kernel-mode hooking).(y)
It used to do some light user-mode hooking (and it might still do) but it's on no level remotely close to Sandboxie in terms of danger and what they used to be doing (and might still do) was reasonable when I looked at it. Therefore, it should be fine. It might tarnish code integrity a little bit, but it won't do it as destructive as Sandboxie.

Most of ReHIPS evolves around built-in Windows features which is why it is superior to Sandboxie and much safer. It doesn't go to the extreme with undocumented. In fact, it doesn't even go half the way that Sandboxie goes with it.
 

Freki123

Level 8
Verified
According to a new report, Windows 10 version 1903 is only installed on 6.3 percent of Windows 10 PCs out in the world.

Edit: For the sandboxie paid (if they sell it again) vs rehips paid debate: Rehips is more than twice the price. About 59.20$ for rehips vs 20.95$ for sandboxie (at least in my European country).
 
Last edited:

Andy Ful

Level 62
Verified
Trusted
Content Creator
I thought that we talk about Sandboxie, and not about judging how wise or how stupid are its users. Furthermore, you are an engineer so your diagnosis about the mental health of anyone is pure speculation. Should we start to think that your other opinions are also unsupported speculations?:unsure:
Anyway, that was not you who recommended deferring Windows Updates (for a month) when using Sandboxie. So, Bo Elam was wrong.
I installed a few years ago Sandboxie on my wife's computer with Windows 10 (no deferred updates). The system updates flawlessly and there was only one problem with Sandboxie about two months ago. The problem was solved after a month with a new Sandboxie version.
 
Last edited:
I thought that we talk about Sandboxie, and not about judging how wise or how stupid are its users. Furthermore, you are an engineer so your diagnosis about the mental health of anyone is pure speculation. Should we start to think that your other opinions are also unsupported speculations?:unsure:
I have several qualifications for the health care industry: first-aid, pharmaceutical and psychology. I spent 5 years studying hard to acquire them abroad and later went abroad to the UK to do a series of exams which gave me a license that can be used in many locations world-wide (as opposed to being restricted to my home country).

I am an electrical engineer but I did an extended diploma course which was specifically about software, web technologies and game development. The extended diploma was only two years. All of this was several years ago.

I also have a law degree (not University level) and a college-level qualification in Construction and Media. Among a few other things due to work experience across different industrial jobs which included free training as a new employee. Where I was living for a long time in my home country, there was not much work and people were being made redundant, so I had to get any work I could find and this consistently switched around... usually, it had nothing to do with computers.

That's all I am going to disclose to you about myself. You are free to believe me, disbelieve me or have any opinion of me which you like. In your eyes, I could be a total moron. It really doesn't matter.
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
I have several qualifications for the health care industry: first-aid, pharmaceutical and psychology.
...
Believe me, your teachers and EFPA would not be contented with giving a mental diagnosis on MT forum. Maybe, you should refresh some qualifications, especially in ethics?
I like those parts of your posts when you are focused on well-documented facts and do not force opinions. The first post in this thread about Sandboxie is a good example. Your post about Bo Elam was unnecessary and overactive. Maybe you had a bad day, who knows.:unsure:

But, let's go back to the topic. Some people on some hardware/software configurations can use Sandboxie without problems. There is no need for them to use something else. From the fact that new cars have better technology, it does not follow that using old cars is stupid.
That is not common If a person uses Sandboxie all the time for most activities, but there is also nothing wrong with it. You do not have to hate Himalayan mountaineer if you are a sailor.(y)
 
Last edited:

upnorth

Moderator
Verified
Staff member
Malware Hunter
mental diagnosis on MT forum.
This! Everyone and anyone has the full right to express there opinion ( within the rules ) and I have zero issues with that but, I find it pretty sad when I read things that points to peoples health and especially if it's clearly done in a deliberate negative manner and yes I know I can ignore it or go somewhere else. I'm more then adult enough to use my brain thanks! It's not just one member on this forum that thinks and believe it's actually funny and have this constant poor tendency do it without thinking twice, and instead try behave a bit more normal friendly and helpful. What if people would behave like jerks against your family, loved ones and friends off-line? Probably not pretty funny and just because things are online, everything ain't automatic ok and acceptable. Personal I try my best not offend, or be harsh and rude against others both online and offline. I'm 100% aware of the report option but this just has to be said, even if it's off-topic but then again, in the General Security Discussions forum/section things is pretty common " off-topic ". I think the word " General " should be a hint good enough.

With that said, this topic/thread is great, IMO. (y):emoji_beer:
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
Veloce,
Writing one overreactive post does not mean that you are not welcome here. You have knowledge that can help MT readers. For example, I would like to know more about how Sandboxie changed after introducing Windows 10 to avoid PatchGuard. I could not find anything interesting about it, maybe you know something useful.:unsure:
Sandboxie still uses SbieDrv.sys kernel-mode driver, which in the old article from the year 2011 was responsible for hooking in the kernel. Many applications use mini-filter drivers instead of SSDT hooking.
I used Windows Kernel Explorer (AxtMueller/Windows-Kernel-Explorer) and it seems that SbieDrv.sys is a mini-filter driver. It is also detected under the MSR/EAT/IAT/Code Hook scan.
 
Last edited:
What I love about Sandboxie is:
  • I can try new software (legitimate software by the way) without making changes to the system folder/app folder/registry.
  • I can do so without firing a full-blown VM.
  • Since it's not a full-blown VM, it means all my PC resources are available to the programs.
  • I can get rid of any programs completely by removing the sandbox.
  • In a way, the above points mean that you can make a lot of programs behave like portables programs and you can even detect ill-behaving portable programs that like to save settings in the Users folder.
  • I can have different sandboxes.
  • This means I can keep sandboxes for software I use infrequently.
  • I keep my PC without unwanted services installed on it.
  • I keep my PC without unwanted "upgrades/downgrades". For example, I have all of the Visual C++ Redistributables installed and up to date and I don't need/want games installing their version.
  • If it can't be installed and running smoothly in Sandboxie it usually means the program likes to really hook into the system and then I have to think twice about installing that said software. And yes, I know Sandboxie hooks nastily into the system, but I rather have just one software doing it than many.
Sadly there are no replacements for all this in another neatly-packed software. Also sad that performance has been getting worse: a couple of years ago I could run Adobe programs inside Sandboxie without much performance penalty, now the same versions don't work as smoothly so I have to deal with Adobe nasty services running amok.
 
Last edited:

Andy Ful

Level 62
Verified
Trusted
Content Creator
...
And yes, I know Sandboxie hooks nastily into the system,
...
That is what many people say. I am just curious, what can be the source of such an opinion?
I have read an article about Sandboxie from the year 2011 which includes information about Sandboxie's hooking in the kernel:
"Sandboxie is a sandbox that performs a process isolation. Its main features:
-Access control to kernel resources by direct hooks on kernel objects.
-Some ssdt and shadow ssdt hooks to control window messages.
-Some kernel registered callbacks to be notified of process creating, images loaded, … "
But, in Windows 10 64-bit the hooking in the kernel is well protected by the PatchGuard, so the vendors avoid this by using other well-documented techniques, like for example mini-filter drivers. So, it seems that actually the dirty " ssdt and shadow ssdt hooks to control window messages." are not used in Sandboxie, but "Some kernel registered callbacks to be notified of process creating, images loaded, … " are probably still used.
I am not sure about "direct hooks on kernel objects".
Anyway, is the widely accepted opinion about using by Sandboxie the rootkit methods really true in the year 2019?:unsure:
 
Last edited:
But, in Windows 10 64-bit the hooking in the kernel is well protected by the PatchGuard, so the vendors avoid this by using other well-documented techniques, like for example mini-filter drivers.
Mini-filter device drivers interact with the Filter Manager - fltMgr.sys. They allow you to filter file system events because the Filter Manager will invoke registered callback routines at the appropriate time. When registering with the Filter Manager, you provide registration information which specifies which file system events you want to intercept - specified through an IRP Major Function code - and whether you want to intercept the event for Pre and/or Post operations.

The Windows kernel officially supports filtering of process creation and termination requests, registry requests and object manager requests. All of these can be done from a driver using the normal kernel-mode driver framework model, so a file system mini-filter isn't mandatory for anything other than file system filtering. Commonly, people tend to use a file system mini-filter driver and include everything into it, because it's usually convenient for management to have all of the filtering in one place... and when recorded information needs to be referenced by code belonging to filtering of something else in the future, it's simpler if everything is under one driver because it prevents the need for additional overhead by implementing communication channels between multiple drivers.

PatchGuard does not prevent patching of the Windows kernel. PatchGuard cannot stop you from doing it. PatchGuard is running at the same privilege level as the culprit it wants to stop, which already means it is game over. Anything PatchGuard can do, someone with the same privilege level can undo. Microsoft already knew this and it is why PatchGuard mainly survived on obfuscation to try and thwart reverse engineers from reverse engineering it and then defeating it... and as they likely would have expected, it didn't work, because it was closely examined and then documented by third-party reverse engineers and security researchers... and subsequently bypassed.

PatchGuard is a code integrity feature targeting the Windows kernel. It doesn't stop anything. It detects things which it is programmed to detect using various algorithms and when it detects something it doesn't like, it forces a BSOD. The BSOD will be carried out by the KeBugCheckEx kernel routine, which was actually hooked once upon a time to block the forced BSOD and act as a PatchGuard bypass.

"Some kernel registered callbacks to be notified of process creating, images loaded, … " are probably still used.
Sandboxie still does this but that isn't the unsafe part about it. In fact, that is the good part about it. It's a good thing that Sandboxie does this over alternative routes because it is a documented and officially supported thing to do.

I am not sure about "direct hooks on kernel objects".
Technically, they can still do this, but it depends on what they are doing with the kernel objects - PatchGuard can detect DKOM but not every use of it. It's a technique called Direct Kernel Object Manipulation (DKOM) and it works by modifying kernel objects - it's a rootkit-like technique from the early-on rootkit books and was commonly abused to hide processes, registry keys and files.

Anyway, is the widely accepted opinion about using by Sandboxie the rootkit methods really true in the year 2019?
Yes, because it isn't just about the Windows kernel.

My main issue with Sandboxie is:
a). It messes with the memory of other people's processes. We're not talking about one or two chances. We're talking of non-stop extreme manipulation.
b). Everything happens on the real host environment.

Sometimes, you have no viable alternate to API hooking. API hooking is fine when it is done by people who know what they are doing in a responsible manner. Sandboxie have no choice other than to do what they are doing unless they use the design model of ReHIPS (which doesn't have to hook as much) or Microsoft's sandbox technology (which is powered by work of Intel and AMD). However, due to Sandboxie's chosen design, they get carried away with the hooking and end up causing more harm than good.

If you use Sandboxie to isolate your web browser then you've tarnished several important layers of defense for anti-exploit on your web browser, for example. Realistically, those anti-exploit features you've just tarnished are more important than Sandboxie in the real world, and they genuinely get on the nerves of threat actors. There's a good reason that the level of browser escapes have plummeted over the last decade - secure guidelines being followed, safer client-side scripting run-times and exploit mitigations like ASLR, DEP, Control Flow Guard, blocking of Win32k system calls, etc.

You cannot properly defend against a culrpit which is running at the same privilege level as you. Sandboxie's design is security through obscurity for a large portion of it nowadays.

But, in Windows 10 64-bit the hooking in the kernel is well protected by the PatchGuard
If you're wondering about some other AV vendors as well... some of them evade PatchGuard by doing what Microsoft is doing but differently.

For AMD:
1. Use the CPUID instruction from the IA-32 (AMD64 has backwards compatibility, Intel and AMD made a deal when AMD invented AMD64 which allows AMD to support IA-32 and Intel to use AMD64) instruction set with the code 0x80000001 and then check the ECX register.
2. Use the Virtual Machine Control Register MSR to check whether the SVMDIS bit is clear - if it is set, then AMD SVM is disabled.
3. You can do an extended check depending on #1 and #2 to see if AMD SVM is unlockable via the BIOS or if it requires an administrator key to remove the disable.
4. Use the Extended Feature Enable Register to set the SVME bit on every processor which is going to be included for virtualization.
5. Setup the Virtual Machine Control Block (VMCB) for the host and guest state.
6. Use the VMRUN instruction from the AMD64 instruction set to enter the guest environment and when an exception occurs for the host to become involved again, a #VMEXIT will occur.

That is roughly all you have to do.

Reference:
https://www.amd.com/system/files/TechDocs/24593.pdf (See Chapter 15).

#VMEXIT can cause a lot of system overhead when it is happening a lot so a better design would be implementing Nested Page Tables (NPT) (also referred to as Rapid Virtualization Indexing) which is Second Level Address Translation. Intel have Extended Page Tables (EPT) as their Second Level Address Translation feature.

Anyway, the guest state will mimic the host state, meaning when you enter the guest environment... it's the same as the host environment. The difference is that you're in full control of the guest environment which is based on the host environment. With this design model, you can push the end user into a virtual environment which will appear and behave the same as the host environment to them, and they won't even be aware unless you notify them (or unless they are technical enough and paranoid enough to be running tests, which can also be subverted). It's a simultaneous transition.

You don't have to mimic the host environment, but this is the model that sandbox systems from vendors like Comodo use as well. This is why Comodo can patch the Windows kernel on x64 systems. Kaspersky uses the hyper-visor for some things as well, probably for banking protection.

Microsoft's technology works a bit differently. Hyper-V doesn't mimic the host environment. It sets up a guest environment with it's own resources as well. VMware works like Hyper-V in the sense that it doesn't mimic the host environment either - it uses its own OS media source and reserves host resources for the guest based on the configuration. Same for VirtualBox but VirtualBox also supports a compatibility software-level emulation mode for those who do not have supported hardware to use the virtualization features which will use Ring 1 to host the guest OS kernel (since on Windows at least, Ring 1 is unused and thus available).

Hyper-visors aren't bullet-proof either though. Nothing is 100%.

For example, VMware's backdoor channel can be exploited to leak host information (e.g. the clipboard of the host) if the guest kernel is subverted and also from user-mode of Guest Additions is installed. But, it's all still better than Sandboxie.
 
Last edited:

foray

New Member
Sandboxie should be avoided in 2019 and above.

1. Sandboxie messes with the memory of processes belonging to other people's software.

First of all, messing with memory of other people's software can introduce additional vulnerabilities in other people's software. There's people out there who have a good track record with finding (and exploiting) vulnerabilities which are introduced by security software injecting code for one reason or another.

Second of all, messing with the memory of other people's software will tarnish code integrity defenses. Code integrity is there to validate that code is as it should be and hasn't been modified, but thanks to Sandboxie, those features can go flying out the window. You can trust Sandboxie to hook away at its own discretion, destroying effective use of code integrity to ensure that no one who shouldn't be messing with things in certain areas.

Third of all, messing with the memory of other people's software... breaks other people's software. Developers have enough on their plate without having to clean up Sandboxie's mess. People report compatibility issues even though it isn't the developers fault, but Sandboxie's fault. It's not acceptable given Sandboxie doesn't have to behave in the way it's behaving: there are modern model designs for sandbox systems which they are voluntarily deciding to ignore and not bother implementing.

2. Sandboxie has a lot of incompatibility problems.

Sandboxie is constantly forcing people to use beta versions for quicker compatibility patches, even though using a beta channel is not a good idea for security. General stability and security may differ when using a beta product compared to a release product. Beta products are in beta because they haven't been tested/vetted as much and are pending normal release until they can prove themselves to be stable and secure enough.

3. Sandboxie does not have a proper channel for reporting critical vulnerabilities.

There's someone on the forums asking for assistance in reporting a potential critical vulnerability. The claims are that the vulnerability, when exploited, can result in escalation of privileges. Of course, it took several days before an official employee could even reply to the thread.

Here's what some of the forum members over there have to say about Sandboxie.







Well, there we have it... two Sandboxie supporters themselves had some interesting things to say.

Windows 10 Professional (and above) users can switch to Microsoft Windows Sandbox - it works like a charm and doesn't have the above mentioned caveats - which is made by people who are willing to design a sandbox system that is robust and relatively secure. For anyone that is unaware, Windows 10's new sandbox feature is powered by Hyper-V (enterprise-grade virtual machine software).







Thanks for reading. You know what to do if you have Sandboxie installed right now (*hint* Control Panel -> Uninstall programs -> Sandboxie -> Uninstall *hint*).

Your opinion is spot on!:emoji_clap:
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
...
PatchGuard is a code integrity feature targeting the Windows kernel. It doesn't stop anything. It detects things which it is programmed to detect using various algorithms and when it detects something it doesn't like, it forces a BSOD. The BSOD will be carried out by the KeBugCheckEx kernel routine, which was actually hooked once upon a time to block the forced BSOD and act as a PatchGuard bypass.
...
The PatchGuard was bypassed several times. If I correctly recall, the KeBugCheckEx was used to bypass it by Turla malware (via hooking RtlCaptureContext function). But, PatchGuard code changes its position in the kernel mode with the new Windows updates, and this breaks already existent malware families. Also from time to time, Microsoft patches the known bypasses.
I read somewhere that KeBugCheckEx bypass does not work on the new releases of Windows 10 64-bit.

Anyway, it seems that we agree about SbieDrv.sys . Like other security software vendors, Sandboxie avoids hooking in the kernel. So, the nasty things are related to the user-mode hooking via SbieDll.dll .
I did not research Sandboxie's messing with the memory of other processes, but it seems that it is different from Excubits MemProtect.
 
I did not research Sandboxie's messing with the memory of other processes
It's the code injection (DLL injection for SbieDll.dll) and API hooking which I am referring to by "messing with the memory of other processes". It's the virtual memory of other people's processes which Sandboxie messes with.

but it seems that it is different from Excubits MemProtect.
Sandboxie does what Excubits's MemProtect does as well.

Excubits's MemProtect uses the ObRegisterCallbacks kernel-mode callback which is filtering with the object manager. When an object for a process (_EPROCESS - PsProcessType) or a thread (_ETHREAD - PsThreadType) is created or duplicated in the Windows kernel, a routine is called to invoke all the registered callbacks waiting for a Pre/Post operation notification. In the Pre operation callback, you can strip access rights you do not want to be granted to the caller getting a handle to the object.

When you create a handle to an object, the value returned is a pointer which is meaningless outside of the Windows kernel. However, when you use that handle with an NT API, the Windows kernel will look up the value in a table which will return a pointer to the kernel object that is being referenced with the handle. The Windows kernel keeps track of the references to the kernel objects and which user-mode processes have opened/duplicated a handle to a kernel object and with what access rights so it knows what to allow/disallow with the use of the handles.

In user-mode, when you use NtOpenProcess/NtOpenThread/NtDuplicateObject and the access rights being requested are stripped, the NT API returns STATUS_ACCESS_DENIED.

That is how Excubits's MemProtect works. Sandboxie uses the same kernel-mode callback to restrict programs under the sandbox containment from being able to open or duplicate a handle to processes/threads that aren't within the sandbox containment. So if you try to open a handle to notepad.exe outside of Sandboxie (if the program running in the sandbox can find out or guess the PID) then it will be blocked because Sandboxie will know which PIDs/TIDs are inside the sandbox and thus will deny if it isn't inside of it.

Unrelated to this discussion but interesting: there's an undocumented hack that can be used to filter handle creation / duplication for literally any kernel object as long as you know the enumeration type value representing that kernel object. PsProcessType and PsThreadType are defined in the Windows Driver Kit (WDK) header files. You can even do it for ALPC ports.
 
The PatchGuard was bypassed several times. If I correctly recall, the KeBugCheckEx was used to bypass it by Turla malware (via hooking RtlCaptureContext function). But, PatchGuard code changes its position in the kernel mode with the new Windows updates, and this breaks already existent malware families. Also from time to time, Microsoft patches the known bypasses.
I read somewhere that KeBugCheckEx bypass does not work on the new releases of Windows 10 64-bit.
It's been bypassed by overwriting the MBR and starting up before Windows as well. It can be bypassed by installing a UEFI bootkit (you'll need to be in the kernel overwrite EFI).

Another bypass was using vulnerable drivers like VirtualBox's old driver to target CI.dll (Code Integrity in the Windows kernel, loaded by ntoskrnl.exe at start-up).

Note, I'm referring to DSE with the above two points, a feature of PatchGuard. Earlier we were talking about KPP.

Either way, it doesn't matter what Microsoft patches, because you cannot protect against someone running with the same privilege level as you. Anything Microsoft does, it can be bypassed. If the host OS is compromised then it is game over. There's loads you can do without bypassing PatchGuard anyway.

There are documents written in Russian, Japanese and Chinese out there which go into technical depth of how PatchGuard works and how it can be defeated - outdated but still a good read.
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
It's the code injection (DLL injection for SbieDll.dll) and API hooking which I am referring to by "messing with the memory of other processes". It's the virtual memory of other people's processes which Sandboxie messes with.
These methods are pretty standard for security applications. What Sandboxie does to deserve the bad opinion?
...
Sandboxie does what Excubits's MemProtect does as well.
...
So, does MemProtect uses rootkit methods too?:unsure:
 
These methods are pretty standard for security applications. What Sandboxie does to deserve the bad opinion?
It does it excessively. Sandboxie chose to use a bad design. Third-party AVs use the same techniques all the time but usually it's only for a few APIs and they are improving for compatibility with modern exploit techniques, so things will get better.

Now that Google have been pressuring AVs to move away from injecting code into Google Chrome, they're starting to slowly back away from all of the web browsers and move to browser extensions or working with Microsoft to use the official mechanisms (that also rely on code injection using a COM In-Process server but it's with official integration with the browser vendors since they have to call the AMSI/IOfficeAntivirus APIs for it to work).

I've seen many third-party AVs make a right old mess. I currently have a stack of roughly seven unfixed vulnerability submissions dating back 2 years on a bug bounty system for a particular vendor, all because they were messing with the memory of other people's processes. I cannot disclose anything more because I had to sign contracts to participate.

Anyway, a third-party vendor who needs to just hook an API like NtQueueApcThread/NtQueueApcThreadEx do not need to go to the extreme overkill model of a Type 2 hypervisor. But, a sandbox system should be using a Type 2 hypervisor to create a proper guest environment that it has full control over from the host. That would be responsible. It's Sandboxie's design that limits it from becoming enterprise-grade and it wouldn't actually cost SOPHOS much given how much money they have to spare.

HitmanPro.Alert is another one. Talks the talk but cannot walk the walk. All that talk about defeating exploits but then got hit with two exploits via vulnerable IOCTLs - I wouldn't mind if it wasn't as pathetic as IOCTLs. It's just pathetic. And once again, it's SOPHOS.

So, does MemProtect uses rootkit methods too?:unsure:
It's not a rootkit method. It's an officially supported and documented mechanism which Microsoft introduced to reduce the need of hooking kernel APIs for process/thread handle creation or duplication.

Integrity checks need to be enabled on the kernel-mode software trying to use ObRegisterCallbacks but if it isn't, you can force it with DKOM on the _DRIVER_OBJECT structure (PatchGuard won't care). That's an example of another kernel patch you can do that PatchGuard won't do anything about, since we were talking about it earlier.

There is nothing wrong with Excubits's MemProtect but be aware it can be bypassed if the person doing the code injection spawns the process they want to inject into. Therefore, you can deploy a process hollowing attack regardless of Excubits's MemProtect. The Windows kernel provides a handle back to user-mode with the NtCreateProcess/Ex and NtCreateUserProcess system calls and you will be able to get PROCESS_VM_READ, PROCESS_VM_WRITE access rights assuming the process being created is at the same privilege level as the creator or the creator is already administrative rights. You can also inject code into other processes without needing a handle created/duplicated with sufficient access rights - DLL hijacking for example.
 
Last edited:
What Sandboxie does to deserve the bad opinion?
Third-party AVs aren't claiming to be sandboxing applications whilst just relying on user-mode API hooking - any that are should be avoided though. And for those that do offer a sandbox, it's almost always using hardware-based isolation nowadays. A design that is powered by technology designed and optimized for such use cases.

Comodo use a hypervisor implementation.

Kaspersky uses a hypervisor implementation.

Avast has a hypervisor implementation powered by VirtualBox.

Microsoft have a hypervisor implementation powered by their own Hyper-V.

ESET have code emulation powered by hardware-based isolation technologies.

QIhoo probably have a hypervisor implementation but I've never checked - after all, Qihoo developers are geniuses and know enough about virtualization to compromise VMware (they got paid big bounty money for that one). Let me know if you find any information on that.
 
Status
Not open for further replies.
Top