What is it?

Windows Product Activation is a technology devised by Microsoft for its new XP products. This includes Windows XP and Office XP. Apparently their goal is to prevent users from using a single CD to install many copies of the software.

How does it work?

Let's assume you have just bought a new computer without an existing installation of Windows XP. When you install the OS, it generates a so called Hardware ID (HWID) based on the hardware you have installed. You then have 30 days to register your copy of Windows via the Net or phone. The HWID is sent to Microsoft along with a unique Product ID, which came with the CD, and based on these two numbers, they send you back a code you use to register Windows.


The HWID is generated based on your hardware, so what if you change that hardware? Suppose you're deeply dissatified with the fact that Quake III only gives 50 fps, and that new GeForce 3 looks mighty fine. When you install the new board, the HWID also changes, and the the key used to register Windows is now invalid. Fortunately, Microsoft has implemented a system called "tolerance", which dictates that the HWID is allowed to change to a certain degree. If this tolerance is exceeded, you apparently have to phone in to Microsoft's tech support and explain to them just why your system has just changed.

It should be noted, though, that at this point it's still unclear what hardware features are used to calculate the HWID. It could be that something as simple as changing a DMA or IRQ setting might be enough to cause the HWID to change.

And what of larger companies, say the ones that have around 50,000 computers? According to this scheme they would have to buy 50,000 CD's to install Windows XP to every computer. To combat this problem, Microsoft plans to issue special versions of the OS, which have the WPA disabled. How long do you think it takes for this version to be pirated and distributed around the world?
Update 21 october, 2001: Well, it didn't take long. In fact, the pirated version of the non-WPA encumbered XP has been available for some time in Morpheus for example, and the OS isn't officially released yet!

It seems to me that it's only a matter of time that this system is defeated completely, either by pirated copies of the non-WPA version, or by handy H4x0rs finding a way to generate the registration keys with a key generator. Microsoft will not only be unable to prevent piracy or breaches of the EULA, but they will also make the life of honest users more difficult.

And what of larger companies, say the ones who have around 50,000 computers? According to this scheme they would have to buy 50,000 CD's to install Windows XP to every computer. To combat this problem, Microsoft plans to issue special versions of the OS, which have the WPA disabled. How long do you think it takes for this version to be pirated and distributed around the world?

Actually, at this point in time, it already has. Even before Corporate XP was released, apparently someone within M$ leaked the OS, and it has already been widely pirated. This not only upsets Microsoft Officials because of the obvious pirating hack, but also because of there are leaks internally within Microsoft. So this is one of those cases where a Napster-style upset has given the world a sneek preview of future before it has happened. I for one am not crying for Microsoft.
This Paper is being posted here in an effort to ensure it remains free from the clutches of Microsoft's lawyers.

Noder's Comments

Just posting the paper is well and good, but it doesn't add much other than increasing the security of the paper a small bit. I must confess at the outset that I am an anti-Microsoft 'bigot' and have been for quite some time. The authors of this paper have indeed gone to great detail to attempt to avoid legal action on the part of Microsoft. They claim that they are not presenting a complete 'method' for decrypting and encrypting the data fields required by Microsoft's much-heralded 'Windows Product Activation' methods.

They do, however, give a fairly detailed and close explanation of what is going on under the hood. They won't give you the particular decryption key that they used for their research (and, in fact, they don't talk about their research much, and that makes me nervous). However, armed with this knowledge, a malicious hacker (or cracker) would have a much easier time of it. For example, one could carefully step through the code looking for the decryption key.

The authors offer their support to the notion of Product Activation near the end of the paper - not surprising, given that they themselves are in the business of selling licensing technologies. The paper is a sort of subtle jab - it supports the notion while demonstrating (without explicitly stating) that Microsoft's implementation is fairly silly and easily circumvented.

