👩🏻‍🎨 🌊 🐬 Schützen und Hacken der Xbox 360 (Teil 1) 🖕🏾 🐀 👩🏻‍🌾

Sie haben wahrscheinlich schon von der Xbox 360-Spielekonsole gehört und dass sie „blinkt“. Mit "Firmware" ist hier eine Umgehung der integrierten Schutzmechanismen zum Starten von Kopien von Spielen und proprietärer Software gemeint. Und hier stellen sich Fragen! Welche Mechanismen, wie kommen sie herum? Was haben die Entwickler getan, wie haben sie es geschafft, das zu umgehen? Tatsächlich ist das Thema sehr umfangreich und interessant, insbesondere für die Xbox 360 - hier finden Sie Software-Schwachstellen, Hardware-Fehler und absolut magische Magie. Interessant? Vorbeikommen! Im ersten Teil werden wir mit dem Hypervisor, den Laufwerken und der Firmware vertraut gemacht ...

Treffen Sie das Thema

Die Xbox 360-Spielekonsole wurde 2005 veröffentlicht und hat seitdem keine Änderungen an den Eigenschaften von Eisen erfahren. Die ganze Zeit, in der es veröffentlicht wurde, waren sie gleich:

3,2 GHz PowerPC-CPU, / 3 Kerne
500 MHz GPU
512 MB RAM
SATA DVD-ROM
SATA-Festplatte (optional)

Ja, das Design hat sich im Laufe der Zeit geändert, die Nanometer haben abgenommen:

Trotzdem funktionierten alle Spiele auf allen „Revisionen“ von Konsolen gleich gut - genau dies ist der Fall, wenn moderne Spiele auf Geräten von 2005 ausgeführt werden können.

Zum Zeitpunkt der Veröffentlichung wurde lautstark erklärt, dass die Konsole so sicher wie möglich entwickelt wurde - benutzerdefinierte Chips mit Schutz auf Hardwareebene, und im Allgemeinen haben Hacker dies noch nicht gesehen:

In dieser Box wird es Sicherheitsstufen geben, die die Hacker-Community noch nie gesehen hat

Was haben sich die Entwickler ausgedacht?

Erstens haben sie alles getan, damit der Programmcode des Systems nicht erhalten werden konnte . In den Zentralprozessor wurde ein 32-KB-ROM mit einem Primärlader (1BL) und einem 64-KB-SRAM eingebaut, in dem er ausgeführt wurde. Es ist sehr, sehr schwierig, den Inhalt eines ROM von einem CPU-Chip zu erhalten:

Zweitens wurden spezielle Sicherungen in denselben Prozessor eingesetzt - gebrannte (buchstäblich Hochspannungs-) Jumper, eine Art einmal programmierbarer Speicher. Die Sicherungen enthalten:

JTAG-Schnittstellensperrbits
Bits, die den Zweck des Präfixes bestimmen (Retail / Devkit / Testkit)
eindeutiger 128-Bit-Prozessorschlüssel
LDV-Zähler (Lock-Down Value) zum Deaktivieren des Downgrades

Ja, das Ausmaß der Fusion ist begrenzt. Wenn Sie es schaffen, Ihre Konsole 80 Mal hintereinander zu aktualisieren, wird der CFLDV-Zähler beendet und ... Ich weiß nicht, ich habe nicht versucht, dies zu tun. Wahrscheinlich wird das Präfix nicht mehr aktualisiert.

Drittens haben die Entwickler eine Vertrauenskette implementiert . Um die Authentizität von Bootloadern zu überprüfen, wurde eine Kombination aus modernen (zu dieser Zeit) SHA-1- und RSA-2048-Algorithmen verwendet, die die Möglichkeit ausschloss, einen eigenen Code zu starten oder Bootloader nicht autorisiert zu ändern, selbst wenn Sie irgendwie alle Schlüssel von der Konsole erhalten und das System neu erstellen konnten .

Viertens beschlossen die Entwickler, das Prinzip "niemandem vertrauen" weiter zu verfolgen und ein spezielles Hardwaremodul zum Schutz des Arbeitsspeichers in dieselbe unglückliche CPU zu integrieren ! Mit seiner Hilfe wurden alle Bereiche mit Programmcode verschlüsselt und die Integritätsüberwachung für die wichtigsten Bereiche (Hypervisor) aktiviert!

