from memory hashed keyvaults contained an extra key which was actually the hash over the keyvault. if it is indeed just a hash then the hash should be recalculatable as long as you have access to your cpu/fuse key.

In process of researching the modification of Console ID, we have come to a few pieces of information. However, one thing is not behaving logically, so perhaps you can shed some light on it.

I have been told by atleast a dozen people that the hash checks are not active in v1 KV’s. This should enable us to modify them. I am however, resigned to what limited information was provided, and no one has been able to tell me as of yet, specifically, the differences between ‘v1′ and ‘v2′ KV’s and how it affects security/hash checks. But we just proved it is indeed verifying the console ID against the cert when we altered our KV’s with a new console ID on a xenon. Could you please shed some light on the subject of what is different between v1 and v2 KV’s? And if this is something not possible, how would one patch the HV/routine to prevent the check in the first place? Should XBR not be able to patch for that?

As for working out the algorithm it is the same as with anything hacking related, you take what you have and work backwards. So you look at the Console ID from a number of different xbox360s along with whatever other relevant information you can gleam and then it becomes fairly obvious. It is not a complicated algorithm; basically consisting of parts of the mac address and the date of manufacture.

The top 4 bits are still unknown to me as I did not come across an Xbo360 that had anything there except zeros, however the revoked list does show a very small number of IDs have some data here.

The only thing left is the CRC which tend to be calculated according to the same kinds of general rules and in this case was very simple. A brute force app that tested many different kinds of possible rules was able to identify the CRC algorithm after just a few seconds.

anyway thanks 4 replay