The Reset Glitch Hack - ein umfangreiches Tutorial v1.1.0 *08.12.2011*

[nightcode]

--1-- Einleitung --1--

Hallo zusammen.
Ich habe mir mal die wochenlange Mühe gemacht, ein relativ noobfreundliches und umfangreiches Reset Glitch Hack Tutorial zu erstellen. Zwar existiert bereits ein Tut, aber ich hatte schon angefangen und wollte es etwas umfangreicher gestalten. Es behandelt sowohl die Xell Installation als auch die DVD-Key Recovery sowie die Installation eines Freeboot Dashboards. Somit ist das Ergebnis gleichwertig mit einer JTAG Konsole, nur das eben der Weg etwas anders ist.

Falls es schon am löten oder basteln diverser Zusatzhardware hapert lasst den Umbau bitte von einem Dritten durchführen!

Falls ihr Fehler findet oder Verbesserungsvorschläge habt könnt ihr sie mir gerne per PN mitteilen.

Ich füge in den nächsten Tagen zu den Teilelisten links zu Conrad und Reichelt hinzu und bemühe mich, das Tut stets aktuell zu halten.


-- Inhaltsverzeichnis --

1 => Einleitung

2 => Changelog

3 => Technische Erklärung

4 => Vorbereitung / Teileliste

5 => Xilinx vorbereiten und flashen

6 => Verkabelung bei Slim (Trinity) Konsolen

7 => Verkabelung bei FAT (Zephyr, Opus, Falcon, Jasper) Konsolen

8 => NAND auslesen, Xell Image erstellen und Flashen, CPU- und DVD-Key ermitteln

9 => Hacked Image erstellen und flashen

10 => Troubleshooting

11 => Downloads

12 => Softwareinstallation nach dem Hack

[nightcode]

--2-- Changelog --2--

v1.1.0 08.12.2011

• Update auf Version 1.1.0
• Neuer Navigationspunkt 12 => Softwareinstallation nach dem Hack
• Teileliste für Conrad und Reichelt hinzugefügt
• kleine Änderungen an Textpassagen und Alternativbildern

v1.0.1 02.12.2011

• Update auf Version 1.0.1
• kleine Änderungen an Textpassagen
• Aktualisierung des Downloadpakets auf v1.0.1

v1.0 25.11.2011

• initiales Release (v1.0)

[nightcode]

--3-- Technische Erklärung --3--


Dieser Text enthält die technische Erklärung der "Entdecker des Hacks" und richtet sich eher an die Informatiker oder "Technikversteher" unter euch. Er wurde von mir größtenteils übersetzt und an vielen Stellen ergänzt.
Es ist auf jeden Fall hilfreich, ihn zu lesen, da er zu besserem Verständnis der Materie beiträgt und es sich somit leichter hackt :-P

Für eine erfolgreiche Anwendung des Reset Glitch Hacks ist die Kenntnis dieser Fakten jedoch nicht zwingend notwending.


Was ist der Reset Glitch Hack ?

Um es kurz zu fassen: das Ergebnis des Reset-Glitch-Hacks ist identisch mit dem des JTAG Hacks, nur der Weg dahin ist etwas anders (CPU Glitching mittels Xilinx Coolrunner II / CMOD). Microsoft kann jedoch keine Updates gegen kompatibele Konsolen herausbringen.
Die einzige Einschränkung ist, dass der Bootvorgang bis zu 2 Minuten dauern kann.
In der Regel passiert dies jedoch, je nach Timing optimierung und Glück, innerhalb weniger Sekunden. Besonders die Falcon Boxen booten bei mir sofort und das sogar schneller als eine JTAG Konsole.


Einleitung / wichtige Fakten

Die Software bzw. das Betriebssystem der XBOX360 wurde (ganz im Gegensatz zur PS3 oder Wii) sehr effizient gegen äußere Eingriffe abgesichert (wirksame Public Key Kryptografie, sämtliche Checks und Hashing Verfahren, ein Hypervisor usw). Selbst wenn softwareseitige Sicherheitslücken, die das Ausführen von unsigniertem Code ermöglichen (z.B. King Kong Exploit oder Teile des JTAG SMC Hacks), entdeckt werden, können diese seitens Microsoft mit einem Update schnell geschlossen- und durch das setzen einer "E-Fuse" ein Downgrade auf ein älteres, für den Hack anfälliges, Update unterbunden werden. Somit werden durch Updates von XBOX Live oder neuen Spielen diese Konsolen extrem schnell extrem selten.

Die CPU der XBOX 360 beginnt beim Start der Konsole den Code des 1BL (1. Bootloader) aus einem prozessorinternen ROM-Speicher auszulesen uns auszuführen. Da dieser Speicher im Prozessor nur lesbar ist (ein ROM halt) kann dieser nicht von Microsoft gepatcht werden. Nur durch neue CPU-Chips oder andere Hardwareänderungen sind solche Patches möglich und genau das ist bei den ganz neuen Slim Modellen (ab ca. 15.08.2011) der Fall. Diese haben keinen HANA Chip mehr auf dem Mainboard und somit fällt eine wichtige Signalleitung aus. Auch bei den alten FAT Konsolen könnte es durchaus möglich sein, dass die Geräte, welche vom Support repariert oder refurbished wurden, später einmal mit einer neue CPU bestückt werden. Dieser 1. Bootloader ist mit dem 1BL Key verschlüsselt, welcher bei allen Konsolen identisch und bekannt ist. Der 1BL läd dann den CB (2. Bootloader), welcher sich im NANDspeicher befindet sowie RSA signiert und RC4 verschlüsselt ist, und startet ihn. Der CB ist unser Knackpunkt, denn er initialisiert das Sicherheitssystem der CPU (Echtzeitverschlüsselung und Hash-Checks des RAMs) und genau dort hat der alte JTAG Hack angesetzt, welcher jedoch durch ein Update des CB verhindert wurde.
Als Sicherheitsmethoden wird eine 128 Bit AES Verschlüsselung sowie vermutlich das Toeplitz Hashverfahren angewendet. Die Verschlüsselung variiert bei jedem Start der Konsole, da sie bzw der Schlüssel sich aus folgenden Teilen zusammensetzt:
-Eine Hashsumme des kompletten fusesets (die z.B. auch den CPU Key enthalten, JTAG Usern bekannt sein sollten)
-Ein zeitbasierter Zähler
-Eine (im Gegensatz zur PS3) wirklich zufällige Zufallszahl, welche dem Zufallszahlengenerator der CPU entspringt. Es gibt zwar bei den FAT Konsolen einen Weg, diesen Generator elektrisch zu deaktivieren, jedoch prüft der CB, ob die Zahl auch wirklich zufällig und eben nicht statisch ist.
Danach führt der 2. Bootloader eine bytecodebasierte, schlichte Softwareengine aus, die z.B. den RAM initialisiert und letztendlich den CD (3. Bootloader) aus nem NAND läd, entschlüsselt und ausführt.
Der CD beinhaltet und startet den Kernel und somit auch den Hypervisor, welcher im Originalzustand der Software eine Virtuelle Hardwareumgebung zur Verfügung stellt (ähnlich wie bei einer Virtuellen Maschine am PC) und somit sämtliche Datenströme kontrollieren und gegen Hacks absichern kann. Nur dieser Hypervisor hat genug Rechte um unsignierten Code auszuführen. Ausschließlich in den Kernelversionen 4532 und 4548 (ursprünglich bekannt durch den KingKong Exploit) existiert eine kritische Schwachstelle. Alle bekannten XBOX360 Dashboard Hacks basieren auf einem dieser Kernel und nutzen diese Schwachstelle aus, um unsignierten Code auszuführen.
Leider beinhaltet der CD bei allen Konsolen mit neuerem Kernel Hashsummen dieser anfälligen Versionen und blockiert somit den Startvorgang wenn man versucht, einen dieser Kernel zu laden.

