AppDomain Wrapper Management

[ghost]

Some NET Framework programs use AppDomain wrappers (kind of like capsules for code execution) in which one executable image is a wrapper that manages real executable image with a different file name and/or different directory. Only the wrapper executable image shows up as in process managers as a running process. Real executable image does not show up as a running process, but it can be seen when viewing handles and threads for wrapper executable image.

How do I go about applying Sandboxie rules in such cases? Do I apply them to wrapper executable images or real executable images or both? Is there some generic method to unwrap such cases?

In some cases real executable images can be started without respective wrappers, but in other cases real executable images do not start without respective wrappers. There are also cases when the same wrapper can start and manage multiple images that share libraries, threads, handles, pipes, and yet run with different privileges.

[DavidXanatos]

Could you please provide a download for such an application such that we can investigate it.

[ghost]

https://learn.microsoft.com/en-us/dotnet/framework/app-domains/application-domains , which only sounds good if there aren't issues within application domains themselves. What if applications within applicaiton domain have different privileges, share many resources, create duplicate Named Pipes (race condition) that are shared between applicaitons within applicaiton domain + between applications outside of application domain?

Here's a good example of such case - https://downloads.nordcdn.com/apps/windows/NordVPN/beta/NordVPNInstall.exe

"C:\Program Files\NordVPApp.exe" is the actual program, but it can only be started with "NordVPN.exe" wrapper (if just double-clicking from explorer.exe). The "NordVPN.exe" wrapper can be launched with Sandboxie Default Yellow Box (and even more restrictive boxes) if the following line is added:
OpenFilePath=NordVPN.exe,\Device\NamedPipe\NordSec\NordVPN\NordVPN*

"C:\Program Files\NordVPN-Service-App.exe" is the actual program system service, but is normally started (and by default) with "NordVPN-Service.exe" wrapper. Neither the wrapper nor the actual program system service can be started with any Sandboxie type due to them needing WFP access, but that's expected for VPN software and system services.

"NordVPNApp.exe" and "NordVPN-Service-App.exe" do not show up as running processes in Process Explorer or System Informer when launched via respective wrappers ("NordVPN.exe" and "NordVPN-Service.exe"), but examining handles and threads lists "NordVPNApp.exe" and "NordVPN-Service-App.exe" in the same task managers.

Adding "DenyHostAccess=NordVPNApp.exe,y" (just to to experiment and see what happens) to "NordVPN.exe" sandbox prevents "NordVPN.exe" wrapper from starting, confirming that "NordVPN.exe" are dependent on each other, even though "NordVPNApp.exe" doesn't show up as a running process in task managers. "NordVPN.exe" also won't start if "ClosedFilePath=NordVPNApp.exe,\Device\NamedPipe\NordSec\NordVPN\NordVPN*" restriction is added to "NordVPN.exe" wrapper sandbox, which confirms that Named Pipes for "NordVPN.exe" and "NordVPNApp.exe" are dependent on each other.

As mentioned, "NordVPN.exe" wrapper can run sandboxed (when provided Named Pipe exception) and "NordVPN-Service.exe" wrapper cannot, which is normal behavior for services that need system-level control. I assume that means that Sandboxie can and does isolate applications within application domains, but do wrappers hinder effect of such isolation? Perhaps Sandboxie can perform "CreateInstanceAndUnwrap" function for such application domain wrappers?