🏾 ✖️ 💨 Schützen und Hacken der Xbox 360 (Teil 3) 🤳🏿 🐶 🤛🏾

Im Jahr 2011, 6 Jahre nach der Veröffentlichung der Xbox 360-Spielekonsole, entdeckten die Forscher eine interessante Tatsache: Wenn das Signal „0“ für eine sehr kurze Zeit an den RESET-Ausgang des Zentralprozessors gesendet wird, setzt der Prozessor seinen Status nicht zurück (wie es sein sollte), sondern stattdessen ändere dein Verhalten! Basierend auf dieser „Funktion“ wurde Reset Glitch Hack (RGH) entwickelt , mit dessen Hilfe der Schutz der Xbox 360 vollständig gefährdet, nicht signierter Code ausgeführt werden konnte, wodurch das System selbst gehackt und die „unzerbrechlichen“ DG-16D5S-Laufwerke besiegt werden konnten .

Schauen wir uns genauer an, wie RGH funktioniert, wie die Entwickler versucht haben, ein Loch zu flicken, und wie diese Patches umgehen konnten!

Was ist ein Glitch-Angriff?

Der Prozessor ist ziemlich dumm, egal was Vermarkter sagen. Der gesamte von Programmierern geschriebene High-Level-Code reduziert sich auf die Ausführung einfacher Befehle - Arithmetik mit Zahlen, sich bewegenden Daten, bedingten und bedingungslosen Sprüngen. Es wird davon ausgegangen, dass der Prozessor diese Befehle immer fehlerfrei ausführt und das Ergebnis mit der Dokumentation übereinstimmt.

In der Tat, den Code zu kompilieren

i = i + 2;

Sie verlassen sich auf die Tatsache, dass sich der Wert der Variablen i um genau 2 erhöht, ohne zu wissen, wie es anders sein könnte.

Glitch-Angriffe verletzen dieses Vertrauen - ihr Ziel ist es, sicherzustellen, dass der Prozessor „fehlerhaft“ ist und sich falsch verhält. Es gibt verschiedene Möglichkeiten, den Prozessor zu „stören“, zum Beispiel:

CPU-Spannung abbauen
Um der Referenzfrequenz der CPU einen zusätzlichen Impuls zu geben
"Shine" auf prozentuale Strahlung

Es gibt spezielle Geräte, um solche Angriffe auszuführen - zum Beispiel bietet ChipWhisperer eine breite Palette von Angriffen in Frequenz und Leistung:

Bei der Xbox 360 tritt aufgrund der Exposition gegenüber der RESET-Leitung ein „Fehler“ auf. Der Prozessor beginnt mit dem Zurücksetzen, hat jedoch aufgrund der sehr kurzen Dauer des Signals keine Zeit, es abzuschließen, und arbeitet weiter, als wäre nichts passiert. Aber nur für diesen kurzen Moment, während das RESET-Signal aktiv ist, ändert sich sein Verhalten!

Glitch-Prozessor

Der Xbox 360-Schutz beruht auf Bootloadern, die sich gegenseitig in einer Kette überprüfen. Letztendlich kommt es bei der Überprüfung in jeder Phase darauf an, die Funktion des Vergleichens der Hash-Summe mit dem „Muster“ aufzurufen. Zu diesem Zeitpunkt wendeten sie den Glitch-Angriff an und zwangen den Prozessor, die Nichtübereinstimmung zu ignorieren. Ein Impuls an die RESET-Zeile unmittelbar nach dem Aufrufen der memcmp- Prozedur zwingt den Prozessor, einen anderen Zweig zu "durchlaufen" und weiter zu laden, selbst wenn die Hash-Summe falsch ist:

Der beste Ort zum Angriff wurde im Bootloader der zweiten Stufe "CB" gefunden. Die späteren Phasen sind schwieriger anzugreifen (und leicht zu beheben), aber in der ersten Phase des Ladens („1BL“, ROM) schlug der Angriff aufgrund einer etwas anderen Konstruktion des Programmcodes fehl.

Es klingt einfach, aber tatsächlich wurden beim Versuch, einen Angriff auszuführen, viele Nuancen entdeckt.

