Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Product key
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Examples == === Windows 95 retail key === Windows 95 retail product keys take the form XXX-XXXXXXX.<ref>{{Cite web |last=Upadhyay |first=Saket |date=May 14, 2021 |title=Reversing Microsoft's Windows95 Product Key Check Mechanism |url=https://infosecwriteups.com/reversing-microsofts-windows95-product-key-check-mechanism-ca7e825014b6 }}</ref> To determine whether the key is valid, Windows 95 performs the following checks: * The first 3 characters must not be equal to 333, 444, 555, 666, 777, 888 or 999. * The last 7 characters must all be numbers from 0-8. * The sum of the last 7 numbers must be divisible by 7 with no remainder. * The fourth character is unchecked. If all checks pass, the product key is valid. Consequently a product key of 000-0000000 would be considered valid under these conditions. === Windows 95 OEM key === Windows 95 OEM keys take the form XXXXX-OEM-XXXXXXX-XXXXX. * The first 3 characters must be a number between 0-366. * The next 2 characters must be a number between 04-93. * The next 3 characters must be OEM. * The sum of the next 7 numbers must be divisible by 7 with no remainder. * The rest of the characters are unchecked. === Windows XP retail key === Windows XP uses an installation ID, product ID, and a product key for activation.<ref>{{Cite web |last=Purdy |first=Kevin |date=2023-05-26 |title=Green hills forever: Windows XP activation algorithm cracked after 21 years |url=https://arstechnica.com/gadgets/2023/05/a-decade-after-it-mattered-windows-xps-activation-algorithm-is-cracked/ |access-date=2024-06-29 |website=Ars Technica |language=en-us}}</ref><ref>{{Cite web |last=Chaussee |first=Rudower |date=July 2001 |title=Inside Windows Product Activation |url=https://www.licenturion.com/xp/fully-licensed-wpa.txt |access-date=June 28, 2024 |website=Licenturion}}</ref> ==== Installation ID ==== The installation ID is a 50 digit decimal string that is divided into 5 groups of six digits each with 2 digits at the end, which takes the form of XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX. The installation ID is regenerated every time msoobe.exe is ran. ===== Check digits ===== The right most digit in each group of the installation ID is a check digit. * Each check digit is calculated by adding the other five digits in its group. * Then adding the digits in that group in the even positions a second time. * Then dividing the sum of them by 7. * The remainder is the value of the check digit in its group. ===== Decoding ===== Removing the check digits results in a 41-digit decimal encoded 136 bit [[Multi-precision|multi precision integer]], which is stored in [[little endian]] byte order as a byte [[Array (data structure)|array]]. ===== Decryption ===== The lower 16 bytes of the Installation ID are encrypted, whereas the most significant byte is kept in plaintext. The cryptographic algorithm used 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|message digest algorithm]] keyed with a four-byte sequence. Let + denote the concatenation of two byte sequences, ^ the [[XOR cipher|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 which will be interpreted as four [[Double word|double words]] in little endian byte order followed by a single byte. {| class="wikitable" |+ !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. ===== 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. {| class="wikitable" |+ !Digits !Length !Encoding !Meaning |- |AAAAA |17 Bits |Bit 0 to bit 16 of P1 |Always 55034 (in Windows XP RC1) |- |BBB |10 Bits |Bit 17 to bit 26 of P1 |Most significant three digits of Raw Product Key |- |CCCCCCC |28 Bits |Bit 27 to bit 31 of P1 (lower 5 bits) and Bit 0 to bit 22 of P2 (upper 23 bits) |Least significant six digits of Raw Product Key and check digit |- |DDEEE |17 Bits |Bit 23 to bit 31 of P2 (lower 9 bits) and Bit 0 to bit 7 of P3 (upper 8 bits) |DD = Index of the public key used to verify the Product key EEE = Random value |} ==== Product key ==== The Product key takes the form as XXXXX-XXXXX-XXXXX-XXXXX-XXXXX. 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 The 25 characters of the Product Key form a base-24 encoding of the binary representation of the Product Key. The Product Key is a multi-precision integer of roughly 115 bits, which is stored in little endian byte order in an array of 15 bytes. 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 to the left by one bit position. 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. To obtain the CCCCCCC component, a check digit is appended, and the check digit that is chosen such that the sum of all digits, including the check digit, is divisible by seven. For verifying a Product Key, more than one [[Public-key cryptography|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. ===== Hardware information bit-fields ===== 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. {| class="wikitable" |+ !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 |Hard drive hardware identification string |- |H2 |16 |5 |[[SCSI]] host adapter hardware identification string |- |H2 |21 |4 |[[Parallel ATA#IDE and ATA-1|IDE]] controller hardware identification string |- |H2 |25 |3 |Processor model string |- |H2 |28 |3 |[[Random-access memory|RAM]] size |- |H2 |31 |1 |1 = dockable, 0 = not dockable |} If [[Docking station|docking]] is possible, the activation mechanism will be more tolerant with respect to future hardware modifications. 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 algorithm|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 <math>Hash = (Hash % BitFieldMax) + 1</math>. 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 from the other bit-fields as shown in the table. {| class="wikitable" |+ !Value !Amount of RAM possible |- |0 |(bit-field is 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 |} 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". ==== Hardware modifications ==== wpa.dbl is the [[RC4]]-encrypted database that stores, expiration information, the confirmation ID of an activated installation, the bit-field values representing the current hardware configuration, and the bit-field values representing the hardware configuration at the time of product activation, etc. The current hardware configuration is automatically updated each time the hardware configuration is modified in order to reflect the changes, while the values representing the hardware configuration at the time of product activation is fixed. When judging whether re-activation is necessary, the bit-field values of the current hardware configuration is compared to the hardware configuration at the time of activation. ===== Non-dockable computers ===== 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 the current hardware configuration since product activation, re-activation is required. ===== Dockable computers ===== If bit 31 of H2 indicates that our computer supports a docking station, 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. Of these remaining seven bit-fields, only up to three may change without requiring re-activation.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)