TMBINC (ein Hacker) hat jedoch festgestellt, dass die XBOX360 nicht gegen Hardwareattacken wie z.B. die "Timing Attacks" aus dem KingKong Exploit oder eben das "Glitching" abgesichert wurden.

Unter Glitching versteht man grundsätzlich das Auslösen von Prozessorschwachstellen durch elektronische Mittel und genau auf diese Art und Weise sind wir endlich wieder in der Lage, unsignierten Code auf unseren XBOXen auszuführen.


Der Reset Glitch Hack in ein paar Worten

Die Hacker haben herausgefunden, dass durch das Senden eines winzigen Reset Impulses an die CPU, während deren Taktrate extrem reduziert ist, diese nicht resettet wird, sondern sich die Art der Befehlsausführung ändert. Dieser Vorgang ist eine sehr effiziente Methode die Funktion "memcmp" (memory compare => Vergleich von 2 Speicherbereichen) zu veranlassen, keine Unterschiede in den verglichenen Speicherbereichen zu erkennen, selbst wenn diese Existieren. Memcmp wird oft verwendet um einen SHA Hashwert des nächsten zu ladenden Bootloaders mit einem gespeicherten Wert zu vergleichen und diesen auszuführen, falls die verglichenen Werte identisch sind. Somit ist es möglich, einen Bootloader, welcher den Hash Check nicht besteht, trotzdem zu laden und zwar in dem der vorherige Bootloader "geglitcht" wird und somit den darauffolgenden ausführt, selbst wenn dieser den Hash Check nicht besteht (z.B. läd dann der geglitchte CB anstandslos den CD).


Details über den Hack bei FAT Konsolen a.k.a. Zephyr/Opus/Falcon/Jasper

Bei den FAT XBOXen wird der CB geglitcht und läd somit einen beliebigen CD.

Der Hacker "cjak" hat herausgefunden, dass sich durch die Belegung des "CPU_PLL_BYPASS" Signals die Taktrate des Prozessors erheblich verringert.
Somit arbeitet die CPU mit einer Taktrate von 200MHz wenn das Dashboard läuft, mit 66,6MHz wenn die Konsole bootet und mit 520kHz wenn das Signal eingespeist wird.

Dieser Vorgang läuft folgendermaßen ab:
-Das CPU_PLL_BYPASS Signal wird zeitlich gesehen in der Nähe des POST-Codes (power-on self-test - sollte euch vom PC bekannt sein) 0x36 aktiviert
-Es wird auf den POST-Code 0x39 gewartet (zu diesem Zeitpunkt wird die memcmp Funktion ausgeführt und somit der Check der Hashwerte durchgeführt) und senden dann einen 100ns Impuls auf die CPU_RESET Leitung des Prozessors
-Nach etwas Wartezeit wird die CPU_PLL_BYPASS Leitung wieder freigegeben und somit die originale Taktrate der CPU wieder aktiviert
-Mit etwas Glück wird der Bootvorgang nun fortgesetzt und der CB führt den gehackten CD aus, anstatt den Vorgang mit dem POST-Code 0xAD abzubrechen

Der NANDSpeicher muss einen "zero-paired" CB (nicht wie das original von Microsoft paired, sodass das Image nicht an die originale Konsole gebunden ist [Pairing Data wird durch Nullen ersetzt]), den Payload (sollte von der PS3 bekannt sein) im CD und ein modifiziertes SMC Image (eine Art BIOS der XBOX) enthalten.
Der Glitch ist von Natur aus unzuverlässig. Es wird daher ein modifiziertes SMC Image eingesetzt, welcher so lange rebootet, bis der Glitch erfolgreich war (bei originalen Konsolen erscheint nach 5x Rebooten ein ROD).
In den meisten Fällen funktioniert der Glitch innerhalb von 30 Sekunden nach Start der Konsole. Ich kann jedoch aus persönlichen Erfahrungen sagen, dass es meist nicht länger als 10 Sekunden dauert. Insebsondere Falcon Revisionen starten sogar schneller als eine JTAG Box - und das jedes mal!


Details über den Hack bei SLIM Konsolen a.k.a. Trinity/Valhalla

Hier wird der Bootloader CB_A geglitcht, um einen beliebigen CB_B auszuführen.
Die Hacker konnten auf dem Mainboard der XBOX360 Slim keine Leiterbahn für das CPU_PLL_BYPASS Signal finden.
Auf der Suche nach Alternativen fanden sie heraus, dass der HANA Chip (Zuständig für die Skalierung von Videosignalen) ein konfigurierbares PLL Register besitzt, das die CPU und GPU mit einer 100MHz Taktrate versorgt. Glücklicherweise werden diese Register über einen I2C Bus vom SMC beschrieben. Dieser Bus ist frei zugänglich und besitzt sogar einen Lötpunkt auf dem Mainboard (J2C3). Somit ist der HANA Chip die neue Geheimwaffe um die Taktrate der CPU bei slim Konsolen zu verringern.
Leider ist in neuen Slim Revisionen mit Produktionsdatum ab Anfang bis Mitte August 2011 kein HANA Chip mehr verfügbar, was den Glitch Hack für diese Konsolen vorerst unmöglich macht.

Der Glitching Vorgang läuft folgendermaßen ab:
-Es wird beim POST-Code 0xD8 ein I2C Befehl an den HANA Chip gesendet, der die Taktrate der CPU verringert
-Es wird auf den Start des POST-Codes 0xDA gewartet (an dieser Stelle wird die memcmp Funktion ausgeführt) und danach ein Zähler gestartet
-Wenn der Zähler einen bestimmten Wert erreicht wird ein 20ns Impuls an die CPU_RESET Leitung des Prozessors gesendet
-Nach etwas Wartezeit wird erneut ein I2C Befehl an den HANA Chip gesendet und die CPU somit wieder auf ihre Ausgangstaktrate gesetzt
-Mit etwas Glück wird der Bootvorgang nun fortgesetzt und der CB_A führt den gehackten CB_B (2. Teil des 2. Bootloaders) aus, anstatt den Vorgang mit dem POST-Code 0xF2 abzubrechen

Wenn der CB_B startet ist der RAM noch nicht initialisiert und somit können ein paar Patches angewendet werden, um einen beliebigen CD auszuführen
-Es wird immer der zero-paired Modus aktiviert umd ein gehacktes SMC ausführen zu können
-Der CD wird nicht verschlüsselt. Es wird ein entschlüsselter CD im NAND erwartet
-Der Bootvorgang wird fortgesetzt, auch wenn die Hashprüfung des CD fehlschlägt

CB_B ist mit dem RC4 Algorithmus verschlüsselt. Dieser Schlüssel wiederum wird mithilfe des CPU-Keys entschlüsselt. Auf die Methode der Entschlüsselung seitens der Hacker möchte ich hier nicht eingehen. Jeder der Interesse an Kryptografie hat kann sich damit auseinandersetzen, für den Rest ist dieser Schritt relativ unwichtig.

Der NAND enthält nun den originalen CB_A, einen gepatchten CB_B, den Payload in einem unverschlüsselten CD sowie ein modifiziertes SMC Image.
Das SMC Image wurde modifiziert um einen unendlichen Neustart der Konsole zu realisieren (bis der Hack erfolgreich war) und um die Konsole daran zu hindern, periodisch I2C Befehle an den HANA Chip zu senden, sodass die Einspeisung zur Realisierung der niedrigen CPU Taktrate problemlos funktioniert.


Der Clou

