10 Days Of Hacking, Day 7: The Xbox 360

Acid_Snake

I like beer.

You may also like...

28 Responses

  1. Shapeshifter says:

    Typed my email wrong damn it my profile looks different

  2. Shapeshifter says:

    1st
    Don’t delete my comments pls

  3. VinsCool says:

    You forgot to talk about the glitch hack, or RGH, wich was an advanced step forward in xbox 360 hacking.

  4. Netrix says:

    Is there no security for the X360 OS itself, such as encryption, signature checking, etc.? Of course being able to write to the NAND with JTAG is great, but was it as easy as just replacing some files to bypass the security checks?

  5. Acid_Snake says:

    Ok people let me be clear about this article: I do NOT own a 360 and I do NOT follow the 360 scene closely. I had to write this article based on the very little technical information I could find and my own personal knowledge, please don’t remind me that I missed “this” hack or “that” hack, cause I know I did, there’s only so much I can talk about a console I don’t know very well and there really isn’t that need to talk about every hack out there to get to my point.

    • NoSpam says:

      This article was very disappointing, not from the technical side but because of your enthusiasm. The whole tone is pretty much:
      “I’m only writing this because I have to. People hacked it, lets move on. May as well take a few jabs at Microsoft while I’m here.”

      On the technical side you never mentioned what the hacks allow users to do. Yes, we know it allows people to play fake DVDs but did you know there’s also older model 360’s running different operating systems (and running off completely different hacks)? It probably would have been better to start with the original XBox before doing the 360, not only is it more developed but some of the techniques carried over to the 360 such as fooling the drive (HD in the Xbox’s case).

      Personally I feel this article is a major letdown and one of your worse, I expect better quality from you and you didn’t deliver. Your attitude sucked everything else I can forgive.

      • Frezzno says:

        I kind of agree here with classic xbox. I still have my 007 game and xbox in my closet. Softmod hack with game exploit, same with psp 3000. You mentioned some of the hacks and it’s open for interested to research the rest. Critisism is good, gives you hair on the chest, or removes it.But hey Acid_Snake a score of 6 out of 7 is outstanding. And that not counting earlier articles by you. You can’t feed all the hungry people. When some likes apples and others likes bananas then we totally forget about the small group that wants something totally different like peanuts. Keep up the good work. Still 3 days to go.

  6. anhell28 says:

    im actually selling my xbox360 jtag…i got a bunch of emu’s and stuff on there already.

  7. warfaren says:

    Actually, a few things are wrong about JTAG here and it really requires a more in depth explanation. First of the NAND reading/writing isn’t done via the JTAG port at all. The JTAG port invovled in this hack is the GPU JTAG port. This port gets disabled very early in the boot chain via software, and the hack is quickly performed before that happens. What essentially is done is that the SMC (system management controller) of the 360 (it’s a chip on the mainboard, kinda similar to a BIOS as I understand it) has its firmware loaded from a part of the NAND of the 360. This firmware is altered to make the SMC send instructions into the GPU JTAG port (thus eliminating the need for an additional modchip, since we already have a chip in the machine we can control). As I understand, a bridge is soldered between the SMC and the GPU JTAG port to allow signals to go this way.

    Anyway, I’m by no means an expert on this subject so don’t take my words for definite fact. I just happen to have read alot about this hack so I believe my description of the JTAG hack should be closer to reality.

  8. Thrawn says:

    Oh yeah the gamecube modchips. @Acid_Snake, you should do an article series about modchips, as there are truely amazing pecies of hardware developed just for tricking devices. For example the viper extreme for the gamecube, the king class of modchips with bios selection and usb injection. Or the matrix infinity and its clones, qoob, xeno gc, aladdin, cobra ode, 3key, Xkey, duox, smartxx, wasabi360, wiikey, wode, sundriver (my favorite), those trillion baziilion sunkey wasp fusion & clones… even the undiluted platinum, the nds flash carts, supercard for gba and gbc and gb (they are esentially mod chips), ultra 64, everdrive, game genie (oh we had that one :).
    AND 100% of the time hardware solutions preceed software hacks, software hacks are born out of hardware solutions. The first real thing we will see for the vita, will be a custom game cartridge. Hey Yifan_Lu if you read this, you will want to go after the SCEI 1148KM458 or also 1144KM427 which is the security/controller for the psvita game cartridges.

  9. Nonlin says:

    I think they wanted to get hack. You can sell more consoles if people can bootleg your games because A. Buy a console you can bootleg games from and B. Ban their live accounts making them buy another console.

    Its a win in there book. Let them hack, so you can ban, so they can buy more, so you can ban… until the user learns from their mistake and stop playing online.

    Just my opinion.

  10. VC says:

    Here’s a much better run-down of the Xbox 360 scene.

    First, the Xbox 360 was hacked through two different exploit vectors at the same time originally. The DVD-ROM was actually hacked, not for piracy, but to be used to launch the second exploit vector. You see, the game King Kong had unsigned executable shader code, so code only executable from the Xbox 360’s GPU, and this could be used, in conjunction with a small bridging of points between the GPU JTAG port and CPU JTAG port, to take over the system completely by means of overwriting the CPU’s active registers. This allowed for the first running exploit that let us boot Linux on the Xbox 360.

    Following this, as the exploit was patched and the JTAG port effectively disabled, a new exploit vector was required. As the Xbox 360 employed efuses, essentially small fuses that are burned to indicate a value that can be read as a 1 or 0 and are on the CPU’s die so they can’t be altered, it is not possible to downgrade to a firmware that’s bootloader does not match the efuse burning pattern. This effectively stopped people from being able to downgrade the console. As such, as a new exploit was needed, a new flaw in how the new bootloader disabled the GPU JTAG and CPU JTAG ports was found. By using the SMC, or System Management Chip, it was possible to override this function and inject the required code to take over the GPU before it even had a chance to turn off the JTAG port. From there, the first exploit is re-launched and the CPU is taken over, all before the bootloader can shut down the JTAG port. Next, as this causes the GPU to become unusably unstable, a soft-reboot of the system is applied, which powers down the GPU and then restarts the GPU, followed by soft-rebooting the CPU and running patched bootloaders within the CPU that have the security bits turned off or patched out. From here, the system boots up to a patched kernel and hypervisor, and is then stable and also able to run homebrew.

    This was, of course, patched as well, and until August of 2011, no new hacks were released for the console besides continuing to crack the DVD-ROM security for the playback of backup disks.

    In August of 2011, a new exploit vector surfaced. With knowledge of the previous hacks, a team most notably comprised of GliGli, a yet mostly unknown hacker, and a few other significant members of the Xbox Linux project, the Reset Glitch Hack emerged. This hack exploited a flaw in the CPU’s thread management code, and this code is part of the 1bl, or First Bootloader. As the 1bl is stored in ROM on the CPU’s die, it is an unpatchable exploit.

    The exploit works like this. First, the CPU is put into the lowest possible clock speed that will still let it run signed code. This is made possible by abusing the second system management chip on the console, known as the HANA, which also handles scaling the image from the GPU for sending over the HDMI port and analog ports. This chip was introduced in the second model Xbox 360’s, known as the Zephyr motherboard series, and exists in every motherboard model since. The original Xbox 360, the one lacking an HDMI port, had a similar chip known as the ANA, and it is not vulnerable to the same hacking methods originally created for the reset glitch hack. This is because, as there is no CPU control on the console via the HANA chip, the CPU is always set at the maximum clock speed, and no software is there to allow for it to be altered. Although the hack is still possible by pulling the CPU down with direct hardware, when attempting to re-assert the full speed, the CPU doesn’t know how to respond and it results in a full crash. Though this was remedied by the R-JTAG exploit, which combines both of the exploits into a hybird, this is still a problem with the Xenon boards and limits them from using the original RGH code.

    Next, as this glitch is not always perfect and can fail, the SMC’s code is modified, as it is not signed and can be modified on the NAND of the console without any knowledge of the console’s private keys. From here, the code that would normally make the Xbox 360 shut down after 3 attempts to boot is patched out, allowing for the console to have as many tries as is necessary to achieve the exploit. This leads to the actual hack.

    For the RGH1, the first released version of the RGH, the console starts up the 1bl from the CPU’s ROM, the 1bl starts the 2bl from NAND, which is original and unmodified, and the 2bl (also known as CB) then starts up the 4bl (also known as CD) which is what is modified. This is where the exploit takes place. The 2bl has a set of code designed to check the 3bl for the correct signature from Microsoft. As the 4bl has been modified, how does it pass? That’s where this hack comes into play. The 2bl’s checking code is vulnerable to the thread-drop exploit, which is what is used here. The Thread-Drop exploit is an exploit where, by using the CPU_RESET test point on the Xbox 360’s motherboard, we can reset the CPU very quickly, thus causing it to drop the thread that performs the hash and RSA checks on the 4bl. By only asserting the reset command the CPU for 200ns, the CPU does not actually reset, and instead just drops the current running active thread. When the thread drops without returning an error, the previous thread perceives this as a successful check, and continues to hand off execution to our modified 4bl. Therefore, we have effectively taken over the entire system without any other software to stand in our way.

    The only problem, is that this only works on consoles that allow this bootloader to run. This is because the 2bl contains the first check for the previously mentioned efuses, and therefore only runs on those consoles that are properly set to use that bootloader. to work around this, it was found that some consoles were repaired by Microsoft that had, in fact, two 2bl’s split to let consoles with NAND chips that had bad blocks within the first 50 blocks of NAND still be able to be used. These are known as CB_a and CB_b, respectively. The problem here, is that Microsoft didn’t actually implement the efuse check until the second of the two part 2bl was run. This let us change our attack vector to the first part of the 2bl, and have it launch a modified part 2 of the 2bl with had those checks patched out, and continued our patched boot chain from there. Though there were some challenges in executing the exploit earlier in the boot chain, which led to hardware revisions on the dev-boards used to execute the exploit, it was an overall success and has been unpatchable up to date. The problem here, is that it is a slow booting process, and the exploit regularly fails to work which causes this effect. As such, a new hybird hack was born, known as R-JTAG. This hack uses a more expensive FPGA, where the others used a relatively inexpensive CPLD to execute the code, as much more precision was required to speed things up and attack the new vector. Basically, as it was proved that the efuse measures could be ignored, older firmwares, and in effect older bootloaders, could be started. This led to the older, JTAG-exploitable bootloaders being started on the hardware via the Thread-drop exploit paired with the multi-part CB to reuse the much more stable GPU JTAG exploit. This is the fruition of the current Xbox 360 hacks and is, as of now, completely unpatchable on any currently released Xbox 360 hardware.

    As for NAND-RW, the SPI port on the SouthBridge is connected directly to the NAND, so reading and writing to the NAND chip is easy to do with very basic CPLD hardware, and even some of the slightly more powerful PIC controllers, though at the cost of performance in reading and writing the NAND.

    Additionally, by piggybacking the NAND chip with external hardware, it became possible to have an unexploited NAND paired with an exploited NAND on the same console, thus allowing for seamless jumping from a homebrew-enabled console to a retail, online capable console all on the same machine. This also allowed for the console to be run as a DevKit through modified binarys run in the same way as the modified retail software.

    In conclusion, thanks to these hacks and the second custom OS loader known as XELL (XEnon Linux Loader), homebrew was able to be made possible on all currently released Xbox 360 console hardware.

    – VC (Gadorach)

    PS. You’re welcome to use this information to update your article, and it would, in fact, be appreciated if you did for the sake of consistency in the articles and truth in this console’s hacking scene.

    • Some1Else says:

      Nice to see info on the R-JTAG hack. Also, do you know how the DGX actually worked? And If i understand correctly that the DGXless method used a MFG zeropair bootloader from a slim, how was it able to work on phats?

      • VC says:

        The DGX, or Dual Glitch X (Xecuter) was essentially a two part glitch. First, to drop the initial check on the efuses and start a cracked 2bl, then to drop the CPU key encryption check using the same method. The accuracy required to do this prompted the need for a more expensive FPGA and generally took at minimum 2 minutes to actually achieve the glitches properly even under ideal circumstances. The RGX, or Regular Glitch X (Xecuter), was basically the same, but because of it’s lack of the second check bring glitched out thanks to it’s signed manufacturers mode, it worked on all consoles through the use of only the RGH2 code. As, essentially, all second stage bootloaders will run on any console hardware if the efuse checks pass and hardware accepts the commands, using this mfg bootloader on every released console was very easy as it had no efuse check. As a mfg mode bootloader, it didn’t expect any efuses to be burned or encryption to be set whatsoever, and therefore bypassed all the checks. It just isn’t allowed to boot normally on a console not flagged for mfg mode, so it took the split bootloader to make it start unhindered. That’s just from memory, like the rest of that though, so it may be slightly off. It should be mostly correct though.

        • VC says:

          Also of note, the DGX exploit was able to be run on every hardware revision, but optimizing it for more than the Trinity and Corona V1-V6 was too much to ask of the team at the time, so those were the only ones released. It’s also believed that the mfg mode bootloaders showed up around the time that they were working on the DGX code, and therefore decided it was a waste of effort to continue work on the other consoles. Original plans were to wait until the Xbox One was released before publicly releasing the mfg bootloaders, but as they were leaked, it was only fitting to make a proper, if premature, release.

          • intel352 says:

            VC, is it possible to completely replace the Xbox 360 os with a linux install on hdd, so that gaming on the system is no longer an option? I’d like to repurpose my Xbox 360, but most discussion I’ve seen has been based around the ability to switch from Linux to a still-functional gaming system, which I don’t need.

            It would be nice to be able to do so without having to rely on any sort of hacks that have to be applied on every boot (rather, hack once, replace OS).

            If you can link to some relevant resources, I’d appreciate it.

  11. sav says:

    360 was no where near as hard to hack as the ps3, far as piracy is concerned.

    360 was hacked for backups in like the first year or so.

  12. Tnutbutter says:

    I wanted to flash my Xbox 360, but it proved more difficult, than I had thought. Taking apart the Xbox 360 was easy, finding where its SATA port was easy, but taking apart my pc was where I completely gave up.

  13. shootermcgavin says:

    These are fairly nice articles, but when these started I was always wondering why there is no “day” for the Dreamcast? It has more homebrew and was hacked before the PS2. Is it cause it was a software hack and not hardware?

  14. noname says:

    Is this 10 days thing cancelled? At least I expected like… 10 parts.

  15. Daniel says:

    Plus you can not write anything to the NAND as you will blow the efuses the only thing you can do is read it unless you insert some modchip to bypass the original NAND which would shorten the life of the console

  16. anonymous says:

    I was hacked need help for revenge will 1 of u plz contact me this is bs and xbox. Won’t even try to help

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>