Auf diese Weise verteidigten sich die Entwickler gegen DMA-Angriffe, wenn sie über externe Geräte, die Zugriff auf RAM haben, den Systemprogrammcode im RAM ändern.

Schließlich befasste sich der Hypervisor mit der Differenzierung von Rechten in Speicherbereiche . Nur er konnte die Seiten natürlich ausführbar machen, bevor er die digitale Signatur überprüfte, so dass es unmöglich war, nicht signierten Code herunterzuladen oder etwas aus dem Datenbereich auszuführen, selbst durch eine Sicherheitslücke in einem Treiber oder Spiel (die Achse und die Spiele wurden mit Kernel-Rechten gestartet). .

Infolgedessen war das Xbox 360-Betriebssystem gut geschützt, und daher wurde DVD-ROM als erster Angriffsvektor ausgewählt.

Wir starten ... Backups!

In der Xbox 360 wurde eine Dual-Layer-DVD als Hauptmedium für Spiele ausgewählt. Natürlich waren auch hier Abwehrmechanismen vorhanden:

Der Datenaustausch mit DVD-ROM wurde mit einem eindeutigen Schlüssel verschlüsselt
Am Anfang der CD befanden sich spezielle „Sicherheitssektoren“, um die Lizenzierung zu bestätigen
Ausführbare Dateien auf der Festplatte wurden digital signiert

Dem Schutz des DVD-Laufwerks wurde jedoch viel weniger Aufmerksamkeit geschenkt als dem Hauptsystem. Die Spielekonsole zeigte zu viel Vertrauen in das DVD-Laufwerk - es war die DVD-ROM, die die Lizenzierung der Disc bestimmte. Darüber hinaus wurde die Firmware im externen Speicher gespeichert und konnte vom Programmierer gelesen werden:

Infolgedessen veröffentlichte Commodore4eva (c4eva) am 14. Mai 2006 die erste modifizierte Firmware für das TS-H943-Modell:

README für die Firmware-Version

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

Die Firmware las Sicherheitssektoren aus festen Bereichen auf einer DVD und betrog die Konsole, sodass sie den Eindruck erweckte, dass eine lizenzierte Disc eingelegt wurde.

Gleichzeitig wurde die Firmware 0800 veröffentlicht, mit der Kopien von Spielen erstellt und Sicherheitssektoren gelesen werden können. Das Xbox 360-Laufwerk, das mit einer solchen Firmware geflasht wurde, wurde auf dem Computer erkannt und konnte die Sektoren der Spiel-CD vollständig lesen.

README zur Verwendung der 0800-Firmware

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Ein anderes Spiel könnte teilweise mit dem folgenden Trick kopiert werden:

Legen Sie in eine Computer-DVD-ROM gewöhnliche Zweischicht-Disc
Warten Sie, bis es sich beruhigt und nicht mehr dreht
Öffnen Sie mit einer Büroklammer das Fach und wechseln Sie das Laufwerk von der Xbox 360 zum Spiel
Schließen Sie das Fach und erstellen Sie ein Disk-Image!

(Es funktionierte nicht bei allen DVD-ROM-Modellen.)

Das Wichtigste ist, dass das Laufwerk ausschließlich per Software mit speziellen ATA-Befehlen geflasht wurde. Das Kit enthielt ein spezielles Programm zum Lesen der Original-Firmware und zum modifizierten Schreiben. In der ursprünglichen Firmware wurde der geschätzte Schlüssel gespeichert, mit dem das Laufwerk an die Xbox 360 gebunden wurde:

Der Verlust des Schlüssels führte dazu, dass selbst lizenzierte Festplatten nicht gestartet werden konnten. Einige schrieben den Schlüssel in ein Notizbuch und speicherten ihn, wo immer dies möglich war. Dies war das am meisten geschätzte Wissen.

Ein separates Thema war die Panik über das Online-Spiel. Alle hatten Angst, dass Microsoft herausfinden würde, dass das Laufwerk geändert wurde, und die Konsole remote deaktivieren würde. Einige haben sogar einen Hardware-Mod entwickelt, um zwischen werkseitiger und modifizierter Firmware zu wechseln:

