Office 2010 Toolkit and EZ-Activator.

You need to login to view this posts content.

 

I can't seem to find it. Also, note I need an actual live KMS server to do the test I want to do.

On an unrelated set of testing (making sure my PID's work on Windows and Office). After nuking the ones that failed for office and finding a few more on the internet. I have 10 PIDs that work both on my Office 2010 on my PC and Win 7 SP1 Enterprise in a VM. While you said testing may have one not work, my goal was to axe ones that were tested never to work within my zone (so I know each one at least works some of the time, and 1 out of 10 should result in a match).

 

Thanks for the extra PID's but I managed to meet my quota of 10.

Also, a friend of mine was able to with a real KMS server at work test my PID idea. You can have a PID 100% fail with KMSEmulator, but a server using the same PID will have no issue.

This killed the last tiny doubt that the fault is 100% in the emulator, and it means someone skilled enough could probably fix it (I lack the knowledge of reverse engineering and cryptography to even attempt suck a task, but it should be possible to fix).

 

Well given that Phazor has passed out PID's and I have axed the bad ones, I have one more update planned.

I'll replace the bad PID's in 2.1.3 with good ones, and I will make AutoKMS 100% independent of Office (you can currently activate windows, but it will bail out immediately if it doesn't find office, also, toolkit won't even let you currently install AutoKMS if Office 2010 is not installed.).

 

Nope. I rigged things so that I could use a KMSEmulator elsewhere by rigging the hostsfile. Domain/IP has no effect whatsoever.

There isn't a blacklist given things can match up except for the difference being a real vs fake server. The KMSEmulator is undoubtedly at fault. I don't even think it does anything to windows/office in any way shape or form that makes a difference, I just think KMSEmulator chokes out in certain scenarios due to flaws in the code of the keygen.

 

Of course Windows AutoKMS users still will have to explicitly enable Windows activation in Settings to use it. I'd rather not have to implement a windows KMS detector, I just assume the user has things setup right since they manually enabled the support. I'd have to check too many SKUs since there Vista/7/Server/Server R2/Other KMS Enabled Windows crap, and not only would it be a lot of code but doing the checks would be slow.

 

There is one more thing I'll try. But so far in my testing, by using the same PID, the only thing changed besides server name was the fact we used a real server.

I will test another scenario. Where I use the server PID in the keygen, but I will use host file to redirect the real server to localhost (last time I used a random domain just to see if it had an effect). Effectively this means one less thing will change on the PC.

I'll post back soon, but I don't believe there is a "Blacklist", rather, I believe giving certain PID and CMID combos causes KMSEmulator to persistently and expectedly fail.

One thing someone should look into. Does a KMSEmulator response with a certain CMID and the PID of a real server vary much from the real server's response that has the same PID and client has same CMID. I know the responses will vary but it might give a clue if it can be seen that the KMSEmulator response is malformed or anything. Matter of fact, it may be possible to do the same kind of check by just using the PID change without changing CMID. Obviously changing PID changes the responses, so I believe there is a bug is the resposne generation.

 

Test confirms domain makes no difference.

 

Well if could occur on a system from the start but be very rare. Since either changing the CMID or changing the PID solves the issue, and I can loop CMIDs until I get a bad one. It might be possible that someone gets a bad CMID from the start. The rarity makes this hard to believe but it seems if a blacklist exists it is contained in the license files. Regardless if it is the CMID or blacklist, a restore would put both back into place. But given that I have created a test scenario where the only things that have varied are the times between activation attempts, and what is physically generating the response, I believe KMSEmulator generates bad responses based on CMID/PID combination, because leaving a PID/CMID the same and simulating all other conditions exactly, the real server has no issue (a blacklist should block a server since the client has the same CMID and the server has the same PID. You can generate a response over and over and the server never fail (knowing the responses are probably a bit different each time) and the KMSEmulator always fail in its responses).

Also, even in my scenario where all that varies is who is giving the response, even after the server activates, the KMSEmulator still fails. Normally I believed that once activated you were always good, but changing PID complicated this since you could activate, change the PID, and that PID cause issues. But things have always held that if you successfully activated with a PID, you would not have any issue reactivating. But this is not the case with going from server to emulator, another reason why I believe KMSEmulator is giving bad responses.

 

This is what I believe, that whatever goes on inside the KMSEmulator has some issues, because my testing with a real KMS server and new tools allows testing scenarios I don't think have been tried before.