Det som ga meg ideen om å lage et lommeverktøy for å analysere WiFi-nettverk var .
Takk til dem for ideen. Jeg hadde bare ingenting å gjøre.
Alt arbeid ble utført som en del av en hobby med det formål å ha det gøy og utvide min kunnskap innen nettverksteknologi. Sakte, 1..4 timer i uken, siden begynnelsen av dette året.
Jeg planla ingen praktisk bruk. De. Dette er IKKE et hackers verktøy.
For øyeblikket fungerer all planlagt funksjonalitet. Alle kilder, helt klare for montering, . Det er også monteringsinstruksjoner osv. I dette notatet vil jeg ikke duplisere informasjonen som er lagt ut på github. Jeg vil bare fortelle deg det jeg anser som nødvendig å beskrive separat.
Min mening om det "universelle verktøyet" og grunnen til å velge ESP32
Jeg påstår ikke å være sannheten. Alle har sin egen. Jeg skal prøve å begrunne mitt valg av maskinvare.
brukstilfellet av en kombinasjon av Linux (opprinnelig Raspberry Pi) + "periferiutstyr" i form av en kontroller (STM32) + CC1110 (8051 core) og planen om å stappe alt mulig inn der (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) virket ikke passende for meg. Derimot, Det ser ut til at det vil forbli privat og lukket (flipper-null github "Denne organisasjonen har ingen offentlige arkiver.") og gikk mot ikke veldig vanlig maskinvare.
Kanskje jeg tar feil, og i fremtiden vil forfatterne gjøre programvarekildene offentlig tilgjengelige. Men hvis ikke, så ville jeg ikke kjøpt en slik maskinvare uten kildekoden.
Mine krav til "verktøyet"
Boksen skal være liten (jo mindre jo bedre).
derfor:
- Trenger ikke innebygd batteri. Med en strøm > 100 mA når du jobber med Wifi, vil det innebygde batteriet enten være stort eller ikke vare lenge. La derfor "boksen" drives av en standard strømbank. Uansett, jeg har alltid en powerbank i lommen/bilen.
- Hold en Linux "boks" med verktøy inni, skrevet over mange år på alle språk Med en liten skjerm og et magert sett med kontrollknapper gir det ingen mening. Resultatene kan sees/behandles på en vanlig bærbar PC med fullt tastatur og skjerm.
- Komponenter skal være lett tilgjengelige og allment kjent (tilgjengelig SDK, mange eksempler og dokumentasjon).
Som et resultat, for meg, var valget åpenbart - ESP32.
For alle oppgavene som er oppgitt i artikkelen som fikk meg til å iverksette tiltak, er egenskapene til ESP32 ganske tilstrekkelige. Selv om det meste jeg fortsatt ønsker å gjøre er:
- Lek med Bluetooth.
- Lek deg rundt med 433mHz-området med den enkleste maskinvaren (kun amplitudemodulasjon, som er nok til praktiske behov).
Fly i salven i ESP32
- ESP32 SDK (IDF) er noe klønete.
- Noe av funksjonaliteten (WiFi-stack, for eksempel) kommer uten kildekode i form av sammensatte statiske biblioteker.
- 5gHz-båndet støttes ikke, og det er noen begrensninger og klønete arbeid med WiFi.
Men prisen/størrelsen kompenserer fullstendig for disse manglene.
Hovedprogramvarefunksjonalitet
Jeg vil kort beskrive funksjonaliteten og min mening om...
Administrere innstillinger og laste opp filer fra SD
All ekstern kontroll gjøres gjennom en enkel webside, lansert i et eget menypunkt. ESP32 starter i WiFi AP-modus og viser en side på en fast IP-adresse.
Selv om ESP32-kjernene er ganske raske, som eksperimenter har vist, er den samtidige driften av den innebygde webtjenesten og for eksempel rutermodusen lite kompatible. Derfor er det ingen dynamisk kontroll og siden er ikke tilgjengelig i alle andre moduser.
Dessuten er dynamisk kontroll ikke nødvendig for forskningsformål.
Arbeidsmåte med Beacon-pakker
Modiene er banale og lite interessante. Laget "fordi det er mulig." For sjekk.
Det er eksempler i de offisielle Espressif-eksemplene.
AP liste skannemodus.
Faktisk kan enhver smarttelefon gjøre dette.
Vel, i denne modusen vil AP-listen bli lagret.
Beacon spammer.
ESP32 starter som et AP med en skjult SSID og en tilfeldig MAC og begynner å sende [beacon frame] i henhold til en forhåndsopprettet liste over SSIDer (opprettet manuelt eller hentet tidligere ved å skanne AP-listen)
WiFi-pakkesniffingsmodus
Espressif-utviklere har lagt til muligheten for applikasjonsprogramvare for å motta alle WiFi-pakker som "flyr i luften" gjennom tilbakeringingsfunksjonen. Faktisk ikke alle, siden du bare kan stille inn modus for én fast kanal.
Svært strenge tidsbegrensninger er pålagt behandling av en tilbakeringingsfunksjon. Hvis dette ikke forårsaker problemer for den enkle statistikkinnsamlingsmodusen, måtte jeg for PCAP-filopptaksmodusen på SD-kortet tukle, organisere opptaket gjennom en kø i minnet og semaforer. Tatt i betraktning det særegne at prosessen som kaller tilbakeringingen kjører på en kjerne, og prosessen som skriver til SD i en annen.
Under "støyende luft" går noen pakker tapt (det er ikke plass i køen og de kastes), men med en typisk "luft" av en leilighet om kvelden (5..7 APs innenfor synlighet), opptak i PCAP fullføres uten pakketap.
I tillegg, for PCAP-overvåking og opptak, er det en filtreringsmodus basert på MAC-listen i pakkehodene.
Du kan for eksempel spore utseendet til en person på en klubb/kafé før han i det hele tatt kommer inn eller dukker opp i sikte. Få mennesker deaktiverer WiFi og automatiske tilkoblinger til kjente AP-er. (Jeg slår den av nå..)
Å se registrert trafikk i Wireshark er lærerikt og interessant for å forstå kart – alt fungerer.
Modus for å jobbe med deauth-pakker
Som standard er det forbudt å sende disse pakkene i biblioteket libnet80211.a, som kommer uten kilder. Men det er enkelt å fikse ved å justere et par biter. Først tvilte jeg på om det var verdt å legge ut patch. Men etter å ha gått rundt forskjellige steder med skanningsmodus for avautentiseringsramme slått på, tenkte jeg: "hva i helvete." Dessuten, i esp8266 er ikke leveringen av disse pakkene lukket, og det er sammenstillinger på github for esp8266.
Mange steder (jeg vil ikke si hvor) brukes undertrykkelse av uønskede AP-er gjennom denne metoden. Og dette er ikke "mobbere"...
Og jeg ble også overrasket over at internettdistribusjonen min fra telefonen min ikke fungerte noen steder...
Modusen for å spore antall og RSSI til slike pakker er veldig nyttig for å forstå "hvor venstre AP-er ikke liker det."
rutermodus
Denne funksjonen er sannsynligvis den mest interessante av alle å utforske.
ESP32 støtter samtidig drift i STA + SoftAP-modus. Derfor kan du implementere en klassisk NAT-ruter på den.
For å støtte nettverksstabelen bruker Espressif en gaffel (nesten uendret) av lwip-biblioteket.
Men som standard, i standardbyggingen, gir ikke esp-lwip-biblioteket videresending mellom netif-grensesnittene 'ap' (SoftAP) og 'st' (STA).
Selvfølgelig kan du gjøre det uten NAT, men det er et problem med å koble to eller flere STA-er til 'ap'-grensesnittet samtidig og synkronisere IP-adresser fra 'st'-nettverksgrensesnittet til 'ap'. Så vanskelighetene er ikke verdt det, og det er lettere gjennom NAT.
Dessuten er det en gaffel esp-lwip fra Martin-ger, som legger til en enkel implementering av NAT for IP4.
Selv om hendene mine kløet etter å gjenskape det rent kosmetisk (etter min mening var det lettere uten forgrening av prosjektet, men gjennom LWIPHOOK funksjoner definert under montering), men latskap rådde og alternativet fra Martin-ger brukes som det er.
I rutermodus vises innkommende og utgående IP4-trafikk.
Spesielt er følgende trukket ut fra den for visning på skjermen og innsamling av statistikk til en fil:
- Navn på enheten som koblet til SoftAP ESP32 (DHCP-pakker)
- URL fra DNS-forespørsler (UDP-port 53) fra en enhet koblet til SoftAP ESP32.
I tillegg kan du aktivere trafikkregistrering til en PCAP-fil.
Denne modusen er veldig nyttig, for eksempel for å forstå for eksempel hva telefonen sender til nettverket og hvor den går.
Du kan tenke på andre måter å bruke denne modusen på, med tanke på muligheten til å fullstendig kontrollere softAP ESP32 innkommende og utgående trafikk på nettverksgrensesnittnivået: Ehernet header (destMAC[6]+srcMAC[6]+type[2]) + nyttelast (IP4, IP6, DCHP, etc. type).
I prinsippet takler ESP32 ganske bra funksjonen WiFi->WiFi-ruter, og passerer gjennom normal trafikk uten spesielle forsinkelser. Subjektivt er forsinkelser i en telefon tilkoblet via en ruter på en ESP32 ikke merkbare.
Dessverre har ikke Espressif API muligheten til å sette et filter for MAC koblet til SoftAP EPS32. I stedet foreslås det å si "farvel" (esp_wifi_deauth_sta) til allerede tilkoblede STA-er som er "ikke ønsket".
Filtrering etter MAC for tilkoblede STA-er måtte gjøres gjennom esp_wifi_deauth_sta()-kallet
i konklusjonen
Selv om jeg ikke kom på noe nytt innenfor rammen av å jobbe med ESP32, vil kanskje resultatet (kildekoden) være interessant for noen.
Jeg vil merke meg at koden ble skrevet utelukkende for pedagogiske formål. For "hacking" osv., ble det bevisst gjort lite praktisk.
Jeg lagde ikke et kretskort fordi det tok 1.5-2 timer å lodde de ferdige skjerfene med ledning.
Og hvis du gjør det, må du ikke montere det fra ferdige brett, men fra individuelle komponenter. Da blir dimensjonene enda mindre.
Kilde: www.habr.com