🥇Spēles ar Wifi uz ESP32

Domāšana par kabatas rīka izveidi WiFi tīklu analīzei mani iedvesmoja raksts.

Paldies viņiem par ideju. Man tieši nebija ar ko nodarboties.

Visu darbu veicu kā hobiju, ar mērķi gūt baudu un paplašināt savas zināšanas tīklu tehnoloģijā. Lēnāk, no 1 līdz 4 stundām nedēļā, sākot no šī gada sākuma.
Praktisko pielietojumu es neplānoju. T.i., tas NAV rīks hakeriem.

Šobrīd viss iecerētais funkcionalitāte darbojas. Visi avoti, pilnībā gatavi montāžai, ir publicēti šeit. Turpat ir montāžas instrukcija utt. Šajā piezīmē es neatkārtošu informāciju, kas publicēta github, tikai pastāstīšu to, ko uzskatu par nepieciešamu aprakstīt atsevišķi.

Manas domas par "universālo rīku" un iemesls ESP32 izvēlei

Es nepretendēju uz patiesību. Katram tā ir savs. Es centīšos pamatot savu "dzelžus" izvēli.

Ierosinātais rakstā izmantošanas variants Linux (sākotnēji Raspberry Pi) + "perifērijas" kontrolleris (STM32) + CC1110 (8051 kodols) un plāns iebāzt tur visu, ko vien var (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) man nešķita piemērots. Tomēr, šis projekts izskatās paliks privāts un slēgts (flipper-zero github "Šai organizācijai nav publisku krātuves.") un es devos uz mazāk izplatītu dzelzi.

Iespējams, ka es kļūdos, un turpmāk autori publicēs programmatūras avotus atklātā piekļuvē. Bet, ja nē, tad es tādu dzelzi bez avotiem nepirktu.

Manas prasības attiecībā uz "rīku"

Lādītājam jābūt mazam (jo mazāks, jo labāk).

Therefore:

Iebūvēts akumulators nav nepieciešams. Ar strāvu > 100 mA, strādājot ar Wifi, iebūvētais akumulators būs vai nu liels, vai arī tā uzlāde nepietiks ilgi. Tāpēc lai "kastīte" tiek barota no standarta power bank. Man vienmēr ir power bank kabatā / mašīnā.
Iekļaut "kastītē" Linux ar rīkiem, rakstītiem daudzu gadu laikā visās valodās ar mazu ekrānu un ierobežotu vadības pogu komplektu nav jēgas. Rezultātus var apskatīt / apstrādāt arī uz normāla portatīvā datora ar pilnvērtīgu tastatūru un ekrānu.
Komponentiem jābūt viegli pieejamiem un plaši zināmiem (pieejams SDK, daudz piemēru un dokumentācijas).

Tādējādi, man izvēle bija acīmredzama — ESP32.

Visām uzdevumiem, par kuriem tika runāts rakstā, kas mani mudināja rīkoties, ESP32 iespējas ir pietiekamas. Tomēr maksimums, ko es vēlētos izdarīt, ir:

Pavērties ar Bluetooth.
Pavērties ar 433mHz diapazonu ar visvienkāršāko aparatūru (tikai amplitūdas modulācija, kas ir pietiekama praktiskām vajadzībām).

Piliņš darvas ESP32

SDK (IDF) ESP32 ir nedaudz neveiklā.
Daļa funkcionalitātes (piemēram, WiFi stacks) nāk bez avotiem kā saliktas statiskas bibliotēkas.
Nepieciešamās 5gHz diapazona atbalsts nav, un ir dažas ierobežojumi un neveiklības WiFi darbībā.

Tomēr cena/izmēri pilnībā kompensē šos trūkumus.

Pamatsofta funkcionalitāte

Īsi aprakstīšu funkcionalitāti un savu viedokli par…

Iestatījumu pārvaldība un failu augšupielāde no SD

