Az ötlet, hogy készítsek egy zsebes WiFi-elemző eszközt, arra késztetett, .
Köszönöm nekik az ötletet. Éppen nem volt mit csinálnom.
Az egész munka hobbi keretei között valósult meg, célja, hogy élvezzem és bővítsem a tudásomat a hálózati technológiák terén. Lassan, heti 1-4 órában, az év eleje óta.
A gyakorlati használatot nem terveztem. Tehát ez NEM eszköz a hackerek számára.
Jelenleg az összes tervezett funkció működik. Az összes forráskód, teljesen kész a felépítéshez, . Ott található az összeszerelési útmutató is. Ebben a megjegyzésben nem fogom megduplázni azt az információt, amelyet a githubon közzétettek. Csak azt fogom elmondani, amit külön érdemes leírni.
A véleményem az "univerzális eszközről" és az ESP32 választásának oka
Nem tartom magam igazságbajnoknak. Mindenkinek megvan a saját igazsága. Megpróbálom indokolni a "hardver" választásomat.
használati mód a Linux (eredetileg Raspberry Pi) + periféria, mint például a kontroller (STM32) + CC1110 (8051 mag) kombinációja, és a terv, hogy mindent beleverjek, amit csak lehet (125 kHz, NFC, 433 mHz, USB, iButton, bluetooth, ?) számomra nem tűnt megfelelőnek. Mindazonáltal, valószínűleg így magán- és zárt marad (flipper-zero github "Ez a szervezet nem rendelkezik nyilvános tárolókkal.") és olyan hardver felé fordultam, amely nem túl elterjedt.
Lehet, hogy tévedek, és a jövőben a szerzők nyilvános hozzáférésre bocsátják a szoftver forráskódját. De ha nem, akkor ilyen hardvert forráskód nélkül nem vásárolnék.
Az igényeim az "eszközzel" kapcsolatban
A doboznak kicsinek kell lennie (minél kisebb, annál jobb).
Ezért:
- Beépített akkumulátor nem szükséges. Ha a Wifi használatakor a folyamat 100 mA felett van, a beépített akkumulátor vagy nagy lesz, vagy nem tart sokáig. Ezért legyen a "doboz" a szokásos power bankból táplálva. Egyébként nálam mindig van power bank a zsebben/autóban.
- A "doboz" belsejében Linuxszal kell tartalmaznia az eszközöket, amelyeket évek során írtak minden nyelven kis képernyő és szegényes vezérlőgombok készlete mellett értelmetlen. Az eredményeket normális laptopon, teljes billentyűzettel és képernyővel is meg lehet nézni/feldolgozni.
- Az elemeknek könnyen hozzáférhetőnek és széles körben ismerteknek kell lenniük (elérhető SDK, sok példa és dokumentáció).
Ennek eredményeként a választás számomra egyértelmű volt - ESP32.
Az összes feladat esetében, amelyet a cikkben említettek, ami akcióra ösztönzött, az ESP32 lehetőségei bőven elegendőek. Bár maximum annyit szeretnék még tenni, hogy:
- Játszadozom a Bluetooth-tal.
- Játszadozom a 433mHz frekvenciasávval egyszerű hardverrel (csak amplitúdómodulációval, ami elegendő a legtöbb igényhez).
Hiba az ESP32-ben
- Az ESP32 SDK (IDF) kicsit ügyetlen.
- A funkciók egy része (például WiFi stack) forráskód nélkül, előállított statikus könyvtárak formájában érkezik.
- Nem támogatja az 5gHz frekvenciatartományt, és vannak néhány korlátozás és ügyetlenség a WiFi működésében.
De az ár/méret arány bőven kompenzálja ezeket a hátrányokat.
A szoftver fő funkciói
Röviden összefoglalom a funkciókat és a véleményemet a…
Beállítások kezelése és fájlok letöltése SD-ről
Minden külső vezérlés a legnagyobb egyszerűségű weboldalon keresztül történik, amely egy külön menüpontban fut. Az ESP32 WiFi AP módban indít, és fix IP címen adja meg az oldalt.
Bár az ESP32 magjai meglehetősen gyorsak, de kísérletek alapján az integrált webszolgáltatás egyidejű működése, és például a router üzemmód nem túl jól működik együtt. Ezért dinamikus vezérlés nem érhető el, és minden más üzemmódban az oldal nem elérhető.
Főleg azért, mert kutatási célokra dinamikus vezérlésre nincs szükség.
Beacon csomagokkal való munkamódban
Az üzemmódok banálisak és nem túl érdekesek. Azért készült, mert lehet.
Példák találhatóak az Espressif hivatalos példáiban.
AP listák beolvasási módja.
Ezt gyakorlatilag bármely okostelefon tudja.
Ezen mód mellett listát is mentenek az AP-kból.
Beacon spammelő.
Az ESP32 AP-ként indít, rejtett SSID-vel és véletlenszerű MAC-címmel, és elkezd [beacon frame]-et küldeni egy előre létrehozott SSID listáról (kézzel létrehozott vagy előzőleg AP lista beolvasásával kapott)
WiFi csomagok sniffing üzemmódja
Az Espressif fejlesztői lehetőséget adtak az alkalmazás szoftver számára, hogy a callback funkción keresztül összes WiFi csomagot megkaphasson, amelyek "átszáguldanak a levegőben". Valójában nem mindet, mivel a mód csak egy fix csatornára állítható be.
A callback function call is subject to very strict time limits. While this is not a problem for the simple statistics collection mode, organizing the recording of a PCAP file to an SD card required some effort, setting up the recording through a memory queue and semaphores. Considering the peculiarity that the process calling the callback runs on one core, and the process writing to the SD runs on another.
In a 'noisy environment,' some packets are lost (there is no space in the queue, so they are discarded), but under typical evening 'environment' conditions in an apartment (with 5 to 7 APs in visibility), the recording in PCAP is completed without packet loss.
Additionally, for monitoring and recording PCAP, there is a filtering mode based on a MAC list in packet headers.
For example, you can track a person's presence in a club/café before they actually entered or came into sight. Few people turn off WiFi and automatic connections to known APs. (I do now...)
Viewing recorded traffic in Wireshark is educational and interesting for understanding how all this works.
Operation mode with deauth packets
By default, sending these packets is prohibited in the libnet80211.a library, which comes without the source code. But it's not difficult to modify a couple of bytes. Initially, I hesitated whether to publish the patch. However, after walking around various places with the scanning mode enabled for sending [deauthentication frames], I thought, 'why not.' Moreover, in esp8266, sending these packets is not restricted and there are builds on GitHub for esp8266.
In many places (I won't say where), this method is used to suppress unwanted APs. And it's not 'hooligans'...
I was still surprised that my internet sharing from the phone sometimes didn't work...
The tracking mode for the quantity and RSSI of such packets is very useful to understand 'where they don't like rogue APs.'
Router mode
This function is probably the most interesting of all for research.
ESP32 supports concurrent operation in STA + SoftAP mode. Therefore, a classic NAT router can be implemented on it.
To support the network stack, Espressif uses a fork (almost unchanged) of the lwip library.
However, by default, in the standard build, in the esp-lwip library, there is no provision for passing through between the netif interfaces 'ap' (SoftAP) and 'st' (STA).
Természetesen NAT nélkül is megoldható, de problémát okoz, ha két vagy több STA csatlakozik az 'ap' interfészhez, és szinkronizálni kell az 'st' hálózati interfész IP-címeit az 'ap'-val. Így a nehézségek nem érik meg, és egyszerűbb NAT-on keresztül.
Ráadásul létezik a martin-ger által készített esp-lwip fork, amely tartalmaz egy egyszerű NAT implementációt az IP4-hez.
Bár úgy éreztem, hogy érdemes lenne csak kozmetikai okokból átdolgozni (szerintem egyszerűbb lett volna a fork projekt nélkül, hanem az LWIP révén), de a lustaság győzött, így a martin-ger változata maradt kiindulási alapként.HOOK a build során definiált funkciók), de a lustaság győzött, így a martin-ger változata marad felhasználásra.
Router üzemmódban figyelemmel kísérhetjük a bejövő és kimenő IP4 forgalmat.
Különösen, innen kinyerhető, hogy megjelenítsük a kijelzőn és statisztikát gyűjtsünk a fájlba:
- Az eszköz neve, amely csatlakozott a SoftAP ESP32-höz (DHCP csomagok).
- URL a DNS lekérdezésekből (UDP port 53) a SoftAP ESP32-höz csatlakoztatott eszköztől.
Továbbá lehetőség van a forgalom PCAP fájlba történő rögzítésére.
Ez a mód nagyon hasznos, például hogy megértsük, mit küld a telefonunk a hálózatba és hova csatlakozik.
Más módokat is kitalálhatunk ennek a módnak a kihasználására, figyelembe véve a teljes programozható irányítást a SoftAP ESP32 bejövő és kimenő forgalma felett a hálózati interfész szintjén: Ehernet fejléc (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP, stb. típusa).
Elvileg az ESP32 jól teljesít a WiFi->WiFi router funkcióban, anélkül, hogy jelentős késleltetést okozna a normál forgalomban. Szubjektíven a telefonon, amely az ESP32 routerén keresztül csatlakozik, nem érzékelhető késlekedés.
Sajnos, az Espressif API-jában nincs lehetőség MAC szűrő beállítására a SoftAP EPS32-hez csatlakozó eszközöknél. Ehelyett azt javasolják, hogy mondjunk „viszontlátásra” (esp_wifi_deauth_sta) a már csatlakoztatott nem kívánatos STA-k számára.
A MAC szűrést a csatlakoztatott STA-knál a esp_wifi_deauth_sta() hívásán keresztül kellett megoldani.
Végül
Bár nem találtam ki semmi újat az ESP32 működésével kapcsolatban, de lehet, hogy valakinek érdekes lesz az eredmény (forráskódok).
Szeretném megjegyezni, hogy a kódot kizárólag oktatási célokra írtam. A "feltörés" és hasonlók érdekében szándékosan nem készítettem túl kényelmessé.
Nyomtatott áramkört nem készítettem, mivel a kész táblák vezetékkel való összeszerelése körülbelül 1.5-2 órát vett igénybe.
Ha pedig készíteni akarunk, nem készen kapott táblákat kellene használni, hanem külön alkatrészekből dolgozni. Akkor a méretek még kisebbek lennének.
Forrás: habr.com
