32100/UDP - Pentesting PPPP (CS2) P2P कैमरे

Reading time: 10 minutes

अवलोकन

PPPP (a.k.a. “P2P”) CS2 Network द्वारा विकसित एक proprietary device connectivity stack है जो कम-लागत के IP कैमरों और अन्य IoT डिवाइसेज़ में व्यापक रूप से एम्बेड किया जाता है। यह rendezvous, NAT traversal (UDP hole punching), UDP के ऊपर एक application-layer “reliable” stream, और एक ID-based addressing स्कीम प्रदान करता है, जिससे एक mobile/desktop app केवल device ID जानकर इंटरनेट पर कहीं भी डिवाइस तक पहुँच सकती है।

आक्रमणकर्ताओं के लिए मुख्य प्रासंगिक गुण:

• डिवाइसेज़ अपने ID prefix के लिए तीन vendor-operated rendezvous सर्वरों पर रजिस्टर करते हैं। क्लाइंट वही सर्वर क्वेरी करते हैं ताकि डिवाइस का external/relay address मिले, और फिर UDP hole punching करने की कोशिश करते हैं। Relay fallback मौजूद है।
• Default server listener UDP/32100 पर पहुंच योग्य है। एक न्यूनतम “hello” probe सर्वरों और कुछ डिवाइसेज़ को फिंगरप्रिंट करने के लिए पर्याप्त है।
• Optional blanket cipher और एक विशेष “CRCEnc” mode मौजूद हैं लेकिन डिजाइन में कमजोर हैं और आम तौर पर लोकप्रिय ecosystems (जैसे LookCam) में disabled रहते हैं।
• Control plane आमतौर पर PPPP stream पर JSON commands होते हैं और अक्सर missing auth और memory-safety bugs से ग्रस्त होते हैं।

Typical device ID फ़ॉर्मेट (LookCam family): PREFIX-######-CCCCC, apps में छोटा करके दिखाया जाता है (उदाहरण: GHBB-000001-NRLXW → G000001NRLXW). देखे गए prefixes: BHCC ("hekai"), FHBB और GHBB ("mykj")।

Discovery and Enumeration

• Internet exposure: कई PPPP super-nodes 32100/UDP probe का उत्तर देते हैं। ज्ञात plaintext और error-string responses उन्हें traffic captures और Internet scanners में पहचानना आसान बनाते हैं।
• LAN discovery: डिवाइसेज़ अक्सर local broadcast पर एक unencrypted search का उत्तर देती हैं। Paul Marrapese’s स्क्रिप्ट का उपयोग करके enumerate करें:
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

नोट्स:

• Apps में embedded “init strings” होते हैं जिनमें obfuscated server IP lists और protocol keys होते हैं। ये strings Android/iOS/Windows clients से आसानी से extract किए जा सकते हैं और अक्सर कई product lines में reuse होते हैं।

NAT Traversal and Transport

• Rendezvous servers डिवाइस के public mapping को डिवाइस के periodic keepalives से सीखते हैं। क्लाइंट mapping के लिए सर्वरों से क्वेरी करते हैं और फिर hole punching का उपयोग करके direct UDP flows की कोशिश करते हैं। यदि NAT traversal विफल रहती है, तो traffic निर्दिष्ट PPPP relay hosts द्वारा relay किया जाता है।
• Application “stream” UDP के ऊपर अपना ACK/retx logic लागू करता है; retransmission loops कई code paths में duplicated होते हैं और lossy links पर flood कर सकते हैं।

Weak “Encryption” and Key Recovery

CS2 stack में दो अकार्यक्षम मैकेनिज्म मौजूद हैं:

1. Blanket cipher (optional) – P2P_Proprietary_Encrypt

• आम तौर पर OEMs द्वारा LookCam के उपयोग में disabled रहती है।
• App-side “init string” key material प्रदान करती है जिसे एक प्रभावी 4-byte key (~2^32 space) में réduit किया जाता है।
• Practical known-plaintext: MSG_HELLO के UDP/32100 पर पहले 4 bytes ज्ञात होते हैं: F1 00 00 00. एक single encrypted handshake देखकर rapid key recovery या validation संभव है।
• कुछ control messages (उदा., MSG_REPORT_SESSION_READY) हमेशा library-hardcoded key के साथ encrypted होती हैं जो apps में साझा होती है।

2. Registration “encryption” – PPPP_CRCEnc

• नाम के बावजूद, यह CRC नहीं है। यह एक fixed repeating XOR keystream है जिसमें 4-byte padding check है (authenticated नहीं)।
• LookCam networks सामान्यतः CRCEnc का उपयोग केवल device → server registration (MSG_DEV_LGN_CRC) के लिए करते हैं। अधिकांश अन्य traffic plaintext में रहता है।

PPPP_CRCEnc के लिए सरल keystream recovery (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)])

Threat model mismatch: CS2 सामग्री fake device registrations के जरिए DoS को रोकने पर केंद्रित है, न कि confidentiality पर। यही बताता है कि registration की selective “encryption” क्यों की जाती है जबकि video/control वैकल्पिक या cleartext में रहते हैं। Historical PPPP servers में rate limiting नहीं होता, जिससे बड़े पैमाने पर brute-force/abuse संभव होता है।