Der CB_A (bei Slim Konsolen) enthält keinen Check der E-Fuses. Somit ist dieser Hack NICHT DURCH MICROSOFT PATCHBAR (da die Chain of Trust direkt an ihrem ersten Glied gebrochen wird) und wird uns, ganz im Gegensatz zu den JTAG Konsolen, bei den bisher produzierten Slim Konsolen hoffentlich ewig erhalten bleiben!!! Für die FAT Version heißt es abwarten ob eventuell der 2-Stage CB der Slim für die FAT portiert wird, wodurch dann auch die 6752 Jasper Konsolen laufen sollten (gleicher Aufbau).


Vorbehalte

-Der Glitch ist relativ zuverlässig (durchschnittlich 25% Erfolg pro Reset), kann jedoch auch im worst case mehrere Minuten dauern (was eigentlich nie der Fall ist und durch ausgefeiltere Firmwares der Glitch Chips [Xilinx] vermutlich noch weiter reduziert wird)
-Die Erfolgsrate scheint abhängig von der Hashsumme des zu ladenden, modifizierten Bootloaders zu sein (CD für die FAT Konsolen und CB_B für die Slims)
-Es ist präzise und schnelle Hardware erforderlich um den extrem kurzen Reset Impuls zu senden


Die momentane Implementierung des Hacks

Es wird ein Xilinx CoolRunner II CPLD (xc2c64a) bzw C-MOD verwendet, da dieser günstig, schnell, präzise sowie updatebar ist und mit 2 verschiedenen Betriebsspannungen gleichzeitig arbeiten kann.
Es wird ein 48 MHz Standby Takt für den Glitch Zähler verwendet. Bei den Slim Konsolen sind es sogar 96 MHz.
Die Firmware des CoolRunners ist in VHDL geschrieben.
Um den aktuellen POST Code zu ermitteln wurden in der 1. Implementierung alle 8 Bits des POST Ports dafür verwendet. Nun ist man jedoch in der Lage den Code anhand eines einzigen Bits zu ermitteln und spart sich somit die Lötarbeit für 7 weitere Kabel.


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.

Falls einige Begriffe unklar sind bitte fragen und ich werde sie erklären und evtl. hinzufügen.

[nightcode]

--4-- Vorbereitungen / Teileliste --4--


Welche Boxen sind Glitchbar?


Der Hack lässt sich grundsätzlich bei allen XBOX360 Versionen mit HDMI Ausgang durchführen (also keine XENON!). Außerdem ist er mit Opus Mainboards, also einer Falcon Revision ohne HDMI Ausgang, kompatibel.
Ausgeschlossen sind hierbei jedoch Slim Modelle mit Produktionsdatum ab ca. 15. August 2011 (besitzen ein Corona Mainboard und somit keinen HANA Chip [siehe Bild]).

Slim Corona Mainboard ohne HANA Chip



Außerdem gilt die Grundregel, dass alle Falcon und Jasper Konsolen, die ab 2011 beim Support waren oder Refurbished sind, mit dem neuen CB bestückt sind und somit momentan nicht glitchen. Der Umbau bei Falcon Konsolen mit einer CB-Version größer 5771 sowie Jasper Versonen mit CB größer 6751 (6750 direkt und 6751 per donor CB glitchbar) funktioniert somit nicht. Die CB Version euerer Box könnt ihr leider nur herausfinden, in dem Ihr eueren NAND auslest und mit 360 Flashtool (aktuell Version 0.97 - beiliegend im Softwarepaket) analysiert.


Bestimmung der Konsolenrevision

Die Revision des Mainboards lässt sich glücklicherweise kinderlicht mithilfe des Stromanschlusses ermitteln. Außerdem spielt es eine Rolle, ob ein HDMI Anschluss vorhanden ist oder nicht. Schaut einfach auf der Grafik nach den Passenden Eigenschaften.
Falls ihr eine Jasper Arcade Konsole (weiße Frontblende, interne Memory Unit) besitzt, dann handelt es sich um eine Jasper BigBlock (BB) Revision. Bei einem NAND Chip von der Firma Samsung handelt es sich um 512MB Speicher, ansonsten sind 256MB in diesen Mainboards verbaut.

XBOX360 Revisionen




Teileliste

|für alle Konsolen|

• 1x XC2C64A CoolRunner-II CPLD (alternativbezeichnung: C-MOD)
  
• 1x Nand-Spi-Flasher - vorzugsweise USB, alternativ funktioniert auch LPT
  
• [OPTIONAL] 1x Xilinx Programmer (selbstgebauter LPT Flasher oder eine USB Lösung [USB NAND Spi Flasher mit ARM Chip können laut tyros mit Nandpro ab Version 3 den Xilinx beschreiben] - alternativ kann man auch einen für das entsprechende Konsolenmodell vorprogrammierten Xilinx kaufen)
  
• Softwarepaket
  
• Lötausrüstung (vernünftiger Kolben, Zinn, Flussmittel, Entlötlitze, Litze, Schrumpfschlauch usw.)
  
• [OPTIONAL] Sockel für den Coolrunner - 40 Pin (es kann jedoch auch direkt auf den Chip gelötet werden)

|nur für FAT Konsolen|

• 3x 1N4148 Diode |Conrad| - |Reichelt|
  
• 2x 100nF Kondensator |Conrad| - |Reichelt|
  
• 1x 1kOhm Widerstand |Conrad| - |Reichelt|
  
• 1x 22kOhm Widerstand |Conrad| - |Reichelt|
  
• 1x 680pF Kondensator (optional, nur erforderlich wenn Jasper nicht glitcht) |Conrad| - |Reichelt|
  
• 1x 470pF Kondensator (optional, nur erforderlich wenn Jasper nicht glitcht) |Conrad| - |Reichelt|

|nur für Slim Konsolen|

• 1x 270pF Kondensator |Conrad| - |Reichelt|
• 1x 220pF Kondensator |Conrad| - |Reichelt|

|für den Xilinx LPT Programmer (OPTIONAL)|

• 1x LPT Stecker |Conrad| - |Reichelt|
  
• 3x 1N4148 Diode |Conrad| - |Reichelt|
  
• 1x 220 Ohm Widerstand |Conrad| - |Reichelt|
  
• 4x 3,3kOhm Widerstand |Conrad| - |Reichelt|
  
• [OPTIONAL] 3,3V Festspannungsregler inkl. Kondensatoren laut Datenblatt sowie USB-Buchse |Conrad| - |Reichelt|

Systemupdate der Konsole

Auch wenn es unter Umständen mit verschiedenen Systemupdates funktioniert empfiehlt es sich sehr, die XBOX auf ein aktuelles Dashboard, für welches ein ggbuild verfügbar ist, zu updaten. Momentan ist das die Version 2.0.13604. Dazu einfach aus dem Softwarepaket in den Ordner Systemupdate_13604 navigieren und den Ordner $systemupdate ins Hauptverzeichnis eines FAT32 formatierten USB Sticks kopieren. Den Stick an die Box anschließen, Box einschalten und das Update durchführen (falls keine Festplatte vorhanden ist und eine Meldung kommt, dass nicht genügend Speicher verfügbar ist, kann dieser Vorgang abgebrochen werden - der interne NAND wurde dennoch auf 13604 geupdated - nur eben ohne Avatare u.ä.). Zur Kontrolle könnt ihr danach die Version noch einmal unter "Konsoleneinstellungen -> Systeminformationen" überprüfen.

[nightcode]

--5-- Xilinx flashen und vorbereiten --5--


