Downgrading to Older Kernels/Dashboards with Xbox 360 Bad Update

BadUpdateDowngrading.md

NOTES: I AM NOT RESPONSIBLE FOR ANY DAMAGE DONE TO YOUR CONSOLE! PLEASE MAKE A NAND BACKUP AND HAVE AN EXTERNAL PROGRAMMER IN THE EVENT OF A BRICKED CONSOLE

PLEASE DO NOT SELL DOWNGRADED CONSOLES!

Please do not use this guide for any malicious or scammy behavior. I only want this guide to be used for personal projects/nostalgia.

THIS WILL NOT RE-ENABLE ANY PATCHED EXPLOITS LIKE THE JTAG EXPLOIT. THERE IS NO WAY TO DOWNGRADE CB TO RE-ENABLE THESE.

Thanks to everyone that made this possible:

grimdoomer: For the Bad Update exploit

InvoxiPlayGames: For the FreeMyXe project

MrMario2011: For the Bad Update tutorial

Octal450: For J-Runner with Extras

Jordan_1_Evo in the Xbox 360 Hub Discord server: For making me aware that this is possible

This guide assumes you have an Xbox 360 console running the latest dashboard version (2.0.17559.0) that can run homebrew applications with BadUpdate. If you do not know how to exploit with BadUpdate, here are some resources to get you started:

How to Run the Xbox 360 Hypervisor Exploit with a Free Demo - Bad Update Setup! from MrMario2011

grimdoomer/Xbox360BadUpdate

This guide was tested with a Xenon console downgraded to 2.0.6717 with CB 1928 as well as a Trinity downgraded to 2.0.9199.0 with CB 9231. The Xenon booted, the Trinity didn't. Your results may vary.

Step 1: Making a NAND Backup

Make a NAND backup! Not only will it benefit you in the case of a brick, but it will also help you in the process of building a new, downgraded NAND.

Follow the MrMario2011 Bad Update guide linked here. He explains everything better than me :P

Step 2: Modifying a NAND backup

Connect the USB device you used for Bad Update into your computer. Locate the folder containing Simple 360 NAND flasher and copy flashdmp.bin and cpukey.txt somewhere safe.

Download the latest version of J-Runner with Extras and extract it. Open JRunner.exe. Once it has loaded, find the Load button and locate your NAND backup. Your CPU key and console information should automatically show up. (If your CPU key does not automatically show up, open the cpukey.txt file that you copied earlier and paste the CPU key from that into J-Runner.)

On the right side of J-Runner, you should see the tab Bootloaders and SMC. Look for Console and CB_A and take note of the entire number that shows up. This is important. Make sure you have the correct number, otherwise you could brick your system. Now, close J-Runner.

In the J-Runner with Extras folder, navigate to xeBuild\17559 and open _retail.ini. Notepad will work fine for this. Using the Console and CB_A from earlier, use Ctrl+F and search for the CB_A you wrote down earlier. In my case, this was 1928. Go through all of the matching strings until you get to one that matches your console. In my case, this was Xenon

Copy the first 5 lines starting from [<your_console>bl_<your CB_A>]. Do not copy the cf_17559.bin or lower lines.

In the same file explorer window, go back to the xeBuild folder and go to the kernel you would like to downgrade to. 6717 is Blades. 9199 is NXE. 13604 is Kinect NXE.

For this example, I will be using 6717. Open the folder for the kernel you would like and open _retail.ini. Paste the 5 lines copied from earlier into the file after the version strings. Right below where you pasted the other lines, find the cf_6717 and cg_6717 strings (or whatever kernel version you have) and copy those. Paste them below the ce_1888.bin line and then save the ini file.

Open J-Runner and load your NAND backup again. In the XeBuild box (top right corner) select the kernel version you want to downgrade to, then select Retail. In the CB box, the CB version you added earlier should appear. If it doesn't, ensure the changes you made earlier are correct.

After selecting everything, press the Create XeBuild button. Once XeBuild completes, press Show Working Folder under the Bootloaders and SMC box. You should now see a file explorer window containing important console information, including your updflash.bin file.

Step 3: Restoring a NAND backup

Using the USB drive from earlier, copy the updflash.bin file to the folder containg Simple 360 NAND Flasher. If you turned off or rebooted your console during this process, run Bad Update again. Open Simple 360 NAND Flasher and it should detect the NAND backup that is ready to flash. To ensure you have a functional NAND backup after flashing, press B to dump your NAND and write the new NAND.

Once it is complete, wait for the console to restart. You should now see the console booting into your new dashboard. You will be restricted to any hard drives, games, and accessories that are only supported on that kernel.

If you get 3 red lights, a red dot, or a green light without boot on your console, you might have done something wrong during the process or your CB does not support the kernel you were trying to go to. You will need to reflash your NAND using an external programmer.

Please comment any successful (or unsuccessful) downgrades with your console, kernel, and CB version :)

Yeah.. I think I made that pretty clear in the guide. I don’t get the point of commenting warnings I’ve already put in the guide?

could this be used to patch a modified nand to boot into a modified state?

Sadly no, because the boot chain of the Xbox 360 is still untouched regardless of whether or not you have the CPU key. The wiring for RGH or JTAG, no matter what method you do, is present in order to trick the console into allowing a modified kernel to boot up and bypass all the security checks typically present in the console. Any modifications to the Xbox 360's system kernel (on a stock system) will cause the console to not start, typically resulting in a 0022 secondary error code, which also happens if you try to flash a stock kernel with the wrong CB (regardless of kernel version).

