Two methods of avoiding Windows Vista product activation

A few months back, I wrote about how Windows Vista product activation works for volume license customers.  Last night I was searching to find out what the grace period is before activation is required and I stumbled across some interesting articles. You see, it turns out that there are three main problems with product activation:

  • Corporate IT departments want to produce customised Windows builds.  These builds must be valid when deployed to client PCs (i.e. the product activation period must not have expired!) and, as the product activation timer is ticking away during the customisation process, there needs to be a method to “rearm” product activation.
  • OEMs want to ship pre-activated versions of the operating system (an arrangement with which I’m sure Microsoft are happy to comply as they need OEMs to preload their operating system and not an alternative, like, let’s say… Ubuntu Linux!), so Microsoft provides these so-called Royalty OEMs with special product keys which require no further activation, under as scheme known as system-locked pre-installation (SLP) or OEM activation (OA) 2.0.
  • Anti-piracy measures like product activation is that they are to hackers like a red rag is to a bull.

The net result, it seems, is two methods to avoid product activation.  The first method, can be used to simply delay product activation, as described by Brian Livingston at Windows Secrets. It uses an operating system command (slmgr.vbs -rearm), to reset the grace period for product activation back to a full 30 days.  The Windows Secrets article also describes a registry key (HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL\SkipRearm) and claims that it can be set to 00000001 before rearming, allowing the rearm to take place multiple times (this registry key is reset by the rearm command, which is also available by running rundll32 slc.dll,SLReArmWindows); however, Microsoft claims that the SkipRearm key is ineffective for the purpose of extending the grace period as it actually just stops sysprep /generate (another command used during the imaging process) from rearming activation (something which can only be done three times) and does not actually reset the grace period (this is confirmed in the Windows Vista Technical Library documentation).  Regardless of that fact, the rearm process can still be run three times, giving up to 120 days of unactivated use (30 days, plus three more rearms, each one providing an additional 30 days). That sounds very useful for both product evaluation and for corporate deployments – thank you very much Microsoft.  According to Gregg Keizer at Computer World/PC World Magazine, a Microsoft spokesperson has even confirmed that it’s not even a violation of the EULA.  That is good.

So that’s the legal method; however some enterprising hackers have a second method, which avoids activation full stop.  Basically it tricks the operating system into thinking that its running on a certain OEM’s machine, before installing the relevant certificate and product key to activate that copy of Windows.  The early (paradox) version involved making hex edits to the BIOS (hmm… buy a copy of Windows or turn my PC into a doorstop, I know which I’ll choose) but the latest (vstaldr) version even has an installer for various OEMs, and if that doesn’t work then there is a list of product keys which can be installed and activated using two operating system commands:

slmgr.vbs -ipk productkey
slmgr.vbs -ato

I couldn’t possibly confirm or deny whether or not that method works… but Microsoft’s reaction to the OEM BIOS hacks would suggest that this is not a hoax.  Microsoft’s Senior Product Manager for Windows Genuine Advantage (WGA), Alex Kochis, describes the paradox method as:

“It is a pretty labor-intensive [sic] process and quite risky.”

(as I indicated above).  Commenting on the vstaldr method, he said:

“While this method is easier to implement for the end user, it’s also easier to detect and respond to than a method that involves directly modifying the BIOS of the motherboard”

Before continuing to hint at how Microsoft may respond:

“We focus on hacks that pose threats to our customers, partners and products.  It’s worth noting we also prioritize our responses, because not every attempt deserves the same level of response. Our goal isn’t to stop every ‘mad scientist’ that’s on a mission to hack Windows.  Our first goal is to disrupt the business model of organized counterfeiters and protect users from becoming unknowing victims.   This means focusing on responding to hacks that are scalable and can easily be commercialized, thereby making victims out of well-intentioned customers.”

Which I will paraphrase as “it may work today, but don’t count on it always being that way”.

Ask for genuine Microsoft softwareNote that I’m not encouraging anybody to run an improperly licensed copy of Windows.  That would be very, very naughty. I’m merely pointing out that measures like product activation (as for any form of DRM) are more of an inconvenience to genuine users than they are a countermeasure against software piracy.

Disclaimer

This post is for informational purposes only. Please support genuine software.

Introducing Windows Server 2008

Windows Server 2008 logoWhen I logged on to the Microsoft Connect site this morning, I noticed that the beta program for Windows Server codenamed Longhorn has been renamed… it seems that I should have checked in on more details from Bill Gates’ WinHEC keynote, where he announced that the product will be called Windows Server 2008 (no surprises there then).  Actually, dull as it sounds, I think that’s the right name - it’s clear and unambiguous (although I expect the product bundling will be confusing as always).

Reinstalling Windows Home Server

After replacing a failed hard disk yesterday, I needed to rebuild my Windows Home Server (WHS).  The process was surprisingly straightforward – having suffered a total disk failure, I had no data to worry about (in any case, the server only contained client PC backups), so all I needed to do was re-install the software (although I’m not sure what the effect of product activation would have been as I hadn’t activated WHS when the disk crashed) and re-establish my configuration changes (firewall changes, language settings, date and time, etc.).  One item I had expected some trouble with was the remote access address but because this is linked to my Windows Live identity, it was re-established automatically and so the only concern was reconnecting my client computers.  I had to recreate the user accounts manually but to reconnect an existing client computer, it was as simple as running %programfiles%\Windows Home Server\discovery.exe (thanks to GordonTGopher and Ken Warren for helping me out on that one at the WHS forums).  This added the computers back into the WHS console and that night, the backups ran as normal.

One more item that may be useful (it certainly saves using the Windows Home Server client connector CD), is to note that the client software is available at \\servername\software\Home Server Connector Software\setup.exe (via Optika’s workaround to beta feedback request 262981).