Inside Windows Product Activation A Fully Licensed Paper July 2001 Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin, Germany http://www.licenturion.com >> INTRODUCTION 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 002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX 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. 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. >>> Decoding 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. >>> Decryption 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