Mängud Wifi-lt ESP32-l

Mõte luua taskuanalüüsi tööriist WiFi-võrkude jaoks tuli mulle see artikkel.

Tänan neid idee eest. Mul ei olnud just midagi teha.

Kogu töö tehti hobi raames eesmärgiga saada naudingut ja laiendada oma teadmisi võrgu tehnoloogiate valdkonnas. Aeglaselt, 1..4 tundi nädalas, alates selle aasta algusest.
Ma ei kavatsenud seda praktiliselt kasutada. See EI OLE tööriist häkkeritele.

Praeguseks on kogu ette nähtud funktsionaalsus töökorras. Kõik lähtekoodi failid, täielikult valmis kokkupanekuks, on üles pandud siia. Seal on ka kokku panemise juhised ja muu. Selles märkuses ma ei kordaks teavet, mis on üles pandud githubis. Räägin vaid sellest, mida pean vajalikuks eraldi kirjeldada.

Minu arvamus "üldsusele suunatud tööriistast" ja põhjus, miks valisin ESP32

Ma ei pretendeeri tõele. Igaühel on oma tõde. Püüan põhjendada oma valikut "rauda".

Artiklis pakutud kasutamisvariant Linux (algselt Raspberry Pi) + "perifeeria" nagu kontroller (STM32) + CC1110 (8051 tuum) ja plaan panna sinna kõik, mis võimalik (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) tundus mulle sobimatu. Kui aga, see projekt tundub jäävat eratukseks ja suletuks (flipper-zero github "Sellel organisatsioonil pole avalikke reposid.") ja suundusin vähem levinud rauda poole.

Võib-olla ma ei ole õige, ja edaspidi jagavad autorid tarkvara lähtekoodi avalikkuse ees. Aga kui ei, siis ma ei ostaks sellist rauda ilma lähtekoodita.

Minu nõuded "tööriistale"

Karp peab olema väike (mida väiksem, seda parem).

Seega:

• Integreeritud akufunktsioon ei ole vajalik. Üle 100 mA voolu puhul WiFi kasutamisel on integreeritud aku kas liiga suur või ei pea kaua. Seega las "karp" töötab tavalise power bank'i pealt. Power bank on mul igal juhul taskus/auto taga alati olemas.
• Hoidke "karbi" sees Linux koos tööriistadega, mis on kirjutatud aastate jooksul kõikide keeltega olemasoleva väikese ekraani ja vaese juhtnuppude komplektiga pole mõtet. Tulemusi saab vaadata/töötleda ka normaalsel sülearvutil koos täis klaviatuuriga ja ekraaniga.
• Komponendid peavad olema kergesti kättesaadavad ja laialdaselt tuntud (saadaval SDK, palju näiteid ja dokumentatsiooni).

Kokkuvõttes oli minu jaoks valik ilmselge — ESP32.

Kõikide artiklis esitatud ülesannete jaoks, mis tõukavad mind tegutsema, on ESP32 võimekus täiesti piisav. Kuigi maksimum, mida ma veel teha tahan, on:

• Mängida Bluetoothiga.
• Mängida 433mHz sageduse baasil kõige lihtsama riistvaraga (ainult amplituudimodulatsioon, mis on praktiliste vajalikkuste jaoks piisav).

ESP32-s on üks mustus.

• ESP32 SDK (IDF) on veidi kohmakas.
• Mõnede funktsioonide (näiteks WiFi stack) jaoks ei ole allikaid, vaid need on koostatud staatilisteks teegiteks.
• 5gHz sagedusala ei ole toetatud ja WiFi töö osas on teatud piirangud ja ebamugavused.

Kuid hind/suurused kompenseerivad need puudused täielikult.

Peamine tarkvara funktsionaalsus

Käin lühidalt üle funktsionaalsuse ja oma arvamuse…

Seadete haldamine ja failide laadimine SD-lt

Kõik väline haldus toimub kõige lihtsama veebilehe kaudu, mida käivitatakse eraldi menüüs. ESP32 käivitatakse WiFi AP režiimis ja väljastab lehe statsionaarsel IP-aadressil.

Kuigi ESP32 sisemised tuumad on üsna kiired, näitasid katsed, et sisseehitatud veebiteenuse ja näiteks ruuteri režiimi samaaegne töö ei ühildu hästi. Seetõttu pole dünaamilist haldust ja kõigis teistes režiimides leht ei ole kättesaadav.
Eriti kuna uurimistööde eesmärkidel dünaamiline haldus ei ole vajalik.

Režiim Beacon-pakettidega

Režiimid on banaalsed ja mitte eriti huvitavad. Tehtud „sest saab“. Vormistuseks.
Näidiseid on ametlikes Espressifi näidetes.

AP-de skaneerimise režiim.
Tegelikult oskab seda teha iga nutitelefon.
Ja selles režiimis salvestatakse AP-de nimekiri.
Beacon spämmija.
ESP32 käivitub kui AP peidetud SSID ja juhusliku MAC-iga ning hakkab saatma [beacon frame] eelnevalt loodud SSID-de nimekirjast (kas käsitsi loodud või varasematest skaneerimistest saadud).

WiFi pakettide nuhkimise režiim

Espressifi arendajad lisasid rakendustarkvarale võimaluse saada callback-funktsiooni kaudu kõik WiFi paketid, mis „lendavad õhus“. Tegelikult ei saa kõiki, kuna saavad seadistada režiimi ainult ühel kindlal kanalil.

Callback funktsiooni töötlemisel kehtivad väga ranged ajapiirangud. Kui lihtsa statistika kogumise režiim ei tekita probleeme, siis PCAP-faili salvestamise režiimi korral SD-kaardile tuli vaeva näha, et organiseerida salvestamine mälu kaudu järjekorras ja semaforide abil. Arvestades, et protsess, mis kutsub esile callback'i, töötab ühel tuumal, ja protsess, mis teeb salvestamist SD-le, töötab teisel.