Visa ārējā pārvaldība tiek veikta caur visvienkāršāko tīmekļa lapu, kas tiek palaista atsevišķā izvēlnē. ESP32 startē WiFi AP režīmā un piegādā lapu pa fiksētu IP adresi.

Lai gan ESP32 kodoli ir diezgan ātri, tomēr, kā pierādīja eksperimenti, vienlaicīga iekšējā tīmekļa pakalpojuma darba un, piemēram, maršrutētāja režīma darbība nav pārāk saderīgi. Tāpēc dinamisks pārvaldība nav pieejama, un visos pārējos režīmos lapa nav pieejama.
Jo īpaši, ka pētniecības nolūkiem dinamiskā pārvaldība nav nepieciešama.

Darba režīms ar Beacon pakotnēm

Režīmi ir banāli un ne ļoti interesanti. Tā ir izveidota "jo var". Atzīmēšanai.
Piemēri ir oficiālajos Espressif piemēros.

Režīms skenēšanas saraksti AP.
Īstenībā to spēj darīt jebkurš viedtālrunis.
Nu, un šajā režīmā tiek saglabāts saraksts AP.
Beacon spameris.
ESP32 startē kā AP ar slēptu SSID un nejaušu MAC un sāk sūtīt [beacon frame] pa iepriekš sastādītu SSID sarakstu (sastādītu manuāli vai iegūtu iepriekš skenējot AP sarakstu)

WiFi pakotņu sniffing režīms

Espressif izstrādātāji ir pievienojuši iespēju piemērojamai programmatūrai saņemt caur callback funkciju visus WiFi pakotnes «lidojošās gaisā». Patiesībā ne visas, jo var iestatīt režīmu tikai vienam fiksētam kanālam.

Klausījumu apstrādei attiecībā uz callback funkcijām ir ļoti stingri laika ierobežojumi. Ja parasti statistikas vākšanas režīmā tas nerada problēmas, tad PCAP failu ierakstā uz SD karti bija jāpavada laiks, organizējot ierakstu caur atmiņas rindām un semaforiem. Ņemot vērā, ka process, kas izsauc callback, darbojas uz viena kodola, bet process, kas veic ierakstu uz SD, – uz cita.

Attiecībā uz "trokšņainu gaisu" daži paketi tiek zaudēti (rindā nav vietas un tie tiek izmesti), bet tipiskā "gaisā" dzīvokļa vakaros (5..7 AP redzamības laukā) ieraksts PCAP tiek veikts bez paketes zuduma.

Papildus, PCAP uzraudzīšanai un ierakstīšanai ir filtrēšanas režīms pēc MAC saraksta paketu virsrakstos.

Piemēram, var izsekot cilvēka parādīšanos klubā/kafejnīcā, pirms viņš pat ir iegājis vai parādījies redzes laukā. Maz cilvēku izslēdz WiFi un automātiskās savienojumus ar zināmiem AP. (Es tagad izslēdz..)

Apskatīt ierakstīto trafiku Wireshark ir izglītojoši un interesanti, lai saprastu, kā visa šī sistēma darbojas.

Darba režīms ar deauth paketi

Kā noklusējums, šo paketi nosūtīšana ir aizliegta bibliotēkā libnet80211.a, kas nāk bez avota kodiem. Bet tas nav grūti salabot, koriģējot pāris baitus. Sākumā es šaubījos, vai ir vērts publicēt patch. Bet, pārvietojoties pa dažādām vietām, kur bija ieslēgts avotu skenēšanas režīms [deauthentication frame], domāju: "kādēļ gan ne". Turklāt esp8266 paketes nosūtīšana nav bloķēta, un ir kompilācijas uz github priekš esp8266.

Daudzās vietās (negribu teikt kur) tiek izmantota nevēlamu AP apspiešana šādā veidā. Un tas nav "huligāni"...

Un es vēl brīnījos, kāpēc man vietām interneta koplietošana no telefona nedarbojas...