Nun ist es an der Zeit, das Xilinx Board zu flashen. Dazu wird ein Programmer sowie eine 3,3V Spannungsversorgung benötigt. Ich gehe hier nur auf den LPT Selfmade Programmer ein. Es gibt auch kommerzielle Programmer die unter anderem mit USB Anschluss arbeiten und keine zusätzliche Spannungsversorgung benötigen. Außerdem ist NandPro ab Version 3.0a in der Lage, mithilfe eines ARM basierten USB Nand Spi flashers (z.B. Xecuter Nand-X) und passender Firmware, den Xilinx zu beschreiben (ungetestet!).
Für die Stromversorgung des Chips beim Flashen empfehle ich einen 3,3V Festspannungsregler, wie er auch beim 93 Extractor verwendet wird. Ich könnt euch an der Anleitung orientieren, müsst jeodoch einfach nur den Widerstand weglassen.
Das Ergebnis sieht dann in etwa so aus:

Programmer mit 3,3V Spannungsversorgung



Ihr solltet das Teil noch mit etwas Schrumpfschlauch oder Isolierband schützen.

Als nächstes müsst ihr euch den LPT Programmer bauen, falls ihr keine alternative besitzt.
Es wird benötigt:

-1x LPT Stecker
-3x 1N4148 Diode
-1x 220 Ohm Widerstand
-4x 3,3kOhm Widerstand
-Kabel
-Schrumpfschlauch oder Isolierband

Schaltplan des LPT Programmers



Lötet einfach die Komponenten wie im Diagramm zu sehen zusammen und isoliert die Lötstellen mit Schrumpfschlauch oder Isoband. Die Pinnummern des LPT Steckers stehen meist klein neben den Pins (jedoch auf der Vorderseite).
Es ist ratsam, sich die Kabel zu beschriften und diese eventuell an eine Stiftleiste zu löten wenn man den Programmer öfters benutzt. Ansonsten geht es auch schnell und einfach die Kabel direkt auf den Xilinx zu löten.



Nun verbindet ihr den Programmer sowie die Spannungsversorgung mit dem Xilinx Board.

Steckt den Programmer in den LPT Port eueres Rechners und schließt, falls vorhanden, die Spannungsversorgung an den USB Port an. Falls ihr den Strom aus der XBOX abgreift müsst ihr diese nun starten (mit AV-Kabel!). Euer LPT Port sollte nativ sein (kein USB->LPT Kram) und im ECP Modus arbeiten (im BIOS einstellbar).

Der Glitch Chip wird in diesem Beispiel mit 360gcprog beschrieben, da es keine riesige Installation erfordert und einfach zu bedienen ist. Alternativ ist es natürlich auch mit dem Tool IMPACT aus den Xilinx Lab Tools möglich.

Nun müsst ihr euren LPT I/O Port ermitteln. Dazu klappt ihr im Windows Gerätemanager die Kategorie "Anschlüsse (COM und LPT)" und klickt doppelt auf den entsprechenden LPT Anschluss (in der Regel LPT1). Nun wechselt ihr zum Reiter "Ressourcen". Der erste Wert im ersten E/A Bereich Eintrag ist der I/O Port. In meinem Fall 0378 bzw 0x0378 mit hexadezimaler Kennzeichnung.


Öffnet nun das Programm 360gcprog im Ordner "\LPT Programmer\360gcProg\360gcProg.exe" des Softwarepakets. Unter "Select Cable" wählt ihr die Option "I Use a JTAG LPT Cable". Als nächstes klickt ihr auf den Schraubenschlüssel und gebt den oben ermittelten LPT Port in Hexadezimaler Schreibweise ein (z.B. 0x378 im aktuellen Fall).
Danach betätigt ihr die Schaltfläche "Connect". Nun sollte das Tool wie im Bild unter Punkt "4" markiert, den Xilinx finden und zu ihm verbinden. Falls ihr hier einen Fehler wie z.B. "TDO seems to be stuck at 1" oder ähnliches bekommt überprüft bitte den Programmer, den richtigen I/O Port, die Stromversorgung sowie die Verkabelung. Alternativ könnte ein anderer Rechner helfen. Nun auf den Button "..." klicken und aus dem Softwarepaket im Ordner "\LPT Programmer\firmwares_sfv" die Firmware für die entsprechende Konsole auswählen. Klickt anschließend auf "Flash" um den Xilinx zu beschreiben.

Xilinx Flashvorgang mit 360gcprog



Nun sollte die Meldung "The Board has been successfully flashed and verified" erscheinen.


Falls dies nicht der Fall ist einfach nochmal versuchen.
Ihr könnt nun mithilfe von "Identify" überprüfen, ob auch wirklich die richtige Firmware auf dem Xilinx ist (erscheint dann unter "Current FW").
Der Glitch Chip ist nun beschrieben. Ihr könnt ihn vom Rechner trennen und die Verbindungskabel komplett entlöten.


Versionen des Xilinx aka CoolRunner-II aka C-Mod


Es gibt verschiedene Xilinx DevBoards. Die bekanntesten sind unten mit Bildern aufgelistet. Ich kann nur wärmstens die "designed by ngzhang" Version empfehlen, welche ich problemlos in etlichen Boxen erfolgreich eingesetzt habe. Bevor die Chips in die XBOX kommen müssen unter Umständen noch Widerstände entfernt oder gebrückt werden.


designed by ngzhang Version

Hier muss erstmal der Widerstand R1 entfernt werden.
Bei Slim Konsolen C3 und C4 brücken, bei FAT Konsolen R2 brücken.




C-MOD

Entfernt für FAT Revisionen R2 und brückt R3. Bei den Slims ebenfalls R2 entfernen und das obere Pad von R1 via Kabel mit dem unteren Pad von R2 verbinden.

FAT



Slim




Coolrunner II von Dangerous Prototypes

Setzt den Jumper 2 für alle Revisionen auf 3,3V.
Jumper 1 ist bei FAT Revisionen auf "off" zu setzen. Bei Slims auf 1,8V.


FAT



Slim




Coolrunner II von Thaoyu Electronics

Entfernt für FAT Revisionen R2 und brückt R3. Bei den Slims ebenfalls R2 entfernen und das obere Pad von R1 via Kabel mit dem unteren Pad von R2 verbinden.

FAT



Slim




designed by Zhangjiqi007

VORSICHT! Diese Boards haben bei mir nicht funktioniert. Bei anderen laufen sie jedoch einwandfrei.

Es gilt der gleiche Plan wie bei der "ngzhang" Version.

[nightcode]

--6-- Verkabelung bei Slim (Trinity) Konsolen --6--


In diesem Abschnitt wird die Verkabelung bei Slim Konsolen behandelt. Besitzer einer FAT Konsole überspringen bitte diesen Punkt.

Ihr benötigt:

• 1x 270pF Kondensator ODER 1x 220pF Kondensator
• 1x Xilinx CoolRuner-II bzw C-Mod mit Trinity Firmware
• Kabel
• Isolierband / Schrumpfschlauch

Sucht euch nun einen geeigneten Platz für den Chip (ich empfehle unter dem Laufwerk) und lötet die Kabel zwischen den Punkten auf dem XBOX Board und dem Xilinx wie unten auf dem Bild zu sehen. Ich habe bei Slim Konsolen eigentlich nur mit einem 270pF Kondensator gute erfahrungen gemacht. Sollte die Box jedoch nicht booten könnt ihr es auch mit 220pF versuchen. Es ist ratsam, verschiedenfarbige Kabel zu verwenden. Bitte beschmiert nicht die Lötpunkte mit Heißkleber. Entweder ein Stück Isoband oder eben Heißkleber etwas hinter der Lötstelle über das Kabel kleben um es zu fixieren und das Lötpad zu schützen. Die Kabel auf der Unterseite können, wie unten im Bild zu sehen, durch eines der Löcher im Mainboard neben der Southbridge nach oben verlegt werden (bitte nicht die mit dem Kupferring benutzen - da müssen noch Schrauben durch ). Sollte die Konsole später nicht booten oder länger als 30 Sekunden zum Booten benötigen empfiehlt es sich, das "CPU_RST" Kabel um ca. 20-50cm zu verlängern. Ich konnte mit dieser Methode bei den Slims die Bootzeiten von weit über 2 Minuten auf 3-10 Sekunden senken. Man kann die Konsole immer auf "kaltboot" oder "warmboot" optimieren, da die Erfolgsraten zwischen kaltem und warmen Zustand stark variieren. Ich empfehle ersteres, da ein Kaltstart weitaus häufiger sein sollte.


