 TVO. Alisa Isage ist eine unabhängige Sicherheitsforscherin mit Netzwerkforschung. Alisa wird die neuesten Erkenntnissen zum Qualcomm Diagnostik-Protokoll zeigen, was in großen Modems drin zu finden ist. Und jetzt willkommen zu Alisa. Sie sind Alisa Isage. Ihr seid in meiner Präsentation an der Advanced-Hexagon-DAG an der Chaos-Communication Congress. Ja, hier bei 2020 Remote Experience. Und ihr hört meinem Talk zu Advanced-Hexagon zu. Mein Hauptinteresse sind komplexe und gehertete Systeme. Ich habe Windows, Kernel, Browser, Scripting-Engines angeschaut. Und jetzt habe ich Halberweise angeschaut. Das, was ich heute zeige, war ein Seitenprojekt. Der Name ist ein Understatement. Ich versuche, das hier einfach zu halten. Ein großer Teil des Vortrags wird in Baseband-Prozessoren sich beschäftigen. Der Qualcomm Diagnostik-Manager ist ein Protokoll, was von Qualcomm in den Baseband-Prozessoren drin ist. Und das ist in allen Snapdragon Silicon on Chips drin. Und die modernen Qualcomm Chips haben Spezialtechnik. Und läuft mit einem speziellen Real-Time-Operating-System. Und da sind die Diagnostik-Handler drin. Normalerweise, wie üblich mit meinen Vorträgen, habe ich das für verschiedene Zuhörer angepasst. Der erste Teil ist High-Level. Und der zweite Teil ist für spezialisierte Techniker, Programmiere, die mit diesem Thema zu tun haben. Lass uns mal von oben anfangen, wie diese Technologie zusammenpasst. Hier ist ein Mindmap. Wenn wir mit Baseband zu tun haben, dann haben wir mit folgenden Sachen zu tun. Das ist jetzt nicht vollständig, aber das sind mal die wichtigsten. Das ist jetzt die Client-Seite. Da sind jetzt keine Server-Seite-Sachen dabei. Es gibt viele Mobile-Portokolle. Von der Benutzer-Seite ist das einfach. 1G, 2G, 3G, 4G, 5G. Aber tatsächlich versteckt sich hinter diesen einfachen Namen verschiedenste sehr unterschiedliche Technologien. Es gibt ein paar wichtige Punkte zu diesen Funk-Portokollen, die man verstehen muss, bevor man sich mit diesem Thema beschäftigt. Also die 1G, 2G, das sind die Familien. Und die Generation ist ein Marketingname. Aber da gibt es keine technische Bedeutung dazu. Das ist einfach nur eine Evolutionsstufe. Wichtig für die Protokolle ist das Luftinterface. Dieses Protokoll über die Luft beschreibt, wie das Signal digitalisiert ist und wie die verschiedenen Teilnehmer an diesem Protokoll sich verhalten müssen. Historisch gab es zwei Stück, TDMA und CDMA. TDMA ist Time-Division Multiplexes. Und da wird das Elektrospektrum in Zeitabschnitte unterteilt. So dass die Telefone sich abwechseln und die Zeit in Zeitschreiben eingeteilt ist. CDMA wird in GSM verwendet. Das andere ist CDMA, das ist ein bisschen schwieriger. Code Division Multiplexes ist der Name. Und anstatt das in Zeitschreiben zu teilen, verwendet das pseudo-zufällige Code und diese Codes können dafür verwendet werden, das Protokoll zu modulieren, so dass die in unterschiedlichen Masken liegen. CDMA ist von Qualcomm entwickelt. In 2G gab es GSM und CDMA-1. Die dritte Generation dieser Protokolle, da sind die beiden Dinger weitergeführt worden. CDMA ist zu UMTS geworden und CDMA ist zu CDMA 2000 geworden. Der Qualcomm hat das ursprünglich angepasst. Und in 4G sind die beiden dann zusammengeführt worden. Und das gleiche gilt für 5G. Das ist relativ wichtig für uns. Alle diese Technologien mit der Luftschnittstelle sind Code-Stücke und Algorithmen, die in den Baseband-Prozessoren drin stecken. Und die müssen in allen Baseband-Prozessoren drin sein, egal welchen ich benutze, was es anzuhändig unterstützen könnte. Wenn man sich mit Angriffs-Sicherheit beschäftigt, dann kann man sich auch darüber Gedanken machen, dass das evolutionär entstanden ist. LTE ist nicht vollkommen unterschiedlich von GSM, sondern es hat die gleichen internen Strukturen. Wenn man in die Spezifikation anschaut, sind einige direkt relevant von 2G zu LTE. Das ist wichtig, wenn man die Protokolle darauf abklopft, wo man sie angreifen könnte. Die Mobile-Protokolle sind in Layer geschachtelt. Hier sieht man die Spezifikationen, wie die übereinander liegen. Als Nudel habe ich hinzugefügt aus Bequemlichkeit, offiziell sind die 1, 2, 3. Der interessanteste zum Angreifen ist Level 3, weil da drin die höchste abstraktesten Daten drin sind. Wenn die Leute davon reden, das Baseband anzugreifen über die Luft, dann reden sie über die Architektur. Das ist das Interessanteste. Aber lass uns mal das große Bild anschauen. Das Diagramm hier ist der zusammengepasste Blick da drauf. Es gibt zwei unterschiedliche Prozessoren, die hier drin sind, der TSP oder eine andere CPU. Die beiden sind zwei unterschiedliche Prozessoren und jeder hat ein eigenes Betriebssystem. Der Applikationprozessor kann zum Beispiel Android sein und der Baseband Prozessor hat irgendeine Ich-Zeit-Betriebssystem, das die Mobilfunkseite unterstützt. Der wichtige Punkt hier ist, dass bei modernen Implementationen dieses Basebandgerät von irgendeiner Sicherheitsumgebung geschützt ist und Android ist davon getrennt, also iOS-Unappelgeräten. Das bedeutet, dass diese Privilegien grenzig hier links ist, beidseitig ist. Das heißt, obwohl man Zugriff hat auf dem Android-Körnel, dann soll man immer noch nicht in der Lage sein, den Arbeitsspeicher vom Baseband lesen zu können oder da irgendwie draufzugreifen zu können. Zumindest bei modernen Smartphones. Und genau dasselbe ist in die andere Richtung. Das Baseband sollte nicht Zugang zu dem Applikationsprozessor haben. Die sollten sich gegenseitig nicht vertrauen. Beide Seiten sollten voneinander getrennt sein. Es gibt eine Privilegiengrenze, die wir angreifen wollen. Innerhalb des Echtzeitbetriebssystems gibt es drei große Angriffsbereiche, von links zu rechts. Links, graue Kiste, ist die Angriffsstelle der Mobilfunk-Stelle, die analysiert die Mobilfunk-Protokolle. Normalerweise gibt es da mehrere Tas im Echtzeitbetriebssystem. Und dieser Teil der Angriffsstelle sind die ganzen Schichten des Protokolls. Es gibt eine große Menge Anpaarsen, das hier stattfindet. Das zweite, die zweite Kiste, sind die Management-Protokoller. Das Einfachste, dass man denken könnte, ist das IT-Befiliprotokoll. Das wird immer noch viel benutzt. Und es wird meistens auch irgendwie zum Applikationsprozessor veröffentlicht werden. Das heißt, man kann da Befehle hinschicken. Ein bisschen interessanter ist dann, dass die herstellerspezifischen Protokoller, weil das Basement oder moderne Basements sind so komplex, dass Hersteller unterschiedliche Protokoller haben, um das zu analysieren und zu konfigurieren. Bei Qualcomm zum Beispiel ist das DEAC nur eines der vielen Protokolle, die involviert sind. Die dritte Kiste ist der RTOS Core, das Echtzeitbetriebssystem Core. Das sind ganzen integrierten Funktionalitäten im Betriebssystem. Code, der den Zugang zum Anwendungsprozessor darstellt. Auf der Seite des Betriebssystems sind auch zwei Angriffe, die vom Basement angegriffen werden können. Das eine davon ist die Treiber, weil das Basement hat eigentlich eine Profi-Anstoßstützstellen, die mit Treibern die Angriffe werden können. Und es gibt auch unterschiedliche Interface-Händlers, die vom Basement benutzt werden. Die haben ein spezielles Interface. In Qualcomm ist das geteilte Arbeitsspeicher. Das geteilte Arbeitsspeicher ist in der Regel sehr komplex implementiert und sie sind eine große Angriffsschnittstelle auf beiden Seiten. Und das dritte Teil des Diagramms ist unten die zwei kleinen grauen Kosten, die Trust des Ausführungseinheit. Die meisten haben ein Trusted, ein kleines vertrauenswürdiges Gerät. Und die einen des Wassertrins läuft, sind interessante Sachen zu der Verteidigung, die Verteidigung von Basements erforscht. Hier sind zwei Verteidigungsbereiche. Das eine ist ein sichere Call-Händler. Das ist der Grundinterface, das Aufrufe vom Anwendungsprocessor ausführt. Und das andere sind halt diese Trustlets, diese kleinen Stücke von Software, die darin ausgeführt werden. Hier gibt es auch noch weitere Informationen über Daten. Ich weiß nicht, ob die im R2S Core sind, aber die sind in der Regel ähnlich anzugreifbar. Und hier sind auch ein paar Teile davon, über die eher aufrufbar. Und hier sind ein paar Beispiele für Sicherheitslücken. Ich weiß jetzt nicht genauer analysieren, als nicht die Aufgabe von diesem Vortrag ist. Und die über Porn to Own kann man im Internet finden, was da passiert ist. Um die Basement-Verteidigungswerkzeuge zu erklären, habe ich die Diagramm zu einer einzigen Angriffsstelle reduziert. Es ist die Angriffsstelle, die vom Paarsen und der Implantation von unterschiedlichen Protokollen innerhalb des Basement-Strip-Systems erschellt wird. Es ist die Angriffsstelle, die über die Luft angegriffen werden kann. Um das benutzen zu können, brauchen wir ein Transceiver, der die spezifischen Protokolle redet. Das ist zum Beispiel ein Software-Defined-Radio. Und die einfachste Art, das zu machen, ist halt ein Blade-Out oder ein anderes Software-Defined-Radio. Und das gibt da Implementationen, wie zum Beispiel OpenBTS oder GateBTS. Und diese Software-Implementationen sind in der Regel hinter der technologischen Entwicklung. Die GSM-Implementationen sind sehr gut und sehr bekannt. OpenBTS zum Beispiel. Und als ich versucht hatte, da Analysen zu machen, war das sehr einfach. Bei UmTS und LTE gibt es weniger Software-Implementation und außerdem gibt es mehr Anforderungen für die Hardware. Zum Beispiel meine Version der Hardware ist zu schwach für UmTS. Und es gibt bei CDMR keine Software-basierte Implementation, wo man eine Base-Dation implementieren kann. Das ist ein Pseudo-Diagramm von einem der Snapdragon. Es gibt viele Generationen davon. Ich habe den zufällig ausgewählt, um ein visuelles Diagramm zu haben. Qualcomm hat High-Level-Diagramme in den Marketingmaterialien von der Architektur zugeführt gehabt, aber das tun sie nicht mehr. Das ist vom Model 820. Und das ist interessant, weil er der erste ist, der ein AI, ein künstlicher Intelligenz-Agent mit dabei hatte. Unser Fokus ist auf den Prozessor. Die meisten Snapdragon haben viele Prozessoren. Das sind mehrere armen, basierte CPUs, die halt das Android-Betrieb-System laufen lassen, dann die Android und dann mehrere Hexagons. Und in dem neuesten ist nicht nur ein Hexagon, es sind mehrere und sie sind zu unterschiedlichen Aufgaben zuwiesen. MDSP hat das Modem und das Real-Time-Betrieb-System. Der ADSP-Medien, der CDSP-Rechnen. Die Hexagons sind ungefähr die Hälfte der Rechenkraft von einem modernen Snapdragon. Zwei wichtige Aspekte hier bei dieser Hexagon-Architektur aus der Hardware-Sicht. Hexagon ist spezialisiert auf parallele Verarbeitung. Das erste Konzept sind ähnlich große Aufgabenpakete und die können gleichzeitig in diese Ausführungs-Units eingefügt werden. Außerdem macht es Hardware-Multithreading. Auf der rechten Seite ist ein bisschen Hex-Assembly. Das ist komisch. Also die geschweiften Klammern zeigen, was gleichzeitig ausgeführt wird. Und die müssen kompatibel sein, um diese Scheibe benutzen zu können. Und die können den alten und den neuen Wert von einem bestimmten Register in der gleichen Instruktion verwenden. Auf der anderen Seite ist das Hexagon-Programm-Reference-Manual. Das ist die Spezifikation. Und warum haben sie eine Architektur gemacht, um das Ding zu härten? Hier ist das Production Fusing. Die machen das häufig so, dass sie das Gerät so einfrieren, dass es hinterher nicht geändert werden kann, wo es auf den Markt kommt. Es gibt mehrere Wege, wie das gemacht werden kann. Diagnostik und Debugging-Funktionalitäten werden von der Software entfernt und zum Teil von der Hardware. Normalerweise werden sie nur von der Software entfernt und die Hardware bleibt. Und manchmal kommen die Forscher mit ihrer eigenen Software, um das wieder aufzumachen. Hier bei Qualcomm, da gab es ein internes Memo, und das hat beschrieben, was sie für dieses Production Fusing machen, um diese Debugging-Funktionalitäten zu entfernen. Für die modernen Androids, und hier auf meiner Implementation, da ist es bereits ziemlich eingeschränkt, das Basement nutzt eine separate Komponente namens MBA. Und das wird von einem Komponente im Android-Körner namens PEL betrieben. Und die Aufgabe von diesem MBA ist, die Firmware zu authentisieren, sodass man da nicht mal anderes reinschieben kann. Das ist ein anderer Aspekt von der Härtung, und das macht es schwierig, da einen beliebigen Code reinzuschicken. Also im Prinzip kann man nur eine Softwareloch ausnutzen, wenn man es finden. Während dieses Projekt ist, habe ich die Hexagon-Firmware zum Teil reverse-engineered von dem Nexus 6B. Dieser Prozess war nicht so schwierig. Ich habe die Firmware aus der Webseite geholt. Dann habe ich das Binary gesucht, was das Modemprogramm ist. Das Binary hat unterschiedliche Abschnitte. Da muss es drin aufgesplittet werden innerhalb der Firmware. Und dafür haben wir Unified Trusted verwendet. Nachdem ich das in unterschiedliche Abschnitte geschnitten habe, kann ich es in Disassembler reinladen. IDA Pro unterstützt Hexagon. Ich glaube, GSMK hat ziemlich gut funktioniert für das einfache Reverse-Engineering. Einige Abschnitte sind komprimiert. Die kann ich nicht reverse-engineeren, wenn ich sie nicht ausgepackt kriege. Das ist eine Herausforderung. Qualcomm nutzt eine interne Komprimierung. Der Hauptansatz von Reverse-Engineering ist ein real-time-operating-System. Da müssen Taskstrukturen sein und von da müsste ich zu interessierendem Code finden. Es kann sein, dass ich Dinge finde, die Taskstrukts aussehen, aber das hat keine Lock-Strings. Deswegen ist es schwierig, sich darin zurechtzufinden. Die Lock-Strings sind natürlich von einem Q-String entfernt worden. Das MST-Unterstrich-Hash-File sollte eigentlich nicht zur Verfügung stehen, weder auf dem Mobilgerät noch sonst wo. Ich denke, dass dieses File der einzige Art weg ist, um das zu machen. Die Lock-Strings haben dann die Namen von den Quellmodulen, die daraus gebaut wurden. Das gibt mir dann die Möglichkeit zu verstehen, was das Ding tut. Die debugging gab es bei mir nicht. Da hätte ich zwei Monate mehr gebraucht. Am besten müsste man einen Software-Debagger herstellen. In der Referenz, im Referenzabschöne-TV am Vortrag angeben. Wir müssen irgendwie Callbacks zu einem Software-Debagger in das Baseband hineinfügen. Das muss in dieser Task-Zone passieren. Hier sieht die Firma aus ohne die Lock-Strings. Hier sind schon ein paar Namen. Es gab anfangs keine Namen, sondern nur Hashes. Jeder Hashes ist ein Lock-String, das von einem Message-Hash-File genommen ist. Hier sieht man, wie man die Texteinträge hinzufügt und die Funktionen umbelandt hat. Da kann man dann hunderte von Prozeduren finden, die direkt mit dem DIAC-Subsystem zu tun haben. Da gibt es welche, die über die Luftschnittstelle gehen. Aber leider sind diese Luftschnittstellen-Vektoren in dem Bereich, der nicht direkt zugänglich ist. Ich habe jetzt verschiedene Sachen ausprobiert, während dieses Projekt ist. Ich habe das MSM Kernel gebaut, da war nichts Besonderes. Ein weiterer Ansatz ist, wenn man alte Firma reinlädt und die Firma downgraded und die Firma hat schon bekannte Probleme. Wenn ich die Firma reinlade, dann mache ich das Ding angreifbar und dann kann ich es ausnutzen. Und dann kann ich es vielleicht auch auseinander nehmen und anschauen. Das hat funktioniert und es war einfach. Ich habe versucht, die Qualcomm-Firmware zu bauen aus deren Source Code. Ich habe das nur ein paar Tage versucht und ich habe es in der verfügbaren Zeit nicht geschafft. Aber das ist nicht kritisch. Das ist jetzt nicht direkt relevant, um da neue Probleme zu finden. Ich habe es für später gelassen. Ich habe auch Ramdumps gemacht und das ist auch ziemlich gut zugemacht. Das ist mir schon gefallen. Und auf einmal ist mir Qualcomm DIAC wieder eingefallen. Anstrengend, während der ursprünglichen Nachforschung, habe ich ein paar White Papers gefunden, wo das drin erwähnt war. Es schien mir sehr mächtig, um das Baseband zu konfigurieren. Also habe ich es erst einmal getestet. Vielleicht wäre ich damit möglich, da reinzuschauen. Und vielleicht bin ich in der Lage, das in dem Lockdown auch zu verwenden. Und dieses proprietäre Protokoll Qualcomm UCDM ist das proprietäre Protokoll. Das ist für Entwickler von diesem Betriebssystem nicht für Benutzer. Das hat ungefähr 200 Kommandos in der Theorie runterladen. In 2010 wurde das teilweise reverse engineered. In einem Open-Source-Projekt namens Modem Manager. Und dann ist es beim 3C11 in 2011 auch noch mal gezeigt worden. Und diese Präsentation hat das dann auch populär gemacht. Aber leider ist die für moderne Telefone nicht mehr gültig. Aber es gibt eine allgemeine Übersicht, womit man es zu tun hat. Und dieses Protokoll, das ist also für mich jetzt ein lokaler Angriffsvektor. Und das kann sehr nützlich sein. Insbesondere, wenn man Handys hat, die für einen spezifischen Mobilfunkanbieter gelockt sind. Es ermöglicht, Code auf dem Baseband direkt auszuführen und Einstellungen zu ändern. Normalerweise wurde es über 80 Befehle gemacht, aber auch sogar andere Befehle, die sehr hilfreich sind. Wie kann das angegriffen werden? Man kann zum Beispiel in Software basierten Debugger initiieren. Wenn man in DIAC einen Bug hat, dann, wo man Schließ- und Schreib-Zugriffe auf das Beste hat, kann man Les- und Schreib-Hooks haben. Und damit kann man ein Satz für Basierten, die Bugger haben, auch wenn er offiziell nicht nützlich sein sollte. Was hat in den letzten 10 Jahren im DIAC passiert, was hat sich da geändert? Zuerst die originale Publikation hat Qualcomm Baseband mit arms basierten Servern und einem RTOS-REx-Betrieb-System. Heutzutage ist das alles hexagon und nicht mehr arm, und Rex wurde durch Q-U-R-T ersetzt. Es hat immer noch ein paar Inhalte von Rex, aber es ist eigentlich ein anderes Betriebssystem. Die meisten sehr wertvollen Befehle, die sehr mächtigen Befehle, Arbeitsspeicher lesen und schreiben, wurde auf meinem Gerät entfernt. Und es gibt auch keine einfach verfügbaren Kanäle, zum Beispiel USB. Es soll irgendwie möglich sein, die Geräte wieder zu freizugeben in USB-Kanäle, aber braucht man hier speziellen Bootfeinschlangen und ... Es ist in der Regel nicht verfügbar. Das war jetzt mein Test-Rett des Nexus 6P und sollten mit dem Mittellevel von ... Sicherheitssachen sein. Moderne Google Pixel sollten noch weniger Fähigkeiten haben. Insbesondere bei Google, weil die auf die Sicherheitserhöhung aufpassen. Auf der anderen Seite, wenn man Modem-Sticks sich anschaut, USB-Sticks sind teilweise offener und einfacher anzugreifen, dass man sie einfacher analysieren kann. Das Direktprotokoll in der Architektur ist relativ einfach. Das Diagramm zeigt, dass im Endeffekt dasselbe Diagramm, was wir am Anfang hatten. Links ist der Android-Körnel und rechts ist das Baseband-Betrieb-System. Direktprotokoll kann von beiden Seiten angriffen werden, weil es auch Nachrichten, die von Baseband auf den Anwendungsprozess weitergeleitet werden oder gesendet werden. Die grünen Pfeile sind ein Beispiel wie Code, durch Dividaten dadurch fließt. Aus dem Baseband in den Applikationsprozessor. Dann fließt die Daten halt auch in beide Richtungen. Die Haupteinheit ist dieses Diaktask. Der hat einen eigenen Task, der insbesondere die ganzen Anforderungen zum Diaktprotokoll umsetzt. Der Datenaustausch zwischen Diaktask und anderen sind über Buffer, wenn wir den Datenringenbuffer realisiert. Wenn einer das Task etwas schreiben möchte durch den Diakt, benutzt es eine spezielle Lock-Appi. Die Locking-Daten werden auf den Ringenbuffer gelegt. Der Ringenbuffer wird entweder durch Timing oder Software Interrupts ausgelesen. Zu diesem Zeitpunkt werden die Daten in Diaktprotokoll Nachrichten eingewickelt und wir senden sie als Serial-Daten und senden die Daten zum Output zu einem spezifischen Interface, wo das hängt von der Konfiguration ab. Das Hauptinterface, mit dem ich gearbeitet habe, ist dieses geteilten Arbeitsspeicher, in dem die Aktscharotreiber sind im Android-Kernel. Von dort geht es zu einem speziellen Task im Baseband und endet in der Diaktasche und potenziell in anderen responsiblen Taschen. Auf dem Android-Kernel ist Diakt mit dem Dem-Diakt-Device, welches die Diaktascharotreiber und Diaktascharotreiber in den MSM-Kernel verwendet. Das Ziel der Diaktascharotreiber ist, die Diaktascharotreiber in den MSM-Kernel zu unterstützen. Es ist ziemlich komplex im Code, aber funktioniell ist es ziemlich einfach. Es hat ein paar basicen Minimum von Diak-Kommunz, die die Konfiguration der Interface auf dem Baseband-Schein enthalten. Und dann kann man die Diaktascharotreiber in den MSM-Kernel multiplizieren. Es hat auch ein paar ARC-Tails für die Konfiguration, die von dem Android-Kernel existiert. Und finally, die Diaktascharotreiber filteren viele Konfigurationen, die es unnötig ist. Das ist ein bisschen wichtig, weil, wenn du startest, wenn du tryst, ein paar Tests zu tun und die Konfiguration der Diak-Kommunz durch den Diak-Interface sendest, du würdest die Diaktascharotreiber in den MSM-Kernel zu verbinden. Ansonsten wird die Konfiguration der Diak-Kommunz nicht auf dem Baseband-Schein enthalten. Ansonsten wird die Diaktascharotreiber auf dem SMD-Schein-Memory-Device-Interface enthalten. Das ist eine Konfiguration der Diak-Interface, die für die Konfiguration der Diak-Kommunz ist. Also, das ist, wo die Diak-Kommunz auf dem Diak-Kommunz ist. Der Diak-Scharotreiber ist in der Applikation OS-Vendor-Specific-Drivers. Und dann gibt es ein paar Shared-Memory-Implimentationen in der Baseband, die es handelt. Der Diak-Scharotreiber hat viel Code, aber die Funktionalität ist relativ einfach. Es implementiert einige kleinen Sachen. Ich habe jetzt nicht genau nachgeschaut, was das alles ist. Es gibt das Gerät weiter zum Schreiben in den Sprecher. Aber normalerweise kann man den Diak-Kanal nicht direkt zugreifen. Weil um den Diak-Kanal zu zugreifen, muss man den Diak-Kanal nicht direkt zugreifen. Um den Diak-Kanal zu zugreifen, muss man diese Diak-Switch-Login-Funktion benutzen, die den Kanal der ADEF umgeschaltet. Hier sehen wir unterschiedliche Modi. Und nur zwei werden im USB-Modus unterstützt und im Arbeitsspeichergerät. USB-Modus ist der Standard. Und wenn man den Treiber normalerweise geöffnet und davon versucht zu lesen, funktioniert das nicht, weil es normalerweise USB ist. Um zu konfigurieren, dass es den Arbeitsspeichergerät benutzt, muss man einen speziellen Code senden. Es gibt hier diese Funktion Mask Request Validate, die einen sehr starken Filter anwendet, der auf alle Befehle angewendet wird, die man versucht zu senden. Versucht alles auszufiltern, bis auf ein paar grundlegenden Konfigurationsanfragen. Grundlegend wird dieses geteilte Arbeitsspeicher benutzt, um mit dem Maceband zu reden. Und das ist ziemlich komplex. Es leitet die Lese-RP, um die Daten aus dem Arbeitsspeicher zu lesen. Das ist eine der APIs. Der geteilte Arbeitsspeicher hat auch abstrakte Kanäle, die durch ein SMD Open-Nedge aufgerufen wird. Es können gewisse Befehle Kanäle geöffnet werden. Jetzt schauen wir uns doch mal diese Software Shared Memory Gerät, weil das ein Teil der Angriffsfläche ist, um vom Modem auf den Applikationsprozess zu sich zu erweitern. Wenn man nur auf dem Basement Konfiguration hat, dann ist es relativ sinnfrei, weil es dort das Hauptbetriebssystem nicht einzugreifen kann. Um es nützlich zu machen, braucht man eine Angriffskette und... eins, davon ist es mal eine Privilegien-Erreiterung hat. Und dieser Shared Medium ist eine dieser Angriffsfletschstellen. Das geteilte Arbeitsspeicher und Shared Memory Gerät wird von den Qualcomm Anschlussen freit, angezeigt oder weitergerätet. Und hier ist ein Pointer auf den Anfang des Bereiches. In dieser Bereich hat es ein Konzept von Kanälen und Einträgen. Das heißt, es gibt unterschiedliche Teile, die durch eine Funktion SMM Gate Entry aufgerufen werden können. Und eine dieser Einträge ist eine Liste von Kanälen, die geöffnet werden können. Von dort können Kanäle geöffnet werden und das Interfest kann benutzt werden. Nach diesem anfänglichen Forschungsprojekt war es mein Ziel, das gesamte System zu analysieren. Als ich auf diesen Vortrag vorbereitete, habe ich ein paar andere interessante Sachen im Calecode gefunden. Zum Beispiel gibt es einen speziellen Treiber, der... G-Tag My Region benutzt. Im Treiber wird es nur gelesen. Man kann ja nichts aufschreiben, aber mal schauen. Und dann lass uns auf das Dialog Protokoll selber schauen. Was ich gemerkt habe war, dass es in unterschiedlichen Orten benutzt wird. Beliebt zum Beispiel Snoop Snitch kann Protokoll Dumps ermöglichen und um das zu verfügen, um das zu machen, sendet es ein Befehl, ein paar Befehle zum Gerät, ein Blob und niemand weiß, was dieser Blob machen. Ich wollte wissen, was machen diese Befehle. Aber bevor wir uns das näher anschauen können, müssten wir das Protokoll unterstützen. Der Protokoll hat 200 Befehle oder Pakete. Ein paar der sind offen dokumentiert, aber einige sind es nicht. Hier rechts kann man sehen, manche der Kommentare fehlen. Und einer dieser fehlenden Kommentare ist der Nr. 9-2 Exhalizimal. Und das ist die Hashlock Nachricht. Befehlformat ist relativ einfach. Sieben E ist das Beispieletoken hier. Und es fehlt in der offenen Dokumentation. Und das Directbefehl hat mehrere. Es gibt rundherum den Rapper mit sieben E. Dann gibt es den Hauptbefehl. Und dann gibt es variable Länge an Daten, die weitere Unterbefehle enthalten kann. Das Ganze wird mit einer CST überprüft und ein paar Bytes werden ignoriert. Eine interessante Sache mit dem Direct Protokoll ist, dass es Untersysteme unterstützt. Unterschiedliche Systeme können ihre eigenen Diak-System-Händler anmelden, beliebiger. Und es gibt nur spezielles Befehl, der dem Diak-System sagt, hey, gibt dieses Befehl zu dem relevanten Subsystem weiter. Und es wird dort analysiert und ausgeführt. Es gibt eine große Anzahl von Untersystemen. Nicht alle von denen sind dokumentiert. Und als ich anfing, dies zu analysieren, merkte ich, dass es ein Diak-Subsystem existiert. Das Letztere fand ich sehr interessant, weil ich hoffte, dass es weitere Analyse-Methoden existiert. Aber das Diak-Subsystem ist relativ einfach, es unterstützt nur einen Befehl. Und das war Injected Crash, so abstürzen lassen. Also man kann einen speziellen Diak-Befil senden, der dafür, dass ihr das Baseband abstürzt. Ich werde später darüber mehr berichten. Jetzt ein paar Beispiele. Dies ist ein Snipple aus dem Code, den ich in SnubSnitch gefunden habe. Dieser Block hat vier logische Teile. Der erste Teil ist irrelevant. Es sind ein paar Sachen, die Informationen aus dem Baseband brauchen, wie die Reaktion, Bild-Idee gebaut wurde, ein paar Kommentare. Also ein paar Befiele, 37 Hexatecimal, und das ist der Command-Lock-Configuration. Es ist ein Befehl, der Protokoll-Dumps ermöglicht und sie konfiguriert. Und der dritte Teil ist der Befehl, das ist der Command-Hex-Message-Config, das soll Text loggen. Aber bei SnubSnitch bestellt es alle Logging-Funktionalitäten auf Aus. Wie funktionieren jetzt diese Protokoll-Dumps? Es ist teilweise dokumentiert. Die Protokoll beinhaltet den Code und den Unterkommentar-Mask in diesem Fall. Und es veracht auch die ID. Und das hängt davon ab, welches Protokoll wir dumpen wollen. Und es wird gefiltert. Und es ist relativ offensichtlich. Jetzt das zweite Kommando, wo die Nachricht konfiguriert wird. Ex-Message-Config. Das Kommentarformat ist nicht dokumentiert. Der Kommentar besteht aus Unterkommentar. Hier setzt er die Maske. Und dann kommen 2 16-Bit Integer. Das sind SSID Anfang und Ende. Und das ist die Subsystem-ID. Das ist was anderes als ein Direktnosesubsystem. Und das Letzte ist die Maske. Die Subsystem-IDs werden dafür verwendet, um die Nachrichten zu filtern, je nach Subsystem. Und wenn die alle anfangen, im Basement zu loggen, dann wird es sehr viel Daten. Und deswegen muss man da halt zerk rausfiltern. Auf das, was einen interessiert. Hier ist ein bisschen Python-Code. Wie man Text-Messages für alle Subsysteme einschalten kann. Man muss die Maske auf alles einsetzen. Und das gibt eine ganze Menge Log-Infos nach meiner Erfahrung. Um diese reinkommenden Nachrichten zu pausen, gibt es 2 Arten von Tokens, die beide nicht dokumentiert sind. Das Nr. 79 Hexatezimal ist die Message. Die ist ASCII-basiert. Die kommt durch das Direktinterface. Und damit kann ich es einfach lesen. Das 2. Und das ist das Diagnostikkommando LogHash. Und das ist 0x92. Und da sind nur die Hashes drin. Wenn ich das Message-Hash-Txt-File habe, dann kann ich den hash dort nachschauen. Und den Text zurückwinnen. Unten sind 2. Beide haben einen ähnlichen Aufbau. So, da sind Argumente mit dabei. Dann kommt ein 64-Bit Timestamp. Dann kommt die SSID-16-Bit. Die Zahlennummer. Ich bin mir nicht ganz sicher, was das nächste Argument ist. Entweder die ASCII-Nachricht, den Rotext oder der Hash von dem LogString. Und potenziell kommen da noch ein paar Argumente. Im ersten Fall sind die Argumente in der Nachricht. Und im zweiten Fall sind sie nach dem Hash. Zumindest in meiner Version. Hier ist ein Diagnose-Paket, das mir die Möglichkeit gibt, das Baseband abschützen zu lassen. In meinem Fall hat es nicht funktioniert. Das ist aber nicht ins Baseband reingekommen. Es wird jetzt eigentlich erwartet auf einem Produktionsgerät. Es ist halt rausgefiltert worden, aber wahrscheinlich funktioniert es auf irgendwelchen anderen Geräten. So, um das jetzt alles benutzen zu können, habe ich ein einfaches Tool gebraucht mit 2 Funktionen. 1. Direkt der Zugriff auf das DEFDIAC-Interface. Wahrscheinlich eine Python-Shale. Und das 2. LogStringslesen und Pausen. Ich habe ein Framework geschrieben, das heißt Direct Talk. Und das ist direkt dieses DEFDIAC-Interface im Android-Körne. Und auf der rechten Seite ist das Message-Log, mit den LogStrings, die ich rausgeholt habe. Das Log ist sehr interessant. Sehr detaillierte Informationen, GPS-Koordinaten. Und wo das Baseband versucht, mit verschiedenen Kanälen sich zu verbinden. Und ich glaube, das ist sehr nützlich für Angriffsforschung. So, zusammenfassend, Hexagon ist ein anspruchsvolles Angriffsziel. Wahrscheinlich braucht man mehrere Monate, um noch wirklich etwas zu erreichen. Ich bin darüber nachzudenken, ein Software-Debagger zu schreiben. Das ist wahrscheinlich der verlässlichste Weg, um hineinschauen zu können. Und ich habe ein paar leere Stellen gefunden, die man noch auszufüllen gilt. Es gibt noch andere Qualcomm-Portikale. Da gibt es mehrere. Da gibt es QMI, das ist weniger bekannt als DIAC. Dann muss man eine Emulation bauen. Also der Decompiler muss gebaut werden. Da gibt es drei Angriffswege. Der erste ist Debugging, Software-Base-Debugging. Oder man muss übers JTAC irgendwie reinkommen. Und dann vielleicht über die Luft. Und vielleicht kann man aus dem Baseband in den Anwendungsprozessor eskalieren. Für das Baseband gibt es interessante Angriffspunkte. OsmoCom-BT kann man verwenden. OsmoCom-BB braucht ein Update. Das ist die einzige Open-Source-Baseband-Implementierung, in der es so alt ist. Und das ist eine richtig komische Hardware. Es gibt keine Software-basierte CDMA-Implementierung. Oh mein Ton. Kein Ton mehr da. Ich habe auch keinen. Also Elisa, Fragen vom Publikum. Hast du einen Mobile-Telefon und vertraust du ihm? Nein, ich nutze nur Twitter. Gibt es auch irgendjemanden, der so etwas benutzt? Keine Ahnung. Gibt es... Hast du ja auch mal den Qualcomm-WLAN-Chips angeschaut? Diese Informationen, da hatte ich nur ein Gerät. Das heißt, ich hatte noch nicht Zeit, alles zu anschauen. Aber ich habe gesehen, dass die Qualcomm-WLAN-Chips drauf haben, die auch auf Hexagon basiert sind. Und sie benutzen ähnliche Primitiven. Low-Level-Primitiven. Man könnte sich das durchaus mal detaillierter anschauen. Okay, thanks. Ich nenne Sie eine technische Frage. Anstelle die großen DR-Triber zu analysieren, wäre es möglich, den arbeitenspeicher in die Tieselenz zu mapen und darüber die Werte zu senden. Das hängt davon ab, welche Hinterrund man hat und welche Ziele man hat. Standardmäßig kann ein Angreifer nicht beliebiger DIAC-Befeder senden. Das heißt, wie dem auch sei, irgendwas muss man hocken. In der Regel benutzt man seinen eigenen Treiber und sende diese Daten direkt zum DIAC-Interface. Anderes wäre, den geteilten Arbeitsspeicher direkt zu greifen. Und die Implementation ist ziemlich komplex. Das heißt, die einfachste Weg wäre es, direkt auf den Driver zuzugreifen und den zu benutzen. Okay, thanks. Wow, ist das... Es gibt eine Frage, die die Primitiven erhält. Vielleicht kann man es auch machen. Ist das typisch gut, die Charakter für mobile Phones? Ist das alles üblich mit der Sicherheit für mobile Telefonen? Dieses Level mit Hardening ist mittelmäßig. Produktions-Telefone werden teilweise noch mehr gehärtet. Wie zum Beispiel die schneusten iOS-Geräten oder den Google-Telefonen. Wir sind noch besser geschützt als das, was ich besprochen habe. Vielen Dank. Es sieht nicht so aus, als ob wir noch weitere Fragen hätten. Wenn ihr noch weitere Fragen stellen wollt, dann gibt es den Feedback-Tab, der unter dem Video existiert. Und schreibt eure Fragen dort rein. Und das ist ein Toller, mit ihr zu greifen in den Vortragenden. Damit sind wir fertig mit dem heutigen aktuellen Vortrag. Vielen Dank. Ich werde jetzt weiter zu der Herold Nachrichtenschau weiterleiten.