wraggster
October 13th, 2007, 22:39
via xbox scene (http://www.xbox-scene.com/)
Arnezami started a thread over at XBH to start of development of a 'rebooter' for the Xbox360 with exploitable HV. The goal is to reboot with a modified kernel and HV that will allow unsigned executables. Arnezami already released an initial version of his rebooter, but some work is still required before we can actually run homebrew code:
This thread/post is about the ability to run an(y) unsigned kernel + hypervisor by rebooting.
***Introduction:
Before going to the juicy stuff I will first address these matters:
* How rebooting into an(y) unsigned kernel and hypervisor is done (using a 4532 or 4548 xbox).
* Why it is required to make substantial progress in the development of homebrew applications and software mods.
* How it can be a solution to the dilemma of having to choose between homebrew/linux vs playing new (or live) games.
* What milestones this project has to reach to arrive at the desired results.
I'm also releasing the first version of the rebooter which does most of the rebooting already. :-) That way other hackers can contribute as well and speed up the progress. I've also made a tool to assemble the rebooter file (using your own xbox-specific information) to allow everyone to create his or her own kernel/hv patches and run (and share) them. And that way there are no copyright issues.
I hope my contribution here will kickstart this project and will give all xbox 360 users a good reason not to update to any future version of the dash/kernel (which will most likely kill any hope of homebrew/linux or whatever else can be done besides what MS wants you to do) but instead to consider downgrading your xbox using the timing attack.
***Rebooting:
First off. We are talking about rebooting. Not about booting. And there is a fundamental difference.
I will explain.
When the xbox 360 is turned on the first thing it does is start look in its ROM (also called the first bootloader or 1BL). In the 1BL there is code which the cpu will execute. There is also a public key in it. This is used to check the validity of second bootloader (the CB section in the flash). Because the key is in ROM (and only MS has the private key) and the ROM is inside the cpu casing there is no way to run unsigned code during normal boot.
We can however run unsigned code on the xbox 360. This is done using the KK exploit. And you need kernel version 4532 or 4548 for this. The problem is when doing the KK exploit there is still a signed kernel in memory. And its "non-trivial" to change/patch it on-the-fly and return to it as if nothing was happened.
In order to run an unsigned kernel/hv (which is required to run unsigned software on the xbox 360) you somehow need to replace the current operating system (kernel/hv/dash etc) completely. The best way to do this is to reboot the xbox but while rebooting change some things on-the-fly (eg. turning off xex-signature checks, the functions that blow fuses etc).
In other words: do a soft-reboot.
Doing a soft-reboot (as opposed to a hard-reset/boot which lets the cpu start in the ROM again) allows us to stay in control. That way we can choose how the to-be-booted kernel/hv/dash should look like (and in principle we can also choose which version we want to run, more on that later).
The rebooter I've written so far does this. It loads the CD section into memory and essentially runs it. The tricky part is to make sure the xbox is put into the same state as it was during the normal boot. But much of this has been done now. The current version of the rebooter can now reliably reboot from POST 0x40 to 0x79 (which is the last POST output during normal boot). The xbox also resets the screen output and seems to detect the wireless again.
***Homebrew:
If we are succesfull in (fully) rebooting into an unsigned kernel/hv we can patch the the kernel/hv to allow execution of unsigned xex-es (among many other things). Right now it is already possible to patch the kernel/hv so the moment we can get it to fully boot it should be easy to turn off the bad stuff... Wink
Creating unsigned xex-es probably requires the ability to compress and encrypt self made xex-es. Although the availabilty of libraries (not on retails boxes) might be a harder problem. But I guess these problems were also solved with the xbox1.
Apart from homebrew applications you can also think of mods: how big do you want your hdd to be? Want to change the dashboard appearance? Want to disable dvd-video or game region check? No problem.
But all of that is only possible if you can run an unsigned kernel/hv. And since we cannot boot into one we have to reboot into one.
Keep in mind that in order to run homebrew or linux you have to downgrade to an exploitable kernel. And this requirement is unlikely to change. Upgrading to the upcoming "fall update" is most likely going to disable the ability to run any old kernel version (well thats what we expect MS to do). So its decision time Wink.
***Solution to the Dilemma:
While it may seem like you have to choose between two worlds the ability to run any unsigned kernel/hv may the solution to the problem. ;)
The idea to run a different kernel from the the one on the flash could work like this:
* You start with a dual nand system where both nands have the same kernel/dash version: 4532/4548
* You boot and start the KK game resulting in the exploit.
* You then hot-switch to the other nand. And reboot into the 4532/4548 dash. The hypervisor is patched to fake any efuse blowing (meaning it writes the new contents of the fuses on the nand or somewhere else )
* You upgrade to the latest kernel. Lets assume this will be the fall update and it blows a fuse in the fuserow 2. However since we are running a patched hv the fuses aren't actually blown. But on the second nand (which is now active) the new bootloaders/kernel/dash is written to including the new fuserow 2 value (in the CB).
* The beauty is: you can still boot into 4532/4548 and run homebrew/linux. And you can also reboot into the fall update by starting in 4532/4548 then switching to the second nand and rebooting into the new kernel.
* Apart from a tiny patch deep inside the hypervisor (which fakes the fuse blowing) there is no way to tell (for an executable coming from live or a new game) that the xbox is running in "unsigned mode". In fact (and this is the kicker) the hv protection system is working for us now Grin. MS can't detect what we're doing because of their own protection system. Talk about irony...
Keep in mind this is still theory.
Of course a dual nand system still requires soldering. But maybe the above is also possible by using a memory card to store the new kernel/dash etc. This is much harder to make stealthier though so live is not really an option. But new games probably are Wink.
***Project phases:
I guess the project can be divided into several phases given the above:
* Phase 1: Rebooting into an unsigned kernel. Making sure no patches are needed to the kernel/hv to simply boot. Main goal is to basicly restore the xbox 360 into the state it was during boot. Also making it possible to restart from CB or even 1BL so if CB changes in any of the new updates we can run it. This would require a "recursive" patcher though.
* Phase 2: Disable all security measures in the 4532/4548 kernel. The ability to run unsigned xex-es (also being able to encrypt them). Basicly removing all the "bad" stuff and paving the way for homebrew. Also being able to disable fuse blowing functions.
* Phase 3: Hotswapping the nand (best software triggered). Fake fuse blowing by storing the new values somewhere (a place a xex can't access, maybe in the kv). Being able to upgrade and dual boot using the rebooter. Making it stealthy by cleaning up all traces.
* Phase 4: Doing the same as in phase 3 but using a mem card or harddrive as storage device (or for example the flash on the hd-dvd drive).
***The rebooter:
And finally the juicy stuff. Go here to try out (and help testing/developing) the rebooter itself:
http://www.xboxhacker.net/index.php?topic=8737.0
Arnezami started a thread over at XBH to start of development of a 'rebooter' for the Xbox360 with exploitable HV. The goal is to reboot with a modified kernel and HV that will allow unsigned executables. Arnezami already released an initial version of his rebooter, but some work is still required before we can actually run homebrew code:
This thread/post is about the ability to run an(y) unsigned kernel + hypervisor by rebooting.
***Introduction:
Before going to the juicy stuff I will first address these matters:
* How rebooting into an(y) unsigned kernel and hypervisor is done (using a 4532 or 4548 xbox).
* Why it is required to make substantial progress in the development of homebrew applications and software mods.
* How it can be a solution to the dilemma of having to choose between homebrew/linux vs playing new (or live) games.
* What milestones this project has to reach to arrive at the desired results.
I'm also releasing the first version of the rebooter which does most of the rebooting already. :-) That way other hackers can contribute as well and speed up the progress. I've also made a tool to assemble the rebooter file (using your own xbox-specific information) to allow everyone to create his or her own kernel/hv patches and run (and share) them. And that way there are no copyright issues.
I hope my contribution here will kickstart this project and will give all xbox 360 users a good reason not to update to any future version of the dash/kernel (which will most likely kill any hope of homebrew/linux or whatever else can be done besides what MS wants you to do) but instead to consider downgrading your xbox using the timing attack.
***Rebooting:
First off. We are talking about rebooting. Not about booting. And there is a fundamental difference.
I will explain.
When the xbox 360 is turned on the first thing it does is start look in its ROM (also called the first bootloader or 1BL). In the 1BL there is code which the cpu will execute. There is also a public key in it. This is used to check the validity of second bootloader (the CB section in the flash). Because the key is in ROM (and only MS has the private key) and the ROM is inside the cpu casing there is no way to run unsigned code during normal boot.
We can however run unsigned code on the xbox 360. This is done using the KK exploit. And you need kernel version 4532 or 4548 for this. The problem is when doing the KK exploit there is still a signed kernel in memory. And its "non-trivial" to change/patch it on-the-fly and return to it as if nothing was happened.
In order to run an unsigned kernel/hv (which is required to run unsigned software on the xbox 360) you somehow need to replace the current operating system (kernel/hv/dash etc) completely. The best way to do this is to reboot the xbox but while rebooting change some things on-the-fly (eg. turning off xex-signature checks, the functions that blow fuses etc).
In other words: do a soft-reboot.
Doing a soft-reboot (as opposed to a hard-reset/boot which lets the cpu start in the ROM again) allows us to stay in control. That way we can choose how the to-be-booted kernel/hv/dash should look like (and in principle we can also choose which version we want to run, more on that later).
The rebooter I've written so far does this. It loads the CD section into memory and essentially runs it. The tricky part is to make sure the xbox is put into the same state as it was during the normal boot. But much of this has been done now. The current version of the rebooter can now reliably reboot from POST 0x40 to 0x79 (which is the last POST output during normal boot). The xbox also resets the screen output and seems to detect the wireless again.
***Homebrew:
If we are succesfull in (fully) rebooting into an unsigned kernel/hv we can patch the the kernel/hv to allow execution of unsigned xex-es (among many other things). Right now it is already possible to patch the kernel/hv so the moment we can get it to fully boot it should be easy to turn off the bad stuff... Wink
Creating unsigned xex-es probably requires the ability to compress and encrypt self made xex-es. Although the availabilty of libraries (not on retails boxes) might be a harder problem. But I guess these problems were also solved with the xbox1.
Apart from homebrew applications you can also think of mods: how big do you want your hdd to be? Want to change the dashboard appearance? Want to disable dvd-video or game region check? No problem.
But all of that is only possible if you can run an unsigned kernel/hv. And since we cannot boot into one we have to reboot into one.
Keep in mind that in order to run homebrew or linux you have to downgrade to an exploitable kernel. And this requirement is unlikely to change. Upgrading to the upcoming "fall update" is most likely going to disable the ability to run any old kernel version (well thats what we expect MS to do). So its decision time Wink.
***Solution to the Dilemma:
While it may seem like you have to choose between two worlds the ability to run any unsigned kernel/hv may the solution to the problem. ;)
The idea to run a different kernel from the the one on the flash could work like this:
* You start with a dual nand system where both nands have the same kernel/dash version: 4532/4548
* You boot and start the KK game resulting in the exploit.
* You then hot-switch to the other nand. And reboot into the 4532/4548 dash. The hypervisor is patched to fake any efuse blowing (meaning it writes the new contents of the fuses on the nand or somewhere else )
* You upgrade to the latest kernel. Lets assume this will be the fall update and it blows a fuse in the fuserow 2. However since we are running a patched hv the fuses aren't actually blown. But on the second nand (which is now active) the new bootloaders/kernel/dash is written to including the new fuserow 2 value (in the CB).
* The beauty is: you can still boot into 4532/4548 and run homebrew/linux. And you can also reboot into the fall update by starting in 4532/4548 then switching to the second nand and rebooting into the new kernel.
* Apart from a tiny patch deep inside the hypervisor (which fakes the fuse blowing) there is no way to tell (for an executable coming from live or a new game) that the xbox is running in "unsigned mode". In fact (and this is the kicker) the hv protection system is working for us now Grin. MS can't detect what we're doing because of their own protection system. Talk about irony...
Keep in mind this is still theory.
Of course a dual nand system still requires soldering. But maybe the above is also possible by using a memory card to store the new kernel/dash etc. This is much harder to make stealthier though so live is not really an option. But new games probably are Wink.
***Project phases:
I guess the project can be divided into several phases given the above:
* Phase 1: Rebooting into an unsigned kernel. Making sure no patches are needed to the kernel/hv to simply boot. Main goal is to basicly restore the xbox 360 into the state it was during boot. Also making it possible to restart from CB or even 1BL so if CB changes in any of the new updates we can run it. This would require a "recursive" patcher though.
* Phase 2: Disable all security measures in the 4532/4548 kernel. The ability to run unsigned xex-es (also being able to encrypt them). Basicly removing all the "bad" stuff and paving the way for homebrew. Also being able to disable fuse blowing functions.
* Phase 3: Hotswapping the nand (best software triggered). Fake fuse blowing by storing the new values somewhere (a place a xex can't access, maybe in the kv). Being able to upgrade and dual boot using the rebooter. Making it stealthy by cleaning up all traces.
* Phase 4: Doing the same as in phase 3 but using a mem card or harddrive as storage device (or for example the flash on the hd-dvd drive).
***The rebooter:
And finally the juicy stuff. Go here to try out (and help testing/developing) the rebooter itself:
http://www.xboxhacker.net/index.php?topic=8737.0