|
=================
>>
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
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
AAAAA-BBB-CCCCCCC-DDEEE
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.
=================
>>>>
Decoding
=================
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
FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
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
583728439
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 product version.
Finally, a valid Product ID derived from our example
Product Key might be
55034-583-7284392-00123
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.
=================
>>>>
Bit-fields
=================
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.
=================
>>>>
Hashing
=================
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
XPDec -p FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
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.)
=================
>>
HARDWARE MODIFICATIONS
=================
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,
and
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, re-activation 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.
CONCLUSIONS
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.
=================
>>
ABOUT THE AUTHORS
=================
Fully Licensed GmbH is a start-up company focusing on novel
approaches to online software licensing and distribution.
Related Hyperlinks
WinXP
product activation cracked
http://www.theregister.co.uk/content/4/20433.html
Windows Product Activation compromised
http://www.tecchannel.de/betriebssysteme/746/index.html
German
press release (ASCII, 4.4 kb)
XPDec executable (zipped, 25.2 kb)
XPDec executable (self-extracting, 48.7 kb)
XPDec source code (zipped VC project, 49.4 kb) (Only the
executables contain the cryptographic key.)
Credits and Copyrights
Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin,
Germany
http://www.licenturion.com/xp/ |