application virtualization - how is it done?

Started by
11 comments, last by cameyo 13 years, 2 months ago
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?
Advertisement
It can be done a number of ways. One way is through emulation, where either each instruction is interpreted or translated into X86 code with augmentation that traps memory and privileged operations, passing them on to a handler function.

It's been years since I've looked at how X86 protected mode works but I think tasks on modern operating systems are each assigned their own page tables, with only the pages they are allowed to access marked as usable. Illegal accesses will cause an exception. Presumably, there is some access to this level of control within the Windows API, at the system-level, and I imagine that virtualization software uses this. They probably create a task in which the pages normally containing system (Windows) API hooks are marked as restricted, allowing them to trap any such operation (as well as any privileged operations).
----Bart
The old method, probably do it the same way hackers did it to run the root kits outside of the OS.. it patches all the calls to the OS and runs the OS in a sandbox while it runs at a higher privilege level. There are virtualization instruction sets now supported at the CPU level which allows a host program to run a slave program within a sandbox at the hardware instruction level.. It's much faster than the old methods and all the new virtulazation software supports it.. That's what the Cloud is built upon.. virtualized software running in a sandbox at the hardware level.. They write emulated device drivers which limit access to the real hardware and pipe it to a realtime compressor which then streams it too u, ie Onlive and Gankai ..

see :

http://en.wikipedia.org/wiki/X86_virtualization

-ddn

it patches all the calls to the OS and runs the OS in a sandbox while it runs at a higher privilege level.

When you have a program running that you have downloaded/streamed (or whatever) from spoon.net there is a process running that is called something like spoon-sandbox or something like that. So that would be their fake version of Windows? -- wouldn't that process then have to be gigantic?

I don't know maybe I'm naive but all these low-level rootkit-like explanations seem a little heavy-weight for this website that is deploying stuff via a firefox plugin to be using...
Think of it more like their Wrapper for the app. It isn't a fake windows but acts more like a firewall between windows system calls and the application. It keeps "changes" made to the system within its own Wrapper application and returns those values whenever requested be the child application. It's more like a firewall between an application and Files/Registry than a "fake windows".
I was describing the method people used 5 years ago, that method is hopelessly out of date with the advent of the virtualized instruction set supported by hardware. Now its all done in a cloud configuration remotely and streamed too you.. Spoon.net likely has instances running on a cloud then using proprietary graphics drivers intercept and encode the low level UI command and send then to their clients aka like Remote Desktop. This is a cheaper solution than what Onlive and Gankai does which is fast hardware accelerated encoding turning it all into a video stream.. Maybe they do run a process on your side but i doubt it, its probably just nothing more than a thin client to decode GUI commands..

-ddn
Ah, you are right. It's probably a similar process in which applications get distributed via Citrix Metaframe. The applications run server side on a Windows Server box, but the client has a video interpretation of the application on their local machine. Each application user has their own application state stored on the server. It's like remote desktop, except without the desktop. The application windows are remotely projected to the client.

Edit: Also, originally I was envisioning Application Virtualization like VMWare ThinApp. This basically encapsulates an application installation into a single .exe. The .exe runs in a sandboxed state on any machine, but allows you to do things like running IE6, IE7, IE8 and IE9 concurrently (or at least this is how it was demonstrated to me during the training sessions). This runs more like the Sandboxed client I was referring to in the earlier post, acting as a firewall between the app and the system.

Spoon.net likely has instances running on a cloud then using proprietary graphics drivers intercept and encode the low level UI command and send then to their clients aka like Remote Desktop.


the client has a video interpretation of the application on their local machine. Each application user has their own application state stored on the server. It's like remote desktop, except without the desktop. The application windows are remotely projected to the client.


I'm pretty sure that this is not what they are doing because (1) There's no latency, (2) I haven't tested this but I get the feeling you could run the spoon.net virtualized apps without a live internet connection, and (3) 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.

It seems to me that they are running actual Win32 exe's on the client that are altered such that when a system call occurs that would interact with or modify some global OS asset it somehow gets diverted to only modify the sandbox. I think that the only thing the browser plugin is doing is serving as basically a download manager for the apps and that this is basically a re-packaging of the xenocode virtualization stuff that they released a few years ago -- they're just re-branding themselves to look all Web-2.0-ish.
In which case I would go back to my Firewall description. It is basically working to interpret system calls but replacing "changes" to the system with a changes to a table within the firewall/virtualization app. Basically it is a buffer between the OS and the sandboxed app. This way the Virtualization client basically lets calls to create windows go through the standard System DLLs and any changes to registry or file system go to an app specific table in the Virtualization Client. This way it does not need to reimplement Windows, but only stop changes being made to the existing system. Having not implemented something like this myself I can't say exactly how it works, but it sounds very much like VMWare ThinApp or a Sandboxie type setup.
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..

Here is their docs link

http://spoon.net/Studio/Spoon-Studio-User-Guide.pdf

The claim hardware virtulziation is slower that their method, that hasn't been my experience between the 2 methods, when they can show modern DX games running near full framerate in their VM i'll be impressed :)



-ddn

This topic is closed to new replies.

Advertisement