Die enthüllte Kommunikation: Reverse Engineering des Sendeverhaltens beim ESP32 – TechnoDidact

Vom passiven Lauscher zum aktiven Verstehen – wie man IoT-Geräten auf die Spur kommt

Einleitung: Die Sprache der Dinge

In einer Welt, in der vernetzte Geräte längst unseren Alltag durchdringen, bleibt ihre eigentliche Kommunikation für die meisten Menschen unsichtbar. Smart-Home-Sensoren senden Temperaturdaten, Überwachungskameras übertragen Videoströme, und Türschlösser warten auf Öffnungsbefehle – all das geschieht in elektromagnetischen Wellen, die uns umgeben, ohne dass wir sie wahrnehmen könnten.

Doch was, wenn wir diese Kommunikation sichtbar machen wollen? Was, wenn wir verstehen möchten, welche Daten ein Gerät wirklich preisgibt, ob es mehr sendet als nötig, oder ob es heimlich mit unbekannten Servern kommuniziert? Dann betreten wir die faszinierende Welt des Reverse Engineering von Sendeverhalten – eine Disziplin, die Detektivarbeit, Elektrotechnik und Datenanalyse vereint.

Der ESP32, jener unscheinbare Mikrocontroller für wenige Euro, der in einer Milliarde Geräten steckt , eignet sich dafür nicht nur als Untersuchungsobjekt, sondern auch als perfektes Werkzeug. Denn er kann beides: senden und empfangen – und im richtigen Modus sogar all das belauschen, was um ihn herum geschieht.

Dieser Artikel taucht tief ein in die Methoden, Werkzeuge und Erkenntnisse, die das Analysieren des Sendeverhaltens von ESP32-Geräten ermöglicht. Von der Aktivierung des Lauschmodus über die Extraktion einzelner Pakete bis hin zur vollständigen Rekonstruktion von Kommunikationsprotokollen – und den überraschenden Entdeckungen, die dabei zutage treten können.

I. Die Grundlage: Promiscuous Mode und Monitor Mode

Vom braven Empfänger zum neugierigen Lauscher

Im Normalbetrieb verhält sich jedes WiFi-Gerät wie ein wohlerzogener Gesprächsteilnehmer: Es hört nur zu, wenn es direkt angesprochen wird. Alle Pakete, die nicht an die eigene MAC-Adresse gerichtet sind, werden ignoriert. Das ist effizient, aber für Analysezwecke unbrauchbar.

Die Lösung heißt Promiscuous Mode (auch Monitor Mode). In diesem Betriebsmodus wirft der Chip seine Höflichkeit über Bord und empfängt jedes Datenpaket, das auf dem eingestellten Kanal gesendet wird – unabhängig vom Empfänger .

Die Aktivierung ist beim ESP32 denkbar einfach. Im offiziellen Entwicklungsumfeld ESP-IDF genügt eine einzige Codezeile:

esp_wifi_set_promiscuous(true);

Damit verwandelt sich der Chip in einen passiven Lauscher, der die gesamte drahtlose Kommunikation in seiner Reichweite mitschneiden kann .

Die technische Umsetzung: Pakete einfangen

Doch der bloße Empfang reicht nicht – die Pakete müssen auch erfasst und verarbeitet werden. Dafür implementiert man eine sogenannte Callback-Funktion:

void sniffer_callback(void *buf, wifi_promiscuous_pkt_type_t type) {
    wifi_promiscuous_pkt_t *pkt = (wifi_promiscuous_pkt_t*)buf;
    uint32_t paketlaenge = pkt->rx_ctrl.sig_len;
    uint8_t *nutzdaten = pkt->payload;
    // Hier können die Daten weiterverarbeitet werden
}

Diese Funktion wird bei jedem empfangenen Paket automatisch aufgerufen und erhält einen Zeiger auf die rohen Paketdaten .

Die Herausforderung: Hardware-Filter umgehen

Eine häufige Fehlerquelle bei ersten Experimenten sind die hardware-seitigen MAC-Filter des ESP32. Selbst wenn der Promiscuous Mode aktiviert ist, filtern diese Filter standardmäßig alle Pakete heraus, die nicht an die eigene MAC-Adresse gerichtet sind. Sie müssen explizit deaktiviert werden:

