Spel med Wifi på ESP32

Tanken att skapa ett bärbart verktyg för analys av WiFi-nätverk kom till mig article.

Tack till dem för idén. Jag hade precis inget att göra.

Allt arbete har utförts inom ramen för en hobby med syftet att få njutning och utöka mina kunskaper inom nätverksteknik. Saktmodigt, 1 till 4 timmar i veckan, sedan början av det här året.
Jag hade inte planerat något applicerbart bruk. Det är INTE ett verktyg för hackers.

Just nu fungerar all planerad funktionalitet. Alla källfiler, helt redo för kompilering, är uppladdade här. Där finns också instruktioner för kompilering och liknande. I denna anteckning kommer jag inte att duplicera informationen som lagts ut på github. Jag kommer bara att berätta det jag anser är viktigt att beskriva separat.

Min åsikt om "universella verktyg" och orsaken till att jag valde ESP32

Jag gör inga anspråk på sanning. Den är olika för varje person. Jag ska försöka motivera mitt val av "hårdvara".

Förslaget i artikeln att använda kombinationen Linux (ursprungligen Raspberry Pi) + "periferi" i form av en kontroller (STM32) + CC1110 (kärna 8051) och planen att få in allt möjligt (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) verkade inte rätt för mig. Hur som helst, detta projekt verkar förbli privat och stängt (flipper-zero github "Denna organisation har inga offentliga repor"), och jag gick åt ett håll med mindre vanligt hårdvara.

Kanske har jag fel, och i framtiden kommer författarna att publicera källkoden offentligt. Men om inte, så skulle jag inte köpa en sådan hårdvara utan källkod.

Mina krav på "verktyget"

Lådan måste vara liten (ju mindre desto bättre).

Därför:

• Inbyggt batteri behövs inte. Vid strömstyrkor > 100 mA när man arbetar med Wifi, kommer det inbyggda batteriet antingen att vara stort eller inte räcka länge. Så låt "lådan" drivas av en standard power bank. Jag har alltid en power bank liggande i fickan/bilen.
• Att ha Linux med verktyg inuti "lådan", skrivna under många år på alla språk med en liten skärm och ett begränsat antal kontrollknappar finns ingen mening. Resultaten kan ses/bearbetas även på en vanlig bärbar dator med ett komplett tangentbord och skärm.
• Komponenterna måste vara lättillgängliga och allmänt kända (tillgänglig SDK, många exempel och dokumentation).

Som resultat var valet uppenbart för mig — ESP32.

För alla uppgifter som nämns i artikeln som fick mig att agera, räcker ESP32:s möjligheter väl. Det enda jag egentligen vill göra mer är:

• Lek med Bluetooth.
• Lek med 433mHz-bandet med enklast möjliga hårdvara (bara amplitudmodulering, vilket är tillräckligt för praktiska behov).

En skugga på ESP32

• SDK (IDF) för ESP32 är något klumpigt.
• En del funktionalitet (WiFi-stacken, till exempel) finns utan källkoder i form av sammanställda statiska bibliotek.
• 5gHz-bandet stöds inte och det finns vissa begränsningar och brister i WiFi-funktionalitet.

Men priset/avstånden kompenserar fullt ut för dessa brister.

Huvudfunktionen för programvaran

Jag kommer kort beskriva funktionaliteten och min åsikt om…

Hantera inställningar och överföra filer från SD

All extern styrning görs via en enkel webbsida som startas i en separat meny. ESP32 startar i WiFi AP-läge och ger en sida på en fast IP-adress.

Även om ESP32-kärnorna är ganska snabba, visade experiment att samtidig körning av den inbyggda webbservern och exempelvis router-läget inte riktigt fungerar ihop. Därför finns det ingen dynamisk kontroll och i alla andra lägen är sidan inte tillgänglig.
För forskningsändamål behövs inte dynamisk kontroll.

Driftläge med Beacon-paket

Läget är banalt och inte särskilt intressant. Skapat "bara för att det går". För att ha det med.
Exempel finns i de officiella exempel på Espressif.

Läge för att skanna AP-listor.
Detta kan faktiskt vilken smartphone som helst göra.
Och i detta läge sparas listan över AP.
Beacon spammer.
ESP32 startar som AP med dold SSID och slumpmässig MAC och börjar sända [beacon frame] från en förhandsskapad lista med SSID (skapad manuellt eller erhållen tidigare vid skanning av AP-listan)

Läge för sniffning av WiFi-paket

Utvecklarna på Espressif har lagt till möjligheten för applikationer att få alla WiFi-paket "som flyger i luften" via callback-funktion. Egentligen inte alla, eftersom endast ett fast kanal kan väljas.

Det finns mycket strikta tidsgränser för behandling av anrop till callback-funktionen. Om det inte är ett problem för läget för enkel insamling av statistik, så var det nödvändigt att arbeta med inspelning i PCAP-fil på SD-kortet, vilket krävde att inspelningen organiserades genom en kö i minnet och semaforer. Med tanke på att processen som anropar callback-funktionen körs på en kärna, medan processen som utför inspelningen på SD-kortet körs på en annan.

