Wat mij op het idee bracht om een zakinstrument te maken voor het analyseren van WiFi-netwerken was .
Dank aan hen voor het idee. Ik had gewoon niets te doen.
Al het werk werd gedaan als onderdeel van een hobby met als doel plezier te hebben en mijn kennis op het gebied van netwerktechnologieën uit te breiden. Langzaam, 1 uur per week, sinds begin dit jaar.
Ik had geen praktisch gebruik gepland. Die. Dit is GEEN tool voor hackers.
Op dit moment werken alle geplande functionaliteiten. Alle bronnen, geheel montageklaar, . Er zijn ook montage-instructies, enz. In deze notitie zal ik de informatie die op github is geplaatst niet dupliceren. Ik zal u alleen vertellen wat ik noodzakelijk acht om afzonderlijk te beschrijven.
Mijn mening over het “universele hulpmiddel” en de reden om voor de ESP32 te kiezen
Ik beweer niet dat ik de waarheid ben. Iedereen heeft zijn eigen. Ik zal proberen mijn hardwarekeuze te rechtvaardigen.
de use case van een combinatie van Linux (aanvankelijk Raspberry Pi) + “randapparatuur” in de vorm van een controller (STM32) + CC1110 (8051 core) en het plan om daar alles in te proppen (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) leek mij niet geschikt. Echter, Het lijkt erop dat het privé en gesloten zal blijven (flipper-zero github “Deze organisatie heeft geen openbare repositories.”) en richting niet erg gebruikelijke hardware is gegaan.
Misschien heb ik het mis en zullen de auteurs de softwarebronnen in de toekomst openbaar beschikbaar maken. Maar zo niet, dan zou ik zo'n stuk hardware niet kopen zonder de broncode.
Mijn vereisten voor de "tool"
De doos moet klein zijn (hoe kleiner, hoe beter).
daarom:
- Geen ingebouwde batterij nodig. Bij een stroomsterkte > 100 mA bij het werken met Wifi zal de ingebouwde batterij groot zijn of niet lang meegaan. Laat de “box” daarom van stroom voorzien door een standaard powerbank. Hoe dan ook, ik heb altijd een powerbank op zak/auto.
- Bewaar een Linux-"doos" met tools erin, geschreven gedurende vele jaren in alle talen Met een klein scherm en een schamele set bedieningsknoppen heeft het geen zin. De resultaten zijn te bekijken/bewerken op een normale laptop met volledig toetsenbord en scherm.
- Componenten moeten gemakkelijk toegankelijk en algemeen bekend zijn (beschikbare SDK, veel voorbeelden en documentatie).
Als gevolg hiervan lag de keuze voor mij voor de hand: ESP32.
Voor alle taken die in het artikel worden vermeld en die mij ertoe aanzetten actie te ondernemen, zijn de mogelijkheden van de ESP32 ruim voldoende. Alhoewel ik het liefste nog wil doen:
- Speel met Bluetooth.
- Speel met het bereik van 433 MHz met de eenvoudigste hardware (alleen amplitudemodulatie, wat voldoende is voor praktische behoeften).
Vlieg in de zalf in ESP32
- De ESP32 SDK (IDF) is enigszins onhandig.
- Een deel van de functionaliteit (bijvoorbeeld WiFi-stack) wordt geleverd zonder broncode in de vorm van samengestelde statische bibliotheken.
- De 5GHz-band wordt niet ondersteund en er zijn enkele beperkingen en onhandigheid bij het werken met WiFi.
Maar de prijs/grootte compenseert deze tekortkomingen volledig.
Belangrijkste softwarefunctionaliteit
Ik zal kort de functionaliteit beschrijven en mijn mening geven over...
Instellingen beheren en bestanden uploaden vanaf SD
Alle externe controle vindt plaats via een eenvoudige webpagina, gelanceerd in een apart menu-item. De ESP32 start in WiFi AP-modus en geeft een pagina weer op een vast IP-adres.
Hoewel de ESP32-cores behoorlijk snel zijn, zo blijkt uit experimenten, zijn de gelijktijdige werking van de ingebouwde webservice en bijvoorbeeld de routermodus niet erg compatibel. Daarom is er geen dynamische controle en is de pagina niet in alle andere modi beschikbaar.
Bovendien is dynamische controle niet nodig voor onderzoeksdoeleinden.
Wijze van werken met Beacon-pakketten
De modi zijn banaal en niet erg interessant. Gemaakt ‘omdat het kan’. Ter controle.
Er zijn voorbeelden in de officiële Espressif-voorbeelden.
Scanmodus AP-lijst.
Eigenlijk kan elke smartphone dit.
Welnu, in deze modus wordt de AP-lijst opgeslagen.
Beacon-spammer.
De ESP32 start als een AP met een verborgen SSID en een willekeurige MAC en begint [bakenframe] te verzenden volgens een vooraf gemaakte lijst met SSID's (handmatig gemaakt of eerder verkregen door het scannen van de AP-lijst)
WiFi-pakket-snuffelmodus
Espressif-ontwikkelaars hebben de mogelijkheid voor applicatiesoftware toegevoegd om alle WiFi-pakketten die “in de lucht vliegen” te ontvangen via de callback-functie. Eigenlijk niet allemaal, aangezien je de modus maar voor één vast kanaal kunt instellen.
Er worden zeer strikte tijdsbeperkingen opgelegd aan het verwerken van een callback-functie. Als dit geen problemen oplevert voor de eenvoudige modus voor het verzamelen van statistieken, dan moest ik voor de PCAP-bestandsopnamemodus op de SD-kaart sleutelen, waarbij ik de opname organiseerde via een wachtrij in het geheugen en semaforen. Rekening houdend met de eigenaardigheid dat het proces dat de callback aanroept op één kern draait, en het proces dat naar SD schrijft in een andere.
Tijdens “luidruchtige lucht” gaan sommige pakketten verloren (er is geen ruimte in de wachtrij en ze worden weggegooid), maar met een typische “lucht” van een appartement in de avond (5..7 AP's binnen zicht), opname in PCAP wordt voltooid zonder pakketverlies.
Bovendien is er voor PCAP-monitoring en -opname een filtermodus gebaseerd op de MAC-lijst in de pakketheaders.
U kunt bijvoorbeeld het uiterlijk van een persoon in een club/café volgen voordat hij zelfs maar binnenkomt of in zicht verschijnt. Weinig mensen schakelen wifi en automatische verbindingen met bekende toegangspunten uit. (Ik zet het nu uit..)
Het bekijken van opgenomen verkeer in Wireshark is leerzaam en interessant voor het begrijpen van kaarten - het werkt allemaal.
Modus voor het werken met death-pakketten
Standaard is het verzenden van deze pakketten verboden in de libnet80211.a-bibliotheek, die zonder bronnen wordt geleverd. Maar het is eenvoudig op te lossen door een paar stukjes aan te passen. In eerste instantie twijfelde ik of het de moeite waard was om een patch te posten. Maar nadat ik op verschillende plaatsen had rondgelopen terwijl de deauthenticatieframe-scanmodus was ingeschakeld, dacht ik: "wat maakt het uit." Bovendien is in esp8266 de levering van deze pakketten niet gesloten en staan er assemblages op github voor esp8266.
Op veel plaatsen (ik zal niet zeggen waar) wordt via deze methode gebruik gemaakt van onderdrukking van ongewenste AP's. En dit zijn geen “pestkoppen”…
En ik was ook verrast dat mijn internetdistributie vanaf mijn telefoon op sommige plaatsen niet werkte...
De modus voor het volgen van het aantal en de RSSI van dergelijke pakketten is erg handig om te begrijpen “waar de linker AP’s het niet leuk vinden.”
router-modus
Deze functie is waarschijnlijk het meest interessant om te verkennen.
ESP32 ondersteunt gelijktijdige werking in STA + SoftAP-modus. Daarom kunt u er een klassieke NAT-router op implementeren.
Om de netwerkstack te ondersteunen, gebruikt Espressif een fork (vrijwel onveranderd) van de lwip-bibliotheek.
Maar standaard biedt de esp-lwip-bibliotheek in de standaardversie geen doorsturing tussen de netif-interfaces 'ap' (SoftAP) en 'st' (STA).
Natuurlijk kun je het doen zonder NAT, maar er is een probleem met het gelijktijdig verbinden van twee of meer STA's met de 'ap'-interface en het synchroniseren van IP-adressen van de 'st'-netwerkinterface naar 'ap'. De moeilijkheden zijn dus niet de moeite waard en het is gemakkelijker via NAT.
Bovendien is er een fork esp-lwip van martin-ger, die een eenvoudige implementatie van NAT voor IP4 toevoegt.
Hoewel mijn handen jeukten om het puur cosmetisch opnieuw te maken (naar mijn mening was het gemakkelijker zonder afsplitsing van het project, maar via LWIPHOOK functies gedefinieerd tijdens de montage), maar luiheid had de overhand en de optie van martin-ger werd gebruikt zoals hij is.
In de routermodus wordt inkomend en uitgaand IP4-verkeer bekeken.
In het bijzonder wordt het volgende eruit gehaald voor weergave op het scherm en het verzamelen van statistieken in een bestand:
- Naam van het apparaat dat verbinding heeft gemaakt met SoftAP ESP32 (DHCP-pakketten)
- URL van DNS-verzoeken (UDP-poort 53) van een apparaat dat is aangesloten op SoftAP ESP32.
Bovendien kunt u verkeersregistratie naar een PCAP-bestand inschakelen.
Deze modus is bijvoorbeeld erg handig om te begrijpen wat uw telefoon naar het netwerk stuurt en waar deze naartoe gaat.
U kunt andere manieren bedenken om deze modus te gebruiken, rekening houdend met de mogelijkheid om software-inkomend en uitgaand SoftAP ESP32-verkeer volledig te controleren op netwerkinterfaceniveau: Ehernet-header (destMAC[6]+srcMAC[6]+type[2]) + laadvermogen (IP4, IP6, DCHP, etc. type).
In principe kan de ESP32 redelijk goed overweg met de WiFi->WiFi-routerfunctie, waarbij hij zonder vertraging door normaal verkeer gaat. Subjectief gezien zijn vertragingen in een telefoon die is aangesloten via een router op een ESP32 niet merkbaar.
Helaas heeft de Espressif API niet de mogelijkheid om een filter in te stellen voor MAC die is aangesloten op SoftAP EPS32. In plaats daarvan wordt voorgesteld om “vaarwel” (esp_wifi_deauth_sta) te zeggen tegen reeds aangesloten STA's die “niet gewenst” zijn.
Filteren op MAC voor verbonden STA's moest worden gedaan via de esp_wifi_deauth_sta() -aanroep
Concluderend
Hoewel ik niets nieuws heb bedacht in het kader van het werken met ESP32, zal het resultaat (broncode) misschien voor iemand interessant zijn.
Ik zou willen opmerken dat de code uitsluitend voor educatieve doeleinden is geschreven. Voor het ‘hacken’ etc. is het bewust niet erg handig gemaakt.
Ik heb geen printplaat gemaakt omdat het 1.5-2 uur duurde om de afgewerkte sjaals met draad te solderen.
En als u dat doet, moet u het niet uit kant-en-klare planken samenstellen, maar uit afzonderlijke componenten. Dan zullen de afmetingen nog kleiner zijn.
Bron: www.habr.com