32100/UDP - Pentesting PPPP (CS2) P2P Kamery

Reading time: 8 minutes

Przegląd

PPPP (a.k.a. “P2P”) to proprietarny stos łączności urządzeń od CS2 Network, szeroko osadzony w tanich kamerach IP i innych urządzeniach IoT. Zapewnia rendezvous, NAT traversal (UDP hole punching), warstwowy „reliable” stream na bazie UDP oraz schemat adresowania oparty na ID, pozwalając aplikacji mobilnej/desktopowej dotrzeć do urządzeń w dowolnym miejscu w Internecie znając tylko ich ID.

Kluczowe cechy istotne dla atakujących:

• Urządzenia rejestrują się do trzech serwerów rendezvous zarządzanych przez producenta dla każdego prefiksu ID. Klienci pytają te same serwery o zewnętrzny/relay adres urządzenia, po czym próbują UDP hole punching. Istnieje fallback na relay.
• Domyślny listener serwera jest dostępny przez UDP/32100. Minimalny probe „hello” wystarcza do zfingerprintingowania serwerów i niektórych urządzeń.
• Opcjonalny blanket cipher oraz specjalny tryb „CRCEnc” istnieją, ale są słabe z założenia i zazwyczaj wyłączone w popularnych ekosystemach (np. LookCam).
• Control plane to zwykle JSONowe komendy przesyłane przez PPPP stream i często cierpi na brak autoryzacji oraz błędy związane z bezpieczeństwem pamięci.

Typowy format ID urządzenia (rodzina LookCam): PREFIX-######-CCCCC, skracany w aplikacjach (np. GHBB-000001-NRLXW → G000001NRLXW). Zaobserwowane prefiksy: BHCC ("hekai"), FHBB i GHBB ("mykj").

Odkrywanie i enumeracja

• Ekspozycja w Internecie: wiele super-nodów PPPP odpowiada na probe UDP/32100. Odpowiedzi z znanym plaintextem i error-stringami ułatwiają ich identyfikację w przechwyconym ruchu i przy użyciu skanerów Internetowych.
• Odkrywanie w LAN: urządzenia często odpowiadają na niezaszyfrowane zapytanie wysłane na broadcast lokalny. Użyj skryptu Paula Marrapese do enumeracji:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Uwagi:

• Aplikacje zawierają „init strings”, które zawierają obfuskowane listy IP serwerów i klucze protokołu. Te stringi są trywialnie wydobywalne z klientów Android/iOS/Windows i często współdzielone pomiędzy wieloma liniami produktowymi.

NAT Traversal i transport

• Serwery rendezvous uczą się publicznego mapowania urządzenia dzięki okresowym keepalive wysyłanym przez urządzenie. Klienci pytają serwery o mapowanie, a następnie próbują bezpośrednich połączeń UDP używając hole punching. Jeśli NAT traversal zawiedzie, ruch jest relayowany przez wyznaczone hosty PPPP relay.
• Aplikacyjny „stream” implementuje własną logikę ACK/retx na bazie UDP; pętle retransmisji są powielone w wielu ścieżkach kodu i mogą zalać łącza o wysokiej utracie pakietów.

Słabe „szyfrowanie” i odzyskiwanie klucza

W staku CS2 istnieją dwa nieskuteczne mechanizmy:

1. Blanket cipher (opcjonalny) – P2P_Proprietary_Encrypt

• Zazwyczaj wyłączany przez OEMy używające LookCam.
• Po stronie aplikacji „init string” dostarcza materiał kluczowy, redukowany do efektywnego 4-bajtowego klucza (~2^32 przestrzeni).
• Praktyczny known-plaintext: pierwsze 4 bajty MSG_HELLO do UDP/32100 są znane i wynoszą F1 00 00 00. Zaobserwowanie pojedynczego zaszyfrowanego handshake pozwala na szybkie odzyskanie klucza lub jego walidację.
• Niektóre komunikaty kontrolne (np. MSG_REPORT_SESSION_READY) są zawsze szyfrowane twardo zakodowanym w bibliotece kluczem współdzielonym między aplikacjami.

