Two Slashes

Note:  As of August 18, 2008, LogMeIn has decided to offer all non-commercial users most of the benefits of their Premium tier service for free.  This decision includes the ability to run Hamachi as a service without my gaudy workaround, and as such all information below is no longer relevant and kept solely for historical purposes.  This method still works (should you choose to use it), but using the built-in option in Hamachi is the recommended course of action.

Note:  As of September 2009, LogMeIn has released a new version of Hamachi (Hamachi²) which runs as a service automatically regardless of any additional configuration.  Don’t try to use this workaround on the new version; it’s not intended for it and won’t benefit you at all.

Introduction
It’s plagued me for a while that the free version of Hamachi does not offer any form of service mode whatsoever, and that the licensing for the paid edition (and the service-mode support) is prohibitively expensive to a private user such as myself, when I rely on the service so much for some of my day-to-day activities. Of course, I understand that LogMeIn has employees and expenses to pay off at the end of the day, but I do think that something so simple, yet so essential in today’s world, should not require people to pay for.

By Hamachi’s design, the free version will only run when the user who installed it (or another with it in their Startup path) logs into the computer. Hamachi then starts and creates the tunnels based upon the user network/peer configuration. For some systems, where Windows has only one user with no password, and consequently automatically logs in, this isn’t too much of a hassle. But when more than one user or passwords come into play, even a simple restart of the computer renders the VPN useless until someone logs in and starts the application up all over again.

The paid version gets around this by running as a system service; that is, it starts up with the operating system and builds the connections then. In this way, you can access the system from anywhere, even if it’s just booted up. (There are a few catches to this, which I might get around to explaining in a moment, but just bear with me as these are few and far between.)

An Explanation
Since the free version of Hamachi obviously and blatantly disables the option to run as a service from within the Settings panel, we need some way to run Hamachi as a service, but without actually running the Hamachi executable itself as a service.

This is where applications called ‘service wrappers’ come in. These applications, which are written to intercept and handle the service control calls Windows passes to them periodically, “wrap” themselves around an application that would ordinarily run in userland. It is one of these wrappers that we shall use to escalate Hamachi to service level…without really paying to do so.

It took me a while to find a suitable and configurable wrapper for what I wanted to do. And seriously, I went through a good number of them. The one I ultimately settled on, however, was the NTWrapper Lite wrapper from DuoData, which not only seems to be working quite well for me, but the Lite version allows for non-commercial redistribution (and consequently, the permission for me to hand it on as part of my “hack” without forcing you to download more – or at least, I think it does).

Using The Hack
In an attempt to make this as easy to deploy as possible, I spent a few minutes and made a rather nice wrapper application myself that will install and configure the service for you, provided you’re logged in as an administrator when you run it (which the typical Windows XP user is because Limited accounts are next to useless…therefore if you’re unsure, you can go ahead and give it a try).

At the core, all my application does is “detect” the Hamachi user configuration data (by ultimately assuming Hamachi was installed and running as the same user running the tool, and using that Hamachi configuration as a base), configures an NTWrapper configuration file with that path, copies both to a system folder, and then installs the wrapper (and consequently, Hamachi) as a service. And of course, starts Hamachi for good measure.

If you decide that it isn’t for you, I wrote an ‘uninstallation’ routine which really just stops the service and offers to delete the files copied to your system directory when you installed it in the first place. Going through this process, however, is essential if you want to successfully and safely uninstall the actual Hamachi application.

For quick deployment, you can also use the /install and /uninstall command line parameters to quickly install or uninstall the hack from your system. This works well for instances where you push updates to other machines. Similarly, the service can be started or stopped using the net start/net stop command with HamachiServiceMode as a parameter.

Once you install the service, you can delete the installation tool if you want, as it is not required after the successful installation; however, mind that it is also needed to perform the uninstall, so keeping it around might be a good idea in case I cease to distribute the tool.

