@Tito yes token backups work for similar hardware.....but not if you change "C Drive". I believe changing your System drive will invalidate a token backup/restore if I am not mistaken
There's a lot of people in this thread that have already said it's impossible, but what if someone were to take the keyinfo source and modify it to allow the program to do spans of secret numbers on one type of key such as OA 3.0 keys and have the program output them into a database file like a rainbow table and then search for a known OEM key after the span is done. Once the key is found then you know what the parameters that were used to make the OEM key, then you look in the list for several other OEM keys and I'm sure there will be even more to finding out what M$ uses to generate the legit keys. I would do it myself but I do not know enough programing to make it do what I am wanting it to do. They may have a billion secret numbers between us and what they use to generate their keys, but we can use released keys that allow us a reference to work backwards from.
So maybe you should actually listen to them. You completely missed the point. There is nothing to work backwards. The secret number that this thread is referring to is included in the product key itself. The KeyInfo tool does not, in any way, generate any secret numbers. It has no magical sauce. It does no more nor less than simply translate a product key from one form to another. There is no additional information added or removed. It does nothing more than, say, rewriting a number in arabic numerals to roman numerals or vice versa.
I wasn't asking/wanting/needing anyone to create a keygen that will bruteforce product keys until you stumble across a valid M$ key as you will be basically activating somebody elses key that they paid for. I am talking about a program that will take my "genuine paid for key" and be able to produce a Confirmation ID (CID) based on the Installation ID (IID) used in the phone activation method so that I don't need to call m$ just to punch in my CID and then have the automated service tell me that there is a problem with my key, then wait on hold until somebody answers then repeat the process of telling M$ employee my CID so they can tell me my IID every time I want to reformat my pc. I just read Deagles post regarding finding the SHA256 hashing for this. I was just curious if this post meant that there had been some progress on that. that is all.
Not sure if you are aware, but Keyinfo can decode keys as well..that is, if all you want is to see the ID's used (i.e no need to create a gazillion keys in the hope of finding a match just to see which parameters it contains) - anyway I have decoded a bunch of my legit keys and there is no obvious relationship evident... in fact the only commonality amongst them was that secret was 16 digits in length...not much to work with I'm afraid I think the only feasible solution would be deagles' method of simulating the off-line activation...
Thank you superfly, I was unaware that keyinfo can decoding the secret parameter. I am still very curious about that 16 digit "secret" though. You would think that there is some relationship between those 16 digit numbers and how M$ generates their legit keys. Even if it's not immediately apparent. Sadly I have only 2 OEM Win8 Basic keys right now, not really enough to play with. Although hypothetically I might run to a few stores with magic jellybean and take a peek at some OEM keys on some demo machines.
I found something strange: I have a legal, genuine MAK key for 100 activations. Because of several activations VAMT 3.1 shows "Remaining Activation Counter = 67" for this key. With the program "KeyCheck v1.0.3.5" and "decode" function I found the "GroupId", "KeyId" and "Secret key" of this MAK key. "KeyCheck v1.0.3.5" has a hidden key generator (Settings.ini: [Configuration] Generator=2). As parameter for key generating I enter the found "GroupId", "KeyId" and "Secret key". I vary the range of the found "Secret key" (subtract 3 and add 3). With the generator function I get 7 totally different MAK keys - one of them was my legal, genuine MAK key. When I check these 7 MAK keys with VAMT 3.1 it shows "Remaining Activation Counter = 67" for all 7 keys. No one of the 6 new created MAK keys I can use to activate - neither online nor phone activation. Then I use my legal, genuine MAK for an additional activation and VAMT 3.1 shows me "Remaining Activation Counter = 66" - and for the 6 other new created MAK keys as well "66". What secret coupling exists between these keys (simultaneously decreasing "Remaining Activation Counter") ?
MAK count is the same for a each KeyID range thus the same MAK count for the 6 generated keys. The interesting part as you say is why their count decreased when you used a activation of the genuine key...Can only speculate they have a recognition tolerance for the hash of the key submitted, albeit that it can't activate without the exact hash... would be interested to hear others' interpretation as well..
The uniqueness of a product key is determined purely by the combination of GroupID + KeyID. The "secret" value is for verification only, to make sure you own a legitimate key. For each GroupID+KeyID combination, there is exactly one corresponding valid secret value. Clearly VAMT doesn't bother checking the validity of the secret value, since it's not needed to determine the uniqueness of the key. For efficiency reasons, Microsoft servers probably only require the GroupID+KeyID for checking count. The "secret coupling" you are asking about is merely the fact that those keys have identical GroupID+KeyID.
Isn't this kind of security problem? people could actually just flood the activation server with generated keys (without legit hash) and destroy the real key as the activation count drops to zero.
It isn't VAMT. All VAMT does is submit the key to a web service from MS, which does the checking. This is how we were able to make our own MAK checkers. Lots of the PID is completely disregarded on the check.
You misunderstood. Only a legit activation decreases the count. The part about ignoring the secret applies only to checking the count.
In theory, yes, but as has been extensively discussed in this thread already, that's too many to brute force in practice.