2. Rejestracyjne „szyfrowanie” – PPPP_CRCEnc

• Pomimo nazwy, to nie jest CRC. To stały powtarzający się keystream XOR z 4-bajtową kontrolą paddingu (bez uwierzytelnienia).
• Sieci LookCam zwykle używają CRCEnc tylko do rejestracji urządzenie → serwer (MSG_DEV_LGN_CRC). Większość pozostałego ruchu pozostaje w plaintext.

Proste odzyskiwanie keystream dla PPPP_CRCEnc (Python):

# ciphertext: captured bytes of an encrypted registration message
# known: guessed/known plaintext region (e.g., JSON or constant header)
keystream = bytes([c ^ p for c, p in zip(ciphertext[:len(known)], known)])
# Decrypt more bytes by XORing with the repeating keystream
pt = bytes([c ^ keystream[i % len(keystream)] for i, c in enumerate(ciphertext)])

Niedopasowanie modelu zagrożeń: materiały CS2 skupiają się na zapobieganiu DoS poprzez fałszywe rejestracje urządzeń, a nie na poufności. To wyjaśnia selektywną „encryption” rejestracji, podczas gdy video/control pozostają opcjonalne lub w postaci cleartext. Historyczne serwery PPPP nie mają ograniczeń szybkości, umożliwiając brute-force/abuse na dużą skalę.

Płaszczyzna kontrolna: JSON Commands and Auth Bypass

Wiele firmware kamer PPPP wymienia wiadomości JSON po nawiązaniu sesji. Przykładowe „login”, które wysyła klient:

{
"cmd": "LoginDev",
"pwd": "123456"
}

Powszechna podatność w urządzeniach klasy LookCam:

• Firmware ignoruje zarówno flow LoginDev, jak i pola pwd w żądaniach (CWE-287, CWE-306). Urządzenie akceptuje polecenia operacyjne bez weryfikacji hasła.
• Eksploatacja: nie wysyłaj LoginDev lub zignoruj jego wynik; wysyłaj polecenia bezpośrednio.

Przydatne polecenia zaobserwowane:

• searchWiFiList – wywołuje iwlist; zapisuje surowe wyjście w /tmp/wifi_scan.txt.
• DownloadFile – prymityw odczytu dowolnej ścieżki (bez ograniczeń dotyczących ścieżki).

Procedura deanonimizacji lokalizacji za pomocą przemijających artefaktów:

1. Wyślij {"cmd":"searchWiFiList"}.
2. Odczytaj /tmp/wifi_scan.txt za pomocą DownloadFile.
3. Prześlij BSSID MACi do geolocation API (np. Google Geolocation API), aby zlokalizować kamerę z dokładnością do kilkudziesięciu metrów.

Od błędów bezpieczeństwa pamięci do RCE na firmware wbudowanym

Typowy niebezpieczny wzorzec (pseudokod z handlerów):

char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check

• Wyzwalacz: dowolny ciąg cmd > 255 bajtów powoduje stack buffer overflow (CWE-120/121).
• Ochrona: brak stack canary; DEP/NX i ASLR zazwyczaj wyłączone w tych buildach.
• Skutek: prosty jednopoziomowy shellcode lub klasyczny ROP/ret2libc na CPU urządzenia (np. ARM) pozwalający na pełne przejęcie i pivotowanie w LAN.

See also:

Stack Overflow

Ret2lib

Cloud Storage Abuse (HTTP, Device-ID only)

Wiele firmware’ów marki LookCam wysyła nagrania na api.l040z.com (apicn.l040z.com dla BHCC) wyłącznie przez HTTP. Obserwacje:

• Brak TLS w firmware; transport jest jawny HTTP.
• „Uwierzytelnianie” API to tylko device-ID: każdy znający ID może pobrać nagrania.
• Dzielenie na chunky po 5 MiB jest zakodowane na stałe.
• Zdalne włączenie: przy starcie urządzenie wywołuje http://api.l040z.com/camera/signurl; odpowiedź serwera decyduje, czy uploady się rozpoczną. Aplikacja mobilna może pokazywać chmurę jako „disabled” nawet gdy uploady zachodzą. Strona trzecia może zakupić/włączyć chmurę dla czyjegoś ID i po cichu zbierać materiał.

To klasyczne przesyłanie w postaci jawnego tekstu zawierające dane wrażliwe (CWE-319) z brakującą autoryzacją po stronie serwera (authZ).

Device-ID Enumeration and Guessing

• Format ID: PREFIX-######-CCCCC oraz skrócona forma używana przez aplikację (np. GHBB-000001-NRLXW → G000001NRLXW).
• Rodziny prefiksów: BHCC (hekai servers), FHBB i GHBB (mykj servers). Każdy prefiks mapuje na trzy rendezvous servers dla HA.
• Weryfikator 5-literowy używa alfabetu 22 wielkich liter (A, I, O, Q wyłączone) → 22^5 ≈ 5.15M kombinacji na bazę numeryczną.
• Wcześniejsze analizy nie wykazały limitowania zapytań po stronie serwera, co czyni rozproszone zgadywanie praktycznym. Algorytm weryfikatora jest niestandardowy i prawdopodobnie da się go odgadnąć lub uzyskać przez reversing aplikacji/firmware.

Praktyczne źródła ID:

• Wyświetlane w całej oficjalnej aplikacji i często leaked w zrzutach ekranu/filmach użytkowników.
• SSID trybu AP równa się device ID; wiele urządzeń udostępnia otwarte AP podczas onboardingu.

Forcing Remote Reachability

Niektóre firmware’y restartują się w pętli, dopóki rendezvous servers nie będą osiągalne. Jeśli egress jest zablokowany, urządzenie pozostanie w cyklu rebootu, skutecznie zmuszając właścicieli do pozostawienia go z dostępem do Internetu i wystawieniem na PPPP rendezvous.

Practical Exploitation Playbook (for repro/defense testing)

1. Obtain device ID

• Z UI aplikacji lub SSID AP; w przeciwnym razie enumeruj PREFIX+numer i bruteforce’uj przestrzeń weryfikatora 22^5.

2. Establish PPPP session

• Użyj CS2 PPPP clienta lub własnego kodu; wyciągnij listy IP serwerów i init keys z app init string; spróbuj UDP hole punching; w ostateczności użyj relay.

3. Bypass auth

• Pomiń LoginDev lub zignoruj jego wynik; wyślij bezpośrednio operational JSON.

4. Exfiltrate files / geo-locate

• Wyślij {"cmd":"searchWiFiList"}; następnie DownloadFile "/tmp/wifi_scan.txt"; przekaż BSSIDs do geolocation API.

5. Achieve RCE

• Wyślij cmd > 255 bajtów aby wywołać stack overflow; zbuduj ROP/ret2libc lub wrzuć shellcode (brak canary/DEP/ASLR).

6. Cloud access

• Interaguj z endpointami api.l040z.com używając tylko device ID; uwaga na 5 MiB chunking; włączenie chmury kontrolowane przez /camera/signurl niezależnie od stanu UI aplikacji.

Related Protocols/Services

554,8554 - Pentesting RTSP

Pentesting Wifi

References

• A look at a P2P camera (LookCam app) – Almost Secure
• PPPP device discovery on LAN (Paul Marrapese)
• LookCam analysis (Warwick University, 2023)
• General PPPP analysis – Elastic Security Labs (2024)
• CS2 Network sales deck (2016) – PPPP/threat model
• Anyka hardened community firmware