Wi‑Fi vom ESP32 befreien [Video]

 (media.ccc.de)
1 Punkte von GN⁺ 2024-12-29 | 1 Kommentare | Auf WhatsApp teilen
  • Der ESP32 ist so verbreitet, dass vermutlich allein im CCH Tausende davon im Einsatz sind, doch der zentrale Wi‑Fi-Stack ist Closed Source und daher schwer zu modifizieren und zu auditieren.
  • Die 38c3-Session beginnt mit Reverse Engineering des Wi‑Fi-Peripheriegeräts und behandelt den Weg hin zu einem Open-Source-Wi‑Fi-Stack.
  • Das Ziel ist nicht nur eine einfache Ersatzimplementierung, sondern Software, die mit sensiblen Daten umgehen kann, selbst verifizieren und korrigieren zu können.
  • Wenn sich der neue Stack etabliert, könnte sich der ESP32 über einen gewöhnlichen IoT-SoC hinaus zu einer günstigen Wireless-Plattform für Forschung und Experimente entwickeln.
  • Wenn genügend Funktionen geöffnet sind, werden Anwendungen wie Pentesting-Tools, B.A.T.M.A.N.-Mesh-Router oder ein AirDrop-Client möglich.

Warum der Closed-Source-Wi‑Fi-Stack geöffnet werden soll

  • Der bestehende Wi‑Fi-Stack des ESP32 funktioniert, ist aber eine Closed-Source-Implementierung, weshalb sich seine internen Abläufe nur schwer prüfen oder an Anforderungen anpassen lassen.
  • Ein Open-Source-Wi‑Fi-Stack soll vor allem ermöglichen, einen Bereich, der potenziell sensible Daten verarbeitet, zu modifizieren und zu auditieren.
  • Dass es im CCH vermutlich Tausende von ESP32 gibt, die alle einen solchen Closed-Source-Wi‑Fi-Stack ausführen, verschärft das Problembewusstsein.

Vom Reverse Engineering zum neuen Stack

  • Das Projekt begann mit dem Reverse Engineering des proprietären Wi‑Fi-Stacks des ESP32.
  • Daraus entstand anschließend die Implementierung eines Open-Source-Wi‑Fi-Stacks, der die Wi‑Fi-Peripherie des ESP32 direkt anspricht.
  • Dabei werden zugleich Wi‑Fi, der ESP32, allgemeines Reverse Engineering und Herangehensweisen an Projekte dieser Art behandelt.

Einsatzmöglichkeiten, wenn der ESP32 geöffnet ist

  • Wenn seine Funktionen vollständig geöffnet sind, kann der ESP32 als Forschungswerkzeug und IoT-SoC vielfältigere Rollen übernehmen.
  • Mögliche Beispiele sind:
    • Pentesting-Tools
    • B.A.T.M.A.N.-Mesh-Router
    • AirDrop-Client

Session-Informationen und Freigabebedingungen

  • Die Vortragenden sind Frostie314159 und Jasper Devreker.
  • Es handelt sich um eine 38-minütige Session im Hardware-&-Making-Track der 38c3 in Saal 1, datiert auf den 2024-12-27.
  • Video und Audio werden in den Formaten MP4, WebM, MP3 und Opus bereitgestellt.
  • Das Material wird unter den Bedingungen von http://creativecommons.org/licenses/by/4.0 veröffentlicht.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-29