Sie spielten auf der ursprünglichen Firmware "in Lizenz" und trennten sie mit einer Verbindung zum Netzwerk schändlich über das modifizierte Internetkabel. Übrigens war die Panik nicht umsonst, aber solche Mods waren völlig umsonst, alles wurde protokolliert, ohne eine Verbindung zum Netzwerk herzustellen.

Genau einen Monat später (15. Juni 2006) wurde die Firmware auf ein anderes Laufwerksmodell portiert, das zu diesem Zeitpunkt auf der Xbox 360 installiert war - Hitachi GDR3120L. Er hatte auch ein externes Flash-Laufwerk mit Firmware:

Dieses Laufwerk war besser geschützt:

Die Firmware wurde verschlüsselt im ROM gespeichert
Es gab eine Integritätskontrolle in der Firmware
Um die Firmware zu überschreiben, musste man in einen speziellen „Modus B“ wechseln.

Und wenn die Forscher die ersten beiden Punkte selbst schafften, sollte das Kunststück der Übersetzung in „Modus B“ von allen ~~jungen~~ Blinkern wiederholt werden .

Es wurde vorgeschlagen, diese Aktion mit einer speziellen Bootdiskette unter Slax Linux oder durch Kurzschließen der Kabel beim Start durchzuführen. Die Kontakte 0 und 9 des Antriebsstromanschlusses mussten kurzgeschlossen werden. Zum Beispiel mit Stiften!

In beiden Fällen wurde das Laufwerk nach solchen Missbräuchen in Windows als normales DVD-Laufwerk definiert, auf dem es aufgenommen, ~~vergewaltigt~~ und zusammengefügt wurde.

Nach der ersten Veröffentlichung wurden benutzerdefinierte Firmwares fertiggestellt, die Stabilität verbessert und die Unterstützung für neue Spiele hinzugefügt. Im Allgemeinen war alles wie gewohnt.

Microsoft Antwort

Die Entwickler zu den Vorwürfen, dass die "unzerbrechliche" Konsole gehackt wurde, antworteten einfach:

Das System wurde nicht gehackt, wir haben gerade gelernt, wie man Kopien von Spielen startet, wir arbeiten daran

ursprüngliche Antwort

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

Was wurde wirklich getan, um die Situation zu korrigieren:

Samsung TS-H943 wurde mit der ms28-Firmware ausgeliefert, die durch den bekannten ATA-Befehl nicht in den Firmware-Modus wechselte
Hitachi GDR3120L erschien mit den Firmware 0078 und 0079 und blinkte auch im Modus B nicht
Neue BenQ-LiteOn VAD6038-Laufwerke werden angezeigt
Die ersten spitzen "Verbote" von Piraten auf Xbox Live begannen, Piraten war es verboten, für immer online zu spielen

Wenn mit dem Verbot (zu diesem Zeitpunkt) alles eindeutig und irreparabel war, fanden die Forscher bald die Antriebe heraus:

Für Hitachi wurde das Entsperren des Firmware-Modus über eine spezielle Audio-Disc gefunden
Samsung ms28 und BenQ VAD6038 sind über kostengünstige SATA VIA 6421-Controller perfekt in den Firmware-Modus übergegangen

Verlassen wir das Schlachtfeld für eine Weile mit der Firmware für Laufwerke. Es gab keine sehr interessante Zeit, in der Forscher versuchten, "Stealth" -Firmware zu erstellen, um nicht von Xbox Live gebannt zu werden. Passen Sie sich neuen Spielen mit neuen "Wellen" an - Systemaktualisierungsversionen und portieren Sie die Ergebnisse auf alles eine wachsende Auswahl an Firmware und Laufwerken. Trotzdem wurde alles zusammengefügt, die "Backups" wurden erfolgreich gestartet, die Xbox 360 wurde bei den Leuten immer beliebter ...

Achse brechen!

Wie Sie sich aus dem ersten Teil der Geschichte erinnern, verfügte das Xbox 360-System über einen Hypervisor, der alles und jeden kontrollierte. Also. In einer Version des Systems trat plötzlich eine Sicherheitslücke auf! Wie genau die Forscher die Hypervisor-Codebeispiele erhalten haben, ist mir nicht sicher. Tatsache ist jedoch, dass die Forscher Ende 2006 nicht signierten Code auf der Xbox 360 veröffentlicht haben. Anfang 2007 wurde die Sicherheitsanfälligkeit von den Entwicklern behoben:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