Schaltplan des Xilinx Boards Slim




Schaltplan Oberseite Slim




Schaltplan Unterseite Slim



Hier ein Beispiel für das Ergebnis:

Oberseite Slim




Unterseite Slim





Jetzt noch den Xilinx in Schrumpfschlauch oder Isoband einpacken, damit es keinen Kurzschluss gibt

Installierter Xilinx Chip bei einer Slim Konsole



und den Chip mit etwas Klebe- oder Isoband fixieren

Nun legt ihr das Board wieder in den Käfig und fahrt mit dem Punkt "NAND auslesen, Xell Image erstellen und Flashen, CPU- und DVD-Key Recovery" fort.

[nightcode]

--7-- Verkabelung bei FAT (Zephyr, Opus, Falcon, Jasper) Konsolen --7--

In diesem Abschnitt wird die Verkabelung bei FAT Konsolen behandelt. Besitzer einer Slim Konsole überspringen bitte diesen Punkt.

Ihr benötigt:

• 3x 1N4148 Diode
• 1x 100nF Kondensator
• 1x 1kOhm Widerstand
• 1x 22kOhm Widerstand
• 1x Xilinx CoolRuner-II bzw C-Mod mit Zephyr/Falcon/Jasper Firmware
• Kabel
• Isolierband / Schrumpfschlauch

Sucht euch nun einen geeigneten Platz für den Chip (ich empfehle über dem Netzwerk Chip) und lötet die Kabel zwischen den Punkten auf dem XBOX Board und dem Xilinx wie unten auf dem Bild zu sehen. Die Dioden, Widerstände und der Kondensator können direkt auf dem Xilinx Board verlötet werden. Es ist ratsam, verschiedenfarbige Kabel zu verwenden. Bitte beschmiert nicht die Lötpunkte mit Heißkleber. Entweder ein Stück Isoband oder eben Heißkleber etwas hinter der Lötstelle über das Kabel kleben um es zu fixieren und das Lötpad zu schützen. Die Kabel auf der Unterseite können, wie unten im Bild zu sehen, durch eines der Löcher im Mainboard neben der Southbridge nach oben verlegt werden (bitte nicht die mit dem Kupferring benutzen - da müssen noch Schrauben durch ). Sollte die Konsole später nicht booten oder länger als 30 Sekunden zum Booten benötigen empfiehlt es sich, das "CPU_RST" Kabel um ca. 20-50cm zu verlängern.Sollte dies nicht funktionieren schaut bitte unter dem Punkt "Troubleshooting" nach alternativen Verkabelungen (besonders bei Jasper Revisionen). Falcon Boards sollten in der Regel sofort und ohne Probleme starten.


Schaltplan des Xilinx Boards FAT




Schaltplan Oberseite FAT




Schaltplan Unterseite FAT



Hier ein Beispiel für das Ergebnis:

Oberseite FAT




Unterseite FAT





Jetzt noch den Xilinx in Schrumpfschlauch oder Isoband einpacken, damit es keinen Kurzschluss gibt und danach mit Klebeband den Chip auf dem Mainboard fixieren.

Nun legt ihr das Board wieder in den Käfig und fahrt mit dem Punkt "NAND auslesen, Xell Image erstellen und Flashen, CPU- und DVD-Key Recovery" fort.

[nightcode]

--8-- NAND auslesen, Xell Image erstellen und Flashen, CPU- und DVD-Key ermitteln --8--


Als erstes müsst ihr den NANDSpeicher euerer XBOX360 auslesen. Hierfür empfehle ich den USB NAND Spi Flasher. Es gehen natürlich auch kommerzielle Programmer oder die alte LPT Variante. Der USB Spi Flasher ist jedoch sehr zuverlässig und man kann ihn selbst bauen.
Von einem LPT Flasher rate ich stark ab, da diese Lösung sehr fehleranfällig ist.

Selfmade USB NAND Spi Flasher



Lötet nun den NAND-Flasher auf die entsprechenden Punkte des Mainboards. Die unten zu sehenden Diagramme beziehen sich auf den selfmade USB Spi Flasher.


Verkabelung des Flashers bei Slim Konsolen






Verkabelung des Flashers bei FAT Konsolen






Nun schließt ihr zuerst das Kabel an eueren Flasher und steckt danach das Stromkabel der XBOX in das Mainboard (vorsicht das keine Kurzschlüsse entstehen wenn das Board im offenen Zustand unter Strom steht).
Als nächstes benutzt ihr das Programm "nandpro" von Tiros um den Speicher auszulesen. Ich habe dafür extra ein Batch Script geschrieben, das euch den Vorgang erheblich erleichtert. Die alten JTAG-erfahrenen Hasen können natürlich auch wie gewohnt das ganze per Konsole erledigen. Falls Nandpro irgendwelche Dateien fehlen installiert bitte den Port95NT Treiber.

Navigiert nun in den "nandpro20e" Ordner im Downloadpaket und startet die Datei "nandproscript.bat". Nun müsst ihr auswählen, ob ihr einen nandpro kompatibelen USB Nand Spi Flasher (1) oder einen LPT Flasher (2) benutzt.

Nandpro Interfaceauswahl



Danach gebt ihr die unter Punkt "4=>Ermitteln der Konsolenrevision" festgestellte Revision an.

Auswahl der Konsolenrevision



Diese schritte müsst ihr bei jedem Nandpro Start erledigen und ich werde im weiteren Verlauf nicht genauer darauf eingehen. Nun folgt das Nandproscript Hauptmenü.

Als nächstes wollen wir den kompletten NAND Speicher auslesen. Wir wählen dazu den Punkt (1) => NAND komplett auslesen.

Nandproscript Hauptmenü



Nandpro sollte nun einen Flash Controller erkennen und anfangen, den Speicher auszulesen. Sollte das nicht der Fall sein und ihr erhaltet die Nachricht "Could not detect a Flash Controller" oder "No Device Found", dann überprüft die Verkabelung des NANDFlashers und schaut unter dem Punkt "Troubleshooting" nach weiteren möglichen Lösungen.

Nach erfolgreichem Lesevorgang sollte der letzte ausgelesene Block 0x3FF und bei BigBlock Jasper Revisionen 0xFFF sein (siehe Bild) und ihr erhaltet die Datei "nandbackup.bin" im Nandpro Ordner. Speichert die datei sehr gut und möglichst redundant ab und fügt möglichst noch die Seriennummer der Konsole hinzu.

Nandpro Auslesevorgang (hier im Beispiel bei einer 16MB Konsole)



Falls ihr, wie im Bild zu sehen, Errors beim auslesen bekommt, handelt es sich höchstwahrscheinlich um einen BadBlock. Das sind fertigungsbedingte Fehler im NAND Chip und diese werden durch "Remapping" - also verschieben des Blocks in eine Reservezone - umgangen. Lest in einem solchen Fall den NAND immer mehrfach aus und schaut, ob der Fehler immer beim gleichen Block auftritt. Auch später beim Schreibvorgang sollte es an dieser Stelle eine Fehlermeldung geben. Um nochmals auf nummer Sicher zu gehen schaut mithilfe von 360FlashTool 0.97 aus dem Downloadpaket noch einmal nach, ob der BadBlock erfolgreich remapped wurde. Das erkennt ihr daran, dass ein reiter "Bad Blocks" erscheint, in welchem die BadBlocks sowie die dazugehörigen Reserveblöcke aufgeführt sind. Stimmt dieser Wert mit eueren Fehlern überein kanns weitergehen.

