Der Gedanke, ein tragbares Werkzeug zur Analyse von WiFi-Netzwerken zu entwickeln, wurde durch .
sie angestoßen. Ich hatte gerade nichts zu tun.
Die gesamte Arbeit wurde im Rahmen eines Hobbys mit dem Ziel durchgeführt, Freude zu haben und mein Wissen im Bereich Netzwerktechnologien zu erweitern. In aller Ruhe, 1..4 Stunden pro Woche, seit Anfang dieses Jahres.
Eine praktische Verwendung habe ich nicht geplant. Das heißt, es ist kein Werkzeug für Hacker.
Momentan funktioniert die gesamte geplante Funktionalität. Alle Quellcodes, vollständig bereit zur Kompilierung, . Dort finden Sie auch die Anleitung zum Zusammenbau usw. In diesem Artikel werde ich die Informationen, die auf GitHub veröffentlicht wurden, nicht duplizieren. Ich werde nur das beschreiben, was ich für notwendig halte, gesondert zu erläutern.
Meine Meinung zum "universal Werkzeug" und der Grund für die Wahl von ESP32
Ich erhebe keinen Anspruch auf Wahrheit. Jeder hat seine eigene. Ich werde versuchen, meine Wahl des "Hardwares" zu begründen.
Verwendung ist eine Kombination von Linux (ursprünglich Raspberry Pi) + „Peripherie“ in Form eines Controllers (STM32) + CC1110 (Kern 8051) mit dem Plan, alles unterzubringen, was nur möglich ist (125kHz, NFC, 433mHz, USB, iButton, Bluetooth, ?) erschien mir nicht geeignet. Dennoch, scheint privat und geschlossen zu bleiben (flipper-zero github "Diese Organisation hat keine öffentlichen Repositories.") und ich habe mich in Richtung weniger verbreiteter Hardware bewegt.
Vielleicht irre ich mich, und die Autoren werden die Quellcodes der Software irgendwann öffentlich zugänglich machen. Aber wenn nicht, hätte ich so ein Gerät ohne Quellcodes nicht gekauft.
Meine Anforderungen an das "Werkzeug"
Die Box sollte klein sein (je kleiner, desto besser).
Deshalb:
- Ein eingebauter Akku ist nicht nötig. Bei einem Stromverbrauch > 100 mA beim Arbeiten mit Wifi ist der eingebaute Akku entweder groß oder hält nicht lange. Daher sollte die "Box" von einer standardmäßigen Powerbank betrieben werden. Eine Powerbank habe ich sowieso immer in der Tasche/im Auto.
- Es macht keinen Sinn, Linux mit Werkzeugen zu betreiben, die über viele Jahre in allen Sprachen geschrieben wurden wenn ein kleines Display und eine spärliche Anzahl von Steuerungstasten vorhanden sind. Die Ergebnisse können auch auf einem normalen Laptop mit einer vollständigen Tastatur und einem Bildschirm angesehen/bearbeitet werden.
- Die Komponenten sollten leicht verfügbar und weit verbreitet sein (verfügbares SDK, viele Beispiele und Dokumentation).
Das Ergebnis war für mich klar — ESP32.
Für alle Aufgaben, die in dem Artikel erwähnt werden, der mich zu diesen Maßnahmen angeregt hat, reichen die Möglichkeiten des ESP32 vollkommen aus. Obwohl ich maximal Folgendes noch machen möchte:
- Mit Bluetooth experimentieren.
- Mit dem 433mHz-Bereich unter einfachster Hardware experimentieren (nur Amplitudenmodulation, die für die praktischen Bedürfnisse ausreicht).
Ein Wermutstropfen beim ESP32
- Das SDK (IDF) für den ESP32 ist etwas holprig.
- Ein Teil der Funktionalität (z. B. der WiFi-Stack) wird ohne Quellcode in Form von kompilierten statischen Bibliotheken geliefert.
- Der 5Ghz-Bereich wird nicht unterstützt, und es gibt einige Einschränkungen und Unannehmlichkeiten bei der WiFi-Nutzung.
Aber der Preis/die Größen entschädigen für diese Nachteile.
Die Hauptfunktionalität der Software
Ich werde kurz die Funktionalität und meine Meinung zu… beschreiben.
Verwaltung der Einstellungen und das Hochladen von Dateien von der SD-Karte
Alle externe Steuerung erfolgt über eine einfache Webseite, die in einem separaten Menüpunkt aufgerufen wird. Der ESP32 wird im WiFi-AP-Modus gestartet und stellt die Seite unter einer festen IP-Adresse bereit.
Obwohl die Kerne des ESP32 recht schnell sind, hat sich in Experimenten gezeigt, dass die gleichzeitige Nutzung des eingebauten Webservices und z. B. des Router-Modus nicht gut harmoniert. Daher gibt es keine dynamische Steuerung, und in allen anderen Modi ist die Seite nicht verfügbar.
Zumal für Forschungszwecke keine dynamische Steuerung erforderlich ist.
Betriebsmodus mit Beacon-Paketen
Die Modi sind banal und nicht sehr interessant. Sie wurden ‚weil es möglich ist‘ umgesetzt. Nur um ein Häkchen zu setzen.
Beispiele finden sich in den offiziellen Beispielen von Espressif.
Modus zur Scannen von AP-Listen.
Das kann eigentlich jedes Smartphone.
In diesem Modus wird die AP-Liste gespeichert.
Beacon-Spammer.
Der ESP32 startet als AP mit verstecktem SSID und zufälliger MAC und beginnt, [beacon frame] aus einer vorher erstellten SSID-Liste zu senden (entweder manuell erstellt oder zuvor beim Scannen der AP-Liste erhalten).
Modus zum Sniffen von WiFi-Paketen
Die Entwickler von Espressif haben die Möglichkeit hinzugefügt, dass Anwendungssoftware über eine Callback-Funktion alle WiFi-Pakete ‚in der Luft‘ empfangen kann. Tatsächlich nicht alle, da der Modus nur für einen bestimmten festen Kanal eingestellt werden kann.
Auf die Verarbeitung des Rückrufs werden sehr strenge zeitliche Beschränkungen angewendet. Während dies im Modus der einfachen Statistiksammlung keine Probleme verursacht, musste ich im Modus der PCAP-Dateiaufzeichnung auf die SD-Karte einiges an Aufwand betreiben, um die Aufnahme über eine Warteschlange im Speicher und Semaphore zu organisieren. Dabei ist zu beachten, dass der Prozess, der den Rückruf auslöst, auf einem Kern läuft, während der Prozess, der die Daten auf die SD-Karte schreibt, auf einem anderen Kern läuft.
Bei einem "rauschenden Funk" gehen einige Pakete verloren (es gibt keinen Platz in der Warteschlange und sie werden verworfen), aber bei einem typischen "Funk" in Wohnungen am Abend (5..7 APs in Sichtweite) gelingt die PCAP-Aufzeichnung ohne Paketverluste.
Zusätzlich gibt es für das Monitoring und die PCAP-Aufzeichnung einen Filtermodus für MAC-Listen in den Pakethauptteilen.
Zum Beispiel kann man das Erscheinen einer Person im Club/Café verfolgen, bevor sie überhaupt eingetreten oder sichtbar geworden ist. Nur wenige Menschen schalten WiFi und automatische Verbindungen zu bekannten APs aus. (Ich schalte es jetzt aus..)
Den aufgezeichneten Verkehr in Wireshark zu betrachten, ist lehrreich und interessant, um zu verstehen, wie das alles funktioniert.
Betriebsmodus mit Deauth-Paketen
Standardmäßig ist das Senden dieser Pakete in der Bibliothek libnet80211.a, die ohne Quellcode kommt, verboten. Doch es ist nicht schwer, dies zu zensieren, indem man ein paar Bytes anpasst. Zunächst war ich mir unsicher, ob ich den Patch veröffentlichen sollte. Aber nachdem ich mit aktivem Scan-Modus für die Absendung von [deauthentication frame] an verschiedenen Orten unterwegs war, dachte ich: "was soll's". Zumal das Senden dieser Pakete im esp8266 nicht blockiert ist und es Builds auf GitHub für den esp8266 gibt.
An sehr vielen Orten (ich werde nicht sagen wo) wird diese Methode verwendet, um unerwünschte APs zu unterdrücken. Und das sind keine "Rowdys"...
Und ich habe mich noch gewundert, warum die Internetfreigabe mit meinem Handy manchmal nicht funktioniert...
Der Modus zur Verfolgung der Anzahl und RSSI solcher Pakete ist sehr nützlich, um zu verstehen, wo unerwünschte APs nicht gemocht werden.
Router-Modus
Diese Funktion ist wahrscheinlich die interessanteste von allen für die Forschung.
Der ESP32 unterstützt den gleichzeitigen Betrieb im STA + SoftAP-Modus. Daher kann man ihn als klassischen NAT-Router implementieren.
Für die Unterstützung des Netzwerkstacks verwendet Espressif einen Fork (praktisch ohne Änderungen) der lwip-Bibliothek.
Aber standardmäßig ist in der Standardversion der Bibliothek esp-lwip keine Weiterleitung zwischen den netif-Schnittstellen 'ap' (SoftAP) und 'st' (STA) vorgesehen.
Es ist natürlich möglich, es auch ohne NAT zu machen, aber es gibt ein Problem mit der gleichzeitigen Verbindung von zwei oder mehr STAs an die Schnittstelle 'ap' und der Synchronisation der IP-Adressen vom Netzwerkinterface 'st' zu 'ap'. Daher lohnt sich der Aufwand nicht, und es ist einfacher über NAT.
Umso mehr, als es einen Fork von esp-lwip von martin-ger gibt, in dem eine einfache NAT-Implementierung für IP4 hinzugefügt wurde.
Obwohl ich in Versuchung war, es rein kosmetisch umzubauen (meiner Meinung nach wäre es einfacher gewesen, ohne den Fork des Projekts, sondern über LWIP), siegte die Faulheit, und die Variante von martin-ger wird so verwendet, wie sie ist.HOOK Funktionen, die beim Build definiert sind), aber die Faulheit hat gesiegt, und die Variante von martin-ger wird einfach so verwendet.
Im Router-Modus wird der eingehende und ausgehende IP4-Verkehr überwacht.
Dabei werden unter anderem folgende Daten extrahiert, um sie auf dem Bildschirm anzuzeigen und zur Statistikerfassung in eine Datei zu speichern:
- Der Name des Geräts, das sich mit dem SoftAP ESP32 verbunden hat (DHCP-Pakete)
- URLs aus den DNS-Anfragen (UDP-Port 53) vom an den SoftAP ESP32 angeschlossenen Gerät.
Zusätzlich kann die Aufzeichnung des Verkehrs in eine PCAP-Datei aktiviert werden.
Dieser Modus ist sehr nützlich, um zum Beispiel zu verstehen, was Ihr Telefon ins Netzwerk sendet und wohin es dabei geht.
Man kann auch andere Nutzungsmöglichkeiten für diesen Modus erfinden, da man die eingehenden und ausgehenden Datenströme des SoftAP ESP32 auf der Ebene des Netzwerkinterfaces vollständig programmatisch steuern kann: Ethernet-Header (destMAC[6]+srcMAC[6]+type[2]) + Payload (IP4, IP6, DHCP und andere Typen).
Im Prinzip meistert der ESP32 die Aufgabe eines WiFi->WiFi-Routers ganz gut, indem er den gewöhnlichen Verkehr ohne nennenswerte Verzögerungen durchleitet. Subjektiv sind die Verzögerungen bei einem über den Router auf den ESP32 verbundenen Telefon nicht spürbar.
Leider gibt es in der API von Espressif keine Möglichkeit, einen Filter für MAC-Adressen, die sich mit dem SoftAP EPS32 verbinden, einzustellen. Stattdessen wird vorgeschlagen, den bereits verbundenen STAs, die "unerwünscht" sind, "Auf Wiedersehen" zu sagen (esp_wifi_deauth_sta).
Die MAC-Filterung für sich verbindende STAs musste durch einen Aufruf von esp_wifi_deauth_sta() vorgenommen werden.
Abschließend
Obwohl ich im Rahmen der Arbeit mit dem ESP32 nichts Neues erfunden habe, könnte das Ergebnis (der Quellcode) für einige von Interesse sein.
Ich möchte darauf hinweisen, dass ich den Code ausschließlich zu Bildungszwecken geschrieben habe. Für "Hacking" und dergleichen wurde er bewusst nicht sehr benutzerfreundlich gestaltet.
Ich habe keine Platine erstellt, da es ungefähr 1,5 bis 2 Stunden gedauert hat, um die fertigen Platinen mit Draht zu verlöten.
Und wenn man es macht, sollte man nicht aus fertigen Platinen, sondern aus einzelnen Komponenten bauen. Dann wären die Abmessungen noch kleiner.
Quelle: habr.com
