# Pppp Camera Pentesting

> 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.

- Skill: `abelrguezr/pppp-camera-pentesting` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add abelrguezr/pppp-camera-pentesting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abelrguezr/pppp-camera-pentesting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: abelrguezr (https://skillmd.com/u/abelrguezr)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/abelrguezr/pppp-camera-pentesting

---


# 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

```bash
# 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**:
```python
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**:
```c
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**
   ```json
   {"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.

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

### `device_id_enumerate.py`
Enumerate device IDs in a prefix range.

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

### `json_commands.py`
Send JSON commands to bypass authentication.

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

### `wifi_geolocate.py`
Extract WiFi list and geolocate the device.

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

### `cloud_access.py`
Access cloud storage endpoints.

```bash
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](https://palant.info/2025/09/08/a-look-at-a-p2p-camera-lookcam-app/)
- [PPPP device discovery - Paul Marrapese](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)
- [LookCam analysis - Warwick University](https://www.dcs.warwick.ac.uk/~fenghao/files/hidden_camera.pdf)
- [PPPP analysis - Elastic Security Labs](https://www.elastic.co/security-labs/storm-on-the-horizon)
- [Anyka hardened firmware](https://github.com/Nemobi/Anyka/)

## 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