It'd be cool to be able to build "legitimate" LIVE packages that would be usable on unmodified 360s lol
Search for "MSKey README" if you want to read more... but as one interesting datapoint, the computational complexity of finding the private key was 2^31.
(Not that it matters in a world where kmspico and dazloader exist, but still)
Edit: @ale42: makes sense, thanks for putting this one to rest. 36^25 is approximately 8 x 10^38 which is a really, really big number.
This makes me think of a shareware app (I think an icon editor) for Windows 3.1 back in 1994 or so... I could find a valid registration key by entering random numbers by hand in around 2 minutes. And I wasn't lucky as I tried and succeeded several times ;-) But the rule (figured out after I had 10 or so valid keys) was simple maths with the digits, no crypto behind.
Kinda depends what is encrypted there. If it is just "magic number + SKU + licence ID" and there is no online check whether that combination is valid then you're "just" trying to hit one that's valid and that cuts few bits off equation as there is spectrum of keys that will be valid but not generated by Microsoft.
Which doesn't mean you shouldn't also use obscurity. NIST recommends it [1], and the industry widely uses it. In practice "don't rely on obscurity" usually means "have enough security besides obscurity to give you a grace period to switch out the obscurity". That's for whole systems, you might get away with people knowing you use standardized primitives like AES.
[1]: https://csrc.nist.gov/news/2021/revised-guidance-for-develop...
if it's not obscure enough that it will be found, then you are correct.
but what's more secure than a password that you don't know? not knowing there is a password in the first place. if the answer is never found, how can it be insecure? I dub this schrodinger's security.
