Compare commits
10 Commits
e01f29d476
...
f11905a462
Author | SHA1 | Date | |
---|---|---|---|
|
f11905a462 | ||
|
555989891b | ||
|
a10b1bf586 | ||
|
d924b2f7e7 | ||
|
a78b659dc4 | ||
|
5dd275f04a | ||
|
db4c1da820 | ||
|
eb7cb8adb6 | ||
|
767757e9d8 | ||
|
a1a89e10e2 |
@ -40,7 +40,8 @@ Other than full licenses, there are **grants** that are valid for a limited
|
||||
time. After the time period specified in the grant expires your system will want
|
||||
to renew it, prompting what is essentially a "reactivation" of the product.
|
||||
|
||||
Deposited licenses and grants can be found in `%windir%\System32\spp\store`.
|
||||
Deposited licenses and grants can be found in `%windir%\System32\spp\store` and
|
||||
`%programdata%\Microsoft\Windows\ClipSVC`.
|
||||
Here's likely the simplest way to look through licenses in `tokens.dat`:
|
||||
|
||||
```sh
|
||||
@ -67,8 +68,45 @@ license"). This type of license is retrieved through **any** of the following:
|
||||
* **Microsoft account**
|
||||
|
||||
All those above, except the **Machine** type (**TBV**) are subject to RIT and ROT related
|
||||
effects. (**TODO** Explanation)
|
||||
|
||||
effects.
|
||||
|
||||
### RIT and ROT
|
||||
|
||||
When the hardware ID for the machine for which a license is issued changes, the
|
||||
license has to be **reissued**. There are two recognized types of reissues:
|
||||
|
||||
* Reissue **In-Tolerance**
|
||||
* Reissue **Out-of-Tolerance**
|
||||
|
||||
In-tolerance reissues guarantee that the license sticks through some number of minor hardware
|
||||
changes. Out-of-tolerance reissues usually happen for drastic hardware changes, disk transfers
|
||||
and MSA (Microsoft Account) transfers.
|
||||
|
||||
#### Reissue In-Tolerance
|
||||
|
||||
When the hardware changes only slightly (or is client-correctable, e.g. by adjusting for RAM)
|
||||
a Reissue In-Tolerance is triggered and the license's Hardware ID is adjusted
|
||||
to match the new one.
|
||||
|
||||
The "RIT limit", for how many times such a reissue can happen, is currently thought to be
|
||||
unlimited.
|
||||
|
||||
#### Reissue Out-of-Tolerance
|
||||
|
||||
When a drastic hardware change is detected and the license no longer matches - a Reissue
|
||||
Out-of-Tolerance is triggered. The process is roughly the same as for RIT, except the limit
|
||||
for how many reissues can happen is much lower.
|
||||
|
||||
A reissue out-of-tolerance also happens when the same product key is installed on a
|
||||
different machine, when the license store is moved to a different machine or via a
|
||||
Microsoft account.
|
||||
|
||||
The limit for Out-of-Tolerance reissues likely depends on the following:
|
||||
|
||||
* Region (the license's assigned market)
|
||||
* Product (the licensed edition)
|
||||
* **Type of license** (Retail / OEM, tolerance a lot lower for OEM)
|
||||
|
||||
### Product key
|
||||
|
||||
When a valid Windows 10 product key is installed, activation will be attempted.
|
||||
|
172
Hwid.md
Normal file
172
Hwid.md
Normal file
@ -0,0 +1,172 @@
|
||||
# HWID Activation Method
|
||||
|
||||
Welcome to the `HWID` document. This has some details about the HWID activation method.
|
||||
|
||||
# Scope
|
||||
|
||||
How and why `HWID` works is somewhat complicated because of all the preliminary "knowledge" required to know why the very thing abused by HWID activators exists at all. Hence, this document.
|
||||
|
||||
# Digital Licenses
|
||||
|
||||
`Digital Licenses` (recently renamed to `Digital Entitlements`, but no one cares) are a fancy DRM invention by the geniuses over at Microsoft to make the Microsoft Store at least somewhat relevant.
|
||||
|
||||
Their purpose is to be proof of being licensed to use a piece of software (Please note that *You will own nothing and you will be happy* and *This software is licensed, not sold*) assigned to a Microsoft account.
|
||||
|
||||
There is a very long explanation for what keeps track of digital licenses, but that's somewhat complicated and I don't know everything.
|
||||
|
||||
Basically, there is a couple of components that keep track of these licenses and manage all the talking with the Microsoft Store and that talk to software components to tell them what Windows users are allowed to do with their computers. These are the things we want to accept our forgeries.
|
||||
|
||||
# The Free Windows 10 Upgrade
|
||||
|
||||
This activation method was at one point referred to as the "Digital License Generation without KMS or predecessor install/upgrade" and that name is just a tiny bit better and more descriptive than "HWID/KMS38".
|
||||
|
||||
During the free Windows 10 upgrade period, any activated system (this is the "predecessor") that upgraded to Windows 10 got a free digital license. This promotion is long over, but the free upgrade still works.
|
||||
|
||||
This type of reactivation/transfer (legal or otherwise) is actually used during **every single upgrade**, including between individual versions of Windows 10. This mode of activation is what we fake at the moment of writing.
|
||||
|
||||
# Mechanism of Activation Transfer
|
||||
|
||||
The main tool that facilitates the license transfer is called **GatherOsState** (full name: *Gather Downlevel OS Activation State*).
|
||||
|
||||
This tool collects, other than the titular activation state, the following information:
|
||||
|
||||
- Pre-upgrade **Windows Version** (eg. "NT 10.0.10240")
|
||||
- **Hardware ID**
|
||||
- One of the following:
|
||||
- OS **Product family name**
|
||||
- KMS Activation expiration time
|
||||
- MSDM OEM product key
|
||||
|
||||
These are put into a file called the Genuine Authorization Ticket (`GenuineTicket.xml`) and used by `ClipUp.exe` in a process referred to as "License Migration".
|
||||
|
||||
## Hardware ID
|
||||
|
||||
The activation method's name - "HWID" - refers to this very parameter so it must be important.
|
||||
|
||||
The Hardware ID is a magical data structure built by evaluating the system's hardware. In the ticket, it is found under the base64 string `SessionId`. The `Hwid` string is the base64 representation of the `HWID_BLOCK` structure.
|
||||
|
||||
### HWID_BLOCK
|
||||
|
||||
```c
|
||||
struct HWID_BLOCK {
|
||||
uint16_t wSize;
|
||||
uint16_t wVersion; // 0 for all
|
||||
uint16_t threshold; // Set to 0x13
|
||||
struct HWID hwid; // variable length
|
||||
struct TIMEWEIGHT tw; // variable length
|
||||
}
|
||||
```
|
||||
|
||||
### HWID
|
||||
|
||||
```c
|
||||
struct HWID {
|
||||
uint16_t size;
|
||||
uint16_t version;
|
||||
uint16_t instances[9];
|
||||
uint16_t dock_or_PCMCIA;
|
||||
uint16_t hashRAM;
|
||||
uint16_t hashBIOS;
|
||||
uint16_t instanceHashes[];
|
||||
};
|
||||
```
|
||||
|
||||
The hashes are all SHA-256 truncated to 15 bits; the 16th bit is set to whether the device is removable (1 if removable).
|
||||
|
||||
#### `version`
|
||||
|
||||
This is the version of the hardware ID. It is set to `0` for all implementations I'm aware of.
|
||||
|
||||
#### `nInstances`
|
||||
|
||||
This is an array of 9 counts of instances of hardware per type of hardware. The types are, in order (by 0-based index):
|
||||
|
||||
0. `CDROM` or `Mobile Broadband`
|
||||
1. `Hard Disk Controllers`
|
||||
2. `Hard Disk Drives`
|
||||
3. `Displays`
|
||||
4. `SCSI Adapters` or `Bluetooth Controllers`
|
||||
5. `Audio Adapters`
|
||||
6. Unused
|
||||
7. `Network Cards`
|
||||
8. `CPUs`
|
||||
|
||||
When there is an "or" betwen two types, the kind of device that has more instances is chosen.
|
||||
|
||||
#### `bDockOrPCMCIA`
|
||||
|
||||
This is set to 1 if non-user-provided docking info or PCMCIA is present.
|
||||
|
||||
#### `hashRAM`
|
||||
|
||||
This is a hash of the amount of RAM in the local system. It is rather advanced (supports NUMA and such) and is more than just the amount or a hash thereof.
|
||||
|
||||
#### `hashSMBIOS`
|
||||
|
||||
This is a hash of the entire SMBIOS table.
|
||||
|
||||
#### `instanceHashes`
|
||||
|
||||
These are the hashes for all components as per `nInstances`. For removable devices, the least significant bit is used as a flag for whether the device is removable or not.
|
||||
|
||||
Removability is assessed via PnP info. You can check it yourself with Powershell's `Get-PnpDeviceProperty -KeyName DEVPKEY_Device_RemovalPolicy` for any device you like. These values (`CM_REMOVAL_POLICY_[…]`) are mapped to a single bit set if the device is removable.
|
||||
|
||||
Some of the devices are only counted when they are not removable. Exact info on that when I stop being lazy.
|
||||
|
||||
### Timeweight
|
||||
|
||||
```c
|
||||
struct TIMEWEIGHT {
|
||||
struct weight {
|
||||
uint8_t type;
|
||||
uint16_t weight;
|
||||
} weights[];
|
||||
}
|
||||
```
|
||||
|
||||
The timeweight is a structure that contains information on how important certain hardware elements are. The structure is constant across Windows 10's history (not thoroughly verified).
|
||||
|
||||
The type corresponds to identifiers of Hardware Collectors in the HWID algorithm (you can find the values in the [massgravel/hwid-stuff](https://github.com/massgravel/hwid-stuff) repo) and the weight is how "important" a component is.
|
||||
|
||||
When **locally** verifying a hardware ID, you sum all the weights of components matching with the license's HWID and determine if they are equal to or over the threshold. If they aren't, the HWID does not match (`ClipUp` exits with an error).
|
||||
|
||||
### Further reading
|
||||
|
||||
If you're interested, the (somewhat outdated but still matching) patent for this type of Hardware ID can be found [here](https://patents.google.com/patent/US7302590B2).
|
||||
|
||||
## Product Family Name
|
||||
|
||||
The **Product family name** is a string that identifies a product family in the Microsoft store. When it comes to Windows, it is composed of a few mostly stationary parts:
|
||||
|
||||
```
|
||||
Microsoft.Windows.191.X21-99682_8wekyb3d8bbwe
|
||||
```
|
||||
|
||||
The above PFN corresponds to the following fields:
|
||||
|
||||
```
|
||||
Package Identity Name: Microsoft.Windows.191.X21-99682
|
||||
Publisher String: 8wekyb3d8bbwe
|
||||
```
|
||||
|
||||
In turn, the parts of Package Identity Name are:
|
||||
|
||||
- **Product**: `Microsoft Windows`
|
||||
- **SKU ID**: `191` (IoT Enterprise LTSC)
|
||||
- **Product Key Part Number**: `X21-99682`
|
||||
|
||||
### Publisher String
|
||||
|
||||
The publisher string is made by hashing some data about the publisher ([here](https://stackoverflow.com/questions/21568483/how-to-calculate-publisherid-from-publisher)). For all intents and purposes, it's a constant value.
|
||||
|
||||
### SKU ID
|
||||
|
||||
This value corresponds to the edition. You can find an (almost) full list of these IDs in Windows SDK's `winnt.h`.
|
||||
|
||||
### Product Key Part Number
|
||||
|
||||
The product key part number is a value specific to a given range of product key IDs belonging to a given group. Most commonly, you can find it on COA stickers. It's basically the "signature" of a key range; different ranges can have different policies, some ranges can be reserved for testing, etc. etc.
|
||||
|
||||
The part numbers can also be specific to markets (basically countries) in the Store itself, though I have no concrete examples of this.
|
||||
|
||||
### Work In (slow) Progress
|
Loading…
Reference in New Issue
Block a user