Xbox360-Toolz

Zitat

On Tuesday, Microsoft has released an Xbox 360 software update that overwrites the first stage bootloader of the system. Although there have been numerous software updates for Microsoft's gaming console in the past, this is the first one to overwrite the vital boot block. Any failure while updating this will break the Xbox 360 beyond repair. Statistics from other systems have shown that about one in a thousand bootloader updates goes wrong, and unless Microsoft has a novel solution to this problem, this puts tens of thousands of Xboxes at risk.

It seems that this update is being done to fix a vulnerability already known to the Free60 Project. This vulnerability has been successfully exploited to run arbitrary code, and a complete end user compatible hack has been in development for some time and is planned to be released on free60.org shortly. It will allow users to take back control of their Xboxes and run arbitrary code like homebrew applications or Linux right after turning on the console and without the need of a modchip, finally opening up the Xbox 360 to a level of hacking as the original Xbox.

Because of the dangerousness of the update and the homebrew lockout, the Free60 Project advises all Xbox 360 users to not update their systems to the latest software version. The Project website at http://free60.org/ will provide the latest information on this ongoing topic, including the final hack software.

Free60 (www.free60.org) is a project that aims to enable Xbox 360 users to run homebrew applications and operating systems like Linux on their consoles. The effort is headed by Felix Domke and Michael Steil, who have a background in dbox2, Xbox and GameCube hacking, and who have spoken at various conferences about their findings. Two years ago, Free60 released a hack that allowed arbitrary code execution using a game ("King Kong Hack") as well as an adapted version of Linux, but this possibility has been disabled by Microsoft in subsequent updates of the Xbox 360 software.

Felix and Michael have repeatedly argued that game console manufacturers should open up their platforms to Linux and homebrew, similar to what Sony has done with the PlayStation 3.

x-scene

Zitat

So, some quick news:

We kept on working on this idea, and it worked out. pretty well. We use JTAG to program the DMA target addr, and then SMC to trigger the DMA read. The exploit itself is based on the old 4532 exploit.

The magic is how we launch 4532 - there is a "backdoor" for manufacturing since CB 1920. We have been able to restore the newer CD versions for all hardware types.

This means:
- We can boot own code in HV context ~5s after boot, before any video output, right after the kernel runs.
- we need to reflash the flash, and add 3 resistors for the JTAG (no modchip required! but you might want a dual-nand modchip),
- 8498 kills this by updating the bootloader - it blacklists 4532/4548. it also does hw init stuff which might interefere with the jtag hack, we don't know yet.
- we have a proof of concept hack, we will release it SOON (a matter of hours/days, not more - promised.).
- DON'T UPDATE to summer 09. Did i already say this?
- you don't need to know your cpu key. You can update to all BUT summer '09. you don't need a dvdrom.
- It works on all xenon, zephyr, falcon, opus, jasper. Unless you have updated to 849x. Then you're screwed.
______________________________________

- It's possible to recover DVD keys. In fact, no DVD-ROM is required to run the hack, so it's possible to run own code, dump cpu key, decrypt HV, inject key, flash back. Note that I personally don't like games, so I won't be of much help here.
- No, even if you know your CPU key, it's not possible to downgrade back from 8498.
- Right now, the only way to support both gaming and hacking would be a dual-nand modchip, which switches between nand contents. Note that you still couldn't update to 8498, as it likely (haven't tried) doesn't run without R6T3.


you don't need a "jtag adapter". What you need is a way to reprogram the NAND flash. This can be an external programmer, a linux tool (if it already runs), or a yet-to-be-announced project which uses a special southbridge mode (details will be coming soon) with just an LPT port. Or a nand-modchip.
______________________________________
So, some more details:

CB1920 and up allow to boot into any kernel version, including 4532, but only in "mfgbootlauncher" mode, which is used in manufacturing. This mode (also called "zero pairing", because you need to zero out the CB pairing data) has been known before, however, previous to CD1920, it was useless, because you could only boot into 1888, not into 4532. It was *also* useless because you couldn't run a game.

Now, we developed a way that uses JTAG+SMC to write into physical memory at any time. I think the idea came even from this thread. Basically a flash sector will be prepared to contain the exploit buffer and the code we want to run. JTAG will be used to program the DMA target address (the only thing you can't do from SMC), and SMC will be used to kick off the read (remember, SMC code can access the nand controller as well - just not the dma addr.).

SMC will be patched so that it kick off the DMA read right when the kernel is loaded. We are using the "read rtc" command for that, which happens pretty early in the kernel, way before GPU init, for example. It also happens before nand controller init, which is important, as that would overwrite the dma addr again.
______________________________________
I won't comment stuff about what code to run / rebooter questions. This is simply not he place for that, we're talking about the *exploit* here.

Yes, it's the traditional idle-context-stack-overtake vector, like KK used. It's really just the KK exploit converted to be contained in a single sector (plus ecc, for the HV offset overwrite).

Post is 0x6C, iirc. Other threads have already started, yeah. But catching those is FAR more reliable than before, and works almost every time, and takes only a few microseconds.

Remember the code which checks if the pairing data is all-zero, and skips the SMC-checksum/LDV/pairing check then? We're using this codepath. It can be, since 1920, abused to boot into any kernel, because 1920 will also apply (specially patched) updates in this mode. Since it doesn't require pairing, it doesn't require knowing the CPU key, or doing the TA.

However, obtaining a decrypted CD >= 1920 (CB is easy, since it's encrypted only with the 1BL key) is a bit difficult, because you need to know the cpu key, which was a chicken/egg problem. 1920 is relatively easy, since you can TA. 1921 fixed TA, so it's much more difficult. We solved that by diff'ing 1920/1921 CB, and applying those changes to 1921 CD, and fixing alignment etc. until the hash matches. Was some days of boring work, but finally worked out. the other CDs are easy then (just changed version numbers, mostly), except for jasper, which is a totally different story (but we solved that, too).

Once you have CB/CD, you can re-encrypt them, zero the pairing data (CPU key is not used in zero-pair mode, so encryption is like <1920), and prepare a proper update (4532, also zero-paired). Console will boot up, skip the pairing check, apply the 4532, boot into kernel, do basic init, query RTC, get exploited, runs code.

XBH / tmbinc