Um einen Glitch-Angriff erfolgreich durchzuführen, ist es zunächst erforderlich, den Zeitpunkt, zu dem ein RESET-Impuls angelegt werden soll, sehr genau zu bestimmen. Wenn Sie mindestens eine Mikrosekunde lang einen Fehler machen, einen zu kurzen oder langen Impuls senden, funktioniert der Angriff nicht.

Glücklicherweise wird auf Xbox 360 jeder Startschritt von einer Wertänderung auf dem POST_OUT- Debug-Bus begleitet. Darüber hinaus ist die Debug-Ausgabe so oft angeordnet, dass unmittelbar vor dem Vergleich der Hash-Summe ein neuer POST-Wert festgelegt wird:

Das Schließen der Position der Debug-Ausgabe von der Angriffsstelle war daher ein äußerst praktischer Auslöser. POST_OUT ist ein paralleler Bus und wird an 8 Teststellen auf der Leiterplatte ausgegeben, von denen jede für eines der Bits des Werts verantwortlich ist. Es war sogar möglich, das Verbindungsschema mit nur einem Bit zu vereinfachen und die Anzahl der Änderungen in seinem Status seit dem Start des Systems zu zählen:

Es stellte sich auch heraus, dass es aufgrund der hohen Frequenz des Prozessors fast unmöglich ist, hinsichtlich Genauigkeit und Dauer den richtigen Zeitpunkt zu finden. Die Belichtungszeit sollte in der Reihenfolge der Ausführungszeit eines Befehls durch den Prozessor sehr kurz sein. Aber je langsamer der Prozessor läuft, desto länger passt das Zeitintervall. Deshalb nehmen und verlangsamen wir den Prozessor!

Auf einem normalen PC wird die CPU-Frequenz als Produkt aus externer Referenzfrequenz und Multiplikator definiert:

In der Xbox 360 sind externe Leitungen der Referenzfrequenz für den Prozessor geeignet und werden innerhalb dieser Frequenz mit PLL multipliziert . Und bei den alten, „dicken“ Versionen der Set-Top-Box konnte der PLL-Mechanismus ausgeschaltet werden, wodurch der Prozessor um das 128-fache verlangsamt wurde:

Bei den "Slim" -Versionen kann der PLL-Trick nicht ausgeführt werden (die Linie ist auf der Platine nicht getrennt), und da wir den Faktor in "Slim" nicht beeinflussen können, reduzieren wir die "Referenz" -Frequenz!

Es wird vom HANA-Chip generiert und kann über den I2C-Bus konfiguriert werden:

Leider war es nicht möglich, viel zu reduzieren, "bei niedrigen Geschwindigkeiten" begann die endgültige Prozessorfrequenz stark zu "schwimmen", was die Erfolgschancen verringerte. Die stabilste Option war eine Verlangsamung um das 3,17-fache. Nicht 128 Mal, aber zumindest etwas.

Alle? Überhaupt nicht. Es ist weit davon entfernt, dass der Angriff beim ersten Mal funktioniert (insbesondere bei Slim). Wenn der Start fehlschlägt, wird das Präfix neu gestartet und versucht erneut zu starten. Es werden nur 5 Versuche zum Starten gegeben, wonach das Präfix stoppt und der „rote Ring des Todes“ zu blinken beginnt. Daher patchen wir auch die South Bridge-Firmware (SMC), damit sie nicht unter Müll leidet, und starten das Präfix neu, bis es blau wird:

Also bekommen wir den Algorithmus:

Patch SMC
Prozent verlangsamen (über PLL oder I2C)
Warten auf einen POST-Trigger
Warten auf N Mikrosekunden
Impuls an RESET senden
Prozent schneller zurück

Für eine höhere Genauigkeit der Berechnungen nehmen wir die Frequenz von derselben HANA (48 MHz):

Und wir bekommen ein solches Design basierend auf dem preiswerten CPLD Xilinx XC2C64A:

Vergessen Sie nicht, mit der Länge und Position der Verkabelung auf dem RESET zu schamanisieren (achten Sie auf die "Spule" am unteren Rand des Fotos) und vorwärts, hoffen Sie, dass der Start innerhalb einer Minute klappt.

Dies ist jedoch nur auf der Hardwareseite. Wie patchen wir den Bootloader und stopfen unseren Code?

Patchlader

