Xbox 360 Reset Glitch H4ck | Homebrew für Slim & Phat | Ersten Post lesen!

[Jim_Jones]

Dieser Thread befindet sich im AUFBAU!!!
Der Hack ist noch nicht optimiert, es kann durchaus noch Bugs geben!


DIESER HACK IST NICHTS FÜR NOOBS!
WEDER DAS G:B NOCH ICH HAFTEN FÜR EVENTUELLE SCHÄDEN!

!!! DON'T TRY THIS AT HOME !!!

ERST LESEN, DANN POSTEN!!!

Was ist der Reset Glitch Hack?

Spoiler: 

Ähnlich wie ein JTAG-Hack.
Homebrew eben .
Beweis-Video

Was kann ich damit machen?

Spoiler: 

Alles was man mit einer JTAG auch kann .
- Jede beliebige 2,5"/3,5" Festplatte, anstatt der original Microsoft verwenden.
- Spiele von USB-Stick, USB-Festplatte oder der internen HDD ohne DVD spielen.
- Unsignierte Software (XeXMenu, FreeStyle Dash, Emulatoren, Media-Player, etc.) ausführen.
- Linux starten.
- DVD-Key recovery.

Somit alles außer XBL!

Welche Konsolen werden unterstützt?

Spoiler: 

Dieser Hack funktioniert mit folgenden Konsolen:
Slim (bis MFR Mitte Aug. 2011) = WORKS!
Jasper (CB <= 6751) = WORKS!
Falcon (CB <= 5771) = WORKS!
Zephyr = WORKS!
Xenon = DOESN'T WORK!

Welche Bugs gibt es?

Spoiler: 

- Xenon's werden nicht unterstützt, Erklärung:

Xenon was tried once, it seemed asserting CPU_PLL_BYPASS on them crashed the ppc (not sure if it was asserting or deasserting), the HANA+I2C way can't work too because on Xenons, 100Mhz dp clock is provided by a fixed frequency chip, it changed with Zephyrs.

- Die Konsole braucht bis zu 2 Minuten bis sich hochgefahren ist.

Was braucht man dafür?

Spoiler: 

- USB SPI Flasher.
- Dev-Board mit einem XC2C64A-µC (Bspw. C-MOD, CoolRunner-II CPLD)
- 1x 270pF Kondensator. NUR BEI DER SLIM NÖTIG!
- 1x 100nF Kondensator. NUR BEI DER FAT NÖTIG!
- 1x 1k Widerstand. NUR BEI DER FAT NÖTIG!
- 1x 22k Widerstand. NUR BEI DER FAT NÖTIG!
- 3x 1N4148 Dioden. NUR BEI DER FAT NÖTIG!
- alles was man zum löten benötigt.
- Lötkenntnisse.

Für den Programmer (wird für das Dev-Board benötigt):
- 1x 220R, 4x 3k3, 3x 1N4148 Diode, 1x 40-Pin Sockel

Und eben die ganzen Programme die in der Anleitung stehen...
Ganz wichtig: Brain_V2.exe

Wo kann ich das Dev-Board kaufen?

Spoiler: 

Einfach bei Ebay die Bezeichnung des µC in die Suche eingeben.
http://shop.trenz-electronic.de/cata...roducts_id=680
http://www.ehajo.de/Aufgebaut/Cool-R...=1&refertype=8
http://digilentinc.com/Products/Detail.cfm%3FProd=CMOD

Solltet ihr noch andere Quellen kennen, schickt mir eine PN und ich werde es hier hinzufügen.

Wie funktioniert der Reset Glitch Hack?

Spoiler: 

**********************************
* 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.

LPT-Programmer für das Dev-Board:

Spoiler: 

Ladet XilinX Labtools 12.2 (unter 12.2 -> Lab Tools - 12.2 Product Update) herunter und installiert es.
Dazu ladet ihr euch die passenden *.jed-Dateien herunter um diese mit dem LTP-Programmer auf euer Dev Board zu schreiben.

Nun lötet ihr am Dev Board 3V3 und GND an irgendeine Stromquelle an.
Mein Tipp wäre ein Maximus oder CK3.
Ihr könnt jedoch auch die Xbox als Stromquelle benutzen:
Entweder vom Stromkabel des Laufwerks (PIN5 = GND, PIN6 = 3V3), siehe Bild.
Oder am SPI-Port der Konsole.
Slim: J2C1.8 (3V3) und J2C1.6 (GND) (Bild)
Fat: J1D2.8 (3V3) und J1D2.6 (GND) (Bild)

Nun steckt ihr das Dev Board an den LTP-Programmer und setzt das Dev Board unter Strom.
Startet iMPACT (aus dem installierten XilinX Labtools 12.2) und beschreibt euer Dev Board wie folgt vor (natürlich die *.jed auswählen die ihr benötigt):




Nach dem erfolgreichem beschreiben des Dev Boards lötet ihr wieder ab.

