I've read a lot, but probably not all of the 13,155+ posts on the subject and still have a few questions regarding the various KMS emulator tools which are available. 1. Are they built with a real, leaked KMS key, or is there some sort of anonymity or randomness? The reason I have this concern is because MS are actively scanning port 1688 for rogue KMS servers and when they find one, can determine the key it was installed with. I know someone who got an official email from MS anti-piracy informing that their KMS had been blocked because they discovered it to be available online. 2. Which of the tools is most suitable to replace an existing legit KMS server, for the same reason as stated above, not wanting anyone to be able to analyze it to determine whose key was used to build it? It seems most of the tools are suited for localhost installation but might be adaptable for network use. Ability to activate localhost isn't required if the host is already activated by another method. 3. Assuming nobody wants to give a direct answer to the above, can you point me to where it's listed the features and limitations of the various tools?
KMS server emulators do not contain a KMS host key (CSVLK), as they don't have the need for one. The KMS host key is used on a real server to activate the KMS functionality in the server. An emulator does not need this activation. All KMS servers, including both real and emulated servers, send something called an extended product ID (ePID) to any client that tries to activate with them. The value of the ePID is constant for any given real server, so every client always receives the same ePID from the same server. The ePID is in principle derived (in part) from the KMS host key. For a real server, in theory it's possible for Microsoft to look at the ePID that a server sends and from there calculate back to the KMS host key of the server. We can't do this, because only Microsoft has certain secret information that's needed for this. To date, we have no evidence whatsoever that Microsoft has ever done this ePID -> host key reversing. A KMS server emulator, although it does not contain a KMS host key, still sends an ePID to the clients (it must, it's part of the KMS protocol). How a KMS server emulator decides on what ePID to send varies between different implementations and versions of the emulators. Some have a single, fixed ePID hardcoded, and always send that. Some make one up totally randomly. Some make up a random one, but within certain constraints to make it look like a more-or-less legitimate ePID. Some emulators allow you to specify what you want the ePID to be, and allow you to copy the ePID of a real server. Hence to answer your question: if you use a KMS server emulator, then you are not using anyone's KMS host key, so you can't get anyone into trouble that way. The only way you could get someone into trouble is if you set up the KMS server emulator to send out the ePID of a real server. To avoid that, just don't use that function, and instead rely on a (semi-)random ePID, which is possible in almost all emulators.
The above was the part I didn't realize or understand. I have "evidence" of this. They looked at "something" on port 1688 and sent an email to the owner of the KMS key proving so and asking him to firewall the server, thus prompting investigation of what to replace it with that won't get him in trouble again.
Could you clarify this story a little further please. You are saying that MS sent an email to the legitimate owner of a legitimate KMS key, asking them to firewall the server. That makes sense: MS doesn't want a KMS server to be generally accessible over the Internet. What I don't understand is: why would the KMS server need replacing with anything? If the KMS key is legitimate (and by that story it seems so), why not just do what MS asked and firewall it? I may have misunderstood something.
To further clarify something: Although a KMS server emulator does not use a KMS host key, there are alternative solutions out there that are not based on an emulator, but instead leaked KMS host keys and a real server. Generally this involves setting up Windows in a VM using the leaked KMS host key and making it accessible over the Internet. Such solutions would get the owner of the KMS host key in trouble.
How could they tell that port 1688 was running KMS and not something else? Or what key the was being used? ~MC
That wouldn't be hard. You connect to it with a KMS client. If it works, it's running a KMS server. You can then look at the ePID from the server and (in theory) reverse it to get the KMS host key.
Apparently MS have a scanning tool that is looking for exactly that. Find a KMS server, decode the product key, contact the owner. Spoiler Dear Mr. XXXXXXXX, Microsoft has determined that your 2 Key Management Service (KMS) Servers are open to the internet and allowing product activations on multiple volume license keys. The situation opens your network to illegal activity and software piracy. The table below identifies the KMS Volume License Keys (VLK) as well as the IP address the servers are accessible at. For your protection both technically and legally, and to prevent possible software piracy, Microsoft performed a full block (Activation and Validation) on the KMS on XX/XX/201X. This will not affect your existing installs and clients and will not impact your daily operations. To unblock the KMS server can you please confirm in email that you have been able move it behind a firewall? Once we have verified it is secure we will unblock it. If the IP address does not belong to you, please contact me immediately as this may indicate the account has been compromised. Key InformationDetail KMS Key Organization / Owner[Customer Name redacted] KMS Key Agreement NumberXXXXXXXXXXXX KMS Key Product 1 ProdKey3 Windows Svrs 2012 R2 00206 DLA 6 Volume:CSVLK KMS MLF First 5 alpha-numerics of KMS VLK 1XXXXX IP Address of Server allowing activations:[IP address redacted] IP Address Owner (per CentralOps.net)[ISP Name redacted] KMS Key Product 2 ProdKey3 Office 2013 00206 DLA 6 Volume:CSVLK Vol Lic KMSHost MLF First 5 alpha-numerics of KMS VLK 2XXXXX IP Address of Server allowing activations:[IP address redacted] IP Address Owner (per CentralOps.net)[ISP Name redacted] If you have any questions, please let me know. Thank you for your attention to this matter! XXXXXXXXXXXXXX / xxxxxxxxxx@microsoft.com Antipiracy Microsoft Corp. Lync +1 428.703.4000 ex XXXXX To clarify the story: in short, the user in question wants to provide KMS service for several machines he's installed and supports for various people, but doesn't want all the hassle of VPN access or going to all those machines and installing some tool locally.
Thanks for copy/pasting the email, that is very interesting and gives more insight. However, this does not yet prove that Microsoft has determined the KMS host key from the ePID. Since you have (rightly) redacted all the actual information, such as the IP address, name of the owner of the IP address and the owner of the KMS key, the following is also possible. Microsoft could have looked at the owner of the IP address, and determine the owner of the KMS host key from there, after which they can just look up the KMS host key in their own database. Only you know the actual details, so only you can tell whether this was possible. Is the user in question the same as the owner of the KMS host key, or has the user "borrowed" the key from the actual owner?
I did wonder what would happen. Does anyone remember that Taiwanese KMS server? Just imagine the number of people activating their copies with that! I would totally expect M$ to do something similar to them too... or would they not bother?
All the more reason to use a non-standard port number and not advertise your kms server/service to anymore than necessary.
OK, just to complete this thread, with a resolution to the issue. We decided to install the KMSSS v1.1.1 service using this: Spoiler sc create KMSSS binPath= "C:\KMS\KMSSS.exe -Port 1688 -PWin 55041-00172-199-943189-03-1031-7601.0000-3032011 -PO14 55041-00172-102-943189-03-1031-7601.0000-3032012 -PO15 55041-00172-199-943189-03-1031-7601.0000-3032012 -AI 120 -RI 10080 KillProcessOnPort -Log -IPFiltrOFF" start= auto group= WMI DisplayName= "KMS Server Service" I assisted with tweaking the firewall rules to allow access only from the specific ISPs where his "clients" exist. The PIDs came from one of the included example cmd files with the KMSS download. I haven't found what those are yet, I'm guessing they were something the author generated randomly? I wonder if they should be changed.