Spill med Wifi på ESP32

Idéen om at lave et lommetool til analyse af WiFi-netværk blev inspireret af denne artikkelen..

Tak til dem for idéen. Jeg havde faktisk ikke noget at lave.

Alt arbejdet er udført som et hobbyprojekt med det formål at få glæde og udvide mine viden om netværksteknologier. Uden hast, 1 til 4 timer om ugen, siden begyndelsen af året.
Jeg havde ikke planlagt anvendelse til praktiske formål. Dvs. det er IKKE et værktøj til hackere.

På nuværende tidspunkt fungerer al den planlagte funktionalitet. Alle kildefiler, helt klar til kompilering, er lagt ud her. Der er også en vejledning til opsætning osv. I denne note vil jeg ikke duplikere oplysningerne, der er lagt ud på GitHub. Jeg vil kun omtale det, jeg anser for nødvendigt at beskrive separat.

Min mening om "det universelle værktøj" og grunden til valget af ESP32

Jeg gør ikke krav på sandheden. Denne er forskellig for alle. Jeg vil forsøge at begrunde mit valg af "hardware".

Det foreslåede i artiklen kombinationen af Linux (opprindeligt Raspberry Pi) + "periferi" i form af controller (STM32) + CC1110 (8051-kerne) og planen om at presse alt muligt ind (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) virkede ikke passende for mig. Men til gengæld, det projekt ser ud til at forblive privat og lukket (flipper-zero github "Denne organisation har ingen offentlige repository.") og gik i retning af ikke så almindelig hardware.

Måske tager jeg fejl, og i fremtiden vil forfatterne lægge kildekoden ud til offentligheden. Men hvis ikke, så ville jeg ikke købe sådan en hardware uden kildekoder.

Mine krav til "værktøjet"

Boksen skal være lille (jo mindre, jo bedre).

Derfor:

• Indbygget batteri er ikke nødvendigt. Ved strømstyrker > 100 mA, når man arbejder med Wifi, vil et indbygget batteri enten være stort eller have en kort levetid. Så lad "boksen" køre på en standard power bank. Jeg har altid en power bank liggende i lommen/bilen.
• At have Linux med værktøjer indeni "boksen", skrevet i løbet af mange år på alle sprog giver ikke mening, når der kun er en lille skærm og et begrænset antal knapper. Resultaterne kan ses/behandles på en normal laptop med et fuldt tastatur og skærm.
• Komponenterne skal være let tilgængelige og velkendte (tilgængelig SDK, mange eksempler og dokumentation).

Som resultat var valget for mig klart — ESP32.

For all the tasks mentioned in the article that prompted my actions, the capabilities of the ESP32 are more than sufficient. Although the maximum I want to do now is:

• Play around with Bluetooth.
• Experiment with the 433mHz range using basic hardware (just amplitude modulation, which is sufficient for practical needs).

A fly in the ointment with the ESP32

• The SDK (IDF) for ESP32 is somewhat clunky.
• Some functionality (such as the WiFi stack) comes without source code, in the form of precompiled static libraries.
• The 5GHz range is not supported, and there are some limitations and quirks regarding WiFi.

But the price/size compensates for these drawbacks.

The main functionality of the software

I will briefly describe the functionality and share my opinion on…

Managing settings and uploading files from SD

All external management is done through a simple web page launched from a separate menu item. The ESP32 starts in WiFi AP mode and delivers the page at a fixed IP address.

Although the ESP32 cores are quite fast, experiments have shown that running the built-in web service simultaneously with, for example, router mode does not integrate well. Hence, there is no dynamic management and the page is not accessible in all other modes.
Moreover, for research purposes, dynamic management is not needed.

Operating mode with Beacon packets

The modes are basic and not very interesting. Made 'just because it is possible'. For the sake of formality.
Examples are available in the official examples by Espressif.

Scanning mode for AP lists.
Actually, any smartphone can do this.
And in this mode, a list of APs will be saved.
Beacon spammer.
The ESP32 starts as an AP with a hidden SSID and a random MAC, and starts sending [beacon frame] from a pre-created list of SSIDs (created manually or obtained previously while scanning the AP list).

WiFi packet sniffing mode

Espressif developers added the ability for application software to receive all WiFi packets 'flying in the air' through a callback function. In reality, not all packets can be captured since it is possible to set the mode to only one fixed channel.

Det er strenge tidsbegrensninger for behandling av callback-funksjoner. Mens dette ikke utgjør et problem for modusen for enkel statistikkinnsamling, måtte det imidlertid gjøres noen tiltak for å organisere opptak til en PCAP-fil på SD-kortet gjennom en minneskqueue og semaforer. Med tanke på det faktum at prosessen som kaller tilbake, kjører på én kjerne, mens prosessen som utfører opptak på SD, kjører på en annen.