wifi_promiscuous_filter_t filter = {
    .filter_mask = WIFI_PROMIS_FILTER_MASK_ALL
};
esp_wifi_set_promiscuous_filter(&filter);

Erst dann sieht der Chip wirklich alles .

II. Vom Chip zum Computer: Pakete exportieren

Die Rechenleistung eines ESP32 reicht zwar zum Empfangen, aber für eine tiefgehende Analyse ist ein leistungsfähiger Computer unerlässlich. Die typische Architektur sieht daher so aus:

ESP32 fängt Pakete im Promiscuous Mode
Übertragung per UART/Serial, USB CDC oder Ethernet an einen PC
Speicherung im standardisierten PCAP-Format
Analyse mit spezialisierten Tools wie Wireshark

Das PCAP-Format: Der Industriestandard

Das PCAP-Format (Packet Capture) ist das universelle Austauschformat für Netzwerk-Mitschnitte. Es speichert jedes Paket mit einem Zeitstempel und den rohen Byte-Daten – genau das, was der ESP32 liefert. Tools wie Wireshark, tcpdump oder TShark können diese Dateien öffnen und decodieren .

Auf dem ESP32-Seite gibt es fertige Bibliotheken, die das Erstellen von PCAP-Dateien erleichtern. Einige Projekte übertragen die Pakete direkt per UDP an einen PC, wo sie mit einem einfellen Empfänger-Skript entgegengenommen werden .

III. Die Analyse: Wireshark als Fenster in die drahtlose Welt

Wireshark ist das Schweizer Taschenmesser der Netzwerkanalyse. Es kann hunderte Protokolle decodieren, Verbindungen rekonstruieren und selbst in riesigen Datenmengen die Nadel im Heuhaufen finden.

Was Wireshark aus einem einzelnen Paket herausholt

Ein typisches, vom ESP32 empfangenes WiFi-Paket wird von Wireshark in seine Schichten zerlegt – und plötzlich wird aus einem undurchschaubaren Byte-Haufen eine lesbare Struktur:

text

Frame 42: 128 Bytes on wire
├── IEEE 802.11 (MAC-Ebene)
│   ├── Frame Control: 0x0802 (Data, QoS Data)
│   │   ├── Version: 0
│   │   ├── Type: Data (2)
│   │   ├── Subtype: QoS Data (8)
│   │   └── Flags: 0x01 (Nach unten gerichtet)
│   ├── Dauer: 44 Mikrosekunden
│   ├── Adresse 1 (Empfänger): aa:bb:cc:dd:ee:ff
│   ├── Adresse 2 (Sender): 11:22:33:44:55:66
│   ├── Adresse 3 (BSSID): 00:11:22:33:44:55
│   └── Sequenznummer: 1234
├── LLC (Logical Link Control)
│   ├── DSAP: 0xaa (SNAP)
│   └── Control: 0x03 (Unnumbered Information)
├── IPv4
│   ├── Version: 4
│   ├── Quell-IP: 192.168.1.5
│   └── Ziel-IP: 192.168.1.100
├── UDP
│   ├── Quellport: 45678
│   └── Zielport: 1883
└── MQTT (Message Queuing Telemetry Transport)
    ├── Befehl: PUBLISH (3)
    ├── Topic-Länge: 24
    ├── Topic: "haus/wohnzimmer/temperatur"
    └── Payload: "22.5 °C"

Diese hierarchische Darstellung ist nicht nur übersichtlich, sondern ermöglicht gezielte Filterungen und Analysen .

Gezielte Suche: Filter in Wireshark

Die eigentliche Stärke von Wireshark liegt in der Filter-Sprache. Sie können damit präzise die Pakete herausfischen, die Sie interessieren:

wlan.fc.type == 0 – Alle Management-Frames (Verbindungsaufbau, Beacon-Frames)
wlan.fc.type == 2 – Alle Daten-Frames (die eigentlichen Nutzdaten)
mqtt – Alle MQTT-Nachrichten
ip.src == 192.168.1.5 – Alle Pakete von einer bestimmten IP
udp.port == 53 – DNS-Anfragen
http.request.method == "GET" – HTTP-GET-Anfragen

Diese Filter lassen sich beliebig kombinieren, etwa: mqtt && ip.src == 192.168.1.5 – alle MQTT-Nachrichten von einem bestimmten Gerät .

Kommunikationsabläufe rekonstruieren

Wireshark kann mehr als nur Einzelpakete anzeigen. Es kann komplette Gespräche (Conversations) rekonstruieren. Für eine MQTT-Session etwa sehen Sie:

Verbindungsaufbau: Der Client sendet ein CONNECT-Paket
Bestätigung: Der Broker antwortet mit CONNACK
Datenübertragung: Der Client sendet periodisch PUBLISH-Nachrichten
Keep-Alive: Regelmäßige PINGREQ/PINGRESP-Pakete
Verbindungsabbau: DISCONNECT

Das ist besonders wertvoll, um das typische Verhalten eines Geräts zu verstehen: Sendet es alle 30 Sekunden Daten? Gibt es unregelmäßige Spitzen? Sendet es beim Einschalten andere Daten als im Normalbetrieb?

IV. Was man alles analysieren kann: Die Dimensionen des Sendeverhaltens

Die Analyse des Sendeverhaltens ist weit mehr als nur das Mitschneiden einiger Pakete. Sie erlaubt Einblicke in praktisch alle Aspekte der Gerätekommunikation.

1. Verbindungsaufbau und Authentifizierung

Schon beim Einschalten eines Geräts verrät es viel über sich. Die Probe Requests – Anfragen, mit denen ein Client nach bekannten Netzwerken sucht – enthalten oft die Namen der Netzwerke, mit denen das Gerät bereits verbunden war. Das ist nicht nur datenschutzrechtlich brisant, sondern verrät auch, in welcher Umgebung das Gerät typischerweise eingesetzt wird .

Der gesamte 4-Wege-Handshake bei WPA2-Verschlüsselung lässt sich mitschneiden. Zwar sind die Daten selbst verschlüsselt, aber die Tatsache, dass ein Handshake stattfindet, und die beteiligten MAC-Adressen sind sichtbar .

2. Periodizität und Timing

Viele IoT-Geräte senden in regelmäßigen Abständen Daten. Ein Temperatursensor vielleicht alle 5 Minuten, ein Präsenzmelder bei jeder Bewegung. Diese Periodizität lässt sich aus den Mitschnitten exakt bestimmen:

Durchschnittliches Sendeintervall: 29,8 Sekunden
Abweichungen: ±0,5 Sekunden
Besonderheiten: Nach einem Reset sofortige Sendung, dann regelmäßig

Solche Timing-Analysen können versteckte Verhaltensweisen aufdecken: Sendet ein Gerät wirklich nur bei Bewegung, oder gibt es auch „Herzschlag“-Pakete im Leerlauf? .

3. Verwendete Protokolle

Die Protokollanalyse verrät, auf welcher technischen Basis ein Gerät kommuniziert:

MQTT (Message Queuing Telemetry Transport): Sehr verbreitet im IoT-Bereich, erkennbar an Port 1883 oder 8883 (verschlüsselt)
HTTP/HTTPS: Ältere Geräte oder solche mit Web-Interface
CoAP (Constrained Application Protocol): Speziell für ressourcenbeschränkte Geräte
Proprietäre Protokolle: Manchmal auf UDP-Basis, oft auf den ersten Blick unverständlich

Besonders spannend sind verschlüsselte Verbindungen. Hier sieht man zwar nicht den Inhalt, aber oft genug Metadaten: An welche IP wird verschlüsselt? Welches Zertifikat wird verwendet? Weicht das Zertifikat von der Herstellerangabe ab? .

4. Signalstärke und physische Lokalisierung