It is instructive to note that at no point in the paper do the authors describe how they came by their information. The assumption is that they decompiled something and/or performed a classic cryptographic attack against the system and then reverse-engineered it. It's easier to believe the latter than might be expected; given Microsoft's tragically poor record with intelligent crypto management, anything's possible. They tend to rely on security-through-obfuscation rather than security-through-hardening, which makes their systems fairly brittle - once a determined attack breaches the system, it falls apart quickly.

Word of this paper was originally seen on Slashdot. Without further ado...

This paper was posted on the web with a copyright notice, to wit:

Copyright (C) 2001 Fully Licensed GmbH(www.licenturion.com)
All rights reserved

You are free to do whatever you want with this paper. However, you have to supply the URL of its online version


with any work derived from this paper to give credit to its authors.

Inside Windows Product Activation

A Fully Licensed Paper

July 2001

Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin, Germany


The current public discussion of Windows Product Activation (WPA) is characterized by uncertainty and speculation. In this paper we supply the technical details of WPA - as implemented in Windows XP - that Microsoft should have published long ago.

While we strongly believe that every software vendor has the right to enforce the licensing terms governing the use of a piece of licensed software by technical means, we also do believe that each individual has the right to detailed knowledge about the full implications of the employed means and possible limitations imposed by it on software usage.

In this paper we answer what we think are currently the two most important open questions related to Windows Product Activation:

  • Exactly what information is transmitted during activation?
  • How do hardware modifications affect an already activated installation of Windows XP?

Our answers to these questions are based on Windows XP Release Candidate 1 (build 2505). Later builds as well as the final version of Windows XP might differ from build 2505, e.g. in the employed cryptographic keys or the layout of some of the data structures.

However, beyond such minor modifications we expect Microsoft to cling to the general architecture of their activation mechanism. Thus, we are convinced that the answers provided by this paper will still be useful when the final version of Windows XP ships.

This paper supplies in-depth technical information about the inner workings of WPA. Still, the discussion is a little vague at some points in order not to facilitate the task of an attacker attempting to circumvent the license enforcement supplied by the activation mechanism.

XPDec, a command line utility suitable for verifying the presented information, can be obtained from http://www.licenturion.com/xp/. It implements the algorithms presented in this paper. Reading its source code, which is available from the same location, is highly recommended.

We have removed an important cryptographic key from the XPDec source code. Recompiling the source code will thus fail to produce a working executable. The XPDec executable on our website, however, contains this key and is fully functional.

So, download the source code to learn about the inner workings of WPA, but obtain the executable to experiment with your installation of Windows XP.

We expect the reader to be familiar with the general procedure of Windows Product Activation.

Inside the Installation ID

We focused our research on product activation via telephone. We did so, because we expected this variant of activation to be the most straight-forward to analyze.

The first step in activating Windows XP via telephone is supplying the call-center agent with the Installation ID displayed by msoobe.exe, the application that guides a user through the activation process. The Installation ID is a number consisting of 50 decimal digits that are divided into groups of six digits each, as in


In this authentic Installation ID we have substituted digits that we prefer not to disclose by 'X' characters.

If msoobe.exe is invoked more than once, it provides a different Installation ID each time.

In return, the call-center agent provides a Confirmation ID matching the given Installation ID. Entering the Confirmation ID completes the activation process.

Since the Installation ID is the only piece of information revealed during activation, the above question concerning the information transmitted during the activation process is equivalent to the question 'How is the Installation ID generated?'

To find an answer to this question, we trace back each digit of the Installation ID to its origins.

Check digits

The rightmost digit in each of the groups is a check digit to guard against simple errors such as the call center agent's mistyping of one of the digits read to him or her. The value of the check digit is calculated by adding the other five digits in the group, adding the digits at even positions a second time, and dividing the sum by seven(ed note - remember the 'all sevens' product keys of the Win95 era? heh.). The remainder of the division is the value of the check digit. In the above example the check digit for the first group (6) is calculated as follows.

         1 | 2 | 3 | 4 | 5  - position
         0 | 0 | 2 | 6 | 6  - digits

         0 + 0 + 2 + 6 + 6 = 14       (step 1: add all digits)
             0     + 6     + 14 = 20  (step 2: add even digits again)

     step 3: division

             20 / 7 = 2, remainder is 20 - (2 * 7) = 6
             => check digit is 6