Ved «støyende signal» går noen pakker tapt (det er ikke plass i køen, så de blir avvist), men under typiske «signalforsyninger» i leiligheter på kvelden (5-7 AP i sikte) blir opptaket i PCAP fullført uten tap av pakker.

I tillegg er det en filtreringsmodus for overvåkning og opptak av PCAP basert på en liste over MAC-adresser i pakkens overskrifter.

For eksempel kan man spore en persons ankomst til en klubb eller kafe før de faktisk har gått inn eller blitt synlig. Få folk slår av WiFi og automatisk tilkobling til kjente AP. (Jeg slår det nå av...)

Å se gjennom opptatt trafikk i Wireshark er informativt og interessant for å forstå hvordan alt dette fungerer.

Modus for arbeid med deauth-pakker

Som standard er sending av disse pakkene forbudt i biblioteket libnet80211.a, som leveres uten kildetekst. Men det er ikke vanskelig å modifisere ved å justere noen få bytes. Først var jeg usikker på om jeg skulle legge ut patchen. Men etter å ha vært flere steder med skannermodus for sending av [deauthentication frame], tenkte jeg: «hvorfor ikke». Særlig siden i esp8266 er sending av disse pakkene ikke stengt, og det finnes bygninger på github for esp8266.

I mange steder (jeg skal ikke si hvor) brukes metoden for å undertrykke uønskede AP. Og dette er ikke «vandalister»...

Og jeg undret meg over at internettdelingen fra telefonen min ikke alltid virket...

Modus for sporing av antall og RSSI for slike pakker er svært nyttig for å forstå «hvor de ikke liker fremmede AP».

Router-modus

Denne funksjonen er sannsynligvis den mest interessante av alle for forskning.

ESP32 støtter samtidig drift i STA + SoftAP-modus. Derfor kan det implementeres som en klassisk NAT-router.

For å støtte nettverksstakken bruker Espressif en fork (praktisk talt uten endringer) av lwip-biblioteket.

Men som standard i standardbygningen, er det ikke lagt til støtte for tunneling mellom netif-grensesnittene ‘ap’ (SoftAP) og ‘st’ (STA) i esp-lwip-biblioteket.

Det er mulig å gjøre det uten NAT, men det oppstår et problem med samtidig tilkobling av to eller flere STA til 'ap'-grensesnittet og synkronisering av IP-adresser fra nettverksgrensesnittet 'st' til 'ap'. Så problemene er ikke verdt innsatsen, og det er enklere å gjøre det via NAT.

Dessuten finnes det en fork av esp-lwip fra martin-ger som har en enkel implementering av NAT for IP4.

Selv om jeg hadde lyst til å gjøre det om kosmetisk (etter min mening, var det enklere uten fork-prosjektet, men via LWIP)HOOK funksjoner, definert under byggingen), men latskapen vant, og versjonen fra martin-ger brukes som den er.

I routemodus kan man se innkommende og utgående IP4-trafikk.

Spesielt trekkes det ut for å vises på skjermen og samle statistikk i en fil:

• Navnet på enheten som er koblet til SoftAP ESP32 (DHCP-pakker)
• URL fra DNS-forespørslene (UDP-port 53) fra enheten som er koblet til SoftAP ESP32.

I tillegg kan man aktivere registrering av trafikk i PCAP-fil.

Denne modusen er veldig nyttig, for eksempel for å forstå hva telefonen din sender til nettet og hvor den går.

Man kan finne på andre bruksmetoder i denne modusen med tanke på muligheten til å styre innkommende og utgående trafikk fra SoftAP ESP32 programmessig på nettverksgrensesnittnivå: Ethernet-header (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP, og andre typer).

I prinsippet håndterer ESP32 WiFi->WiFi-ruteren ganske bra, og lar vanlig trafikk passere uten vesentlige forsinkelser. Subjektivt er forsinkelsene i telefonen, som er koblet til ruteren på ESP32, ikke merkbare.

Dessverre er det ingen mulighet i Espressif API-en til å sette et filter for MAC-adresser som kobles til SoftAP EPS32. I stedet foreslås det å si «farvel» (esp_wifi_deauth_sta) til allerede tilkoblede STA-er som er «uønsket».

Filtrering etter MAC for tilkoblede STA måtte gjøres via kallet esp_wifi_deauth_sta()

Avslutningsvis

Selv om jeg ikke har funnet på noe nytt i forhold til arbeidet med ESP32, kan det hende at noen vil finne resultatet (kildene) interessant.

Jeg vil gjerne påpeke at jeg skrev koden utelukkende for læringsformål. Den ble gjort litt vanskelig for "hacking" og lignende.

Jeg laget ikke et printet kretskort, siden det tok omtrent 1,5-2 timer å lodde ferdige brett sammen med ledninger.

Og hvis du skal lage det, så må du ikke samle det fra ferdige brett, men fra separate komponenter. Da vil størrelsen bli enda mindre.

Kilde: habr.com