Xbox 360 Reset Glitch Exploit Discussion

Discussion in 'Gaming Hangout' started by Corona, Aug 28, 2011.

  1. Corona

    Corona Addict

    Joined:
    Sep 1, 2010
    Messages:
    576
    Likes Received:
    169
    [​IMG]

    The french developer and hacker, GliGli, is proud to release via XboxHacker forums, what most of us are waiting for since more than one year: a new exploit for the Xbox 360. This new Hack is called "Reset Glitch Hack" and needs the installation of a chip. The Reset Glitch Hack is compatible with most 360 models: all the Xbox Slims models and for FAT, Zephyr and Jasper are working for now (Falcon will be released when the devs will have one at hand)

    To explain it (very) simply, the chip sends little pulses to the processor in order to distabilize the console and make it believe a modified CB is correctly hashed and signed. This operation doesn't succeed every time, but it is repeated till it works. Once the modified/hacked CB is validated by the console, it has enough rights to launch unsigned code and in our case, XeLL, the Xenon Linux Loader. For full details, read GliGli's explanation of his hack, you can also have a look at the source code of Hack available HERE.


    Advantages of this hack:
    - It's unpatchable, in fact the CB is involved so early in the console boot process that it can't be revoked.
    - All the 360 expect the Xenons will be compatible.

    Drawbacks:
    - A chip is needed.
    - The boot time varies and it can take up to a few minutes to run unsigned code.

    Full explanation:


    Quote:
    ***************************************
    * The Xbox 360 reset glitch hack *
    ***************************************

    Introduction / some important facts
    ===================================

    tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.

    The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).

    CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
    - A hash of the entire fuseset.
    - The timebase counter value.
    - A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.

    CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.

    Basically, CD will load a base kernel from NAND, patch it and run it.

    That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code.
    In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code.
    On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them.
    The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.

    On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".

    Glitching here is basically the process of triggering processor bugs by electronical means.

    This is the way we used to be able to run unsigned code.

    The reset glitch in a few words
    =======================

    We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.

    Details for the fat hack
    =================

    On fats, the bootloader we glitch is CB, so we can run the CD we want.

    cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.

    So it goes like that:
    - We assert CPU_PLL_BYPASS around POST code 36 (hex).
    - We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
    - When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
    - We wait some time and then we deassert CPU_PLL_BYPASS.
    - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.

    The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
    A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly.
    In most cases, the glitch succeeds in less than 30 seconds from power on that way.

    Details for the slim hack
    ==================

    The bootloader we glitch is CB_A, so we can run the CB_B we want.

    On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
    Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
    We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
    Apparently those registers are written by the SMC through an I2C bus.
    I2C bus can be freely accessed, it's even available on a header (J2C3).
    So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus

    So it goes like that:
    - We send an i2c command to the HANA to slow down the CPU at POST code D8 .
    - We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
    - When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
    - We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
    - The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.

    When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
    - Always activate zero-paired mode, so that we can use a modified SMC image.
    - Don't decrypt CD, instead expect a plaintext CD in NAND.
    - Don't stop the boot process if CD hash isn't good.

    CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
    RC4 is basically:
    crypted = plaintext xor pseudo-random-keystream
    So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
    guessed-pseudo-random-keystream = crypted xor plaintext
    new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
    You could think there's a chicken and egg problem, how did we get plaintext in the first place?
    Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!

    The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
    The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.

    Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !

    Caveats
    ======

    Nothing is ever perfect, so there are a few caveats to that hack:
    - Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
    - That success rate seems to depend on something like the hash of the modified bootloader we want to run (CD for fats and CB_B for slims).
    - It requires precise and fast hardware to be able to send the reset pulse.

    Our current implementation
    =====================

    We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time.
    We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock)
    The cpld code is written in VHDL.
    We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.

    Conclusion
    ========

    We tried not to include any MS copyrighted code in the released hack tools.
    The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.

    Credits
    =====

    GliGli, Tiros: Reverse engineering and hack development.
    cOz: Reverse engineering, beta testing.
    Razkar, tuxuser: beta testing.
    cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360
    Source :
    Logic-Sunrise : actualités, téléchargements, releases, dossiers et tutoriaux
    http://www.xboxhacker.org

    [video=youtube;JyYdL4L6vwE]https://www.youtube.com/watch?v=JyYdL4L6vwE[/video]
     

    Attached Files:

    Michael_T and kinkywinky like this.
  2. Mr.NightmareTM

    Mr.NightmareTM Addict

    Joined:
    Sep 19, 2010
    Messages:
    344
    Likes Received:
    18
    Location:
    Leeds, West Yorkshire
    I probably won't be exploiting my Xbox 360 since I'm too dumb to know how to wire everything you know? It seems very complicated for someone like me (a dumbass)

    0.0

    Someone please try this or whatever it is. It might work!

    Edit: But then again, Microsoft will take action.
     
  3. InsaneNutter

    InsaneNutter Resident Nutter Staff Member

    Joined:
    Jun 1, 2007
    Messages:
    12,247
    Likes Received:
    3,723
    Location:
    Yorkshire, England
    Hopefully the Xbox 360 homebrew scene will now explode, like what happened in the original Xbox days. Unlike the Jtag hack any console on sale today can be exploited now.

    In comparison by the time the Jtag hack was developed to a point where it was ready to be released, it had been patched for months making obtaining a Jtaggable console not so easily done. Now there is a massive potential audience for Xbox 360 homebrew i hope some great things will happen.
     
    kinkywinky likes this.
  4. Corona

    Corona Addict

    Joined:
    Sep 1, 2010
    Messages:
    576
    Likes Received:
    169
    i think its cool that microsoft cannot fix this only they can if they make new mobo revisions
     
  5. khan1989

    khan1989 Member

    Joined:
    Mar 5, 2011
    Messages:
    5
    Likes Received:
    0
    Have always wanted a Jtag console or the ability to play n64 on my HDTV minus a pc, maybe now it will possible, but at what cost? I am not willing to pay £50+ to be able to use linux.

    Kudos to the creator though, if it works as well as shown il be more than happy to donate to the guy.
     
  6. lem_is_cool

    lem_is_cool Resident

    Joined:
    Jun 21, 2010
    Messages:
    135
    Likes Received:
    9
    Location:
    Geelong, Australia
    The process right now is a little over my head, and I'm also quite invested in live so I'd probably only do it if its invisible to microsoft.
    Although, xbox's are getting real cheap, a second unit isn't out of the question.
     
  7. seanpr92

    seanpr92 Godlike

    Joined:
    Oct 12, 2010
    Messages:
    1,159
    Likes Received:
    195
    Location:
    Nottingham, United Kingdom
    reckon they willbe able to detect this lol
     
  8. InsaneNutter

    InsaneNutter Resident Nutter Staff Member

    Joined:
    Jun 1, 2007
    Messages:
    12,247
    Likes Received:
    3,723
    Location:
    Yorkshire, England
    If this exploit can really not be patched by any update, it would be possible to have one console that can both be used both on Xbox Live and offline for homebrew.

    In the Xbox 1 days we had modchips with a hacked bios on that could boot homebrew with the modchip enabled, then when you disabled the modchip it booted the stock bios on the console and was safe to use on Xbox Live.

    If this can not be patched on the 360 a modchip could be produced capable of running this hack, and that also contains an additional nand. So you could then enable the modchip and run homebrew, then disable it and play on live.

    Of course if you try to connect to live running the hacked kernel / dashboard you will be banned, just like in the Xbox 1 days.

    What ever way you look at it this hack is not going to allow mass cheating on live, however it has the potential to allow people to have the best of both worlds, homebrew and live on one console.
     
  9. Mr.NightmareTM

    Mr.NightmareTM Addict

    Joined:
    Sep 19, 2010
    Messages:
    344
    Likes Received:
    18
    Location:
    Leeds, West Yorkshire
    Why can't it be as simple as signing an update which allows unsigned code to run, is it really that hard to obtain signing keys? I'm not interested in opening my console.
     
  10. MasterChief

    MasterChief Addict

    Joined:
    Sep 17, 2009
    Messages:
    743
    Likes Received:
    89
    Location:
    The Internet
    Basically yes, Sony well and truly messed up with the PS3. The keys should never have been able to be calculated by using an algorithm. Not only that but the PSP keys were also discovered in the PS3 :\ I dont think that has ever happened with any other console to date.

    For any permanent sort of hack the console needs to be atacked as early as possible in the boot up sequence, which is basically what the Reset Glitch and the Jtag hack do.
     
  11. Mr.NightmareTM

    Mr.NightmareTM Addict

    Joined:
    Sep 19, 2010
    Messages:
    344
    Likes Received:
    18
    Location:
    Leeds, West Yorkshire
    With the PS3, I'm sure the actual signing keys were pulled off a drive. This allowed people to resign custom updates etc, the PS3 would then accept the update. It must be possible for the keys to be hacked from the Xbox 360.
     
  12. InsaneNutter

    InsaneNutter Resident Nutter Staff Member

    Joined:
    Jun 1, 2007
    Messages:
    12,247
    Likes Received:
    3,723
    Location:
    Yorkshire, England
    I dont really understand it enough to explain in any great detail, however from what i gather Sony messed up massively with the way everything was signed for the PS3.

    When something is encrypted its good practice to do so with a different random number for each file encrypted, however on the PS3 Sony encrypted everything with the same random number by accident (so it wasn't a random number at all like it was supposed to be), this allowed Fail0verflow to reverse-engineer the encryption keys.

    [​IMG]
     
  13. seanpr92

    seanpr92 Godlike

    Joined:
    Oct 12, 2010
    Messages:
    1,159
    Likes Received:
    195
    Location:
    Nottingham, United Kingdom
    soner or later there gonna sell these kits to jtag a slim ect on ebay for people that cba to go out and buy all stuff correct me if im wrong but the original ps3 jailbreak also used a development usb board before the keys were found
     
  14. Dark Scyth

    Dark Scyth Moderator

    Joined:
    Mar 3, 2009
    Messages:
    2,594
    Likes Received:
    459
    They used a Teensy+ Developmental board but it cracked the PS3 with a certain hex code not by using a pulse, although this is somewhat the same type of exploit that Geohot found with the PS3, which most believe this exploit led up to the dongle for PS3.
     
  15. delhanh

    delhanh PS3 Contributor

    Joined:
    Jul 2, 2009
    Messages:
    205
    Likes Received:
    17
    Location:
    Australia
    am i the only one to see this, but is the guy naked in the video :O ?
     
  16. Michael_T

    Michael_T Addict

    Joined:
    Dec 21, 2009
    Messages:
    836
    Likes Received:
    305
    Would be great if you could run Xex.Menu 1.1 instead of ...
     
  17. Dark Scyth

    Dark Scyth Moderator

    Joined:
    Mar 3, 2009
    Messages:
    2,594
    Likes Received:
    459
    RHG has now been updated to 1.1. Which now includes Falcon Motherboards being usable for the hack among fixes and other things.

     
  18. InsaneNutter

    InsaneNutter Resident Nutter Staff Member

    Joined:
    Jun 1, 2007
    Messages:
    12,247
    Likes Received:
    3,723
    Location:
    Yorkshire, England
    That officially makes all HDMI consoles exploitable now, the N64 Emulator has officially been released as a compiled version now.
    Looking forward to see what this will bring in the future.
     

Share This Page