Adding the even digits twice is probably intended to guard against the relatively frequent error of accidentally swapping two digits while typing, as in 00626 vs. 00266, which yield different check digits.


Removing the check digits results in a 41-digit decimal number. A decimal number of this length roughly corresponds to a 136-bit binary number. In fact, the 41-digit number is just the decimal encoding of such a 136-bit multi-precision integer, which is stored in little endian byte order as a byte array. Hence, the above Installation ID can also be represented as a sequence of 17 bytes as in

0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0x94 0xAA 0x46 0xD6 0x0F 0xBD 0x2C 0xC8 0x00

In this representation of the above Installation ID 'X' characters again substitute the digits that we prefer not to disclose. The '0x' prefix denotes hex notation throughout this paper.


When decoding arbitrary Installation IDs it can be noticed that the most significant byte always seems to be 0x00 or 0x01, whereas the other bytes look random. The reason for this is that the lower 16 bytes of the Installation ID are encrypted, whereas the most significant byte is kept in plaintext.

The cryptographic algorithm employed to encrypt the Installation ID is a proprietary four-round Feistel cipher. Since the block of input bytes passed to a Feistel cipher is divided into two blocks of equal size, this class of ciphers is typically applied to input blocks consisting of an even number of bytes - in this case the lower 16 of the 17 input bytes. The round function of the cipher is the SHA-1 message digest algorithm keyed with a four-byte sequence.

Let + denote the concatenation of two byte sequences, ^ the XOR operation, L and R the left and right eight-byte input half for one round, L' and R' the output halves of said round, and First-8() a function that returns the first eight bytes of an SHA-1 message digest. Then one round of decryption looks as follows.

          L' = R ^ First-8(SHA-1(L + Key))
R' = L

The result of the decryption is 16 bytes of plaintext, which are - together with the 17th unencrypted byte - from now on interpreted as four double words in little endian byte order followed by a single byte as in

                     name | size        | offset
                      H1  | double word |      0
                      H2  | double word |      4
                      P1  | double word |      8
                      P2  | double word |     12
                      P3  | byte        |     16

H1 and H2 specify the hardware configuration that the Installation ID is linked to. P1 and P2 as well as the remaining byte P3 contain the Product ID associated with the Installation ID.

Product ID

The Product ID consists of five groups of decimal digits, as in


If you search your registry for a value named 'ProductID', you will discover the ID that applies to your installation. The 'About' window of Internet Explorer should also yield your Product ID.


The mapping between the Product ID in decimal representation and its binary encoding in the double words P1 and P2 and the byte P3 is summarized in the following table.

       digits |  length | encoding
        AAAAA | 17 bits | bit  0 to bit 16 of P1
          BBB | 10 bits | bit 17 to bit 26 of P1
      CCCCCCC | 28 bits | bit 27 to bit 31 of P1 (lower  5 bits) 
              |         | bit  0 to bit 22 of P2 (upper 23 bits) 
        DDEEE | 17 bits | bit 23 to bit 31 of P2 (lower  9 bits) 
              |         | bit  0 to bit  7 of P3 (upper  8 bits)

The meaning of each of the five groups of digits is documented in the next table.

       digits | meaning
        AAAAA | apparently always 55034 (in Windows XP RC1) 
          BBB | most significant three digits of Raw Product Key
              | (see below) 
      CCCCCCC | least significant six digits of Raw Product Key
              | plus check digit (see below) 
           DD | index of the public key used to verify the
              | Product Key (see below) 
          EEE | random value

As can be seen, the (Raw) Product Key plays an important role in generating the Product ID.

Product Key

The Raw Product Key is buried inside the Product Key that is printed on the sticker distributed with each Windows XP CD. It consists of five alphanumeric strings separated by '-' characters, where each string is composed of five characters, as in


Each character is one of the following 24 letters and digits:

B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9

