Ideea de a crea un instrument portabil pentru analiza rețelelor WiFi m-a inspirat .
Le mulțumesc pentru idee. Tocmai nu aveam ce face.
Întreaga muncă a fost realizată în cadrul unui hobby, cu scopul de a obține plăcere și de a-mi extinde cunoștințele în domeniul tehnologiilor de rețea. Într-un ritm relaxat, de 1 până la 4 ore pe săptămână, începând de la începutul acestui an.
Nu am planificat utilizarea aplicativă. Adică, acesta NU este un instrument pentru hackeri.
În prezent, întreaga funcționalitate planificată funcționează. Toate sursele, complet pregătite pentru compilare, . Acolo se află și instrucțiunile de asamblare etc. În această notă nu voi reproduce informațiile disponibile pe github. Voi vorbi doar despre ceea ce consider necesar să descriu separat.
Părerea mea despre "instrumentul universal" și motivul alegerii ESP32
Nu pretind că am adevărul. Fiecare are propria părere. Voi încerca să justific alegerea mea de "hardware".
varianta de utilizare a combinației Linux (inițial Raspberry Pi) + „periferice” sub formă de controler (STM32) + CC1110 (nucleu 8051) și planul de a integra tot ce se poate (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) mi s-a părut inadecvat pentru mine. Totuși, pare să rămână privat și închis (flipper-zero github „Această organizație nu are repository-uri publice.”) și m-am îndreptat spre hardware mai puțin răspândit.
Poate că greșesc, și în viitor autorii vor face sursele software disponibile public. Dar dacă nu, nu aș cumpăra un astfel de hardware fără surse.
Cerințele mele pentru "instrument"
Cutia trebuie să fie mică (cu cât mai mică, cu atât mai bine).
Prin urmare:
- Bateria încorporată nu este necesară. La un curent > 100 mA când se lucrează cu Wifi, bateria încorporată va fi fie mare, fie nu va rezista mult. Așa că prefer ca „cutia” să fie alimentată de un power bank standard. La urma urmei, am mereu un power bank în buzunar/mașină.
- Să păstreze în interior „cutiei” Linux cu instrumente, scrise de-a lungul anilor în toate limbile nu are sens având un ecran mic și un set limitat de butoane de control. Rezultatele pot fi vizualizate/procesate și pe un laptop normal cu o tastatură și un ecran complet.
- Componentele trebuie să fie ușor accesibile și bine cunoscute (SDK disponibil, multe exemple și documentație).
Ca urmare, pentru mine, alegerea a fost evidentă - ESP32.
Pentru toate sarcinile menționate în articolul care m-a împins la acțiune, capacitățile ESP32 sunt complet suficiente. Totuși, maximul pe care vreau să-l mai fac este:
- Să experimentez cu Bluetooth.
- Să experimentez cu banda de 433mHz folosind hardware-ul cel mai simplu (doar modularea amplitudinii, suficientă pentru nevoile practice).
Un pic de amărăciune în ESP32
- SDK-ul (IDF) pentru ESP32 este oarecum stângaci.
- O parte din funcționalitate (stiva WiFi, de exemplu) vine fără sursă, sub formă de biblioteci statice compilate.
- Banda de 5gHz nu este suportată și există unele limitări și probleme cu funcționarea WiFi-ului.
Dar prețul/dimensiunile compensează aceste dezavantaje.
Funcționalitatea principală a software-ului
Voi descrie pe scurt funcționalitatea și părerea mea despre…
Gestionarea setărilor și transferul de fișiere de pe SD
Toată gestionarea externă este realizată printr-o pagină Web simplă, care se lansează dintr-o opțiune de meniu separată. ESP32 pornește în modul WiFi AP și oferă pagina la o adresă IP fixă.
Deși nucile ESP32 sunt destul de rapide, așa cum au arătat experimentele, funcționarea simultană a serviciului Web încorporat și, de exemplu, modul router nu se potrivește foarte bine. Prin urmare, nu există gestionare dinamică, iar în celelalte moduri pagina nu este accesibilă.
Cu atât mai mult cu cât, pentru scopuri de cercetare, gestionarea dinamică nu este necesară.
Modul de lucru cu pachete Beacon
Modurile sunt banale și nu foarte interesante. Sunt realizate "pentru că se poate". Pentru a bifa.
Există exemple în exemplele oficiale de la Espressif.
Modul de scanare a listelor AP.
Asta poate face practic orice smartphone.
Și în acest mod, va fi salvată lista AP.
Beacon spammer.
ESP32 pornește ca AP cu SSID ascuns și MAC aleatoriu și începe să trimită [beacon frame] dintr-o listă SSID creată anterior (fie manual, fie obținută anterior prin scanarea listei AP)
Modul de sniffing al pachetelor WiFi
Dezvoltatorii de la Espressif au adăugat posibilitatea aplicației să obțină printr-o funcție callback toate pachetele WiFi „care trec prin aer”. De fapt, nu toate, deoarece se poate seta modul doar pentru un singur canal fix.
Procesul de apelare a funcției callback este supus unor restricții foarte stricte de timp. Dacă pentru modul de colectare simplă a statisticilor aceasta nu reprezintă o problemă, pentru modul de înregistrare a fișierului PCAP pe cardul SD a fost nevoie de ceva muncă, organizând înregistrarea printr-o coadă în memorie și semafoare. Având în vedere caracteristica că procesul care apelează callback-ul rulează pe un nucleu, iar procesul care efectuează înregistrarea pe SD pe altul.
În cazul unui „efect de zgomot”, unele pachete sunt pierdute (nu este loc în coadă și sunt respinse), dar în timpul unui „efect tipic” de apartament seara (5..7 AP în raza de vizibilitate) înregistrarea în PCAP reușește să se efectueze fără pierderi de pachete.
În plus, pentru monitorizarea și înregistrarea PCAP există un mod de filtrare pe baza listei MAC în anteturile pachetelor.
De exemplu, poți urmări apariția unei persoane în club/cafenea, înainte ca aceasta să fi intrat sau să apară în câmpul vizual. Puțini oameni dezactivează WiFi-ul și conexiunile automate cu AP-uri cunoscute. (Acum eu dezactivez...)
Vizualizarea traficului înregistrat în Wireshark este fascinantă și interesantă pentru a înțelege cum funcționează acestea.
Modul de lucru cu pachetele de deautenticare
În mod implicit, expedierea acestor pachete este interzisă în biblioteca libnet80211.a, care vine fără surse. Dar nu este greu de corectat, modificând câțiva biți. La început m-am îndoit dacă să public patch-ul. Dar după ce am bătut drumuri în diferite locuri cu modul de scanare a surselor de expediere [deauthentication frame] activat, m-am gândit: „de ce nu?”. Mai ales că în esp8266 expedierea acestor pachete nu este blocată și există build-uri pe github pentru esp8266.
În foarte multe locuri (nu voi spune unde) se utilizează suprimarea AP-urilor nedorite prin acest metodă. Și nu este vorba de „huligani”...
Mă întrebam de ce uneori partajarea internetului de pe telefon nu funcționează...
Modul de monitorizare a numărului și RSSI-ului acestor pachete este foarte util pentru a înțelege „unde nu le plac AP-urile străine”.
Modul router
Această funcție este, probabil, cea mai interesantă dintre toate pentru studiu.
ESP32 suportă funcționarea simultană în modul STA + SoftAP. Deci, pe acesta se poate implementa un router NAT clasic.
Pentru susținerea stivei de rețea, Espressif utilizează un fork (aproape fără modificări) al bibliotecii lwip.
Însă, în mod implicit, în build-ul standard, în biblioteca esp-lwip, nu este prevăzută o transparență între interfețele netif ‘ap’(SoftAP) și ‘st’ (STA).
Sigur, se poate face și fără NAT, dar apare problema conectării simultane a două sau mai multe STA la interfața ‘ap’ și sincronizarea adreselor IP de la interfața de rețea ‘st’ la ‘ap’. Așadar, complicațiile nu merită și este mai simplu prin NAT.
Mai mult, există un fork esp-lwip de martin-ger în care a fost adăugată o implementare simplă a NAT pentru IP4.
Deși îmi doream să o refac pur și simplu cosmetic (din punctul meu de vedere, era mai simplu fără fork, ci prin LWIPHOOK funcții, definite la compilare), dar leneșul a învins și varianta de la martin-ger este utilizată așa cum este.
În modul router, se poate vizualiza traficul IP4 de intrare și de ieșire.
În special, din acesta se extrag pentru a fi afișate pe ecran și pentru a colecta statistici într-un fișier:
- Numele dispozitivului care s-a conectat la SoftAP ESP32 (pachete DHCP)
- URL-urile din cererile DNS (UDP port 53) de la dispozitivul conectat la SoftAP ESP32.
De asemenea, se poate activa înregistrarea traficului într-un fișier PCAP.
Acest mod este foarte util, de exemplu, pentru a înțelege ce anume trimite telefonul tău în rețea și unde navighează în acel moment.
Se pot găsi și alte modalități de utilizare a acestui mod, având în vedere posibilitatea de a gestiona complet programatic traficul de intrare și de ieșire al SoftAP ESP32 la nivelul interfeței de rețea: header Ethernet (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP și alte tipuri).
În principiu, ESP32 se descurcă foarte bine cu funcția de router WiFi->WiFi, trecând prin el traficul obișnuit fără întârzieri semnificative. Subiectiv, întârzierile pe telefonul conectat prin router pe ESP32 nu sunt observabile.
Din păcate, în API-ul Espressif nu există opțiunea de a seta un filtru pe MAC pentru STA-urile conectate la SoftAP ESP32. În loc de aceasta, se propune să spun „adio” (esp_wifi_deauth_sta) STA-urilor deja conectate, care sunt „nedorite”.
Filtrarea după MAC pentru STA-urile conectate a fost realizată prin apelul esp_wifi_deauth_sta()
În concluzie
Deși nu am găsit nimic nou în cadrul lucrului cu ESP32, este posibil ca rezultatul (sursele) să fie interesant pentru cineva.
Aș dori să subliniez că am scris codul exclusiv în scopuri educaționale. A fost realizat astfel încât să fie nu foarte convenabil pentru „hacking” și altele.
Nu am realizat un circuit imprimat, deoarece a durat aproximativ 1.5-2 ore să lipesc plăcuțele existente cu fir.
Și dacă ar fi să fac, ar trebui să folosesc componente separate, nu plăci gata făcute. Atunci dimensiunile vor fi și mai mici.
Sursa: habr.com
