Det, der gav mig ideen til at lave et lommeværktøj til at analysere WiFi-netværk, var .
Tak til dem for ideen. Jeg havde bare intet at lave.
Alt arbejde blev udført som en del af en hobby med det formål at have det sjovt og udvide min viden inden for netværksteknologier. Langsomt, 1..4 timer om ugen, siden begyndelsen af dette år.
Jeg havde ikke planlagt nogen praktisk brug. De der. Dette er IKKE et hackers værktøj.
I øjeblikket fungerer al planlagt funktionalitet. Alle kilder, fuldstændig klar til montering, . Der er også monteringsvejledning osv. I denne note vil jeg ikke duplikere oplysningerne, der er lagt ud på github. Jeg vil kun fortælle dig, hvad jeg anser for nødvendigt at beskrive separat.
Min mening om det "universelle værktøj" og grunden til at vælge ESP32
Jeg hævder ikke at være sandheden. Alle har deres egne. Jeg vil forsøge at begrunde mit valg af hardware.
brugen af en kombination af Linux (oprindeligt Raspberry Pi) + "periferi" i form af en controller (STM32) + CC1110 (8051 kerne) og planen om at proppe alt muligt derind (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) virkede ikke egnet til mig. Imidlertid, Det ser ud til, at det vil forblive privat og lukket (flipper-nul github "Denne organisation har ingen offentlige arkiver.") og gik mod ikke særlig almindelig hardware.
Måske tager jeg fejl, og i fremtiden vil forfatterne gøre softwarekilderne offentligt tilgængelige. Men hvis ikke, så ville jeg ikke købe sådan et stykke hardware uden kildekoden.
Mine krav til "værktøjet"
Kassen skal være lille (jo mindre jo bedre).
Derfor:
- Intet indbygget batteri er nødvendigt. Med en strømstyrke > 100 mA, når man arbejder med Wifi, vil det indbyggede batteri enten være stort eller ikke holde længe. Lad derfor "boksen" forsynes med en standard powerbank. Jeg har i hvert fald altid en powerbank i lommen/bilen.
- Hold en Linux "boks" med værktøjer indeni, skrevet over mange år på alle sprog Med en lille skærm og et sparsomt sæt kontrolknapper giver det ingen mening. Resultaterne kan ses/bearbejdes på en normal bærbar computer med fuldt tastatur og skærm.
- Komponenter skal være let tilgængelige og bredt kendte (tilgængelig SDK, mange eksempler og dokumentation).
Som et resultat, for mig, var valget oplagt - ESP32.
Til alle de opgaver, der er nævnt i artiklen, der fik mig til at handle, er ESP32'ens egenskaber ganske tilstrækkelige. Selvom det mest jeg stadig gerne vil gøre er:
- Leg med Bluetooth.
- Spil med 433mHz-området med den enkleste hardware (kun amplitudemodulation, som er nok til praktiske behov).
Flyv i salven i ESP32
- ESP32 SDK (IDF) er noget klodset.
- Noget af funktionaliteten (WiFi stack, for eksempel) kommer uden kildekode i form af samlede statiske biblioteker.
- 5gHz-båndet er ikke understøttet, og der er nogle begrænsninger og klodsethed i at arbejde med WiFi.
Men prisen/størrelsen kompenserer fuldstændig for disse mangler.
Hovedsoftwarefunktionalitet
Jeg vil kort beskrive funktionaliteten og min mening om...
Håndtering af indstillinger og upload af filer fra SD
Al ekstern kontrol foregår via en simpel webside, der åbnes i et separat menupunkt. ESP32 starter i WiFi AP-tilstand og viser en side på en fast IP-adresse.
Selvom ESP32-kernerne er ret hurtige, som eksperimenter har vist, er den samtidige drift af den indbyggede webservice og for eksempel routertilstanden ikke særlig kompatible. Derfor er der ingen dynamisk kontrol, og siden er ikke tilgængelig i alle andre tilstande.
Desuden er dynamisk kontrol ikke nødvendig til forskningsformål.
Arbejdsmåde med Beacon-pakker
Tilstandene er banale og ikke særlig interessante. Lavet "fordi det er muligt." Til check.
Der er eksempler i de officielle Espressif-eksempler.
AP liste scanningstilstand.
Faktisk kan enhver smartphone gøre dette.
Nå, i denne tilstand vil AP-listen blive gemt.
Beacon spammer.
ESP32 starter som et AP med et skjult SSID og en tilfældig MAC og begynder at sende [beacon frame] i henhold til en forudoprettet liste over SSID'er (oprettet manuelt eller opnået tidligere ved at scanne AP-listen)
WiFi-pakkesniffningstilstand
Espressif-udviklere har tilføjet muligheden for applikationssoftware til at modtage alle WiFi-pakker "flyver i luften" gennem tilbagekaldsfunktionen. Faktisk ikke alle, da du kun kan indstille tilstanden for én fast kanal.
Der er meget strenge tidsbegrænsninger på behandlingen af en tilbagekaldsfunktion. Hvis dette ikke giver problemer for den simple statistikindsamlingstilstand, så for PCAP-filoptagelsestilstanden på SD-kortet var jeg nødt til at pille ved at organisere optagelsen gennem en kø i hukommelsen og semaforer. Under hensyntagen til det særlige ved, at processen, der kalder tilbagekaldet, kører på en kerne, og processen, der skriver til SD i en anden.
Under "støjende luft" går nogle pakker tabt (der er ikke plads i køen og de kasseres), men med en typisk "luft" af en lejlighed om aftenen (5..7 AP'er inden for synlighed), optagelse i PCAP er gennemført uden pakketab.
Derudover er der til PCAP-overvågning og -optagelse en filtreringstilstand baseret på MAC-listen i pakkehovederne.
For eksempel kan du spore en persons udseende i en klub/café, før han overhovedet kommer ind eller dukker op i syne. Få mennesker deaktiverer WiFi og automatiske forbindelser til kendte AP'er. (Jeg slukker nu..)
At se optaget trafik i Wireshark er lærerigt og interessant for at forstå kort - det hele virker.
Tilstand til at arbejde med deauth-pakker
Som standard er det forbudt at sende disse pakker i biblioteket libnet80211.a, som kommer uden kilder. Men det er nemt at rette ved at justere et par stykker. Først tvivlede jeg på, om det var værd at poste patch. Men efter at have gået rundt forskellige steder med deautentificeringsrammescanningstilstanden aktiveret, tænkte jeg: "hvad fanden." Desuden er leveringen af disse pakker ikke lukket i esp8266, og der er samlinger på github til esp8266.
Mange steder (jeg vil ikke sige hvor) bruges undertrykkelse af uønskede AP'er gennem denne metode. Og det er ikke "bøller"...
Og jeg var også overrasket over, at min internetdistribution fra min telefon ikke fungerede nogle steder...
Tilstanden til at spore antallet og RSSI af sådanne pakker er meget nyttig til at forstå "hvor de venstre AP'er ikke kan lide det."
routertilstand
Denne funktion er nok den mest interessante af alle at udforske.
ESP32 understøtter samtidig drift i STA + SoftAP-tilstand. Derfor kan du implementere en klassisk NAT-router på den.
For at understøtte netværksstakken bruger Espressif en gaffel (stort set uændret) af lwip-biblioteket.
Men som standard giver esp-lwip-biblioteket i standardbuilden ikke videresendelse mellem netif-grænsefladerne 'ap' (SoftAP) og 'st' (STA).
Selvfølgelig kan du gøre det uden NAT, men der er et problem med samtidig at forbinde to eller flere STA'er til 'ap'-grænsefladen og synkronisere IP-adresser fra 'st' netværksgrænsefladen til 'ap'. Så vanskelighederne er ikke det værd, og det er nemmere gennem NAT.
Desuden er der en gaffel esp-lwip fra Martin-ger, som tilføjer en simpel implementering af NAT til IP4.
Selvom mine hænder kløede efter at lave det rent kosmetisk (efter min mening var det nemmere uden forgrening af projektet, men gennem LWIPKROG funktioner defineret under montering), men dovenskab sejrede, og muligheden fra Martin-ger bruges som den er.
I routertilstand ses indgående og udgående IP4-trafik.
Især uddrages følgende fra den til visning på skærmen og indsamling af statistik til en fil:
- Navnet på den enhed, der er forbundet til SoftAP ESP32 (DHCP-pakker)
- URL fra DNS-anmodninger (UDP-port 53) fra en enhed tilsluttet SoftAP ESP32.
Derudover kan du aktivere trafikregistrering til en PCAP-fil.
Denne tilstand er meget nyttig, for eksempel til at forstå, for eksempel, hvad din telefon sender til netværket, og hvor den går hen.
Du kan tænke på andre måder at bruge denne tilstand på, idet du tager højde for muligheden for fuldstændig at kontrollere softAP ESP32 indgående og udgående trafik på netværksgrænsefladeniveauet: Ehernet header (destMAC[6]+srcMAC[6]+type[2]) + nyttelast (IP4, IP6, DCHP osv. type).
I princippet klarer ESP32 ganske godt funktionen WiFi->WiFi-router, der passerer gennem normal trafik uden særlige forsinkelser. Subjektivt er forsinkelser i en telefon forbundet via en router på en ESP32 ikke mærkbare.
Desværre har Espressif API ikke mulighed for at indstille et filter til MAC tilsluttet SoftAP EPS32. I stedet foreslås det at sige "farvel" (esp_wifi_deauth_sta) til allerede tilsluttede STA'er, der "ikke ønskes".
Filtrering efter MAC for tilsluttede STA'er skulle udføres gennem esp_wifi_deauth_sta()-kaldet
Afslutningsvis
Selvom jeg ikke fandt på noget nyt inden for rammerne af arbejdet med ESP32, vil resultatet (kildekoden) måske være interessant for nogen.
Jeg vil gerne bemærke, at koden udelukkende er skrevet til uddannelsesformål. Til "hacking" osv. blev det bevidst gjort ikke særlig bekvemt.
Jeg lavede ikke et printkort, fordi det tog 1.5-2 timer at lodde de færdige tørklæder med ledning.
Og hvis du gør det, skal du ikke samle det fra færdige brædder, men fra individuelle komponenter. Så bliver dimensionerne endnu mindre.
Kilde: www.habr.com