Der Hypervisor hatte eine Funktion - im Gegensatz zum Rest des Codes wurde er nicht im virtuellen Adressraum ausgeführt, sondern im physischen (Real-Modus). Die Sendung wurde nicht verwendet, Anrufe wurden direkt getätigt (Adressen der Form 0x00000000'xxxxxx). Entweder wurde dies aus Gründen der Geschwindigkeit oder der Einfachheit halber durchgeführt ... Und hier war eine Funktion des Xbox 360-Adressraums:

Der Zugriffsmodus auf den Speicher wurde durch seine physische Adresse bestimmt. Die wichtigsten Bits der Adresse hatten nämlich einen offiziellen Zweck. Beispielsweise bedeutete die Adresse 0x00000 0 00'0000201C direkten Zugriff auf die Adresse 0x201C, und 0x00000 1 00'0000201C bedeutete, dass Sie die Integrität im laufenden Betrieb entschlüsseln und überprüfen müssen, wenn Sie dieselbe physische Adresse 0x201C lesen.

Dementsprechend müssen Sie sich auf Adressen wie 0x00000 1 00'xxxxxxxx beziehen, damit die Ausführung mit aktivierter Verschlüsselung und aktiviertem Schutz ausgeführt werden kann. Erst dann enthielt das Hardwaremodul Schutzmechanismen. Daher wurde auf Hardwareebene das gewünschte Bit automatisch hinzugefügt (das spezielle HRMOR-Register war dafür verantwortlich - Hypervisor Real Mode Offset Register)!

Noch einmal - sobald der Hypervisor auf eine Adresse wie 0x00000 0 00'xxxxxxxx zugreift, ändert die MMU diese Adresse automatisch in 0x00000 1 00'xxxxxxxx, einschließlich Verschlüsselung und Schutz! Versuche, den Code "direkt" aus dem physischen Speicher ohne Schutz und Verschlüsselung auszuführen, sind zum Scheitern verurteilt ... oder nicht?

Schauen wir uns den anfälligen Code der Hypervisor-Version 4532 an:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

Sehen Sie den Gopher? Aber er ist! Der Befehl Cmplwi funktioniert mit 32-Bit- Werten, aber rldicr - mit 64-Bit ! Das heißt, wir können den Wert 0x20000000'0000002A als Systemrufnummer angeben, er besteht den Test (da der untere 32-Bit-Teil kleiner als 0x61 ist), und als Ergebnis wird anstelle der Adresse 0x10EC die Adresse des Handlers von 0x80000000'000010EC übernommen!

Und dann, wie sie sagen, pass auf deine Hände auf. Die höchstwertigen Bits der Adresse sind nicht gleich Null, HRMOR wird nicht hinzugefügt ! Und da der reale Adressraum 32-Bit ist, wird das von uns festgelegte 63-Bit einfach ignoriert. Wir haben den Hypervisor in den unverschlüsselten und unsicheren Speicher umgeleitet, indem wir einfach eine falsche Systemrufnummer übermittelt haben!

Aber warten Sie, damit wir springen können, müssen wir in der Lage sein, unsere Daten in den physischen Speicher zu schreiben. Wie erreicht man das?

Hier kommt der zweite Faktor ins Spiel - die GPU auf der Xbox 360 war intelligent, sogar zu intelligent. Er unterstützte eine spezielle Shader-Anweisung, MemExport, zum Hochladen von Geometriedaten in den physischen Speicher. Das heißt, Sie können den Shader kompilieren, auf der GPU ausführen und damit überall etwas aufzeichnen! Und am wichtigsten ist, dass die Shader nicht signiert wurden. Wenn Sie die Spiel-CD in irgendeiner Weise ändern, können Sie den Shader-Code problemlos ersetzen.

Eine Frage blieb offen. Wie ersetze ich den Shader-Code auf der Spiel-CD? Und hier war das Hacken des DVD-Laufwerks der Konsole sehr nützlich. Wir haben einen Shader geschrieben, ihn im Image des Spiels ersetzt, auf einer CD aufgezeichnet und Linux gestartet!

Ja, um es auszuführen, musste ich das Spiel jedes Mal starten, warten, bis der Exploit funktioniert, die Bootdiskette unter Linux stellen, aber das war zumindest etwas!

Wie bereits erwähnt, hat Microsoft ein Systemupdate veröffentlicht, mit dem die Sicherheitsanfälligkeit des Hypervisors behoben wurde. Aber was ist, wenn Sie einen anfälligen Kernel zurückgeben?

Downgrade!

Im Allgemeinen wurde die Architektur der Xbox 360 vor Downgrade geschützt. In den Prozessor-Hardware-Sicherungen wurde jedes Mal, wenn das nächste Bit während des Upgrades gebrannt wurde (Sperrwert, LDV erhöht), und wenn diese LDV in den Sicherungen und im System nicht übereinstimmte, wurde die Konsole einfach nicht gestartet.

Betrachten Sie die Xbox 360-Bootloader-Struktur, nämlich "Bootloader-Abschnitte":

Es ist ersichtlich, dass das Bild mehrere Sätze von Bootloadern enthält, von denen jeder einem LDV entspricht. In diesem Beispiel sind dies 1888 für LDV 0, 16767 für LDV 3 und 16756 für LDV 2.

Alle Aktualisierungen des Systems selbst wurden in den Abschnitten 6BL / 7BL aufgezeichnet und einfach als Patches auf den Basis- "Kern" 5BL 1888 "angewendet" . Aber welcher Satz von Patches angewendet werden sollte, wurde gemäß dem vorgeschriebenen LDV in den Sicherungen und Bootloader-Headern ausgewählt! Und gerade bei 5BL konnte der Header mit einem großen ABER geändert werden - der Header wurde mit der darin aufgezeichneten HMAC-SHA-1-Hash-Summe verglichen. Und es wurde von gewöhnlichen memcmp überprüft .

Wenn Sie immer noch nicht verstehen, wohin die Dinge gehen, haben Sie hier einen Zeitangriff (Timing Attack) durchgeführt. Die Standardfunktion memcmp schließt den Vergleich unmittelbar nach der ersten Diskrepanz ab. Daher können Sie durch Ändern des ersten Bytes des Hashs und Erkennen der Laufzeit von memcmp den gewünschten Wert auswählen (die Überprüfungszeit erhöht sich damit). Wenn Sie weiter fortfahren, können Sie alle Bytes der Hash-Summe abrufen!

Zur Messung wurde der Debug-Bus POST_OUT verwendet. Es funktioniert wie ein PC. Zu verschiedenen Ladezeiten wird ein Einzelbyte-Wert angezeigt, anhand dessen Sie beurteilen können, wo der Prozessor gerade ausgeführt wird und welcher Fehler aufgetreten ist. Tatsächlich sind dies 8 Punkte auf dem Motherboard, von denen jeder für einen bestimmten Wert verantwortlich ist:

Nachdem Sie an diese Punkte gelötet haben, können Sie einfach die Ausführungszeit jeder Download-Phase messen und feststellen, ob ein Fehler aufgetreten ist.

Der gesamte Prozess der Hash-Auswahl dauert ungefähr eine Stunde:

Als Ergebnis erhalten wir ein Image, in dem das aktuelle LDV für den Kernel installiert ist, wodurch keine Patches angewendet werden und die älteste Version des 1888-Systems gestartet wird! Von wo aus ist es bereits möglich, auf die anfällige Version 4532 zu aktualisieren:

Natürlich hat Microsoft diese Sicherheitsanfälligkeit behoben, indem der allererste aktualisierte Bootloader (2BL, "CB") aktualisiert und die CBLDV-Sicherung gebrannt wurde, wodurch ein Downgrade erneut unmöglich wurde. Jetzt wurde anstelle von memcmp die sichere Version mit derselben Laufzeit verwendet, unabhängig von den Eingabewerten.

JTAG Hack!

Aber hier gaben die Forscher nicht auf und fanden eine Lücke. Ja, so dass sich die Entwickler das gar nicht vorstellen konnten.

Im normalen Betriebsmodus der Konsole sind alle Bootloader in einer Kette miteinander verbunden. Infolgedessen hängt die Entschlüsselung jedes Bootloaders vom Datenbereich im Header des vorherigen Bootloaders ab (Pairing Data). Darüber hinaus hängt die Verschlüsselung des Codes vom eindeutigen Prozessorschlüssel ab, sodass Sie kein Arbeitsimage erstellen und zusammenstellen können, ohne CPU_Key zu kennen. Oder ist es möglich?

In der Konsolenproduktionsphase (wenn der Prozessorschlüssel noch nicht in Sicherungen gebrannt wurde) wird ein spezieller Xbox 360-Startmodus verwendet, wenn das Pairing von Daten Null ist (Zero-Pairing). Und ein solches Image (mit einem anfälligen Kernel!) Kann auf jeder Konsole ausgeführt werden, ohne den Prozessorschlüssel zu kennen!
Leider wird es keinen vollständigen Start geben. Dieser Fehler wird folgendermaßen aussehen:

Das heißt, das King Kong-Spiel kann nicht gestartet werden, der Exploit durch Shader kann nicht aktiviert werden ... Aber der anfällige Kernel startet bereits! Vielleicht gibt es eine andere Möglichkeit, den RAM aufzuzeichnen? Es stellte sich heraus, dass es gibt.

Für den Anfang löten wir drei freie GPIOs der Südkonsole der Konsole an die GPU-JTAG-Pins:

Dann ändern wir die Firmware der South Bridge (sie ist verschlüsselt, aber nicht signiert) und sammeln das Image mit dem anfälligen Kernel. Dann passiert die Magie:

Beim Start klettert die Südbrücke der JTAG-GPU auf PCI Express und konfiguriert den NAND-Controller
Beim Lesen schreibt der NAND-Controller nun Daten in den von uns benötigten Speicherbereich
Der Kern des Systems startet und informiert die Südbrücke darüber, dass das System gestartet wurde
Die Südbrücke zieht den NAND-Controller, überschreibt den RAM an der richtigen Stelle und nutzt die Schwachstelle des Hypervisors aus!
Die Kontrolle wird auf unseren Code übertragen. Tun Sie, was wir wollen

Kurz gesagt, sie haben alles genauso gemacht wie in King Kong Shader Exploit, aber cooler - es ist nicht nötig, das Spiel zu starten und die Discs zu wechseln.

Auf der Grundlage von JTAG Hack wurden modifizierte Versionen des Systems erstellt - XBReboot, Freeboot mit deaktivierter Signaturüberprüfung, bei denen bereits Piraten herumliefen. Spiele können nicht nur von USB-Laufwerken und -Disketten gestartet werden, sondern auch über das SMB-Protokoll direkt von einem Computer aus.

Wichtig ist, dass ein vollwertiger System-Hack denjenigen eine Chance gab, die den DVD-Schlüssel verloren hatten und nicht abspielen konnten. Mit dem Prozessorschlüssel war es nicht schwierig, den DVD-Schlüssel zu extrahieren.

Natürlich hat Microsoft hier die Sicherheitsanfälligkeit schnell geschlossen, 2BL erneut aktualisiert und den Wert von CBLDV erhöht. Damit endete das Epos des anfälligen Hypervisors, und die Leute rannten los, um die Reste der "JTAG-kompatiblen" Konsolen in Geschäften zu kaufen - jeder wollte problemlos mit USB-Sticks spielen. In Foren wurden Diskussionen darüber geführt, welche Bundles mit welchem Veröffentlichungsdatum zum Hacken geeignet sind ...

Das Thema Änderungen am Xbox 360-System blieb fast zwei Jahre lang stehen, aber das Thema Firmware entwickelte sich weiter. Und gerade in der Firmware der LiteOn-Laufwerke brach der umfangreichste Kampf zwischen Forschern und Microsoft aus. Aber mehr dazu im nächsten Artikel :)

Links:

GoogleTechTalks-Bericht
King Kong Hack
Timing Attack
JTAG / SMC Hack

Xbox 360 Schutz und Hacking, Teil 1 Xbox 360
Schutz und Hacking, Teil 2
Xbox 360 Schutz und Hacking, Teil 3

PS Wer sich für Details interessiert, werde alle Fragen zum Thema in den Kommentaren beantworten!