Discovery: Boot Xbox360 from 1888 Kernel - Downgrade Kernel Options

[Xbox-Scene]

Discovery: Boot Xbox360 from 1888 Kernel - Downgrade Kernel Posted by XanTium | January 13 00:45 EST

Robinsod over at the XBH forums probably found a way to boot his Xbox360 with the original 1888 kernel ('BK' kernel). The onboard flash of the Xbox360 contains the full original kernel (v2.0.1888.0, which is the first public kernel release) and patches (this is what MS adds when they release new kernel updates) to update the kernel to the latest build (currently at v2.0.4552.0). Apparently the systems scans for version numbers in the headers of kernel patches and then selects what to load, by deleting (null) the (non-encrypted) headers (esp. version numbers) of the patches Robinsod probably managed to get his Xbox360 to boot the original 1888 kernel (v2.0.1888.0). While the Xbox360 software (system>console settings>system info) reports being in 1888 kernel it has yet to be tested if it really is booting only the 1888 kernel without patches (looking at the dashboard features is no option ... the dashboard and kernel are not the same, the dashboard stays as it is). [QUOTE] I have now successfully mounted my HYNIX flash in a socket and developed code to read, erase and reflash areas of that flash. I have also been sniffing the flash bus during the 360's power on sequence. I believe my 360 was last updated from the NFS:Carbon game disk. The Kernel and Dash versions are reported as: D 2.0.2868.0, K 2.0.2868.0, BK 2.0.1888.0 The read sequence I observed agrees broadly with that posted on free60 and when "condensed" it looks like this: Power On: Reads 0x000000 - 0x0001FF Reads 0x008000 - 0x00E1FF ---"CB" Reads 0x000000 - 0x0001FF Reads 0x001000 - 0x003FFF Reads 0x00C000 - 0x00C1FF Reads 0x00E000 - 0x0699FF Reads 0x06C000 - 0x06C1FF ---"CF" Reads 0x07C000 - 0x07C1FF ---"CF" As per free60.org upto here Reads 0x06C000 - 0x07BFF0 ---"CF" My log differs from free60.org from here Notice how the 360 reads the first 0x200 bytes of the blocks marked "CF" and then selects one to read completely. This suggests that the 360 is reading the version numbers of kernel patches and selecting the most recent. In this case the patch at 0x06C000 is read. To test the theory I erased: 1) 16KB block of Flash at 0x06C000, result: D 2.0.2858.0, K 2.0.2858.0, BK 2.0.1888.0 2) 16KB block of Flash at 0x06C000 and 0x07C000, result: K 2.0.1888.0 3) Inserted the NFS:C disk and reapplied the 2.0.2868.0 update, result: D 2.0.2868.0, K 2.0.2868.0, BK 2.0.1888.0 So now I need to find a suitable test software to verify that the console really is downgraded to 2.0.1888.0. The kiosk disk perhaps... [/QUOTE] Interesting reply from TheSpecialist: [QUOTE] I'd like to toss in my theory about the 'patches'. There are 2 questions here: 1. Why does MS upgrade via 'patches' and not just by sending the whole files and 2. Why don't they just patch the files in flash, but instead, keep the original files + patches in flash? There are various good answers to question one, but I think the best answer is that it has to do with the limited space. Now, it is very easy to roll back the kernel: they always keep the original file, so they can hold various kernel versions in the Flash, because the patches are relatively small. If they wouldn't use patches, but complete files, then they wouldn't probably have space enough for 2 kernels ! About the answer to question 2 I am pretty sure: they simply can NOT patch the exe files themselves on the flash ! Because doing so, would break the signature, so they would need to resign the files and MS is not going to send us the private key to do so ;) Besides, another reason would be that rolling back would be more difficult. So, to conclude, the filesystem always contains the V1.0 version of the files (well: 2.0.1888.0 November 22, 2005 Original shipped version), plus the patches. The 360 scans for the latest patch, loads both the original exe and the latest patch, checks BOTH files for their signature (at least, that is what i EXPECT) and then creates the new, 'patched' exe in its memory. [/QUOTE] Note that right now, booting up with the 1888 kernel doesn't bring any real advantages (except maybe booting the kiosk disc from recordable media), but it might come in handy later. Full Story/News-Source: xboxhacker.net (hacking discussions ONLY! - thx)

[rasputin69]

I wonder could this help people who have had bad flashes that give errors. The system is still booting, but the flash did not go well. Who knows.

[ILLusions0fGrander]

Note that right now, booting up with the 1888 kernel doesn't bring any real advantages (except maybe booting the kiosk disc from recordable media), but it might come in handy later.

thats what i found pretty cool.

if there was a flaw from day one... it can now be exploited.

[Tobb555]

This is a awsome find but isnt it this kinda a pain in the arse for the normal joe to do. I sure I dont have the skills for this.

[1337 pig]

I saw this eailer today, didnt understand much of thier technical talk but i knew it was another step.

[poncinator]

Hope

[gaming fanboy]

thats what i found pretty cool.

if there was a flaw from day one... it can now be exploited.

i agwee

This is a awsome find but isnt it this kinda a pain in the arse for the normal joe to do. I sure I dont have the skills for this.

true true

Hope

THEY'RE GETTING SOMEWHERE!!!

[Casper1786]

now i'm curious if the new/newer/after launch machines carry a later kernal then launchday or are they preloading launch kernals with latest patches to the flashes? cause unless XBL guys are making "pre-patched" kernals and seperate patch versions for these then it's probable that we all have the same "base kernal"

[appleguru]

now i'm curious if the new/newer/after launch machines carry a later kernal then launchday or are they preloading launch kernals with latest patches to the flashes? cause unless XBL guys are making "pre-patched" kernals and seperate patch versions for these then it's probable that we all have the same "base kernal"

As of now anyways, we all do.

[SwattiMatti]

[NFN_NLN]

I'm always paranoid about taking updates because I know that if they do find an exploit chances are it'll be for an early kernel version. As I understand it this kernel + patch model is a fundamental architecture that can't safely change so we'll always be able to downgrade (assuming you have the balls to pull out your flash memory and reprogram it).
Here's to hoping a number of those patches were to plug up security holes and not just feature enhancements.

[GARRYB]

so does this mean we will soon be running linux on 360 if yes wow u just made my day.

[sicknasty413]

so does this mean we will soon be running linux on 360 if yes wow u just made my day.

soon? doubt it.

Good news though!

[Murc]

smells like progress.

But I'm sure a linux type of interface is still a long while off yet.

I have a question, way out of the left field that has nothing at all to do with this topic....Can people (me) put a custom picture on their 360 for their gamertag pic???

This post has been edited by Murc: Jan 13 2007, 08:35 AM

[signal-to-noise-ratio]

While the Xbox360 software (system>console settings>system info) reports being in 1888 kernel it has yet to be tested if it really is booting only the 1888 kernel without patches (looking at the dashboard features is no option ... the dashboard and kernel are not the same, the dashboard stays as it is).

If the kiosk disc does boot doesnt that prove it has reverted back to the 1888 kernel without patches otherwise the disc wouldnt boot.