Vid 'bullrig sändning' går vissa paket förlorade (det finns inte plats i kön och de kasseras), men vid typisk 'sändning' i lägenheter på kvällarna (5..7 AP synliga) hinner inspelningen i PCAP utföras utan paketförluster.

Dessutom finns det ett filterläget för övervakning och inspelning av PCAP, baserat på en lista över MAC-adresser i paketens huvuden.

Till exempel kan man spåra en persons ankomst till en klubb/kafé, innan de ens har gått in eller dykt upp i sikte. Det är få som stänger av WiFi och automatiska anslutningar till kända AP. (Jag stänger nu av det...)

Att titta på den inspelade trafiken i Wireshark är både lärorikt och intressant för att förstå hur allt detta fungerar.

Arbetssätt med deauth-paket

Som standard är sändning av dessa paket förbjuden i biblioteket libnet80211.a, som kommer utan källkod. Men det är inte svårt att modifiera genom att justera några byte. I början var jag osäker på om jag skulle publicera patchen. Men efter att ha flackat på olika ställen med aktiverad scanningsläge för sändning av [deauthentication frame], tänkte jag: 'vad fan'. Särskilt eftersom sändning av dessa paket på esp8266 inte är stängd och det finns byggen på github för esp8266.

På väldigt många ställen (jag vill inte säga vart) används detta metod för att förhindra oönskade AP. Och detta är inte 'huliganer'...

Och jag undrade ännu varför min internetdelning med telefonen ibland inte fungerar...

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 man ogillar främmande AP'.

Routerläget

Denna funktion är förmodligen den mest intressanta av alla för forskning.

ESP32 stöder samtidig drift i läge STA + SoftAP. Därför kan man implementera en klassisk NAT-router på den.

För att stödja nätverksstacken använder Espressif en fork (nästan utan förändringar) av biblioteket lwip.

Men i standardbygget av biblioteket esp-lwip finns det ingen vidarekoppling mellan netif-gränssnitten 'ap' (SoftAP) och 'st' (STA).

Det går givetvis att göra utan NAT, men det uppstår ett problem med att ansluta två eller fler STA till gränssnittet 'ap' och synkronisera IP-adresser från nätverksgränssnittet 'st' till 'ap'. Så det är inte värt besväret, och det är enklare med NAT.

Dessutom finns det en fork av esp-lwip från martin-ger där en enkel implementation av NAT för IPv4 har lagts till.

Även om jag hade lust att göra om den rent kosmetiskt (enligt min åsikt var det enklare utan fork-projektet, utan genom LWIP), men latheten vann och varianten från martin-ger används som den är.HOOK funktioner som definieras vid kompilering), men latheten vann och varianten från martin-ger används som den är.

I routerläget övervakas inkommande och utgående IPv4-trafik.

Specifikt extraheras detta för att visas på skärmen och samla statistik i en fil:

• Namn på enheten som har anslutit till SoftAP ESP32 (DHCP-paket)
• URL från DNS-förfrågningar (UDP-port 53) från enheten ansluten till SoftAP ESP32.

Dessutom kan man aktivera inspelning av trafiken i en PCAP-fil.

Detta läge är mycket användbart, till exempel för att förstå vad din telefon skickar till nätverket och var den går.

Man kan komma på andra sätt att använda detta läge med tanke på möjligheten att helt programvarumässigt styra inkommande och utgående trafik för SoftAP ESP32 på nätverksgränssnitts-nivå: Ethernet-header (destMAC[6]+srcMAC[6]+type[2]) + payload (IPv4, IPv6, DHCP och andra typer).

I princip klarar ESP32 av att fungera som en WiFi->WiFi-router, och vidarebefordrar vanlig trafik utan betydande fördröjningar. Subjektivt sett märks det inte några fördröjningar på telefonen som är ansluten via routern till ESP32.

Tyvärr finns det ingen möjlighet i Espressifs API att ställa in filter baserat på MAC-adresser för de som ansluter till SoftAP ESP32. Istället erbjuds man att säga 'hej då' (esp_wifi_deauth_sta) till redan anslutna STA som är 'ödesdigra'.

Filtrering baserat på MAC för anslutna STA fick göras genom anrop av esp_wifi_deauth_sta().

Avslutningsvis

Även om jag inte hittade något nytt i arbetet med ESP32, kan resultatet (källkoden) vara intressant för någon.

Jag skulle vilja påpeka att jag skrev koden enbart i utbildningssyfte. För 'hackande' och liknande gjordes den medvetet inte särskilt användarvänlig.

Jag gjorde ingen tryckt kretskort eftersom det tog 1,5-2 timmar att löda samman färdiga plattor med tråd.

Och om man ska göra det, bör man inte använda färdiga plattor, utan separata komponenter. Då blir måtten ännu mindre.

Källa: habr.com