Het idee om een zakinstrument te maken voor het analyseren van WiFi-netwerken werd ingegeven door .
Bedankt voor het idee. Ik had gewoon niks te doen.
Al het werk is hobbymatig gedaan, met als doel plezier te hebben en mijn kennis op het gebied van netwerktechnologie te vergroten. Langzaam, 1..4 uur per week, sinds begin dit jaar.
Ik heb geen praktisch gebruik gepland. Dat wil zeggen, het is GEEN hackerstool.
Momenteel werken alle geplande functionaliteiten. Alle bronnen zijn volledig klaar voor montage. Er zijn ook montage-instructies, enz. In deze notitie zal ik de informatie op GitHub niet herhalen. Ik zal alleen vertellen wat ik nodig acht om apart te beschrijven.
Mijn mening over de "universele tool" en de reden om voor ESP32 te kiezen
Ik beweer niet de waarheid. Iedereen heeft zijn eigen mening. Ik zal proberen mijn hardwarekeuze te rechtvaardigen.
combinatie van gebruiksscenario's Linux (oorspronkelijk Raspberry Pi) + "randapparatuur" in de vorm van een controller (STM32) + CC1110 (8051-kern) en het plan om er alles in te proppen wat mogelijk is (125 kHz, NFC, 433 MHz, USB, iButton, Bluetooth, ?) leek me niet geschikt. Echter, Het lijkt erop dat het privé en gesloten blijft (flipper-zero github "Deze organisatie heeft geen openbare opslagplaatsen.") en dat het de kant opgaat van niet erg gangbare hardware.
Misschien heb ik het mis, en in de toekomst zullen de auteurs de softwarebronnen openbaar maken. Maar zo niet, dan zou ik zulke hardware niet kopen zonder de bronnen.
Mijn eisen voor het "gereedschap"
De doos moet klein zijn (hoe kleiner hoe beter).
daarom:
- Een ingebouwde batterij is niet nodig. Met een stroomsterkte van > 100 mA bij gebruik van wifi zal de ingebouwde batterij ofwel groot zijn ofwel niet lang meegaan. Laat de "box" daarom van stroom voorzien door een standaard powerbank. Ik heb sowieso altijd een powerbank in mijn zak/auto.
- Blijf binnen de "doos". Linux met gereedschap, geschreven gedurende vele jaren in alle talen Met een klein scherm en een beperkt aantal bedieningsknoppen heeft het geen zin. De resultaten kunnen worden bekeken/bewerkt op een normale laptop met een volledig toetsenbord en scherm.
- Componenten moeten gemakkelijk toegankelijk en algemeen bekend zijn (beschikbare SDK, veel voorbeelden en documentatie).
Voor mij was de keuze dus duidelijk: ESP32.
Voor alle taken die in het artikel worden genoemd en die mij tot actie hebben aangezet, zijn de mogelijkheden van de ESP32 ruim voldoende. Hoewel ik in de meeste gevallen het volgende wil doen:
- Experimenteer met Bluetooth.
- Experimenteer met het 433 MHz-bereik met de eenvoudigste hardware (alleen amplitudemodulatie, wat voor praktische doeleinden voldoende is).
Een vlieg in de zalf voor ESP32
- SDK (IDF) ESP32 is een beetje onhandig.
- Een deel van de functionaliteit (bijvoorbeeld de WiFi-stack) wordt geleverd zonder broncode in de vorm van gecompileerde statische bibliotheken.
- Het 5 GHz-bereik wordt niet ondersteund en er zijn enkele beperkingen en onhandigheden bij het werken met WiFi.
Maar de prijs/grootte compenseert deze tekortkomingen ruimschoots.
Belangrijkste functionaliteit van de software
Ik zal kort de functionaliteit en mijn mening over... beschrijven.
Instellingen beheren en bestanden uploaden vanaf SD
Alle externe besturing verloopt via een eenvoudige webpagina, die in een apart menu-item wordt geopend. ESP32 start in de WiFi AP-modus en genereert een pagina op een vast IP-adres.
Hoewel de ESP32-cores behoorlijk snel zijn, zijn, zoals experimenten hebben aangetoond, de gelijktijdige werking van de ingebouwde webservice en bijvoorbeeld de routermodus niet erg compatibel. Er is dus geen dynamische controle en in alle andere modi is de pagina niet beschikbaar.
Bovendien is dynamische controle niet nodig voor onderzoeksdoeleinden.
Bakenpakkettenmodus
De spelmodi zijn banaal en niet erg interessant. Ze zijn gemaakt "omdat het kan". Voor de show.
Voorbeelden vindt u in de officiële Espressif-voorbeelden.
AP-lijstscanmodus.
Eigenlijk kan elke smartphone dit.
In deze modus wordt de AP-lijst opgeslagen.
Beacon-spammer.
ESP32 start als een AP met een verborgen SSID en een willekeurige MAC en begint met het verzenden van [beacon frame] naar een vooraf gemaakte lijst met SSID's (handmatig gemaakt of eerder verkregen door het scannen van de AP-lijst)
WiFi-pakket sniffing-modus
De ontwikkelaars van Espressif hebben de mogelijkheid toegevoegd voor applicatiesoftware om alle wifi-pakketten die "in de lucht vliegen" te ontvangen via een callbackfunctie. Eigenlijk niet allemaal, aangezien je de modus slechts voor één vast kanaal kunt instellen.
Er gelden zeer strikte tijdsbeperkingen voor de verwerking van callback-functieaanroepen. Als dit geen problemen oplevert voor de eenvoudige statistiekverzamelingsmodus, moesten we voor de PCAP-bestandsregistratiemodus op de SD-kaart sleutelen door de registratie te organiseren via een wachtrij in het geheugen en semaforen. Hierbij moesten we rekening houden met het feit dat het proces dat de callback aanroept op één core draait en het proces dat de registratie naar de SD-kaart uitvoert op een andere.
Bij “ruisige ethergolven” gaan sommige pakketten verloren (er is geen ruimte in de wachtrij en ze worden weggegooid), maar bij de typische “ethergolven” van een appartement in de avond (5..7 AP’s binnen zicht) wordt de opname in PCAP voltooid zonder pakketverlies.
Bovendien is er voor het bewaken en vastleggen van PCAP een filtermodus op basis van de MAC-lijst in pakketheaders.
Je kunt bijvoorbeeld iemands uiterlijk in een club/café volgen voordat diegene binnenkomt of in je gezichtsveld verschijnt. Weinig mensen schakelen wifi en automatische verbindingen met bekende AP's uit. (Ik doe dat nu wel.)
Het bekijken van opgenomen verkeer in Wireshark is leerzaam en interessant voor het begrijpen van kaarten, het werkt allemaal.
Werkingsmodus met deauth-pakketten
Standaard is het verzenden van deze pakketten verboden in de libnet80211.a-bibliotheek, die zonder bronnen wordt geleverd. Maar dit is eenvoudig op te lossen door een paar bytes aan te passen. In eerste instantie twijfelde ik of het de moeite waard was om de patch te posten. Maar nadat ik verschillende sites had bezocht met de scanmodus voor het verzenden van bronnen [deauthenticatieframe] ingeschakeld, dacht ik: "wat is er in vredesnaam aan de hand?" Vooral omdat het verzenden van deze pakketten niet is afgesloten in esp8266 en er assembly's op GitHub voor esp8266 beschikbaar zijn.
Op veel plaatsen (ik zeg niet waar) wordt deze methode gebruikt om ongewenste AP's te onderdrukken. En dit zijn geen "hooligans"...
En ik was nog steeds verbaasd dat mijn internetdistributie via mijn telefoon soms niet werkt…
De manier waarop het aantal en de RSSI van dergelijke pakketten worden bijgehouden, is erg handig om te begrijpen ‘waar AP’s niet geliefd zijn’.
Routermodus
Deze functie is waarschijnlijk het interessantst om te verkennen.
ESP32 ondersteunt gelijktijdige werking in STA- en SoftAP-modus en kan daarom worden gebruikt voor de implementatie van een klassieke NAT-router.
Ter ondersteuning van de netwerkstack gebruikt Espressif een fork (met vrijwel geen wijzigingen) van de lwip-bibliotheek.
Maar standaard is in de standaardassembly, in de esp-lwip-bibliotheek, doorsturen tussen netif-interfaces 'ap' (SoftAP) en 'st' (STA) niet voorzien.
Natuurlijk is het mogelijk om het zonder NAT te doen, maar er is een probleem met de gelijktijdige aansluiting van twee of meer STA's op de interface 'ap' en de synchronisatie van IP-adressen van de netwerkinterface 'st' naar 'ap'. De moeite is het dus niet waard en het is makkelijker via NAT.
Bovendien is er een fork esp-lwip van marting-ger, die een eenvoudige implementatie van NAT voor IP4 toevoegt.
Hoewel mijn handen jeukten om het puur cosmetisch opnieuw te maken (wat naar mijn mening makkelijker zou zijn geweest zonder een forkproject, maar via LWIPHOOK functies die tijdens de assemblage zijn gedefinieerd), maar luiheid won het en de versie van marting-ger wordt zoals die is gebruikt.
In de routermodus wordt het binnenkomende en uitgaande IP4-verkeer bekeken.
In het bijzonder worden de volgende gegevens eruit gehaald om ze op het scherm weer te geven en om statistieken in een bestand te verzamelen:
- Naam van het apparaat dat verbinding heeft gemaakt met SoftAP ESP32 (DHCP-pakketten)
- URL van DNS-aanvragen (UDP-poort 53) van het ESP32-apparaat dat is verbonden met SoftAP.
Bovendien kunt u verkeersregistratie inschakelen in een PCAP-bestand.
Deze modus is bijvoorbeeld erg handig om te begrijpen wat uw telefoon naar het netwerk stuurt en waar het naartoe gaat.
U kunt ook denken aan andere manieren om deze modus te gebruiken, gegeven de mogelijkheid om het inkomende en uitgaande verkeer van de SoftAP ESP32 volledig te controleren op het niveau van de netwerkinterface: Ethernet-header (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP, enz. type).
In principe kan de ESP32 prima overweg met de wifi->wifi-routerfunctie en voert hij het gebruikelijke verkeer zonder noemenswaardige vertragingen door. Subjectief gezien zijn vertragingen in de telefoonverbinding via de router op de ESP32 niet merkbaar.
Helaas biedt de Espressif API geen mogelijkheid om een filter in te stellen op basis van MAC-adressen die verbonden zijn met de EPS32 SoftAP. In plaats daarvan wordt voorgesteld om "vaarwel" (esp_wifi_deauth_sta) te zeggen tegen reeds verbonden STA's die "niet wenselijk" zijn.
MAC-filtering voor aangesloten STA's moest worden gedaan via een aanroep van esp_wifi_deauth_sta()
Concluderend
Hoewel ik niets nieuws heb bedacht wat betreft het werken met ESP32, vindt iemand het resultaat (de broncode) misschien interessant.
Ik wil benadrukken dat de code uitsluitend voor educatieve doeleinden is geschreven. Hij is specifiek ontworpen om niet erg geschikt te zijn voor "hacken" en dergelijke.
Ik heb geen printplaat gemaakt, omdat het 1.5 tot 2 uur duurde om de afgewerkte platen met draad te solderen.
En als je dat doet, moet je het niet uit kant-en-klare platen samenstellen, maar uit losse componenten. Dan worden de afmetingen nog kleiner.
Bron: www.habr.com