Režīms, lai izsekotu šādu paketi skaitu un RSSI, ir ļoti noderīgs, lai saprastu, "kur nepatīk kreisās AP".

Router režīms

Šī funkcija, iespējams, ir visinteresantākā no visām pētniecībai.

ESP32 atbalsta vienlaicīgu darbību STA + SoftAP režīmā. Tāpēc uz tā var realizēt klasisku NAT maršrutētāju.

Lai atbalstītu tīkla steku, Espressif izmanto fork (praktiski bez izmaiņām) bibliotēku lwip.

Tomēr, kā noklusējums, standarta būvniecībā bibliotēkā esp-lwip starp netif interfeisiem 'ap' (SoftAP) un 'st' (STA) nav paredzēta pārsūtīšana.

Protams, to var izdarīt arī bez NAT, taču rodas problēmas ar vairāku STA vienlaicīgu savienošanu ar ‘ap’ interfeisu un IP adresu sinhronizāciju no ‘st’ tīkla interfeisa uz ‘ap’. Tāpēc grūtības nav tā vērtas un vienkāršāk ir izmantot NAT.

Ņemot vērā to, ka pastāv martin-ger izstrādātais ESP-LWIP forks, kurā ir iekļauta vienkārša NAT realizācija IP4.

Lai gan man bija vēlme to padarīt tikai kosmētiski (manuprāt, bija vieglāk bez fork projekta, bet gan caur LWIP),HOOK funkcijām, kuras nosaka kompilācijas laikā), taču slinkums uzvarēja un martin-ger versija tiek izmantota tā, kā ir.

Maršrutētāja režīmā tiek uzraudzīta ienākošā un izejošā IP4 satiksme.

Jo īpaši no tā tiek izvilkts, lai parādītu uz ekrāna un vāktu statistiku failā:

Ierīces nosaukums, kas pieslēdzās SoftAP ESP32 (DHCP paketes)
URL no DNS pieprasījumiem (UDP ports 53) no ierīces, kas pieslēgta SoftAP ESP32.

Papildus var iespējot satiksmes ierakstīšanu PCAP failā.

Šis režīms ir ļoti noderīgs, piemēram, lai saprastu, ko jūsu telefons sūta tīklā un uz kurieni tam dodas.

Var izdomāt arī citus veidus, kā izmantot šo režīmu, ņemot vērā iespēju pilnībā programmatiski pārvaldīt ienākošo un izejošo satiksmi SoftAP ESP32 tīkla interfeisa līmenī: Ethernet galvene (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP utt. type).

Principā, ESP32 pilnīgi normāli veic WiFi->WiFi maršrutētāja funkciju, pārsūtot parastās satiksmes bez īpašām kavēšanās. Subjektīvi, kavēšanās telefonā, kas pieslēgts caur ESP32 maršrutētāju, nav manāmas.

Diemžēl Espressif API nepiedāvā iespēju iestatīt filtru pēc MAC adresēm, kas pieslēdzas SoftAP ESP32. Tā vietā tiek piedāvāts teikt "uz redzēšanos" (esp_wifi_deauth_sta) jau pieslēgtajām „nevēlamajām” STA.

Filtrēšana pēc MAC adresēm pieslēgtajiem STA tika veikta, izsaucot esp_wifi_deauth_sta()

Noslēgumā

Lai gan es neizdomāju neko jaunu, strādājot ar ESP32, iespējams, ka kādam rezultāts (avota kodi) būs interesants.

Vēlos uzsvērt, ka kodu rakstīju vienīgi izglītojošiem nolūkiem. "Uzbrukuma" un tamlīdzīgu mērķu dēļ tas tika izstrādāts ne pārāk ērti.

Es neizgatavoju drukāto plati, jo ir aizgājuši apmēram 1.5-2 stundas, lai savienotu gatavas plates ar vadu.

Un, ja taisīt, tad nav jāsavāc no gatavām plāksnēm, bet no atsevišķiem komponentiem. Tad izmēri būs vēl mazāki.

Avots: habr.com