Wie bereits erwähnt, wird der Bootloader der zweiten Ebene, "CB", angegriffen. Dieser Bootloader ist mit einem festen Schlüssel verschlüsselt, der für alle Konsolen gleich ist, aber nur "CB" kann nicht geändert werden, wir greifen ihn nur an. Der nächste ist jedoch bereits mit einem CPU-Schlüssel verschlüsselt, der für jede Set-Top-Box eindeutig ist. Und um es zu ändern, müssen Sie diesen Schlüssel kennen ...
oder nicht?

In den alten "dicken" Revisionen der Xbox 360 wurde im CB-Loader der sogenannte "Zero-Pairing" -Modus unterstützt, der in der Produktionsphase der Konsole verwendet wird. Der Header jedes Bootloaders bei Offset 0x10 enthält einen zufälligen Pairing-Datensatz, der als Teil des Schlüssels für die Entschlüsselung verwendet wird. Und wenn dieser Datensatz vollständig aus Nullen bestand („Zero-Pairing“), wurde der Prozessorschlüssel ignoriert und stattdessen ein fester Nullschlüssel verwendet!

Mit diesem Trick war es möglich, ein Image mit dem Original "CB" zusammenzustellen, den nächsten Bootloader "CD" (mit eigenem Code) mit einem Nullschlüssel zu verschlüsseln und mit RGH auszuführen!

In den Konsolen wickelte „Slim“ diesen Trick ein, entfernte den „Zero-Pairing“ -Modus und teilte den „CB“ in zwei Teile. Hier wurde "CB" in ein sehr einfaches und kleines "CB_A" unterteilt und mit dem Prozessorschlüssel "CB_B" verschlüsselt:

Die Verschlüsselung mit dem RC4-Algorithmus (CB_B wird mit diesem Algorithmus verschlüsselt) weist jedoch eine Besonderheit auf. Bei der Verschlüsselung basierend auf dem Schlüssel wird ein pseudozufälliger Datenstrom erzeugt, der binär mit den Quelldaten „addiert“ wird (Operation 'exklusiv oder', 'xor'). Beim Entschlüsseln geschieht dementsprechend dasselbe: Durch Hinzufügen mit demselben Pseudozufallsstrom werden die Daten auf ihren ursprünglichen Wert zurückgesetzt:

Die binäre Additionsoperation ist jedoch kommutativ und assoziativ, was bedeutet, dass wir die verschlüsselten Daten ändern können, ohne den Schlüssel zu kennen, nur für xor 'und den verschlüsselten Code mit dem Patch, den wir benötigen!

Infolgedessen können wir "CB_A" verschlüsseln, das verschlüsselte "CB_B" patchen (damit es überhaupt keine Entschlüsselung durchführt) und "CD" im Klartext mit seinem Code einfügen!

Kurz gesagt, wenn Sie es zusammenstellen, sieht der Start ungefähr so aus:
(XeLL ist der Bootloader von Homebrew, Linux, und es werden auch die CPU-Schlüssel angezeigt.)

Microsoft schlägt zurück

Natürlich hat Microsoft versucht, alles zu reparieren.

Beim neuen Systemupdate wurden alle alten Konsolen auf einen "separaten" Start von "CB_A" und "CB_B" übertragen, wodurch der "Zero-Paired" -Modus endgültig geschlossen wurde. Auf Slim wurden auch Bootloader aktualisiert. Die neuen Bootloader wurden zum Schutz vor RGH stark modifiziert, wobei der Schutz von CB_A im Vordergrund steht:

Debug-Ausgabe im POST vollständig entfernt
Die Hash-Überprüfung wurde aus Gründen der Zuverlässigkeit wiederholt und dupliziert
Im gesamten Code wurde sleep () für eine zufällige Zeit eingestellt (abhängig vom CPU-Schlüssel !!)
CBLDV-Fusionsprüfung hinzugefügt, um CB_A zu widerrufen

Die Liste der Innovationen lässt für RGH keine Chance. Aber achten wir auf den letzten Punkt auf der Liste - vorher gab es in CB_A keine Fusionsprüfung! Fataler Fehler. Darüber hinaus ist, wie wir uns erinnern, der Prozessorschlüssel nicht an der Decodierung von „CB_A“ beteiligt. Dies bedeutet, dass der für RGH anfällige CB_A-Loader auf jeder Konsole gestartet werden kann und dies nicht verboten werden kann.

