32100/UDP - Pentesting PPPP (CS2) P2P Kameras

Reading time: 9 minutes

Überblick

PPPP (a.k.a. “P2P”) ist ein proprietärer Geräte-Connectivity-Stack von CS2 Network, der weit verbreitet in günstigen IP-Kameras und anderen IoT-Geräten eingesetzt wird. Er bietet Rendezvous, NAT-Traversal (UDP hole punching), einen anwendungsseitigen „reliable“ Stream auf UDP und ein ID-basiertes Adressierungsschema, das einer mobilen/desktop App erlaubt, Geräte überall im Internet nur mit einer Geräte-ID zu erreichen.

Wesentliche Merkmale für Angreifer:

• Geräte registrieren sich pro ID-Präfix bei drei vendor-betriebenen Rendezvous-Servern. Clients fragen dieselben Server ab, um die externe/Relay-Adresse des Geräts zu finden, und versuchen dann UDP hole punching. Ein Relay-Fallback existiert.
• Der Standard-Server-Listener ist über UDP/32100 erreichbar. Eine minimale „hello“-Probe reicht aus, um Server und einige Geräte zu identifizieren.
• Es existiert eine optionale Blanket-Cipher und ein spezieller „CRCEnc“-Modus, beides ist aber per Design schwach und in populären Ökosystemen (z. B. LookCam) typischerweise deaktiviert.
• Die Control-Plane besteht üblicherweise aus JSON-Kommandos über den PPPP-Stream und leidet häufig an fehlender Authentifizierung und Speichersicherheitsfehlern.

Typisches Geräte-ID-Format (LookCam-Familie): PREFIX-######-CCCCC, in Apps verkürzt (z. B. GHBB-000001-NRLXW → G000001NRLXW). Beobachtete Präfixe: BHCC ("hekai"), FHBB und GHBB ("mykj").

Erkennung und Aufzählung

• Internet-Exposition: viele PPPP-Supernodes antworten auf eine 32100/UDP-Probe. Bekannte Klartext- und Fehler-String-Antworten machen sie in Traffic-Captures und mit Internet-Scannern leicht identifizierbar.
• LAN-Erkennung: Geräte antworten oft auf eine unverschlüsselte Suche über lokalen Broadcast. Verwende Paul Marrapese’s Script zur Enumeration:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Hinweise:

• Apps betten „init strings“ ein, die obfuskierte Server-IP-Listen und Protokoll-Keys enthalten. Diese Strings sind trivial aus Android/iOS/Windows-Clients extrahierbar und werden oft über viele Produktlinien wiederverwendet.

NAT Traversal und Transport

• Rendezvous-Server lernen das öffentliche Mapping des Geräts durch periodische Keepalives vom Gerät. Clients fragen die Server nach dem Mapping und versuchen dann direkte UDP-Flows mittels Hole Punching. Wenn NAT-Traversal fehlschlägt, wird der Traffic über designated PPPP-Relay-Hosts weitergeleitet.
• Der applikationsseitige „Stream“ implementiert eigene ACK-/Retx-Logik auf UDP; Retransmissions-Schleifen sind in vielen Codepfaden dupliziert und können verlustbehaftete Links fluten.

Schwache "Verschlüsselung" und Schlüssel-Wiederherstellung

Im CS2-Stack existieren zwei ineffektive Mechanismen:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• Wird von OEMs bei LookCam meist deaktiviert.
• Die App-seitige „init string“ liefert das Key-Material, das auf einen effektiven 4-Byte-Key (~2^32 Raum) reduziert wird.
• Praktisches Known-Plaintext: die ersten 4 Bytes von MSG_HELLO zu UDP/32100 sind bekannt als F1 00 00 00. Das Beobachten eines einzelnen verschlüsselten Handshakes erlaubt schnelle Key-Recovery oder Validierung.
• Einige Control-Messages (z. B. MSG_REPORT_SESSION_READY) sind immer mit einem in der Bibliothek hartkodierten Key verschlüsselt, der across Apps geteilt wird.

2. Registration „encryption“ – PPPP_CRCEnc

• Trotz des Namens ist das keine CRC. Es ist ein festes, wiederholendes XOR-Keystream mit einer 4-Byte-Padding-Prüfung (nicht authentifiziert).
• LookCam-Netzwerke nutzen CRCEnc typischerweise nur für die device → server Registrierung (MSG_DEV_LGN_CRC). Der meiste andere Traffic bleibt im Klartext.

Einfaches Keystream-Recovery für 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)])

Fehlanpassung des Bedrohungsmodells: CS2-Materialien konzentrieren sich darauf, DoS durch gefälschte Geräte-Registrierungen zu verhindern, nicht auf Vertraulichkeit. Das erklärt die selektive „Verschlüsselung“ der Registrierung, während Video/Steuerung optional oder im Klartext bleiben. Historische PPPP-Server zeigen keine Rate-Limitierung, wodurch brute-force/abuse in großem Maßstab möglich ist.

Steuerungsebene: JSON-Befehle und Auth-Bypass

Viele PPPP-Kamera-Firmwares tauschen JSON-Nachrichten aus, sobald die Session steht. Beispiel „login“, das der Client sendet:

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

