Correct. The firmware is the same, unless it is a true development drive. For example, below v40 Hitachi drive revisions would need to be upgraded to a minimum of v40 firmware before they would function properly in a retail console. The same can be said for the other two drive models. If you were to use the previous XeDK retail loader, you would need to modify your dvd firmware. But as stated, that required K:4532.
To play retail games on a devkit there are two protection issues that must handled one way or another... 1. Bypassing the XEX signature check All 360 executables (XEXs) are RSA-signed with a RSA private_key. The XEX loader in the 360 kernel checks this RSA signature against a corresponding RSA public_key before it will boot a game: Retail 360s will only boot XEXs signed with a "retail" private_key. The devkits will only boot XEXs signed with a "devkit" private_key. There are two ways to bypass this check on devkits, allowing retail games to be played. Since the "devkit" private_key is public, it possible to convert retail XEXs (and DLLs) into devkit XEXs by resigning them. This is an oversimplified explanation of course, there is a bit more to it. Another option is to trick the devkit to check the RSA signature against the retail public_key instead of the devkit public_key. This is possible since the retail public_key is known, and since the kernel can be tampered with by exploiting the sc() vulnerability in kernel 4548. This is what the "retail loader" does, and the reason it only works on 4548 - again, this is a very oversimplified explanation. 2. Bypassing the copy protection on 360 retail discs Retail 360 discs are copy protected. To unlock the game partition on retail discs there is a challenge-response (C/R) authentication process. The data needed to perform this C/R process is stored in encrypted tables in a security sector (SS) on the disc. The SS is at a position (PSN) on the disc that can not be copied - in the sense that this PSN can not be written to on writable DVD media. To bypass this protection the Xtreme backup format was invented. In this backup format the SS' differ from retail SS' in that they are located at a PSN that is writable, and that the "drive response table" is stored unencrypted. To play backups the drive firmware needs to hacked to be compatible with this format, and to report Xtreme discs as original 360 discs. This goes for devkits as well. To play backups in Xtreme format on a devkit, using the retail disc loader, the drive must be hacked to be compatiable with this format.... Another solution is to avoid this issue, by extracting all the files from a backup image, convert all XEXs and DLLs to devkit format, stripping any restrictions on the files in the process, and then boot them off the devkit HD instead..... Hope this helps clarify how it works under the hood..... CF
be careful, it has been said that under certain unknown conditions the XDK recovery will reflash the drive's key (and generate a new devkit keyvault). I don't have details, sorry. Just be careful, and always backup the retail dvdkey.
Great guide. Only thing I would change is on pg 4: "If you feel that you unable to accomplish any of these steps, then do proceed with disassembling the XeDK" Sounds like you're telling them that if they are uncomfortable, then to continue on without worry. Just a suggestion though.
lulz, I didn't catch that. Thats pretty funny actually. When in doubt... Just go ahead and bust the damn thing anyway. lol
just a little point to add to this: retail discs and xtreme backups etc have their authentication data encrypted with retail keys, not devkit keys. for this reason these discs will not work on a devkit. (this data is seperate to the signed/encrypted data in the xex files, so altering xex files will not fix this). the only way around this would be to hack the kernel/hypervisor, but that's a story for another day...
Thanks for the feedback ;D That reminds me, i need to add the section about adding a sidecar to a demo/debug kit.