Aber um mit Hilfe dieses verletzlichen "CB_A" etwas zu beginnen, müssen Sie ein wenig ausweichen. Wenn wir den CPU-Schlüssel nicht kennen, müssen wir nur noch den vorhandenen „CB_B“ patchen. Was aber, wenn wir nicht einzelne Abschnitte ändern, sondern den gesamten Bootloader vollständig überschreiben? Und aus diesem Grund "schreiben" Sie den alten Bootloader, den wir bereits patchen können, um den neuen zu ersetzen? Also taten sie:

Wir verschlüsseln die anfällige CB_A auf die gleiche Weise wie im Originalbild
XOR unser CB_B mit dem neuen, den "Unterschied" bekommen
Wir setzen es auf das verschlüsselte "CB_B"!

Alles wieder, ohne den Schlüssel zu kennen, haben wir den verschlüsselten Inhalt erfolgreich ersetzt und auch den anfälligen Bootloader eingesetzt. Konsolen hacken, Microsoft sind überrascht.

Die Entwickler haben hart gearbeitet und im nächsten Systemupdate ... die Verschlüsselungsmethode "CB_B" leicht geändert, jetzt ist der Verschlüsselungsschlüssel auch von der Version von "CB_A" abhängig geworden:

Beim Versuch, die Daten zu xor 'und in das anfällige "CB_A" der alten Version zu verschieben, entschlüsselte der Bootloader den Müll aufgrund unterschiedlicher Schlüssel. Und der neue Bootloader kann nicht gehackt werden, er ist gut vor Glich-Angriffen geschützt. Bisher Sieg für Microsoft!

Corona wirft Probleme

In der Zwischenzeit kam eine neue Version der Xbox 360, Corona, auf den Markt und brachte Modder Probleme:

Nicht genug Chips auf dem Board, kannst du es finden? Richtig, der HANA-Chip war in der Südbrücke "versteckt". Es gibt keinen anderen Ort, an dem die Frequenz von 48 MHz für den Mod-Chip verwendet werden kann. Die vorherigen I2C-Verlangsamungsbefehle funktionieren nicht. Was ist das? Der 16-MB-NAND-Flash, der in all den Jahren als Xbox 360-Systemspeicher diente, wurde auf verräterische Weise durch einen 4-GB-Chip mit eMMC-Schnittstelle ersetzt! (Stimmt, nur in der günstigeren Version der Konsole, aber immer noch):

Aber nichts, alles wurde erledigt. Wir haben herausgefunden, wie man Flash-Speicher über einen Kartenleser liest / schreibt:

Es wurden neue I2C-Verlangsamungsbefehle gefunden. Ein externer 48-MHz-Quarzoszillator ersetzte HANA:

Abgeschlossene Build-Skripte, Unterstützung für 4 GB NAND hinzugefügt ...

Aber Microsoft steckte weiterhin Stöcke in die Räder. Auf den neuen Platinen sind beispielsweise einige Widerstände verschwunden, ohne die der Mod-Chip nicht mehr funktioniert:

Dies wurde zwar durch die Installation von Steckbrücken mit einem Lötkolben behoben:

Die Dinge wurden ernster, als die POST_OUT-Tracks vom Board verschwanden:

Aber hier hatte Microsoft kein Glück, die für RGH benötigten CPU-Bälle befanden sich in der äußersten Reihe:

Und natürlich konnten sie sich mit ihnen verbinden. Zuerst die meisten Ärmel, die den Rand des Prozessors leicht aufbohren und mit der Verkabelung direkt auf die Kugel löten:

Und dann veröffentlichten die Chinesen ein Gerüst mit einer federbelasteten Nadel, die genau auf dem Ball ruhte, und das Problem wurde für alle anderen gelöst:

Die letzte Grenze

Nachdem wir die „Krone“ besiegt hatten, gab es ein Problem: Neue Versionen des Systems gaben dem Hacking nicht nach. Um RGH zu starten, müssen Sie den CPU-Schlüssel kennen, und um den CPU-Schlüssel herauszufinden, müssen Sie RGH mindestens einmal ausführen. Das Problem von Huhn und Eiern im Allgemeinen.