Common vulnerability in LookCam-class devices:

• Die Firmware ignoriert sowohl den LoginDev-Flow als auch die pro-request pwd-Felder (CWE-287, CWE-306). Das Gerät akzeptiert Betriebsbefehle, ohne ein Passwort zu validieren.
• Ausnutzung: LoginDev nicht senden oder dessen Ergebnis ignorieren; Befehle direkt senden.

Useful commands observed:

• searchWiFiList – führt iwlist aus; legt die rohe Ausgabe in /tmp/wifi_scan.txt ab.
• DownloadFile – Lese-Primitive für beliebige Pfade ohne Pfadbeschränkungen.

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.

Von Memory-Safety zu RCE auf Embedded-Firmware

Typisches unsicheres Muster (Pseudocode aus den 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: jede cmd-Zeichenkette > 255 Bytes verursacht einen stack buffer overflow (CWE-120/121).
• Protections: kein stack canary; DEP/NX und ASLR sind in diesen Builds häufig deaktiviert.
• Impact: straightforward single-stage shellcode oder klassisches ROP/ret2libc auf der CPU des Geräts (z. B. ARM) für vollständige Kompromittierung und LAN-Pivoting.

See also:

Stack Overflow

Ret2lib

Missbrauch von Cloud-Speicher (HTTP, nur Device-ID)

Viele LookCam-Firmwares laden Aufnahmen nur über HTTP zu api.l040z.com hoch (apicn.l040z.com für BHCC). Beobachtungen:

• Keine TLS in der Firmware; Transport ist Klartext-HTTP.
• API "authentication" ist nur Device-ID: jeder, der die ID kennt, kann Aufnahmen abrufen.
• Chunking auf 5 MiB ist fest codiert.
• Remote-Aktivierung: Beim Boot ruft das Gerät http://api.l040z.com/camera/signurl auf; die Antwort des Servers entscheidet, ob Uploads starten. Die mobile App kann Cloud als "disabled" anzeigen, selbst wenn Uploads stattfinden. Ein Dritter kann Cloud für eine Opfer-ID kaufen/aktivieren und heimlich Material sammeln.

Dies ist eine klassische Klartext-Übertragung sensibler Daten (CWE-319) mit fehlender serverseitiger authZ.

Device-ID-Enumerierung und Erraten

• ID-Format: PREFIX-######-CCCCC und app-kürzere Form (z. B. GHBB-000001-NRLXW → G000001NRLXW).
• Prefix-Familien: BHCC (hekai servers), FHBB und GHBB (mykj servers). Jeder Prefix mappt auf drei Rendezvous-Server für HA.
• Der 5‑stellige Verifier verwendet ein Alphabet von 22 Großbuchstaben (A, I, O, Q ausgeschlossen) → 22^5 ≈ 5.15M Kombinationen pro numerischer Basis.
• Frühere Arbeiten beobachteten kein serverseitiges Rate-Limiting, was verteiltes Erraten praktikabel macht. Der Verifier-Algorithmus ist maßgeschneidert und wahrscheinlich erratbar oder durch Reverse-Engineering der Apps/Firmware zu erhalten.

Praktische Quellen für IDs:

• In den offiziellen Apps überall angezeigt und oft in user screenshots/videos leaked.
• AP-Modus SSID entspricht der Device-ID; viele Geräte öffnen einen offenen AP während des Onboardings.

Erzwingen der Fern-Erreichbarkeit

Einige Firmwares booten in einer Schleife, bis Rendezvous-Server erreichbar sind. Wenn Egress blockiert ist, bleibt das Gerät im Reboot-Zyklus und zwingt Besitzer effektiv, es Internet-erreichbar zu lassen und PPPP-Rendezvous auszusetzen.

Praktisches Exploitation-Playbook (für Repro/Verteidigungs-Tests)

1. Device ID beschaffen

• Aus der App-UI oder AP-SSID; ansonsten PREFIX+Nummer enumerieren und die 22^5 Verifier-Space brute-forcen.

2. PPPP-Session herstellen

• Verwende einen CS2 PPPP-Client oder eigenen Code; extrahiere Server-IP-Listen und init keys aus dem App-Init-String; versuche UDP hole punching; fallback auf Relay.

3. Auth umgehen

• LoginDev überspringen oder dessen Ergebnis ignorieren; sende operational JSON direkt.

4. Dateien exfiltrieren / geolokalisieren

• Sende {"cmd":"searchWiFiList"}; dann DownloadFile "/tmp/wifi_scan.txt"; BSSIDs an eine Geolocation-API übermitteln.

5. RCE erreichen

• Sende ein cmd > 255 Bytes, um den stack overflow auszulösen; baue ROP/ret2libc oder drop shellcode (kein canary/DEP/ASLR).

6. Cloud-Zugriff

• Interagiere mit api.l040z.com Endpunkten nur mit der Device-ID; beachten: 5 MiB Chunking; Cloud-Aktivierung wird durch /camera/signurl gesteuert, unabhängig vom Zustand der App-UI.

Verwandte Protokolle/Services

554,8554 - Pentesting RTSP

Pentesting Wifi

Referenzen

• 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