32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Reading time: 9 minutes

Oorsig

PPPP (a.k.a. “P2P”) is ’n proprietary device connectivity stack deur CS2 Network wat wyd ingebed is in lae-koste IP-kameras en ander IoT-toestelle. Dit verskaf rendezvous, NAT traversal (UDP hole punching), ’n application-layer “reliable” stream bo-op UDP, en ’n ID-gebaseerde adresseringstelsel wat ’n mobile/desktop app toelaat om toestelle oral op die Internet te bereik deur slegs ’n apparaat-ID te ken.

Belangrike eienskappe relevant vir aanvalers:

• Toestelle registreer by drie deur verskaffer bediende rendezvous-bedieners per ID-voorvoegsel. Clients vra dieselfde bedieners om die toestel se ekstern/relay-adres te vind en probeer dan UDP hole punching. Relay-fallback bestaan.
• Die standaard bediener-luisteraar is bereikbaar oor UDP/32100. ’n Minimale “hello” probe is genoeg om bedieners en sommige toestelle te fingerprint.
• Opsionele blanket cipher en ’n spesiale “CRCEnc” modus bestaan, maar is swak by ontwerp en word tipies gedeaktiveer in gewilde ekosisteme (bv. LookCam).
• Die control plane is gewoonlik JSON-opdragte oor die PPPP-stream en ly dikwels aan ontbrekende auth en geheue-veiligheidsfoute.

Tipiese apparaat-ID-formaat (LookCam family): PREFIX-######-CCCCC, verkort in apps (bv. GHBB-000001-NRLXW → G000001NRLXW). Waargenome voorvoegsels: BHCC ("hekai"), FHBB en GHBB ("mykj").

Ontdekking en enumerasie

• Internet exposure: baie PPPP super-nodes beantwoord ’n 32100/UDP-probe. Bekende plaintext- en foutstring-antwoorde maak dit maklik om hulle te identifiseer in traffic captures en met Internet scanners.
• LAN discovery: toestelle antwoord dikwels op ’n onversleutelde soektog op die plaaslike uitsending. Gebruik Paul Marrapese se script om te enumerate:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Nota:

• Apps embed “init strings” wat obfuskede server IP-lyste en protokol-sleutels bevat. Hierdie strings is triviaal uittreikbaar uit Android/iOS/Windows clients en word dikwels oor baie produklyne hergebruik.

NAT Traversal and Transport

• Rendezvous servers leer die toestel se publieke mapping deur periodieke keepalives vanaf die toestel. Clients vra die bedieners vir die mapping en probeer dan direkte UDP-vloei met hole punching. As NAT traversal misluk, word verkeer gerelê deur aangewese PPPP relay hosts.
• Die toepassing-“stream” implementeer sy eie ACK/retx-logika bo-op UDP; heruitsendingslusse word gedupliseer oor baie kodepade en kan lossy links oorstroom.

Swak “Encryption” en Sleutelherwinning

Twee ondoeltreffende meganismes bestaan in die CS2-stapel:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• Gewoonlik gedeaktiveer deur OEMs wat LookCam gebruik.
• App-side “init string” verskaf die sleutelmateriaal wat verminder word tot ’n effektiewe 4-byte sleutel (~2^32 ruimte).
• Praktiese known-plaintext: die eerste 4 bytes van MSG_HELLO na UDP/32100 is bekend as F1 00 00 00. Die waarneming van ’n enkele versleutelde handshake laat vinnige sleutelherwinning of validasie toe.
• Sommige control messages (bv. MSG_REPORT_SESSION_READY) is altyd versleuteld met ’n library-hardcoded sleutel gedeel oor apps.

2. Registration “encryption” – PPPP_CRCEnc

• Ondanks die naam, is dit nie CRC nie. Dit is ’n vaste herhalende XOR keystream met ’n 4-byte padding check (nie geauthentiseer nie).
• LookCam networks gebruik tipies CRCEnc slegs vir die toestel → bediener registrasie (MSG_DEV_LGN_CRC). Die meeste ander verkeer bly plaintext.

Simple keystream recovery for 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)])