Very similar to the decimal encoding of the Installation ID the 25 characters of the Product Key form a base-24 encoding of the binary representation of the Product Key. Decoding the Product Key yields a multi-precision integer of roughly 115 bits, which is stored - again in little endian byte order - in an array of 15 bytes. Decoding the above Product Key results in the following byte sequence.

0x6F 0xFA 0x95 0x45 0xFC 0x75 0xB5 0x52 0xBB 0xEF 0xB1 0x17 0xDA 0xCD 0x00

Of these 15 bytes the least significant four bytes contain the Raw Product Key in little endian byte order. The least significant bit is removed by shifting this 32-bit value (0x4595FA6F - remember the little endian byte order) to the left by one bit position, resulting in a Raw Product Key of 0x22CAFD37, or


in decimal notation.

The eleven remaining bytes form a digital signature, allowing verification of the authenticity of the Product Key by means of a hard-coded public key.

Product Key -} Product ID

The three most significant digits, i.e. 583, of the Raw Product Key's nine-digit decimal representation directly map to the BBB component of the Product ID described above.

To obtain the CCCCCCC component, a check digit is appended to the remaining six digits 728439. The check digit is chosen such that the sum of all digits - including the check digit - is divisible by seven. In the given case, the sum of the six digits is

7 + 2 + 8 + 4 + 3 + 9 = 33

which results in a check digit of 2, since

7 + 2 + 8 + 4 + 3 + 9 + 2 = 33 + 2 = 35

which is divisible by seven. The CCCCCCC component of the Product ID is therefore 7284392.

For verifying a Product Key, more than one public key is available. If verification with the first public key fails, the second is tried, etc. The DD component of the Product ID specifies which of the public keys in this sequence was successfully used to verify the Product Key.

This mechanism might be intended to support several different parties generating valid Product Keys with different individual private keys.

However, the different private keys might also represent different versions of a product. A Product Key for the 'professional' release could then be signed with a different key than a Product Key for the 'server' release. The DD component would then represent the productversion.

Finally, a valid Product ID derived from our example Product Key might be


which indicates that the first public key (DD = index = 0) matched and 123 was chosen as the random number EEE.

The randomly selected EEE component is the reason for msoobe.exe presenting a different Installation ID at each invocation. Because of the applied encryption this small change results in a completely different Installation ID.

So, the Product ID transmitted during activation will most probably differ in the last three digits from your Product ID as displayed by Internet Explorer or as stored in the registry.

Hardware Information

As discussed above, the hardware configuration linked to the Installation ID is represented by the two double words H1 and H2.


For this purpose, the double words are divided into twelve bit-fields. The relationship between the computer hardware and the bit-fields is given in the following table.

    double word | offset | length | bit-field value based on
         H1     |      0 |     10 | volume serial number string
                |        |        | of system volume
         H1     |     10 |     10 | network adapter MAC address 
                |        |        | string
         H1     |     20 |      7 | CD-ROM drive hardware
                |        |        | identification string
         H1     |     27 |      5 | graphics adapter hardware
                |        |        | identification string
         H2     |      0 |      3 | unused, set to 001
         H2     |      3 |      6 | CPU serial number string
         H2     |      9 |      7 | harddrive hardware
                |        |        | identification string
         H2     |     16 |      5 | SCSI host adapter hardware
                |        |        | identification string
         H2     |     21 |      4 | IDE controller hardware
                |        |        | identification string
         H2     |     25 |      3 | processor model string
         H2     |     28 |      3 | RAM size
         H2     |     31 |      1 | 1 = dockable
                |        |        | 0 = not dockable

Bit 31 of H2 specifies, whether the bit-fields represent a notebook Computer that supports a docking station. If docking is possible, the activation mechanism will be more tolerant with respect to future hardware modifications. Here, the idea is that plugging a notebook into its docking station possibly results in changes to its hardware configuration, e.g. a SCSI host adapter built into the docking station may become available.

Bits 2 through 0 of H2 are unused and always set to 001.

