32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Reading time: 9 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Overview

PPPP (a.k.a. “P2P”) ni stack ya muunganisho ya kifaa ya umiliki kutoka CS2 Network ambayo imejengwa sana katika kamera za IP za gharama nafuu na vifaa vingine vya IoT. Inatoa rendezvous, NAT traversal (UDP hole punching), stream ya application-layer iliyohakikishwa juu ya UDP, na mpangilio wa anuani kwa msingi wa ID, ikiruhusu app ya mobile/desktop kufikia vifaa popote mtandaoni kwa kujua tu device ID.

Sifa kuu zinazohusiana na watapeli:

  • Vifaa hujisajili kwa rendezvous servers tatu zinazofanywa na vendor kwa kila ID prefix. Clients huuliza server hizo kupata anwani ya external/relay ya kifaa, kisha hujaribu UDP hole punching. Kuna fallback ya relay.
  • Default server listener inapatikana kupitia UDP/32100. Probe ndogo ya “hello” inatosha kwa fingerprinting ya servers na baadhi ya vifaa.
  • Kuna blanket cipher ya hiari na mode maalum ya “CRCEnc” lakini zimetengenezwa dhaifu na kawaida zimezimwa katika ecosystems maarufu (e.g., LookCam).
  • Control plane kwa kawaida ni amri za JSON juu ya stream ya PPPP na mara nyingi hugongwa na kukosa auth na bugs za memory-safety.

Muundo wa kawaida wa device ID (familia ya LookCam): PREFIX-######-CCCCC, zilizopunguzwa katika apps (e.g., GHBB-000001-NRLXW → G000001NRLXW). Prefixes zilizoshuhudiwa: BHCC ("hekai"), FHBB na GHBB ("mykj").

Discovery and Enumeration

  • Internet exposure: super-nodes nyingi za PPPP hujibu probe ya 32100/UDP. Known plaintext na majibu ya error-string huwafanya rahisi kutambuliwa katika traffic captures na kwa Internet scanners.
  • LAN discovery: devices mara nyingi hujibu kwa search isiyo-encrypted kwenye local broadcast. Tumia script ya Paul Marrapese kuorodhesha:
  • https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Vidokezo:

  • Apps zinaweka “init strings” ambazo zina orodha za server IP zilizofichwa na protocol keys. Strings hizi ni rahisi kuzichimbua kutoka kwa clients za Android/iOS/Windows na mara nyingi zinatumika tena kwenye mistari mingi ya bidhaa.

NAT Traversal and Transport

  • Rendezvous servers hujifunza public mapping ya kifaa kupitia keepalives ya kipindi kutoka kwa kifaa. Clients huuliza servers kwa mapping kisha hujaribu flows za moja kwa moja za UDP kwa kutumia hole punching. Ikiwa NAT traversal inashindwa, trafiki hurushwa kupitia PPPP relay hosts zilizoteuliwa.
  • Stream ya application inatekeleza logic yake ya ACK/retx juu ya UDP; retransmission loops zimeirudishwa katika njia nyingi za code na zinaweza kuzidisha (flood) links zenye upotevu.

Weak “Encryption” and Key Recovery

Kuna mechanisms mbili zisizo na ufanisi katika stack ya CS2:

  1. Blanket cipher (optional) – P2P_Proprietary_Encrypt
  • Kwa kawaida imezimwa na OEMs zinazotumia LookCam.
  • App-side “init string” hutoa key material ambayo hupunguzwa hadi key ya ufanisi ya 4-byte (~2^32 space).
  • Practical known-plaintext: the first 4 bytes of MSG_HELLO to UDP/32100 are known to be F1 00 00 00. Observing a single encrypted handshake allows rapid key recovery or validation.
  • Baadhi ya control messages (e.g., MSG_REPORT_SESSION_READY) huwa zimefungwa kila mara kwa library-hardcoded key inayoshirikiwa kati ya apps.
  1. Registration “encryption” – PPPP_CRCEnc
  • Licha ya jina, hii si CRC. Ni fixed repeating XOR keystream yenye 4-byte padding check (si authenticated).
  • Mitandao ya LookCam kwa kawaida hutumia CRCEnc tu kwa device → server registration (MSG_DEV_LGN_CRC). Trafiki nyingine nyingi hubaki plaintext.

Simple keystream recovery for PPPP_CRCEnc (Python):

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)])

Ukosefu wa ulinganifu wa modeli ya tishio: nyenzo za CS2 zinazingatia kuzuia DoS kupitia usajili wa vifaa bandia, si ulinzi wa usiri. Hii inaelezea “encryption” teuliwa ya usajili ilhali video/udhibiti zinabaki chaguo au cleartext. Seva za PPPP za kihistoria zinaonyesha kutokuwepo kwa rate limiting, kuruhusu brute-force/abuse kwa wingi.