Tested my fixed Halo 3 console with this method, and surprise surprise it gave me an E66 UEM. My theory for this is that the Liteon drive firmwares post XGD3 implementation are coded in a way that 6717 simply doesn't support. This is also why ditching the DVD drive "fixes" the problem, but it may be possible to fix the issue by flashing an old firmware to the DVD drive. Will leave another comment if this is the case.

Update 5/5/25 9:30 AM EST
I have done more testing with my Halo 3 console. For reference, it's a Zephyr C console that was fixed by Miceosoft under warranty, has CB 4569, and has a Lite On drive. I will list below the kernels I have tested and the results I've obtained.

2.0.6717: MOSTLY WORKS. Crashes with an E66 UEM. I flashed the DVD drive with a firmware from before 2.0.13146 released and that fixed the issue. Using another Lite On drive flashed with the modern firmware causes E66, so it seems the solution is to flash an older DVD drive firmware to your drive if you want to use it. Attempting to boot kernels older than this will likely have varying results due to the fact that only the very first Jasper consoles even shipped with Blades (but all phat consoles CAN run the blades dashboard), so keep that in mind if you want to test really old kernels.

2.0.7371: MOSTLY WORKS. Same as 2.0.6717. Today I will confirm if any newer NXE dashboards work, but as of now this is the newest I've been able to run.

2.0.8955: DOES NOT BOOT. You can tell if you patched the correct CB or not by whether or not you get a general hardware failure with the secondary error code of 0022. I may or may not have done this accidentally in testing yesterday. If the CB is correct, the console will simply sit idle but never boot.

2.0.9199: DOES NOT BOOT. Same result as 2.0.8955. Unfortunately, this means that slims with split CBs will never be able to boot retail NXE, so if you want an NXE slim for some reason, it's best to just do RGH 3.0

2.0.13559: DOES NOT BOOT. Same as 2.0.8955 and 2.0.9199

2.0.13604: DOES NOT BOOT. Same result as 2.0.12559.

2.0.15574: Boots flawlessly. Someone else in this thread also had success with this version, and it's worth noting that every kernel after 2.0.14717 uses split CBs, so it's reasonable to assume that every kernel following that version will boot without much of an issue.

I will continue testing and follow up later today or tomorrow.

Update 5/5/25
This time I'm going to try to be organized with my findings. I have tested most of the kernel versions somebody might want to use, since testing all kernels would be a massive pain. All testing was done on the same console, a Zephyr C with a Rhea GPU and a Lite On D2S DVD drive, downgraded from 17559. I had to create a lot of xebuilds for this, none of which will be released because I don't want to make the scammers' jobs easier. Please excuse any repeated information from my last update.

2.0.1888-2.0.2858: I didn't test these at all. 2858 was released in June of 2006, and I assume these won't work with anything other than a Y1 Xenon. If you'd like to build any of these to try and prove my theory wrong, be my guest, but I just don't feel like it.

2.0.4532-2.0.4548: DOES NOT BOOT. I didn't bother testing these because it's known already that these two kernels specifically don't work. Microsoft patched the JTAG exploit by blacklisting these kernels in updated bootloaders, therefore you can't use them.

2.0.4552-2.0.6770: MOSTLY WORKS. Also yes, 2.0.6770 is a real version of the blades dashboard. As I noted previously, all of these kernels will throw an E66 error if you try to boot them on a console with a DVD drive firmware after XGD3's implementation, which happened with the 2.0.13146 update. The easiest solution is to remove the DVD drive, however you can also flash the DVD drive with a pre-XGD3 firmware, and it will actually read games (so long as you flash the correct DVD key, obviously).

2.0.7357-2.0.7371: MOSTLY WORKS. Out of these three dashboards, I only tried 7371, and it was able to boot with the same issues as the Blades kernels. The solution is also the same for these dashboards, I just noted them separately because this is where the NXE dashboards start.

2.0.8498: WORKS. I know, I was surprised too, but I didn't have any issues with booting this dashboard.

2.0.8955-2.0.9199: DOES NOT BOOT. I'll just repeat what I said last time: You can tell if you patched the correct CB or not by whether or not you get a general hardware failure with the secondary error code of 0022. I may or may not have done this accidentally in testing yesterday. If the CB is correct, the console will simply sit idle but never boot.

All Kinect Dashboards: DOES NOT BOOT. I tried every single version, none of them would even try to boot.

2.0.14699-2.0.14717: DOES NOT BOOT. This ultimately disproves my initial theory about sll split CB versions just working on split cb consoles.

2.0.14719-2.0.15572: I didn't test either of these, not sure if they boot or not. Both of them came with CB changes.

2.0.15574: WORKS. I think this might have been where the modern split CBs started, and someone else in this comment section has posted about successfully getting this version running.

2.0.16197-2.0.16203: WORKS (probably). This is where Metro V2 dashboards start, I only tried 2.0.16203 though because it's the last old dashboard that's even slightly worth running, and it worked without any issues.

Hopefully this is a good reference for anybody who's looking to try these old dashboards on their console. All of my tests here should work on a Xenon, Zephyr, Falcon, or Opus console, with Xenons possibly being able to go lower. Jasper/Tonasket consoles can run 2.0.6717 and should be able to run later kernels (if they're listed here as working). If I post another update, it will be test results with slim consoles, but as it stands now, no slim console can boot any kernel lower than 2.0.9199 regardless of CB due to their XCGPU.