Startet nun den Lesevorgang erneut. Dieses mal werden jedoch nur die ersten 0x50 Blöcke (Option (2) ) ausgelesen, da wir vorerst nur diesen Bereich überschreiben und den Rest später über das Xell Webinterface auslesen. Aus beiden Teilen lässt sich im Notfall ebenfalls ein Originalimage generieren. Ihr erhaltet die Datei "nandbackup_50.bin".

Kopiert die erhaltenen Datei "nandbackup.bin" nun in den Ordner "Xell Glitch Builder" aus dem Downloadpaket. Ich habe hier wieder ein kleines Script geschrieben, was euch umständliche Konsoleneingaben erspart und gleich noch Python integriert, sodass die lästige Installation ebenfalls wegfällt.
Startet danach die build.bat. Falls ihr im Punkt 4 eine Jasper Revision ermittelt habt, wählt die (2). Ansonsten bitte (1) für alle anderen Konsolenrevisionen wählen.
Das Glitch Image wird nun erstellt. Dieser Vorgang kann einige Minuten dauern.
Achtet darauf, dass, wie im Bild am Beispiel einer Slim zu sehen, auch die richtige Konsolenrevision aufgelistet wird und keine Fehler beim erstellen auftreten.

Xell Glitch Builder Ausgabe



Danach überprüft das Script noch einmal die Existenz und größe des generierten Images.

Sollten während des Vorgans Probleme auftreten oder ihr eine Jasper mit CB Version 6751 besitzen, dann kopiert die Datei "nandbackup.bin" in den Ordner "my360" des 360_multi_builders und benennt sie in "nanddump.bin" um. Löscht die "cpukey.txt" und startet die "Run.exe". Das tool wird euch nach Revisionsangabe ebenfalls dieses Image erstellen, das danach im "Data" Ordner zu finden ist.

Falls alles passt habt ihr nun im "Xell Glitch Builder" Ordner die Datei "image_00000000.ecc".
Kopiert diese in den nandpro Ordner. Startet erneut das Script und wählt nun im Hauptmenü den Punkt (4) => NAND mit Xell ecc Image beschreiben. Nun startet der Schreibvorgang. Der letzte Block sollte bei allen Konsolen 0x4F sein.

Nun trennt ihr die Box wieder vom Strom, entfernt das Kabel vom NAND Flasher, verbindet sie danach wieder mit dem Stromnetz und und verbindet sie mit einem LAN-Kabel (möglichst an ein Netzwerk mit DHCP Server - z.B. ein Router etc.).

Nun heißt es warten bis die XBOX startet. Dieser Vorgang kann bis zu 2 Minuten dauern. Unter umständen glitcht eine Box auch garnicht. In diesem Fall einfach nochmal aus- und wieder einschalten. Ihr solltet anhand des Lüftergeräuschs ca. alle 5 Sekunden akustisch den Reset wahrnehmen. Sollte die Box trotzdem nicht starten wird es schwierig, da es kaum Debug Methoden gibt. Überprüft die Verkabelung, stellt sicher das die richtige Firmware auf dem Chip ist und schaut, falls das alles nichts hilft, unter dem Punkt "Troubleshooting" nach weiteren Lösungen.
Habt ihr alles richtig gemacht und noch etwas glück solltet ihr folgenden Bildschirm beim Start sehen.

Xell Reloaded Startbildschirm




Nach etwas Ladezeit bekommt ihr die CPU- und DVD-Keys zu sehen. Außerdem wird die IP-Adresse der Konsole angezeigt. Falls kein DHCP vorhanden ist vergibt die XBOX eine statische IP (glaube 192.168.1.99). In diesem Fall müsst ihr die Netzwerkkarte eueres Rechners für diesen Adressbereich konfigurieren.


Xell Reloaded CPU- und DVD-Key sowie IP-Adresse



Nun greifen wir auf das Xell Webinterface zu. Gebt dazu die ermittelte IP in den Browser am Rechner ein. Zuerst kopiert ihr CPU- und DVD-Key und erstellt eine Textdatei, in die Ihr die Schlüssel einfügt. Danach laden wir noch den Rawflash, die Keyvault sowie die Fuses herunter.

Xell Reloaded Webinterface



Herzlichen Glückwunsch! Euere XBOX Glitcht erfolgreich.

NUR FÜR DVD-KEY RECOVERY:
Für alle, die nur ihren DVD-Key retten wollen ist hier schluss. Benennt einfach die "nandbackup.bin" in "updflash.bin" um, kopiert sie in den nandpro Ordner und wählt im Hauptmenü den Punkt (3) => NAND komplett beschreiben, um die Konsole zurück in den Originalzustand zu versetzen
DVD-Key Recovery Ende

Alle, die sich ein gehacktes Dashboard installieren wollen, fahren nun mit dem Punkt Hacked Image erstellen fort.

[nightcode]

--9-- Hacked Image erstellen und flashen --9--

Nun erstellen wir uns ein gehacktes Freeboot bzw ggbuild Image. Dazu navigieren wir in den Ordner "360_multi_builder/Data/my360" des Downloadpakets. Kopiert die "nandbackup.bin" in diesen Ordner und benennt sie um in "nanddump.bin". Außerdem fügt ihr den CPU-Key der Box (nur der reine Key, keine Leerzeichen oder sonstwas) in die Datei "cpukey.txt".
Startet die "Run.exe". Sollte sie sich mit einem Fehler verabschieden einfach mehrfach versuchen. Wählt anschließend die unter Punkt 4 ermittelte Konsolenrevision aus und wählt danach Punkt 1 => Glitch Hack Image und darauffolgend wieder 1 => Built Image with Dashlaunch (falls ihr Dashlaunch gleich mit installieren Wollt was besonders ratsam ist).

360 Multi Builder




Nun generiert euch das Tool ein Hacked Image. Im Beispiel (Slim) tritt noch eine Fehlermeldung auf, die Ihr jedoch ignorieren könnt.

360 Multi Builder Ausgabe



Ihr erhaltet die Datei "nandflash.bin" im Ordner "Data". Falls ihr beim Auslesen BadBlocks hattet solltet ihr die Datei "xenon.elf" und "nandflash.bin" auf einen USB Stick kopieren, an die XBOX stecken, Xell starten und damit den NAND beschreiben.
Falls ihr keine BadBlocks hattet benennt die Datei "nandflash.bin" nach "updflash.bin" um und kopiert sie in den nandpro Ordner. Startet das Script und wählt zuerst den Punkt (5) => Kompletten NAND Speicher löschen. Danach startet ihr das Script erneut und wählt im Hauptmenü Punkt (3) => NAND komplett beschreiben. Hierbei gelten die gleichen Block und Fehlerregeln wie beim Auslesevorgang.

Nandpro Schreibvorgang am Beispiel einer 16MB Konsole



Trennt danach den USB Spi Flasher von der Box und startet sie. Das gehackte Dashboard sollte nun nach dem Glitch starten. Sollte dies nicht der Fall sein schaut bitte unter Troubleshooting.

[nightcode]

--10-- Troubleshooting --10--


Leider sind die Debugmethoden beim Reset Glitch Hack sehr bescheiden. Ich versuche in diesem Punkt dennoch auf einige Problem einzugehen.

ACHTUNG! Durch den modifizierten SMC landet die XBOX in jedem Fall in einer Endlosschleife und zeigt euch in der Regel keinen ROD an. So wird beispielsweise der klassische 0102 nicht angezeigt sondern die Box rebootet endlos. Sollte der hörbare Reboot in schnelleren Intervallen als 5 Sekunden auftreten lötet den Xilinx ab und flasht das Originalimage. Danach ist es wieder möglich, den Fehler zu identifizieren.