If the hardware component corresponding to one of the remaining ten bit-fields is present, the respective bit-field contains a non-zero value describing the component. A value of zero marks the hardware component as not present.

All hardware components are identified by a hardware identification string obtained from the registry. Hashing this string provides the value for the corresponding bit-field.


The hash result is obtained by feeding the hardware identification string into the MD5 message digest algorithm and picking the number of bits required for a bit-field from predetermined locations in the resulting message digest. Different predetermined locations are used for different bit-fields. In addition, a hash result of zero is avoided by calculating

Hash = (Hash % BitFieldMax) + 1

...where BitFieldMax is the maximal value that may be stored in the bit-field in question, e.g. 1023 for a 10-bit bit-field, and 'x % y' denotes the remainder of the division of x by y. This results in values between 1 and BitFieldMax. The obtained value is then stored in the respective bit-field.

RAM bit-field

The bit-field related to the amount of RAM available to the operating system is calculated differently. The seven valid values specify the approximate amount of available RAM as documented in the following table.

                  value | amount of RAM available
                      0 | (bit-field unused) 
                      1 | below    32 MB
                      2 | between  32 MB and   63 MB
                      3 | between  64 MB and  127 MB
                      4 | between 128 MB and  255 MB
                      5 | between 256 MB and  511 MB
                      6 | between 512 MB and 1023 MB
                      7 | above              1023 MB

It is important to note that the amount of RAM is retrieved by calling the GlobalMemoryStatus() function, which reports a few hundred kilobytes less than the amount of RAM physically installed. So, 128 MB of RAM would typically be classified as "between 64 MB and 127 MB".

Real-world example

Let us have a look at a real-world example. On one of our test systems the hardware information consists of the following eight bytes.

0xC5 0x95 0x12 0xAC 0x01 0x6E 0x2C 0x32

Converting the bytes into H1 and H2, we obtain

H1 = 0xAC1295C5 and H2 = 0x322C6E01

Splitting H1 and H2 yields the next table in which we give the value of each of the bit-fields and the information from which each value is derived.

   dw &  |       |
  offset | value | derived from
   H1  0 | 0x1C5 | '1234-ABCD'
   H1 10 | 0x0A5 | '00C0DF089E44'
   H1 20 |  0x37 | 'SCSI\CDROMPLEXTOR_CD-ROM_PX-32TS__1.01'
   H1 27 |  0x15 | 'PCI\VEN_102B&DEV_0519&SUBSYS_00000000&REV_01'
   H2  0 |   0x1 | (unused, always 0x1) 
   H2  3 |  0x00 | (CPU serial number not present) 
   H2  9 |  0x37 | 'SCSI\DISKIBM_____DCAS-34330______S65A'
   H2 16 |  0x0C | 'PCI\VEN_9004&DEV_7178&SUBSYS_00000000&REV_03'
   H2 21 |   0x1 | 'PCI\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01'
   H2 25 |   0x1 | 'GenuineIntel Family 6 Model 3'
   H2 28 |   0x3 | (system has 128 MB of RAM) 
   H2 31 |   0x0 | (system is not dockable) 

Using XPDec

XPDec is a utility to be run from the command prompt. It may be invoked with one of four command line options to carry out one of four tasks.

XPDec -i

This option enables you to access the information hidden in an Installation ID. It decodes the Installation ID, decrypts it, and displays the values of the hardware bit-fields as well as the Product ID of your product. Keep in mind that the last three digits of the Product ID contained in the Installation ID are randomly selected and differ from the Product ID displayed by Internet Explorer.

The only argument needed for the '-i' option is the Installation ID, as in

XPDec -i 002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX

XPDec -p

To help you trace the origin of your Product ID, this option decodes a Product Key and displays the Raw Product Key as it would be used in a Product ID.

The only argument needed for the '-p' option is the Product Key, as in


Note that this option does not verify the digital signature of the Product Key.

XPDec -v

This option calculates the hash of a given volume serial number. It was implemented to illustrate our description of string hashing. First use '-i' to display the hardware bit-fields. Then use this option to verify our claims concerning the volume serial number hash.

