 So, getretet macht das bitte leise. So, nochmal guten Morgen. Unser nächster Speaker heute Morgen ist ein unabhängiger Sicherheitsforscher. Er hat die CTF Group gegründet. Vielleicht habt ihr davon gehört. Einen großen Applaus zu Oran Abram. Jetzt hören wir hier leider den Speaker nicht im Übersetzungsraum. Wir haben hier leider technische Probleme bei der Übersetzung. Ich hoffe, das klärt sich. Jetzt haben wir hier wieder Ton. Er hat einen Open Source Bootloader für die iPhones geschrieben. Und Verletzbarkeiten im iPhone 3G und 3GS, so wie im iPhone 4 gefunden, im Baseband. Und damit haben wir diese Devices ohne SIM-Karte anlocken können. Und er spielt heute auch mit beim Capture the Flag heute Abend. Also bitte viel Erfolg wünschen. Wenn ihr mich finden wollt auf der Webseite oder auf Twitter. Es geht los. Der Vortrag heute mit einer Vorstellung. Wie er die Telefone entschlüsselt hat. Dann ein Patch für die EMC-Module der Samsung. Wie kommt man an die Firmware ran und wie analysiert man sie. Und dann reden wir über den eigentlichen Fehler, der dazu geführt hat, dass die Devices verstorben sind. Und dann reden wir darüber, wie wir sie die Geräte, die geprägten Geräte wiederbeleben kann. Es gab ein Phänomen, das hieß, der plötzliche Telefon tot. Und das fing in 2012 an. Samsung Galaxy S3-Telefone fing plötzlich an, einfach zu sterben, ohne dass es dafür irgendein Grund gab. Das Telefon blieb plötzlich stehen. Und wenn man versucht hat es zu starten, ist es nicht mehr gestartet. Und wenn man Glück hatte, konnte das Telefon zumindest in den Bootloader gehen. Aber in anderen Fällen ging selbst das nicht. Einfach nur Briefbeschwerer. Man kann es nicht anschalten. Man kann ein Kabel anschließen, aber das hilft nicht. Man kann noch nicht einmal die Batterie laden. Denn selbst die Batterieladfunktion ist nicht in Betrieb. Hier ist ein Beispiel. Hier hat jemand geschrieben, das passiert hier vielen Leuten. Ich hoffe Samsung tut etwas. Jetzt kommt der Spoiler. Das haben sie gemacht, aber nur so halb. Da reden wir gleich drüber. Wie diagnostiziert man denn jetzt solche Geräte? So sieht ein funktionierendes S3 aus. Man sieht den schönen Hintergrund. Der Bildschirm ist einfach nur schwarz. Man kann nichts machen. Wenn man etwas Glück hat, sieht man zumindest diesen Bildschirm. Der wird vom Bootloader dargestellt. S Boot heißt der. Aber das ist der letzte Bildschirm, den man sieht. Wenn man dann eine bestimmte Kombination von Tasten drückt, kommt der Bootloader und über den Reden wir gleich. Das ist jetzt das S3. Meine bisherige Vorstellung davon ist, wie hier dargestellt, in einer groben Darstellung. Es gibt den Hauptprozessor. Das ist der Sony Exynos. Das ist die Haupt-CPU. Dann gibt es den IMMC-Chip. Das ist ein ganz normaler Massenspeicher. In diesem IMMC befindet sich ein Night Flash. Wenn man sich das Silikon anschaut, sieht man darauf ein Night Flash. Samsung hat einen Patch zur Verfügung gestellt. Sie haben behauptet, dass der Fehler dadurch beseitigt würde. Weil Linux ja unter einer Open-Source-Lizenz steht, mussten sie die Quellcodes veröffentlichen. Man sieht hier, dass sie den Code für die Kommunikation mit dem IMMC verbessert. Wir schauen jetzt mal an, wie die Kommunikation mit dem IMMC funktioniert. Ein IMMC ist der Standard für Speicher in Telefonen. Heutzutage benutzen hoher qualitative Telefone auch einen neuen Standard. Im Grunde genommen ist dieses IMMC eine erste Karte im BGA-Format. Es benutzt den selben Bass wie eine erste Karte in einer anderen Bauform. Eine Firma, die Hart Colonel heißt, hat dieses TPCB hergestellt, diese Platine hergestellt und hat auch einen Adapter hergestellt, mit dem man dieses IMMC eine normale erste Karte umwandeln kann, wie ihr links seht. Im Grunde genommen ist das IMMC derselbe Bass wie erste Karten. Darum wird es manchmal auch interne erste Karte genannt. Wenn ich später Karte sage im Talk, dann meine ich diesen IMMC-Chip. Wenn man mit diesem IMMC-Bass kommunizieren will, dann schickt man dem verschiedene Kommandos. Man schickt Kommandos an die Karte. Es gibt 64 Kommandos von 0 bis 63. Zum Beispiel gibt es Kommando 17, das heißt einen einzelnen Block lesen und 20 einen Block schreiben. Jedes Kommando hat einen 32-Bit Argument und diese Kommandos sind klassifiziert und es gibt eine speziell interessante Klasse, das ist die Klasse 8, diese Kommandos 60 bis 63, diese sind reserviert für den Hersteller und das ist das, was letztendlich interessant ist. Also, gehen wir zurück zum Patch. Samsung hat gesagt, sie haben den Backenfehler gepflegt. Die Geräte sollten nicht mehr zum Briefbeschwerer werden. Dieser Patch, was macht dieser Patch? Er vergleicht zuerst den Namen der Karte und wenn die Hardware-Version des Effekten-Chips gefunden wird, dann die Karte, die wir hier sehen, auf die AMC Start, welche ein paar interessante Sachen macht, welche ich erwähnen werde noch und wenn dieser Karte gefunden wurde, dann startet es die Funktion, welche den Chip reparieren sollte. Was man hier erwähnen sollte, ist, dass die Karte, wenn das Gerät gestartet wird, also jedes Mal wenn, ja. Also, reden wir mal über diesen Start. Ich habe den Karte etwas gekürzt, das ist nicht genau der Patch, aber das ist eigentlich die große und ganze Logik, die benutzt wird. Das Interessante daran, ist, dass die Karte, der AMC Verschiebe- und Löschekommando move and arise, der benutzt, der hat zwei Argumente, das benutzt zwei Argumente, weil man zuerst noch ein anderes Kommando voranstellen muss. Das erste Argument ist, dass der erste Block, der gelöscht werden soll, das zweite Argument der letzte Verschiebe- und Löschekommando verwendet wird. Also, was jetzt passieren sollte, alle Block von 40300 bis 4A3, was auch immer, sollten gelöscht werden beim ersten Befall. Beim zweiten Befehl, was da passieren sollte, man sieht, dass dieser Bereich überlappend ist. Also, meine Vermutung, dass das eigentlich gar kein Löschkommando ist, sondern dass das Samsungs-für-Sendung das eigene benutzt. So, AMD move und also das Move I-Kommando ist eines von diesen reservierten Kommandos für den Herrschter reservierten Kommandos, das ich erwähnt habe. Also, meine Vermutung war, dass in einem geheimen Backdoor-Modus gehen, welchen Samsung in diesem Chip implementiert hat und der letzten zwei Kommandos, dass diese den Modus wieder verlassen und die Befehle dazwischen, die machen jetzt irgendwas, aber die löschen nicht, sondern die machen etwas, was Samsung definiert hat. Man sieht also die Zahlen, die da aufgerufen werden, die wir gerne adressen, die zählen hoch, es sind immer vier mehr. Und die zweiten Argumente, da ist mir etwas sehr Interessantes aufgefallen. Wenn ich jetzt davon ausgehen würde, dass das Speicherdaten sind, wenn man sie sich als Little-Indian-Zahlen anschaut, dann sieht man, es fängt an mit 10 B5 und dann schauen wir uns den Assembler an. Und das ist ein Push-Opcode in der Arm-Sprache. Also, es fängt an mit einem Push. Und hier sehen wir den EMMC neben einem Daumen. Also, mein Verständnis, wie das funktioniert, sieht jetzt so aus. In diesem EMMC ist nicht nur ein Nandflash, sondern es ist auch ein Arm-Mikro-Kontroller und der hat auch eine Firmware drauf. Und es sieht so aus, als würde dieser Patch den eingebauten Speicher die eingebaute Firmware verändern. Ich habe mir also diesen Patch jetzt nochmal angeschaut. Ich schaue mir diese Daten an, die er schreibt und habe sie in eine binäre Datei umgewandelt. Und jetzt sehen wir hier, hier sehen wir hier den Patch. Das ist Samsungs Patch. Unten sieht man die tatsächlichen Instruktionen. Was es tut, ist, sie rufen eine Funktion auf und wenn sie 0 zurückliefert, geht der Chip in eine Endloschleife. Ich habe dann später verstanden, was da war, bevor der Patch kam und da wurde einfach nur diese Funktion aufgerufen. Sie haben aus diesem Funktionsaufruf gemacht, einen Funktionsaufruf, aber wenn die Funktion 0 zurückliefert, dann geht der Chip einfach in eine Endloschleife. Das hat für mich bedeutet, das kann eigentlich nichts reparieren, denn es macht das selbe wie vorher und wenn es einen Wert zurückliefert, geht es in eine Endloschleife. Ich habe hier ein paar Threads gelesen und habe das hier gefunden, der ultimative Galaxy S3 seltsame einfriere Thread. Das Galaxy S3, wie die ärgerlichen Benutzer behaupten, es passiert all das. Das Telefon friert ein, es bleibt stehen, der Bildschirm funktioniert nicht mehr. Ich hatte zu dem Zeitpunkt dieses S3 und ich habe auch gemerkt, wie in meinem Telefon auch das manchmal eingefroren ist. Deswegen wollte ich mir die EMMC-Firmware besorgen und anschauen können. Wie kriegt man so eine Firmware? Ich kann versuchen, in die EMMC-Firmware zu schreiben. Ich kann schauen, was dann passiert. Einfach an verschiedene Adressen irgendwas schreiben, ein paar logische Vermutungen anstellen, gucken, was auf dem EMMC-Bus passiert. Aber damit versuche ich, nur im Dunkeln meinen Weg zu finden. Die zweite Möglichkeit ist, verschiedene Kommandos zu probieren, einfach damit zu fassen. Aber damit würde ich mein Telefon zerstören und es funktioniert ja eigentlich noch. Die dritte Möglichkeit ist, nach irgendwelchen Hinweisen zu suchen. Ich habe hier einfach nach diesen Zahlen gesucht, die genutzt werden, um in diesen Backdoor-Mode zu kommen. Mit Google gesucht. Ich habe es gefunden in einem Treiber. Das heißt einfach, die Firmware von bestimmten Samsung EMMC-Bau-Steinen patchen, um einen Back zu finden. Der Kommando ist 1021 und dann 4.0en. Die 4.0en sind wichtig. Aber dann ist noch etwas anderes passiert. Wenn man den Patch weiter liest, dann sieht man das hier. Hier ist ein Blog, der ist eingeschlossen durch ein ifdev. Hier benutzen Sie den selben Kommando wie bisher. Aber das Argument ist das Gleiche mit einer 2 am Ende. Dann benutzen Sie eine Race-Kommando mit derselben Adresse wie vorher. Aber dann machen Sie ein Read-Kommando. Dann haben Sie die Möglichkeit von Samsung diesen Speicher auszulesen. Weil Sie einen Race-Kommando benutzen mit der gleichen Adresse wie vorher. Und dann lesen Sie ein D-Word aus dem EMMC. Ich habe also diesen Kotschnipsel genommen und umgebaut, der einfach iteriert durch all die Adressen, durch den ganzen Adressraum. Und ich schreibe jedes Mal diese Kommandos und lese das Kommando. Und dann schreibe ich das Ergebnis in eine Datei und ich bekomme das hier. Und das sieht ja jetzt auch schon wie eine Firmware aus. Die Namen, die ihr seht, wie EME und Hartford, das sind meine Namen. Aber was ich gesehen habe, waren Adressen. Aber das hier sieht aus wie eine Vektortabelle. Also, so weit ich das verstanden habe, hatte ich jetzt also tatsächlich die Firmware von diesem Chip erhalten. Der nächste Schritt ist nun, die Firma zu analysieren und zu reverse-engineeren. Zum Glück enthalten die Firma einige Strings, die man einfach so lesen kann. Aber nein, es hat nur einen drin. Das ist der, den ich seh. Ja, auf dem Slide. Und der ist nicht allzu nützlich, um da irgendwas mitzumachen. Dies ist ein Coach-Schnipsel von meinem Reverse-Engineering-Prozess. Ich habe Namen benutzt wie Flip-Bit und Memory-Map, Input-Output usw. Aber was ich... Also, ich habe im Großen und Ganzen die High-Level-Logik verstanden. Ja, das Grobe habe ich mir weniger verstanden. Nun zum eigentlichen Bug, zum eigentlichen Fehler. Was ist denn jetzt eAMMC eigentlich, damit wir den Bug verstehen können? Wir haben einen Motorsterist, normaler Speicher, normal Storage. Da gibt es eine Operation, die heißt Lesen. Eine Operation, die heißt Schreiben. Die machen, was man erwarten würde. Dann gibt es einen Nand-Flash-Speicher, der hat ein Lese-Kommando, liest immer noch Daten, wie bisher. Die Schreib-Operation, die schreibt, die macht quasi Bits aus. Wenn ein Bit eins war, dann macht es eine Null draus. Es appliziert eine Maske auf die Bits des Speichers. Und es gibt ein Lösch-Kommando, das dieses Kommando löscht einen gesamten Speicherblock. Also, es macht... Alle diese Bits werden auf eins gesetzt. Dies ist aber eine langsame Operation. Und es gibt ein anderes Problem. Die Blöcke im Flash haben eine limitierte Anzahl Male, die man diese löschen kann. Also, nach einigen Tausend Lösch-Zyklen wird der Block sterben und ihr könnt den nicht mehr benutzen. Irgendeine Software muss nun diese Übersetzung machen von Operation Codes, von diesen Instruktionen, um diese wie einen normalen Speicher anzuzeigen. Das wird so gemacht. Das ist ein FTL Flash Transformation Layer, also Flash Übersetzungs Layer. Und diese Firma ist dafür zuständig, dass tote Blöcke quasi automatisch neu zugewiesen werden, dass man das Gehen außen nicht merkt, dass einzelne Blöcke gestorben sind. Und im Fall von Samsung ist die Firma auch für die Buskommunikation zuständig. Was ist nun eigentlich der Fehler dieser Back? Wenn man Schreiboperation ausführt, dann muss das FTL einige Informationen für sich selber speichern, weil das muss zum Beispiel wissen, wo dieser Block intern jetzt tatsächlich ein Flash gespeichert ist. Also es gibt irgendwo Metadaten, welche das FTL für sich selber speichert. Also man muss irgendwelche Schreibkommandos ausführen, um diese Metadaten zu schreiben. Und der eigentliche Back war, dass diese Daten ab und zu, nicht immer, aber ab und zu korrumpiert waren. Und wenn das einmal geschehen war, wenn man dann den EMMC-Chip starten wollte, wird das FTL diese Daten lesen. Es wird merken, dass da irgendwas schiefgegangen ist und eine Exception um sich schmeißen. Und ja, in diesem Fall ist der Exception-Handler einfach ein Endloslub, eine Endlosschleife. Und ja, da wird dann halt nichts mehr Sinnvolles passieren, wenn das EMMC in einer Endlosschleife ist. Man kann dann senden, was man will. Die Firma wird nicht mehr darauf reagieren. So, der Patch von Samsung war irgendwie in Größenordnung in dem Stil, bevor die Metadaten korrupt werden, muss man die SIPIO anhalten. Also, ja, dann wird halt nie etwas schiefgehen. Ein etwas seltsamer Ansatz, welcher dann zu diesem plötzlichen Telefontod oder seltsamen Einfrieren führt. Und ja, da wird dann etwas schiefgehen. Das ist ein etwas seltsamer Ansatz, wo der plötzlichen Telefontod oder seltsamen Einfrieren führte. Also, ich fasse nochmal zusammen. Ich hatte die EMMC-Formware, in der mich den Patch analysiert hatte. Die EMMC-Formware hatte einen Back, welcher diese Aftialkorruption hervorlöste. Der Back trat nur ab und zu mal aus und so weiter. Und jetzt der nächste Schritt ist, die vor uns zuwider beleben. Also klar, aber was jetzt? Der EMMC startet beim Buten in eine Endlöschleife. Aber was passiert vorher? Ich habe mir die Firmware angesehen. Das ist das Membrider out davon. An der Adresse 0 ist etwas, was ich das Bootraum nenne. Es ist ein Raum, man kann also daher nicht schreiben. Es ist ein Code. Er initialisiert die Hardware von dem EMMC und lädt die Firmware von dem Flash selbst. Das ist natürlich seltsam. Wenn das Bootraum schon da ist, warum macht es dann etwas, wovon das Bootraum ja schon da ist? Scheinbar ist die Firmware zu groß, um in das Bootraum zu passen. Deswegen muss es die eben vom Flash ausladen. Dann hat es noch seine eigene Maschinerie für die EMMC-Kommandos. Was natürlich auch seltsam ist. Am Anfang ist der EMMC leer und es hat keine Firmware. Und wenn das Laden der Firmware nicht funktioniert, dann geht das Bootraum in so eine Art Wiederherstellungsmodus. Es exponiert einen EMMC-Bus und von daraus kann man eine Firmware schreiben. Das Bootraum ist also quasi eine Firmware mit weniger Funktionen. Jetzt inzwischen sieht mein Verständnis, wie dieses EMMC aussieht so aus. In diesem EMMC haben wir zwei Chips. Das eine ist der Armchip und der hat ein Bootraum und der lädt die Firmware aus dem Flash und bootet sie dann. Wenn wir doch nur zu diesem Bootraum sprechen könnten, allerdings funktioniert das Laden der Firmware selbst tatsächlich. Die Firmware lädt, dann geht sie in die Endlosschleife und deswegen haben wir keine Chance jemals mit dem Bootraum zu reden. Allerdings ist es nicht wirklich so. Beim Boot hin wird an der Adresse 7-DBC ein Timer gesetzt für 35 Millisekunden. Und wenn während dieser Zeitdauer ein Interrupt gezündet wird, wird ein Wert vom MemoryMap.io gelesen und verglichen mit dieser magischen Zahl. Und wenn dieser Vergleich gelingt, dann wird das Laden der Firmware übersprungen. Das ist also ein Schema des Bootprozesses. Die linke Spalte ist der normale Booten und wenn wir es schaffen, nach rechts zu kommen, kommen wir in diesen Recovery-Modus. Wiederherstellungsmodus. Ich versuche also ein EMMC-Kommando abzusetzen mit dem Argument dieser magischen Zahl. Wir fassen also zusammen. Die toten EMMCs bleiben beim Booten hängen. Allerdings gibt es ein Zeitfenster kurz vorher und wenn man es in diesem Zeitfenster schafft, den Interrupt auszulösen, kann man in den EMMC-Boot Recovery-Modus kommen. Aber Moment, das Telefon ist ja bereits tot. Wie kann ich also überhaupt mit dem EMMC sprechen? Ich könnte natürlich ein Hardware-Modifikation benutzen, also den EMMC auslöten. Allerdings würde ich gerne etwas mit Software machen wollen. Ich würde nicht gerne BG-Artschirps entlöten. Also der nächste Schritt war nun, irgendwie magisch zu diesem EMMC zu sprechen, um das EMMC-Bootroom darauf zuzugreifen. Und dann könnten wir durch diesen Wiederherstellungsmodus reparieren. Vorhin habe ich gesagt, wenn ihr glücklich seid, wenn ihr glücklich habt, dann seht ihr diesen Ladebildschirm. Wenn ihr diesen noch seht, dann kann man noch auf den Chip zugreifen. Und wie es aussieht, wenn man die Spezifikation von Samsung liest, dann sieht man, dass ihr EMMC zwei Partitionen habt. Das sind nicht Partitionen im Sinne von Data-Systemen, sondern im Sinne von EMMC Partitionen. Es gibt eine Bootpartition und eine Benutzepartition. Die Bootpartition im Fall von Samsung ist der Bootloader für die Haupt-CPU und die User-Partition hat alles andere drin. Da ist das Linux drin, alle die Android-Dataisysteme, Apps und so weiter. Also die Bootpartition hat ihre eigenen FTL-Methodaten und die Benutzepartition hat ebenfalls das FTL-Methodaten. Ein Kollege von mir hatte ein kaputtes S3, welches aber den S-Boot noch buden konnte. Und wie ich dann herausgefunden habe, waren nur die Methodaten der User-Partition defect. Das ist, denke ich, sehr üblich, weil im Normalfall, man schreibt nichts in die Bootpartition, sondern nur in die Benutzepartition. Also wie geht es dieses S3 kaputt? Das S3 schaltet ein, die CPU wird auf das EMMC zugreifen, wird die Bootpartition verarbeiten, dann wird der S-Boot zurückgegeben an die Haupt-CPU und die Haupt-CPU will dann Linux starten und wird dann feststellen, die Benutzepartition ist defekt und geht darum in diesen Endlosschleife. S-Boot hat ein Modus, wie man auf das EMMC zugreifen kann, die heißen Loki und Odin, aber es gibt keine Möglichkeit, auf EMMC-Kommandos zu schreiben. Aber mit diesem Protokoll über USB, Loki-Odin, könnt ihr über USB mit dem EMMC-Chip kommunizieren. Also irgendwie muss ich jetzt das machen, aber es gibt, ich kann ihn wie kommunizieren, aber es ist kein Kofferhandeln in S-Boot. Jetzt muss ich also S-Boot irgendwie ausnutzen, um da draufsteigen zu können. Und dies ist ein Kotschnipsel aus S-Boot. Da kann man diese Variable, ist Damp, die kann man anpassen. Wenn diese gesetzt ist, wird es etwas vom USB lesen und dann gibt es ein Waffer zurück, der wird das Argument quasi als, also schlussendlich, man kann lesen, aber es macht keinen Boundary-Check, also ihr könnt auch über den Bereich darüber lesen, welcher eigentlich nicht vorgesehen wird. Und so kann man also ein pufferer Stellen, der größer ist, weiter lesen, Overflow machen. Damit haben wir eine Verwundbarkeit in S-Boot gefunden. Wenn man jetzt also ein S7 oder S8 nimmt, da ist das inzwischen beseitigt. Aber das S3, das ja nicht mehr unterstützt wird, da ist diese Verwundbarkeit immer noch nicht herausgenommen. Jetzt reden wir darüber, wie der Hieb im S-Boot implementiert ist. Wenn man eine große Summe Speicher allokieren will, dann nimmt es verschiedene Blöcke und fängt an sozusagen am Ende abzuschneiden. Und da gibt es überhaupt keine Sicherheitsvorkehrungen. Nehmen wir mal an, man möchte 50 bytes allokieren und der Chunk, den man da genommen hat, ist 100 bytes groß und da wird das von hinten abgeschnitten und der Header von der Chunk hält die Größe. Und was ich erreichen wollte, ist, was, wohin schreiben und das tue ich, indem ich das Chunk Splitting ausbeute. Ich fälsche also einen Chunk Header mit einer großen Größe. Dann schaue ich nach der Adresse und versuche sicherzugehen, dass dieser Chunk tatsächlich ausgewählt ist, nachdem Malok aufgerufen wurde. Und ich gebe zurück die Adresse, zähle zu der Größe des Chunks eben meine Größe hinzu und ziehe den Header wieder ab und setze die Chunks entsprechend auf die Adresse, auf die ich zu greifen will. Detail sind natürlich langweilig, deswegen verweise ich hier auf diese Skithub Repository. Da kann man das runterladen. Und das ist jetzt eine Demo erbutet und jetzt funktioniert es. Was passiert aber, wenn es wirklich tot ist, also wenn das hier passiert, wenn auch die Bootpartition nicht funktioniert? Irgendwas muss ja laden. Irgendwas muss ja S-Boot laden. Es gibt noch ein weiteres Stück Hut, das ist das Exynos Bootraum und das lebt in der Haupt-CPU. Was normalerweise passiert, ist, dass das Bootraum im Exynos lädt. Es lädt den 1BL, den ersten Bootloader, der ist signiert und der prüft dann die Signatur von S-Boot und springt da rein und S-Boot lädt dann den Betriebssystemkehren. Und das Bootraum muss aber diesen First Boot von irgendwo laden und das versucht es zuerst vom EMMC zu laden. Wenn das nicht funktioniert, dann muss man eine externe SD-Karte laden. Also ich habe jetzt versucht, ob das geht, aber das geht nicht, weil der Modus ein anderer ist, welchen man nicht benutzen kann. Ich kann nicht von der externe SD-Karte ein Bootloader laden. Und jetzt habe ich mal in ein Forum geschrieben oder in Forum geschaut und es gibt ein Entwicklerboard, ein Entwicklungsboard, welches das selbe Bootraum verwendet, aber es benutzt einen anderen ersten Bootloader, welcher keine Signaturprüfung macht. Wenn ich jetzt also diesen Bootloader nehmen kann, dann kann ich in den S-Boot Patch springen und den Patch ausführen. Also dies ist jetzt der modifizierte Bootprozess. Ich starte mit Exynos, gehe auf die externe SD-Karte, die hat einen Signeten-Bootloader. Das Bootraum wird da reinspringen, das wird zum gepatchten Asput springen und dann kann man tatsächlich in die Forum-Barkane ausnetzen. Und jetzt kann man also irgendwie entweder über die Interne oder externe SD-Karte diesen Asput lesen. Jetzt müssen wir auf das EMC Bootraum draufkommen. Wie vorhin erwähnt, muss sich irgendwie diesen Interab triggern und dieses Argument, dieses magische Argument. Also, was ich jetzt gemacht habe, ich habe alle möglichen EMMC-Kommandos ausprobiert, von 0 bis 63, immer wieder das EMMC ausgeschaltet, eingeschaltet, nächstes Kommando probiert und dann habe ich schnell dieses Kommando X mit diesem Argument gesendet, dann 200 Sekunden gewarten, irgendein Kommando gesendet, weil es vom Wiederherstellungs-Modus unterstützt wird oder werden sollte und geschaut, ob eine Antwort kommt. So wusste ich, bin ich jetzt im Recovery-Modus oder nicht. Und so habe ich dann herausgefunden, dass der letzte Kommando funktioniert. Und das war sehr aufregend, weil das ist das erste Mal das EMMC tatsächlich eine Antwort gegeben hat. Und so habe ich jetzt versucht, verschiedene Kommandos an das EMMC zu senden und dies war effektiv das erste Mal, dass das EMMC tatsächlich eine Antwort gesendet hat. Das Kommando 62, das kann man jetzt benutzen, irgendwie um das zu reparieren. Also, es gibt zwei Revisionen von diesem Defektenchip, das Erst-Minus-Firmware-Version 1, welcher den Back hat und dann hat es eine andere Firmware-Version, 0xF7, wo der Back nicht mehr vorhanden ist. Samsung hat das wahrscheinlich also in der Zwischenzeit eh normal gepflegt. Das Ziel ist jetzt, alle Firmware auf die F7 abzudeiden, wo der Back nicht mehr vorhanden ist. Was ich nun also gemacht habe, ich wollte also diesen F7 irgendwie herunterladen. Darum habe ich so ein Tool geschrieben, das Low-Level-EMCs-Commandos sendet, um die Firmware herunterzuladen. Und danke auch an Artesa von den XDA-Developers, welche mir dann einen Damp zur Verfügung stellen konnte. Jetzt muss ich das EMMC updaten, das ist überhaupt kein Problem. Ich benutze die Hintertür, um meinen eigenen Code in das Rahmen zu schreiben und dort auszuführen. Und schreibe damit die neue Firmware. Aber ich habe noch etwas einfacheres gefunden. Es gibt eine weitere Hintertür und das ist das Kommando 60. Es hat zwei Firmware-Upgrade-Modi. Der eine ist CBAD1160. Da kann man dann einen Errace-Command schicken und dann formatiert er den gesamten Firmware-Bereich und man kann eine neue Firmware schicken und die wird dann geschrieben. Fassen wir also zusammen, wie repariert man ein totes S3? Man besorgt sich ein totes S3. Es gibt verschiedene Revisionen des Galaxy S3. Ich spreche von dem GT19300. Man bootet in das S-Boot entweder direkt oder mit einer externen SD-Karte. Man exploitet den S-Boot. Von dem Shellcode booten wir die EMMC neu in das Bootraum Recovery Modus. Dann benutzen wir Kommando 60 um den FTL zu formatieren und die Version F7 zu flaschen. Wir booten den EMMC neu und wir schreiben S-Boot in die EMMC Boot Partition. Das ist dann der Profit und das Telefon funktioniert wieder und dann möchte ich jetzt vorführen. Ich habe hier ein geprägtes Device, ich habe das absichtlich geprägt. Da ist eine Batterie drin und wenn ich es anschalte, passiert nichts. Wenn ich versuche in den Download Modus zu kommen, passiert auch nichts. Ich habe hier diese externe SD-Karte auf der S-Boot, wie ich vorher beschrieben habe. Ich lege die ein und es sollte booten. Ja, ok. Also es bootet in etwas. Jetzt gehe ich zurück zum Rechner und stecke das Telefon an den USB. S-Boot antwortet und jetzt lasse ich den Shellcode laufen. Der hat den EMMC referiert. Der Shellcode läuft. Er bootet den EMMC in den Bootraum Modus. Macht das Firmware-Upgrade. Es dauert ein paar Sekunden. Ruhig bleiben steht da. Das nächste was passiert ist, dass er in die Firmware bootet und die Partitionsgröße ändert, sodass er tatsächlich in den Bootraum schreiben kann. Und jetzt ist das Shell-Komando fertig und ich kann jetzt eine andere SD-Karte benutzen, die es boot normal startet und in diesem SD-Karten-Modus wird der S-Boot in die Boot-Partition schreiben. Ok. Das ist der SD-Karten-Modus. Ich glaube ihr könnt das sehen. Wenn ich jetzt diese SD-Karte entferne und das Gerät neu starte, ich nehme also die Batterie raus, es sollte booten in den S-Boot. Das Gerät funktioniert wieder. Hier raus. Dankeschön. So. Zusammenfassung. Ein zweites ein paar Dankes. Dankeschön an Rebellas oder Mautler-Lagheff, welche den Exynos, welche viel zum Exynos-Boot lauter beigetragen haben. Ohne sie, hätte ich nie ein geprägtes Gerät starten können. Entropie 512, Bunny and Xops, welche einen schönen Talk hier am CCC schon mal gehalten haben über das Hacken von chinesischen SD-Karten. Und die haben meine Forschung erwähnt, was mich natürlich sehr motiviert hat, dass ich weitermache und auch heute hier stehe, diesen Vortrag halte. Also, ich habe jetzt, kann ich es zugerufen, auf Samsung EMMCs. Gebrickte AMM-S3 reparieren. Und man kann auch übrigens machen, was man will. Und was sollte man jetzt das Nächstes machen? Wir könnten schauen, ob die neuen Flashtipps, die AMM-C's, auch diese Backdoor haben. Also, ja. Vielleicht haben auch neue Geräte und neue AMM-C's diesen Modus. Und den UFAS ist ein Bass, welcher AMM-C ersetzen soll. Und Samsung macht auch UFAS-Chips. Also, ja, ich würde schauen, ob es eine ähnliche Backdoor gibt. Und es ist natürlich auch interessant, andere Hersteller anzuschauen. Vielleicht gibt es eines Tages eine Open-Source-Alternative-Formware für solche Geräte. Da findet ihr ein Code, falls ihr experimentieren möchtet. Unten findet ihr natürlich auch die Slides. Das ist bereits online. Wenn ihr Fragen habt, jetzt ist die Zeit dafür. Vielen Dank für den sehr interessanten Vortrag. Es gibt dort und dort Mikrofone. Und wir fangen an mit Mikrofon Nummer 2. Dass wir leider in der Übersetzungskabine nicht hören können. Also, die Antwort ist, die ersten Ergebnisse habe ich 2013 publiziert. Aus einer Sicherheitsperspektive wollte, und ich wollte das als 3 flicken. Samsung hat nie geantwortet oder mich irgendwie auf mich geantwortet. Ich habe sie nie kontaktiert über den Bootraum-Rewiderherstellungsmodus oder über die, dass das ein Sicherheitslücke sein könnte. Und über die Verwundbarkeiten im As-Boot, diese sind bereits gepatscht. Also, die Frage war wahrscheinlich, ob das an Samsung reportiert wurde. Das ist also die einzige Möglichkeit, die Geräte zu reparieren, die jetzt gerade kaputt sind? Ja, ich kenne keine andere Möglichkeit. Nachdem du jetzt die Firmware von diesem Chip gesehen hast, benutzt du überhaupt noch echte SD-Karten im wirklichen Leben? Ja, ja, es ist okay. Also, es gibt ja keine Alternative, oder? Aber ja, man könnte ja was damit machen, spielen. Weißt du, ob es noch andere Geräte gibt, die dieses Modell einer EMMC haben und dieselben Kommandos unterstützen, um an die Firmware heranzukommen? Also, das, ja, Galaxy S hat einen eindlichen Bag oder der Kindle Fire. Einige davon haben Patches und der Patch war eigentlich immer etwas in dem Stil. So, Patche, wenn das Gerät startet, ist es so, dass der Bag eigentlich nicht passieren sollte oder nicht passieren wird. Aber weißt du von irgendwelchen anderen Geräten, die nicht von Samsung sind, die dieses Samsung EMMC haben? Also, es gibt nicht so viele EMMC-Hersteller. Samsung ist ein großer Hersteller. Das heißt, viele Geräte benutzen Samsung EMMC. Das ist also schon ein sehr relevanter. Danke für deinen großartigen Vortrag und die Forschung. Meine Fragen, das Samsung Galaxy Note 2. Der hat einen relativ ähnlichen Fehler. Funktioniert dein Fix auch bei diesem Gerät? Und gibt es auch eine Möglichkeit, den Speicher zu dampen, ohne den FTL zu formatieren? Also, was war eine Rückfrage, ob es das Note 2 ist? Ich habe ein Note 2, was auf diese Art und Weise auch zum Brief für schwerer wurde. Also, zur zweiten Frage. Mein Code formatiert alle FTL-Metadata. Das ist zwar nicht optimal, weil es halt alle Metadata löscht, wie viele Mal er im Blog schon gelöscht wurde und so weiter. Eine schönere Lösung wäre natürlich die korrumpierten Daten wieder zu reparieren. Aber das habe ich noch nicht verstanden, wie das FTL intern funktioniert. Also, im Moment funktioniert es mit löschen und ihr seid natürlich willkommen, es zu verbessern. Wunderbar. Ich wüsste gerne, was der Zeitrahmen war, von da, wo du angefangen hast, das Problem anzuschauen, bis du den ersten Fix hattest. Ich habe im 2013 damit angefangen und ich hatte ein funktionierendes Gerät damals und das wollte ich halt keine bösen Sachen damit machen. Darum habe ich dann aufgehört und jetzt erst dieses Jahr oder letztes Jahr wieder weitergemacht. Und letztes Jahr hat mir ein Freund gesagt, dass er ein kaputtes S3 hat und so dachte ich mir, ja, dann versuche ich doch das mal zu flicken. Also, die addierte Zeit, in der ich daran gearbeitet habe, effektiver Arbeitszeit, war vielleicht einige Monate, vier bis fünf Monate, aber es hat schon vor vier Jahren angefangen, auf die vier Jahre verteilt. Haben Samsung SD-Karten auch die gleichen undokumentierten Kommandos? Ich denke, dass sie, also ich vermute, dass sie sowas haben, ich habe ein paar gekauft und bis jetzt habe ich so noch nicht so viele gefunden, wo, ja, also einige, einige, ich bin da noch dran. Es gibt, es gibt Karten, wo welche die Backdoor haben könnten und sobald ich mehr weiß werde, ich das natürlich veröffentlichen. Vielen Dank für den großartigen Vortrag. Ich benutze immer noch ein S3 als mein tägliches Telefon und vor ein paar Monaten fing es an, nicht mehr zu funktionieren, aber erst kam noch der Bootloader hoch und dann kam nur noch der Samsung Bildschirm und ich habe auch versucht die Software neu zu installieren, aber dann ist er auch abgestürzt, aber ich habe dann alles neu formatiert und dann ging es wieder. Das klingt so ein bisschen wie der Bug, den du beschrieben hast, aber nicht ganz. Meinst du, das hat das miteinander zu tun? Also, wenn es etwas damit zu tun hat, dann ist meine Schätzung, ja, da es dann gerade ein In-Memory-Patch hat, welches halt dieses Einfrieden verursacht und irgendwann, also das Gerät ist angefroren, bevor es Android gebotet hat und jetzt, wenn du es neu geflasht hast, wurde wahrscheinlich das interne Block-Mapping irgendwie neu gemacht, neu hergestellt und vielleicht hat es darum jetzt nicht mehr auf, aber ja, es hat ziemlich sicher hat das Telefon den Bug grundsätzlich. Hi, vielen Dank für die großartige Arbeit. Eine Frage. Du hast gesagt, du hast die Firmware der EMMC mit einer neueren Version abgegraded. Ist diese Firmware überhaupt signiert oder kann man in das EMC alles reinschreiben? Man kann alles reinschreiben. Sie haben eine einfache Heuristik, welche die Startadresse prüft, ob die plausibel aussieht und dann bootet das alles, was du willst. Ich denke, in deinem neuen E, in neueren E-AMMCs gibt es ein Mechanismus, um neue Firmware zu flaschen und ich denke, dass die dann signiert sein sollte, aber wahrscheinlich hast du noch kein neueres E-AMMC. Ich habe noch eine letzte Frage über diesen Samsung Patch. Der geht, hast du ja gesagt, einfach in eine Endlussschleife. Meinst du, das ist irgendwie eine Busy-Loop oder dass er darauf wartet, dass irgendwas passiert? Nein, ich denke nur, dass sie wollen einfach, dass der Back nicht passiert. Mein Telefon ist eingefroren, viele Male. Und ich habe irgendwie 30 Minuten gewartet und der Code im Linux-Können macht nichts und es wartet wahrscheinlich auch vor immer. Es gibt keine Fragen mehr, deswegen nochmal einen großen Applaus für den Vortragenden.