Jedes empfangene Paket enthält Informationen über die Empfangsfeldstärke (RSSI – Received Signal Strength Indicator) . Damit lässt sich nicht nur die Entfernung zum Sender abschätzen, sondern bei mehreren Empfängern sogar eine grobe Ortung durchführen.

In der Praxis bedeutet das: Sie können feststellen, ob ein Gerät sich bewegt (etwa ein tracker) oder stationär ist.

5. Versteckte Kommunikation

Der wohl brisanteste Aspekt: Entdeckt man Kommunikation, die nicht zur erwarteten Funktion gehört? Sendet ein smarter Lautsprecher heimlich an Server in Ländern mit fragwürdigen Datenschutzgesetzen? Ruft ein Fernseher regelmäßig Werbe-Server auf, auch wenn er „aus“ ist?

Solche Entdeckungen gab es in der Vergangenheit mehrfach. Die Analyse des Sendeverhaltens ist oft der einzige Weg, solche heimlichen Datenströme aufzudecken .

V. Fortgeschrittene Anwendungen: Vom passiven Lauschen zum aktiven Verstehen

Fallstudie 1: Reverse Engineering des MAC-Layers

Das ehrgeizige ESP32-Open-MAC-Projekt hat gezeigt, wie tief die Analyse des Sendeverhaltens gehen kann. Die Forscher wollten nicht nur verstehen, was gesendet wird, sondern wie der Chip es technisch umsetzt. Dafür haben sie:

Die Kommunikation zwischen dem Hauptprozessor und dem WiFi-Peripheriegerät belauscht
Aus den beobachteten Befehlen die zugrundeliegende Firmware-Logik rekonstruiert
Einen eigenen, quelloffenen MAC-Treiber entwickelt, der die Hardware direkt ansteuert

Das ist die Königsklasse des Reverse Engineering: nicht nur zu sehen, was passiert, sondern zu verstehen, warum und wie es passiert.

Fallstudie 2: Energieverbrauchsanalyse durch Sendeverhalten

An der Technischen Universität Berlin und der Saarland University verfolgte ein Forscherteam ein anderes Ziel. Sie wollten den Energieverbrauch von WiFi-Übertragungen vorhersagen können – essentiell für batterielose Geräte, die ihre Energie aus Umgebung gewinnen (Solar, Vibration, Radiofrequenzen) .

Dazu analysierten sie das Sendeverhalten des ESP32-C3 (der RISC-V-Variante) im Detail. Sie fanden heraus:

Wie lange dauert eine Übertragung tatsächlich? (Nicht nur die reine Sendezeit, sondern auch Aufwachzeit, Synchronisation, Aushandeln der Datenrate)
Welche Befehlssequenzen durchläuft der Chip bei verschiedenen Übertragungsarten?
Wie hoch ist der maximale Energieverbrauch im ungünstigsten Fall?

Die Ergebnisse flossen in ein Modell für statische Worst-Case-Analyse des Energieverbrauchs (WCEC) ein – Grundlagenforschung auf Basis von Reverse Engineering .

Fallstudie 3: Die Entdeckung versteckter Bluetooth-Befehle

Im März 2025 sorgte die Sicherheitsfirma Tarlogic für Schlagzeilen. Sie hatte bei der Analyse der Bluetooth-Implementierung des ESP32 29 undokumentierte Befehle entdeckt, die tiefe Eingriffe in den Speicher erlaubten .

Die ersten Meldungen sprachen von einer „Backdoor“, doch die Realität war differenzierter. Es handelte sich um Debug-Befehle, die für Entwicklungszwecke im Chip verblieben waren. Sie sind nicht remote auslösbar – ein Angreifer müsste bereits physischen Zugriff und privilegierte Rechte haben, um sie nutzen zu können .

Dennoch zeigt der Fall: Selbst in einem der meistverbauten Chips der Welt schlummern Fähigkeiten, von denen niemand weiß – bis jemand genau hinsieht und das Sendeverhalten analysiert.

VI. Praktische Herausforderungen und Lösungen

Kanal-Hopping: Das Problem der verteilten Kommunikation