Control Plane: JSON Commands and Auth Bypass

Many PPPP camera firmwares session चालू होने के बाद JSON messages का आदान-प्रदान करते हैं। उदाहरण के तौर पर client द्वारा भेजा गया “login”:

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

Common vulnerability in LookCam-class devices:

• Firmware ignores both the LoginDev flow and per-request pwd fields (CWE-287, CWE-306). डिवाइस पासवर्ड को सत्यापित किए बिना ऑपरेशनल कमांड स्वीकार करता है।
• Exploitation: LoginDev को न भेजें या उसके परिणाम को अनदेखा करें; सीधे कमांड भेजें।

Useful commands observed:

• searchWiFiList – iwlist को कॉल करता है; कच्चा आउटपुट /tmp/wifi_scan.txt में छोड़ देता है।
• DownloadFile – path प्रतिबंधों के बिना arbitrary path read primitive।

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.

Memory-Safety to RCE on Embedded Firmware

Typical unsafe pattern (pseudocode from 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: कोई भी cmd string > 255 bytes stack buffer overflow (CWE-120/121) का कारण बनता है।
• Protections: कोई stack canary नहीं; DEP/NX और ASLR आमतौर पर इन builds पर disabled होते हैं।
• Impact: सीधे single-stage shellcode या classic ROP/ret2libc device के CPU (e.g., ARM) पर full compromise और LAN pivoting के लिए।

See also:

Stack Overflow

Ret2lib

क्लाउड स्टोरेज दुरुपयोग (HTTP, Device-ID केवल)

कई LookCam-ब्रांडेड firmwares रिकॉर्डिंग्स को केवल HTTP पर api.l040z.com (BHCC के लिए apicn.l040z.com) पर अपलोड करते हैं। अवलोकन:

• Firmware में कोई TLS नहीं; transport cleartext HTTP है।
• API “authentication” केवल device-ID है: जो भी ID जानता है वह रिकॉर्डिंग्स fetch कर सकता है।
• 5 MiB chunking hardcoded है।
• Remote enablement: बूट पर डिवाइस http://api.l040z.com/camera/signurl को कॉल करता है; server का response तय करता है कि uploads शुरू होती हैं या नहीं। मोबाइल app क्लाउड “disabled” दिखा सकता है भले ही uploads हो रही हों। तृतीय पक्ष किसी victim ID के लिए क्लाउड खरीद/enable कर सकता है और चुपचाप फुटेज इकट्ठा कर सकता है।

यह classic cleartext sensitive transmission (CWE-319) है जिसमें 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). प्रत्येक prefix HA के लिए तीन rendezvous servers से मैप होता है।
• 5-letter verifier 22 uppercase letters के alphabet का उपयोग करता है (A, I, O, Q excluded) → 22^5 ≈ 5.15M combos प्रति numeric base।
• पिछले कार्यों में server-side rate-limiting नहीं देखा गया, जो distributed guessing को practical बनाता है। verifier algorithm bespoke है और संभवतः guessable या apps/firmware reverse करके obtain किया जा सकता है।

व्यावहारिक स्रोत:

• Official apps पर कहीं भी दिखते हैं और अक्सर user screenshots/videos में leaked होते हैं।
• AP mode SSID device ID के बराबर होता है; कई devices onboarding के दौरान एक open AP expose करते हैं।

Remote Reachability को मजबूर करना

कुछ firmwares तब तक loop में reboot करते हैं जब तक rendezvous servers reachable न हो जाएँ। यदि egress blocked हो, डिवाइस reboot cycle में बना रहेगा, जिससे मालिकों को प्रभावी रूप से इसे Internet-reachable छोड़ने के लिए बाध्य किया जाता है और PPPP rendezvous के लिए exposed रहता है।

Practical Exploitation Playbook (for repro/defense testing)

1. Obtain device ID

• app UI या AP SSID से; अन्यथा PREFIX+number enumerate करें और 22^5 verifier space को brute-force करें।

2. Establish PPPP session

• CS2 PPPP client या custom code का उपयोग करें; app init string से server IP lists और init keys extract करें; UDP hole punching का प्रयास करें; असफल होने पर relay पर fallback करें।

3. Bypass auth

• LoginDev को skip करें या उसके result को ignore करें; operational JSON सीधे भेजें।

4. Exfiltrate files / geo-locate

• {"cmd":"searchWiFiList"} भेजें; फिर DownloadFile "/tmp/wifi_scan.txt"; BSSIDs को किसी geolocation API में submit करें।

5. Achieve RCE

• cmd > 255 bytes भेजें ताकि stack overflow trigger हो; ROP/ret2libc बनाएं या shellcode drop करें (कोई canary/DEP/ASLR नहीं)।

6. Cloud access

• केवल device ID का उपयोग कर api.l040z.com endpoints के साथ interact करें; ध्यान दें कि 5 MiB chunking है; क्लाउड enablement /camera/signurl द्वारा नियंत्रित होती है भले ही app UI state कुछ भी हो।

Related Protocols/Services

554,8554 - Pentesting RTSP

Pentesting Wifi

References

• 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