How and why does it verify the integrity of the CPU key if it's a random key in the first place?There is code in the HV that generates and burns the cpukey lines. However I thought it was just leftover from manufacturing. I suppose its possible on brand new consoles that the nand is encrypted with a 0'd key and the hv/kernel will set it and rewrite the nand encrypted with the new keys on it's first run. But never heard of anyone mentioning this process and never see any references in the kernel to it.
On top of that, cpukeys are generated a specific way and can be verified as being legit. The HV does this in a couple places and if its not legit, it might cause issues.
Because its not random. Its generated from a random salt but can be verified by a checksum algorithm MS uses. Idk if they actually use it on live servers but it might just be another thing that they can use to confirm if your console is as it should be.How and why does it verify the integrity of the CPU key if it's a random key in the first place?
You would be missing some hardware that the devkit HV/kernel references. (don't know about the kernel actually, but the HV references some special registers that are not on retail. AND some parts of the cpu work differently that may cause issues). I don't know when exactly the fuses are burned, but there are algorithms in the HV to burn the patterns we all see on lines 0, 1, and to generate and blow the cpukeys. Meanwhile the LDV lines are blown through variables. For example this is the algorithm to blow line 0: https://i.imgur.com/uUjQGvD.pngI'm pretty sure stock consoles already have the CPU key bunt before they get shipped to stores, otherwise, you can swap the nand and put in an XDK recovery disk and convert them to a devkit, no RGH chips, no JTAGs needed.