32100/UDP - Pentesting PPPP (CS2) P2P Cameras

Reading time: 9 minutes

Overview

PPPP (a.k.a. “P2P”) é uma stack proprietária de conectividade de dispositivos da CS2 Network amplamente embutida em câmeras IP de baixo custo e outros dispositivos IoT. Fornece rendezvous, NAT traversal (UDP hole punching), um “stream” confiável em camada de aplicação sobre UDP e um esquema de endereçamento baseado em ID, permitindo que um app móvel/desktop alcance dispositivos em qualquer lugar da Internet conhecendo apenas o ID do dispositivo.

Traços-chave relevantes para atacantes:

• Os dispositivos se registram em três servidores de rendezvous operados pelo vendor por prefixo de ID. Os clients consultam os mesmos servidores para descobrir o endereço externo/relay do dispositivo e então tentam UDP hole punching. Existe fallback por relay.
• O listener de servidor padrão é alcançável via UDP/32100. Uma sonda mínima de “hello” é suficiente para fingerprint de servidores e alguns dispositivos.
• Existe um cipher “blanket” opcional e um modo especial “CRCEnc”, mas são fracos por design e normalmente são desativados em ecossistemas populares (e.g., LookCam).
• O plano de controle é geralmente comandos JSON sobre o stream PPPP e comumente sofre de ausência de auth e bugs de segurança de memória.

Formato típico de ID de dispositivo (família LookCam): PREFIX-######-CCCCC, abreviado em apps (e.g., GHBB-000001-NRLXW → G000001NRLXW). Prefixos observados: BHCC ("hekai"), FHBB e GHBB ("mykj").

Discovery and Enumeration

• Exposição na Internet: muitos super-nodes PPPP respondem a uma sonda UDP/32100. Respostas com plaintext conhecido e strings de erro tornam-nos fáceis de identificar em captures de tráfego e com scanners de Internet.
• Descoberta na LAN: dispositivos frequentemente respondem a uma busca não criptografada via broadcast local. Use o script de Paul Marrapese para enumerar:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Notas:

• Apps embutem “init strings” que contêm listas de IPs de servidores ofuscadas e chaves de protocolo. Essas strings são trivialmente extraíveis de clientes Android/iOS/Windows e frequentemente reutilizadas em várias linhas de produto.

NAT Traversal and Transport

• Os servidores de rendezvous aprendem o mapeamento público do dispositivo por keepalives periódicos do dispositivo. Os clients consultam os servidores pelo mapeamento e então tentam fluxos UDP diretos usando hole punching. Se a NAT traversal falha, o tráfego é relayado por hosts PPPP designados.
• O “stream” de aplicação implementa sua própria lógica de ACK/retx sobre UDP; loops de retransmissão são duplicados em muitos caminhos de código e podem inundar links com perda.

Weak “Encryption” and Key Recovery

Dois mecanismos ineficazes existem na stack CS2:

1. Blanket cipher (opcional) – P2P_Proprietary_Encrypt

• Geralmente desativado por OEMs usando LookCam.
• A “init string” do lado do app fornece o material de chave que é reduzido a uma chave efetiva de 4 bytes (~2^32 de espaço).
• Known-plaintext prático: os primeiros 4 bytes de MSG_HELLO para UDP/32100 são conhecidos como F1 00 00 00. Observar um único handshake criptografado permite recuperação rápida da chave ou validação.
• Algumas mensagens de controle (e.g., MSG_REPORT_SESSION_READY) são sempre criptografadas com uma chave hardcoded na biblioteca compartilhada entre apps.

2. Registration “encryption” – PPPP_CRCEnc

• Apesar do nome, isto não é CRC. É um keystream XOR repetido fixo com uma verificação de padding de 4 bytes (não autenticada).
• Redes LookCam tipicamente usam CRCEnc apenas para o registro device → server (MSG_DEV_LGN_CRC). A maior parte do restante do tráfego permanece em plaintext.

Recuperação simples do keystream para PPPP_CRCEnc (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)])

Desalinhamento do modelo de ameaça: os materiais do CS2 focam em prevenir DoS via registros falsos de dispositivos, não em confidencialidade. Isso explica a “criptografia” seletiva do registro enquanto vídeo/controle permanecem opcionais ou em texto claro. Servidores PPPP históricos não apresentam limitação de taxa, permitindo brute-force/abuso em escala.

Plano de Controle: Comandos JSON e Auth Bypass

Muitos firmwares de câmeras PPPP trocam mensagens JSON uma vez que a sessão está estabelecida. Exemplo de “login” que o cliente envia:

{
"cmd": "LoginDev",
"pwd": "123456"
}

Vulnerabilidade comum em dispositivos da classe LookCam:

• Firmware ignora tanto o fluxo LoginDev quanto os campos pwd por requisição (CWE-287, CWE-306). O dispositivo aceita comandos operacionais sem validar uma senha.
• Exploitation: do not send LoginDev or ignore its result; send commands directly.

Comandos úteis observados:

• searchWiFiList – executa iwlist; deixa a saída bruta em /tmp/wifi_scan.txt.
• DownloadFile – primitiva de leitura de caminhos arbitrários sem restrições.

Fluxo para desanonimizar a localização via artefatos transitórios:

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 em firmware embarcado

Padrão inseguro típico (pseudocódigo dos handlers):

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:

Stack Overflow

Ret2lib

Abuso de Armazenamento em Nuvem (HTTP, Device-ID apenas)

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

554,8554 - Pentesting RTSP

Pentesting Wifi

Referências

• A look at a P2P camera (LookCam app) – Almost Secure
• PPPP device discovery on LAN (Paul Marrapese)
• LookCam analysis (Warwick University, 2023)
• General PPPP analysis – Elastic Security Labs (2024)
• CS2 Network sales deck (2016) – PPPP/threat model
• Anyka hardened community firmware