Przejdź do głównej zawartości

ESP32 za 6 dolarów przeciwko sieci kamer za 4,37 mln — ekonomia kontrinwigilacji

· 6 min aby przeczytać
Przemysław Majdak
Full-Stack Developer, Automation Engineer & Web Security Specialist

Klasyczne wykrywanie podsłuchów i sensorów (TSCM) zaczyna się od odbiornika SDR za kilka tysięcy złotych i kończy na tym, że nikt tego nie robi. Prelekcje z tegorocznego DEF CON pokazują inną ścieżkę: pasywny nasłuch Wi-Fi i BLE na ESP32 za 6 USD, który wykrywa kamery ALPR, drony z Remote ID i policyjne kamery nasobne. Liczby robią wrażenie — sieć 211 kamer Flock kosztowała 4,37 mln USD, jej zmapowanie mieści się w 850 USD. Poniżej: co te narzędzia faktycznie potrafią, dlaczego pojedynczy układ gubi pakiety i w którym miejscu cała metoda przestaje działać.

Ciekawa jest tu ekonomia, nie elektronika

ESP32 nie robi niczego, czego nie zrobi SDR. Robi jedną rzecz inaczej: kosztuje tyle, że można go zostawić na słupie i zapomnieć. Cała teza sprowadza się do stosunku kosztów — strona inwigilująca płaci za sensor kilka tysięcy dolarów, strona wykrywająca płaci za detektor kilka dolarów.

System nadzoruKoszt systemuDetektorKoszt detektoraStosunek
Pojazd z IMSI catcherem~1 000 000 USDRayhunter na używanym sprzęcie20–40 USD~50 000 : 1
Sieć 211 kamer Flock ALPR (Las Vegas Metro)4 370 000 USDWęzeł ESP32 na kamerę850 USD (całość)~5 100 : 1
Skaner RF / zestaw TSCMtysiące USDOUI Spy na Xiao ESP32< 10 USD> 100 : 1

Zastrzeżenie, bez którego ta tabela jest ściemą: to liczby z prelekcji, nie z mojego zakupu. Kwota 4,37 mln USD dotyczy konkretnego kontraktu opłaconego z darowizny prywatnej, a 850 USD to koszt materiału na węzły, nie wdrożenia — bez zasilania, obudów, montażu i czasu ludzi. Rząd wielkości jest jednak na tyle duży, że nawet dziesięciokrotna pomyłka w oszacowaniu niczego nie zmienia.

Rayhunter to zresztą projekt EFF, nie ESP32 — działa na taniej hotspotowej modemce z drugiej ręki i wykrywa fałszywe stacje bazowe. Wrzucam go do tabeli, bo to ten sam wzorzec: sprzęt konsumencki plus open source zamiast dedykowanego odbiornika.

Co realnie daje ESP32 w tej roli

Trzy cechy układu decydują o tym, że nadaje się do pasywnego nasłuchu:

  • Tryb promiscuous w Wi-Fi. Radio wystawia ramki zarządzające (beacony, probe requesty) bez asocjacji z siecią. To wystarcza, żeby zobaczyć adresy MAC urządzeń, które same się rozgłaszają.
  • Dwa rdzenie i FreeRTOS. W wariantach typu S3 jeden rdzeń obsługuje stos BLE, drugi Wi-Fi — bez przełączania kontekstu między radiami.
  • Cena i pobór prądu. Układ da się zasilić z powerbanku i schować w kieszeni, naszywce albo skrzynce na słupie.

Dwie platformy sprzętowe, które w tych projektach powtarzają się najczęściej: Seeed Studio Xiao ESP32 (mikroskopijny, do urządzeń ubieralnych) i M5Stack Core S3 (moduły Grove, ekran, obudowa, zero lutowania). Słaby punkt M5Stacka: ekran jest pierwszą rzeczą, która pęka przy noszeniu w plecaku.

Kluczowe ograniczenie jest częstotliwościowe. Popularne układy — w tym S3 — obsługują wyłącznie 2,4 GHz. Pasmo 5 GHz pojawia się dopiero w ESP32-C5 i to nie jest szczegół, tylko warunek dalszej przydatności całej metody (wracam do tego niżej).

Cztery narzędzia i to, co faktycznie wykrywają

OUI Spy — pasywna analiza BLE i Wi-Fi pod kątem OUI, czyli pierwszych trzech bajtów adresu MAC identyfikujących producenta. Urządzenie brzęczy buzzerem, gdy w zasięgu pojawi się zdefiniowany prefiks — na przykład nadajnik kamery nasobnej. Kamery Axon, „inteligentne" kabury i sprzęt w radiowozach rozgłaszają statyczne adresy Bluetooth, więc dają się mapować jak każdy inny beacon.

