XP spyware features

Discussion in 'Windows Desktop Systems' started by smar999, Nov 4, 2002.

  1. smar999

    smar999 Guest

    Could somebody answer me this question? : What kind of information is Windows XP sending via internet (to Microsoft) about HW, SW implemented on a computer with registered XP?
  2. dave holbon

    dave holbon Moderator

    London England

    This article is the definitive guide to XP activation questions: -

    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

    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

    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

    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

    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.


    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

    '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

    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


    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


    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 product

  3. dave holbon

    dave holbon Moderator

    London England

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


    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

    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

    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

    >>>> 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


    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

    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

    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

    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.


    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
  4. Nick M

    Nick M Moderator

    Wow Dave!

    Great stuff there!
  5. Hipster Doofus

    Hipster Doofus Good grief Charlie Brown

    Melbourne Australia
    Yeah right. And you read it all Nick M. I didn't get past the first line. :eek:
  6. LilBlueDawg

    LilBlueDawg Guest

  7. dave holbon

    dave holbon Moderator

    London England
    The activation encryption was hacked some time ago, so technically its now possible to generate your own keys to send to MS. However you will need about five years use of the most powerful computer in the world to do this. Se you then.

  8. Nick M

    Nick M Moderator

    I read fast :) I skimmed through it; printed it; and put it on my bed; might as well read something tonight. :eek: