Kio donis al mi la ideon fari poŝan ilon por analizi WiFi-retojn estis .
Dankon al ili pro la ideo. Mi nur havis nenion por fari.
Ĉiu laboro estis farita kiel parto de ŝatokupo kun la celo amuziĝi kaj vastigi miajn konojn en la kampo de retaj teknologioj. Malrapide, 1..4 horojn semajne, ekde la komenco de ĉi tiu jaro.
Mi ne planis ajnan praktikan uzon. Tiuj. Ĉi tio NE estas ilo de hakisto.
Nuntempe ĉiuj planitaj funkcioj funkcias. Ĉiuj fontoj, tute pretaj por kunigo, . Estas ankaŭ kunmuntaj instrukcioj ktp. En ĉi tiu noto, mi ne duobligos la informojn afiŝitajn sur github. Mi diros al vi nur tion, kion mi opinias necesa priskribi aparte.
Mia opinio pri la "universala ilo" kaj la kialo por elekti la ESP32
Mi ne pretendas esti la vero. Ĉiu havas sian propran. Mi provos pravigi mian elekton de aparataro.
la uzkazo de kombinaĵo de Linukso (komence Raspberry Pi) + "periferiaĵoj" en la formo de regilo (STM32) + CC1110 (8051 kerno) kaj la plano enŝlosi ĉion eblan tie (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) ne ŝajnis taŭga por mi. Tamen, Ŝajnas, ke ĝi restos privata kaj fermita (flipper-zero github "Ĉi tiu organizo ne havas publikajn deponejojn.") kaj iris al ne tre ofta aparataro.
Eble mi eraras, kaj estonte la aŭtoroj disponigos la programfontojn publike. Sed se ne, tiam mi ne aĉetus tian aparataron sen la fontkodo.
Miaj postuloj por la "ilo"
La skatolo estu malgranda (ju pli malgranda des pli bone).
Sekve:
- Ne necesas enkonstruita kuirilaro. Kun fluo > 100 mA kiam vi laboras kun Wifi, la enkonstruita baterio aŭ estos granda aŭ ne daŭros longe. Sekve, lasu la "skatolon" funkciigi per norma potenca banko. Ĉiuokaze, mi ĉiam havas elektran bankon en mia poŝo/aŭto.
- Konservu Linuksan "skatolon" kun iloj interne, verkita dum multaj jaroj en ĉiuj lingvoj Kun malgranda ekrano kaj magra aro de kontrolbutonoj, ĝi ne havas sencon. La rezultoj povas esti viditaj/procesitaj sur normala tekkomputilo kun plena klavaro kaj ekrano.
- Komponentoj estu facile alireblaj kaj vaste konataj (disponebla SDK, multaj ekzemploj kaj dokumentaro).
Rezulte, por mi, la elekto estis evidenta - ESP32.
Por ĉiuj taskoj deklaritaj en la artikolo, kiu instigis min agi, la kapabloj de la ESP32 estas sufiĉe sufiĉaj. Kvankam la plej multe, kiun mi ankoraŭ volas fari, estas:
- Ludu per Bluetooth.
- Ludu kun la 433mHz-gamo kun la plej simpla aparataro (nur amplitudmodulado, kiu sufiĉas por praktikaj bezonoj).
Flugu en la ungvento en ESP32
- La ESP32 SDK (IDF) estas iom mallerta.
- Kelkaj el la funkcieco (WiFi-stako, ekzemple) venas sen fontkodo en la formo de kunvenitaj senmovaj bibliotekoj.
- La 5gHz-bendo ne estas subtenata kaj estas iuj limigoj kaj mallerteco en laborado kun WiFi.
Sed la prezo/grandeco tute kompensas ĉi tiujn mankojn.
Ĉefa programara funkcio
Mi mallonge priskribos la funkciojn kaj mian opinion pri...
Administri agordojn kaj alŝuti dosierojn el SD
Ĉiu ekstera kontrolo estas farita per simpla TTT-paĝo, lanĉita en aparta menuero. La ESP32 komenciĝas en WiFi AP-reĝimo kaj montras paĝon ĉe fiksa IP-adreso.
Kvankam la ESP32-kernoj estas sufiĉe rapidaj, kiel eksperimentoj montris, la samtempa funkciado de la enkonstruita TTT-servo kaj, ekzemple, la enkursigilo ne tre kongruas. Tial, ne ekzistas dinamika kontrolo kaj la paĝo ne estas disponebla en ĉiuj aliaj reĝimoj.
Krome, dinamika kontrolo ne estas necesa por esplorceloj.
Reĝimo labori kun Beacon-pakaĵoj
La modoj estas banalaj kaj ne tre interesaj. Farita "ĉar ĝi eblas." Por kontrolo.
Estas ekzemploj en la oficialaj Espressif-ekzemploj.
AP-lista skananta reĝimo.
Efektive, ajna saĝtelefono povas fari tion.
Nu, en ĉi tiu reĝimo la AP-listo estos konservita.
Signostango-spamisto.
La ESP32 komenciĝas kiel AP kun kaŝita SSID kaj hazarda MAC kaj komencas sendi [signostangon] laŭ antaŭkreita listo de SSID-oj (kreitaj permane aŭ akiritaj pli frue per skanado de la AP-listo)
Reĝimo de snufado de WiFi-pakaĵo
Espressif-programistoj aldonis la kapablon por aplika programaro ricevi ĉiujn WiFi-pakojn "flugante en la aero" per la revokfunkcio. Fakte ne ĉiuj, ĉar vi povas nur agordi la reĝimon por unu fiksa kanalo.
Tre striktaj tempolimigoj estas truditaj pri prilaborado de revokfunkcio. Se ĉi tio ne kaŭzas problemojn por la simpla statistika kolekta reĝimo, tiam por la PCAP-dosierregistra reĝimo sur la SD-karto mi devis tinti, organizante la registradon per vico en memoro kaj semaforoj. Konsiderante la proprecon, ke la procezo, kiu vokas la revokadon, funkcias sur unu kerno, kaj la procezo, kiu skribas al SD en alia.
Dum "brua aero", kelkaj pakaĵetoj estas perditaj (ne estas loko en la vico kaj ili estas forĵetitaj), sed kun tipa "aero" de loĝejo vespere (5..7 AP-oj ene de videbleco), registrado en PCAP. estas kompletigita sen paka perdo.
Aldone, por monitorado kaj registrado de PCAP, ekzistas filtra reĝimo bazita sur la MAC-listo en la pakaĵetokapoj.
Ekzemple, vi povas spuri la aspekton de persono en klubo/kafejo antaŭ ol li eĉ eniras aŭ aperas en la vido. Malmultaj homoj malŝaltas WiFi kaj aŭtomatajn konektojn al konataj AP-oj. (Mi malŝaltas ĝin nun..)
Vidi registritan trafikon en Wireshark estas eduka kaj interesa por kompreni mapojn - ĉio funkcias.
Reĝimo por labori kun deauth-pakaĵoj
Defaŭlte, sendi ĉi tiujn pakaĵojn estas malpermesita en la biblioteko libnet80211.a, kiu venas sen fontoj. Sed ĝi estas facile ripari per tajlado de kelkaj pecoj. Komence mi dubis ĉu indas afiŝi flikaĵon. Sed post promenado ĉirkaŭ diversaj lokoj kun la senaŭtentiga kadro-skanada reĝimo ŝaltita, mi pensis: "kio diable." Plie, en esp8266 la livero de ĉi tiuj pakoj ne estas fermita kaj estas kunigoj sur github por esp8266.
En multaj lokoj (mi ne diros kie) estas uzata forigo de nedezirataj AP-oj per ĉi tiu metodo. Kaj ĉi tiuj ne estas "ĉikanantoj"...
Kaj mi ankaŭ surpriziĝis, ke mia interreta distribuo de mia telefono ne funkciis kelkloke...
La reĝimo por spuri la nombron kaj RSSI de tiaj pakaĵoj estas tre utila por kompreni "kie la maldekstraj AP-oj ne ŝatas ĝin."
enkursigilo-reĝimo
Ĉi tiu funkcio estas verŝajne la plej interesa el ĉiuj por esplori.
ESP32 subtenas samtempan funkciadon en STA + SoftAP-reĝimo. Tial vi povas efektivigi klasikan NAT-enkursigilon sur ĝi.
Por subteni la retan stakon, Espressif uzas forkon (preskaŭ senŝanĝan) de la lwip-biblioteko.
Sed, defaŭlte, en la norma konstruo, la biblioteko esp-lwip ne disponigas plusendon inter la netif-interfacoj 'ap' (SoftAP) kaj 'st' (STA).
Kompreneble, vi povas fari ĝin sen NAT, sed estas problemo kun samtempe konekti du aŭ pli da STA-oj al la 'ap'-interfaco kaj sinkronigi IP-adresojn de la 'st' reto-interfaco al 'ap'. Do la malfacilaĵoj ne valoras kaj ĝi estas pli facila per NAT.
Plie, ekzistas forko esp-lwip de martin-ger, kiu aldonas simplan efektivigon de NAT por IP4.
Kvankam miaj manoj jukis refari ĝin pure kosmetike (laŭ mi, estis pli facile sen forko de la projekto, sed per LWIPHOOK funkcioj difinitaj dum asembleo), sed maldiligento regis kaj la opcio de martin-ger estas uzata kiel estas.
En enkursigilo, envenanta kaj eksiĝinta IP4-trafiko estas rigardata.
Aparte, la jena estas ĉerpita el ĝi por montriĝi sur la ekrano kaj kolekti statistikojn en dosieron:
- Nomo de la aparato konektita al SoftAP ESP32 (DHCP-pakoj)
- URL de DNS-petoj (UDP-haveno 53) de aparato konektita al SoftAP ESP32.
Aldone, vi povas ebligi trafikregistradon al PCAP-dosiero.
Ĉi tiu reĝimo estas tre utila, ekzemple, por kompreni, ekzemple, kion via telefono sendas al la reto kaj kien ĝi iras.
Vi povas pensi pri aliaj manieroj uzi ĉi tiun reĝimon, konsiderante la kapablon tute kontroli softAP ESP32 envenantan kaj elirantan trafikon ĉe la reto-interfaco-nivelo: Ehernet-kapo (destMAC[6]+srcMAC[6]+type[2]) + utila ŝarĝo (IP4, IP6, DCHP, ktp. tipo).
Principe, la ESP32 sufiĉe bone traktas la funkcion WiFi->WiFi-enkursigilo, trairante normalan trafikon sen specialaj prokrastoj. Subjektive, malfruoj en telefono konektita per enkursigilo sur ESP32 ne estas rimarkeblaj.
Bedaŭrinde, la Espressif API ne havas la kapablon agordi filtrilon por MAC konektita al SoftAP EPS32. Anstataŭe, oni proponas diri "ĝis revido" (esp_wifi_deauth_sta) al jam konektitaj STA-oj kiuj estas "ne dezirataj".
Filtri per MAC por konektitaj STA-oj devis esti farita per la alvoko esp_wifi_deauth_sta()
En konkludo
Kvankam mi elpensis nenion novan kadre de laboro kun ESP32, eble la rezulto (fontokodo) estos interesa por iu.
Mi ŝatus noti, ke la kodo estis verkita nur por edukaj celoj. Por "hakado", ktp., ĝi estis intence farita ne tre oportuna.
Mi ne faris presitan cirkviton, ĉar necesis 1.5-2 horoj por luti la pretajn koltukojn per drato.
Kaj se vi faras, vi devas kunveni ĝin ne el pretaj tabuloj, sed el individuaj komponantoj. Tiam la dimensioj estos eĉ pli malgrandaj.
fonto: www.habr.com