Alternative:

Für alle die noch keinen LPT Programmer haben bzw die keine Lust auf die Xillinx Software zum Flashen haben, gibs hier nen einfacheren Programmer (stand schon ein paar Seiten vorher und der funzt wunderbar und braucht weniger Bauteile) und eine sehr einfache kleine Software zum beschreiben der Chips.
Beachtet bitte nur , dass ihr eure richtige LPT Port Adresse eintragt.


Hier der Bauplan, danke nochmal an esunny4711


und hier das Tool (knapp 20 MB)

http://www.multiupload.com/U85IEM49Q1

Lötanleitung für die Slim:

Spoiler: 

Resultat:

Lötanleitung für die Phat:

Spoiler: 

Resultat:

[Jim_Jones]

Alternative Lötpunkte auf der Fat:

Spoiler: 

Lötpunkte auf dem Dev-Board (Slim):

Spoiler: 

"China Dev Board":


CoolRunner II von Dangerous Prototypes:


haoyu:


C-MOD:

Lötpunkte auf dem Dev-Board (Fat):

Spoiler: 

"China Dev Board":


CoolRunner II von Dangerous Prototypes:


haoyu:


C-MOD:

[Jim_Jones]

!!! VOR DEM AUSLESEN SOLLTET IHR AUF 13604 UPDATEN !!!

NAND-Flash auslesen:

Spoiler: 

DIE KONSOLE MUSS BEIM AUSLESEN UND SCHREIBEN MIT NANDPRO IM STAND-BY-MODUS SEIN!
Bitte öfters auslesen (3-4x).

Zum NAND-Flash auslesen benutzt ihr NandPro.
Slim:


Fat:


Befehl für Zephyr/Falcon/Jasper16/Trinity:
nandpro usb: -r16 nand1.bin

Befehl für Jasper256/Jasper512:
nandpro usb: -r64 nand1.bin

Befehl zum vergleichen:
fc /b nand1.bin nand2.bin

Erstellen der *.ecc-Datei:

Spoiler: 

Python 2.7 und Python Crypto 2.3 herunterladen und installieren.



Nach dem installieren den ECC Builder herunterladen. Kopiert euer ausgelesenes Backup vom NAND-Flash in den "ecc builder"-Ordner.
Startet die "ECC Builder.bat" und folgt den Anweisungen.



Wenn die *.ecc erfolgreich erstellt wurde, steht am Ende "Written into output/image_00000000.ecc"

image_00000000.ecc auf den NAND-Flash schreiben:

Spoiler: 

Kopiert die mit dem ECC Builder erstellte image_00000000.ecc in den Ordner im dem sich NandPro befindet.

Beschreibt nun den NAND-Flash mit folgendem Befehl:
(Zephyr/Falcon/Jasper16/Trinity)
nandpro usb: +w16 image_00000000.ecc

(Jasper256/512)
nandpro usb: +w64 image_00000000.ecc



Nach dem beschreiben die Konsole vom Strom nehmen und den USB-Flasher abstecken.

Starten von Xell um den CPU-Key zu bekommen:

Spoiler: 

Nach erfolgreichem beschreiben der *.ecc-Datei, sollte beim starten der Konsole folgendes Bild erscheinen (Dauert i.d.R. bis zu 2 Minuten):



Nun schreibt euch den CPU-Key auf, fotografiert ihn oder kopiert ihn per Ethernet.

Erstellen eines hacked Dashboard mit ggBuild:

Spoiler: 

Ladet folgendes Paket herunter: Download

Vorgehensweise für die Fat:

Spoiler: 

Benennt euer ausgelesenes Backup (nand.bin) in "nanddump.bin" um und kopiert ihn in den Ordner "mybackup" hinein, führt die "builder.bat" aus und folgt den Anweisungen.

Jetzt könnt ihr die "builder.bat" ausführen und den Anweisungen folgen.
Wenn alles ohne Probleme abläuft solltet ihr eine "nandflash.bin" erhalten.
Die Datei nandflash.bin ist das hacked Dashboard!

Selbstverständlich könnt ihr auch andere Tools zum erstellen eines hacked Dashboard verwenden.
z.B. Easy ggBuild v0.4

Vorgehensweise für die Slim:

Spoiler: 

Benennt euer ausgelesenes Backup (nand.bin) in "nanddump.bin" um und kopiert ihn in den Ordner "mytrinity" hinein.
Anschließend öffnet ihr "360 Flash Tool" im "Tools"-Ordner und fügt euer CPU-Key hinzu. Nun setzt unter "Settings" -> "Options" -> "Extract iBuild" einen Haken.
Danach klickt ihr auf "Extract" -> "Generic Files" -> "Firmware Challenge Response Table" einen Haken und sucht euch irgend ein Ordner zum entpacken aus.
Anschließend kopiert ihr die zwei Dateien "fcrt.bin.meta" und "fcrt.bin" die sich in "GenericFiles" -> "FreeBOOT" -> "Data" befinden in den Ordner "mytrinity" (da wo sich die zuvor kopierte nanddump.bin-Datei befindet).

