 Das Publikum mag Wavey also nicht. Wir werden jetzt mehr hören, was Wavey ist. Wie man das brauchen kann, wie man das im Userspace ausführen kann. Unser Speaker ist Jethro Beakman. Ja, also du hast die Bühne, Jethro. Herzlichen Dank für die Einführung. Ich bin ein PhD-Student an der UC Berkeley und in meiner großzügig gemessenen Freizeit mache ich viel Reverse-Engineering. Ich habe mir Wavey angeschaut, also der moderne Ersatz für das BIOS. In diesem Tag stelle ich eine Werkzeuge vor, die ihr verwendet könnt, um UEFI Reverse zu engenieren. Von mir und von anderen geschrieben. Als Projekt hat angefangen, habe ich eine neue SSD gekauft für mein Laptop. Wie ihr vielleicht wisst, haben moderne SSDs eingebaute Verschlüsselung. Ob das sicher ist oder nicht, ist eine gute Frage. Aber SSD-Firma zu Reverse-Engineering ist ein Tag für einen anderen Tag. Ich wollte diese Verschlüsselung verwenden mit dem eingebauten Passwortoption der Wavey-Funktion. Also das ist das Passwort, das ich verwenden wollte hier. Also ein ziemlich sicheres Passwort, offensichtlich 64 Zeichen lang. Das schien gut zu funktionieren. Und ich dachte ja, meine Festplatte ist verschlüsselt. Wenn man sich überlegt, wie könnte das denn funktionieren, dann fällt eine Diskrepanz auf. Weil so, wie das Passwort eingegeben wird, und zur Festplatte übertragen wird, mit deinen Security Features set unlock command verwendet. Wenn man sich jetzt das anschaut, dann sollte das Passwort da 32-byte lang sein. Also wie kann jetzt das gehen, dass die 64 Zeichen in 32-byte umgewandelt werden? Wenn jetzt mein Laptop kaputt geht, und aber die SSD noch geht, will ich natürlich die SSD rausnehmen in einen anderen Computer, einbauen, um meine Daten wieder herzustellen. Also ich habe jetzt die übliche Verdächtige ausprobiert, also das abzuschneiden oder so übliche Herrschfunktion zu verwenden. Aber diese Dinge haben alle nicht funktioniert. Also dann auf den Folgen an, da wirklich reinzuknien, dieses Problem. Also könnte das auch im Prinzip ein alternativen Titel dieses Talk sein, wie man 64 Zeichen in 32-bytes umwandelt. Also was sind die Herausforderungen, wenn man Wavy Reverse-Engine will? Also das Erste, das läuft, wenn man den Computer einschaltet. Also das heißt, man kann nicht einfach einen üblichen Debuggen nehmen. Also klar, Leute, die firmware entwickeln, als Hauptberuflich haben irgendwie ein Werkzeug dafür, aber das funktioniert wahrscheinlich nicht für so ein Consumergerät, wie dieser Laptop. Vielleicht kann man das irgendwie emulieren, die firmware, aber die Hardware wird wahrscheinlich nicht korrekt emuliert, wenn man so ein Emulation-System benutzt. Also es ist wahrscheinlich nicht so realistisch, das so zu machen. Weil das Wavy eigentlich nur ein großer Prozess ist, also in einem Adressraum läuft, gibt es kein Betriebssystem, also gibt es keine System-Calls. Und es gibt keine dynamischen Linker und keine dynamischen Symbolen, keine Symbol-Tabellen, die man als Ausgangspunkt nehmen kann beim Reverse-Engineering. Das bei üblichen Passwortprogrammen im Userspace würde man zum Beispiel anfangen mit dem Read-System-Call, also beim User angezeigt wird, dass es ein Passwort eingeben soll, aber bei UEFI geht das halt nicht. Obwohl es kein dynamischen Linker gibt, besteht die ganze firmware aus 281 Modulen in meinem Fall hier. Also es kann natürlich einfacher sein bei euch. Also diese Module müssen ja irgendwie miteinander zusammenspielen. Also schauen wir ein paar dieser Module an. Also es gibt das UEFI Tool. Das sollte in eurem Werkzeugkoffer dabei sein jedes Mal, wenn ihr was mit UEFI macht. Also ich benutze hier mal UEFI Extract. Das ist ein Kommando-Zeilen-Programm, das zu diesem UEFI Tool gehört. Und das erlaubt es aus diesem Firmware-Blob Zeug zu extrahieren. Also das ist jetzt von der CD geladen. Nach dem Entpacken habe ich diese schöne Ordner-Struktur mit einem Unterordner pro Modul. Wie man hier sieht, ja es ist ein ziemlicher Handvoll. Das ist zum Beispiel System Management Mode Control Modul, Timer-Modul. Und jedes Modul hat hier Unterordner mit verschiedenen Abschnitten dieses Moduls. Eines, das da oft vorkommt, ist das PE32 Plus Image. Das ist das Portable Execution Image. Also das gleiche Format, das Windows für Binär-Dateien verwendet. Also dachte ich mir, ja vielleicht kann man die halt ausführen. Ja, das stimmt. Zuerst schauen Sie uns mal an, was passiert, wenn ein Modul ausgeführt wird. Jedes Modul hat einen Einstiegspunkt, der heißt Main. Die Main-Funktion wird dieser Pointer übergeben auf eine System-Table. Das ist ein Struct mit Pointer auf andere Structs. Also zum Beispiel für die Terminals, also Eingabeausgabe und Standard Error. Und eine Struktur Boot Services. Diese Struktur enthält diese Funktionspointer. Zu den Funktionspointer gehören unter anderem Installed Protocol Interface. Das erlaubt einem Modul eine Protokollschnittstelle zu installieren. Spezifiziert euch in der bestimmte GUID, eine bestimmte eindeutigen Identifier und ein paar Vault-Pointer für weitere Argumente. Andere Argumente können dann, andere Module können dann später die Locate-Protokoll-Funktion aufrufen mit dieser GUID und können dann den Pointer auf das Modul erlangen. Die meisten Module fangen daher in ihrer Main-Funktion damit an, dass sie diverse Protokolle laden und danach installieren sie eine oder mehrere eigene Protokolle. All das passiert zur Laufzeit. Das heißt, es gibt ja keine statische Möglichkeit, die Abhängigkeiten zwischen den Modulen sich anzuschauen. Glücklicherweise können wir diese Module vielleicht ausführen, wie vorher schon angedeutet. Diese Module sind schließlich geschrieben worden für die Hardware, die du benutzt mit einem aktuellen Interface. Das heißt, die haben ein dazu kompatibles Instruktionssatz. Das heißt, man muss nur das entsprechende Interface für die Anwendung dazu bauen. Das habe ich getan mit dem Tool EFI-PE-Run. Stell dir das vor, so wie Rhyne für UEFI. So wie Rhyne ist euch erlaubt, Windows-Programme unter Linux auszuführen. Erlaubt es euch, EFI-PE-Run, UEFI-Module unter Linux auszuführen. EFI-PE-Run hat diverse Funktionalitäten. Es enthält viele der Standard-APIs, die bei EFI dazugehören. Es ist sehr einfach, weitere Module für weitere APIs hinzuzufügen. Zur Laufzeit können außerdem fehlende APIs automatisch generiert werden mit leeren Funktionen. Es gibt Annotationen an dem Speicherabbilder, damit man sieht, welcher Teil des Speichers durch welches Modul reduziert wurde. Man kann das in einem normalen Debug wie GDB ausführen, die man so kennt. Außerdem, als interessanter Punkt am Rande, ist es das einzige Programm, das ich online finden konnte, das den Cross-Minus-Stitted-Arc-Header verwendet, dass dieser Header dafür verwendet wird, Funktionen mit einer variablen Anzahl Argumente über verschiedene Calling-Conventions hinweg aufzurufen. Das ist also anschauen, was passiert, wenn wir ein UEFI-Modul aufrufen. In dieser Demo-Demonstration werde ich einfach ein EFI-PE-Run ausführen, auf einem Modul umzuschauen, wie es mit anderen Modulen interagiert. Ich habe da so ein kleines Rubi-Script geschrieben, dass den Verzeichnungsbaum abläuft, den wir gerade eben schon gesehen haben, den wir da extrahiert haben, und dass dann all die, das dann auf jedem einzelnen Modul EFI-PE-Run ausführt. Da sehe ich einen Fehler einer Assertion, die fehlgeschlagen ist, die ich vorher noch nicht gesehen habe. Das macht immer Spaß. Ich habe 281 Prozesse worden ausgeführt, und jetzt können einfach normal aus ihrer Men-Funktion zurück. Manche davon hängen in der Entloscheife fest, die werden wir dann automatisch abbrechen. Wissen Sie uns jetzt anschauen, was all diese Module, die ausgeführt wurden, von EFI-PE-Run ausgegeben haben. Wir sehen können, gibt es einige Sack-Falls hier, Speicherfehler, was verständlich ist, weil Sie vermutlich davon ausgehen, dass der Speicher irgendwie eingerichtet wurde, auf eine Art und Weise, was wir natürlich nicht hier getan haben. Aber einige Module funktionieren tatsächlich, wie zum Beispiel der System Boot Manager. Ihr könnt hier sehen, dass das einige Dinger ausdruckt, Informationen über die Version von irgendwelchen Programmen, Copyright Informationen, fordern einen Protokoll an. Dieses, die GUID, das fordert einen Protokoll an, dessen GUID schon festgelegt wurde von der UEFI-Spezifikation. Wir wissen also, was die bedeutet. Und dann ruft es einige Funktionen auf diese Module auf. Und danach startet es ein eigenes Protokoll, ebenfalls ein Protokoll, das von der UEFI-Spezifikation festgelegt wurde. Ein anderes interessantes Modul ist das System Splash-Modul. Das können wir hier uns anschauen. Wir sehen können, fordert es einige Protokolle an, die nicht von EFI-PE-Run implementiert wurden. Ihr seht also, wie hier automatisch Dummy-Interface generiert wurden. Und dann stellt ihr fest, dass es einige Funktionen in diesem Dummy-Interface aufruft. In diesem Fall die Funktion Nummer 2. Und weil wir diese Funktion nicht anfangen können, brechen wir einfach ab. Okay. Jetzt habe ich euch gezeigt, wie wir diese verschiedene Module ausführen können. Jetzt können wir anfangen mit dem Reverse Engineering um herauszukriegen, wie die 64 Zeichen zu 32 Bytes werden. Erinnert euch an dieses Bild aus der von der zweiten Folie. Oben links ist eine kleine Grafik, die angezeigt wird bei der Passortabfrage. Diese Grafik muss also irgendwo gespeichert werden in dieser Firmware, und es muss Code da sein, der diese Grafik anzeigt. Lass uns also schauen, welche Module etwas zu tun haben könnten mit Grafikmanipulation, Grafikanzeige. Stellt sich heraus, dass nur vier Module Dateinamen haben, die so klingen, als würden sie was mit Grafik oder Bildern tun. Das erste dieser Module, stellt sich dann heraus, ist wiederum aufgehoben von einem anderen Modul, namens Lenovo Prompt Service. Und dieses Modul enthält wie doch immer so einen Datenbereich genau das Bild, das wir kennen von dem Passwort Prompt. Das heißt, wir wissen, dass dieses Modul etwas mit dem Passwort Prompt zu tun hat. Dieses Modul Prompt Service ist nur von einem einzigen anderen Modul aufgerufen. Einem Modul, namens Lenovo Password CP, das heißt sowas wie Password Einstellungsmodul, Password Control Planner. Das wiederum, Lenovo Password CP ruft noch drei andere Module auf, Lenovo Sound Service, also ein Ton, wenn das Passwort falsch eingegeben wurde. Lenovo Translate Service, Besetzungsdienst, das habe ich reverseingeniert und herausbekommen, dass es verwendet wird, um Ascii Zeichen zurück zu übersetzen in die Scan Codes der Tastatur. Diese Scan Codes werden jeder Taste der Tastatur zugewiesen, das ist die Art und Weise, wie die Tastatur, die Hardware mit dem Rechner kommuniziert. Und schließlich ist da das Modul Lenovo Crop Service, das, so stellt sich heraus, ist eine Standard Shard 256 Heischfunktion. Okay, dann schauen wir uns jetzt mal eine andere Demo an. In dieser Demo werden wir dann angucken, was diese Funktion der Lenovo CP Modul genau tut. Also wennlau p if i run es erlaubt, Die zweite wird nach dem Funktionsaufruf ausgeführt. Also zuerst rufen wir hier Install irgendwas auf und nachher rufen wir dann Call auf. Die Installationsfunktion hier macht hier ein Stubb Lenovo Crypt Service Protocol. Das ist nötig, denn das übliche Service ruft in Management Mode Hashing auf und das geht halt im Linux User Space nicht. Die zweite Funktion, Call Lenovo Password CPHCC, bestimmt die Adresse in der Funktion und ruft dann diese Funktion auf. Dann nimmt sie zwei Argumente in und out. In ist dieser Unicode string myPassword und out ist dieser ArrayBuffer hier. Dann wird einfach dieser Puffer ausgedruckt nach dem Aufruf dieser Funktion. Wie ihr hier seht, tut dieser Lenovo Translate Service dieses Protokoll E3 unsweit installieren. Dann später wird das Password Modul dieses E3, was auch immer aufrufen. Man sieht hier, dass das Password CPH Modul noch ein anderes Protokoll anfordert, 7.3. Das Lenovo Crypt Service Protokoll, also wir vorher installierten. Und hier gibt es hier ein paar Speicheroperationen und am Ende kommt dann Output raus. Also ich habe jetzt diese Funktion reverse engineered beim Offset 8CC. Also tatsächlich ist es die folgende Funktion hier. Es nimmt den Input, das Password, und wandelt es in ScanCodes um. Und dann wird es gepaddert auf 64 Zeichen. Und dann nimmt man davon Schad 256 Herrsch und zeigt davon die erste Hälfte an. Also, da ist es. Also wir haben die erste Hälfte reverse engineered, das Passwort Algorithmus ist. Da hat mich etwa 3 Wochen gedauert, das Ganze zu reverse engineern, und hier ist es. Das ist was wir gerade gesehen haben, dieser Herrsch. Dann wird er zusammengehängt mit der Seriennummer und Modellnummer des Laufwerks. Das Ganze wird dann nochmal geherrscht und wird dem Laufwerk übergeben. Das ist eigentlich ziemlich gute Idee, weil wenn man das Passwort auf dem Satabus abhören kann, kann man nur genau dieses Laufwerk entsperren. Und andere Laufwerke kann man damit nicht entsperren, weil die eben eine andere Seriennummer haben. Leider ist der Algorithmus etwas komplizierter. Also, der Passwort Herrsch benutzt die Scan Codes. Das heißt, da wird nichts zwischen Groß- und Kleinbuchstaben unterschieden. Und nach dem Herrsch werden wir etwas noch gekürzt. Also heißt man hat maximal 96 Bit Entropie in diesem Herrsch. Also, das ist ziemlich unglücklich. Wobei natürlich die meisten von Menschen gemachten Passwörtern weniger als 96 Bit Entropie haben. Also, das ist wahrscheinlich nicht so ein Problem. Dann hier wieder, bei diesem Teil vom Herrsch, wird er zusammengesetzt mit der Modellnummer. Und die Reihenfolge der Bits, dabei wird umgekehrt. Also, es ist mir nicht klar, wieso das gemacht hier wird. Aber es wird halt gemacht. Ich weise, ist es weil 16 Bit Nummern da reinkommen, aber dann irgendwie mit Bites umgegangen wird, ist mir nicht so ganz klar. Ja, also diesen Talk habe ich euch gezeigt, wie ihr auch UE4 Reverse einschienen könnt, mit diesen Tools hier. Und damit könnt ihr eben UE5-Module ausführen auf eurem Linux-System. Also, die Tools sind selbstverständlich unter GPR-Lizenz verfügbar auf GitHub. Und wenn ihr Main-Informations diesen Tools wollt, dann könnt ihr gerne auf meinen Blog lesen. Herzlichen Dank. Gut, dann gehen wir über zu den Fragen aus dem Publikum. Herzlichen Dank, dass du diese Tools bereitstellst. Ich habe schon ein ähnliches erlebt wie du, um solche Zeug zu lösen. Das gesagt, SMM ist nicht unterstützt und die Unterstützung in den Long-Mode ist auch nicht unterstützt. Ist das etwas, was du vielleicht noch entwickeln willst? Also, ich bin definitiv daran interessiert, aber ich bin schon ganz sicher, wie ich das machen soll. Insbesondere der Part mit dem Aufruf in den Systems Management Mode. Den geschützten Modus 16-bit-Long-Mode, das ist vielleicht möglich, auch die Übersetzung in den Long-Mode mag noch funktionieren, aber ansonsten weiß ich es nicht. Wenn mir jemand helfen will bei der Implementierung, bin ich natürlich sehr offen für eure Unterstützung und dankbar. Was ist der Vorteil von Wavey gegenüber Coreboot? Coreboot ist die Implementierung. Nein, stimmt, du hast recht, das ist nicht der Fall. Ich bin nicht ganz sicher, was der Vorteil ist, aber Wavey ist etwas, was auf meinem Laptop läuft. Hallo, danke für deinen Talk. Hast du andere Firma schon angeschaut, abgesehen von deinem Laptop? Ich selbst nicht, nein, aber ich weiß, dass andere Leute das getan haben. Herzlichen Dank für deinen Talk. Wie also rausgefunden, wie dieser Password-Hasch rauskommt mit dieser Kombination mit Seriennummer und Modellnummer? Die kompletten Details findet ihr auf meinem Blog, aber die Kurzfassung ist, es gibt ein Protokoll in EFI, um mit der Festbade zu reden, über das ATA-Support-Protokoll. Es gibt nur sehr wenige Module, die dieses Protokoll sprechen, und deswegen habe ich die mehr dis-assembliert und mir genauer angeschaut, was sie tun und was sie an die ATA-Festbade schicken. Also das Internet will wissen, ob du irgendwelche unerwarteten Bugs gefunden hast, und ob es jetzt möglich ist, Wavey zu prüfen mit Tools wie Valgrind zum Beispiel. Wir sind jetzt nicht wirklich irgendwelche anderen unerwarteten Bugs aufgefallen, aber ich habe auch nicht wirklich gezielt nach innen geschaut. Ich habe nur wenig Verständnis von Wavey, aber ich hatte die Idee, in Boothroms Reinshow schauen, um die von Grafikkarten zu extrahieren, von Grafikkarten, die auf Max laufen. Und ich habe mich gefragt, ja, diese Grafikkarten, da läuft eben halt im alten Bios, im Real-Modus, und ich wollte rausfingen, ob ich deinen Stubb schreiben kann, der dann von Wavey geladen wird, und dann mein Code dieses Graphics from Boothrom ausführt. Also dein Tool würde mir das helfen, das zu bauen, wenn mein Mac läuft, weil ja, das kann ich auch nicht, wenn der Mac am Buden ist. Ich weiß, es klingt wie ein sehr kompliziertes Setup. Es könnte sein, dass es möglich ist, eine Wavey-Module zu schreiben, das tut, was du gesagt hast, aber ich weiß nicht, ob es möglich ist, das auszuführen, während das Betriebssystem auch läuft. Daher bin ich nicht sicher, wir können uns gerne offline dann noch mehr über deine spezielle Situation unterhalten. Hast du ein serielles ICE, die überlegt, um das zu Ausführung von Wavey anschauen kann? Das ist im Prinzip QEMU, aber es leitet alle Hardware-Zugriffe weiter an echte Hardware. Also man kann damit im Prinzip das zurückverfolgen und das auf beliebiger echter Hardware ausführen. Ich habe mir das nicht näher angeschaut, aber es klingt auf jeden Fall ein sehr interessanter Ansatz. Vielen Dank. Ja, keine Maten fahren, herzlich...