WiFi-Geräte senden nicht auf einem einzigen Kanal, sondern wechseln je nach Netzwerkbedingungen. Ein einzelner ESP32 kann immer nur auf einem Kanal gleichzeitig lauschen. Wenn Sie die gesamte Kommunikation eines Geräts erfassen wollen, müssen Sie regelmäßig den Kanal wechseln – und riskieren dabei, Pakete auf anderen Kanälen zu verpassen.

Typische Implementierungen springen alle 200–300 Millisekunden zum nächsten Kanal . Das ist ein Kompromiss: Sie sehen alles, aber nicht alles gleichzeitig.

Eine professionelle Lösung sind mehrere ESP32, die synchronisiert auf verschiedenen Kanälen lauschen. Für Hobby-Zwecke reicht oft das Kanal-Hopping aus.

ACK-Timing: Wenn die Hardware zu langsam ist

Wenn Sie nicht nur passiv lauschen, sondern aktiv kommunizieren wollen (etwa um auf Probe Requests zu antworten), stoßen Sie an eine Grenze: ACK-Bestätigungen müssen innerhalb von 10 Mikrosekunden bei 802.11b gesendet werden. Das ist in Software unmöglich – hier muss die Hardware so konfiguriert werden, dass sie automatisch ACKs sendet .

MAC-Adressen korrekt setzen

Bei eigenen Experimenten mit aktivem Senden ist die Wahl der MAC-Adresse wichtig. Das erste Byte darf nicht mit 01 beginnen, da dies Multicast-Adressen kennzeichnet. Mit einer ungültigen MAC-Adresse antwortet kein Access Point auf Ihre Anfragen .

Datenmengen bewältigen

Im Promiscuous Mode kann ein ESP32 in dichten Umgebungen tausende Pakete pro Sekunde empfangen. Die Übertragung per serieller Schnittstelle wird schnell zum Flaschenhals. Hier hilft:

Reduktion auf relevante Pakete bereits auf dem ESP32 (etwa nur Pakete eines bestimmten Typs)
Puffern und gebündelte Übertragung
Verwendung von USB-CDC für höhere Übertragungsraten

VII. Ethische und rechtliche Dimension

Die Fähigkeit, drahtlose Kommunikation zu belauschen, ist ein mächtiges Werkzeug – und wie alle mächtigen Werkzeuge birgt es Missbrauchspotenzial.

Was ist erlaubt?

Die klare Regel: Nur Geräte analysieren, die einem selbst gehören oder für die man eine ausdrückliche Erlaubnis hat . Das Abhören fremder Kommunikation ist in den meisten Ländern strafbar, selbst wenn sie „nur“ über WLAN läuft.

Für Forschungszwecke gibt es Ausnahmen, aber auch hier gilt: Die Ergebnisse sollten so veröffentlicht werden, dass sie keine konkreten Angriffe ermöglichen. Die Entdecker der versteckten Bluetooth-Befehle etwa kommunizierten verantwortungsvoll mit dem Hersteller, bevor sie an die Öffentlichkeit gingen .

Verantwortung der Forscher

Reverse Engineering ist keine destruktive Disziplin. Im besten Fall deckt es Sicherheitslücken auf, bevor Angreifer sie ausnutzen können. Es zwingt Hersteller zu mehr Transparenz und hilft Verbrauchern, informierte Entscheidungen zu treffen.

Die ESP32-Community hat hier eine bemerkenswerte Kultur entwickelt: Espressif selbst steht Reverse Engineering für Forschungszwecke offen gegenüber und kooperiert mit Forschern .

VIII. Zukunftsperspektiven: Wohin entwickelt sich die Analyse?

Automatisierung durch KI

Die manuelle Analyse von Paket-Mitschnitten ist aufwendig. Erste Ansätze nutzen maschinelles Lernen, um automatisch Auffälligkeiten im Sendeverhalten zu erkennen:

Abweichungen vom normalen Kommunikationsmuster
Ungewöhnliche Ziel-IPs
Verdächtige Periodizitäten

Diese Werkzeuge stecken noch in den Kinderschuhen, aber die Entwicklung schreitet schnell voran.

Verschlüsselung als Herausforderung