Jetzt könnt ihr die "builder.bat" ausführen und den Anweisungen folgen.
Wenn alles ohne Probleme abläuft solltet ihr eine "nandflash.bin" erhalten.
Die Datei nandflash.bin ist das hacked Dashboard!

Selbstverständlich könnt ihr auch andere Tools zum erstellen eines hacked Dashboard verwenden.
z.B. Easy ggBuild v0.4

Beschreiben des hacked Dashboard auf den NAND-Flash:

Spoiler: 

Es gibt zwei Möglichkeiten den NAND-Flash zu beschreiben.

Möglichkeit 1:
Das Programm RawFlash v3 herunterladen und die "xenon.elf" mit der erstellten nandflash.bin in einen Root eines USB-Sticks kopieren.
Anschließend den USB-Stick in die Konsole stecken und die Konsole einschalten.
Bei erfolgreichem beschreiben sollte "...shut down..." da stehen.
Danach die Konsole kurz vom Strom nehmen und den USB-Stick abziehen.

======================================================

Möglichkeit 2:
Die erstellte "nandflash.bin"-Datei mit NandPro und einem USB-Flasher auf den NAND-Flash schreiben. Kopiert hierzu einfach die "nandflash.bin" in den Ordner wo sich die "Nandpro.exe" befindet und gibt folgenden Befehl ein:

(Zephyr/Falcon/Jasper16/Trinity)
nandpro usb: -w16 nandflash.bin

(Jasper256/Jasper512)
nandpro usb: -w64 nandflash.bin

Wenn der Flashvorgang fertig war, zieht ihr den USB-Flasher und die Stromzufuhr ab.

======================================================

DONE! Nun könnt ihr eure Xbox starten und ein hacked Dashboard genießen!!!
Solltet ihr Xell starten wollen, dann drückt den Eject-Knopf.

[Jim_Jones]

reserviert...

[bosco82]

Wow, damit ist die 360 also endgültig offen. Hätte nicht gedacht das nach dem JTAG-Hack noch mal sowas Großes kommt

[Uldi]

und wo sind nun die leute, die meinten das ich nur "müll laber"?

Hach, wenn dus unbedingt willst: Du laberst Müll :O

Doof, wenn man die Hardware nicht da hat

[bosy]

wäre jetzt auch gut zu wissen ob man den Drive key jetzt auslesen kann hab hier noch ne konsole wo der key weg ist

[Unimatrix-zero]

Was braucht man dafür?

Spoiler: 

Lediglich einen µC (XC2C64A).

Wie kommst du darauf? In der Anleitung steht was anderes. Man braucht in erster Linie einen Programmer und einen XC2C64A CoolRunner-II CPLD

[bignfan]

genial...
so geil das ganze
jetzt brauch ich nicht beten das meine launch 360er ewig hält ^^

hammer, nur ein derbysieg ist schöner

[Jim_Jones]

ein dev-board braucht man halt....
C-MOD, CoolRunner-II CPLD, etc.
eins mit nem XC2C64A µc.

[Unimatrix-zero]

Genau. Die Frage ist jetzt nur wo ich so ein DEV Board her bekomme? Bei Conrad und Reichelt gibts das nicht und Farnell hat nur den Controller ohne Board.

[Jim_Jones]

über google sollte man den ein oder anderen shop finden...

[deaconfrostnav]

Kenn den laden zwar nicht aber google shopping hat mir spontan das gebracht

[Ix_JumPeR_xI]

Das klingt ja jetzt echt mal geil Slim mit JTAG hack

[TK8228]

und wo sind nun die leute, die meinten das ich nur "müll laber"?

Ich wusste das es mehr als "nur" irgendein X-Key Clone ist!!

[Pady]

Nur was denn dann muss der cmod dann in der box bleiben

[Unimatrix-zero]

Kenn den laden zwar nicht aber google shopping hat mir spontan das gebracht

Habe ich auch gefunden, ist aber nicht genau das Board wie im tutorial

[HITS25]

was beudetet das jetzt für uns?


kann man damit alles machen was JTAG auch kann?

[deaconfrostnav]

so in der art wenn ichs richtig verstanden habe - nur mit längerer "wartezeit" unter umständen

allerdings was ich jetzt noch nicht ganz verstanden habe - bleibt dann die ganze platine in der box - oder nur der chip?

[Ix_JumPeR_xI]

Wenn ich das richtig verstehe glitcht man die Box ja erstma nur ins Xell. Ist es dann nicht einfach möglich wenn man den CPU Key usw einfach nen Freeboot nand zu flashen? Dann könnte man doch die Platine usw entfernen oder?
Naja da wird jetzt bestimmt viel viel mehr kommen in den Monaten