10 Days Of Hacking, Day 7: The Xbox 360

The Xbox 360 was Microsoft’s second home console, and the first one to be widely acceptable, but there’s probably nothing about its background story that you don’t already know, so lets cut to the point.

Along with the PS3, the Xbox 360 was a really tough machine to hack, but it still fell victim to hackers, specially due to a big time mistake made by Microsoft. Before I get to that, let me show you some important 360 hacks that, while I do not care for them, they are actually pretty cool.

If we have learned something from previous consoles is that there are a few different ways of hacking that can be applied to almost all of them: tricking the BIOS or OS into either ignoring the security or thinking it has passed, tricking the reader into telling the BIOS/OS that the security measures have been met, tricking a legit game into loading our own code, and many other.

The 360 is no strange from at least a few of these options, and I’m gonna do a quick sum up of some of interesting hacks before I get to my main one.


For consoles with optical discs, the disc reader is an essential and important sector in preventing piracy and unlicensed games. It’s simple: the game disc has something special that no other disc has and the laser drive is customized to be able to tell this difference, essentially letting the underlying BIOS or OS know if the disc is legit or not. Hardware makers can use special and closed machinery to craft game discs in a way that allows the system to differentiate them from standard discs and drives, and since this information is usually closed and the hardware/process involved in creating the discs is strictly locked behind doors, it is almost impossible for outsiders to replicate the structure a legit game disc has to be able to bypass the protection.

So we are facing the problem that we cannot craft our own discs to be just like legit ones, we have two options at this point if we want to achieve disc-based hacks: either we hack the drive so that it ignores the disc protection and always tells the system that it’s booting a licensed game, or we hack the system itself so it ignores the disc drive telling it that the disc is not legit, in either way, we should end up with the system being fooled one way or the other.

On most older systems this had to be done on the system itself due to the fact that the disc drive controller was on the same motherboard as the rest of the system, where the BIOS/OS is, but there were a few exceptions like the Dreamcast or the GameCube, which had separate motherboards for the system and the disc drive. In the case of the Dreamcast there was no need to hack any of them as another, better, software-based hack was found, in the case of the GameCube there were mostly modchips to fool the system itself, until Xeno-GC came out, which was a great piece of hardware hack: it had a very easy installation process and allowed for the same functionality as any other BIOS modchip. Why am I talking about GameCube hacks in a 360 hacking page? well aside from filler, it is needed to understand one of the first 360 hacks. This GameCube hack falls into the category of a hack that forces the disc drive to ignore the protection on the disc and send the “incorrect” signal to the system that the disc was “ok” to boot, when in reality we were booting a completely unlicensed game.

Now we understand these hacks work and that some 6th gen system separated main system board from disc drive board, essentially giving us the opportunity to choose which one of those to hack, but modern machines have an extra layer of security. In modern systems, specially the PS3 and 360, we have a hybrid combination at hand. We certainly don’t have one motherboard for both system and disc drive, but the two motherboard we have are tied together so that you can’t easily separate them without the system complaining. This is called married boards.

The way married boards work is simple: the motherboard has a special key that is unique to each system, and the disc drive board has the same exact key stored in it. So you have the same key but in two different places, at this point you can guess that the system simply compares them. So, we have the added extra security of not being able to replace the disc drive, at least not the motherboard, which is just there to annoy people.

So how can we come up with a hack on the disc drive? simple: connect it to your PC.
They didn’t even bother making their own proprietary ports for the 360, they use standalone SATA ports that every other PC disc drive uses, and there’s something we know about PC’s disc drives: we can flash the firmware.
Thanks Microsoft, you pretty much allow us to connect the 360 disc drive on our PC and lets us flash it, awesome job!

Ok we have covered this hack, but there’s another one that I will just merely point it out.

Much like with the new PS3 ODE, the Xbox 360 has gotten a special type of modchip. This modchip takes control of the connections between the system and the disc drive, inhibiting some of the features of the disc drive and replacing it with its own. This modchip essentially emulates the disc drive and allows you to mount ISO games and maybe some homebrews.
This modchip doesn’t require any soldering and does its job well, but I won’t talk much about it as I do not consider it to be either a clever hack nor a stupid mistake.

Joint Test Action Group

JTAG was a group formed in 1985, before then it was really complicated to test whether complex circuits were functioning correctly once assembled completely. It was common to find solder points not well connected, or ones that shouldn’t be connected at all, faulty units, or other problems that could lead to device malfunction, in some cases these could be just one out of a thousand, in some cases it could be a common problem due to a bug in either the development of the circuit or its manufacturing, but all having something in common: it was hard to debug.

JTAG sought to change this by creating an industry standard for debugging and fixing critical parts of the system, ensuring the completed device was functional and operational once completely manufactured and allows the device maker to easily track down problems that could affect too many units.

On modern systems the JTAG port is used for software debugging, CPU debugging, and most importantly, to flash to NAND and other writable devices.
These JTAG ports are of course available in most, if not all, modern systems, and they would give us almost complete control over the device, or at least give us critical information about the device itself.
One of the many features of JTAG, as I mentioned, is the ability to write to NAND flash and/or other internal writable media. If we can gain access to where the system OS is located, we can attempt to modify it, thus being able to achieve another type of hack: fooling the system into ignoring the disc drive’s warning that the game is legit, or simply fooling the system into booting our own code located away from the disc drive.
But can we do this with JTAG? long answer: NO, JTAG ports are usually only used in the factory and are disabled completely by the manufacturer when the device is ready to be sent to the shelves, specially if your device is as close as gaming devices are. Short answer: THEY FORGOT TO DISABLE THE JTAG PORT!

I never, ever, ever thought a company would be so stupid to do this, they have a port in their console that allows them, and pretty much anyone, to mess around with the internals of the console, a port that is normally used for debugging and writing the firmware, and they keep this port enable for everyone to mess around with!

This hack, if we can even call it a hack, it’s a mayor design flaw, is the main reason I decided to talk about the Xbox 360, as I consider it to be a mayor f*ck up on behalf of Microsoft that should have never happened had they decided to put some brains into what they were doing, but hey, Sony’s no different! don’t miss the next episode where I will talk about numbers and what Sony defines as “random”.

  1. Shapeshifter’s avatar

    Typed my email wrong damn it my profile looks different


  2. Shapeshifter’s avatar

    Don’t delete my comments pls


    1. BigBlackDildo’s avatar



      1. WTFIsThatName^’s avatar

        Why would we delete a common tradition here at wololo by us for us?


    2. Shapesh1tt3r’s avatar



      1. shapeshifter0100’s avatar

        F*** off troll get a life and use ur own game name u dumbass


  3. VinsCool’s avatar

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


    1. fate6’s avatar

      Lets not forget R-JTAG :3


    2. APRON-MAN’s avatar

      or could of talked a bit more about the homebrews and not piracy


  4. Netrix’s avatar

    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. BigBlackDildo’s avatar

    I Like Big Black Dildos!


  6. Acid_Snake’s avatar

    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.


    1. NoSpam’s avatar

      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.


      1. Frezzno’s avatar

        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.


  7. anhell28’s avatar

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


  8. warfaren’s avatar

    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.


  9. Thrawn’s avatar

    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.


  10. Nonlin’s avatar

    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.


  11. VC’s avatar

    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.


    1. Some1Else’s avatar

      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?


      1. VC’s avatar

        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.


        1. VC’s avatar

          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.


  12. sav’s avatar

    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.


  13. Tnutbutter’s avatar

    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.


  14. shootermcgavin’s avatar

    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?


  15. noname’s avatar

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



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>