Safu ya Udhibiti: JSON Amri na Auth Bypass

Firmware nyingi za kamera za PPPP hubadilishana ujumbe za JSON mara tu kikao kinapoanzishwa. Mfano wa “login” ambao mteja anamtumia:

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

Udhaifu wa kawaida katika vifaa vya LookCam-class:

  • Firmware hunyang'anywa mtiririko wa LoginDev na mashamba ya pwd ya kila ombi (CWE-287, CWE-306). Kifaa kinakubali amri za uendeshaji bila kuthibitisha nenosiri.
  • Exploitation: usitume LoginDev au puuza matokeo yake; tuma amri moja kwa moja.

Amri muhimu zilizobainika:

  • searchWiFiList – huendesha iwlist kupitia shell; huacha matokeo asilia katika /tmp/wifi_scan.txt.
  • DownloadFile – primitive ya kusoma path yoyote bila vizuizi vya path.

Hatua za deanonymize eneo kwa kutumia artifacts za muda:

  1. Tuma {"cmd":"searchWiFiList"}.
  2. Soma /tmp/wifi_scan.txt kupitia DownloadFile.
  3. Tuma BSSID MACs kwa geolocation API (mfano, Google Geolocation API) ili kuweka kamera ndani ya mita kadhaa.

Usalama wa Kumbukumbu hadi RCE kwenye Embedded Firmware

Mfano wa kawaida usio salama (pseudocode kutoka handlers):

c
char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check
  • Kichocheo: any cmd string > 255 bytes causes a stack buffer overflow (CWE-120/121).
  • Ulinzi: no stack canary; DEP/NX and ASLR commonly disabled on these builds.
  • Athari: straightforward single-stage shellcode or classic ROP/ret2libc on the device’s CPU (e.g., ARM) for full compromise and LAN pivoting.

See also:

Stack Overflow

Ret2lib

Matumizi mabaya ya Cloud Storage (HTTP, Device-ID pekee)

Many LookCam-branded firmwares upload recordings to api.l040z.com (apicn.l040z.com for BHCC) over HTTP only. Observations:

  • Hakuna TLS in firmware; transport is cleartext HTTP.
  • API “authentication” ni device-ID pekee: anyone knowing the ID can fetch recordings.
  • 5 MiB chunking is hardcoded.
  • Uwezeshaji wa mbali: on boot the device calls http://api.l040z.com/camera/signurl; the server’s response decides whether uploads start. The mobile app may show cloud “disabled” even when uploads occur. A third party can purchase/enable cloud for a victim ID and silently collect footage.

This is classic cleartext sensitive transmission (CWE-319) with missing server-side authZ.

Uorodheshaji na Kukisia Device-ID

  • Umbizo la ID: PREFIX-######-CCCCC and app-shortened form (e.g., GHBB-000001-NRLXW → G000001NRLXW).
  • Prefix families: BHCC (hekai servers), FHBB and GHBB (mykj servers). Each prefix maps to three rendezvous servers for HA.
  • The 5-letter verifier uses an alphabet of 22 uppercase letters (A, I, O, Q excluded) → 22^5 ≈ 5.15M combos per numeric base.
  • Prior work observed no server-side rate-limiting, making distributed guessing practical. The verifier algorithm is bespoke and likely guessable or obtainable by reversing apps/firmware.

Vyanzo vya vitendo vya IDs:

  • Displayed all over the official apps and often leaked in user screenshots/videos.
  • AP mode SSID equals the device ID; many devices expose an open AP during onboarding.

Kulazimisha Upatikanaji wa Mbali

Baadhi ya firmwares reboot in a loop until rendezvous servers are reachable. If egress is blocked, the device will remain in a reboot cycle, effectively coercing owners to leave it Internet-reachable and exposed to PPPP rendezvous.

Practical Exploitation Playbook (for repro/defense testing)

  1. Obtain device ID
  • From app UI or AP SSID; otherwise enumerate PREFIX+number and brute 22^5 verifier space.
  1. Establish PPPP session
  • Use a CS2 PPPP client or custom code; extract server IP lists and init keys from the app init string; attempt UDP hole punching; fall back to relay.
  1. Bypass auth
  • Skip LoginDev or ignore its result; send operational JSON directly.
  1. Exfiltrate files / geo-locate
  • Send {"cmd":"searchWiFiList"}; then DownloadFile "/tmp/wifi_scan.txt"; submit BSSIDs to a geolocation API.
  1. Achieve RCE
  • Send a cmd > 255 bytes to trigger the stack overflow; build ROP/ret2libc or drop shellcode (no canary/DEP/ASLR).
  1. Cloud access
  • Interact with api.l040z.com endpoints using only the device ID; note 5 MiB chunking; cloud enablement controlled by /camera/signurl regardless of the app UI state.

554,8554 - Pentesting RTSP

Pentesting Wifi

Marejeo

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks