"It is basically working to interpret system calls"
Generally virtualisation works by using memory/IO protection structures. When an app, (possibly via its OS layer) tries to write to memory or IO it ought not to be allowed to, then there's an exception. Either to the OS (in the case of app virtualisation) or to the hypervisor if you're doing OS virtualisation.
This actually allows you to run unmodified systems. You can either pass through monitored access to the real hardware or provide "simulated" hardware. The former is more useful for performance (since you can give a guest direct access to something like a video card). The latter is more useful for cloud systems (since you can arrange for all hosts to provide the same emulated hardware regardless of their real physical config -- meaning you can migrate VMs around your hosts).
There is an option of "paravirtualisation". This is where the drivers know they're on a VM. Instead of prodding at memory or setting up DMA to do things, their code marshalls stuff up into neater packages and passes it in one go to the driver system. This is generally much more efficient.
XenDesktop/XenApp (I believe[1]) run paravirtualised graphics drivers which render the window contents to memory and then send the memory contents over the network. There are some options to end up with more of the app running locally but I don't know quite how that works (IIRC it relies on the client being Windows as well). Those virtualised systems live on top of XenServer. XenServer uses the Xen hypervisor to run the machine, and a privileged version of linux provides all the emulated hardware interfaces.
" if you examine the spoon.net virtualized apps with Spy++ you will see that they are composed of real win32 child windows, real win32 listviews and edit controls etc."
This would seem entirely reasonable in Windows client system -- the emulated win32 systems simply sanity check the inputs and then throw the request at the hosts win32.
[1] I have some contact with them, but I don't work directly with them.
application virtualization - how is it done?
I've read further on their tech on their dev site. It does what I've said but also allows you to run those virtualized bundled app locally as well (maybe that's what your running, however i would be weary of anything which downloads and runs arbitrary executables no matter how secure they think it is). They are using the same techniques all virtualziation software is using, use the virtualized instruction set, run the sandbox client program in a host program, hook the calls to low level devices and services to make the exe thinks its running on clean native windows install (they do this so they don't have to buy a license of windows for each instance?) etc.. with an added boost they decouple the UI from the executable core so its easy to do remote execution, ie their intranet /internet deploy schemes, upload to their cloud etc... All the calls to windows and runtime libraries can be hooked and overridden to make the app thinks its running inside windows but in reality its running inside a sandbox.. Probably analyze the exe and patch up the system calls to their on Spoon OS as they call it..
You can't analyze .exe files and expect to catch everything. It has to be done at run-time, which means it either uses virtualization instructions (but I thought these were not standardized between Intel and AMD and were unavailable on most desktop X86 machines), Windows device-level APIs that allow manipulation of the page table (I don't know if these exist), or, most likely, dynamic binary translation (because I think even the page table technique cannot trap everything that needs to be trapped -- namely certain instructions) which would allow them to analyze the code as it runs and trap everything.
Remember the Google plug-in that allowed X86 code to be used in web pages? I think this is basically the same idea.
I was fooling around with spoon.net today and am trying to figure out how they are doing what they are doing.
Reading some old discussions of their previous product xenocode virtualization -- which, I think, is what the newer spoon.net site is on top of -- it seems like they are running actual windows executables in a sand box but changing the runtime environment such that some call that is supposed to, say, modify the registry will just modify the sand box version of the registry, etc. What I don't understand is how this could be done. Are they hooking the win32 API or is there some more clever way?
Yes, the APIs are hooked indeed. In a very short description: resources required by the application (mostly files and registry keys) are redirected to and from a separate folder, provided by the virtual package.
Free app virtualization can be found on our website: www.cameyo.com
Regards
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