The Good
If you can get it to work, you’ll immediately notice that Hamachi is using the same configuration as the administrative user who ran my installation tool. This is partially because I figured it would be handy to ensure Hamachi was configured and working normally as a normal application before you bothered to proceed, and because I figured there might be an instance where it would be that much more useful to run Hamachi as a user application (with the service stopped).

When the service is started, Hamachi is issued a command line parameter (generated by the installation tool and saved to the configuration file) that causes it to read configuration from the installation tool user’s directory. If you were connected to any networks before, you’ll notice that you connect right back up to them, with the same system name, established networks, and other important things. This means that other network/Internet-facing services, such as VNC, are accessible to Hamachi peers without having to have a locally-logged-in user (again, a very useful thing indeed for a remotely accessed system).

The Bad
One of the biggest problems with running Hamachi in this way is that Hamachi ends up running as the SYSTEM user. This is a security flaw if there is a problem with Hamachi, as SYSTEM has even more access and control than the typical Administrator account, and is the highest level account on any Windows NT-based system. Any knowledgable security analyst will slap you in the face for allowing an application that wasn’t designed to be run as a service run with free reign on a system, but ultimately the choice lies with the user in how secure they want or can make their system.

Also remember that while running as SYSTEM, Hamachi could potentially cause stability problems because of the other core services and components it has access to. This, once again, is a potential problem that is outside the scope of my hack and left up to the user to consider.

On a different note, Hamachi will only actually successfully connect before login if you’re running on a wired network connection or have some way of configuring your wireless connection before logging in. This is because of the way Windows networking works, and there’s not really anything you can do about it. So don’t expect this to be a turnkey laptop-tracking solution, but it will work great for that wired desktop at home that you need to access a service from while the power’s flickering on and off (yes, exaggerated, but it helps to get the point across). My recommendation would be this: If you intend to install my hack, first consider whether the system will primarily or always be connected via a wired network connection. If your answer is no or maybe, stop right where you are because this isn’t the solution for you.

Also keep in mind that this hack only patches the limitation that Hamachi cannot be configured to run as a service; you still have all of the other limitations of the free version.

If part of your intention is for universal access to the machine you’re installing it on, regardless of other bumbling users (like parents or the general public) that might somehow manage to reconfigure the application, you might want to change the ‘run interactive’ option in the service’s options pane (see services.msc).

Expanding Horizon
One of my kvetches with the installer as I’ve written it at the moment is that it expects Hamachi to be installed in the default location. In the future, I would like to write some form of detection that would locate Hamachi on the system (either through the path of a running Hamachi process, or by scanning the contents of the system’s Program Files directory for something containing the Hamachi executable). Considering my normal level of work, however, this may be just a distant fantasy.

I’d also like to find some way to hook the Hamachi uninstaller (perhaps renaming it and replacing it with a dummy that warns you about the service) so that people don’t go screwing themselves over royally. If you’re using this hack, I wouldn’t expect you to be that stupid in the first place, but accidents do happen and people tend to forget things.

Non-Windows Users
And even though this hack is focused on the Windows family, I wouldn’t want to leave Linux users in the dark when it comes to something as important as this either.

The best way I can think of to get Hamachi started at system startup is to configure Hamachi as root (gasp), then write a script that starts tuncfg and Hamachi and symlink it into the appropriate /etc/rc directory for your usual runlevel. (Make sure the symlink starts with S99 so that it gets started last…) Again, this is somewhat of a security no-no, so it’s at your own risk and I’m not going to provide help for it. But I’ve done it in the past and it’s worked for me.

Conclusion
I still feel that this hack is the result of yearning for a feature that should not require very deep pockets or a corporate account in the first place, but that’s just me. I’d love to see Hamachi allow native service runs in future versions, even if only because the fact that such a feature needs to be kludged together in the first place is a slap-in-the-face. Come on, LogMeIn crew, wake up and add the service!