NandPro erkennt keinen Flash Controller

Falls ihr bei NandPro die Meldung "no device found" erhaltet überprüft, ob euer USB Spi Flasher richtig angeschlossen ist, erkannt wurde und auch der Treiber installiert ist. Das Gerät sollte im Windows Gerätemanager als "Memory Access" erkannt werden.

Wenn ihr die Meldung "could not detect a flash controller" erhaltet überprüft zuerst die Verkabelung und lötet gegebenenfalls nach. Geht folgendermaßen vor: USB Flasher an PC Kabel anschließen, danach an XBOX, danach XBOX Stromkabel einstecken. Sollte das nichts bringen könnt ihr einen Bad Flash Fix versuchen.
Im Ernstfall bleibt dann nur noch ein direkter NAND Programmer. Das wäre z.B. ein Infectus(2), Cygnos360 (Rev F bei BigBlocks) oder ProgSkeet etc.


Xell startet nicht

Das ist wohl eines der größten Probleme, denn hier ist es teilweise unmöglich den Fehler zu 100% ausfindig zu machen. Falcon Besitzer überprüfen bitte mit 360flashtool, dass ihre CB Version <= 5771 ist. Andernfalls ist die Konsole nicht kompatibel. Gleiches gilt für Jasper Konsolen mit CB größer als 6751. Als erstes sollten natürlich alle Löststellen peinlichst überprüft und eventuell durchgemessen werden. Beim Starten der Konsole sollte, wie bereits beschrieben, akustisch anhand der Lüfter ca. alle 5 Sekunden ein Reset zu hören sein. Bei Slim Konsolen lässt sich das auch optisch gut am Lüfter erkennen. Ist das nicht der Fall ist vermutlich etwas bei der Erstellung des ECC Images schiefgelaufen. Bitte verschiedene Tools testen.
Eine weitere Debug Methode ist eine LED zwischen Pin 15 und GND des Xilinx Boards zu löten. Diese sollte alle 5 Sekunden kurz aufleuchten.
Falls die Box dann immernoch nicht startet oder zu lange benötigt kann bei Slim Konsolen die CPU_RESET Leitung um 20-50cm verlängert werden (am besten Kabel mit 0,14er Querschnitt). Alternativ kann der 270pF Kondensator durch einen 220pF oder 330pF ersetzt werden.
Es sollten stets hochwertige Kupferlitzen mit einem 0,14mm Querschnitt verwendet werden. Lediglich bei der CPU_PLL_BYPASS funktioniert eine dünne Einzelader (z.B. aus einem IDE Kabel) oder Kuperlackdraht (davon rate ich definitiv ab!) oft besser.

Bei FAT Konsolen bieten sich folgende alternative Belegungen an:

Alternative 1



Alternative 2




Sollte auch das nichts helfen dann postet einfach das Problem möglichst detailliert hier im Forum.


Xell startet aber das Hacked Dash (Freeboot) nicht

Falls Xell erfolgreich bootet aber Freeboot nicht solltet ihr mit 360 Flash Tool den LDV analysieren. Beim generieren des Images wurde dieser wert am Ende angezeigt. Der LDV muss immer größer oder gleich der Anzahl der Buchstaben "f" im Fuseset 07 und 08 sein. Ist der Wert inkorrekt so könnt ihr ihn mit dem Parameter "cfldv" der Datei "options.ini" im "my360" Ordner des 360 Multibuilders erzwingen. Vergesst danach nicht, diesen Wert wieder zu entfernen!!!


E71 oder E79 beim Starten der Box

Hier sind höchstwahrscheinlich Bad Blocks im Spiel.
Überprüft mithilfe von 360FlashTool, ob die Blocks im Originaldum und erstellten Freeboot Image identisch sind. Falls nicht flasht das Image wie oben beschrieben über Xell und USB oder per Debian LiveCD und xbrflash.

[nightcode]

--11-- Downloads --11--


Reset Glitch Hack Downloadpaket v1.01 *02.12.2011*

• 360 FlashTool 0.97
• 360 Multi Builder 0.4 *aktualisiert*
• FreestyleDash 2, XeXMenu, Xbox360 Nandflasher *neu*, NXE2GOD
• Glitch Xell Builder Script v1.0
• LPT Programmer Software und Schaltplan
• nandpro 2.0e und nandproscript Glitch Edition v1.0
• Systemupdate 2.0.13604
• Wiring Diagramme
• XeX Menu ISO
• PC Tools zum entpacken etc. (Xbox360 ISO Extract XDG3 Support, ISO2GOD v1.3.6, FileZilla)

|uploaded| - |megaupload| - |share-online| - |FreakShare|




Reset Glitch Hack Downloadpaket v1.0 [veraltet!]

• 360 FlashTool 0.97
• 360 Multi Builder 0.3
• FreestyleDash 2, XeXMenu, Flash360, NXE2GOD
• Glitch Xell Builder Script
• LPT Programmer Software und Schaltplan
• nandpro 2.0e und nandproscript Glitch Edition
• Systemupdate 2.0.13604
• Wiring Diagramme
• XeX Menu ISO

|uploaded| - |megaupload| - |share-online|

[roym899]

Wow, sieht richtig gut aus. Werde es mir morgen mal durchlesen.

Edit: Sorry, wollte dir nicht dazwischen posten.

@mods: Bitte löschen oder nachunten verschieben.

[nightcode]

--12-- Softwareinstallation nach dem Hack --12--


Hier möchte ich nun auf Wunsch darauf eingehen, wie ihr die benötigte Software auf die XBOX bekommt. Generell empfiehlt sich hier eine interne Festplatte, auch wenn diese nicht sonderlich groß ist. Ihr könnt jedoch eine beliebig große 2,5" SATA Festplatte in das Originalgehäuse einbauen und danach in der XBOX formatieren. Die interne MU der Konsole sollte ebenfalls nicht benutzt werden. Außerdem werden die 4GB Speicher der Slim nur vom neuen Freestyledash 2.2 unterstützt.


Installation der Tools aus dem Softwarepaket

Im Folgenden werde ich darauf eingehen, wie ihr unkompliziert die XBOX Tools aus dem Softwarepaket (XeXMenu, FreestyleDash, NXE2GOD, etc) auf die Konsole kopiert, sodass sie sich danach aus dem Menüpunkt "Spieledemos und Testversionen" der Spielebibliothek starten lässt. Die Datenübertragung läuft mithilfe des im XeXMenu 1.1 integrierten FTP Servers via Netzewerk.
Als erstes müsst ihr die Konsole über Netzwerk mit dem PC verbinden. Am besten ihr hängt euch an einen Router mit DHCP Server wenn möglich, denn so spart ihr euch die Konfiguration der IP Adressen. Ansonsten legt sowohl in der XBOX als auch am Rechner eine IP im gleichen Adressbereich fest (z.B. Rechner: 192.168.1.250, XBOX 192.168.1.251).
Brennt nun die XeXMenu ISO aus dem Softwarepaket auf eine CD oder DVD und legt diese in die XBOX. Das Laufwerk muss dazu nicht geflashed sein. Startet das "Spiel" und wartet bis XeXMenu geladen ist. Nun 2x RB am Controller drücken und ihr könnt euere IP Adresse sehen (falls noch nicht bekannt).


XeXMenu IP-Adresse




Ich gehe im weiteren Verlauf immer auf die IP Adresse "192.168.2.158" ein. Wann auch immer die IP in einem Programm eingetragen werden muss gebt bitte die IP eurer Box ein.

Startet nun das Programm Filezilla aus dem Ordner PC Tools des Softwarepakets.
Öffnet nun den Servermanager wie im Bild zu sehen.