Kuna „mürarikkal õhkul” kaotatakse mõned paketid (järjekorras ei ole ruumi ja need visatakse ära), siis tüüpilise õhku täis korteri (5..7 AP nähtavuses) korral toimub PCAP salvestamine ilma pakettide kadudeta.

Lisaks on PCAP-i jälgimiseks ja salvestamiseks režiim, mis filtreerib MAC nimekirja pakettide pealkirjades.

Näiteks saab jälgida, kuidas keegi edasi tuleb klubisse/kohvikusse, enne kui ta üldse sisse astub või silmapiirile ilmub. Vähemalt keegi ei lülita WiFi-d ja automaatse ühenduse loomist teadlike AP-dega välja. (Mina lülitan nüüd välja..)

Salvestatud liiklust Wiresharkis vaadata on hariv ja huvitav, et mõista, kuidas see kõik töötab.

Töörežiim deauth pakettidega

Vaikimisi on nende pakettide saatmine keelatud raamatukogus libnet80211.a, mis tuleb ilma allikaid. Kuid seda pole keeruline kopeerida, parandades paari baitit. Alguses kahtlesin, kas tasub patchi välja anda. Kuid seigeldes erinevates kohtades skaneerimisseisundis [deauthentication frame], mõtlesin: 'miks mitte'. Eriti kuna esp8266 pakettide saatmine pole suletud ja esp8266-le mõeldud kogumid on githubis.

Paljudes kohtades (ei hakka ütlema kus) kasutatakse soovimatute AP-de summutamiseks seda meetodit. Ja need pole „linnud”...

Ja ma imestasin, miks mul mõnes kohas interneti jagamine telefonist ei toimi...

Pakettide arvu ja RSSI jälgimise režiim on väga kasulik, et mõista, „kus ei armastata vale AP-de”

Routeri režiim

See funktsioon on ilmselt kõige huvitavam kõigist uurimiseks.

ESP32 toetab samaaegset töötamist STA + SoftAP režiimis. Seega saab sellel ellu viia klassikalise NAT ruuteri.

Espressif kasutab võrgu stack'i toetamiseks fork'i (peaaegu ilma muutusteta) lwip raamatukogu.

Kuid vaikimisi, standardkogumites ei ole esp-lwip raamatukogus 'ap' (SoftAP) ja 'st' (STA) vahel võrguühenduste edastamist ette nähtud.

Muidugi on võimalik teha ka ilma NAT, kuid tekib probleem kahe või enama STA samaaegse ühenduse loomisega liidese ‘ap’ kaudu ja IP-aadresside sünkroniseerimisega võrgu liideselt ‘st’ liidesesse ‘ap’. Seega, vaeva ei tasu ja on lihtsam läbi NAT.

Eriti, et on olemas martin-geri fork esp-lwip, milles on lisatud lihtne NAT teostus IP4 jaoks.

Kuigi mul oli tahtmine seda puhtalt kosmeetiliselt ümber teha (minu arvates oli lihtsam ilma fork projektita, vaid läbi LWIP),HOOK kogutud funktsioonide määratlemiseks ehitamisel), kuid laiskus võitis ja martin-geri variant jääb kasutusele.

Ruuterirežiimis on näha sisenevat ja väljuvat IP4 liiklust.

Eelkõige saab sellest ekraanil kuvamiseks ja statistika kogumiseks faili:

• Seade nimega, mis on ühendatud SoftAP ESP32 (DHCP paketid)
• URL DNS-päringutest (UDP port 53) ühendatud SoftAP ESP32 seadmetelt.

Lisaks saab sisse lülitada liikluse salvestamise PCAP faili.

See režiim on väga kasulik, näiteks et mõista, mida teie telefon võrku saadab ja kuhu ta sellega ühendub.

Võib välja mõelda ka teisi viise, kuidas seda režiimi kasutada, arvestades võimalust täielikult programmeerimislikult hallata SoftAP ESP32 sisenemist ja väljumist liiklust võrgu liidese tasemel: Etherneti pealkiri (destMAC[6]+srcMAC[6]+type[2]) + koormus (IP4, IP6, DCHP jne).

Põhimõtteliselt suudab ESP32 normaalselt hakkama saada WiFi->WiFi ruuteri funktsiooniga, edastades tavalist liiklust ilma eriliste viivitusteta. Subjektiivselt ei ole ESP32 ruuteri kaudu ühendatud telefonis viivitusi tunda.

Kahjuks ei ole Espressifi API-s võimalik seada MAC filtrit SoftAP EPS32'ga ühendatud seadmete jaoks. Selle asemel pakutakse lahendada „head aega” (esp_wifi_deauth_sta) juba ühendatud STA-de jaoks, mis on „soovimatud”.

MAC filtreerimine ühendatavate STA-de jaoks tuli teha kutsudes esp_wifi_deauth_sta()

Kokkuvõtteks

Kuigi ma ei leidnud midagi uut ESP32 töö käigus, võiks tulemus (allikakood) huvi pakkuda kellelegi.

Tahaksin märkida, et koodi kirjutati rangelt hariduslikel eesmärkidel. „Murdmiseks” ja muuks tehtud see tahtlikult mitte eriti mugavaks.

Ma ei teinud trükkplatset, sest selleks, et valmis plaate juhtmega joota, kulus 1,5-2 tundi.

Ja kui seda teha, siis ei tuleks kokku panna valmis plaatidest, vaid eraldi komponentidest. Siis oleks mõõtmed veel väiksemad.

Allikas: habr.com