Sky Spy — dekoder Remote ID. Drony cywilne w USA mają obowiązek rozgłaszać identyfikator i telemetrię (faa.gov), a broadcast Remote ID leci po Wi-Fi lub BLE, otwartym tekstem. Odbiornik dostaje pozycję drona i pozycję operatora, a numer rejestracyjny pozwala sprawdzić model. To nie jest exploit — to odczyt danych, które regulacja kazała nadawać.

FlockU — detekcja kamer ALPR firmy Flock po ich własnym ruchu Wi-Fi. Z dołożonym modułem GPS zapisuje współrzędne trafień w SPIFFS i eksportuje je do JSON-a, co daje gotowy materiał na mapę crowdsourcingową.

Fox hunting — namierzanie kierunkowe tanią anteną PCB: obracasz anteną, buzzer zmienia ton wraz z siłą sygnału. Prymitywne i skuteczne.

Wspólny mianownik: żadne z nich nie nadaje. To czysty odbiór, więc detekcja detektora jest praktycznie niemożliwa.

Jeden układ to za mało — klaster ESP-NOW

Tu wchodzi realny problem inżynierski. Pojedynczy ESP32 ma jedno radio, więc żeby objąć całe pasmo, musi skakać po kanałach. Każdy przeskok to okno, w którym pakiet z sąsiedniego kanału po prostu przepada. Przy jeździe samochodem — a tak wygląda mapowanie kamer — trafienie zależy od tego, czy akurat byłeś na właściwym kanale w ciągu tych kilkuset milisekund, gdy kamera coś nadała.

Rozwiązanie z prelekcji: klaster kilkunastu układów spiętych ESP-NOW, gdzie każdy siedzi na stałe na jednym kanale i nie skacze nigdzie. ESP-NOW to protokół Espressifu do bezpośredniej komunikacji między układami, bez access pointa i bez ruszania głównego stosu Wi-Fi. Dwanaście układów to nadal koszt poniżej stu dolarów, czyli ułamek ceny odbiornika SDR o porównywalnym pokryciu.

Słaby punkt: prąd. Dwanaście radiów nadających i odbierających jednocześnie to zasilanie, którego nie da się już wyciągnąć z byle powerbanku — i to jest główny problem konstrukcyjny takiego klastra, nie oprogramowanie.

Gdzie ta metoda przestaje działać

Uczciwie: to jest wyścig, w którym strona z budżetem ma przewagę i już się rusza.

  • Randomizacja MAC. Detekcja po OUI działa tylko dopóty, dopóki urządzenie nadaje stały prefiks producenta. Przy pełnej randomizacji trzeba przejść na fingerprinting — dane producenta w ramce reklamowej BLE, zestaw UUID usług, charakterystyka czasowa. To znacznie mniej niezawodne i łatwiejsze do zepsucia jedną aktualizacją firmware'u.
  • Ucieczka na 5 GHz i LTE. Nowe generacje kamer Flock migrują na 5 GHz albo w ogóle na łącze komórkowe. Dla układu obsługującego wyłącznie 2,4 GHz są niewidzialne — i żadna zmiana w oprogramowaniu tego nie naprawi. Jedyna odpowiedź to migracja na ESP32-C5.
  • Detekcja to nie ochrona. Wiedza, że na skrzyżowaniu stoi ALPR, nie usuwa ALPR-a. Wartość tych narzędzi jest w agregacji: mapa kilkuset trafień z wielu urządzeń to argument w rozmowie z radą miasta, pojedynczy pisk buzzera to ciekawostka.
  • Granica prawna jest ostra i biegnie dokładnie tam, gdzie kończy się pasywność. Wszystkie opisane narzędzia tylko słuchają. Próba zdalnego włączenia cudzej kamery przez lukę w BLE, zagłuszanie albo zatruwanie skanerów RF to inna kategoria czynu — i inna kategoria konsekwencji. W Polsce dochodzi jeszcze zakaz używania urządzeń zakłócających jako takich.

Co bym z tego wziął do własnego warsztatu

  • Kupuj ESP32-C5, nie S3, jeśli budujesz cokolwiek do detekcji infrastruktury miejskiej — pasmo 5 GHz przestało być opcjonalne.
  • Nie buduj jednego sensora z channel hoppingiem. Trzy układy na trzech stałych kanałach dadzą więcej trafień niż jeden skaczący po trzynastu, i nadal kosztują mniej niż obiad.
  • Zapisuj wszystko z GPS-em do JSON-a od pierwszego dnia. Pojedyncze trafienie jest bezwartościowe, zbiór trafień z czasem i pozycją — nie.
  • Trzymaj kod w trybie wyłącznie odbiorczym. Żadnych prób asocjacji, connectów, deautentykacji. To nie jest kwestia etyki, tylko kwalifikacji prawnej tego, co robisz.

Do tematu samego układu wracam nie pierwszy raz — o wkładzie w narzędzie pentesterskie na tym samym chipie pisałem w wpisie o ESP32Marauder, a o tym, że sam ESP32 też bywa problemem, a nie tylko narzędziem — w tekście o znalezisku Tarlogic.