Säure zersetzt das mechanische Herz
Am 13. September 2026 veröffentlichte der kanadische Hardware-Enthusiast DiscoStarslayer den vollständigen Prozess zur Extraktion der Firmware aus dem originalen PlayStation-2-Sicherheitschip CXP102064. Dieser Steuerbaustein, der 1999 mit den ersten Konsolen vom Band lief, hielt Angriffen 26 Jahre lang stand – bis er schließlich hochkonzentrierten chemischen Reagenzien und Hochleistungsmikroskopen weichen musste. Die vielschichtigen hardwarebasierten Verschlüsselungsmechanismen, die Sony einst implementierte, wurden auf physikalischer Ebene aufgebrochen.
In der Geschichte der Videospielkonsolen bleibt die PS2 mit über 155 Millionen weltweit verkauften Einheiten ein unübertroffener Rekordhalter. Bei einer derart gewaltigen Gerätebasis und einer jahrzehntelangen Lebensdauer bedeutete der Black-Box-Status der Kernkomponenten, dass Low-Level-Reparaturen und hardwarenahe Emulationen stets auf Vermutungen und Notlösungen angewiesen waren.
Der als MechaCon (kurz für Mechanism Controller) bekannte Spezialchip ist weit mehr als eine gewöhnliche Recheneinheit. Er steuert direkt die mechanischen Abläufe des optischen Laufwerks sowie die Schreib- und Lesezugriffe auf den Flash-Speicher. Zugleich fungiert er als einzige Hardwareschnittstelle für die Authentifizierung von MagicGate-Speicherkarten und die Entschlüsselung zentraler ausführbarer Dateien (KELF). Das Abriegeln dieser Schlüsselebene glich einer vollständigen Versiegelung der obersten Validierungsautorität der Konsole über physische Medien und externe Speichermedien.
Als diese ersten Konsolen das Werk verließen, hatten Sonys Ingenieure die Sicherheitslogik fest verdrahtet tief im Epoxidharz vergossen. Der Versuch, den internen Zustandsraum über herkömmliche Softwaretests oder Brute-Force-Verfahren abzutasten, überstieg die damaligen Rechenkapazitäten bei Weitem.
Bild: Der nach chemischer Zersetzung der Schutzschicht freigelegte PS2-Sicherheitschip. Quelle: Tom’s Hardware
Ätzende Flüssigkeiten und Mikroskope legen das Silizium frei
Das chemische Freilegen (Decapping) ist eine anspruchsvolle Laborarbeit, die Schutzanzüge und den Umgang mit hochaggressiven Flüssigkeiten erfordert. Die Forscher benötigten vier volle Jahre, um mit erhitzten Säurelösungen die äußere Kunststoffkapselung des Chips schichtweise aufzulösen, bis die mikroskopisch feinen Leiterbahnen auf dem Silizium-Die vollständig freilagen.
Im Anschluss folgte die optische Extraktion. Unter Hochleistungsmikroskopen fotografierte das Team die freigelegte Schaltung Schicht für Schicht in extrem hoher Auflösung. Durch Bildabgleich und algorithmische Rekonstruktion wurden die abgebildeten Logikgatter Schritt für Schritt in digitale Logik zurückübersetzt. Mit ingenieurtechnischer Ausdauer wurde so die physische Hardwarestruktur Schicht um Schicht in lesbaren Programmcode transformiert.
Hardwareverschlüsselung bietet niemals absolute physische Unangreifbarkeit. Solange ein Siliziumchip in der realen Welt physisch existiert, degradieren die vom Verteidiger aufgebauten Barrieren letztlich zu einer Frage von Zeit und Aufwand für den Angreifer.
In der Schlussphase dieser langwierigen Analyse gelang dem Team ein überraschender Durchbruch. Die Sicherheitsforscherin Libby entdeckte in den noch verrauschten, unvollständigen optischen Datensätzen eine ausnutzbare Software-Schwachstelle, die den Weg zum vollständigen Auslesen der Firmware drastisch verkürzte.
Beteiligte Entwickler ziehen drei klare technische Grenzen
Meilensteine im Hardware-Reverse-Engineering werden in der Öffentlichkeit oft überschwänglich aufgebauscht. In den Diskussionsspalten technischer Berichte zog der an dem Projekt beteiligte Entwickler uyjulian jedoch umgehend klare Grenzen für die praktische Tragweite des Erfolgs.
Er betonte, dass der bloße Besitz der ausgelesenen Firmware keineswegs sofort zu einem einsatzbereiten optischen Laufwerksemulator (Optical Drive Emulator, ODE) führt. Die aktuellen Methoden zur Datenextraktion erfordern nach wie vor umfangreiche Schreibvorgänge in bestimmte Speicherbereiche, sodass bis zu einer perfekten, zerstörungsfreien Nachbildung noch einige physikalische Kopplungshürden zu nehmen sind.
| Technischer Angriffspfad | Community-Workarounds der letzten 20 Jahre | Konkreter technischer Nutzen durch den Low-Level-Code |
|---|---|---|
| Ausführen von Sicherheitskopien | Abhängig von Speicherkarten-Lücken, Festplatten-Exploits oder Softmods | Verifikations-Bypasses erfordern kein blindes Raten mehr, gezielte Ausnutzung logischer Schwachstellen |
| Bau von Optical Drive Emulatoren (ODE) | Benötigte spezifische Mainboard-Revisionen und Hardware-Hijacking | Ermöglicht Ersatzplatinen, die den zentralen Sicherheitschip direkt ersetzen |
| Region-Lock-Bypass und Systemrechte | Softwarebasierte Privilegien-Eskalationsketten über spezielle Tools | Liefert authentischen Quellcode als Referenz für Reverse-Engineering-Projekte |
Den technischen Durchbruch auf den konkreten ingenieurtechnischen Nutzen einzugrenzen, zeugt von professioneller Zurückhaltung. Die Inhalte regulärer Spiel-Discs waren ohnehin nie verschlüsselt; abgesehen von Online-Verifikationsbestandteilen bietet der Firmware-Dump daher keine Abkürzungen zur Entschlüsselung von Spieldaten.
Bild: Mainboard-Architektur der PlayStation 2 und Positionierung des MechaCon-Chips. Quelle: Neoteo
Software-Exploits versus hardwarebasiertes Reverse Engineering
Vor diesem physikalischen Teardown konzentrierte sich die Homebrew-Forschung an frühen PS2-Modellen vorwiegend auf das Auffinden von Software-Schwachstellen. Ob weithin bekannte Boot-Exploits oder Pufferüberläufe über das optische Laufwerk: All diese Ansätze blieben letztlich Flickwerk innerhalb der vom Hersteller definierten Berechtigungsarchitektur.
Der proprietäre Sicherheitschip bildet das Fundament der gesamten Vertrauenskette (Root of Trust) der Konsole. Solange er als Black Box operierte, blieb Entwicklern akkurater Emulatoren nichts anderes übrig, als sein Verhalten anhand beobachteter Ein- und Ausgangssignale nachzubilden.
Die Einzigartigkeit des hardwarebasierten Reverse Engineerings liegt in seiner physischen Beständigkeit. Auf Softwareebene entdeckte Sicherheitslücken konnten in späteren Hardwarerevisionen jederzeit geschlossen werden. Doch bei einem 1999 in Epoxidharz gegossenen Silizium-Die ist die Anordnung der Transistoren auf dem damaligen Fertigungsstand für immer eingefroren.
Sobald ein optisches Mikroskop die feste Verdrahtung des Festwertspeichers (ROM) erfasst hat, liegt der kryptografische Bauplan offen da. Der Aufwand, monatelang unscharfe mikroskopische Aufnahmen zu entziffern, ist immens – doch das Resultat ist eine universelle Lösung, die unabhängig von einzelnen Software-Schwachstellen Bestand hat.
Fundamente für die digitale Langzeitarchivierung
Das bloße Ausführen von Homebrew-Software wurde bereits vor über zehn Jahren durch zahlreiche Soft- und Hardware-Patches gelöst. Spätere Konsolenrevisionen erlaubten es Nutzern sogar, unsignierte optische Medien direkt über eingespeiste Patches zu laden.
Der eigentliche Wert der Offenlegung der chipinternen Logik liegt in der präzisen Low-Level-Emulation und der Bewahrung des digitalen Kulturguts. Wenn nach über 20 Jahren Betrieb die Elektrolytkondensatoren eines Mainboards austrocknen und der Sicherheitsbaustein physisch durchbrennt, müssen Restauratoren nicht länger auf Gebrauchtmärkten nach intakten Spenderplatinen suchen.
Dank des vollständigen Verständnisses der Authentifizierungsabläufe und der Regeln zur Entschlüsselung von Binärdateien kann die Open-Source-Community künftig kostengünstige, programmierbare Logikbausteine (FPGAs) nutzen, um sämtliche Signalfolgen und Rückmeldungen dieses betagten Sicherheitschips exakt nachzubilden.
Die Abwehr solcher Sicherheitschips war stets ein Kräftemessen zwischen Rechenkapazität und Zeitinvestition. Der bleibende Wert besteht darin, die Reparatur historischer Hardware und die digitale Emulation von einzelnen, unweigerlich alternden Sammlerstücken in einer Schublade zu lösen. An ihre Stelle tritt ein quelloffener, beliebig oft reproduzierbarer Code-Bestand, der auf modernen Systemen neu kompiliert und betrieben werden kann. Wollen künftige Emulatoren die damalige Ablaufumgebung originalgetreu rekonstruieren, greifen Entwickler künftig direkt auf diese Blaupause zurück.
Weiterführende Links:
- Bericht auf Tom’s Hardware
- Lobsters-Diskussion
- PSDev Wiki
- MechaPwn- und TonyHax-Projekte
- Öffentliche Dokumentation von DiscoStarslayer
