Det som gav mig idén att göra ett fickverktyg för att analysera WiFi-nätverk var .
Tack till dem för idén. Jag hade bara ingenting att göra.
Allt arbete gjordes som en del av en hobby i syfte att ha roligt och utöka mina kunskaper inom nätverksteknik. Långsamt, 1..4 timmar i veckan, sedan början av detta år.
Jag planerade ingen praktisk användning. De där. Detta är INTE ett hackers verktyg.
För tillfället fungerar all planerad funktionalitet. Alla källor, helt redo för montering, . Det finns också monteringsanvisningar etc. I denna anteckning kommer jag inte att duplicera informationen som lagts ut på github. Jag kommer bara att berätta vad jag anser vara nödvändigt att beskriva separat.
Min åsikt om det "universella verktyget" och anledningen till att jag valde ESP32
Jag påstår inte att jag är sanningen. Alla har sina egna. Jag ska försöka motivera mitt val av hårdvara.
användningsfallet av en kombination av Linux (initialt Raspberry Pi) + "kringutrustning" i form av en kontroller (STM32) + CC1110 (8051 kärna) och planen att stoppa in allt möjligt där (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) verkade inte lämplig för mig. Dock, Det ser ut som att det kommer att förbli privat och stängt (flipper-noll github "Denna organisation har inga offentliga arkiv.") och gick mot inte särskilt vanlig hårdvara.
Jag kanske har fel, och i framtiden kommer författarna att göra programvarukällorna offentligt tillgängliga. Men om inte, då skulle jag inte köpa en sådan hårdvara utan källkoden.
Mina krav på "verktyget"
Lådan ska vara liten (ju mindre desto bättre).
därför:
- Inget inbyggt batteri behövs. Med en ström > 100 mA när man arbetar med Wifi blir det inbyggda batteriet antingen stort eller håller inte länge. Låt därför "lådan" drivas av en vanlig powerbank. Hur som helst så har jag alltid en powerbank i fickan/bilen.
- Håll en Linux "låda" med verktyg inuti, skriven under många år på alla språk Med en liten skärm och en mager uppsättning kontrollknappar är det ingen mening. Resultaten kan ses/bearbetas på en vanlig bärbar dator med fullt tangentbord och skärm.
- Komponenter bör vara lättillgängliga och allmänt kända (tillgänglig SDK, många exempel och dokumentation).
Som ett resultat, för mig, var valet självklart - ESP32.
För alla uppgifter som anges i artikeln som fick mig att vidta åtgärder, är funktionerna hos ESP32 ganska tillräckliga. Även om det mest jag fortfarande vill göra är:
- Lek med Bluetooth.
- Lek med 433mHz-området med den enklaste hårdvaran (endast amplitudmodulering, vilket räcker för praktiska behov).
Gick i glädjebägaren i ESP32
- ESP32 SDK (IDF) är något klumpig.
- En del av funktionaliteten (WiFi-stack till exempel) kommer utan källkod i form av sammansatta statiska bibliotek.
- 5gHz-bandet stöds inte och det finns vissa begränsningar och klumpighet i att arbeta med WiFi.
Men priset/storleken kompenserar helt för dessa brister.
Huvudfunktionalitet i programvaran
Jag kommer kort att beskriva funktionaliteten och min åsikt om...
Hantera inställningar och ladda upp filer från SD
All extern styrning sker via en enkel webbsida, som lanseras i ett separat menyalternativ. ESP32 startar i WiFi AP-läge och visar en sida på en fast IP-adress.
Även om ESP32-kärnorna är ganska snabba, som experiment har visat, är den samtidiga driften av den inbyggda webbtjänsten och till exempel routerläget inte särskilt kompatibla. Därför finns det ingen dynamisk kontroll och sidan är inte tillgänglig i alla andra lägen.
Dessutom behövs inte dynamisk styrning för forskningsändamål.
Arbetssätt med Beacon-paket
Lägena är banala och inte särskilt intressanta. Gjort "för att det är möjligt." För kontroll.
Det finns exempel i de officiella Espressif-exemplen.
AP-lista skanningsläge.
Egentligen kan vilken smartphone som helst göra detta.
Tja, i detta läge kommer AP-listan att sparas.
Beacon-spammare.
ESP32 börjar som en AP med ett dolt SSID och en slumpmässig MAC och börjar skicka [beacon frame] enligt en förskapad lista med SSID (skapad manuellt eller erhållen tidigare genom att skanna AP-listan)
WiFi-paketsniffningsläge
Espressif-utvecklare har lagt till möjligheten för applikationsprogramvara att ta emot alla WiFi-paket som "flyger i luften" genom återuppringningsfunktionen. Egentligen inte alla, eftersom du bara kan ställa in läget för en fast kanal.
Mycket strikta tidsbegränsningar införs för bearbetning av en återuppringningsfunktion. Om detta inte orsakar problem för det enkla statistikinsamlingsläget, så för PCAP-filinspelningsläget på SD-kortet var jag tvungen att mixtra, organisera inspelningen genom en kö i minnet och semaforer. Med hänsyn till egenheten att processen som anropar återuppringningen körs på en kärna, och processen som skriver till SD i en annan.
Under "bullrig luft" försvinner vissa paket (det finns inget utrymme i kön och de slängs), men med en typisk "luft" av en lägenhet på kvällen (5..7 AP:er inom synlighet), inspelning i PCAP slutförs utan paketförlust.
Dessutom, för PCAP-övervakning och inspelning, finns det ett filtreringsläge baserat på MAC-listan i pakethuvuden.
Du kan till exempel spåra en persons utseende på en klubb/café innan han ens går in eller dyker upp i sikte. Få människor inaktiverar WiFi och automatiska anslutningar till kända AP:er. (Jag stänger av den nu..)
Att titta på inspelad trafik i Wireshark är lärorikt och intressant för att förstå kartor – allt fungerar.
Läge för att arbeta med deauth-paket
Som standard är det förbjudet att skicka dessa paket i biblioteket libnet80211.a, som kommer utan källor. Men det är lätt att fixa genom att justera ett par bitar. Först tvivlade jag på om det var värt att lägga upp en patch. Men efter att ha gått runt på olika platser med skanningsläget för avautentiseringsram påslaget tänkte jag: "vad i helvete." Dessutom, i esp8266 är leveransen av dessa paket inte stängd och det finns sammansättningar på github för esp8266.
På många ställen (jag kommer inte att säga var) används undertryckande av oönskade AP:er genom denna metod. Och det här är inte "mobbare"...
Och jag blev också förvånad över att min internetdistribution från min telefon inte fungerade på vissa ställen...
Läget för att spåra antalet och RSSI för sådana paket är mycket användbart för att förstå "var vänster AP:er inte gillar det."
routerläge
Denna funktion är förmodligen den mest intressanta av alla att utforska.
ESP32 stöder samtidig drift i STA + SoftAP-läge. Därför kan du implementera en klassisk NAT-router på den.
För att stödja nätverksstacken använder Espressif en gaffel (nästan oförändrad) av lwip-biblioteket.
Men som standard, i standardbygget, tillhandahåller esp-lwip-biblioteket inte vidarebefordran mellan netif-gränssnitten 'ap' (SoftAP) och 'st' (STA).
Naturligtvis kan du göra det utan NAT, men det finns ett problem med att samtidigt ansluta två eller flera STA till 'ap'-gränssnittet och synkronisera IP-adresser från 'st'-nätverksgränssnittet till 'ap'. Så svårigheterna är inte värda det och det är lättare genom NAT.
Dessutom finns det en gaffel esp-lwip från Martin-ger, som lägger till en enkel implementering av NAT för IP4.
Även om mina händer kliade efter att göra om det rent kosmetiskt (enligt min mening var det lättare utan projektets gaffel, men genom LWIPKROK funktioner definierade under montering), men lathet rådde och alternativet från Martin-ger används som det är.
I routerläge visas inkommande och utgående IP4-trafik.
I synnerhet extraheras följande från den för att visas på skärmen och samla in statistik till en fil:
- Namnet på enheten som anslutit till SoftAP ESP32 (DHCP-paket)
- URL från DNS-förfrågningar (UDP-port 53) från en enhet ansluten till SoftAP ESP32.
Dessutom kan du aktivera trafikregistrering till en PCAP-fil.
Det här läget är väldigt användbart, till exempel för att förstå vad din telefon skickar till nätverket och vart den tar vägen.
Du kan tänka på andra sätt att använda det här läget, med hänsyn till möjligheten att helt kontrollera softAP ESP32 inkommande och utgående trafik på nätverksgränssnittsnivån: Ehernet header (destMAC[6]+srcMAC[6]+type[2]) + nyttolast (typ IP4, IP6, DCHP, etc.).
I princip klarar ESP32 ganska bra med WiFi->WiFi-routerfunktionen, som passerar genom normal trafik utan några speciella förseningar. Subjektivt märks inte förseningar i en telefon ansluten via en router på en ESP32.
Tyvärr har inte Espressif API möjlighet att ställa in ett filter för MAC ansluten till SoftAP EPS32. Istället föreslås det att säga "hejdå" (esp_wifi_deauth_sta) till redan anslutna STA:er som "inte önskas".
Filtrering av MAC för anslutna STA:er måste göras genom anropet esp_wifi_deauth_sta()
Sammanfattningsvis
Även om jag inte kom på något nytt inom ramen för att arbeta med ESP32, kanske resultatet (källkoden) kommer att vara intressant för någon.
Jag skulle vilja notera att koden skrevs enbart för utbildningsändamål. För "hacking" etc. gjordes det medvetet inte särskilt bekvämt.
Jag gjorde inte ett kretskort eftersom det tog 1.5-2 timmar att löda de färdiga halsdukarna med tråd.
Och om du gör det måste du montera det inte från färdiga brädor, utan från enskilda komponenter. Då blir måtten ännu mindre.
Källa: will.com