DΛΣMӨП

// HackTricks · Network Services

32100/UDP - Pentesting PPPP (CS2) P2P Cameras

32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Overview

PPPP (a.k.a. “P2P”) is a proprietary device connectivity stack by CS2 Network that’s widely embedded in low-cost IP cameras and other IoT devices. It provides rendezvous, NAT traversal (UDP hole punching), an application-layer “reliable” stream on top of UDP, and an ID-based addressing scheme, allowing a mobile/desktop app to reach devices anywhere on the Internet by knowing only a device ID.[1]

Key traits relevant to attackers:[1][4]

  • Devices register to three vendor-operated rendezvous servers per ID prefix. Clients query the same servers to find the device’s external/relay address, then attempt UDP hole punching. Relay fallback exists.
  • The rendezvous-server listener is commonly reachable over UDP/32100. A minimal “hello” probe can fingerprint servers and some devices.
  • Optional blanket cipher and a special “CRCEnc” mode exist but are weak by design and are typically disabled in popular ecosystems (e.g., LookCam).
  • Control plane is usually JSON commands over the PPPP stream and commonly suffers from missing auth and memory-safety bugs.

Typical device ID format (LookCam family): PREFIX-######-CCCCC, shortened in apps (e.g., GHBB-000001-NRLXW → G000001NRLXW). Observed prefixes: BHCC (“hekai”), FHBB and GHBB (“mykj”).

Discovery and Enumeration

  • Internet exposure: many PPPP super-nodes answer a 32100/UDP probe. Known plaintext and error-string responses make them easy to identify in traffic captures and with Internet scanners.
  • LAN discovery: devices often reply to an unencrypted search on local broadcast. Use Paul Marrapese’s script to enumerate:[2]

Notes:

  • Apps embed “init strings” that contain obfuscated server IP lists and protocol keys. These strings are trivially extractable from Android/iOS/Windows clients and often reused across many product lines.

NAT Traversal and Transport

  • Rendezvous servers learn the device’s public mapping by periodic keepalives from the device. Clients query the servers for the mapping and then attempt direct UDP flows using hole punching. If NAT traversal fails, traffic is relayed by designated PPPP relay hosts.
  • The application “stream” implements its own ACK/retx logic on top of UDP; retransmission loops are duplicated across many code paths and can flood lossy links.[4]

Weak “Encryption” and Key Recovery

Two ineffective mechanisms exist in the CS2 stack:[1]

  1. Blanket cipher (optional) – P2P_Proprietary_Encrypt
  • Usually disabled by OEMs using LookCam.
  • App-side “init string” supplies the key material which is reduced to an effective 4-byte key (~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.
  • Some control messages (e.g., MSG_REPORT_SESSION_READY) are always encrypted with a library-hardcoded key shared across apps.
  1. Registration “encryption” – PPPP_CRCEnc
  • Despite the name, this is not CRC. It’s a fixed repeating XOR keystream with a 4-byte padding check (not authenticated).
  • LookCam networks typically use CRCEnc only for the device → server registration (MSG_DEV_LGN_CRC). Most other traffic stays 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)])

Threat model mismatch: CS2 materials focus on preventing DoS via fake device registrations, not on confidentiality. This explains selective “encryption” of registration while video/control remain optional or cleartext. Historical PPPP servers show no rate limiting, enabling brute-force/abuse at scale.[1][5]

Control Plane: JSON Commands and Auth Bypass

Many PPPP camera firmwares exchange JSON messages once the session is up. Example “login” the client sends:

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

Common vulnerability in LookCam-class devices:

  • Firmware ignores both the LoginDev flow and per-request pwd fields (CWE-287, CWE-306). The device accepts operational commands without validating a password.[3]
  • Exploitation: do not send LoginDev or ignore its result; send commands directly.

Useful commands observed:

  • searchWiFiList – shells out to iwlist; leaves raw output in /tmp/wifi_scan.txt.
  • DownloadFile – arbitrary path read primitive without path restrictions.

Workflow to deanonymize location via transient artifacts:

  1. Send {"cmd":"searchWiFiList"}.
  2. Read /tmp/wifi_scan.txt through DownloadFile.
  3. Submit observed BSSIDs to an authorized geolocation service. Accuracy depends on the service’s database and local access-point density.

Memory-Safety to RCE on Embedded Firmware

Typical unsafe pattern (pseudocode from 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: the analyzed builds lacked stack canaries, NX, and ASLR; verify each target rather than assuming all PPPP firmware has the same build settings.
  • Impact: straightforward single-stage shellcode or classic ROP/ret2libc on the device’s CPU (e.g., ARM) for full compromise and LAN pivoting.[1]

See also:

Readme

Readme

Cloud Storage Abuse (HTTP, Device-ID only)

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

  • No TLS in firmware; transport is cleartext HTTP.
  • API “authentication” is device-ID only: anyone knowing the ID can fetch recordings.
  • 5 MiB chunking is hardcoded.
  • Remote enablement: 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.[1]

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). 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.[1]

Practical sources of 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.

Forcing Remote Reachability

Some 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.[1]

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. Test the documented authentication bypass
  • Skip LoginDev or ignore its result; send operational JSON directly.
  1. Validate file-read and geolocation exposure
  • Send {“cmd”:“searchWiFiList”}; then DownloadFile “/tmp/wifi_scan.txt”; submit BSSIDs to a geolocation API.
  1. Validate memory safety in a lab
  • Send a cmd > 255 bytes to trigger the stack overflow; build ROP/ret2libc or drop shellcode (no canary/DEP/ASLR).
  1. Test cloud authorization
  • 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.

The concrete hostnames, commands, missing checks, and exploitability observations above describe the analyzed LookCam/Anyka ecosystem; they are not universal properties of every product that embeds a PPPP-derived library.[1][3]

Defensive validation

  • Block unnecessary outbound rendezvous/relay traffic and inbound UDP/32100 at network boundaries, then verify that required local operation still works.
  • Inventory device IDs exposed in SSIDs, screenshots, support logs, and mobile-app telemetry.
  • Capture traffic to confirm whether control/video/cloud data is encrypted and authenticated rather than trusting a vendor’s “P2P encrypted” label.
  • Replace unsupported vendor firmware where feasible. Compatible Anyka devices have community firmware projects, but hardware support and security properties must be evaluated per model before flashing.[6]

554 8554 Pentesting Rtsp

Readme

References