32100-udp-pentesting-pppp-cs2-p2p-cameras.md (11659B)
1 --- 2 title: "32100/UDP - Pentesting PPPP (CS2) P2P Cameras" 3 section: "Network Services" 4 sectionSlug: "network-services-pentesting" 5 sourcePath: "src/network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # 32100/UDP - Pentesting PPPP (CS2) P2P Cameras 14 15 ## Overview 16 17 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.<sup>[[1]](#references)</sup> 18 19 Key traits relevant to attackers:<sup>[[1]](#references)[[4]](#references)</sup> 20 21 - 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. 22 - The rendezvous-server listener is commonly reachable over UDP/32100. A minimal “hello” probe can fingerprint servers and some devices. 23 - Optional blanket cipher and a special “CRCEnc” mode exist but are weak by design and are typically disabled in popular ecosystems (e.g., LookCam). 24 - Control plane is usually JSON commands over the PPPP stream and commonly suffers from missing auth and memory-safety bugs. 25 26 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"). 27 28 ## Discovery and Enumeration 29 30 - 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. 31 - LAN discovery: devices often reply to an unencrypted search on local broadcast. Use Paul Marrapese’s script to enumerate:<sup>[[2]](#references)</sup> 32 - [https://github.com/pmarrapese/iot/tree/master/p2p/lansearch](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)<sup>[[2]](#references)</sup> 33 34 Notes: 35 - 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. 36 37 ## NAT Traversal and Transport 38 39 - 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. 40 - 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.<sup>[[4]](#references)</sup> 41 42 ## Weak “Encryption” and Key Recovery 43 44 Two ineffective mechanisms exist in the CS2 stack:<sup>[[1]](#references)</sup> 45 46 1) Blanket cipher (optional) – P2P_Proprietary_Encrypt 47 - Usually disabled by OEMs using LookCam. 48 - App-side “init string” supplies the key material which is reduced to an effective 4-byte key (~2^32 space). 49 - 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. 50 - Some control messages (e.g., MSG_REPORT_SESSION_READY) are always encrypted with a library-hardcoded key shared across apps. 51 52 2) Registration “encryption” – PPPP_CRCEnc 53 - Despite the name, this is not CRC. It’s a fixed repeating XOR keystream with a 4-byte padding check (not authenticated). 54 - LookCam networks typically use CRCEnc only for the device → server registration (MSG_DEV_LGN_CRC). Most other traffic stays plaintext. 55 56 Simple keystream recovery for PPPP_CRCEnc (Python): 57 ```python 58 # ciphertext: captured bytes of an encrypted registration message 59 # known: guessed/known plaintext region (e.g., JSON or constant header) 60 keystream = bytes([c ^ p for c, p in zip(ciphertext[:len(known)], known)]) 61 # Decrypt more bytes by XORing with the repeating keystream 62 pt = bytes([c ^ keystream[i % len(keystream)] for i, c in enumerate(ciphertext)]) 63 ``` 64 65 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.<sup>[[1]](#references)[[5]](#references)</sup> 66 67 ## Control Plane: JSON Commands and Auth Bypass 68 69 Many PPPP camera firmwares exchange JSON messages once the session is up. Example “login” the client sends: 70 ```json 71 { 72 "cmd": "LoginDev", 73 "pwd": "123456" 74 } 75 ``` 76 77 Common vulnerability in LookCam-class devices: 78 - Firmware ignores both the LoginDev flow and per-request pwd fields (CWE-287, CWE-306). The device accepts operational commands without validating a password.<sup>[[3]](#references)</sup> 79 - Exploitation: do not send LoginDev or ignore its result; send commands directly. 80 81 Useful commands observed: 82 - searchWiFiList – shells out to iwlist; leaves raw output in /tmp/wifi_scan.txt. 83 - DownloadFile – arbitrary path read primitive without path restrictions. 84 85 Workflow to deanonymize location via transient artifacts: 86 87 1. Send `{"cmd":"searchWiFiList"}`. 88 2. Read `/tmp/wifi_scan.txt` through `DownloadFile`. 89 3. Submit observed BSSIDs to an authorized geolocation service. Accuracy depends on the service's database and local access-point density. 90 91 ## Memory-Safety to RCE on Embedded Firmware 92 93 Typical unsafe pattern (pseudocode from handlers): 94 ```c 95 char buf[256]; 96 char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring; 97 memset(buf, 0, sizeof(buf)); 98 memcpy(buf, cmd, strlen(cmd)); // no bound check 99 ``` 100 101 - Trigger: any cmd string > 255 bytes causes a stack buffer overflow (CWE-120/121). 102 - Protections: the analyzed builds lacked stack canaries, NX, and ASLR; verify each target rather than assuming all PPPP firmware has the same build settings. 103 - Impact: straightforward single-stage shellcode or classic ROP/ret2libc on the device’s CPU (e.g., ARM) for full compromise and LAN pivoting.<sup>[[1]](#references)</sup> 104 105 See also: 106 - 107 [Readme](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/binary-exploitation/stack-overflow/README.md) 108 - 109 [Readme](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/binary-exploitation/rop-return-oriented-programing/ret2lib/README.md) 110 111 ## Cloud Storage Abuse (HTTP, Device-ID only) 112 113 Many LookCam-branded firmwares upload recordings to api.l040z.com (apicn.l040z.com for BHCC) over HTTP only. Observations: 114 - No TLS in firmware; transport is cleartext HTTP. 115 - API “authentication” is device-ID only: anyone knowing the ID can fetch recordings. 116 - 5 MiB chunking is hardcoded. 117 - 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. 118 119 This is classic cleartext sensitive transmission (CWE-319) with missing server-side authZ.<sup>[[1]](#references)</sup> 120 121 ## Device-ID Enumeration and Guessing 122 123 - ID format: PREFIX-######-CCCCC and app-shortened form (e.g., GHBB-000001-NRLXW → G000001NRLXW). 124 - Prefix families: BHCC (hekai servers), FHBB and GHBB (mykj servers). Each prefix maps to three rendezvous servers for HA. 125 - The 5-letter verifier uses an alphabet of 22 uppercase letters (A, I, O, Q excluded) → 22^5 ≈ 5.15M combos per numeric base. 126 - 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.<sup>[[1]](#references)</sup> 127 128 Practical sources of IDs: 129 - Displayed all over the official apps and often leaked in user screenshots/videos. 130 - AP mode SSID equals the device ID; many devices expose an open AP during onboarding. 131 132 ## Forcing Remote Reachability 133 134 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.<sup>[[1]](#references)</sup> 135 136 ## Practical Exploitation Playbook (for repro/defense testing) 137 138 1. Obtain device ID 139 - From app UI or AP SSID; otherwise enumerate PREFIX+number and brute 22^5 verifier space. 140 141 2. Establish PPPP session 142 - 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. 143 144 3. Test the documented authentication bypass 145 - Skip LoginDev or ignore its result; send operational JSON directly. 146 147 4. Validate file-read and geolocation exposure 148 - Send {"cmd":"searchWiFiList"}; then DownloadFile "/tmp/wifi_scan.txt"; submit BSSIDs to a geolocation API. 149 150 5. Validate memory safety in a lab 151 - Send a cmd > 255 bytes to trigger the stack overflow; build ROP/ret2libc or drop shellcode (no canary/DEP/ASLR). 152 153 6. Test cloud authorization 154 - 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. 155 156 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.<sup>[[1]](#references)[[3]](#references)</sup> 157 158 ## Defensive validation 159 160 - Block unnecessary outbound rendezvous/relay traffic and inbound UDP/32100 at network boundaries, then verify that required local operation still works. 161 - Inventory device IDs exposed in SSIDs, screenshots, support logs, and mobile-app telemetry. 162 - Capture traffic to confirm whether control/video/cloud data is encrypted and authenticated rather than trusting a vendor's “P2P encrypted” label. 163 - 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.<sup>[[6]](#references)</sup> 164 165 ## Related Protocols/Services 166 167 - 168 [554 8554 Pentesting Rtsp](/hacktricks/network-services-pentesting/554-8554-pentesting-rtsp) 169 - 170 [Readme](https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/generic-methodologies-and-resources/pentesting-wifi/README.md) 171 172 ## References 173 174 - [1] [A look at a P2P camera (LookCam app) – Almost Secure](https://palant.info/2025/09/08/a-look-at-a-p2p-camera-lookcam-app/) 175 - [2] [PPPP device discovery on LAN (Paul Marrapese)](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch) 176 - [3] [LookCam analysis (Warwick University, 2023)](https://www.dcs.warwick.ac.uk/~fenghao/files/hidden_camera.pdf) 177 - [4] [General PPPP analysis – Elastic Security Labs (2024)](https://www.elastic.co/security-labs/storm-on-the-horizon) 178 - [5] [CS2 Network sales deck (2016) – PPPP/threat model](https://prezi.com/5cztk-98izyc/cs2-network-p2p/) 179 - [6] [Anyka hardened community firmware](https://github.com/Nemobi/Anyka/)