Ez adta az ötletet, hogy készítsek egy zsebeszközt a WiFi hálózatok elemzésére .
Köszönöm nekik az ötletet. Egyszerűen nem volt semmi dolgom.
Minden munka hobbi keretében történt, a szórakozás és a hálózati technológiai ismereteim bővítése céljából. Lassan heti 1..4 órában, ez év eleje óta.
Gyakorlati felhasználást nem terveztem. Azok. Ez NEM hacker eszköze.
Jelenleg minden tervezett funkció működik. Minden forrás, teljesen összeszerelésre kész, . Vannak még összeszerelési utasítások stb. Ebben a megjegyzésben nem fogom megismételni a githubon közzétett információkat. Csak azt mondom el, amit szükségesnek tartok külön leírni.
Véleményem az "univerzális eszközről" és az ESP32 választásának okáról
Nem állítom, hogy ez az igazság. Mindenkinek megvan a sajátja. Megpróbálom indokolni a hardverválasztásomat.
a Linux (kezdetben Raspberry Pi) + „perifériák” kombinációjának felhasználási esete vezérlő (STM32) + CC1110 (8051 mag) formájában, és az a terv, hogy mindent bele kell zsúfolni (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) nem tűnt megfelelőnek számomra. Azonban, Úgy tűnik, hogy privát és zárt marad (Flipper-zero github „Ez a szervezet nem rendelkezik nyilvános tárolókkal.”), és a nem túl gyakori hardver felé halad.
Talán tévedek, és a jövőben a szerzők nyilvánosan elérhetővé teszik a szoftverforrásokat. De ha nem, akkor nem vennék ilyen hardvert a forráskód nélkül.
Az "szerszámmal" kapcsolatos követelményeim
A doboznak kicsinek kell lennie (minél kisebb, annál jobb).
ezért:
- Nincs szükség beépített akkumulátorra. 100 mA-nél nagyobb áramerősségnél, ha Wifivel dolgozik, a beépített akkumulátor vagy nagy lesz, vagy nem sokáig bírja. Ezért hagyja, hogy a „dobozt” egy szabványos power bank táplálja. Amúgy mindig van power bank a zsebemben/autómban.
- Tartson egy Linux „dobozt” eszközökkel, évek óta íródott minden nyelven Kis képernyővel és csekély számú vezérlőgomb-készlettel ennek semmi értelme. Az eredmények megtekinthetők/feldolgozhatók egy normál laptopon, teljes billentyűzettel és képernyővel.
- Az összetevőknek könnyen hozzáférhetőnek és széles körben ismertnek kell lenniük (elérhető SDK, sok példa és dokumentáció).
Ennek eredményeként számomra nyilvánvaló volt a választás - ESP32.
A cikkben felsorolt összes feladathoz, amely cselekvésre késztetett, az ESP32 képességei teljesen elegendőek. Bár a legtöbb, amit még mindig szeretnék tenni:
- Játssz a Bluetooth segítségével.
- Játssz a 433 MHz-es tartományban a legegyszerűbb hardverrel (csak amplitúdómoduláció, ami gyakorlati igényekhez elegendő).
Légy jó az ESP32-ben
- Az ESP32 SDK (IDF) kissé ügyetlen.
- A funkciók egy része (például a Wi-Fi-verem) forráskód nélkül érkezik, összeállított statikus könyvtárak formájában.
- Az 5gHz-es sáv nem támogatott, és vannak korlátozások és ügyetlenségek a WiFi-vel való munkavégzés során.
De az ár/méret teljesen kompenzálja ezeket a hiányosságokat.
A szoftver fő funkciói
Röviden leírom a funkcionalitást és a véleményemet a...
Beállítások kezelése és fájlok feltöltése SD-ről
Minden külső vezérlés egy egyszerű weboldalon keresztül történik, amelyet külön menüpontban indítanak el. Az ESP32 WiFi AP módban indul, és egy oldalt jelenít meg egy rögzített IP-címen.
Bár az ESP32 magok meglehetősen gyorsak, amint azt a kísérletek igazolták, a beépített webszolgáltatás és például a router mód egyidejű működése nem nagyon kompatibilis. Ezért nincs dinamikus vezérlés, és az oldal nem érhető el minden más módban.
Ráadásul kutatási célokra nincs szükség dinamikus vezérlésre.
Beacon csomagokkal való munkavégzés módja
A módok banálisak és nem túl érdekesek. Készült, „mert lehetséges”. Ellenőrzésre.
Vannak példák a hivatalos Espressif példákban.
AP lista szkennelési mód.
Valójában minden okostelefon képes erre.
Nos, ebben a módban az AP lista mentésre kerül.
Beacon spammer.
Az ESP32 AP-ként indul rejtett SSID-vel és véletlenszerű MAC-fel, és elkezdi küldeni a [beacon frame]-t az SSID-ek előre létrehozott listája szerint (manuálisan létrehozott vagy korábban az AP-lista szkennelésével kapott)
WiFi csomagszippantási mód
Az Espressif fejlesztői hozzáadták azt a lehetőséget, hogy az alkalmazásszoftver a visszahívási funkción keresztül fogadja az összes „levegőben repülő” WiFi-csomagot. Valójában nem mindegyik, mivel csak egy rögzített csatornához állíthatja be az üzemmódot.
Nagyon szigorú időkorlátozások vonatkoznak a visszahívási funkció feldolgozására. Ha ez nem okoz gondot az egyszerű statisztikai adatgyűjtési módban, akkor az SD-kártyán lévő PCAP fájlrögzítési módnál trükköznöm kellett, a felvételt a memóriában és a szemaforokban lévő soron keresztül rendeztem. Figyelembe véve azt a sajátosságot, hogy a visszahívást hívó folyamat az egyik magon fut, és az SD-re író folyamat egy másikon.
„Zajos levegő” alatt néhány csomag elveszik (nincs hely a sorban, és eldobják), de egy tipikus lakás „levegővel” este (5...7 AP láthatóságon belül), rögzítés PCAP-ban csomagvesztés nélkül fejeződik be.
Ezenkívül a PCAP figyeléséhez és rögzítéséhez van egy szűrési mód, amely a csomagfejlécekben található MAC listán alapul.
Például nyomon követheti egy személy megjelenését egy klubban/kávézóban, még azelőtt, hogy belépne vagy megjelenik a látókörében. Kevesen tiltják le a WiFi-t és az automatikus csatlakozást az ismert hozzáférési pontokhoz. (Most kikapcsolom..)
A rögzített forgalom megtekintése a Wiresharkban tanulságos és érdekes a térképek megértéséhez – mindez működik.
Deauth csomagokkal való munkamód
Alapértelmezés szerint ezeknek a csomagoknak a küldése tilos a libnet80211.a könyvtárban, amely források nélkül érkezik. De könnyen megjavítható néhány bit módosításával. Először kételkedtem abban, hogy érdemes-e patch-et közzétenni. De miután körbejártam a különböző helyeket a hitelesítés-eltávolító keretbeolvasási mód bekapcsolásával, arra gondoltam: „mi a franc”. Sőt, az esp8266-ban ezeknek a csomagoknak a kézbesítése nincs lezárva, és vannak összeállítások a githubon az esp8266-hoz.
Sok helyen (nem mondom meg, hol) használják a nem kívánt hozzáférési pontok elnyomását ezzel a módszerrel. És ezek nem "zsarnokok"...
És azon is meglepődtem, hogy néhol nem működött a telefonomról való internetes terjesztésem...
Az ilyen csomagok számának és RSSI-jének nyomon követésének módja nagyon hasznos annak megértéséhez, hogy „ahol a bal oldali hozzáférési pontok nem szeretik”.
router mód
Valószínűleg ez a funkció a legérdekesebb felfedeznivaló.
Az ESP32 támogatja az egyidejű működést STA + SoftAP módban. Ezért egy klasszikus NAT útválasztót implementálhat rajta.
A hálózati verem támogatásához az Espressif az lwip könyvtár (gyakorlatilag változatlan) elágazását használja.
De alapértelmezés szerint a szabványos buildben az esp-lwip könyvtár nem biztosít továbbítást az „ap” (SoftAP) és az „st” (STA) netif interfészek között.
Természetesen NAT nélkül is megteheti, de gondot okoz, ha egyszerre két vagy több STA-t csatlakoztat az 'ap' interfészhez, és szinkronizálja az IP-címeket az 'st' hálózati interfészről az 'ap'-ra. Tehát a nehézségek nem érik meg, és a NAT-on keresztül könnyebb.
Ezenkívül van egy fork esp-lwip a martin-gertől, amely egy egyszerű NAT megvalósítást ad hozzá az IP4-hez.
Bár a kezem viszketett, hogy pusztán kozmetikailag újrakészítsem (szerintem egyszerűbb volt fork of the project nélkül, de LWIP-en keresztülHOOK az összeszerelés során meghatározott funkciókat), de a lustaság győzött, és a martin-ger opciót úgy használjuk, ahogy van.
Útválasztó módban a bejövő és kimenő IP4-forgalom látható.
A képernyőn való megjelenítéshez és a statisztikák fájlba gyűjtéséhez különösen a következőket bontják ki belőle:
- A SoftAP ESP32-höz (DHCP-csomagok) csatlakozó eszköz neve
- A SoftAP ESP53-höz csatlakoztatott eszközről származó DNS-kérésekből származó URL (32-as UDP-port).
Ezenkívül engedélyezheti a forgalom rögzítését egy PCAP fájlba.
Ez a mód nagyon hasznos például annak megértéséhez, hogy mit küld a telefon a hálózatnak, és hová megy.
Elgondolkodhat más módokon is ennek a módnak a használatára, figyelembe véve a softAP ESP32 bejövő és kimenő forgalom teljes körű vezérlését a hálózati interfész szintjén: Ehernet fejléc (destMAC[6]+srcMAC[6]+type[2]) + hasznos teher (IP4, IP6, DCHP stb. típus).
Az ESP32 elvileg elég jól megbirkózik a WiFi->WiFi router funkcióval, különösebb késések nélkül halad át a normál forgalomban. Szubjektív módon az ESP32-n routerrel csatlakoztatott telefon késése nem észrevehető.
Sajnos az Espressif API nem tud szűrőt beállítani a SoftAP EPS32-höz csatlakoztatott MAC számára. Ehelyett azt javasoljuk, hogy mondjon „viszlát” (esp_wifi_deauth_sta) a már csatlakoztatott STA-knak, amelyek „nem kívánatosak”.
A csatlakoztatott STA-k MAC szerinti szűrését az esp_wifi_deauth_sta() híváson keresztül kellett végrehajtani.
Összefoglalva
Bár az ESP32-vel való munka keretein belül semmi újat nem találtam ki, talán valakinek érdekes lesz az eredmény (forráskód).
Szeretném megjegyezni, hogy a kódot kizárólag oktatási célokra írták. A „hackelés” stb. céljára szándékosan nem túl kényelmessé tették.
Nyomtatott áramköri lapot nem készítettem, mert 1.5-2 órát vett igénybe a kész sálak huzallal történő forrasztása.
És ha igen, akkor nem kész táblákból, hanem egyedi alkatrészekből kell összeállítani. Ekkor a méretek még kisebbek lesznek.
Forrás: will.com