@letsgoawayhell any ideas? The only possible issue is the new KMSEmulator, as nothing activation related has changed. Also when do you think you'll have more info about KMS? Because I'll probably have 2.1.3 out by the end of the weekend if time/errors permit me to implement/test the next EZ-Activator fix method.
Persistent 8007000D error gone for good Well guys, here is the post that I promised you. When a KMS activation is attempted, KMS client send a 260 byte request using MS RPC to KMS host and KMS host sends a 176 byte response using the same protocol. KMS client will send its KMS CMID to KMS host using this request that will be used in the host to identify client. When an activation requested is recieved by the host, the following data is gathered: 1- Client's KMS CMID 2- Host's KMS machine extended PID 3- Activation response timestamp And a message is generated using this data. The message is then encrypted and finally sent to the client that requested activation. Unfortunately, in ZWT's KMS keygen, encryption part is buggy. This bug causes the final encrypted message to be invalid sometimes. The bug can surfaces because of several reasons: 1- message timestamp: In this case your recieve a 8007000D error. to resolve the issue you need to issue a new activation command in your client. timestamp will change and the problem gets solved. 2- Host's KMS machine extended PID/Client's KMS CMID combination: Because ZWT's keygen is hardcoded with 55041-00168-305-190595-03-1033-3790.0000-2692009 as it's KMS machine extended PID and KMS CMID is fixed, the average user can't do anything about this and activation attemps will fail regardless of how many times you attempt. The solution is two fold: change host's PID or client's CMID. We already did a good job and changed ZWT's keygen PID to null for you in Modified version of keygen. This gives the least possible probability of generating a message that causes the bug in encryption algorithm to surface. But there is no guaranty that this new null-PID/CMID combination does not causes the bug to surface again. So there is still a possibility for 8007000D error. Of course if a null PID is not enough for you to put out the bug and if you have enough knowledge you can change PID in keygen again and try it once more, you will most probably be sucessfull this time because PID/CMID combination was changed. But other than changing PID, you can change CMID. The good thing is that when you install office your CMID is null and the moment you try your first activation attempt a random CMID is generated for you. If your PID/CMID is getting you trouble you can easily try to change this combination by changing your CMID. I already posted a lot of stuff about how you can change your CMID so I don't repeat myself. OK guys, I think I made a lot of things clear. The rest of this post is an algorithm that I suggest to all developers who are willing to develope activators for Office 2010 and are willing to use KMS activation. 1. Check if CMID is null? If so, backup the following registy key: Code: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform 2. Launch Modified version of KMS keygen. 3. Try activation for 5 times (or whatever number you think is appropriate). 4. If no success, fall back to original keygen and try activation for 5 times. 5. If no success, If you have a backup from step 1, then restore the backup to get a null CMID and goto step 2. But if you don't have a backup from step 1, use a rearm to get a null CMID and go to step 1; and if in worst case, all rearms are already used up the force a repair to get a null CMID and goto step 1. I am pretty sure that this post resolves persistent 8007000D error for good. Final Note: Please say thanks if you found this post usefull.
Your CMID fix suggestion is the thing I've planned for EZ-Activator over the past few days, but you say the KMS PID can be changed as well. Do we have any way to make new PIDs? Because if we did, we could patch new ones into the keygen (maybe this is what phazor was talking about when he was asking the best way to generate a number to be patched to an offset). The CMID fix in EZ-Activator will take advantage of the fact that when we start the current "Repair", finishing it results in having no CMID.
In response to my friend (CODYQX4)'s question, I have to say: As I said earlier ZWT keygen is packed using UPX 3.03. Packed size is: 77,824 bytes. If you unpack it you'll have a file with 151,552 bytes. You can only modify unpacked one coz UPX compresses the contents in packing stage. ZWT keygen's KMS machine extended PID is located at offset: 136932 (216E4 in hex). And it is 96 bytes in length (because it is in Unicode).
Nice to see you have noticed the PID thing as well. They are very similar to the advanced PID generated by pidxgen. Thing is very little of the ID changes. For the parts you have not identified, the last part is just a date, most likely when it was generated. So the only part of the PID in question is very little. I plan to implement the CMID fix we have both came up with, but would like to test into something. I've unpacked your V2 and repatched the PID back into it. What I'd like to see is for people getting the error with the new keygen, does the old PID work, and if we change said PID (on the fly by closing KMSEmulator, patching it and restarting it) to something else does that help. My idea is can we change the PID on the fly to help remedy the issue. You posed two solutions, one is already in EZ-Activator (rearm). But these require either using a rearm or using my repair to blank the CMID. If we can remedy the issue by patching the PID, I think that would be a more elegant solution as it would be independent of the CMID. This is of course assuming that whatever we change it to can actually make a difference. Phazor must have had this idea because he was asking how to best patch a file via batch file. We need a decent commandline hex patcher for this. That dev tookit I posted is good for creating the initial brick we need for adequate testing of this. PS: The 03 part is always the same as well, so only 6 digits of the PID should be significant, since all the other stuff has a specific purpose and is predictable.
Now that I think of it, being able to edit a byte[] in C# would be better, as I can release a new dev tool to allow direct editing of the PID, because I read the keygens as byte[], but if I can edit the byte[] before writing, then the written KMSEmulator.exe will have a modded PID. I think I have a good idea on how to do so. I'll investigate this more later, it's getting late.
letsgoawayhell thank you man for this detailed and useful information, really appreciate your work and help here. some questions: 1) What does "force a repair" do exactly? how do I force a repair manually? 2) when I launch OSPPREARM.EXE to rearm my office it always get closed immediatly, how to change that? 3) How come you advice to try ZWT original keygen if your modifided one fails? is there some problem with your v2 modifded keygen (like _patrik_ case)? 4) How come a null PID is not enough to fix the bug with a new CMID's? 5) What is the best way to reset my rearm's back to 5 and how to do it properly because the way I use it the rest is not always taking place. CODYQX4 nice idea, and same as letsgoawayhell I really appreciate you both so thank you.
1. Force a repair is to nuke Office 2010's license files then cause setup to repair itself. You can delete the stuff and run office and it runs the MSI's for you, but my "Repair" is automated and faster. 2. I am sure it's supposed to close immediately so it's hard to catch the output that way. Launch it via toolkit or cmd prompt to see what it did. 3. Not sure about this, this was something I theorized to see if having a PID would change cases where null fails. This is happening in _patrik_ case where V2.1 works because KMSEmulator has a PID. 4. He said ZWT encryption is messed up and null helps but is not 100% solution. 5. Force a repair and successfully activate office, there is no other way to reset the count short of having a backup that had 5 rearms.
CODYQX4 has already answered all questions. My answers would be same as his. And thanks for the support, I really appreciate it.
Can you explain how to do it manually via command? which files/reg? "You can delete the stuff" What stuff exactly? & How to run the MSI's manually via command (how do you find out about it?).
Thank you for this nice tool. When i check the remaining Rearm it says "You have 1 Available Rearms" I use ToolKit 2.1.1, W7 64bits French. Info from Word 2010 Help: Office 2010 Version:14.0.5128.5000 (32 bits) French Product ID:02260-018-0000106-48643. Does this mean that after next period of 6 month, i'll be not genuine?
You delete the tokens and OfficeSoftwareProtectionPlatform key, and then if on 64 Bit repair the "Shared Components MSI" , then the main MSI for a product. But this is not enough as you'd have to reinstall all licenses after the fact. It's a bit difficult to explain it but the easiest way to do it manually is to let Office setup do the repairs by launching office (the code for repair is very long and complicated).
The rule of KMS says: You have to reactivate each 180 days. Having 1 rearm left doesn't have anything to do with activation stuff. If you were able to activate in the past, you will be able to do it in the future. Just don't rearm (!) so that your KMS CMID is not changed. P.S. : If you don't activate within 180 days, your Office will go to OOT_Grace mode.
The 2009 is the year the PID was generated. Use the keychecker today and last 4 are 2011, and the whole end is 0902011. This value is always the same today. I change the day by one and its now 0912011. The 091 means 91st day of the year. Their example is 363rd day of the year.