- Ein Experiment zur lokalen Rechteausweitung war erfolgreich: Allein mit einem piezoelektrischen Feuerzeug wurden elektromagnetische Fehler auf dem DDR3-Speicherbus eines Notebooks induziert, wodurch ein nicht privilegierter Linux-Nutzer eine Root-Shell erhielt
- An einen SODIMM-Datenpin eines Samsung-S3520-Notebooks wurden ein 15-Ω-Widerstand und ein als Antenne dienender Draht gelötet; durch Klicken des Feuerzeugs in der Nähe wurden Speicherfehler erzeugt, bei denen bestimmte Bits kippten
- Im CPython-Experiment wurde durch einen Fehler auf der DQ7-Leitung Bit 7 eines Objektzeigers gekippt, sodass dieser auf eine gefälschte
bytearray-Struktur innerhalb vonbyteszeigte; daraus wurden Primitive für beliebiges Lesen/Schreiben im Speicher aufgebaut - Die Linux-Rechteausweitung funktioniert, indem Seitentabellen massenhaft in den physischen Speicher gesprüht werden und anschließend beim Lesen eines PTE ein Fehler in Bit 29 induziert wird, sodass ein für Nutzer zugängliches Mapping auf eine Seitentabelle zeigt
- Nach dem Erfolg wurde die erste Seite von
/usr/bin/suim physischen Speicher gefunden und durch ein kleines setuid-root-ELF ersetzt, wodurch der Page Cache verunreinigt wurde; in der Testumgebung lag die gefühlte Zuverlässigkeit bei etwa 50 % per SSH und etwa 20 % in einer grafischen Shell
Ausgangspunkt des feuerzeugbasierten EMFI-Experiments
- Auch ohne Software-Bug lässt sich durch Fault Injection außergewöhnliches Verhalten erzeugen
- Zu den Methoden der Fault Injection zählen Beschädigung softwaregesteuerter Daten, Power Glitches, Clock Glitches, elektromagnetische Pulse, Laser und mehr
- Hardware-Fault-Injection erfordert normalerweise hohe Präzision bei Zeitpunkt und Ort des Fehlers, was Spezialausrüstung und Kosten bedeutet
- Als kostengünstige Ansätze gibt es Versuche wie das RP2040-basierte PicoEMP und "Laser Fault Injection for The Masses"
- Ausgangspunkt war ein Ansatz, bei dem ein piezoelektrischer BBQ-Zünder mit einer Induktivität gekoppelt und als günstiges Werkzeug für elektromagnetische Fault Injection (EMFI) genutzt wurde
- Zuvor gelang damit ein Angriff per DFA auf eine Software-AES-Implementierung, die auf einem Arduino lief
- Vor dem Hintergrund der näher rückenden Vorstellung der Nintendo Switch 2, erwarteter ähnlicher Systemsoftware wie bei der Switch 1 und eines Mangels an Software-Bugs wurden die kostengünstigen EMFI-Experimente erneut aufgenommen
Testziel und Fehler auf dem DDR-Bus
- Testziel war ein 2011 gebautes Samsung-S3520-Notebook mit Intel-i3-2310M-CPU und 1 GB DDR3-RAM
- Es wurde gewählt, weil darauf Arch als leichtgewichtige Desktop-Linux-Distribution läuft und ein möglicher Schaden am Gerät verkraftbar war
- Ziel war es, einen Exploit zur lokalen Rechteausweitung zu schreiben, der auf injizierten Hardwarefehlern basiert
- Als physisch anfälligster Punkt wurde der DDR-Bus gewählt, der den DRAM-Speicher mit dem System verbindet
- Ein SODIMM besitzt 64 DQ-Pins für Lese-/Schreibdatenbits, DQ0 bis DQ63
- Der Versuchsaufbau bestand darin, an einen vermutlich DQ26 entsprechenden Pin einen 15-Ω-Widerstand und einen Draht zu löten
- Der Draht nimmt wie eine Antenne elektromagnetische Störungen aus der Umgebung auf und leitet sie an den Datenbus weiter
- Der Widerstand soll die Stärke der Störung begrenzen, damit der normale Speicherbetrieb nicht dauerhaft beeinträchtigt wird; möglicherweise ist er in der Praxis nicht nötig
- Allein das Klicken eines gewöhnlichen piezoelektrischen Feuerzeugs in der Nähe des Antennendrahts führte in memtest zuverlässig zu Speicherfehlern
- Die angezeigten Fehler hatten alle die Form eines gekippten Bit 29
- Obwohl der angelötete Pin vermutlich DQ26 war, könnte Bit 29 gekippt sein, weil die Pins falsch gezählt wurden oder das Mainboard die Datenleitungen anders verdrahtet
- Da die Reaktionsgeschwindigkeit auf dem Niveau eines Fingers liegt, ist die Timing-Kontrolle der Fault Injection nicht präzise
- Wenn ein Fehler auftritt, ist es wahrscheinlich, dass bei einem bestimmten 64-Bit-Lese- oder Schreibvorgang dasselbe Bit kippt
Ausnutzung von Bit-Flips in CPython
- Das erste Experiment bestand darin, in CPython einen Exploit in Form eines Sandbox-Ausbruchs zu bauen
- Da CPython selbst keine Sandbox ist, handelt es sich nicht um die Umgehung einer echten Sicherheitsgrenze, sondern um eine Vorbereitungsstufe, die vertraute interne Strukturen nutzt
- In diesem Experiment wurde statt DQ26 aus dem vorherigen Foto ein an DQ7 gelöteter Draht verwendet
- CPython-Objekte liegen im Garbage-Collection-Heap; der Objekt-Header enthält einen Refcount und einen Zeiger auf das Typobjekt, danach folgen typspezifische Felder
- Ein
bytes-Objekt enthält nach dem Längenfeld die Daten selbst innerhalb derselben Heap-Allokation - Ein
bytearray-Objekt enthält nach dem Längenfeld einen Zeiger auf den Puffer, in dem die eigentlichen Daten gespeichert sind
- Ein
- Die Kernstrategie besteht darin, innerhalb eines
bytes-Objekts eine gefälschtebytearray-Struktur als Daten abzulegen- Wenn CPython dazu gebracht wird, eine Referenz auf dieses gefälschte Objekt zu liefern, ermöglichen die vom Angreifer gewählten Längen- und Zeigerfelder des
bytearraybeliebiges Lesen und Schreiben im Speicher
- Wenn CPython dazu gebracht wird, eine Referenz auf dieses gefälschte Objekt zu liefern, ermöglichen die vom Angreifer gewählten Längen- und Zeigerfelder des
- Ein Fehler, der Bit 7 kippt, bewirkt in einem 64-Bit-Wort, dass ein Zeiger um 128 erhöht oder verringert wird
- Platziert man das gefälschte
bytearraymit einem Offset von +128 Bytes innerhalb desbytes-Objekts, kann derbytes-Objektzeiger durch den Fehler zu einem Zeiger auf das gefälschtebytearraywerden - Diese Umwandlung erfolgt mit 50 % Wahrscheinlichkeit in die gewünschte Richtung
- Platziert man das gefälschte
- Wichtig ist, dass nicht der Speicherinhalt selbst verändert wird, sondern Lese-/Schreibvorgänge auf dem Speicherbus geglitcht werden
- Anders als bei Rowhammer werden nicht gespeicherte Daten geändert, sondern ein gerade laufender Zugriff auf dem Bus beschädigt
- Um den gewünschten Zeigerzugriff zum Großteil der Busaktivität zu machen, wird dieselbe Objektreferenz in ein großes Tuple gefüllt
- Da CPU-Caches DRAM-Zugriffe reduzieren, wird eine Struktur sequenziell durchlaufen, die größer als der 3-MiB-Cache ist, sodass jedes Mal aus dem DRAM gelesen wird
- Pythons
isverhält sich wie ein Zeigervergleich und wird verwendet, um zu prüfen, ob sich der Zeiger geändert hat
- Der vollständige CPython-Exploit-Quellcode befindet sich in ddr3_dq7.py
- Mit der Variable
TESTINGlassen sich Bit-Flips ohne Hardware in Software simulieren
- Mit der Variable
Für die Linux-Rechteausweitung nötige Speicherstrukturen
- Bei der lokalen Rechteausweitung unter Linux sind Caches, virtueller Speicher, Seitentabellen und TLB die zentralen Strukturen
- Da DRAM vergleichsweise langsam ist, nutzt die CPU L1-, L2- und L3-Caches
- Der L3-Cache des Testnotebooks ist 3 MiB groß
- Bei einem Cache Hit wird nicht auf DRAM zugegriffen; erst ein Cache Miss löst einen DRAM-Lesevorgang aus
- Die kleinste Einheit aus Cache-Sicht ist die Cache Line; bei diesem Notebook beträgt sie 64 Byte
- Selbst beim Lesen eines einzelnen Bytes wird, sofern die Daten nicht im Cache liegen, ein 64-Byte-DRAM-Lesevorgang ausgelöst
- Da der DDR-Datenbus 64 Bit breit ist, wird dieses Lesen als Burst aus 8 sequenziellen Zugriffen abgewickelt
- Der virtuelle Speicher von x86-64 ist mit 4-KiB-Seiten und baumförmigen Seitentabellen implementiert
- Auf dieser Plattform gibt es vierstufige Seitentabellen
- Jede Seitentabelle ist eine 4-KiB-Seite und enthält 512 64-Bit-PTEs
- PTEs höherer Ebenen zeigen auf die physische Adresse der Seitentabelle der nächsten Ebene; ein Level-0-PTE zeigt auf die physische Zielseite
- Die physische Adresse der Root-Seitentabelle ist im CPU-Register CR3 gespeichert
- Der benötigte Teil eines PTE ist das Feld für die physische Adresse
- Maskiert man die Flag-Bits aus, bleibt eine seitenausgerichtete physische Speicheradresse übrig
- Der TLB ist Hardware innerhalb der CPU, die Seiten-Mappings von virtuellen auf physische Adressen cached
- Die genaue TLB-Größe des Testnotebooks ist unbekannt, scheint aber bei ungefähr 1024 Einträgen zu liegen
Seitentabellen in den Nutzerspeicher holen
- Die Linux-Exploit-Strategie ist von Elementen aus Mark Seaborns Rowhammer-Exploit inspiriert
- Ziel ist es, die Seitentabellen des eigenen Prozesses in für Nutzer zugänglichen Speicher zu mappen
- Dann lassen sich PTEs ändern, um auf beliebigen physischen Speicher zuzugreifen
- Statt die Belegung des physischen Speichers präzise zu kontrollieren, wird exakt 50 % des physischen Speichers mit Level-0-Seitentabellen gefüllt
- Anschließend werden R/W-Mappings wiederholt angesprochen, um den TLB zu umgehen
- Da die Zahl der Mappings die TLB-Größe übersteigt, lässt sich bei jedem Zugriff ein Page-Table-Walk erzwingen
- Ziel ist es, während dieses Walks beim Lesen eines Level-0-PTE einen Fehler in Bit 29 auszulösen
- Kippt Bit 29, ändert sich die physische Adresse, auf die der PTE zeigt, um einen 512-MiB-Offset
- Mit Glück zeigt die geänderte Adresse auf eine der zuvor gesprühten Level-0-Seitentabellen
- In diesem Fall legt ein Mapping, das eigentlich als normale R/W-Seite erscheinen sollte, eine Seitentabelle wie eine normale R/W-Seite offen
- Theoretisch kann jeder Bit-Flip von Bit 29 bis Bit 12 funktionieren
- Bit 12 entspricht einem Offset von 4 KiB
- Entscheidend ist, dass der PTE auf „irgendwo anders“ zeigt und ungefähr 50 % des physischen Speichers mit ausnutzbaren Seitentabellen gefüllt sind
- Das Anlöten des Antennendrahts ist möglicherweise nicht zwingend notwendig
- Wenn sich eine ausreichend starke elektromagnetische Störung erzeugen lässt, könnte es möglich sein; die Wahrscheinlichkeit für Systemabstürze oder Schäden steigt jedoch deutlich
Vorgehen beim Sprühen von Level-0-Seitentabellen
- Zunächst wird mit Linux’ memfd_create eine speicherbasierte Datei erstellt
- Sie erfüllt dieselbe Rolle wie die
/dev/shm/-Datei im Exploit von Mark Seaborn, ohne das Dateisystem direkt anzufassen
- Sie erfüllt dieselbe Rolle wie die
- Derselbe Puffer wird mehrfach per mmap gemappt
- Mit der Option
MAP_FIXEDwird erzwungen, dass jedes Mapping im virtuellen Speicher an 2 MiB ausgerichtet ist - Diese Ausrichtung garantiert, dass jedes Mal eine neue Level-0-Seitentabelle erzeugt wird
- Mit der Option
- Linux hat ein Limit von etwa 2^16 für die Zahl der Mappings pro Prozess, also für VMAs
- Jedes Mapping wird 32 MiB lang gemacht, sodass ein einzelnes Mapping 16 Level-0-Seitentabellen erzeugt
- Jedes Mapping belegt im virtuellen Adressraum 32 MiB, die PTEs zeigen jedoch auf dieselbe physische Seite
- Die physischen Speicherkosten bestehen nur aus den Level-0-Seitentabellen
- Auf diese Weise lassen sich Seitentabellen sprühen, bis der Speicher voll ist
Lesen/Schreiben von physischem Speicher und Verunreinigung des su-Page-Cache
- Während auf einen Fehler gewartet wird, werden R/W-Mappings wiederholt angesprochen; wenn ein unerwarteter Wert zurückkommt, wird ein Fehler erkannt
- Wenn die zurückgegebenen Daten wie ein PTE aussehen, wurde R/W-Zugriff auf eine Seitentabelle erlangt
- Der nächste Schritt besteht darin, herauszufinden, zu welcher virtuellen Adresse diese Seitentabelle gehört
- Der PTE wird so geändert, dass er auf die physische Adresse 0 zeigt
- Anschließend werden die R/W-Mappings erneut gescannt, um zu finden, welches Mapping sich geändert hat
- Auch wenn ein PTE geändert wird, merkt die MMU das nicht sofort
- Das liegt daran, dass das Mapping von virtueller auf physische Adresse im TLB gecached ist
- Da keine Methode bekannt war, den TLB aus dem Userspace direkt zu flushen, werden Tausende R/W-Mappings wiederholt angesprochen, um den TLB mit neuen Werten zu füllen und die alten zu verdrängen
- An diesem Punkt ist Lese-/Schreibzugriff auf den gesamten physischen Speicher möglich
- Danach wird die ausführbare Datei
/usr/bin/suread-only geöffnet und ihre erste Seite per mmap gemappt/usr/bin/suist eine setuid root-ausführbare Datei- Der gesamte physische Speicher wird gescannt, um dieselbe Seite zu finden
- Auf die gefundene physische Seite wird schreibend zugegriffen und sie durch ein unter 4 KiB großes ELF-Payload ersetzt, das eine Root-Shell startet
- Wenn Linux beim nächsten Ausführen von
susieht, dass die erste Seite bereits im Speicher liegt, liest es sie nicht erneut von der Festplatte- Es verwendet den verunreinigten Page Cache wieder und führt das injizierte ELF aus
- Das injizierte ELF leert mit
echo 1 > /proc/sys/vm/drop_cachesden Page Cache, sodass der nächstesu-Aufruf wieder normal funktioniert
- Der vollständige Linux-Exploit-Quellcode befindet sich in linux_x86_64_lpe.c
Zuverlässigkeit und Umgebungsbeschränkungen
- Bei der Demo-Ausführung trat mit Glück durch einen einzigen Klick des Feuerzeugs ein guter Glitch auf
- Bei mehreren früheren Versuchen stürzte das gesamte System ab
- Die Gesamtzuverlässigkeit des Exploits wurde nicht streng gemessen
- Bei ausgeschaltetem Notebook-Display und Zugriff per SSH lag sie gefühlt bei etwa 50 %
- In einer grafischen Shell eher bei etwa 20 %
- Das Testsystem nutzt integrierte Grafik
- Speicherzugriffe der GPU könnten den Exploit stören
- Hintergrunddienste für pipewire, sshd und systemd sowie Swap waren ebenfalls aktiviert
- Das war eine bewusste Entscheidung, um eine realistische Desktop-Linux-Umgebung beizubehalten; eine Deaktivierung könnte die Zuverlässigkeit erhöhen
- Wäre mehr RAM installiert gewesen, hätte ein höherer Anteil mit Seitentabellen gefüllt werden können, was die Gesamtzuverlässigkeit erhöhen könnte
Mögliche Anwendungen und offene Fragen
- Falls eine zuverlässige lokale EMFI-Rechteausweitung unter Windows möglich ist, könnte das Situationen beeinflussen, in denen TPM-basierte Anti-Cheat-Systeme die auf dem System erlaubte Software beschränken
- Für Androids SafetyNet- oder Play-Integrity-Prüfungen wäre eine ähnliche Geschichte denkbar, allerdings ist es schwieriger, ein Glitch-Modchip in ein Smartphone einzubauen
- Bei Low-Level-Performance-Optimierung sind Kenntnisse über Seitentabellen und TLB oft nicht direkt wichtig, in diesem Exploit werden jedoch genau die Strukturen angegriffen, die die Illusion virtuellen Speichers aufrechterhalten
- Beim Anwendungsbereich ist noch vieles zu klären
- Ob es auch mit DDR4 und DDR5 funktioniert
- Ob es auch auf ARM funktioniert
- In welchem Maß verschiedene ECC-Typen, insbesondere DDR5 Link-ECC, das Problem abschwächen
- Was der einfachste Weg ist, ähnliche Fehler mit einem Gerät wie dem RP2040 elektronisch auszulösen
- Ob es für einen Hypervisor-Escape genutzt werden kann
- Ob daraus ein WebKit-Exploit oder ein Kernel-Exploit für die Nintendo Switch gemacht werden kann
2 Kommentare
Das erinnert mich daran, wie man bei Feuerzeugen den Zünder herausgenommen hat, um in der Spielhalle die Münzen hochzuschieben.
Meinungen auf Hacker News
Die Inspiration hier war, Root-Rechte auf der Switch 2 zu erlangen; Root unter Linux zu bekommen, war der Proof of Concept.
Das Ziel war weniger, eine praktisch ausnutzbare grundlegende Sicherheitslücke zu zeigen, sondern eher, das tatsächliche Eigentum an der eigenen Hardware zurückzugewinnen, ohne TPM oder Kernel-Level-Anti-Cheat von Spielen zu knacken.
Die Arbeit ist beeindruckend, und Bemühungen zum Schutz der Software-Freiheit begrüße ich, aber ich würde lieber Alternativen unterstützen. Warum ihnen Zahlen liefern, die wie eine installierte Basis aussehen, und obendrein Gewinn? Man kann gleich ein Steam Deck oder ein anderes Handheld-Gerät kaufen, bei dem Root-Zugriff als Feature vorgesehen ist.
Der Artikel ist sehr gut geschrieben und die Herausforderung beeindruckend, aber mein Kopf reagiert eher mit der Hacker-Binsenweisheit: „Wenn physischer Zugriff besteht, ist es ohnehin vorbei.“
Mein erster Gedanke war: Bei physischem Zugriff flasht man das BIOS neu, installiert einen Treiber-Backdoor, bootet ein Live-OS und manipuliert
/etc/{passwd,shadow,groups, etc}.Dann fiel mir aber ein, dass die meisten Angriffe mit physischem Zugriff nicht funktionieren, wenn die Festplatte verschlüsselt ist, und dann wirkt so ein Angriff enorm reizvoll. Die Antennenidee ließe sich zu Hardware mit eingebauter Störvorrichtung erweitern, die über ein drahtloses Medium nach außen kommuniziert, sodass ein Angreifer die Störung aus der Ferne auslösen könnte. Kombiniert mit einer vom Angreifer kontrollierten Website, auf die das Opfer gelockt wird, wird das realistisch.
Diese elektromagnetische Störtechnik täuscht die CPU selbst; ich sehe nicht recht, wie man das beheben könnte, solange es keinen neuen Paging-Algorithmus gibt.
Auch mein PC nutzt Vollverschlüsselung, aber nach dem Booten wird das Keyfile zur Entschlüsselung verwendet, und ab diesem Moment ist es ein physisch zugänglicher PC.
Gefällt mir. Der Kern ist, dass beim Lesen oder Schreiben von Speicher ein elektrostatischer Bit-Flip passiert, und dass man mit etwas Löten einen „sicheren“ Pointer deterministisch in einen von mir gewünschten bösartigen Pointer verwandeln kann.
Historisch lautete die Sicht auf physischen Zugriff: „Wenn der Gegner das Gerät in die Hände bekommt, ist das Spiel vorbei.“ TPMs und Trusted Execution Environments haben diese Sichtweise zu „Selbst wenn der Nutzer physischen Zugriff hat, kann man bestimmten Operationen innerhalb einer Enklave vertrauen“ verschoben.
Der nächste Schritt ist der interessanteste. Kann man auch ohne Löten einigermaßen zuverlässige Ergebnisse erzielen? Da in den Umgang mit elektrischen Störungen schon viel Überlegung geflossen ist, dürfte das deutlich schwieriger sein, aber es könnte möglich sein. Wenn bei jedem Druck auf den Feuerzeugknopf bei einem 64-Bit-Lesevorgang ein zufälliges einzelnes Bit kippt und der Exploit zum Beispiel schon mit einem von vier bestimmten Bit-Flips funktioniert, wäre die durchschnittliche Zahl der Versuche vielleicht gar nicht so hoch.
Man kann jeden beliebigen Speicherbereich zu jedem gewünschten Zeitpunkt auf jeden gewünschten Wert ändern, also muss man sich nicht auf zufällige Bit-Flips verlassen. Man injiziert einfach das gesamte Programm.
Nur vom Titel her dachte ich, jemand habe Root-Rechte auf einem Zigarettenanzünder erlangt, und ich war völlig bereit, das zu glauben.
Der Ofen meiner Eltern bekommt auch regelmäßig Software-Updates, also hätte ich nicht einmal angezweifelt, dass ein Feuerzeug „smart“ ist.
Natürlich braucht es auch einen Chip, der das LiDAR betreibt und gleichzeitig intensive LED-Blitze mit Fade, haptische Stöße und Soundeffekte ausgibt. Jemand sollte daraus eine Demo bauen. Es wäre schön, wenn es wie ein kleiner Revolver aussähe, aber für die Sicherheit von Fingern und Hotdogs müsste man wohl den virtuellen Speichercontroller härten.
Dass Lötzinn zu schmelzen so kompliziert sein kann. Deshalb würde ich auch einen Artikel über das Rooten eines Feuerzeugs sofort glauben.
Das erinnert mich an einen Exploit, den man in den 80er- und 90er-Jahren an Arcade-Automaten in Sydney gemacht hat. Die Gasöfen in der Schule hatten einen piezoelektrischen Zünder, den wir „Clicker“ nannten, und den man vom Ofen abnehmen konnte.
Wenn man diesen Clicker in die örtliche Spielhalle mitnahm und an einer Ecke des CRT klicken ließ, bekam das System einen Schlag und die Spiel-Credits gingen hoch. Vermutlich lag es daran, dass die CRT-Masse physisch dieselbe Masseleitung nutzte wie die Vorrichtung, die Münzen prüfte.
Mit der Zeit merkten es die Betreiber und bauten so etwas wie einen Alarm ein, aber bis dahin waren es wirklich goldene Zeiten.
Das ging ein paar Jahre lang, bis die Betreiber es bemerkten und anfingen, die Arcade-Cabinets mit durchsichtigem Plastik abzudecken. Gleichzeitig mussten sie, weil die Cabinets nun in Plastik eingeschlossen waren, hinten Löcher zur Belüftung bohren. Dabei stellten wir fest, dass man mit einem Bambusstab den Hebel drücken konnte, der den Münzeinwurf registrierte.
Daraufhin verlegten sie die Lüftungsöffnungen von hinten nach oben, damit man den Hebel nicht mehr erreichte. Dann fanden wir aber heraus, dass man durch den Rückgabeschacht eine Münze nach oben schieben und so den Münzregistrierungshebel berühren konnte, und die Gratis-Spiele gingen weiter. Am Ende schraubten sie scharfe Schrauben in den Rückgabekasten, damit man sich die Finger schnitt, und danach kauften wir uns eine SEGA. Es hat wirklich Spaß gemacht.
Ich weiß nicht, ob das absichtlich so konstruiert war, damit Mitarbeiter kostenlos testen konnten, aber mein Freund kroch hinten hinein und spielte immer weiter gratis.
Bei der „Jungle Jive“-Version kamen auf der anderen Seite der Maschine Token heraus, wenn man mit dem elektrischen Zünder eines Zigarettenanzünders dem metallenen Einwurfschlitz einen kleinen Schlag versetzte. Wenn man zu schnell und zu oft klickte, ging sie in einen Warnmodus. Allein ging es auch, aber die optimale Besetzung war ein Dreierteam: eine Person zur Mitarbeiter-Beobachtung, eine zum Klicken und eine zum Einsammeln.
https://www.amazon.com/CYBERPUNK-Outlaws-Hackers-Computer-Fr...
Als Australier liest sich das anders. Je nach Verhandlungsgeschick kann man auch allein mit einem Zigarettenanzünder root bekommen.
Das ist nicht nur ein interessanter Exploit, sondern auch eine schöne kleine Einführung dazu, wie Caches in CPUs funktionieren.
Ich erinnere mich, dass vor etwa einem Jahr ein Artikel gepostet wurde, der erklärte, wie Computer funktionieren und gebaut werden, angefangen beim kleinsten Bauteil, den Logikgattern. Weiß jemand noch, welche Website das war?
https://www.nand2tetris.org/course
„Es sind nur ein 15-Ohm-Widerstand und ein Draht an DQ26 gelötet. Der Draht wirkt wie eine Antenne, nimmt nahegelegene elektromagnetische Störungen auf und leitet sie direkt in den Datenbus.“
Wirklich ein großartiger Hack. Elektromagnetische Störungen mit einem Feuerzeug zu erzeugen – ich muss mal neben einem DDR-Bus ein Feuerzeug zünden und schauen, was passiert.
Klar, wenn man vorher eine Antenne an den Speicher löten muss, dann geht das :-)
Trotzdem ist es ein hervorragender und sorgfältiger Artikel darüber, wie man solche Glitches tatsächlich ausnutzen kann. Ein Zigarettenanzünder lässt sich auch dafür verwenden, am Hintereingang eines Rechenzentrums herumzulungern und darauf zu warten, dass ein Admin zum Rauchen herauskommt.
Beim Titel dachte ich, es ginge darum, mit einem USB-C-Zigarettenanzündergerät Hyundai-Autos zu hacken.