Merge pull request #1400 from HackTricks-wiki/update_A_look_at_a_P2P_camera__LookCam_app__20250912_123723

A look at a P2P camera (LookCam app)

src/SUMMARY.md

@@ -570,6 +570,7 @@
 - [15672 - Pentesting RabbitMQ Management](network-services-pentesting/15672-pentesting-rabbitmq-management.md)
 - [24007,24008,24009,49152 - Pentesting GlusterFS](network-services-pentesting/24007-24008-24009-49152-pentesting-glusterfs.md)
 - [27017,27018 - Pentesting MongoDB](network-services-pentesting/27017-27018-mongodb.md)
+- [32100 Udp - Pentesting Pppp Cs2 P2p Cameras](network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md)
 - [44134 - Pentesting Tiller (Helm)](network-services-pentesting/44134-pentesting-tiller-helm.md)
 - [44818/UDP/TCP - Pentesting EthernetIP](network-services-pentesting/44818-ethernetip.md)
 - [47808/udp - Pentesting BACNet](network-services-pentesting/47808-udp-bacnet.md)

src/hardware-physical-access/firmware-analysis/README.md

@@ -11,6 +11,10 @@
 synology-encrypted-archive-decryption.md
 {{#endref}}
 
+{{#ref}}
+../../network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md
+{{#endref}}
+
 
 Firmware is essential software that enables devices to operate correctly by managing and facilitating communication between the hardware components and the software that users interact with. It's stored in permanent memory, ensuring the device can access vital instructions from the moment it's powered on, leading to the operating system's launch. Examining and potentially modifying firmware is a critical step in identifying security vulnerabilities.
 
@@ -309,5 +313,3 @@ To practice discovering vulnerabilities in firmware, use the following vulnerabl
 - [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation)
 
 {{#include ../../banners/hacktricks-training.md}}
-
-

src/network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md

@@ -0,0 +1,168 @@
+# 32100/UDP - Pentesting PPPP (CS2) P2P Cameras
+
+{{#include ../banners/hacktricks-training.md}}
+
+## 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.
+
+Key traits relevant to attackers:
+- 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.
+- Default server listener is reachable over UDP/32100. A minimal “hello” probe is enough to 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:
+  - [https://github.com/pmarrapese/iot/tree/master/p2p/lansearch](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)
+
+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.
+
+## Weak “Encryption” and Key Recovery
+
+Two ineffective mechanisms exist in the CS2 stack:
+
+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.
+
+2) 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):
+```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.
+
+## Control Plane: JSON Commands and Auth Bypass
+
+Many PPPP camera firmwares exchange JSON messages once the session is up. Example “login” the client sends:
+```json
+{
+  "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.
+- 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 via DownloadFile.
+3) Submit BSSID MACs to a geolocation API (e.g., Google Geolocation API) to localize the camera to tens of meters.
+
+## Memory-Safety to RCE on Embedded Firmware
+
+Typical unsafe pattern (pseudocode from 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
+```
+
+- 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:
+-
+{{#ref}}
+../binary-exploitation/stack-overflow/README.md
+{{#endref}}
+-
+{{#ref}}
+../binary-exploitation/rop-return-oriented-programing/ret2lib/README.md
+{{#endref}}
+
+## 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.
+
+## 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.
+
+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.
+
+## 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
+
+-
+{{#ref}}
+554-8554-pentesting-rtsp.md
+{{#endref}}
+-
+{{#ref}}
+../generic-methodologies-and-resources/pentesting-wifi/README.md
+{{#endref}}
+
+## References
+
+- [A look at a P2P camera (LookCam app) – Almost Secure](https://palant.info/2025/09/08/a-look-at-a-p2p-camera-lookcam-app/)
+- [PPPP device discovery on LAN (Paul Marrapese)](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)
+- [LookCam analysis (Warwick University, 2023)](https://www.dcs.warwick.ac.uk/~fenghao/files/hidden_camera.pdf)
+- [General PPPP analysis – Elastic Security Labs (2024)](https://www.elastic.co/security-labs/storm-on-the-horizon)
+- [CS2 Network sales deck (2016) – PPPP/threat model](https://prezi.com/5cztk-98izyc/cs2-network-p2p/)
+- [Anyka hardened community firmware](https://github.com/Nemobi/Anyka/)
+
+{{#include ../banners/hacktricks-training.md}}

src/network-services-pentesting/554-8554-pentesting-rtsp.md

@@ -82,6 +82,12 @@ To bruteforce: [https://github.com/Tek-Security-Group/rtsp_authgrinder](https://
 - Try to create a Gstreamer pipeline to check if they are properly encoded
 - Print a summary of all the informations Cameradar could get
 
+### See also
+
+{{#ref}}
+32100-udp-pentesting-pppp-cs2-p2p-cameras.md
+{{#endref}}
+
 ## References
 
 - [https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol](https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol)