ThinappHelper – A Thinapp Utility For The Rest Of Us …

In a previous post I talked about the different Thinapp isolation modes and how these could be manually adjusted with a text editor. This is not a very user friendly process and so today I am going to take a look at ThinappHelper which provides a GUI for configuring Thinapp projects.

ThinappHelper is available from here: http://thinapphelper.cis-group.nl/en/download.php and requires that you have the .NET Framework installed (version 2 or higher). As Windows 7 comes with .NET version 3.5 I did not have to worry about this.

ThinappHelper runs from a single executable so we don’t need to install it.

Once we double-click ThinappHelper.exe the first thing that we should do is configure a backup location – just make sure that you have plenty of space if you are working on large Thinapp projects.

Note that some changes made with ThinappHelper will be performed immediatley (such as creating or deleting files and folders) so a backup is important!

Click Edit, Settings and then the Backup tab to define a backup location.

So now let’s take a quick look at the basics of the ThinappHelper GUI.

In the Settings tab we can see various options from the package.ini file which contains the build and other general options.

Some fields are just text fields while others are drop down menus containing the options available for a given parameter. Making simple changes then can be very quick – such as changing the Compression Type, or the Directory or Registry Isolation Modes.

The Executables tab shows the executables that will be created when the project is built. Here you can see that I have the main Firefox exectable and the Safe Mode executable for Firefox selected. The cmd.exe, regedit.exe and iexplore.exe executables are all entry points that can be used for debugging virtual applications.

In the Folders tab we can see the entire folder structre that Thinapp captured (in this instance for Firefox).  The GUI colour codes the folders per their isolation mode, which is very useful:

Green: Full Isolation
Yellow: WriteCopy
Red: Merged

Even though the isolation modes can only be changed one item at a time this is still a much nicer way to do it that by manually editing the files directly!

In the Registry tab everything is colour coded again per isolation mode. The ThinappHelper release notes do contain some caveats though regarding the use of special characters:

Any non-printable character -or reserved character (‘# ’, ‘~’ and ‘%’)- has to be escaped by replacing the character with a ‘# ’, followed by its hex-value. For example the ‘# ’ becomes ‘# 23’ and the ‘null’ is represented as ‘# 00’.
Unicode characters are escaped with ‘~’ and its 16-bit hex value (‘# ’ = ‘~0023’).
Strings (normal string and expandable) have to be terminated with a null-character (# 00). Strings-multi must have an additional empty string at the end (just add an additional # 00).
- String (normal/expandable): ‘This is a normal or expandable string#00’
- String Multi: ‘First string#00String # 23 2 (=number 2, dash escaped)#00Last string#00#00’

All -in-all ThinappHelper is a great tool for working with Thinapp projects and makes alot of things much much easier!

Many thanks to the CIS-Group for making their application available to the public!

 

VMware Thinapp – Isolation Modes Explained

In VMware Thinapp the different isolation modes govern how much access a virtual application has to the physical host OS. With Merged isolation mode our virtual application can save files to the physical host OS just like any other application. With WriteCopy isolation we are restricted to the Desktop and My Documents folders. Full isolation has no access to the physical environment at all.

But how does Thinapp handle run-time changes to the application itself?

Before we get in to the subtleties in behavior between these modes it is important to be clear about the areas impacted by run-time changes in a virtualized application.

First we have the virtualized environment itself which consists of the file system and registry settings that Thinapp captured during the application install.

Next we have the application sandbox (which is typically stored in the User profile). The sandbox is a user specific extension of the virtualized environment.

Finally we have the physical host OS itself.

Note that the following discussion assumes that the virtual application has the appropriate permissions to modify the physical host OS, which of course it might not have in real life.

Let’s look at how the different isolation modes affect access to the physical host OS:

Isolation Mode: Access To The Physical Host OS

Isolation Mode	Read	Modify
Merged	Yes	Yes
WriteCopy	Yes	No
Full	No	No

Note that read access is limited by the structure of the virtual environment. If, for example, the same file or registry key exists in both the physical and virtual environments then the virtual application will only be able to see the virtual file (or registry key).

Here we can also see that the Merged isolation mode is the only mode that allows the virtual environment to modify the physical environment. We will find though that Merged isolation is limited in terms of what it can modify on the physical host OS.

Merged Isolation Mode: Run-time Modifications

Isolation Mode	File or setting already exists in physical environment?	File or setting already exists in virtual environment?	Modification Destination
Merged	N	N	Physical
Merged	Y	N	Virtual
Merged		Y	Sandbox

With Merged isolation then we can see that run-time modifications will be made to the physical host OS only if those modifications do not already exist in either the virtual or physical environments.

If the run-time modification does exist in the physical host OS (but not the virtual environment) then it will take effect within the virtual environment. As noted earlier this means that a conflict arises between the physical and virtual environments whereby the virtual application can no longer see the conflicting element(s) that exist in the physical environment.

Finally, any modification that already exists within the virtual environment will be sent to the sandbox.

Now let’s take a look at the WriteCopy isolation mode.

WriteCopy Isolation Mode: Run-time Modifications

Isolation Mode	File or setting already exists in physical environment?	File or setting already exists in virtual environment?	Modification Destination
WriteCopy	N	N	Sandbox
WriteCopy	Y	N	Virtual
WriteCopy		Y	Sandbox

WriteCopy behaves very much like the Merged isolation mode. The difference is that when the virtual environment tries to “modify” the physical environment these changes are sent to the sandbox.

Otherwise the WriteCopy and Merged isolation modes function in the same way.

This just leaves us with Full isolation, and this is the simplest mode to discuss.

Full Isolation Mode: Run-time Modifications

Isolation Mode	File or setting already exists in physical environment?	File or setting already exists in virtual environment?	Modification Destination
Full	N/A	N	Sandbox
Full	N/A	Y	Sandbox

As we can see all run-time modifications are directed to the sandbox. Full isolation mode cannot read the physical environment at all.

If we take a closer look at the virtualized files and registry keys of a Thinapp project we will find settings for each of the isolation modes on a per folder and per registry key basis.

Each directory, for example, contains an ##Attributes.ini file that tells the application what the isolation mode is for that given folder:

[Isolation]
DirectoryIsolationMode=WriteCopy

Isolation modes for the registry are handled on a per key basis as the following extract from my Firefox 3.6.3 HKEY_CURRENT_USER.txt shows:

isolation_writecopy HKEY_CURRENT_USER\Software\Classes\Local Settings\
Software\Microsoft\Windows\Shell\BagMRU\1\1
Value=MRUListEx
REG_BINARY=#00#00#00#00#ff#ff#ff#ff
Value=0

This flexibility means that if we need to we can manually adjust the isolation modes for any directory or registry key as we see fit, before we build the application for deployment. We are not locked in to the modes that Thinapp initially assigns to the project.

The current version of Thinapp, version 4.5 supports Windows 7 and a 60 day trial is available from VMware: http://www.vmware.com/products/thinapp/.

Source: Thinapp Blog.

Related Posts: ThinappHelper – A Thinapp Utility For The Rest Of Us …

 

VMware Thinapp – An Introduction To Application Virtualization

VMware Thinapp is a suite of components that work together to virtualize applications. In basic terms Thinapp abstracts the file system and registry of a given application into a single executable file – decoupling it from the host Operating System (OS).

The Thinapp 'Suite' of Applications

This independence from the host OS has many benefits and a few drawbacks (depending on how you look at things).

Obviously isolating applications from the OS has security benefits, especially when something like a virus or malware is confined to a sandbox. The fact that applications can be configured before deployment is another great benefit from a standard installation. Probably the greatest benefit of application virtualization is conflict free application delivery. Need to run multiple applications with different versions of Java Runtime Environment? Not a problem!

The downside is that there are simply applications that Thinapp cannot virtualize – examples include Antivirus software, firewalls and device drivers. Other applications with shell integration might suffer from reduced functionality, for example an application that integrates its own menus into Windows Explorer. This is not an exhaustive list by any means so consult the Thinapp User Guide if you need more clarification.

Thinapp has a wizard driven interface that belies the potential complexity that you might encounter virtualizing something like Office 2007. Best practise is to run Thinapp on a “clean” virtual machine – which basically means a virtual machine with just the OS. You can install Thinapp on your virtual machine or run it from an available file share. I would recommend using VMware Workstation or vSphere for hosting the clean virtual machine as these products support multiple snapshots (which means that you will be able to revert your virtual machine to its original state to virtualize another application).

So how does Thinapp work? Well, Thinapp first performs a prescan of the clean virtual machine. Then you install your chosen application. Thinapp will then perform a postscan which identifies the changes made to the prescan baseline. After this you configure various settings and (optionally) build your virtual application.

Showing you each step of the process through the Thinapp wizard would be a little tedious so I am going to show you the most important screenshots with a brief discussion of each. At this point in the Thinapp wizard I have completed the prescan, installed Firefox and completed the postscan.

Application entry points are basically the executables that you want to be available in your virtualized application. So for Firefox we would obviously need Firefox.exe and probably want the safe mode executable too. The entry points for debugging will give you shortcuts to a command prompt, regedit and Internet Explorer that can all be used to debug your virtual application.

Entry Points

Isolation modes effect how much access the virtual application has to the host OS file system. As you can see the WriteCopy isolation mode is the most tightly sandboxed mode having access to only the Desktop and My Documents folders on the host.

Isolation Modes

After this you choose where the virtual application’s sandbox will exist (but that is not very exciting) so we’ll move on to package settings. Here we select the primary entry point – essentially this is the main executable that Thinapp will produce. If the application is large it will be split between this executable and a separate .dat file. For Firefox we would want the primary entry point to be Firefox.exe or Mozilla Firefox.exe. The next option is to produce an .msi package – this is an installer for your virtualized application that will register file associations and shortcuts to the application. You will want to compress the final build of your Thinapp applications.

Package Settings

The final screen in the wizard is the Ready to Build screen. Here we can access the project folder that contains the virtualized file system and registry of our target application. We can also configure more advanced Thinapp options if we need to in the package.ini file.

Ready to build

This is what the project folder for Firefox 3.6.3 looks like:

As you can clearly see there is a virtual file system that includes (amongst other things) a Program Files directory – and a virtual registry that includes windows registry hives in plain text (.txt) form.

Conceptually we end up with something like this once we have built our Thinapp application:

Inside a Thinapp package is a small Virtual Operating System (VOS) that is roughly 400k on disk and about 2Mb in RAM. Thinapp virtualizes the registry and file system of the target application and links it to the VOS within a single compressed .exe file.

Well that’s it for my introduction to Thinapp – for reference I used Thinapp 4.5, Windows 7 and vSphere.

The current version of Thinapp, version 4.5 supports Windows 7 and a 60 day trial is available from VMware: http://www.vmware.com/products/thinapp/.