194 lines
12 KiB
HTML
194 lines
12 KiB
HTML
<!DOCTYPE html>
|
||
<title>Read Me - Activation FAQs</title>
|
||
<html>
|
||
<head>
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
</head>
|
||
<body style="background-color: #DfDfDf;">
|
||
<pre>
|
||
<code>
|
||
Updated 30-08-2019
|
||
|
||
|
||
====================================================================================================
|
||
Activation FAQs:
|
||
====================================================================================================
|
||
|
||
The following text is a mixture of facts and few guesses. The facts as listed are true as far as
|
||
I am able to know.
|
||
You should read it with a grain of salt. It's a good habit to doubt things, but don't start to
|
||
believe your doubts if you don't have any reasonable argument to justify the doubt.
|
||
|
||
Digital License and KMS38 activation descriptions are based on reverse engineering efforts by
|
||
the methods' authors - @mspaintmsi and an Anonymous developer.
|
||
|
||
If you think anything written here is false, please notify https://massgrave.dev/
|
||
|
||
====================================================================================================
|
||
|
||
=====================================
|
||
Digital License (HWID) Activation:
|
||
=====================================
|
||
Written by @mspaintmsi-
|
||
|
||
During the upgrade process from Windows 7, 8, 8.1 to Windows 10 (Also from Windows 10 to a newer
|
||
version of Windows 10) properly activated systems are eligible for a digital license.
|
||
The digital license activation is permanent and linked to a specific user (Through hardware and optionally through a Microsoft Account).
|
||
|
||
Internally it works something like this,
|
||
|
||
The upgrade process executes gatherosstate.exe contained in the installation medium.
|
||
The job of gatherosstate is to generate a Genuine Ticket for use by the Client License Platform migration tool (ClipUp)
|
||
This ticket is a GenuineAuthorization XML file containing the following information: (There are more fields in tickets from ClipUp, but we won't need those)
|
||
* Its version. As of now, this is always "1.0"
|
||
* the genuineProperties:
|
||
* Properties:
|
||
* OA3xOriginalProductId - The Product ID of the BIOS key.
|
||
* OA3xOriginalProductKey - The BIOS product key.
|
||
* SessionId:
|
||
* OSMajorVersion - The OS Version Major
|
||
* OSMinorVersion - The OS Version Minor
|
||
* OSPlatformId - The OS Platform ID. Always 2 (2 means Windows NT)
|
||
* PP - Protected Process - Whether or not gatherosstate was run as a protected process
|
||
(It practically never does. ClipUp is also capable of generating those tickets, and it runs as a protected process.)
|
||
* Hwid - The Hardware Id - a base64-encoded byte array containing information about the current hardware configuration.
|
||
* Pfn - Package Family Name - The package family name of your Windows edition.
|
||
* OA3xOriginalProductKey - The BIOS product key. (Yes, it's a duplicate)
|
||
* DownlevelGenuineState - Indicates whether or not your system is genuine. (activated)
|
||
* TimeStampClient - The ISO 8601 format date of ticket generation.
|
||
* Signatures:
|
||
* signature: (Either downlevelGTkey or clientLockboxKey depending on which utility actually generated the ticket - SLC, gatherosstate or ClipUp)
|
||
* downlevelGTkey - rsa-sha256 signature for the Properties field
|
||
* clientLockboxKey - rsa-sha256 signature for the Properties field
|
||
|
||
This ticket is later applied using ClipUp and sent to Microsoft Servers.
|
||
In return, the Microsoft servers responds with the JSON "receipt" for the digital license. The fields in it are irrelevant and mean practically nothing.
|
||
|
||
This license is linked to specific hardware, and can be transferred to other hardware if needed using a linked Microsoft Account.
|
||
|
||
This process during upgrading requires a lot of time, and it's not as easy as clicking an “Activate” button.
|
||
so to achieve this, @mspaintmsi and an Anonymous developer discovered a way to quickly generate a valid ticket for acquiring a license.
|
||
|
||
There were a lot of methods for this, but the simplest one is placing a modified SLC (Software Licensing Client) library next to gatherosstate.
|
||
Due to gatherosstate loading this library dynamically it can be substituted very easily without modifying the gatherosstate file at all.
|
||
This library was originally a modified version of SLSHIM by @vyvojar on GitHub (but has went through so many changes that it barely resembles it anymore).
|
||
|
||
This library is supposed to query the licensing information for use by gatherosstate.
|
||
gatherosstate has no way to verify this information, so it blindly places it into the ticket.
|
||
|
||
After sending the ticket and receiving the receipt your system is activated.
|
||
|
||
Now a question arises,
|
||
Q.) Can Microsoft differentiate counterfeit tickets and block the license?
|
||
A.) Umm.. Yes, but actully no.
|
||
The signature type can (sort of) be used to determine what utility is responsible for the ticket.
|
||
There is no way (in a standard environment) for a non-activated Windows 10 installation to generate a ticket.
|
||
In the normal process, gatherosstate will ask SLC for the entire ticket, but when this fails it will generate and sign it by itself, creating a
|
||
"downlevelGTkey" signature.
|
||
For every system with an installed product key a generated ticket will be returned by SLC and thus will have a "clientLockboxKey" signature.
|
||
|
||
Put simply, the signature (should) always be a "clientLockboxKey" one in case of an activated system, but in this case it isn't.
|
||
Microsoft will not take action against it, because of the risk of voiding valid licenses.
|
||
Besides, they never really cared for consumer piracy; That's not where they get the most money from.
|
||
|
||
====================================================================================================
|
||
|
||
==============================
|
||
KMS38 Activation:
|
||
==============================
|
||
|
||
Written by @mspaintmsi-
|
||
|
||
The KMS38 method is closely related to the HWID method, as it utilizes the same tools.
|
||
This method also generates a GenuineAuthorization XML file using gatherosstate, but with slight differences.
|
||
This time instead of the "Pfn" field, we have the "GVLKExp" field.
|
||
GVLKExp is short for "Generic Volume Key Expiration (date)" and contains an ISO 8601 timestamp of when the KMS activation ends.
|
||
|
||
This volume expiration date can be changed to an arbitrarily (signed) integer value using the SLC library.
|
||
The very long time for activation is related to the Y2K38 problem as this date (19 january 2038 around 3AM) is the maximum date we can give
|
||
to gatherosstate without it looping back to year 1970.
|
||
|
||
The main difference is that those tickets are only valid on Volume:GVLK systems. That mostly includes Enterprise and Education editions.
|
||
|
||
Now another question,
|
||
Q.) Can Microsoft block this kind of activation?
|
||
A.) Not directly. They could only update Clipup to allow for a maximum activation period of 180 days.
|
||
Not much beside that can be done on their part.
|
||
The tickets are not sent to Microsoft at all, so they can't block them or take action directly.
|
||
|
||
====================================================================================================
|
||
|
||
==============================
|
||
Online KMS Activation:
|
||
==============================
|
||
|
||
- What is KMS activation?
|
||
Key Management Service (KMS) is a genuine activation method provided by Microsoft for volume
|
||
licensing customers (organizations, schools or governments). The machines in those environments
|
||
(called KMS clients) are activated via the Environment KMS Host Server (authorized Microsoft's
|
||
licensing key), instead of Microsoft activation servers.
|
||
By design, the KMS activation period lasts up to 180 Days (6 Months) at max, with the ability to
|
||
renew and reinstate the period at any time. Activation renewal automatically happens every 7
|
||
days if the client can connect to the KMS host server.
|
||
For more info, see,
|
||
https://www.microsoft.com/Licensing/servicecenter/Help/FAQDetails.aspx?id=201#215
|
||
https://technet.microsoft.com/en-us/library/ee939272(v=ws.10).aspx#kms-overview
|
||
|
||
- How we are getting it for free?
|
||
Developers reverse-engineered the KMS Host Server setup, so now anyone can host a KMS server and
|
||
activate the systems without any limitations.
|
||
KMS activators such as KMSpico, MTK, KMS_VL_ALL, and etc., locally create an emulated KMS Host
|
||
Server and activate Windows and Office.
|
||
|
||
This locally-emulated KMS server requires you to run binary files which often cause
|
||
anti-virus alerts (false positives).
|
||
|
||
Another method of KMS activation is publicly-available Online KMS Host Server.
|
||
In this method, the site hosts the emulated KMS server and anyone can simply use this server to
|
||
activate their systems, there is no requirement for running any software on your system and
|
||
no worry of AV's alert. And this method is the most identical to the genuine KMS activation.
|
||
As long as the site hosting the emulated KMS server remains on line, and is available to connect
|
||
to, continued activation will be assured.
|
||
|
||
- Is it safe to use Online KMS activation?
|
||
Yes.
|
||
Now let's go into the details, why,
|
||
In the KMS protocol, there is a relationship of host and client. The client system asks the host
|
||
system to grant the activation, and the host system grants the activation if it's eligible.
|
||
In doing this, the client system shares some of the system’s data, which is not sensitive in nature.
|
||
According to the Microsoft documents, the client system shares the following LIMITED data
|
||
with the host system:
|
||
Client FQDN, CMID, time-stamp, Product license state, expiration time and IP address
|
||
https://technet.microsoft.com/en-us/library/ee939272(v=ws.10).aspx#kms-overview
|
||
|
||
In this info sharing, the only important part is your IP address.
|
||
We can now talk about possible assumptions and consequences regarding this, but before we begin,
|
||
you should know the following facts.
|
||
- IP addresses do not necessarily represent a specific person. Internet Service Providers (ISP's)
|
||
mostly use DYNAMIC IP, which means the same IP address can be used by many different persons,
|
||
and a dynamic IP address is periodically reassigned to different people all the time. But a
|
||
STATIC IP address is permanently assigned to a single, unique, subscriber.
|
||
However, the Internet Service Provider (ISP) won't reveal that information unless
|
||
there is a legal reason to do so.
|
||
- Microsoft has NEVER tried to catch Home users for using a few pirated activations (not
|
||
talking about stolen legal keys) simply because the cost of legal actions would be much higher
|
||
than the amount of money gained by forcing a few people to PURCHASE activations.
|
||
- No law enforcement is going to take action based on the IP's from all over the world without
|
||
the consent from the Microsoft itself.
|
||
- In case you are feeling that your machine’s sharing of IP address information as part of the
|
||
ongoing KMS activation process is quite intrusive in nature, then you should keep in
|
||
mind that any website can fingerprint your device, which means that website can keep a record of
|
||
you not only by your IP address, but also with information about your device hardware.
|
||
|
||
* After these facts, I can't imagine how Online KMS Activation can negatively affect the user.
|
||
If you know exactly how it can, than please let me know. Thanks.
|
||
|
||
====================================================================================================
|
||
</code></pre>
|
||
</body>
|
||
</html>
|
||
|
||
<p> </p>
|
||
|
||
|