Anfang November 2026 veröffentlichte der Reverse-Engineering-Entwickler Andrew Spode einen bemerkenswerten Hardware-Hack: Auf einer namenlosen Kinder-Spielzeugkamera für umgerechnet kaum zehn Euro gelang ihm die vollständige Portierung des legendären Ego-Shooters DOOM. Das Spiel läuft flüssig mit rund 30 Bildern pro Sekunde, unterstützt alle Bewegungs- und Schussfunktionen und liefert dazu polyphone Soundeffekte sowie Originalmusik.
Das äußere Gehäuse besteht aus bunt bedrucktem Billigplastik mit Zeichentrickmotiven. Auf der Verpackung fehlen Herstellername und Markenlogo völlig; in der Anleitung findet sich lediglich die kryptische Modellbezeichnung „X9S“. Doch im Inneren des Plastikgehäuses arbeitet ein ausgewachsener 32-Bit-SoC aus chinesischer Fertigung: der HX3302B.
Um die Stückkosten auf ein absolutes Minimum zu drücken, greift die White-Label-Lieferkette konsequent auf fertige Standard-Steuerchips zurück. Dadurch verfügt das Spielzeug über weitaus mehr Rechenleistung, als für einfache Schnappschüsse jemals nötig wäre. Um das Produkt möglichst schnell auf den Markt zu werfen, sparte man sich in der Referenz-Firmware jegliche Sicherheitsprüfungen. Das hermetisch wirkende Spielzeug verwandelte sich so in eine perfekte Spielwiese für Hardware-Hacker.
Abbildung: Die Spielzeugkamera rendert DOOM mit 30 FPS auf ihrem Miniatur-Farbdisplay. Quelle: Spode’s Abode.
DOOM auf 891 KB freiem RAM: Zehn-Euro-Spielzeug liefert 120 MIPS
Vor dem Öffnen des Gehäuses waren im Netz praktisch keine technischen Dokumentationen zu dem Gerät auffindbar. Den entscheidenden Hinweis lieferten die EXIF-Metadaten geschossener Testfotos: Im Herstellerfeld stand „HX-Tech“ – ein Name, der bereits in früheren Teardowns des Hardware-Hackers Jeroen Domburg aufgetaucht war.
Spode lötete die Batteriekabel ab und entnahm die Platine. Das Herzstück bildet der HX3302B-Chip zusammen mit einem 8-poligen 4-MB-SPI-Flash-Baustein. Mithilfe eines Programmiergeräts las Spode die Firmware aus; die Analyse bestätigte, dass der Prozessorkern auf dem OpenRISC-Befehlssatz basiert.
Benchmarks offenbarten das Leistungsprofil des SoCs. Der stromsparende Prozessor verfügt über jeweils 8 KB L1-Befehls- und Daten-Cache bei einem Cache-Durchsatz von 164 MB/s. Er erreicht bis zu 120 MIPS Spitzenleistung und hält selbst bei häufigen Sprungvorhersagefehlern solide 82 MIPS. Diese Rechenleistung reicht vollkommen aus, um die Raycasting- und Projektionsberechnungen einer über dreißig Jahre alten 3D-Engine mühelos zu stemmen.
Der eigentliche Engpass lag beim Arbeitsspeicher. Das Gesamtsystem verfügt über gerade einmal 2 MB physisches RAM mit einer Leserate von 65 MB/s. Da Systemdienste und der Display-Framebuffer den Großteil belegen, blieben für eigenen Code exakt 891 KB freier Heap-Speicher übrig. Während Taktzyklen reichlich vorhanden waren, musste die gesamte Spiel-Engine in weniger als ein Megabyte gequetscht werden.
Abbildung: Der HX3302B-SoC und der 8-Pin-Flash-Speicher auf der Platine. Quelle: Spode’s Abode.
Blinder Firmware-Dump per EXIF: Referenzdesign spart alle Prüfungen ein
Die Update-Routine der Firmware bot den ersten Hebel zum Aufbrechen des Systems. Beim Einschalten sucht die Kamera im Stammverzeichnis der SD-Karte nach einer Datei namens Xly100s.bin. Obwohl im Dateikopf ein Prüfsummenfeld vorgesehen ist, gleicht der Bootloader-Updater den Hashwert schlichtweg nie ab.
Zudem nutzt die Aktualisierungsroutine ein einfaches Überschreibverfahren: Das Flashen beginnt an der Basisadresse des Speichers und schreibt exakt so viele Bytes wie die Eingabedatei groß ist. Wird eine 1-MB-Datei eingespielt, überschreibt das System lediglich das erste Megabyte; die verbleibenden 3 MB des Flashs bleiben unberührt. Eine winzige Anpassung des Zeitstempels im Header genügt, um den Flash-Vorgang zu starten. Der Speicherkartenslot fungiert somit als offenes Einfallstor für ungeprüften Schadcode.
Nachdem Schreibzugriff etabliert war, musste das Speicherlayout offengelegt werden. Spode entwickelte dafür einen verblüffenden Trick: Er leitete den Speicherinhalt direkt in die EXIF-Header geschossener Fotos um. Der JPEG-Standard erlaubt bis zu 64 KB an EXIF-Metadaten, doch die Firmware der Kamera nutzte standardmäßig nur etwa 730 Bytes.
Spode patchte die Bildspeicherroutine der Kamera. Da der festverdrahtete Hardware-JPEG-Encoder keinen direkten Zugriff auf den Boot-Speicher hat, kopierte Spode den gewünschten Speicherbereich stückweise per CPU in den EXIF-Puffer. Jeder Druck auf den Auslöser erfasste 4 KB Daten und verschob den Adresszeiger um ein Fenster. Nach 16 Fotos war der komplette 64 KB große Boot-Bereich lückenlos auf der SD-Karte abgelegt. Ein Datenabgleich bewies: Es gab kein gesperrtes Mask-ROM; der gesamte Low-Level-Code lag ungeschützt offen.
29 KB Kernschleife im RAM: XIP bricht die 4-MB-Schwelle
Die PC-Originalfassung von DOOM setzte mindestens 4 MB Arbeitsspeicher voraus. Um das Spiel in 891 KB zum Laufen zu bringen, musste das Speichermanagement von Grund auf neu gestrickt werden. Spode bereinigte ungenutzte Kamerapuffer und kratzte so rund 1,4 MB nutzbaren Heap zusammen.
Dieser knappe Speicher litt jedoch unter massiver Fragmentierung. Größere zusammenhängende Allokationen scheiterten regelmäßig, da die Original-Engine unzählige kleine, unzusammenhängende Speicherblöcke anfordert. Spode baute dedizierte Speicherpools für kleine Objekte und sorgte dafür, dass Texturen und Audiodaten von Leveln sofort nach deren Abschluss freigegeben wurden.
Auch die Unterbringung des Codes erwies sich als Knackpunkt. Die kompilierte 260 KB große Binärdatei passte nicht komplett ins RAM. Zwar unterstützt der HX3302B Execute-in-Place (XIP) direkt aus dem SPI-Flash, doch Messungen zeigten, dass die Codeausführung aus dem Flash 18-mal langsamer war als aus dem internen RAM.
Die Lösung lieferte eine detaillierte Profiling-Analyse im Emulator: 99 Prozent der gesamten Rechenzeit wurden in einer inneren Hauptschleife verbracht, die gerade einmal 29 KB Maschinencode umfasst. Der Rest der Binärdatei bestand überwiegend aus Initialisierungsroutinen und Menülogik. Spode verankerte diese 29 KB große Heißschleife dauerhaft im physischen RAM, während die selten genutzten Codepfade bei Bedarf per XIP direkt aus dem Flash nachgeladen wurden. Diese Aufteilung ermöglichte volle Performance bei minimalem Speicherbedarf.
Abbildung: Äußeres der markenlosen Spielzeugkamera X9S. Quelle: Spode’s Abode.
Hauptschleife umgangen & Software-Synthesizer: Direktes Polling bringt 30 FPS
Nach der Speicheroptimierung bremste die Firmware-Architektur die Bildrate aus. Das Werkssystem lief in einer kooperativen Ereignisschleife, deren Dispatching pro Frame allein 38 Millisekunden schluckte – was die Framerate halbierte.
Spode überging das werksseitige Event-Framework komplett und implementierte eine minimalistische Polling-Schleife, die Hardware-GPIOs direkt über Register abfragt. Das Steuerkreuz steuert die Bewegung, der Auslöser das Dauerfeuer. Ein kurzer Druck auf den Power-Knopf wechselt die Waffe, ein langer öffnet das Einstellungsmenü, und das Anstoßen an Wände löst Türinteraktionen aus. Ohne den Scheduling-Ballast kletterte die Bildrate auf stabile 30 FPS.
Auch die Audiowiedergabe verlangte Improvisationstalent, da die Hardware nur einen einzelnen PWM-Pin bereitstellt. Spode schrieb einen schlanken Software-Mixer, der mehrere Effektkanäle zu einem Monosignal bündelt.
Die Hintergrundmusik gelang ganz ohne Zusatzchips. Im Original liegt die Musik im MUS-Format vor und wurde früher von FM-Synthesizer-Chips wie dem OPL2 erzeugt. Die Spielzeugplatine besitzt keinerlei Soundhardware dieser Art. Spode programmierte daher einen extrem ressourcenschonenden Software-Wellenformgenerator, der lediglich 2 Prozent der Prozessorlast beansprucht. Über Rechteck- und Dreieckswellen erzeugt er eine 16-stimmige Polyphonie und bringt den legendären Soundtrack über den winzigen Piezo-Lautsprecher erstaunlich authentisch zur Geltung.
Beliebige Codeausführung über SCSI: Firmware-Dumps ohne Lötkolben
Nach erfolgreicher Portierung suchte der Entwickler nach einem Weg, den Hack unkompliziert für die Community zugänglich zu machen. Das Verteilen vorkompilierter Firmware scheidet aus urheberrechtlichen Gründen aus; gesucht war also eine elegante Methode zum Auslesen und Flashen ohne Öffnen des Gehäuses.
Hierbei half eine gravierende Schwachstelle im USB-Massenspeicher-Treiber der Kamera. Im Speichermodus reagiert der Controller auf undokumentierte herstellerspezifische SCSI-Befehle. Über standardisierte USB-Pakete lässt sich der Chip anweisen, zu einer beliebigen RAM-Adresse zu springen und den dortigen Code auszuführen. Spode schleuste über das SCSI-Protokoll einen winzigen Speichertreiber ins RAM ein. Der Chip las daraufhin eigenständig die gesamten 4 MB Flash-Speicher aus und übertrug das Abbild blockweise zurück an den Rechner.
Nutzer können nun über ein simples USB-Kabel innerhalb weniger Sekunden ein vollständiges, zerstörungsfreies Firmware-Backup ziehen. Die im generischen Chip-Design verbliebenen Debug-Schnittstellen brachten die ohnehin fragile Hardware-Sicherheitsarchitektur vollends zum Einsturz.
Das Marktsegment für Zehn-Euro-Elektronik wird von rasanten Entwicklungszyklen und extremem Kostendruck diktiert. Um minimale Beträge und Entwicklungszeit zu sparen, fluten Hersteller den Markt mit ungeschützter Standardhardware, die erstaunliche Rechenreserven birgt. Sobald diese Geräte im Handel landen, sind sie den Vorgaben der Hersteller entwachsen. Die Hacker-Community hat erneut bewiesen: Selbst das unscheinbarste No-Name-Gerät lässt sich durch Reverse Engineering in eine faszinierende, frei programmierbare Plattform verwandeln.
Weiterführende Links:
- Hackaday-Sonderbericht
- Spode’s Abode Reverse-Engineering-Blog
- Sprite_tm Kinderkamera-Firmware-Analyse