Bedreigingsmodel-onvereenstemming: CS2-materiale fokus op die voorkoming van DoS deur vals toestelregistrasies, nie op vertroulikheid nie. Dit verduidelik die selektiewe “enkripsie” van registrasie, terwyl video/beheer opsioneel of in klaarteks bly. Historiese PPPP-bedieners toon geen rate limiting nie, wat brute-force/misbruik op skaal moontlik maak.

Beheervlak: JSON Commands and Auth Bypass

Baie PPPP-kamera firmwares ruil JSON-boodskappe uit sodra die sessie opgestel is. Voorbeeld “login” die kliënt stuur:

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

Algemene kwesbaarheid in LookCam-class toestelle:

• Firmware ignoreer beide die LoginDev flow en per-request pwd fields (CWE-287, CWE-306). Die toestel aanvaar operasionele opdragte sonder om 'n wagwoord te valideer.
• Eksploitasie: stuur nie LoginDev nie of ignoreer die resultaat; stuur opdragte direk.

Nuttige commando's waargeneem:

• searchWiFiList – voer 'n shell-oproep na iwlist uit; laat rou uitvoer in /tmp/wifi_scan.txt.
• DownloadFile – arbitrêre pad-lees-primitive sonder padbeperkings.

Werksvloei om ligging te ontmasker via tydelike artefakte:

1. Stuur {"cmd":"searchWiFiList"}.
2. Lees /tmp/wifi_scan.txt via DownloadFile.
3. Dien BSSID MACs in by 'n geolocation API (bv. Google Geolocation API) om die kamera op 'n akkuraatheid van tientalle meters te lokaliseer.

Geheue-veiligheid na RCE op Embedded Firmware

Tipiese onveilige patroon (pseudokode van handlers):

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

• Trigger: any cmd string > 255 bytes causes a stack buffer overflow (CWE-120/121).
• Protections: no stack canary; DEP/NX and ASLR commonly disabled on these builds.
• Impact: 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

Cloud Storage Abuse (HTTP, Device-ID only)

Baie LookCam-gebrande firmwares laai opnames op na api.l040z.com (apicn.l040z.com vir BHCC) slegs oor HTTP. Waarnemings:

• Geen TLS in die firmware; die vervoer is cleartext HTTP.
• API “authentication” is device-ID only: enigiemand wat die ID ken kan opnames aflaai.
• 5 MiB chunking is hardcoded.
• Remote enablement: op boot roep die toestel http://api.l040z.com/camera/signurl; die bediener se reaksie bepaal of uploads begin. Die mobiele app kan cloud “disabled” wys selfs al geskied oplaai. ’n Derde party kan cloud koop/enable vir ’n slagoffer-ID en stilletjies beeldmateriaal insamel.

Dit is klassieke cleartext sensitive transmission (CWE-319) met ontbrekende server-side authZ.

Device-ID Enumeration and Guessing

• ID format: PREFIX-######-CCCCC and app-shortened form (e.g., GHBB-000001-NRLXW → G000001NRLXW).
• Prefix families: BHCC (hekai servers), FHBB and GHBB (mykj servers). Elke prefix kaarteer na drie rendezvous servers vir 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.
• Vorige werk het geen server-side rate-limiting waargeneem nie, wat verspreide guessing prakties maak. Die verifier-algoritme is bespoke en waarskynlik guessable of verkrygbaar deur reversing apps/firmware.

Praktiese bronne van IDs:

• Vertoon dwarsdeur die amptelike apps en dikwels leaked in gebruikers-screenshots/videos.
• AP mode SSID is gelyk aan die device ID; baie toestelle openbaar ’n oop AP tydens onboarding.

Forcing Remote Reachability

Sommige firmwares reboot in ’n lus totdat rendezvous servers bereikbaar is. As egress geblokkeer is, sal die toestel in ’n reboot-siklus bly, wat eienaars effektief dwing om dit Internet-reachable te laat en bloot te stel aan 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.

2. 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.

3. Bypass auth

• Skip LoginDev or ignore its result; send operational JSON directly.

4. Exfiltrate files / geo-locate

• Send {"cmd":"searchWiFiList"}; then DownloadFile "/tmp/wifi_scan.txt"; submit BSSIDs to a geolocation API.

5. Achieve RCE

• Send a cmd > 255 bytes to trigger the stack overflow; build ROP/ret2libc or drop shellcode (no canary/DEP/ASLR).

6. 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.

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