L'idea di creare uno strumento portatile per l'analisi delle reti WiFi mi è venuta in mente grazie a .
Grazie a loro per l'idea. Non avevo niente da fare.
Tutto il lavoro è stato svolto nell'ambito di un hobby con l'obiettivo di divertirsi e ampliare le proprie conoscenze nel campo delle tecnologie di rete. Con calma, da 1 a 4 ore a settimana, dall'inizio di quest'anno.
Non avevo pianificato un utilizzo pratico. Cioè, NON è uno strumento per hacker.
Al momento, tutte le funzionalità pensate funzionano. Tutti i codici sorgente, completamente pronti per la compilazione, . Lì troverai anche istruzioni per la compilazione e altro. In questa nota non duplicherò le informazioni pubblicate su GitHub. Racconterò solo ciò che considero necessario descrivere separatamente.
La mia opinione sull'"strumento universale" e il motivo della scelta dell'ESP32
Non pretendo di avere la verità in tasca. Ognuno ha la sua. Cercherò di giustificare la mia scelta di "hardware".
combinazione di Linux (inizialmente Raspberry Pi) + periferiche come controllori (STM32) + CC1110 (nucleo 8051) e l'intenzione di inserire tutto ciò che è possibile (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) mi sembra inadeguata per me. Tuttavia, sembra rimanere privato e chiuso (flipper-zero github "Questa organizzazione non ha repository pubblici.") e ho optato per hardware non troppo diffuso.
Forse mi sbaglio, e in futuro gli autori pubblicheranno il codice sorgente del software in accesso aperto. Ma se non lo faranno, non comprerei mai un hardware del genere senza codici sorgente.
Le mie esigenze per l'"strumento"
La scatola deve essere piccola (più è piccola, meglio è).
Quindi:
- Una batteria integrata non è necessaria. Con correnti > 100 mA durante l'uso del Wifi, la batteria integrata sarà o grande, o non durerà a lungo. Quindi lascia che la "scatola" si alimenti da un power bank standard. Ho sempre un power bank in tasca/auto.
- Non ha senso ospitare Linux con strumenti all'interno della "scatola", scritti in molti anni in tutti i linguaggi se c'è un piccolo schermo e un ridotto numero di pulsanti di controllo. I risultati possono essere visualizzati/elaborati anche su un normale laptop con una tastiera e uno schermo adeguati.
- I componenti devono essere facilmente accessibili e ampiamente conosciuti (SDK accessibili, molti esempi e documentazione).
Di conseguenza, per me, la scelta è stata ovvia: ESP32.
Per tutte le attività menzionate nell'articolo che mi hanno spinto all'azione, le possibilità dell'ESP32 sono più che sufficienti. Anche se il massimo che voglio fare è:
- Sperimentare con il Bluetooth.
- Sperimentare con la banda 433mHz con hardware semplice (solo modulazione di ampiezza, sufficiente per esigenze pratiche).
Un aspetto negativo dell'ESP32
- Il SDK (IDF) dell'ESP32 è un po' goffo.
- Parte delle funzionalità (come lo stack WiFi) arriva senza sorgenti sotto forma di librerie statiche compilate.
- Non supporta la banda 5gHz e ci sono alcune limitazioni e imperfezioni nel funzionamento con WiFi.
Ma il prezzo/dimensioni compensano ampiamente questi difetti.
Funzionalità principali del software
Descriverò brevemente le funzionalità e la mia opinione su …
Gestione delle impostazioni e caricamento di file dalla SD
Tutta la gestione esterna è realizzata tramite una semplice pagina web, avviata in un’apposita voce di menu. L'ESP32 si avvia in modalità WiFi AP e fornisce una pagina a un indirizzo IP fisso.
Sebbene i core dell'ESP32 siano abbastanza veloci, come hanno dimostrato gli esperimenti, il funzionamento simultaneo del servizio web integrato e, ad esempio, della modalità router non è molto compatibile. Pertanto, il controllo dinamico non è disponibile e in tutte le altre modalità la pagina non è accessibile.
Soprattutto perché per scopi di ricerca il controllo dinamico non è necessario.
Modalità di funzionamento con pacchetti Beacon
Le modalità sono banali e non molto interessanti. Realizzate "perché si può fare". Per dire di averlo fatto.
Ci sono esempi negli esempi ufficiali di Espressif.
Modalità di scansione delle liste AP.
In effetti, qualsiasi smartphone è in grado di farlo.
E in questa modalità verrà salvata la lista degli AP.
Beacon spammer.
L'ESP32 si avvia come AP con SSID nascosto e MAC casuale e inizia a inviare [beacon frame] da una lista SSID creata in precedenza (creata manualmente o ricevuta in precedenza durante la scansione della lista AP)
Modalità sniffing dei pacchetti WiFi
Gli sviluppatori di Espressif hanno aggiunto la possibilità per il software applicativo di ricevere tramite una funzione di callback tutti i pacchetti WiFi "che passano nell'aria". In realtà non tutti, poiché può essere impostata la modalità solo per un canale fisso.
Ci sono vincoli temporali molto severi sul callback delle funzioni. Se per la modalità di semplice raccolta delle statistiche non ci sono problemi, nella modalità di registrazione del file PCAP su scheda SD è stato necessario lavorare un po', organizzando la registrazione tramite una coda in memoria e i semafori. Tenendo conto del fatto che il processo che chiama il callback gira su un core, mentre il processo che esegue la registrazione sulla SD si trova su un altro.
In caso di "segnale rumoroso", alcuni pacchetti vengono persi (non c'è spazio nella coda e vengono scartati), ma in un tipico "segnale" serale in un appartamento (5..7 AP visibili) la registrazione in PCAP viene completata senza perdita di pacchetti.
Inoltre, per il monitoraggio e la registrazione dei PCAP esiste una modalità di filtraggio secondo l'elenco dei MAC negli header dei pacchetti.
Ad esempio, è possibile tracciare l'entrata di una persona in un club/ristorante, prima che sia entrato o sia comparsa nel campo visivo. Pochi disattivano il WiFi e la connessione automatica ai AP noti. (Ora io lo disattivo...)
Esplorare il traffico registrato in Wireshark è istruttivo e interessante per comprendere come tutto funziona.
Modalità di lavoro con i pacchetti deauth
Di default, l'invio di questi pacchetti è vietato nella libreria libnet80211.a, che viene fornita senza sorgenti. Ma non è difficile modificarla, sistemando un paio di byte. All'inizio ero incerto se fosse il caso di pubblicare la patch. Ma, dopo aver visitato diversi luoghi con la modalità di scansione attivata degli invii di [deauthentication frame], ho pensato: "che diavolo". Soprattutto considerando che nell'esp8266 l'invio di questi pacchetti non è bloccato e ci sono compilazioni su github per esp8266.
In molti luoghi (non dirò dove) viene utilizzata la soppressione degli AP indesiderati tramite questo metodo. E non sono "teppisti"...
E io mi chiedevo perché a volte la condivisione di internet dal telefono non funzionasse...
La modalità di monitoraggio del numero e del RSSI di tali pacchetti è molto utile per capire "dove non gradiscono i AP indesiderati".
Modalità router
Questa funzione è probabilmente la più interessante di tutte per essere esplorata.
L'ESP32 supporta l'operatività simultanea in modalità STA + SoftAP. Pertanto, è possibile implementare un classico router NAT.
Per supportare lo stack di rete, Espressif utilizza un fork (praticamente senza modifiche) della libreria lwip.
Tuttavia, di default, nella compilazione standard, nella libreria esp-lwip non è prevista la fuga tra le interfacce netif ‘ap’ (SoftAP) e ‘st’ (STA).
Si può sicuramente fare anche senza NAT, ma sorge il problema della connessione simultanea di due o più STA all'interfaccia 'ap' e della sincronizzazione degli indirizzi IP dall'interfaccia di rete 'st' all''ap'. Quindi le complicazioni non valgono la pena e risulta più semplice utilizzare NAT.
Inoltre, esiste un fork esp-lwip di martin-ger in cui è stata aggiunta una semplice implementazione di NAT per IP4.
Anche se mi grattavo le mani per rifarlo puramente a livello cosmetico (secondo me era più semplice senza fork di progetto, ma attraverso LWIPHOOK funzioni definite al momento della compilazione), ma la pigrizia ha prevalso e si usa la versione di martin-ger così com'è.
In modalità router viene monitorato il traffico IP4 in entrata e in uscita.
In particolare, da esso vengono estratti per la visualizzazione sullo schermo e per la raccolta di statistiche nel file:
- Nome del dispositivo che si è connesso al SoftAP ESP32 (pacchetti DHCP)
- URL delle richieste DNS (porta UDP 53) dal dispositivo collegato al SoftAP ESP32.
In aggiunta, è possibile abilitare la registrazione del traffico in un file PCAP.
Questa modalità è molto utile, ad esempio, per capire cosa manda il vostro telefono in rete e dove si collega.
Si possono ideare anche altri modi di usare questa modalità tenendo conto della possibilità di controllare completamente tramite software il traffico in entrata e in uscita del SoftAP ESP32 a livello dell'interfaccia di rete: intestazione Ehernet (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DCHP, e altro tipo).
In linea di principio, l'ESP32 gestisce abbastanza bene la funzione di router WiFi->WiFi, passando normalmente il traffico senza ritardi significativi. Soggettivamente, i ritardi sul telefono connesso tramite il router ESP32 non sono percepibili.
Sfortunatamente, nell'API di Espressif non è possibile impostare un filtro per i MAC collegati al SoftAP EPS32. Invece, si propone di dire "addio" (esp_wifi_deauth_sta) agli STA già connessi, che sono "non desiderabili".
La filtrazione per MAC per gli STA collegati è stata effettuata tramite la chiamata esp_wifi_deauth_sta()
In conclusione
Anche se non ho ideato nulla di nuovo nell'ambito del lavoro con l'ESP32, potrebbe comunque interessare a qualcuno il risultato (i sorgenti).
Vorrei sottolineare che ho scritto il codice esclusivamente per scopi didattici. Per "hackeraggio" e simili, è stato deliberatamente reso non molto comodo.
Non ho realizzato un circuito stampato, poiché ci sono volute circa 1,5-2 ore per saldare insieme i circuiti pronti con un cavo.
E se si decide di farlo, non si dovrebbe assemblare da circuiti pronti, ma da singoli componenti. Allora le dimensioni saranno ancora più piccole.
Fonte: habr.com
