OK I think I got a good setup worked out for PID. If EZ-Activator uses the PID fix, it stores the PID in the INI for AutoKMS and the Toolkit. Letting it install AutoKMS adds it to the AutoKMS.ini. Since the PID is set in the INI. I can configure any activation to patch that PID into memory once it starts the keygen. This way if you EZ-Activated and used the PID, the regular "Activate" button and AutoKMS will use this PID. For the chance you do wind up messing with the PID, you still have to by bad luck the changed PID be bad, and if this does happen, you can just run EZ-Activator again and it will through its fixes get a new PID or setup where everything is good again.
I have not actually checked Installation ID before or after (I should but I cannot reformat and a VM is likely to keep ID). It does work after a reformat where as using a normal restore after a reformat always fails. How the Reinstall Keys works is that you just restore the tokens, and then you reinstall all the product keys you had (taking a backup creates a keys.ini file). The catch is the License Store (the registry) must be good (as in if you reformat and brick office you can't restore). Best thing to do is reformat, and EZ-Activate immediately so you have 180 days KMS and 5 rearms, then restore via Reinstall Keys assuming you have a full and complete Keys.ini. This is how I got my MAK activation back. You could help me out since you have interest in this, is do this on a real PC, and show me the IID's. 1 Before reformat, 1 after reformat + clean install of Office 2010, and 1 after successful restore. Do note that if your backup is converted this is comparing apples to oranges, so if you are dealing with a MAK, you need that product and key installed (IID is there for each key, so if restoring MAK Pro Plus, we care about Pro Plus with the same MAK's IID, the KMS IID is useless).
What do you mean? Are you suggesting that restoring tokens.dat back and installing your previous MAK key is gonna get your activated status back?!!!
If Office is "bricked", that this won't work. My definition of bricked is either marked as tampered (which it is when you repair) or the registry/license stuff is deleted/corrupted in some other way that make it unusable. Otherwise yes, you stop OSPPSVC, just overwrite the tokens.dat and cache.dat (leaving the registry alone), restart OSPPSVC and reinstall the keys, and you are activated. This technique was partially used to hack BETA MAK activation into RTM, but it require replacing other files (frankenbuilding so it takes the BETA key). As long as you aren't "Bricked" this should work. You can even have 0 rearms + Notifications mode if you got there naturally (time expire, not "bricked"), and this work. The Reinstall Keys option just does a tokens only restore and reinstalls all the keys in a list (which are saved/user prompted when a backup is taken). Another thing to keep in mind is this seems to give you the rearm count of the existing PC vs the one in the backup. This is because rearm count is stored in the reg stuff, which we do not replace to make this work. This is why I recommend using a state with 5 rearms. If you remember, I used to have a "tokens only" restore, but without WMI, I could not differentiate having no keys installed vs being marked as tampered (because this is how I check a backup, but with WMI I can tell if licenses WITHOUT keys are there, if so then you aren't bricked you just have to reinstall the keys.) Due to this I scrapped tokens only restore until I found this out, where it came back in the form of Reinstall Keys. I have a MAK backup from 10/23/2010, I have reformatted my PC several times since then. The normal backup always fails but I sit today MAK activated where I had once given up hope of using this backup ever again.
Pretty much in my last post, that by the new backup/restore, the transfer after reformat issue is dead (of course it only works on the same PC though, I never tested it or expect it to work on a different PC). V2.1.3 is very close to release. As I said I added phone activation. One thing I noticed weird about phone activation compared to normal activation is what happens when you change/reinstall keys. If you online activate a MAK and activate KMS, switching or reinstalling the keys does not change status, as in if you had 180 days, installed a MAK, activated, then 5 days later reinstalled KMS key, you'd have 175 days, and going back to the MAK, it would still be activated. Phone activation however does not seem to persist. Assume in the same scenario that the MAK was phone activated. The KMS would still be 175 days, but going back to the MAK would go to where it would be in grace mode as if you never activated. Note that this is irrelevant because the toolkit saves your phone activation, so you just press phone and it looks in PhoneActivation.ini and reinstalls the Confirmation ID and your MAK is reactivated.
v2.1.3 is live with Phone Activation support and an EZ-Activator that should kill persistent KMS failure for good. Enjoy.
Indeed i did...and thats what LocalHosts FixMe-Mode is based upon. (Not the batch-patching, the CMID exchanging.) Now since i had my reasons for not making this public i am obviously not exactly excited over the fact that it is now, but now that the cats out of the bag anyway i might as well share my findings on the subject, which are quite substantial. Just give me some time to get everything together, i am still recovering from an illness and in the process of finding back to a normal daily routine... Heres the CL patcher i was using when i still persued the hot-patching idea. Extremely small and easy to use: View attachment ptch.7z
This blacklist thing is interesting. It explains why I can change the PID on the fly to get successful activation, but going back to the old PID (or blank PID if it was blank when it failed) still fails after the fact (_patrik_ case most resembles this, but strangely he activated with ZWT, and likely never used the Null PID beforehand, yet switching out the keygens resulted in failure for him). So of the two fixes I added to EZ-Activator, my CMID changing loop would reset the blacklist, since it has first nuked everything, repaired it, and set a new CMID. The PID wouldn't effect the blacklist, it would just get around it. There is a scenario that still eludes me. You said blacklisting occurs if you rearm a product and it does not have a GVLK installed. But change of CMID resets the blacklist. However, my repair destroys the old license stuff, and afterwards it will wind up with a new CMID. But old EZ-Activator could still fall victim to persistent error after totally rebuilding the license stores and getting a new CMID, also noting that after the repair and reconversion if reconversion occurs, no rearming occurs, converting goes straight to GVLK (but a lot of people don't even need the convert/reconvert and therefore it doesn't occur). In theory this should have reset the blacklist, and since there is a new CMID, the activation should have succeeded after the repair. My CMID fix simply takes a backup after repair/reconversion with a blank CMID so if there is failure it restores to get a new CMID (Resetting the blacklist).
First off let me say that i am massively disappointed in the behavior of letsgoawaytohell. Just to let you know; he found no solution to nothing, all he did was tear apart LocalHost (see my thread) and copycat my FixMe-Mode Host, which employs the null-string strategy. This is really a bummer and a typical example of someone who tries to cash in kudos for the work of others. I have spent countless days and nights analyzing and re-analyzing this stuff, and as you can imagine i am pretty pissed of right now. Had i known that an hour ago i probably would have thought twice about posting my findings, unfortunately i read his posts in my thread only after i posted here. Anyhow, since you (Cody) always were respectful i dont see why i shouldnt help you out with my findings anyway. Now that the cats out of the bag theres little sense in keeping things secret anymore. As for your questions, i made these notes as i went along so the notes at the very beginning may be outdated by newer findings. I would have to check that again to be certain. Everything after 'General' is reliable, though. (You have no idea how often i thought 'Oh thats how this works', just to find that it changed three or four tries later.)
One more thing; a 'blank' CMID is not really a blank CMID, at least not in the eyes of the licensing module. The licensing module simply interprets it as what it is, namely a string with all hex-zeroes, which is why this quasi-blank CMID is still blacklistable. (At first i too thought that using an all-zeroes string is the ultimate solution since i figured where there are no numbers/chars there is nothing that can be blacklisted. But as you remember i had to retract my statement regarding a failsafe solution shortly afterwards because i found out that it CAN be blacklisted too. Thats why FixMe-Mode uses the zeroed Host only as an 'inbetween-step' to generate a new CMID, as that unblacklists the old CMID so that the regular host will be accepted again. Seems our copy-happy friend overlooked this simple but very important detail...)
Don't you mean PID? The PID is what gets blacklisted (In the KMSEmulator). By blank CMID I mean the fact that office 2010 does not have a CMID until it tries to KMS activate (I added CMID to Check Activation). As far as CMID goes, it's impossible to use a CMID as office generates it the first time it tries to KMS activate. Since you say changing CMID resets the blacklist, if you disable my PID Changing, then this is attempted. Office 2010 is repaired, it has a blank CMID (and I took a license backup) .I at this point use a blank PID but I very well could use a normal PID. I attempt activation 10 times. If it fails, I restore backup and try another 10 times, because the CMID will be changed since CMID from blank to something once activation occurs (and restore brings back CMID to allow reactivation with a new CMID). What I don't get is that if changing CMID resets the blacklist, then why can this fail? If we ignore changing PID, the most likely reason my repair ever had an effect in the first place is because it resets the CMID (but I would think the blacklist itself would be stored in the license info). But if a CMID reset is a fix and clears the blacklist, then the repair should have worked and me never have needed to change EZ-Activator. Thing is, repair totally resets license stuff, though Office marks it as tampered, most likely so we can't just exploit this for easy rearming, and requiring activation. But the CMID has changed and the blacklist should be gone since a CMID blanks it and rearm effectively regenerates license stuff (which repair also does). So if blacklisting occurs by rearming only and a CMID change fixes it, then the fact repair changes CMID means activation shouldn't fail after it. I am missing something here. Your regular Keygen has ZWT PID, and Fix-Me mode uses null PID, and using the NULL PID you say unblocks ZWT. Then that makes me wonder why _patrik_ activated via ZWT and yet NULL failed, reactivated with ZWT, and NULL still failed.
I know for sure any such blacklist is stored inside the license stuff I back up. I released a tool called CMIDTest, which you take a backup where you have a blank CMID, and it loops and restores until activation fails. Then a backup of this is taken and you restore.. The restore is not blacklisted, but you can restore the Bad CMID dump and it is blacklisted. At no point in the CMIDTest loop did I change the PID of KMSEmulator, rather, office generates new CMID's and eventually creates one that for some reason it outright cannot activate with that combination of CMID+PID. You can change the CMID to beat the failure or you can change the PID, but the 10+ fail manifested itself purely off of CMID in this case. The same applies to EZ-Activator doing a repair and failing again right after. The CMID loop just takes advantage of the fact that right after repair we can take a NoCMID backup. We try 10 times like we normally would, but instead of throwing in the towel if we fail, we start a loop where we restore to blank the CMID, activate to change the CMID, and the change of CMID works. The CMID in office seems to be more powerful in this than the blacklisting of PID, as out of bad luck (and my bricker usually creates a BadCMID after 3-12 loops) you get a CMID that doesn't work. It's easier to change the PID as I see that I have 11 PIDs I can use, and certaintly one of them will work.
Goes to show what can happen when youre out of the loop for too long. Replace all CMID in the previous post with 'KMS Machine extended PID'. As for the patrik case, i would need to have more info on that to say more. At any rate, what always worked in my tests (while many other proceedings failed) is this: ● Regular Host blacklisted ● Use some other Host with a working different PID ● Perform a rearm ● Use the regular host to go back to the old PID This goes for both Windows and Office and so far it never failed. Its important not to forget the rearm.
I have searched until my eyes bled for where this is stored but so far i couldnt find it. If we could find the exact location of this (which BTW is the other method i was talking about) then we could simply delete the PID from the blacklist and all would be good again. But knowing Microsoft, chances are that this is stored in more locations than just one. They have a backup of just about everything somewhere, so even if we find it in one place a copy may still be in another. (And consequently restored from there.) Maybe i will give this another shot when im fully through with that illness stuff...
If it helps, using the CMIDTest.exe in conjunction with the toolkit is very good for creating test scenarios and then getting out of them easily. The last one I posted has a few bugs but if it would be of use to you I could post a fixed one. If I understand the above process, you start with ZWT PID failing, you use a different PID (does this step need to activate, fail to activate, or is it irrelevant?). Assuming you activated with the changed PID, I assume you use the rearm since the CMID has not changed by activation. You said previously you get 1 rearm to use. you use it and reactivate with the old host. If I am correct, that process works because you got around the problem by a PID change, but the old host starts works again because the CMID changes after rearm blanks it and you reactivate with the old PID.
BTW, as stated in my notes you can use just about everything, meaning it doesnt have to be something specific like a real-existing PID. For testing purposes i once used something ridiculous like 'f.u.c.k. .y.o.u. .a.s.s.h.o.l.e' (replacing some of the numbers) and it was accepted no problem. All thats important is that the combination as a whole meets a certain criterium, which would hint at a hash-check or something like that as the only check thats taking place. So whether the string is made out of numbers, chars or a combination of both is irrelevant. Thats also why the null-string works...it simply happens to meet that yet-unknown criterium...
They embed it in the license stuff, because you can do a backup/restore and go from blacklisted to fine. Problem is some things totally change this (a rearm completely creates new stuff, not just decrease a number). Thing is even if we could read this data (I don't currently know how or if it is encrypted or not) but OSPPSVC would likely detect a change.