Jeg fik ideen til at lave et bærbart værktøj til analyse af WiFi-netværk .
Tak til dem for idéen. Jeg havde lige tid til overs.
Hele arbejdet blev udført som et hobbyprojekt med det formål at få glæde og udvide mine viden inden for netværksteknologier. Uden hast, 1 til 4 timer om ugen, siden begyndelsen af året.
Jeg planlagde ikke anvendelse i praksis. Dvs. dette er IKKE et værktøj til hackere.
På nuværende tidspunkt fungerer hele den planlagte funktionalitet. Alle kildekoder er fuldt klargjorte til kompilering, . Der er også en samlingsvejledning osv. Jeg vil ikke gentage informationen, der er lagt op på GitHub. Jeg vil kun fortælle, hvad jeg anser for nødvendigt at beskrive separat.
Min mening om "det universelle værktøj" og grunden til valget af ESP32
Jeg påstår ikke at have sandheden. Den er forskellige for alle. Jeg vil forsøge at begrunde mit valg af "hardware".
kombinationen af Linux (oprindeligt Raspberry Pi) + "periferi" i form af controller (STM32) + CC1110 (8051-kerne) og planen om at presse alle mulige funktioner ind (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) syntes ikke at være passende for mig. Dog, ser ud til at forblive privat og lukket (flipper-zero GitHub "Denne organisation har ingen offentlige repositories.") og jeg er gået i retning af ikke så almindelig hardware.
Måske tager jeg fejl, og i fremtiden vil forfatterne offentliggøre softwarekilderne. Men hvis ikke, ville jeg ikke købe sådan en hardware uden kilderne.
Mine krav til "værktøjet"
Kassen skal være lille (jo mindre, jo bedre).
Derfor:
- Et indbygget batteri er ikke nødvendigt. Ved en strømstyrke > 100 mA under brug med WiFi, vil et indbygget batteri enten være stort, eller det vil ikke holde længe. Så lad "kassen" blive drevet af en standard power bank. Jeg har altid en power bank liggende i lommen/bilen.
- At have Linux med værktøjer inden i "kassen", skrevet over mange år på alle sprog giver ikke mening med en lille skærm og sparsomt antal kontrolknapper. Resultaterne kan ses/behandles på en ordentlig bærbar med et fuldt tastatur og skærm.
- Komponenter skal være let tilgængelige og velkendte (tilgængelig SDK, mange eksempler og dokumentation).
Resultatet for mig var derfor åbenlyst - ESP32.
Til alle opgaver, der er nævnt i artiklen, som fik mig til at handle, er mulighederne for ESP32 helt tilstrækkelige. Selvom det maksimalt, jeg ønsker at gøre, er:
- At lege med Bluetooth.
- At lege med 433mHz-båndet med det simpleste hardware (kun amplitudemodulation, hvilket er tilstrækkeligt til næsten alle behov).
En skefuld tjære i ESP32
- SDK (IDF) til ESP32 er en smule klodset.
- En del af funktionen (WiFi-stakken, for eksempel) kommer uden kildekoder i form af sammenbyggede statiske biblioteker.
- 5GHz-båndet understøttes ikke, og der er nogle begrænsninger og klodsetheder i arbejdet med WiFi.
Men prisen/størrelsen kompenserer helt for disse mangler.
De vigtigste softwarefunktioner
Jeg vil kort beskrive funktionaliteten og mine tanker om…
Håndtering af indstillinger og filoverførsel fra SD
Al ekstern styring er lavet gennem en simpel webside, der startes i en separat menu. ESP32 starter i WiFi AP-tilstand og leverer siden via en fast IP-adresse.
Selvom ESP32-kernene er ret hurtige, har eksperimenter vist, at samtidig drift af den indbyggede webservice og for eksempel router-tilstand ikke fungerer særlig godt sammen. Derfor er der ingen dynamisk styring, og i alle andre tilstande er siden ikke tilgængelig.
Især fordi der ikke er behov for dynamisk styring til forskningsformål.
Driftsmode med Beacon-pakker
Tilstandene er banale og ikke særlig interessante. De er lavet "fordi det kan lade sig gøre". For at have noget dokumenteret.
Eksempler findes i de officielle eksempler fra Espressif.
Tilstand til scanning af AP-lister.
Det kan enhver smartphone faktisk gøre.
I denne tilstand gemmes listen over AP'er.
Beacon spammer.
ESP32 starter som AP med skjult SSID og tilfældigt MAC og begynder at sende [beacon frame] fra en forudbestemt liste af SSID'er (manuelt oprettet eller tidligere indsamlet ved scanning af AP-listen).
WiFi-pakke sniffing tilstand
Udviklerne af Espressif har gjort det muligt for applikationssoftware at modtage alle WiFi-pakker, der "flyver i luften", via en callback-funktion. Faktisk ikke alle, da man kun kan indstille tilstand til én fast kanal.
Der behandling af callback-funktionens opkald er underlagt meget strenge tidsbegrænsninger. Hvis dette ikke er et problem for den enkle statistikindsamlingsmetode, krævede det lidt mere arbejde at organisere optagelsen af PCAP-filen på SD-kortet via et hukommelseskø og semaforer. Dette skal tages i betragtning, da processen, der kalder callback, kører på en kerne, og processen der udfører optagelsen på SD kører på en anden.
Ved en 'støjende antenne' går nogle pakker tabt (der er ikke plads i køen, og de kastes væk), men ved en typisk 'antenne' i lejligheden om aftenen (5..7 AP i synsvidde) lykkes det at optage i PCAP uden pakketab.
Derudover er der en filtreringsmetode for PCAP-optagelse, der anvender en liste over MAC-adresser i pakkeoverskrifterne.
For eksempel kan man spore en persons ankomst i en klub/café, før de overhovedet er trådt ind eller kommet i syne. Kun få slår WiFi og automatisk forbindelse til kendte AP'er fra. (Jeg slår det nu fra...)
At gennemse den optagne trafik i Wireshark er både lærerigt og interessant for at forstå, hvordan dette hele fungerer.
Driftsmode for deauth-pakker
Som standard er sendelse af disse pakker forbudt i biblioteket libnet80211.a, som leveres uden kildekode. Men det er ikke svært at kryptere ved at justere et par bytes. I starten var jeg i tvivl om, hvorvidt jeg skulle offentliggøre patchen. Men efter at have bevæget mig rundt forskellige steder med aktiveret scanning af kilder til at sende [deauthentication frame], tænkte jeg: 'hvorfor ikke'. Desuden er sendelsen af disse pakker ikke lukket i esp8266, og der er builds på github til esp8266.
I mange steder (jeg vil ikke sige hvor) anvendes undertrykkelse af uønskede AP'er ved hjælp af denne metode. Og dette er ikke 'bøller'...
Og jeg undrede mig over, at internetdeling fra min telefon nogle steder ikke virkede...
Funktionen til at spore antallet og RSSI af sådanne pakker er meget nyttig for at forstå 'hvor der ikke er kærlighed til de forkerte AP'er'.
Router-tilstand
Denne funktion er sandsynligvis den mest interessante af alle til forskning.
ESP32 understøtter samtidig drift i STA + SoftAP-tilstand. Derfor kan man implementere en klassisk NAT-router.
For at støtte netværksstakken anvender Espressif en fork (næsten uden ændringer) af lwip-biblioteket.
Men som standard i den standardbuild, er der ikke nogen forwarding mellem netif-interfacene 'ap' (SoftAP) og 'st' (STA) i library esp-lwip.
Det kan selvfølgelig gøres uden NAT, men der opstår et problem med samtidig tilslutning af to eller flere STA'er til 'ap'-interfacet og synkronisering af IP-adresser fra netværksinterfacet 'st' til 'ap'. Så vanskelighederne er ikke værd at tage, og det er nemmere at bruge NAT.
Desuden findes der en fork af esp-lwip fra martin-ger, som har tilføjet en enkel implementering af NAT til IP4.
Selv om jeg havde lyst til at ændre det kosmetisk (jeg mener, det var lettere uden fork-projektet, men gennem LWIP), så vandt dovenskaben, og varianten fra martin-ger bruges som den er.HOOK funktioner, der defineres ved bygning), men dovenskaben vandt, og varianten fra martin-ger bruges som den er.
I router-tilstand kan man se den indgående og udgående IP4-trafik.
Især udtrækkes der information til visning på skærmen og indsamling af statistik til en fil:
- Navnet på enheden, der er tilsluttet SoftAP ESP32 (DHCP-pakker)
- URL'er fra DNS-forespørgsler (UDP port 53) fra enheden tilsluttet SoftAP ESP32.
Derudover kan man aktivere optagelse af trafikken i en PCAP-fil.
Denne tilstand er ret nyttig, for eksempel for at forstå, hvad din telefon sender til netværket og hvor den sender hen.
Man kan finde på andre måder at bruge denne tilstand på, idet man tager i betragtning, at man fuldt ud kan styre indkommende og udgående trafik fra SoftAP ESP32 på netværksinterfaceniveau: Ethernet-header (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP osv. type).
I princippet håndterer ESP32 ganske fint funktionen som WiFi->WiFi-router, og passerer almindelig trafik igennem uden betydelige forsinkelser. Subjektivt er forsinkelserne på telefonen, der forbindes gennem routeren på ESP32, ikke mærkbare.
Desværre er der ikke mulighed for at sætte et filter baseret på MAC-adresser i Espressifs API til tilsluttede STA'er til SoftAP EPS32. I stedet er man nødt til at sige "farvel" (esp_wifi_deauth_sta) til allerede tilsluttede STA'er, der er "uønskede".
MAC-filtrering for tilsluttede STA'er måtte laves gennem kaldet til esp_wifi_deauth_sta()
Afslutningsvis
Selvom jeg ikke fandt på noget nyt i forhold til arbejdet med ESP32, kan resultatet (kildekoden) være interessant for nogen.
Jeg vil gerne understrege, at jeg kun skrev koden af læringsmæssige årsager. Den var ikke lavet for at være praktisk til "hack" osv.
Jeg lavede ikke et printplade, fordi det tog omkring 1.5-2 timer at lodde færdige plader sammen med ledninger.
Og hvis man skulle lave det, så skulle man ikke samle det fra færdige plader, men fra separate komponenter. Så ville dimensionerne også blive endnu mindre.
Kilde: habr.com
