Vom passiven Lauscher zum aktiven Verstehen \u2013 wie man IoT-Ger\u00e4ten auf die Spur kommt<\/p>\n\n\n\n
In einer Welt, in der vernetzte Ger\u00e4te l\u00e4ngst unseren Alltag durchdringen, bleibt ihre eigentliche Kommunikation f\u00fcr die meisten Menschen unsichtbar. Smart-Home-Sensoren senden Temperaturdaten, \u00dcberwachungskameras \u00fcbertragen Videostr\u00f6me, und T\u00fcrschl\u00f6sser warten auf \u00d6ffnungsbefehle \u2013 all das geschieht in elektromagnetischen Wellen, die uns umgeben, ohne dass wir sie wahrnehmen k\u00f6nnten.<\/p>\n\n\n\n
Doch was, wenn wir diese Kommunikation sichtbar machen wollen? Was, wenn wir verstehen m\u00f6chten, welche Daten ein Ger\u00e4t wirklich preisgibt, ob es mehr sendet als n\u00f6tig, oder ob es heimlich mit unbekannten Servern kommuniziert? Dann betreten wir die faszinierende Welt des Reverse Engineering von Sendeverhalten \u2013 eine Disziplin, die Detektivarbeit, Elektrotechnik und Datenanalyse vereint.<\/p>\n\n\n\n
Der ESP32, jener unscheinbare Mikrocontroller f\u00fcr wenige Euro, der in einer Milliarde Ger\u00e4ten steckt , eignet sich daf\u00fcr nicht nur als Untersuchungsobjekt, sondern auch als perfektes Werkzeug. Denn er kann beides: senden und empfangen \u2013 und im richtigen Modus sogar all das belauschen, was um ihn herum geschieht.<\/p>\n\n\n\n
Dieser Artikel taucht tief ein in die Methoden, Werkzeuge und Erkenntnisse, die das Analysieren des Sendeverhaltens von ESP32-Ger\u00e4ten erm\u00f6glicht. Von der Aktivierung des Lauschmodus \u00fcber die Extraktion einzelner Pakete bis hin zur vollst\u00e4ndigen Rekonstruktion von Kommunikationsprotokollen \u2013 und den \u00fcberraschenden Entdeckungen, die dabei zutage treten k\u00f6nnen.<\/p>\n\n\n\n
Im Normalbetrieb verh\u00e4lt sich jedes WiFi-Ger\u00e4t wie ein wohlerzogener Gespr\u00e4chsteilnehmer: Es h\u00f6rt 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\u00fcr Analysezwecke unbrauchbar.<\/p>\n\n\n\n
Die L\u00f6sung hei\u00dft Promiscuous Mode<\/strong> (auch Monitor Mode). In diesem Betriebsmodus wirft der Chip seine H\u00f6flichkeit \u00fcber Bord und empf\u00e4ngt jedes Datenpaket<\/strong>, das auf dem eingestellten Kanal gesendet wird \u2013 unabh\u00e4ngig vom Empf\u00e4nger .<\/p>\n\n\n\n Die Aktivierung ist beim ESP32 denkbar einfach. Im offiziellen Entwicklungsumfeld ESP-IDF gen\u00fcgt eine einzige Codezeile:<\/p>\n\n\n\n c<\/p>\n\n\n\n Damit verwandelt sich der Chip in einen passiven Lauscher, der die gesamte drahtlose Kommunikation in seiner Reichweite mitschneiden kann .<\/p>\n\n\n\n Doch der blo\u00dfe Empfang reicht nicht \u2013 die Pakete m\u00fcssen auch erfasst und verarbeitet werden. Daf\u00fcr implementiert man eine sogenannte Callback-Funktion:<\/p>\n\n\n\n c<\/p>\n\n\n\n Diese Funktion wird bei jedem empfangenen Paket automatisch aufgerufen und erh\u00e4lt einen Zeiger auf die rohen Paketdaten .<\/p>\n\n\n\n Eine h\u00e4ufige Fehlerquelle bei ersten Experimenten sind die hardware-seitigen MAC-Filter des ESP32. Selbst wenn der Promiscuous Mode aktiviert ist, filtern diese Filter standardm\u00e4\u00dfig alle Pakete heraus, die nicht an die eigene MAC-Adresse gerichtet sind. Sie m\u00fcssen explizit deaktiviert werden:<\/p>\n\n\n\n c<\/p>\n\n\n\n Erst dann sieht der Chip wirklich alles .<\/p>\n\n\n\n Die Rechenleistung eines ESP32 reicht zwar zum Empfangen, aber f\u00fcr eine tiefgehende Analyse ist ein leistungsf\u00e4higer Computer unerl\u00e4sslich. Die typische Architektur sieht daher so aus:<\/p>\n\n\n\n Das PCAP-Format<\/strong> (Packet Capture) ist das universelle Austauschformat f\u00fcr Netzwerk-Mitschnitte. Es speichert jedes Paket mit einem Zeitstempel und den rohen Byte-Daten \u2013 genau das, was der ESP32 liefert. Tools wie Wireshark, tcpdump oder TShark k\u00f6nnen diese Dateien \u00f6ffnen und decodieren .<\/p>\n\n\n\n Auf dem ESP32-Seite gibt es fertige Bibliotheken, die das Erstellen von PCAP-Dateien erleichtern. Einige Projekte \u00fcbertragen die Pakete direkt per UDP an einen PC, wo sie mit einem einfellen Empf\u00e4nger-Skript entgegengenommen werden .<\/p>\n\n\n\n Wireshark<\/strong> ist das Schweizer Taschenmesser der Netzwerkanalyse. Es kann hunderte Protokolle decodieren, Verbindungen rekonstruieren und selbst in riesigen Datenmengen die Nadel im Heuhaufen finden.<\/p>\n\n\n\n Ein typisches, vom ESP32 empfangenes WiFi-Paket wird von Wireshark in seine Schichten zerlegt \u2013 und pl\u00f6tzlich wird aus einem undurchschaubaren Byte-Haufen eine lesbare Struktur:<\/p>\n\n\n\n text<\/p>\n\n\n\n Diese hierarchische Darstellung ist nicht nur \u00fcbersichtlich, sondern erm\u00f6glicht gezielte Filterungen und Analysen .<\/p>\n\n\n\n Die eigentliche St\u00e4rke von Wireshark liegt in der Filter-Sprache. Sie k\u00f6nnen damit pr\u00e4zise die Pakete herausfischen, die Sie interessieren:<\/p>\n\n\n\n Diese Filter lassen sich beliebig kombinieren, etwa: Wireshark kann mehr als nur Einzelpakete anzeigen. Es kann komplette Gespr\u00e4che (Conversations)<\/strong> rekonstruieren. F\u00fcr eine MQTT-Session etwa sehen Sie:<\/p>\n\n\n\n Das ist besonders wertvoll, um das typische Verhalten eines Ger\u00e4ts<\/strong> zu verstehen: Sendet es alle 30 Sekunden Daten? Gibt es unregelm\u00e4\u00dfige Spitzen? Sendet es beim Einschalten andere Daten als im Normalbetrieb?<\/p>\n\n\n\n Die Analyse des Sendeverhaltens ist weit mehr als nur das Mitschneiden einiger Pakete. Sie erlaubt Einblicke in praktisch alle Aspekte der Ger\u00e4tekommunikation.<\/p>\n\n\n\n Schon beim Einschalten eines Ger\u00e4ts verr\u00e4t es viel \u00fcber sich. Die Probe Requests<\/strong> \u2013 Anfragen, mit denen ein Client nach bekannten Netzwerken sucht \u2013 enthalten oft die Namen der Netzwerke, mit denen das Ger\u00e4t bereits verbunden war. Das ist nicht nur datenschutzrechtlich brisant, sondern verr\u00e4t auch, in welcher Umgebung das Ger\u00e4t typischerweise eingesetzt wird .<\/p>\n\n\n\n Der gesamte 4-Wege-Handshake<\/strong> bei WPA2-Verschl\u00fcsselung l\u00e4sst sich mitschneiden. Zwar sind die Daten selbst verschl\u00fcsselt, aber die Tatsache, dass ein Handshake stattfindet, und die beteiligten MAC-Adressen sind sichtbar .<\/p>\n\n\n\n Viele IoT-Ger\u00e4te senden in regelm\u00e4\u00dfigen Abst\u00e4nden Daten. Ein Temperatursensor vielleicht alle 5 Minuten, ein Pr\u00e4senzmelder bei jeder Bewegung. Diese Periodizit\u00e4t l\u00e4sst sich aus den Mitschnitten exakt bestimmen:<\/p>\n\n\n\n Solche Timing-Analysen k\u00f6nnen versteckte Verhaltensweisen aufdecken: Sendet ein Ger\u00e4t wirklich nur bei Bewegung, oder gibt es auch „Herzschlag“-Pakete im Leerlauf? .<\/p>\n\n\n\n Die Protokollanalyse verr\u00e4t, auf welcher technischen Basis ein Ger\u00e4t kommuniziert:<\/p>\n\n\n\n Besonders spannend sind verschl\u00fcsselte Verbindungen<\/strong>. Hier sieht man zwar nicht den Inhalt, aber oft genug Metadaten: An welche IP wird verschl\u00fcsselt? Welches Zertifikat wird verwendet? Weicht das Zertifikat von der Herstellerangabe ab? .<\/p>\n\n\n\n Jedes empfangene Paket enth\u00e4lt Informationen \u00fcber die Empfangsfeldst\u00e4rke (RSSI \u2013 Received Signal Strength Indicator)<\/strong> . Damit l\u00e4sst sich nicht nur die Entfernung zum Sender absch\u00e4tzen, sondern bei mehreren Empf\u00e4ngern sogar eine grobe Ortung durchf\u00fchren.<\/p>\n\n\n\n In der Praxis bedeutet das: Sie k\u00f6nnen feststellen, ob ein Ger\u00e4t sich bewegt (etwa ein tracker) oder station\u00e4r ist.<\/p>\n\n\n\n Der wohl brisanteste Aspekt: Entdeckt man Kommunikation, die nicht zur erwarteten Funktion geh\u00f6rt? Sendet ein smarter Lautsprecher heimlich an Server in L\u00e4ndern mit fragw\u00fcrdigen Datenschutzgesetzen? Ruft ein Fernseher regelm\u00e4\u00dfig Werbe-Server auf, auch wenn er „aus“ ist?<\/p>\n\n\n\n Solche Entdeckungen gab es in der Vergangenheit mehrfach. Die Analyse des Sendeverhaltens ist oft der einzige Weg, solche heimlichen Datenstr\u00f6me aufzudecken .<\/p>\n\n\n\n Das ehrgeizige ESP32-Open-MAC-Projekt<\/strong> 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<\/strong>. Daf\u00fcr haben sie:<\/p>\n\n\n\n Das ist die K\u00f6nigsklasse des Reverse Engineering: nicht nur zu sehen, was passiert, sondern zu verstehen, warum und wie es passiert.<\/p>\n\n\n\n An der Technischen Universit\u00e4t Berlin<\/strong> und der Saarland University<\/strong> verfolgte ein Forscherteam ein anderes Ziel. Sie wollten den Energieverbrauch von WiFi-\u00dcbertragungen vorhersagen<\/strong> k\u00f6nnen \u2013 essentiell f\u00fcr batterielose Ger\u00e4te, die ihre Energie aus Umgebung gewinnen (Solar, Vibration, Radiofrequenzen) .<\/p>\n\n\n\n Dazu analysierten sie das Sendeverhalten des ESP32-C3 (der RISC-V-Variante) im Detail. Sie fanden heraus:<\/p>\n\n\n\n Die Ergebnisse flossen in ein Modell f\u00fcr statische Worst-Case-Analyse des Energieverbrauchs (WCEC)<\/strong> ein \u2013 Grundlagenforschung auf Basis von Reverse Engineering .<\/p>\n\n\n\n Im M\u00e4rz 2025 sorgte die Sicherheitsfirma Tarlogic<\/strong> f\u00fcr Schlagzeilen. Sie hatte bei der Analyse der Bluetooth-Implementierung des ESP32 29 undokumentierte Befehle<\/strong> entdeckt, die tiefe Eingriffe in den Speicher erlaubten .<\/p>\n\n\n\n Die ersten Meldungen sprachen von einer „Backdoor“, doch die Realit\u00e4t war differenzierter. Es handelte sich um Debug-Befehle, die f\u00fcr Entwicklungszwecke im Chip verblieben waren. Sie sind nicht remote ausl\u00f6sbar<\/strong> \u2013 ein Angreifer m\u00fcsste bereits physischen Zugriff und privilegierte Rechte haben, um sie nutzen zu k\u00f6nnen .<\/p>\n\n\n\n Dennoch zeigt der Fall: Selbst in einem der meistverbauten Chips der Welt schlummern F\u00e4higkeiten, von denen niemand wei\u00df \u2013 bis jemand genau hinsieht und das Sendeverhalten analysiert.<\/p>\n\n\n\n WiFi-Ger\u00e4te 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\u00e4ts erfassen wollen, m\u00fcssen Sie regelm\u00e4\u00dfig den Kanal wechseln \u2013 und riskieren dabei, Pakete auf anderen Kan\u00e4len zu verpassen.<\/p>\n\n\n\n Typische Implementierungen springen alle 200\u2013300 Millisekunden zum n\u00e4chsten Kanal . Das ist ein Kompromiss: Sie sehen alles, aber nicht alles gleichzeitig.<\/p>\n\n\n\n Eine professionelle L\u00f6sung sind mehrere ESP32, die synchronisiert auf verschiedenen Kan\u00e4len lauschen. F\u00fcr Hobby-Zwecke reicht oft das Kanal-Hopping aus.<\/p>\n\n\n\n Wenn Sie nicht nur passiv lauschen, sondern aktiv kommunizieren wollen (etwa um auf Probe Requests zu antworten), sto\u00dfen Sie an eine Grenze: ACK-Best\u00e4tigungen m\u00fcssen innerhalb von 10 Mikrosekunden<\/strong> bei 802.11b gesendet werden. Das ist in Software unm\u00f6glich \u2013 hier muss die Hardware so konfiguriert werden, dass sie automatisch ACKs sendet .<\/p>\n\n\n\n Bei eigenen Experimenten mit aktivem Senden ist die Wahl der MAC-Adresse wichtig. Das erste Byte darf nicht mit Im Promiscuous Mode kann ein ESP32 in dichten Umgebungen tausende Pakete pro Sekunde empfangen. Die \u00dcbertragung per serieller Schnittstelle wird schnell zum Flaschenhals. Hier hilft:<\/p>\n\n\n\n Die F\u00e4higkeit, drahtlose Kommunikation zu belauschen, ist ein m\u00e4chtiges Werkzeug \u2013 und wie alle m\u00e4chtigen Werkzeuge birgt es Missbrauchspotenzial.<\/p>\n\n\n\n Die klare Regel: Nur Ger\u00e4te analysieren, die einem selbst geh\u00f6ren oder f\u00fcr die man eine ausdr\u00fcckliche Erlaubnis hat<\/strong> . Das Abh\u00f6ren fremder Kommunikation ist in den meisten L\u00e4ndern strafbar, selbst wenn sie „nur“ \u00fcber WLAN l\u00e4uft.<\/p>\n\n\n\n F\u00fcr Forschungszwecke gibt es Ausnahmen, aber auch hier gilt: Die Ergebnisse sollten so ver\u00f6ffentlicht werden, dass sie keine konkreten Angriffe erm\u00f6glichen. Die Entdecker der versteckten Bluetooth-Befehle etwa kommunizierten verantwortungsvoll mit dem Hersteller, bevor sie an die \u00d6ffentlichkeit gingen .<\/p>\n\n\n\n Reverse Engineering ist keine destruktive Disziplin. Im besten Fall deckt es Sicherheitsl\u00fccken auf, bevor Angreifer sie ausnutzen k\u00f6nnen. Es zwingt Hersteller zu mehr Transparenz und hilft Verbrauchern, informierte Entscheidungen zu treffen.<\/p>\n\n\n\n Die ESP32-Community hat hier eine bemerkenswerte Kultur entwickelt: Espressif selbst steht Reverse Engineering f\u00fcr Forschungszwecke offen gegen\u00fcber und kooperiert mit Forschern .<\/p>\n\n\n\n Die manuelle Analyse von Paket-Mitschnitten ist aufwendig. Erste Ans\u00e4tze nutzen maschinelles Lernen, um automatisch Auff\u00e4lligkeiten im Sendeverhalten zu erkennen:<\/p>\n\n\n\n Diese Werkzeuge stecken noch in den Kinderschuhen, aber die Entwicklung schreitet schnell voran.<\/p>\n\n\n\n Die zunehmende Verschl\u00fcsselung erschwert die Analyse. W\u00e4hrend Metadaten oft sichtbar bleiben, sind die Nutzdaten immer h\u00e4ufiger unlesbar. Hier k\u00f6nnten Hardware-Angriffe (etwa das Auslesen von Schl\u00fcsseln aus dem Speicher) oder Seitenkanal-Analysen an Bedeutung gewinnen.<\/p>\n\n\n\n Die Methoden der Sendeverhaltens-Analyse wandern zunehmend in standardisierte Sicherheitsbewertungen. Tarlogic etwa hat mit der Bluetooth Security Assessment Methodology (BSAM)<\/strong> einen strukturierten Ansatz vorgelegt, der auch die Analyse des Sendeverhaltens umfasst .<\/p>\n\n\n\n Das Reverse Engineering des Sendeverhaltens beim ESP32 ist mehr als eine technische Spielerei. Es ist ein Werkzeug der Aufkl\u00e4rung in einer Welt, die zunehmend von unsichtbarer Kommunikation durchdrungen ist.<\/p>\n\n\n\n Wer versteht, was seine Ger\u00e4te wirklich senden, kann:<\/p>\n\n\n\n Die technischen H\u00fcrden sind \u00fcberwindbar. Ein ESP32 f\u00fcr wenige Euro, etwas Code und Wireshark als Analysesoftware \u2013 mehr braucht es nicht, um in die verborgene Welt der drahtlosen Kommunikation einzutauchen.<\/p>\n\n\n\n Und manchmal, wenn man genau hinh\u00f6rt, entdeckt man Dinge, die niemand erwartet hat: 29 versteckte Befehle in einem allt\u00e4glichen Chip oder heimliche Datenstr\u00f6me zu Servern in fernen L\u00e4ndern.<\/p>\n\n\n\n Die Ger\u00e4te sprechen \u2013 man muss nur lernen, ihnen zuzuh\u00f6ren.<\/p>\n\n\n\n Vom passiven Lauscher zum aktiven Verstehen \u2013 wie man IoT-Ger\u00e4ten auf die Spur kommt Einleitung: Die Sprache der Dinge In einer Welt, in der vernetzte Ger\u00e4te l\u00e4ngst unseren Alltag durchdringen, bleibt ihre eigentliche Kommunikation f\u00fcr die meisten Menschen unsichtbar. Smart-Home-Sensoren senden Temperaturdaten, \u00dcberwachungskameras \u00fcbertragen Videostr\u00f6me, und T\u00fcrschl\u00f6sser warten auf \u00d6ffnungsbefehle \u2013 all das geschieht in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41,17,19,32],"tags":[2225,3428,5185,5565,5876,6257,7777],"class_list":["post-1747","post","type-post","status-publish","format-standard","hentry","category-digitalkultur","category-im-herz","category-im-ruckspiegel","category-techarchaologie","tag-esp32","tag-iot-sicherheit","tag-paketanalyse","tag-promiscuous-mode","tag-reverse-engineering","tag-sendeverhalten","tag-wireshark"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/1747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=1747"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/1747\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=1747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=1747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=1747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}esp_wifi_set_promiscuous(true);<\/pre>\n\n\n\n
Die technische Umsetzung: Pakete einfangen<\/h3>\n\n\n\n
void sniffer_callback(void *buf, wifi_promiscuous_pkt_type_t type) {\n wifi_promiscuous_pkt_t *pkt = (wifi_promiscuous_pkt_t*)buf;\n uint32_t paketlaenge = pkt->rx_ctrl.sig_len;\n uint8_t *nutzdaten = pkt->payload;\n \/\/ Hier k\u00f6nnen die Daten weiterverarbeitet werden<\/em>\n}<\/pre>\n\n\n\nDie Herausforderung: Hardware-Filter umgehen<\/h3>\n\n\n\n
wifi_promiscuous_filter_t filter = {\n .filter_mask = WIFI_PROMIS_FILTER_MASK_ALL\n};\nesp_wifi_set_promiscuous_filter(&filter);<\/pre>\n\n\n\n
\n\n\n\nII. Vom Chip zum Computer: Pakete exportieren<\/h2>\n\n\n\n
\n
Das PCAP-Format: Der Industriestandard<\/h3>\n\n\n\n
\n\n\n\nIII. Die Analyse: Wireshark als Fenster in die drahtlose Welt<\/h2>\n\n\n\n
Was Wireshark aus einem einzelnen Paket herausholt<\/h3>\n\n\n\n
Frame 42: 128 Bytes on wire\n\u251c\u2500\u2500 IEEE 802.11 (MAC-Ebene)\n\u2502 \u251c\u2500\u2500 Frame Control: 0x0802 (Data, QoS Data)\n\u2502 \u2502 \u251c\u2500\u2500 Version: 0\n\u2502 \u2502 \u251c\u2500\u2500 Type: Data (2)\n\u2502 \u2502 \u251c\u2500\u2500 Subtype: QoS Data (8)\n\u2502 \u2502 \u2514\u2500\u2500 Flags: 0x01 (Nach unten gerichtet)\n\u2502 \u251c\u2500\u2500 Dauer: 44 Mikrosekunden\n\u2502 \u251c\u2500\u2500 Adresse 1 (Empf\u00e4nger): aa:bb:cc:dd:ee:ff\n\u2502 \u251c\u2500\u2500 Adresse 2 (Sender): 11:22:33:44:55:66\n\u2502 \u251c\u2500\u2500 Adresse 3 (BSSID): 00:11:22:33:44:55\n\u2502 \u2514\u2500\u2500 Sequenznummer: 1234\n\u251c\u2500\u2500 LLC (Logical Link Control)\n\u2502 \u251c\u2500\u2500 DSAP: 0xaa (SNAP)\n\u2502 \u2514\u2500\u2500 Control: 0x03 (Unnumbered Information)\n\u251c\u2500\u2500 IPv4\n\u2502 \u251c\u2500\u2500 Version: 4\n\u2502 \u251c\u2500\u2500 Quell-IP: 192.168.1.5\n\u2502 \u2514\u2500\u2500 Ziel-IP: 192.168.1.100\n\u251c\u2500\u2500 UDP\n\u2502 \u251c\u2500\u2500 Quellport: 45678\n\u2502 \u2514\u2500\u2500 Zielport: 1883\n\u2514\u2500\u2500 MQTT (Message Queuing Telemetry Transport)\n \u251c\u2500\u2500 Befehl: PUBLISH (3)\n \u251c\u2500\u2500 Topic-L\u00e4nge: 24\n \u251c\u2500\u2500 Topic: \"haus\/wohnzimmer\/temperatur\"\n \u2514\u2500\u2500 Payload: \"22.5 \u00b0C\"<\/pre>\n\n\n\n
Gezielte Suche: Filter in Wireshark<\/h3>\n\n\n\n
\n
wlan.fc.type == 0<\/code>\u00a0\u2013 Alle Management-Frames (Verbindungsaufbau, Beacon-Frames)<\/li>\n\n\n\nwlan.fc.type == 2<\/code>\u00a0\u2013 Alle Daten-Frames (die eigentlichen Nutzdaten)<\/li>\n\n\n\nmqtt<\/code>\u00a0\u2013 Alle MQTT-Nachrichten<\/li>\n\n\n\nip.src == 192.168.1.5<\/code>\u00a0\u2013 Alle Pakete von einer bestimmten IP<\/li>\n\n\n\nudp.port == 53<\/code>\u00a0\u2013 DNS-Anfragen<\/li>\n\n\n\nhttp.request.method == \"GET\"<\/code>\u00a0\u2013 HTTP-GET-Anfragen<\/li>\n<\/ul>\n\n\n\nmqtt && ip.src == 192.168.1.5<\/code> \u2013 alle MQTT-Nachrichten von einem bestimmten Ger\u00e4t .<\/p>\n\n\n\nKommunikationsabl\u00e4ufe rekonstruieren<\/h3>\n\n\n\n
\n
\n\n\n\nIV. Was man alles analysieren kann: Die Dimensionen des Sendeverhaltens<\/h2>\n\n\n\n
1. Verbindungsaufbau und Authentifizierung<\/h3>\n\n\n\n
2. Periodizit\u00e4t und Timing<\/h3>\n\n\n\n
\n
3. Verwendete Protokolle<\/h3>\n\n\n\n
\n
4. Signalst\u00e4rke und physische Lokalisierung<\/h3>\n\n\n\n
5. Versteckte Kommunikation<\/h3>\n\n\n\n
\n\n\n\nV. Fortgeschrittene Anwendungen: Vom passiven Lauschen zum aktiven Verstehen<\/h2>\n\n\n\n
Fallstudie 1: Reverse Engineering des MAC-Layers<\/h3>\n\n\n\n
\n
Fallstudie 2: Energieverbrauchsanalyse durch Sendeverhalten<\/h3>\n\n\n\n
\n
Fallstudie 3: Die Entdeckung versteckter Bluetooth-Befehle<\/h3>\n\n\n\n
\n\n\n\nVI. Praktische Herausforderungen und L\u00f6sungen<\/h2>\n\n\n\n
Kanal-Hopping: Das Problem der verteilten Kommunikation<\/h3>\n\n\n\n
ACK-Timing: Wenn die Hardware zu langsam ist<\/h3>\n\n\n\n
MAC-Adressen korrekt setzen<\/h3>\n\n\n\n
01<\/code> beginnen, da dies Multicast-Adressen kennzeichnet. Mit einer ung\u00fcltigen MAC-Adresse antwortet kein Access Point auf Ihre Anfragen .<\/p>\n\n\n\nDatenmengen bew\u00e4ltigen<\/h3>\n\n\n\n
\n
\n\n\n\nVII. Ethische und rechtliche Dimension<\/h2>\n\n\n\n
Was ist erlaubt?<\/h3>\n\n\n\n
Verantwortung der Forscher<\/h3>\n\n\n\n
\n\n\n\nVIII. Zukunftsperspektiven: Wohin entwickelt sich die Analyse?<\/h2>\n\n\n\n
Automatisierung durch KI<\/h3>\n\n\n\n
\n
Verschl\u00fcsselung als Herausforderung<\/h3>\n\n\n\n
Integration in Sicherheitsforschung<\/h3>\n\n\n\n
\n\n\n\nFazit: Die unsichtbare Sprache verstehen lernen<\/h2>\n\n\n\n
\n
\n\n\n\nQuellen<\/h2>\n\n\n\n
\n
\n\n\n\nKategorisierung<\/h2>\n\n\n\n
\n