Pomysł stworzenia kieszonkowego narzędzia do analizy sieci WiFi przyszedł mi do głowy .
Dziękuję im za pomysł. Właśnie nie miałem nic do roboty.
Cała praca była wykonywana w ramach hobby z zamiarem uzyskania przyjemności i poszerzenia swojej wiedzy w dziedzinie technologii sieciowych. Powoli, od 1 do 4 godzin w tygodniu, od początku tego roku.
Nie planowałem zastosowań praktycznych. Tzn. to NIE jest narzędzie dla hakerów.
Na chwilę obecną cała zamierzona funkcjonalność działa. Wszystkie źródła, całkowicie gotowe do kompilacji, . Tam też znajduje się instrukcja obsługi i inne informacje. W tej notatce nie będę powtarzać informacji zamieszczonych na githubie. Opiszę tylko to, co uważam za ważne, aby opisać osobno.
Moje zdanie na temat "uniwersalnego narzędzia" i powód wyboru ESP32
Nie rościłem sobie prawa do prawdy. Każdy ma swoją. Postaram się uzasadnić swój wybór "sprzętu".
wariant zastosowania to połączenie Linuxa (pierwotnie Raspberry Pi) + "peryferiów" w postaci kontrolera (STM32) + CC1110 (rdzeń 8051) z planem wciśnięcia tam wszystkiego, co tylko możliwe (125kHz, NFC, 433mHz, USB, iButton, bluetooth, ?) wydawał mi się nieodpowiedni. Niemniej jednak, wygląda na to, że pozostanie prywatny i zamknięty (flipper-zero github "Ta organizacja nie ma publicznych repozytoriów.") i poszedłem w stronę mniej popularnego sprzętu.
Możliwe, że się mylę, i w przyszłości autorzy udostępnią źródła oprogramowania w otwartym dostępie. Ale jeśli nie, to nie kupiłbym takiego sprzętu bez źródeł.
Moje wymagania wobec "narzędzia"
Skrzynka powinna być mała (im mniejsza, tym lepsza).
Dlatego:
- Wbudowana bateria nie jest potrzebna. Przy prądzie > 100 mA w pracy z WiFi wbudowana bateria będzie albo duża, albo wystarczy na krótko. Dlatego niech "skrzynka" zasilana jest z standardowego power banka. I tak power bank zawsze leży w mojej kieszeni/samochodzie.
- Mieścić wewnątrz "skrzynki" Linuxa z narzędziami, napisanymi przez wiele lat w różnych językach przy posiadaniu małego ekranu i ubogiego zestawu przycisków nie ma sensu. Wyniki można oglądać/przetwarzać również na normalnym laptopie z pełną klawiaturą i ekranem.
- Komponenty powinny być łatwo dostępne i powszechnie znane (dostępny SDK, dużo przykładów i dokumentacji).
W rezultacie dla mnie wybór był oczywisty — ESP32.
Do wszystkich zadań opisanych w artykule, który skłonił mnie do działania, możliwości ESP32 są całkiem wystarczające. Chociaż maksymalnie, co chciałbym jeszcze zrobić, to:
- Pobawić się Bluetooth.
- Pobawić się zakresami 433mHz z najprostszym sprzętem (tylko modulacja amplitudy, co wystarcza do praktycznych potrzeb).
Łyżka dziegciu w ESP32
- SDK (IDF) ESP32 jest nieco niedopracowany.
- Część funkcjonalności (strefa WiFi, na przykład) jest dostępna bez kodów źródłowych w postaci skompilowanych bibliotek statycznych.
- Zakres 5gHz nie jest wspierany, a także występują pewne ograniczenia i niedopracowania w działaniu WiFi.
Jednak cena/rozmiary w pełni rekompensują te niedostatki.
Podstawowa funkcjonalność oprogramowania
Krótko opiszę funkcjonalność i moje zdanie na temat...
Zarządzanie ustawieniami i przesyłanie plików z SD
Wszystkie zewnętrzne zarządzanie odbywa się przez najprostsza stronę internetową, uruchamianą w osobnym punkcie menu. ESP32 działa w trybie AP WiFi i serwuje stronę pod stałym adresem IP.
Chociaż rdzenie ESP32 są dość szybkie, to jak pokazują eksperymenty, jednoczesna praca wbudowanej usługi webowej oraz np. trybu routera nie współgrają zbyt dobrze. Dlatego brak dynamicznego zarządzania i w pozostałych trybach strona nie jest dostępna.
Tym bardziej, że dla celów badawczych dynamiczne zarządzanie nie jest konieczne.
Tryb pracy z pakietami Beacon
Tryby są banalne i niezbyt interesujące. Zrobiono je 'bo można'. Dla formalności.
Przykłady są w oficjalnych przykładach Espressif.
Tryb skanowania list AP.
Właściwie, to potrafi zrobić każdy smartfon.
No i w tym trybie zapisywana jest lista AP.
Beacon spammer.
ESP32 startuje jako AP z ukrytym SSID i losowym MAC i zaczyna wysyłać [beacon frame] z wcześniej utworzonej listy SSID (stworzona ręcznie lub uzyskana wcześniej podczas skanowania listy AP)
Tryb sniffing pakietów WiFi
Programiści Espressif dodali możliwość dla aplikacji uzyskiwania przez funkcję zwrotną wszystkich pakietów WiFi 'przelatujących w powietrzu'. W rzeczywistości nie wszystkich, ponieważ można ustawić tryb tylko dla jednego stałego kanału.
Na przetwarzanie wywołania funkcji callback nałożone są surowe ograniczenia czasowe. Jeśli w przypadku trybu prostego zbierania statystyk nie stanowi to problemu, to w trybie nagrywania pliku PCAP na kartę SD trzeba było się napracować, organizując nagrywanie przez kolejkę w pamięci i semafory. Biorąc pod uwagę, że proces wywołujący callback działa na jednym rdzeniu, a proces zapisujący na SD w innym.
W przypadku 'szumnego eteru' niektóre pakiety są tracone (w kolejce nie ma miejsca, więc są odrzucane), ale przy typowym 'eterze' mieszkań w godzinach wieczornych (5..7 AP w zasięgu) nagranie do PCAP zdąża być wykonane bez utraty pakietów.
Dodatkowo, w celu monitorowania i nagrywania PCAP dostępny jest tryb filtrowania według listy MAC w nagłówkach pakietów.
Na przykład, można śledzić pojawienie się osoby w klubie/kawiarni, zanim ona w ogóle weszła lub pojawiła się w polu widzenia. Mało kto wyłącza WiFi i automatyczne połączenie z znanymi AP. (Ja teraz wyłączam...)
Przeglądanie zapisanych danych w Wireshark jest pouczające i interesujące dla zrozumienia, jak to wszystko działa.
Tryb pracy z pakietami deauth
Domyślnie, wysyłanie tych pakietów jest zabronione w bibliotece libnet80211.a, która jest dostarczana bez źródeł. Ale nie jest to trudne do naprawienia, modyfikując kilka bajtów. Na początku miałem wątpliwości, czy warto publikować łatkę. Jednak po przejściu przez różne miejsca z włączonym trybem skanowania źródeł wysyłania [deauthentication frame], pomyślałem: 'czemu nie'. Tym bardziej, że w esp8266 wysyłanie tych pakietów nie jest zablokowane i są dostępne kompilacje na github pod esp8266.
W bardzo wielu miejscach (nie będę mówił gdzie) używa się tłumienia niepożądanych AP przy użyciu tej metody. I to nie są 'chuligani'...
A ja jeszcze się dziwiłem, że to u mnie czasami nie działa udostępnianie internetu z telefonu...
Tryb monitorowania liczby i RSSI takich pakietów jest bardzo pomocny, aby zrozumieć 'gdzie nie lubią lewych AP'.
Tryb routera
Ta funkcja jest chyba najbardziej interesująca ze wszystkich do badania.
ESP32 obsługuje jednoczesną pracę w trybie STA + SoftAP. Dlatego można na nim zrealizować klasyczny router NAT.
Aby wspierać działanie stosu sieciowego, Espressif używa fork (praktycznie bez zmian) biblioteki lwip.
Jednak, domyślnie, w standardowej kompilacji, w bibliotece esp-lwip nie przewidziano przekazywania pomiędzy interfejsami netif ‘ap’(SoftAP) i ‘st’ (STA).
Oczywiście można to zrobić bez NAT, ale pojawia się problem z jednoczesnym podłączeniem dwóch lub więcej STA do interfejsu ‘ap’ oraz synchronizacją adresów IP z interfejsu sieciowego ‘st’ do ‘ap’. Tak więc trudności nie są warte zachodu i łatwiej jest to zrobić przez NAT.
Tym bardziej, że istnieje fork esp-lwip od martin-ger, w którym dodano prostą implementację NAT dla IP4.
Chociaż miałem ochotę na kosmetyczną przeróbkę (moim zdaniem, łatwiej było bez fork projektu, a przez LWIPHOOK funkcje definiowane podczas kompilacji), ale lenistwo zwyciężyło i wariant od martin-ger jest używany taki, jaki jest.
W trybie routera przeglądany jest przychodzący i wychodzący ruch IP4.
W szczególności wyodrębnia się go do wyświetlenia na ekranie oraz zbierania statystyk do pliku:
- Nazwa urządzenia, które połączyło się z SoftAP ESP32 (pakiety DHCP)
- URL z zapytań DNS (port UDP 53) od podłączonego urządzenia do SoftAP ESP32.
Dodatkowo można włączyć nagrywanie ruchu do pliku PCAP.
Ten tryb jest bardzo przydatny, aby na przykład zrozumieć, co wasz telefon wysyła do sieci i dokąd trafia.
Można wymyślić inne sposoby wykorzystania tego trybu, biorąc pod uwagę możliwość pełnego programowego zarządzania przychodzącym i wychodzącym ruchem SoftAP ESP32 na poziomie interfejsu sieciowego: Nagłówek Ehernet (destMAC[6]+srcMAC[6]+type[2]) + payload (IP4, IP6, DHCP, i inne typy).
W zasadzie, ESP32 całkiem dobrze radzi sobie z funkcją WiFi->WiFi routera, przepuszczając przez siebie normalny ruch bez większych opóźnień. Subiektywnie opóźnienia w telefonie podłączonym przez router na ESP32 nie są zauważalne.
Niestety, w API Espressif nie ma możliwości ustawienia filtru według MAC dla podłączanych do SoftAP ESP32. Zamiast tego proponuje się powiedzieć ‘do widzenia’ (esp_wifi_deauth_sta) już podłączonym STA, które są ‘niepożądane’.
Filtracja według MAC dla podłączanych STA musiała być wykonana przez wywołanie esp_wifi_deauth_sta()
Na zakończenie
Choć nie wymyśliłem nic nowego w ramach pracy z ESP32, być może komuś wynik (źródła) będzie interesujący.
Chciałbym zaznaczyć, że kod pisałem wyłącznie w celach edukacyjnych. Dla ‘hackowania’ i tym podobnych celów został specjalnie zaprojektowany tak, aby nie był zbyt wygodny.
Nie zrobiłem płytki drukowanej, ponieważ to, że aby przylutować gotowe płytki kablem zajęło około 1,5-2 godzin.
A nawet jeśli bym robił, to należałoby nie zbierać z gotowych płyt, lecz z oddzielnych komponentów. Wtedy rozmiary byłyby jeszcze mniejsze.
Źródło: habr.com