Die zunehmende Verschlüsselung erschwert die Analyse. Während Metadaten oft sichtbar bleiben, sind die Nutzdaten immer häufiger unlesbar. Hier könnten Hardware-Angriffe (etwa das Auslesen von Schlüsseln aus dem Speicher) oder Seitenkanal-Analysen an Bedeutung gewinnen.

Integration in Sicherheitsforschung

Die Methoden der Sendeverhaltens-Analyse wandern zunehmend in standardisierte Sicherheitsbewertungen. Tarlogic etwa hat mit der Bluetooth Security Assessment Methodology (BSAM) einen strukturierten Ansatz vorgelegt, der auch die Analyse des Sendeverhaltens umfasst .

Fazit: Die unsichtbare Sprache verstehen lernen

Das Reverse Engineering des Sendeverhaltens beim ESP32 ist mehr als eine technische Spielerei. Es ist ein Werkzeug der Aufklärung in einer Welt, die zunehmend von unsichtbarer Kommunikation durchdrungen ist.

Wer versteht, was seine Geräte wirklich senden, kann:

Sicherheitslücken entdecken, bevor Angreifer sie ausnutzen
Datenschutzverletzungen aufdecken, wenn Geräte mehr preisgeben als nötig
Energieverbrauch optimieren, indem man unnötige Kommunikation erkennt
Hersteller zu mehr Transparenz zwingen

Die technischen Hürden sind überwindbar. Ein ESP32 für wenige Euro, etwas Code und Wireshark als Analysesoftware – mehr braucht es nicht, um in die verborgene Welt der drahtlosen Kommunikation einzutauchen.

Und manchmal, wenn man genau hinhört, entdeckt man Dinge, die niemand erwartet hat: 29 versteckte Befehle in einem alltäglichen Chip oder heimliche Datenströme zu Servern in fernen Ländern.

Die Geräte sprechen – man muss nur lernen, ihnen zuzuhören.

Quellen

Espressif Systems: „ESP-IDF Programming Guide – Wi-Fi Driver“, Version 5.4, März 2026. https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi.html
Tarlogic Security: „Function Identification in ESP32 Firmware Using Ghidra FIDB“, Dezember 2025. https://www.tarlogic.com/blog/esp32-firmware-using-ghidra-fidb/
Mudraje, I. et al.: „Reverse Engineering the ESP32-C3 Wi-Fi Drivers for Static Worst-Case Analysis of Intermittently-Powered Systems“, arXiv:2501.17684, Januar 2025. https://arxiv.org/html/2501.17684v3
Technische Universität Berlin: „Literature Database Entry – mudraje2025reverse“, Januar 2026. https://www.tkn.tu-berlin.de/bib/mudraje2025reverse/
Tarlogic Security: „Bluetooth Security Assessment Methodology (BSAM)“, Februar 2026. https://www.tarlogic.com/bsam/
van Beijnum, W.: „Breaking and Remaking ESP32 Devices: A Practical Guide to Reverse Engineering and Patching“, OrangeCon 2025. https://pretalx.com/orangecon-2025/talk/WFUSHE/
Kimasplund: „ESP32 Universal Firmware Extractor“, GitHub Repository, September 2025. https://github.com/kimasplund/esp32_universal_extractor
ESP32-Open-MAC: „Open Source MAC Layer for ESP32“, GitHub Repository, laufend aktualisiert. https://github.com/esp32-open-mac/esp32-open-mac
Wireshark Foundation: „Wireshark User’s Guide“, Version 4.4, 2026. https://www.wireshark.org/docs/wsug_html/
Staudacher, M.: „Sicherheitslücke in ESP32-Chip ermöglicht Schadcode-Infektionen in IoT-Geräten“, elektronikpraxis, März 2025. https://www.elektronikpraxis.de/sicherheitsluecke-esp32-chip-iot-geraete-a-bf9542f5cf37776ab9be7a5a46f60de6/
ESPBoards: „esptool.py Guide: Install, Flash, Erase & Backup ESP32 Firmware“, Februar 2025. https://www.espboards.dev/blog/standalone-esptool-basics/

neustes