PPPP (CS2) P2P Camera Pentesting

A skill for security testing PPPP (P2P) protocol-based IP cameras and IoT devices manufactured by CS2 Network and its OEM partners.

What is PPPP?

PPPP is a proprietary device connectivity stack widely embedded in low-cost IP cameras. It provides:

• NAT traversal via UDP hole punching
• Rendezvous-based device discovery
• Application-layer reliable streams over UDP
• ID-based addressing (no public IP needed)

Why this matters for pentesting: Many PPPP devices have critical vulnerabilities including missing authentication, weak encryption, memory safety bugs, and cleartext cloud storage.

Quick Start

# 1. Probe for PPPP servers on UDP/32100
python scripts/pppp_probe.py --target <ip> --port 32100

# 2. Enumerate device IDs in a prefix range
python scripts/device_id_enumerate.py --prefix GHBB --start 000001 --end 000100

# 3. Send JSON commands to bypass auth
python scripts/json_commands.py --device-id <ID> --cmd "searchWiFiList"

# 4. Extract WiFi list and geolocate
python scripts/wifi_geolocate.py --device-id <ID> --api-key <google-key>

# 5. Access cloud storage
python scripts/cloud_access.py --device-id <ID> --action list

Attack Surface Overview

1. UDP/32100 Discovery

PPPP devices and servers listen on UDP port 32100. A minimal "hello" probe fingerprints them.

Known plaintext: First 4 bytes of MSG_HELLO are

F1 00 00 00

Use case: Identify PPPP infrastructure in network scans or traffic captures.

2. Device ID Format

Standard format:

PREFIX-######-CCCCC

• PREFIX: Vendor identifier (BHCC, FHBB, GHBB)
• ######: 6-digit numeric sequence
• CCCCC: 5-letter verifier (22 chars: excludes A, I, O, Q)

App-shortened form:

G000001NRLXW

(prefix first char + number + verifier)

Prefix families:

• BHCC

  : Hekai servers

• FHBB

  ,

  GHBB

  : Mykj servers

Each prefix maps to 3 rendezvous servers for high availability.

3. Weak Encryption Mechanisms

Blanket Cipher (P2P_Proprietary_Encrypt)

• Usually disabled by LookCam OEMs
• Effective 4-byte key (~2^32 space)
• Known-plaintext attack: MSG_HELLO starts with

  F1 00 00 00

• Single encrypted handshake enables key recovery

CRCEnc (Registration "Encryption")

• Not CRC - it's a fixed repeating XOR keystream
• 4-byte padding check (not authenticated)
• Used only for device→server registration (MSG_DEV_LGN_CRC)
• Most traffic remains plaintext

Keystream recovery:

ciphertext = captured_bytes
known = b'{"cmd":'  # or other known plaintext
keystream = bytes([c ^ p for c, p in zip(ciphertext[:len(known)], known)])
pt = bytes([c ^ keystream[i % len(keystream)] for i, c in enumerate(ciphertext)])

4. Authentication Bypass

Critical vulnerability: Many LookCam-class devices ignore LoginDev and password fields entirely.

Exploitation: Skip authentication and send operational commands directly.

Common vulnerable commands:

• searchWiFiList

  - Shells out to

  iwlist

  , output in

  /tmp/wifi_scan.txt

• DownloadFile

  - Arbitrary path read without restrictions

• UploadFile

  - Arbitrary path write

5. Memory Safety to RCE

Typical vulnerable pattern:

char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memcpy(buf, cmd, strlen(cmd));  // No bound check!

Trigger: Any

cmd

string > 255 bytes causes stack buffer overflow

Protections: Typically none (no canary, DEP/NX disabled, ASLR disabled)

Impact: Full RCE via shellcode or ROP/ret2libc on ARM

6. Cloud Storage Abuse

Endpoint:

api.l040z.com

(or

apicn.l040z.com

for BHCC)

Vulnerabilities:

• Cleartext HTTP (no TLS)
• Authentication is device-ID only
• 5 MiB chunking hardcoded
• Cloud enablement controlled by

  /camera/signurl

  (app UI may show "disabled" while uploads occur)

Attack: Anyone with device ID can fetch recordings.

Practical Exploitation Workflow

Phase 1: Reconnaissance

1. Obtain device ID

   • From app UI or AP SSID (AP mode SSID = device ID)
   • Enumerate PREFIX + number + brute 22^5 verifier space
   • No server-side rate limiting observed

2. Probe rendezvous servers

   • Query servers for device mapping
   • Attempt UDP hole punching
   • Fall back to relay if NAT traversal fails

Phase 2: Session Establishment

1. Extract server IP lists and init keys from app init string
2. Establish PPPP session via UDP/32100
3. Handle NAT traversal (hole punching or relay)

Phase 3: Exploitation

1. Bypass authentication

   • Skip LoginDev or ignore result
   • Send operational JSON directly

2. Exfiltrate sensitive data

   {"cmd": "searchWiFiList"}
   {"cmd": "DownloadFile", "path": "/tmp/wifi_scan.txt"}
   

3. Geolocate via WiFi

   • Parse BSSID MACs from wifi_scan.txt
   • Submit to Google Geolocation API
   • Accuracy: tens of meters

4. Achieve RCE

   • Send

     cmd

     > 255 bytes to trigger overflow
   • Build ROP chain or drop shellcode
   • No canary/DEP/ASLR to bypass

5. Access cloud storage

   • Query

     api.l040z.com

     with device ID
   • Download 5 MiB chunks
   • Enable cloud for victim ID via

     /camera/signurl

Scripts Reference

pppp_probe.py

Probe PPPP servers and devices on UDP/32100.

python scripts/pppp_probe.py --target <ip> --port 32100 [--timeout 2]

device_id_enumerate.py

Enumerate device IDs in a prefix range.

python scripts/device_id_enumerate.py --prefix GHBB --start 000001 --end 000100 [--workers 10]

json_commands.py

Send JSON commands to bypass authentication.

python scripts/json_commands.py --device-id <ID> --cmd <command> [--args <json>]

wifi_geolocate.py

Extract WiFi list and geolocate the device.

python scripts/wifi_geolocate.py --device-id <ID> --api-key <google-key>

cloud_access.py

Access cloud storage endpoints.

python scripts/cloud_access.py --device-id <ID> --action <list|download|enable> [--chunk <N>]

Safety and Legal Considerations

Only test devices you own or have explicit authorization to test.

• PPPP cameras are often consumer devices with real privacy implications
• Cloud storage abuse can expose sensitive video footage
• RCE exploitation can compromise entire networks
• WiFi geolocation reveals precise physical locations

Defense recommendations:

• Update firmware to latest versions
• Disable cloud storage if not needed
• Use strong, unique passwords (even if ignored, future fixes may use them)
• Isolate IoT devices on separate VLANs
• Monitor UDP/32100 traffic for PPPP activity

Related Resources

• LookCam analysis - Almost Secure
• PPPP device discovery - Paul Marrapese
• LookCam analysis - Warwick University
• PPPP analysis - Elastic Security Labs
• Anyka hardened firmware

Troubleshooting

No response on UDP/32100:

• Check firewall rules
• Verify device is online and registered
• Try different rendezvous servers

Authentication bypass not working:

• Some firmwares may have patched this
• Try sending LoginDev with empty password first
• Check for version-specific behavior

RCE not triggering:

• Verify cmd length > 255 bytes
• Check for ASLR/DEP (rare but possible)
• Try different shellcode/ROP chains for target architecture

Cloud access fails:

• Verify device ID format
• Check if cloud is enabled for the device
• Try both api.l040z.com and apicn.l040z.com