pppp-camera-pentesting

name

pppp-camera-pentesting

description

Pentest PPPP (CS2) P2P IP cameras and IoT devices. Use this skill whenever the user mentions P2P cameras, IP camera pentesting, PPPP protocol, CS2 Network, LookCam, device ID enumeration, or wants to test IoT camera security. This skill covers UDP/32100 discovery, weak encryption analysis, authentication bypass, JSON command injection, buffer overflow exploitation, and cloud storage abuse on PPPP-based cameras.

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