Und dann kam ein Gedanke auf - und lassen Sie uns nicht nur die "Glitch" -Authentifizierung überprüfen, sondern auch die Entschlüsselung überspringen! Wenn es klappt, müssen wir den Schlüssel nicht kennen, setzen Sie "CB_B" klar, das ist alles. Diese Idee bildete die Grundlage von Double Glitch Hack (DGX):

Dieser Chip "fehlerhaft" den Prozentsatz zweimal, der erste Impuls übersprang die Entschlüsselungsphase des Bootloaders und der zweite Impuls übersprang die Authentifizierung. Es funktionierte viel weniger stabil, da mindestens ein erfolgreicher Start erforderlich war - dann erhalten wir den CPU-Schlüssel und fahren wie zuvor fort.

DGX war nicht lange relevant, nach 3 Monaten warfen die Chinesen die Veröffentlichung von „DGX RIP“ mit Bildern ein, die auf Set-Top-Boxen laufen, mit Standard-RGH arbeiten und natürlich viel stabiler starten:

Diese Bilder enthielten eine spezielle Version des CB_A-Bootloaders, der in der Xbox 360-Produktion verwendet wurde, und sind in der Tat ein vollständiges Analogon zum guten alten „Zero-Pairing“ -Modus. Anstelle des Prozessorschlüssels entschlüsselte dieses "CB_A_mfg" "CB_B" mit einem festen Nullschlüssel:

Und hier ist Microsoft. In dieser "Service" -Version von "CB_A" gab es auch keine Fusionsprüfung und es war unmöglich, sie zu verbieten. Es genügte, das Bild gemäß der Revision der Xbox 360 aufzunehmen, den Chip zu löten - und alles funktionierte.

Winchester!

RGH wurde nur in der neuen Version der Konsole mit dem Codenamen Winchester vollständig behoben. Zum ersten Mal, wenn CPU- und GPU-Prozessoren in einem Chip kombiniert wurden, wurde die Karte so weit wie möglich vereinfacht:

POST_OUT-Tracks wurden nicht nur entfernt. Auch wenn Sie unter dem Prozessor auf die Plattform löten:

Und selbst wenn Sie den Prozessor mit einer speziellen Version der Platine für Entwickler, XDK, verlöten, wo diese Spuren noch vorhanden sind:

Bei POST_OUT ist beim Starten der Konsole nur ein Impuls sichtbar. Bus gesperrt:

Darüber hinaus ist es nur in der Produktionsphase gesperrt. Wenn Sie einen "sauberen" Prozessor aus einer Fabrik nehmen, in der Sie noch keine Sicherungen gebrannt haben, arbeitet POST_OUT daran!

Aber RGH darauf funktioniert nicht mehr. Unabhängig davon, wie Sie versuchen, einen RESET-Impuls zu geben, führt der Prozessor einen Reset korrekt durch oder ignoriert Ihr Signal aufgrund seiner zu kurzen Dauer. Anscheinend wurde dem Prozessor ein spezielles Logikmodul hinzugefügt, das die RESET-Leitung filtert und damit schließlich den Hardwarefehler behebt.

Post scriptum

Es stellt sich heraus, dass die neueste Version der Xbox 360 nicht zu hacken ist?

Ja und nein. Derzeit ist nur eine Möglichkeit bekannt, ein modifiziertes System mit einer Winchester-Revision auszuführen.

Das Software Development Kit (XDK) enthält verschiedene private Schlüssel zum Signieren von kompiliertem Code. Und so stellte sich heraus, dass unter ihnen der Signaturschlüssel „shadowboot“, ein Bootloader der dritten Ebene für XDK-Systeme, überfüllt war. Und damit können Sie ein legitimes signiertes Bild mit geänderter Firmware sammeln. Arbeiten Sie einfach an gewöhnlichen "Laden" -Konsolen, das wird er nicht. Wir benötigen einen Prozessor mit der XDK-Version der Konsole oder eine „saubere“ CPU mit nicht abgesicherten Sicherungen (Sie können dies auf Aliexpress sehen):

Und nur dann haben Sie die Möglichkeit, eine solche Inschrift in den "Systeminformationen" der benutzerdefinierten Shell zu betrachten:

Und das ist alles! Wie üblich bin ich bereit, Ihre Fragen in den Kommentaren zu beantworten :)

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

Schützen und Hacken der Xbox 360 (Teil 3)