De gedachte om een draagbaar hulpmiddel voor het analyseren van WiFi-netwerken te maken, werd bij mij opgewekt .
Bedankt aan hen voor het idee. Ik had toevallig niets te doen.
Al het werk werd uitgevoerd als een hobby met als doel plezier te hebben en mijn kennis op het gebied van netwerktechnologieƫn uit te breiden. Op mijn gemak, 1 tot 4 uur per week, sinds het begin van dit jaar.
Ik had niet de bedoeling om het praktisch te gebruiken. Dit is GEEN hulpmiddel voor hackers.
Momenteel werkt alle geplande functionaliteit. Alle broncodes, volledig klaargemaakt om te bouwen, . Daar is ook een handleiding voor de assemblage etc. In deze opmerking zal ik de informatie die op GitHub staat niet dupliceren. Ik zal alleen beschrijven wat ik nodig acht om afzonderlijk te vermelden.
Mijn mening over het "universele hulpmiddel" en de reden voor de keuze van de ESP32
Ik claim niet de waarheid. Deze is voor iedereen anders. Ik zal proberen mijn keuze voor de "hardware" te onderbouwen.
gebruik combinerend Linux (oorspronkelijk Raspberry Pi) + 'periferie' in de vorm van een controller (STM32) + CC1110 (op basis van 8051) en had de intentie om daar alles in te stoppen wat maar mogelijk is (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) leek niet geschikt voor mij. Echter, blijkt waarschijnlijk een privƩ en gesloten project te blijven (flipper-zero github "Deze organisatie heeft geen openbare repositories.") en ging ik naar minder gangbare hardware.
Misschien heb ik het mis, en zullen de auteurs in de toekomst de broncodes van de software openbaar maken. Maar als dat niet gebeurt, zou ik zo'n apparaat zonder de broncodes niet kopen.
Mijn eisen aan het "hulpmiddel"
De doos moet klein zijn (hoe kleiner, hoe beter).
Therefore:
- Een ingebouwde batterij is niet nodig. Bij een stroom van > 100 mA bij gebruik van Wifi, zal de ingebouwde batterij groot zijn, of het houdt het niet lang vol. Daarom moet de "doos" van een standaard powerbank worden voorzien. Ik heb altijd een powerbank in mijn zak/bij de auto.
- Er moet Linux met tools in de "doos" draaien, geschreven over veel jaren in alle talen met een klein scherm en een beperkt aantal bedieningsknoppen heeft geen zin. Resultaten kunnen ook bekeken/ verwerkt worden op een normale laptop met een volledig toetsenbord en scherm.
- De componenten moeten gemakkelijk verkrijgbaar en algemeen bekend zijn (beschikbare SDK, veel voorbeelden en documentatie).
Uiteindelijk was de keuze voor mij duidelijk - ESP32.
Voor alle taken die in het artikel zijn genoemd dat me tot actie heeft aangezet, zijn de mogelijkheden van de ESP32 ruim voldoende. Hoewel het maximum dat ik nog wil doen is:
- Spelen met Bluetooth.
- Spelen met het 433mHz bereik met de eenvoudigste hardware (alleen amplitude-modulatie, wat voldoende is voor praktisch gebruik).
Een lepel tegenspoed bij de ESP32
- SDK (IDF) voor de ESP32 is wat rommelig.
- Een deel van de functionaliteit (zoals de WiFi-stack) komt zonder bronbestanden in de vorm van voorgecompileerde statische bibliotheken.
- Het 5GHz-bereik wordt niet ondersteund en er zijn enkele beperkingen en onvolkomenheden in de werking van WiFi.
Maar de prijs/grootte compenseert deze tekortkomingen goed.
De belangrijkste functionaliteit van de software
Ik zal kort de functionaliteit beschrijven en mijn mening overā¦
Beheer van instellingen en uploaden van bestanden van SD
Al het externe beheer is gedaan via een eenvoudige webpagina die wordt uitgevoerd in een apart menu-item. De ESP32 start op in WiFi AP-modus en levert een pagina op een vast IP-adres.
Hoewel de cores van de ESP32 vrij snel zijn, heeft experimenteren aangetoond dat de gelijktijdige werking van de ingebouwde webservice en bijvoorbeeld de routermodus niet goed samengaat. Daarom is dynamisch beheer niet beschikbaar en is de pagina in alle andere modi niet toegankelijk.
Bovendien is dynamisch beheer voor onderzoeksdoeleinden niet nodig.
Werkmodus met Beacon-pakketten
De modi zijn banaal en niet zo interessant. Ze zijn gemaakt 'omdat het kan'. Voor de vorm.
Voorbeelden zijn te vinden in de officiƫle voorbeeldprojecten van Espressif.
Scanmodus voor AP-lijsten.
Eigenlijk kan elke smartphone dit.
In deze modus wordt ook de lijst van AP's opgeslagen.
Beacon spammer.
De ESP32 start als AP met een verborgen SSID en een willekeurige MAC en begint [beacon frame] te verzenden op basis van een vooraf gemaakte lijst van SSID's (handmatig gemaakt of eerder verkregen tijdens het scannen van de lijst met AP's)
WiFi-pakket sniffing modus
De ontwikkelaars van Espressif hebben een mogelijkheid toegevoegd voor applicatiesoftware om via een callbackfunctie alle WiFi-pakketten die 'door de lucht vliegen' te ontvangen. In werkelijkheid niet alles, want het is mogelijk om de modus alleen voor Ć©Ć©n vast kanaal in te stellen.
Bij de verwerking van de callbackfunctie zijn er strikte tijdslimieten. Terwijl dit voor de modus van eenvoudige statistische verzameling geen probleem vormt, bleek het voor de opname van een PCAP-bestand op de SD-kaart een behoorlijke uitdaging te zijn, waarbij ik de opname via een wachtrij in het geheugen en semaforen moest organiseren. Houd rekening met het feit dat het proces dat de callback oproept op Ć©Ć©n kern draait, en het proces dat de opname op de SD uitvoert op een andere.
Bij een "ruizige ether" gaan sommige pakketten verloren (er is geen plaats in de wachtrij en ze worden verworpen), maar in een typische "ether" van een appartement in de avond (5..7 AP's binnen zicht) wordt de opname in PCAP uitgevoerd zonder pakketverlies.
Bovendien is er een filtermodus voor monitoring en opname van PCAP op basis van een MAC-lijst in de pakketkoppen.
Bijvoorbeeld, je kunt het verschijnen van iemand in een club/cafĆ© volgen nog voordat hij of zij Ć¼berhaupt binnenkomt of in het gezichtsveld verschijnt. Weinig mensen schakelen WiFi en automatische verbindingen met bekende AP's uit. (Ik doe het nu...)
Het bekijken van de opgenomen verkeer in Wireshark is leerzaam en interessant om te begrijpen hoe dat allemaal werkt.
Modus voor werken met deauth-pakketten.
Standaard is het verzenden van deze pakketten verboden in de bibliotheek libnet80211.a, die zonder broncode wordt geleverd. Maar het is niet moeilijk om dit te omzeilen door een paar bytes aan te passen. In het begin twijfelde ik of ik de patch moest delen. Maar na verschillende plekken te hebben bezocht met de scanningmodus voor het verzenden van [deauthentication frame], dacht ik: "Waarom niet?" Zeker omdat het verzenden van deze pakketten op de esp8266 niet geblokkeerd is en er versies op github voor de esp8266 bestaan.
Op veel plekken (ik zal niet zeggen waar) wordt deze methode gebruikt om ongewenste AP's te onderdrukken. En het zijn geen "vandalen"...
En ik vroeg me nog af waarom het delen van internet vanaf mijn telefoon soms niet werkte...
De modus voor het volgen van het aantal en RSSI van dergelijke pakketten is erg nuttig om te begrijpen "waar ze geen ongewenste AP's waarderen".
Routermodus.
Deze functie is waarschijnlijk de meest interessante van allemaal om te onderzoeken.
ESP32 ondersteunt gelijktijdige werking in STA + SoftAP-modus. Daarom kan het worden gebruikt als een klassieke NAT-router.
Ter ondersteuning van de netwerkstack gebruikt Espressif een fork (bijna zonder wijzigingen) van de lwip-bibliotheek.
Maar standaard, in de reguliere build, is er in de bibliotheek esp-lwip geen doorgifte tussen de netif-interfaces 'ap' (SoftAP) en 'st' (STA) voorzien.
NAT is certainly optional, but it leads to the issue of connecting two or more STAs to the āapā interface simultaneously and synchronizing IP addresses from the āstā network interface to āapā. Thus, the complications are not worth it, and it's simpler to use NAT.
Moreover, there is a fork of esp-lwip by martin-ger, which includes a simple implementation of NAT for IPv4.
Although I was tempted to modify it cosmetically (in my opinion, it would have been easier without the fork and just using LWIP)HOOK functions defined during the build), but laziness prevailed and I used martin-ger's version as is.
In router mode, incoming and outgoing IPv4 traffic is monitored.
In particular, it extracts data for display on the screen and for collecting statistics in a file:
- The device name that connected to the SoftAP ESP32 (DHCP packets)
- The URL from DNS queries (UDP port 53) from a device connected to the SoftAP ESP32.
Additionally, you can enable traffic logging to a PCAP file.
This mode is very useful, for instance, to understand what your phone is sending to the network and where it is going.
Other usage methods for this mode can be thought of, considering the ability to fully manage the incoming and outgoing traffic of the SoftAP ESP32 at the network interface level: Ethernet header (destMAC[6]+srcMAC[6]+type[2]) + payload (IPv4, IPv6, DHCP, etc.).
In principle, the ESP32 handles the function of a WiFi-to-WiFi router quite well, allowing normal traffic to pass through without significant delays. Subjectively, delays on a phone connected through the router on the ESP32 are not noticeable.
Unfortunately, the Espressif API does not offer a way to set a MAC filter for devices connecting to the SoftAP ESP32. Instead, it suggests saying 'goodbye' (esp_wifi_deauth_sta) to already connected STAs that are 'undesirable'.
MAC filtering for connecting STAs had to be done by calling esp_wifi_deauth_sta()
Ter conclusie
Although I didn't come up with anything new regarding working with the ESP32, perhaps the results (source code) will be of interest to someone.
I would like to note that I wrote the code purely for educational purposes. It was deliberately made inconvenient for 'hacking' and similar purposes.
I did not create a printed circuit board, as it took about 1.5-2 hours to solder ready-made boards with wires.
And if one were to do it, it would be better to assemble it from separate components rather than from ready-made boards. Then the dimensions would be even smaller.
Bron: habr.com
