Nápad vytvořit kapesní nástroj pro analýzu WiFi sítí mě přivedl k myšlence, .
Děkuji jim za nápad. Právě jsem neměl co na práci.
Veškerá práce byla provedena v rámci koníčku s cílem získat potěšení a rozšířit své znalosti v oblasti síťových technologií. Pomalu, 1 až 4 hodiny týdně, od začátku tohoto roku.
Praktické použití jsem neplánoval. Tedy to NENÍ nástroj pro hackera.
V tuto chvíli funguje veškerá zamýšlená funkcionalita. Všechny zdrojové kódy, plně připravené ke kompilaci, . Tam je také návod k sestavení a další. V tomto článku nebudu duplicovat informace zveřejněné na GitHubu. Povím jen to, co považuji za nutné popsat zvlášť.
Můj názor na "univerzální nástroj" a důvod výběru ESP32
Nepovažuji se za znalce. Každý má svou pravdu. Pokusím se ospravedlnit svůj výběr "hardwaru".
varianta použití kombinace Linux (původně Raspberry Pi) + «periferie» ve formě kontroleru (STM32) + CC1110 (jádro 8051) a plán vměstnat tam všechno, co jen půjde (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) mi přišla pro mě nevhodná. Nicméně, se zdá tak zůstat soukromým a uzavřeným (flipper-zero github "Tato organizace nemá veřejné repozitáře.") a zaměřil jsem se na méně běžný hardware.
Možná se mýlím, a v budoucnu autoři zveřejní zdrojové kódy softwaru do veřejného přístupu. Ale pokud ne, tak bych takový hardware bez zdrojových kódů nekoupil.
Moje požadavky na "nástroj"
Krabička by měla být malá (čím menší, tím lepší).
Proto:
- Vestavěná baterie není potřeba. Při proudu > 100 mA při práci s WiFi, vestavěná baterie buď bude velká, nebo jí nebude dlouho stačit. Proto nechť "krabička" získává energii ze standardního power banku. Power bank mám stejně vždy v kapse/auta.
- Udržovat v "krabičce" Linux s nástroji, napsanými za mnoho let ve všech jazycích při současné malé obrazovce a chudém souboru ovládacích tlačítek nedává smysl. Výsledky lze sledovat/zpracovávat i na normálním notebooku s plnohodnotnou klávesnicí a obrazovkou.
- Komponenty by měly být snadno dostupné a široce známé (dostupný SDK, spousta příkladů a dokumentace).
Výsledkem tedy pro mě bylo jasné rozhodnutí — ESP32.
Pro všechny úkoly zmíněné v článku, který mě povzbudil k činům, jsou možnosti ESP32 zcela dostatečné. I když to, co bych chtěl ještě udělat, je:
- Povídat si s Bluetooth.
- Experimentovat s pásmem 433mHz s nejjednodušším hardwarem (pouze amplitudová modulace, což je dostatečné pro praktické potřeby).
Lžíce dehtu v ESP32
- SDK (IDF) pro ESP32 je poněkud neohrabané.
- Část funkcionality (například WiFi stack) přichází bez zdrojáků ve formě zkompilovaných statických knihoven.
- Není podporováno pásmo 5gHz a existují některá omezení a nedostatky v práci s WiFi.
Ale cena/rozměry tyto nedostatky zcela kompenzují.
Hlavní funkcionalita softwaru
Krátce popíšu funkcionalitu a svůj názor na…
Správa nastavení a nahrávání souborů na SD
Veškerá externí správa je provedena prostřednictvím nejjednodušší webové stránky, spuštěné v samostatné nabídce. ESP32 se spouští v režimu WiFi AP a poskytuje stránku na pevném IP adrese.
I když jsou jádra ESP32 docela rychlá, ale jak ukázaly experimenty, současná práce vestavěné webové služby a například režimu routeru se příliš neslučuje. Proto neexistuje dynamické řízení a v ostatních režimech není stránka dostupná.
Zvlášť proto, že pro výzkumné účely dynamické řízení není potřeba.
Režim práce s Beacon pakety
Režimy jsou banální a příliš zajímavé. Udělali to "protože to jde". Pro formu.
Příklady existují v oficiálních příkladech Espressif.
Režim skenování seznamů AP.
To vlastně umí udělat jakýkoli smartphone.
A v tomto režimu se uloží seznam AP.
Beacon spammer.
ESP32 startuje jako AP se skrytým SSID a náhodným MAC a začíná posílat [beacon frame] podle předem vytvořeného seznamu SSID (vytvořeného ručně nebo získaného dříve při skenování seznamu AP)
Režim sniffing paketů WiFi
Vývojáři Espressif přidali možnost aplikovanému softwaru získat prostřednictvím callback funkce všechny WiFi pakety "prolétající vzduchem". Ve skutečnosti ne všechny, protože je možné nastavit režim pouze pro jeden pevný kanál.
Na zpracování volání callback funkce jsou kladeny velmi přísné časové limity. Zatímco pro režim jednoduchého sběru statistik to nepředstavuje problém, pro režim zápisu PCAP souboru na SD kartu to vyžaduje nějaké úsilí, aby se organizoval zápis prostřednictvím fronty v paměti a semaforů. S ohledem na to, že proces, který volá callback, běží na jednom jádře, zatímco proces provádějící zápis na SD běží na jiném.
Při „šumové eteru“ některé pakety ztrácíme (v queue není místo a jsou odmítnuty), ale při typickém „eternu“ večera v bytě (5..7 AP v dohlednosti) zápis do PCAP je uskutečněn bez ztrát paketů.
Dodatečně, pro monitorování a zápis PCAP je k dispozici režim filtrování podle seznamu MAC v hlavičkách paketů.
Například je možné sledovat osobu, která se objevila v klubu/kavárně, ještě předtím, než vstoupila nebo se objevila v zorném poli. Málo kdo vypíná WiFi a automatické připojení k známým AP. (Já to teď vypínám..)
Prohlížení zapsaného provozu ve Wiresharku je poučné a zajímavé pro pochopení, jak to celé funguje.
Režim práce s deauth pakety
Ve výchozím nastavení je odesílání těchto paketů zakázáno v knihovně libnet80211.a, která je dodávána bez zdrojových kódů. Ale není těžké to obejít, upravením pár bajtů. Zpočátku jsem váhal, zda zveřejnit patch. Ale pochodil jsem s povoleným režimem skenování zdrojů odeslání [deauthentication frame] a pomyslel jsem si: „proč ne“. Tím spíše, že v esp8266 není odesílání těchto paketů zakázáno a na githubu jsou sestavení pro esp8266.
Na velmi mnoha místech (nebudu říkat kde) se používá potlačení nežádoucích AP tímto způsobem. A to nejsou „hooligans“…
A já jsem se divil, že mi někde nefunguje sdílení internetu z telefonu...
Režim sledování počtu a RSSI takových paketů je velmi užitečný pro pochopení „kde nemají rádi cizí AP“.
Režim router
Tato funkce je pravděpodobně nejzajímavější ze všech pro zkoumání.
ESP32 podporuje současnou práci v režimu STA + SoftAP. Proto na něm lze realizovat klasický NAT router.
Pro podporu síťového zásobníku používá Espressif fork (v podstatě bez změn) knihovny lwip.
Ale ve výchozím nastavení, v standardní sestavě, v knihovně esp-lwip není mezi netif rozhraními „ap“ (SoftAP) a „st“ (STA) zajištěn přenos.
Samozřejmě, lze to udělat i bez NAT, ale vzniká problém s paralelním připojením dvou nebo více STA k rozhraní 'ap' a synchronizace IP adres z síťového rozhraní 'st' na 'ap'. Takže složitosti nestojí za to a je to jednodušší přes NAT.
Tím spíše, že existuje fork esp-lwip od martin-ger, ve kterém je přidána jednoduchá implementace NAT pro IP4.
I když mě svrběly ruce ji předělat čistě kosmeticky (podle mě bylo jednodušší bez forku projektu, a přes LWIPHOOK funkce definované při sestavení), ale lenost zvítězila a varianta od martin-ger se používá tak, jak je.
V režimu router se sleduje příchozí a odchozí IP4 provoz.
Z něj se mimo jiné extrahuje pro zobrazení na displeji a sběr statistik do souboru:
- Jméno zařízení, které se připojilo k SoftAP ESP32 (DHCP pakety)
- URL z DNS dotazů (UDP port 53) od připojeného zařízení k SoftAP ESP32.
Navíc lze zapnout záznam provozu do souboru PCAP.
Tento režim je velmi užitečný, například aby bylo jasné, co váš telefon posílá do sítě a kam při tom chodí.
Můžete vymyslet i další způsoby použití tohoto režimu s ohledem na možnost plně řídit programově příchozí a odchozí provoz SoftAP ESP32 na úrovni síťového rozhraní: Ethernet hlavička (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP a další typy).
V zásadě si ESP32 celkem dobře poradí s funkcí WiFi->WiFi routera, procházejícího běžným provozem bez výrazných zpoždění. Subjektivně si zpoždění v telefonu připojeném přes router na ESP32 nevšimnete.
Bohužel v API Espressif neexistuje možnost nastavit filtr podle MAC připojených k SoftAP ESP32. Místo toho se navrhuje říci 'sbohem' (esp_wifi_deauth_sta) již připojeným STA, které jsou 'nežádoucí'.
Filtrace podle MAC pro připojované STA musela být učiněna pomocí volání esp_wifi_deauth_sta()
Na závěr
I když jsem nic nového v rámci práce s ESP32 nevymyslel, možná bude někomu výsledek (zdrojové kódy) zajímavý.
Chtěl bych zdůraznit, že kód jsem psal výhradně pro vzdělávací účely. Pro 'hacking' a podobně byl úmyslně udělán ne moc pohodlný.
Tištěný obvod jsem nedělal, protože to, že jsem pájel drátem hotové desky, zabralo asi 1,5-2 hodiny.
A i když bych to dělal, tak je třeba ne ze hotových desek skládat, ale z jednotlivých komponent. Pak budou rozměry ještě menší.
Zdroj: habr.com