FileZilla Servermanager




Als nächstes klickt ihr auf "New Site", tragt die IP-Adresse der Konsole ein und wählt bei Benutzername und Passwort jeweils "xbox".

FileZilla Servermanager



Nun müsst ihr nur noch im Reiter "Transfer Settings" den "Transfer Mode" auf "Active" stellen, da sonst keine Verbindung zustande kommt.


FileZilla Transfereinstellungen




Betätigt nun die Schaltfläche "Connect" und FileZilla sollte sich zur XBOX verbinden. Die Ordnerstruktur der Konsole erscheint im rechten Fenster, den lokalen Rechner erreicht ihr über das linke Fenster. Kopiert nun den Inhalt des Ordners "FSD Paket..." nach hdd1.
Beendet das XeXMenu und navigiert zum Unterpunkt "Spieledemos und Testversionen" in der Spielebibliothek. Es sollten die eben installierten Tools auftauchen und ihr könnt die CD aus dem Laufwerk nehmen.


Programme in der Spielebibliothek







Spiele als GoD Container auf die interne Festplatte installieren


Als erstes müsst ihr die Konsole über Netzwerk mit dem PC verbinden. Am besten ihr hängt euch an einen Router mit DHCP Server wenn möglich, denn so spart ihr euch die Konfiguration der IP Adressen. Ansonsten legt sowohl in der XBOX als auch am Rechner eine IP im gleichen Adressbereich fest (z.B. Rechner: 192.168.1.250, XBOX 192.168.1.251). Startet nun das Programm XeXMenu aus der Spielebibliothek.
Nun 2x RB am Controller drücken und ihr könnt euere IP-Adresse sehen (falls noch nicht bekannt).


XeXMenu IP-Adresse




Ich gehe im weiteren Verlauf immer auf die IP Adresse "192.168.2.158" ein. Wann auch immer die IP in einem Programm eingetragen werden muss gebt bitte die IP eurer Box ein.
Lasst die Konsole laufen und das Programm offen. XeXMenu stellt einen FTP-Server zur Verfügung und ohne diesen kann sich der PC nicht zur Konsole verbinden.
Um die Spiele aus der Spielebibliothek zu starten müsst ihr zunächst die ISO Datei in einen GoD Container umwandeln. Benutzt dazu das Tool "ISO2GOD" aus dem Ordner PC Tools des Softwarepakets.
Zunächst müsst ihr unter Settings ein paar Einstellungen vornehmen. Aktiviert den FTP Transfer und gebt einen Standard Output- sowie Rebuild Pfad an. Das Programm generiert die ISO komplett neu (Rebuild Path) um sie dann wieder zu entpacken. Dies sind beides nur temporäre Verzeichnisse, da die neue ISO und die GoD Container nach Transfer auf die Konsole gelöscht werden können. Bei Padding solltet ihr "Full (ISO Rebuild)" nehmen, da ihr auf diese Weise Speicherplatz einsparen könnt. Die Haken bei "Always safe rebuilt Iso" und "Ask if rebuild ISO should be saved" entfernen, es sei denn ihr wollt die rebuild ISO dauerhaft behalten (sinnlos).


ISO2GOD Einstellungen




Klickt nun im Hauptprogramm auf "Add ISO" und fügt auf diesem Weg beliebig viele ISO Dateien hinzu. Gebt dem Spiel ggf. einen neuen Namen und stellt sicher, dass alle benötigten Pfade vergeben wurden.


ISO2GOD Spiel hinzufügen




Nachdem ihr die ISOs fertig eingetragen habt klickt einfach auf "Convert".
Das Programm erstellt nun für jedes Spiel einen Ordner mit GoD Containern und kopiert ihn auf die XBOX. Falls der Transfer nicht klappt können die generierten Ordner auch einfach per FileZilla (siehe oben => Installation der Tools) in den Ordner "HDD1/Content/0000000000000000" kopieren.

Habt ihr diese Schritte abgeschlossen sollten sich die Spiele direkt aus der Spielebibliothek ohne irgend ein Zusatztool starten lassen.



Spiele von einer externen USB-Festplatte / USB-Stick starten


Ich kann nur nochmals wärmstens die obere Version mit den Spielen als GoD Container empfehlen. Ist aber auch Budget- und Geschmackssache.

Ihr benötigt eine externe USB Festplatte oder einen USB Stick. Der Datenträger muss zwingend Fat32 formatiert sein. Erstellt einen Ordner "Games". In diesen müsst ihr später die Spiele in entsprechende Unterordner entpacken.
Startet das Tool "XBOX360 ISO Extract" aus dem Ordner PC Tools des Softwarepakets (es kommt auch mit dem neuen XDG3 Format klar).
Wählt über "Choose ISO Folder" den Ordner mit der/den entsprechenden ISO(s) aus. Falls ihr einen Haken bei "recursive" setzt werden die Unterordner rekursiv durchsucht und somit jede ISO Datei geladen. Als nächstes wählt ihr über "choose destination" den Ordner "Games" auf der externen Festplatte. Nach einem Klick auf "Go" beginnt der Prozess.


XBOX360 ISO Extract mit XDG3 Support




Schließt danach die Festplatte an einen USB Anschluss der XBOX und startet das FSD2 aus der Spielebibliothek. Hier sollten unter XBOX360 Games die Spiele auftauchen.
Falls das nicht der Fall ist könnt ihr in den FreestyleDash Einstellungen die Scantiefe auf 4 oder 5 stellen.




Spiele von DVD installieren

Um ein Spiel von DVD aus auf die interne Festplatte zu installieren wählt den klassischen Weg, also Spiel einlegen, Y drücken und dann auf "Spiel Installieren". Nun startet ihr einmalig nach der Installation eines oder mehrerer neuer Spiele das Tool "NXE2GOD" aus dem Menüpunkt "Spieledemos und Testversionen" in der Spielebibliothek. Das Programm erkennt automatisch die zu patchenden Spiele und listet sie auf. Durch Bestätigen mit A werden die Spiele innerhalb kürzester zeit gepatcht und ihr beendet das NXE2GOD mit einem weiteren Druck auf A.
Jetzt könnt ihr die Spiele ohne Disc aus der Spielebibliothek starten.

Falls ihr das Spiel auf die externe USB-Festplatte installieren wollt startet in der Spielebibliothek das Programm "FSD2" und wählt unter "Utilities" den Punkt "Copy DVD".
Nach gültiger Pfadangabe wird das Spiel auf die externe HDD kopiert und lässt sich danach aus dem FSD starten.

[nightcode]

*platzhalter2*

[nightcode]

*Platzhalter3*

[andy.macht]

wow ein tut von vorne bis hinten
hut ab!

[nightcode]

Irgendjemand muss dich doch entlasten

[starchildx]

hey, klasse tutorial, hab eine kleine anmerkung, es gibt bei jasper boxen ab und zu probleme dass xell und oder das dashboard hängen bleibt. hatte den fehler selber, ein 100nf kondensator von cpu reset (also zwischen widerstand und kontakt aufm motherboard) zu GND anlöten. der glitch kommt dann auch nach maximal 6 sekunden und der freeze ist dann auch weg....

[derlangeandreas]

Das ist der absolute oberburner! Respekt!

[iglitare]

hey, klasse tutorial, hab eine kleine anmerkung, es gibt bei jasper boxen ab und zu probleme dass xell und oder das dashboard hängen bleibt. hatte den fehler selber, ein 100nf kondensator von cpu reset (also zwischen widerstand und kontakt aufm motherboard) zu GND anlöten. der glitch kommt dann auch nach maximal 6 sekunden und der freeze ist dann auch weg....

cpu pll bypass gegen masse, nicht cpu-reset...