Meinungen auf Hacker News

  • Verwandter Beitrag: https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/

    • Wenn die Open-Source-Version mit der proprietären API kompatibel wäre, hätte das wohl große Vorteile.
      Bei Kompatibilität könnte man die im Internet bereits vorhandenen Hilfen und Beispiele unverändert nutzen, und die Einstiegshürde wäre niedriger. Auch wer nur eine winzige Änderung an der MAC-Schicht vornehmen möchte, könnte wie bisher einsteigen und nur den gewünschten Teil anfassen, ohne erst eine neue API lernen zu müssen.
    • Ich bin der Autor. Die ganze Artikelserie gibt es auch unter https://esp32-open-mac.be/.

  • Es ist immer noch ziemlich seltsam, dass offenbar nur Espressif es geschafft hat, ein WiFi-Modem in einen recht ordentlichen Mikrocontroller zu integrieren.
    ST hinkt in diesem Bereich weiterhin deutlich hinterher.

    • Weitere Beispiele sind die BK72xx-Reihe (BK7231T, BK7231N), die RTL87xx-Reihe (RTL8710BN, RTL8710BX) und der RP2040.
      Beim RP2040 W sieht das WiFi allerdings eher wie ein externes Modul aus. Quelle: https://esphome.io
    • Espressif hat die Kombination aus günstig, gut verfügbar, einfacher Hardware, einfacher Software und keinen seltsamen Lizenzbeschränkungen gut getroffen.
      Man kann die Teile überall einzeln kaufen; sie werden auf diversen Breakout-Boards mit USB-Stromversorgung, Programmierport und beschrifteten Pins verkauft; Dokumentation, Beispiele, Arduino IDE und NodeMCU sind ebenfalls gut verfügbar. Arduino war am Anfang ähnlich, blieb aber zu lange bei leistungsschwachen AVR-Chips; nicht-chinesische Boards waren teuer, und WiFi gab es auch nicht. Der Raspberry Pi Pico hat gute Funktionen, war anfangs aber schwer zu bekommen. Der Rest ist eher ein „Ein-Chip“-Kauf bei Anbietern wie DigiKey, mit hohen Versandkosten, über 600 Seiten Dokumentation, mehr als 300 Seiten nur, um den ersten Ping abzusetzen, Lötarbeit am Board und meist teurer Ausrüstung fürs Programmieren.
    • Nordic Semiconductor hat ebenfalls Mikrocontroller mit Bluetooth und WiFi. Sie sind allerdings deutlich weniger verbreitet als die Lösungen von Espressif.
    • Die meisten TuYa-basierten Module auf AliExpress sind Beken.
    • TI hat schon seit fast zehn Jahren WiFi+Bluetooth-Mikrocontroller und bietet auch Cortex-M4 an.

  • Ich habe das Video noch nicht gesehen, daher sorry, falls es dort schon behandelt wurde, aber ich frage mich, ob die Funkzulassung des ESP32 an die offizielle Blackbox-Firmware gebunden ist.
    Müsste man dieselbe Hardware mit offener Firmware erneut zu FCC und ähnlichen Zulassungsstellen schicken, um die Konformität prüfen zu lassen?

    • Wenn man sie so vertreibt, ja; wenn Endnutzer sie selbst ändern, nein.
      Den CFR-Abschnitt habe ich gerade nicht im Kopf, aber die FCC erlaubt ausdrücklich, dass jedermann kleine Stückzahlen nicht zugelassener Geräte verwenden darf. Wenn das Gerät gegen andere Vorschriften verstößt, ist das weiterhin ein Verstoß, aber allein die Tatsache, dass Hardware oder Software verändert wurde, ist nicht verboten.
    • Ich sehe das als Graubereich. Wenn ich nicht völlig danebenliege, wird bei der Zulassung nur die Funkleistung im Worst Case getestet und dokumentiert; der Rest der technischen Unterlagen ist eher eine ziemlich ausführliche Broschüre mit Blockdiagrammen auf hoher Ebene und Funktionsbeschreibung als moderne Designdokumentation wie PCB-Fertigungsdateien oder Firmware-Build-Skripte.
      Die Existenz der Firmware wird fast gar nicht anerkannt. Dafür gibt es auch einen Grund: Bei zertifizierten lizenzfreien Funkgeräten wie WiFi wird im öffentlichen Interesse erwartet, dass sie manipulationssicher sind. Als die FCC daher die Zulassungsanforderungen für WiFi-Router diskutierte, wurde erwogen, diese auf Software auszuweiten, etwa indem man Secure Boot für all die unsicheren Schrott-WiFi-Router vorschreibt. Das war eine schreckliche Idee und wurde verworfen. Stand heute würde ich sagen: Solange die resultierende Firmware nicht eindeutig Aussendungen außerhalb der Spezifikation erzeugt, ist es eher halb legal beziehungsweise halb illegal. Ich bin kein Jurist.
    • Stimmt.

  • https://github.com/esp32-open-mac

  • Ich hatte früher einmal eine Idee zur Provisionierung von WiFi-Passwörtern. Man kann SSID und Passwort übertragen, indem man die Paketlänge moduliert.
    Ein neues IoT-Gerät kann die Pakete natürlich nicht entschlüsseln, aber es kann die Länge beobachten. Ich hatte auch eine Beispielimplementierung für Linux gebaut, fand aber keinen einzigen IoT-Chip, der ausreichend Low-Level-PHY-Zugriff dafür bot.

    • TIs SmartConfig funktioniert genau so über das Längenfeld. Man kann also einen IoT-Chip verwenden, der das implementiert; TI bietet ziemlich viele solcher Chips an.
    • https://www.keacher.com/xmas24/ nutzt OOK für die Datenkommunikation und hat den Vorteil, Energie aus dem WiFi-Signal zu gewinnen, sodass keine Batterie nötig ist.
    • Könnte man als letzten Ausweg nicht Reverse Engineering betreiben, oder ist das unmöglich?
    • Heute würde ich einfach WPA3 verwenden.

  • Nebenfrage: Einer der Vortragenden hat eine DECT-Nummer veröffentlicht. Heißt das, dass es noch Leute gibt, die für Tech-Konferenzen alte Telefone mit sich herumtragen?

    • Während der Veranstaltung werden mehrere Netze für Sprachkommunikation betrieben. Soweit ich gesehen habe, werden üblicherweise DECT, SIP und GSM gemeinsam verwendet.
      Es gibt auch ein Status-Dashboard, das während der Veranstaltung Kennzahlen zeigt.
      [1] https://events.ccc.de/2024/12/22/38c3-poc-isdn-version/
      [2] https://dashboard.eventphone.de/d/de7sgxz63vzeoe/38c3?orgId=...
    • Ja. Auf Hacker-Camps ist das ziemlich praktisch, und ich habe selbst noch eins.
      Besonders auf dem Campinggelände kann die WiFi-Abdeckung uneinheitlich sein, sodass man auch dann Anrufe entgegennehmen kann, wenn man zum Sanitärgebäude oder zum Parkplatz läuft. Weil DECT eigene Frequenzen nutzt, macht es die von WiFi, Bluetooth und Zigbee genutzten Bänder auch nicht noch voller. Man könnte natürlich auch eine App verwenden, aber DECT ist sehr zuverlässig und hat eine deutlich bessere Reichweite als WiFi. Ich habe ein ordentliches Siemens-Gerät etwa in der Größe eines Nokia 8210, man muss also keinen Ziegelstein mit sich herumtragen. Der Akku ist inzwischen vermutlich fast tot, aber wie damals üblich ist er austauschbar.

  • In deutschen Privathaushalten ist DECT immer noch sehr beliebt
    Deutlich robuster als VoIP über WLAN

    • Ich sehe das als CCC-Tradition
    • Stimmt. Allerdings kann man auch GSM oder SIP verwenden, und selbst wenn tatsächlich ein modernes Netz genutzt wird, nennt man es wegen desselben Nummernraums oft DECT-Nummern
      Weil DECT zuerst da war, hat es sich quasi als Gattungsbegriff für interne Telefonnetze etabliert

  • Ich frage mich, wie tiefgehend der Hack wirklich ist. Das Senden von Frames sieht so aus, als würde man nur ein paar Register setzen und auf Interrupts warten; vielleicht kommuniziert man dabei mit einer anderen Firmware-Schicht, die die eigentliche Arbeit erledigt
    Das erinnert mich an das Raspberry-Pi-Pico-Board. Es gibt zwar den Haupt-SoC RP2040, aber WLAN läuft über ein separates WiFi/BT-Modul (CYW43xx) mit eigenem Arm-Core. Auch die externe Register-Schnittstelle des WiFi-Moduls ist nicht öffentlich dokumentiert, aber es gibt einen Open-Source-Treiber (https://github.com/georgerobotics/cyw43-driver/tree/cf924bb0...), aus dem sich die Spezifikation ableiten lässt. Doch auch dieser Treiber kommuniziert letztlich mit Software, die auf dem Arm-Core im Modul läuft, und diesen Code liefert der Hersteller als riesigen Firmware-Binary-Blob. Dieser Blob steckt tatsächlich in den Header-Dateien im firmware-Verzeichnis des verlinkten Repositories. Ich frage mich, wie dieser ESP32-Hack zu dieser Architektur passt

  • Ich fand beeindruckend, wie jung die Vortragenden wirklich wirkten. Es ist interessant zu sehen, wie man sich in so jungen Jahren ein solches Maß an technischem Wissen aneignet

    • Heutzutage ist alles offen zugänglich. Kinder können immer früher lernen, was sie wollen
      Schach ist ein perfektes Beispiel. Früher steckte viel Wissen in Büchern, oft in fremdsprachigen. Heute ist alles öffentlich zugänglich, und ab einem gewissen Niveau kann man ganz unkompliziert auch gegen Gegner aus den Top 100 spielen, wodurch man schneller wächst

  • Ein Schritt näher an einer MicroPython-Bibliothek mit Unterstützung für den Promiscuous Mode

    • Warum? Das wird doch bereits vom ESP SDK unterstützt

  • Ohne Download ansehen: https://media.ccc.de/v/38c3-liberating-wi-fi-on-the-esp32/pl...