Summary

With elevated access on a Xbox 360 console, it's possible to 'bypass' the code challenge by pushing a unmodified hypervisor to the console and slowly reading back the unmodified encrypted memory and ECC checksum table data from the hypervisor and storing this data to generate correct code challenge results.

Description

The current 17559 code challenge is Xbox's LIVE's main and most critical defense to preventing modified systems from accessing and or staying on LIVE. However, with 2 small issues, this system is able to be completely bypassed. The Xbox 360 code challenge hashes the unencrypted hypervisor, encrypted hypervisor, and the region containing the ecc checksums of each 0x80 byte block of the hypervisor. This data is extremely important as it contains nearly everything to pass the code challenge. The issue however, when a hypervisor is dumped from a modified console, the patches applied to the hypervisor are removed and reverted to their original values, this hypervisor is then placed on the modified console (likely a trinity board), and this hypervisor is then applied to the console, while the code applying this hypervisor takes special care to save/restore anything that would cause the hypervisor to crash. Once the unmodified hypervisor is applied to the modified console, the code executing this task will then slowly read back the correct data used to then generate the code challenge results themselves (take special note there is a sleep that is done after each hypervisor memory read which allows for the dcbst instruction to update the ecc checksum region). At this point the attackers have clean encrypted and unencrypted hypervisor data, along with the correct ecc checksums for the entire hypervisor, which essentially leaves the salt to hopefully pick up the slack. However the current SG configurations for the code challenge are only using a static list of 256 0x10 byte salts. Assuming the algorithm for the ecc checksums isn't compromised, the attacker would next need to be able to generate the ecc checksum for the 0x10 byte salt (the salt is copied 8 times into hypervisor memory and then a ecc checksum is created of that memory and used as the salt of the SHA hash). However with the limit of only 256 salts (assuming due to collisions with ecc checksum salts), an attacker could craft their code challenge/payload to loop through the entire salt array and have the console generate the ecc checksum for the salt and when done correctly, the address of which this was executed in hypervisor memory can be stored as well to further spoof the results of the code challenge.

Steps to Reproduce:

The following steps are assuming you have a Xbox 360 with elevated access (most attackers will use a reset glitch hack on a trinity board, which renders the best results) on the latest 17559 kernel (however the steps currently apply to ANY & ALL kernel versions).

1. Extract the base/offline hypervisor from the system update file.

2. On the Xbox 360 console with elevated access, boot the console, and extract the current hypervisor.

3. Assuming the attacker has decrypted (the code to decrypt the code challenge is available online) and reverse engineered the code challenge, the first logical step would be to extract the addresses and sizes of where the code challenge hashes to know which data we can easily correct in our extracted hypervisor by comparing it to the base/offline hypervisor which clearly wouldn't have any modifications.

4. Once the hypervisor modifications are completely reverted to their original code, there's only 1 security hash that needs to be corrected in the hypervisor, which is stored at 0x100F0. This is a SHA hash which hashes the ecc checksum region of the hypervisor, during the boot process the Xbox 360 initially sets all 3 hypervisor encryption keys to 0x55 (0x30 bytes worth), after this is when the hypervisor computes the ecc checksums of the statically encrypted hypervisor memory. However due to the issue described above with being able to get the data needed for the hashes on a modified console, the same can be applied to this hash with minor changes. Within the hypervisor code is a section that generates the random 3 hypervisor encryption keys via (XeCrytRandom(0x10100 0x30)), by disabling this XeCryptRandom and statically setting the keys to all 0x5's, the console will fully boot with the keys as all 0x5's and the process of applying a clean hypervisor and reading the data back can be applied again to achieve the correct SHA hash.

5. With a patch-free hypervisor, and correctly generated security hash, the next line of defense which either allows the connection to LIVE or doesn't, is the 1st SHA hash inside the code challenge, which essentially hashes the unencrypted hypervisor. This SHA hash is salted with the 0x10 byte salt from the static list of 256 salts, then hashes the code sections of the hypervisor, along with the security hash region containing 4 hashes total. Currently this hash only has 256 possible results due to the static list of only 256 salts, making it possible to have all 256 correct results in seconds.

6. With all 256 results computed of the unencrypted hypervisor hash, along with a few other pieces of data pulled from the console (easily spoofable boot loader flags, etc), the modified console can now run a module to hook XamExecuteChallenge via xam.xex and easily copy in the spoofed results based on a table of 256 salts/results. These results are sent and processed, however even with lots of the data in the code challenge results being wrong, online access will still be allowed if the server verifies the unencrypted hypervisor SHA hash is correct, which essentially gives the attacker anywhere from 1-72 hours before a ban is issued depending on which parts of the code challenge results are wrong. For example, sending the results with a null cpu key sha digest will automatically ban the console, but randomizing the second security hash inside the code challenge will still allow anywhere from 1-3 days before a ban is issued.

7. At this stage, the console is able to connect to LIVE and run game modifications before the system processes the rest of the code challenge results or the randomly generated ban time runs out. This is where the more advanced security hash inside the code challenge was implemented, however using the steps described above, you can dump and store all the data required for this hash, and provide the results you have stored based on the salt the current challenge is sending.

8. The code challenge results also contain 2 other pieces of data we need to correct. The first of which is the RSA signed blob which contains the hypervisor encryption keys, since these are randomly generated on boot, they have to be sent in the code challenge results for the server to be able to generate the same results using the same key. By reverse engineering how the hypervisor RSA signs this data, an attacker can then select and sign their own encryption keys in the code challenge results, allowing them to basically hand-pick which set of pre-dumped data they want to use from their own stockpile. With the code to sign this data, an attacker can now select any set of their pre-dumped data, and sign the key that was used for that data themselves, and replace it in the code challenge results.

9. The last piece of data that needs to be spoofed to completely bypass the code challenge system, is a 2 byte address of where the code challenge was executed, which is needed for the server to be able to process and generate the same ecc checksum of the 0x10 byte salt. This can be achieved by crafting a payload similar to the code challenge, by making the payload copy the 0x10 byte salt 8 times, and executing a dcbst instruction which will make the hypervisor update the ecc checksum region, which an attacker can now store this 2 byte checksum of the 0x10 byte salt, along with the address of where it was executed, to be later used for spoofing.

10. Lastly, assembling the data to make it all make sense. Next we would need to assemble an API to match code challenge results based on the salt being sent. This can be done by creating a Xbox 360 app to run about 10 seconds after boot, which first saves a copy of the hypervisor encryption keys being used, along with a few other variables that need to be restored during this process to prevent a crash. With the current encryption keys saved, the app can now apply the patch-free hypersivor with the correct security hashes, and then slowly read and save the encrypted correct hypervisor data and ecc checksums to be later used for correctly spoofing the code challenge result