The only argument needed for the '-v' option is the volume serial number of your system volume, as in

XPDec -v 1234-ABCD

(The volume serial number is part of the 'dir' command's output.)

XPDec -m

This option calculates the network adapter bit-field value corresponding to the given MAC address. Similar to '-v' this option was implemented as a proof of concept.

The only argument needed for the '-m' option is the MAC address of your network adapter, as in

XPDec -m 00-C0-DF-08-9E-44

(Use the 'route print' command to obtain the MAC address of your network adapter.)


When looking at the effects of hardware modifications on an already activated installation of Windows XP, the file 'wpa.dbl' in the 'system32' directory plays a central role. It is a simple RC4-encrypted database that stores, among other things like expiration information and the Confirmation ID of an activated installation,

a) the bit-field values representing the current hardware configuration,


b) the bit-field values representing the hardware configuration at the time of product activation.

While a) is automatically updated each time the hardware configuration is modified in order to reflect the changes, b) remains fixed. Hence, b) can be thought of as a snapshot of the hardware configuration at the time of product activation.

This snapshot does not exist in the database before product activation and if we compare the size of 'wpa.dbl' before and after activation, we will notice an increased file size. This is because the snapshot is added to the database.

When judging whether re-activation is necessary, the bit-field values of a) are compared to the bit-field values of b), i.e. the current hardware configuration is compared to the hardware configuration at the time of activation.

Non-dockable computer

Typically all bit-fields with the exception of the unused field and the 'dockable' field are compared. If more than three of these ten bit-fields have changed in a) since product activation, reactivation is required.

This means, for example, that in our above real-world example, we could replace the harddrive and the CD-ROM drive and substantially upgrade our RAM without having to re-activate our Windows XP installation.

However, if we completely re-installed Windows XP, the information in b) would be lost and we would have to re-activate our installation, even if we had not changed our hardware.

Dockable computer

If bit 31 of H2 indicates that our computer supports a docking station, however, only seven of the ten bit-fields mentioned above are compared. The bit-fields corresponding to the SCSI host adapter, the IDE controller, and the graphics board are omitted. But again, of these remaining seven bit-fields, only up to three may change without requiring re-activation.


In this paper we have given a technical overview of Windows Product Activation as implemented in Windows XP. We have shown what information the data transmitted during product activation is derived from and how hardware upgrades affect an already activated installation.

Looking at the technical details of WPA, we do not think that it is as problematic as many people have expected. We think so, because WPA is tolerant with respect to hardware modifications. In addition, it is likely that more than one hardware component map to a certain value for a given bit-field. From the above real-world example we know that the PX-32TS maps to the value 0x37 = 55. But there are probably many other CD-ROM drives that map to the same value. Hence, it is impossible to tell from the bit-field value whether it is a PX-32TS that we are using or one of the other drives that map to the same value.

In contrast to many critics of Windows Product Activation, we think that WPA does not prevent typical hardware modifications and, moreover, respects the user's right to privacy.


Fully Licensed GmbH is a start-up company focusing on novel approaches to online software licensing and distribution. Have a look at their website at


for more information.

Their research branch every now and then analyzes licensing solutions implemented by other companies.

Actually, bulk users (i.e. companies) will not need a large number of CDs and do manual activation for each copy. For them, there will be (and has been for a while) license management software that makes it possible to automatize the whole process. Microsoft knows how important it is to make life easier for its corporate customers.

Windows XP Product Activation is part of Microsoft's Out Of the Box Experience (OOBE). The files related to OOBE are stored in system32\oobe under the Windows folder.

If you want to activate Windows XP from the command line after you've installed it, you can type in 'oobe/msoobe /a' at the Start > Run... prompt.

If you fancy the cool, vaguely techno-esque music that's played during Windows XP Setup, you can find it in the images subfolder of the OOBE folder, as title.wma. It's a 2.5 MB file, lasting 5'24", encoded at 64 kbps. It is well worth listening to, if you missed it the first time around.

Log in or register to write something here or to contact authors.