32100/UDP - Pentesting PPPP (CS2) P2P Κάμερες

Reading time: 9 minutes

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Επισκόπηση

PPPP (a.k.a. “P2P”) είναι ένα ιδιόκτητο device connectivity stack της CS2 Network που ενσωματώνεται ευρέως σε low-cost IP cameras και άλλα IoT devices. Παρέχει rendezvous, NAT traversal (UDP hole punching), ένα application-layer “reliable” stream πάνω από UDP, και ένα ID-based addressing scheme, επιτρέποντας σε ένα mobile/desktop app να προσεγγίσει συσκευές οπουδήποτε στο Internet γνωρίζοντας μόνο ένα device ID.

Βασικά χαρακτηριστικά σημαντικά για επιτιθέμενους:

  • Οι συσκευές κάνουν register σε τρεις vendor-operated rendezvous servers ανά prefix ID. Οι clients κάνουν query στους ίδιους servers για να βρουν το external/relay address της συσκευής, και μετά επιχειρούν UDP hole punching. Υπάρχει relay fallback.
  • O default server listener είναι προσβάσιμος μέσω UDP/32100. Μια ελάχιστη “hello” probe αρκεί για να fingerprintάρει servers και μερικές συσκευές.
  • Υπάρχει προαιρετικό blanket cipher και μια ειδική λειτουργία “CRCEnc”, αλλά είναι αδύναμα εκ σχεδίου και τυπικά απενεργοποιημένα σε δημοφιλή ecosystems (π.χ., LookCam).
  • Το control plane είναι συνήθως JSON commands πάνω στο PPPP stream και συχνά υποφέρει από missing auth και memory-safety bugs.

Τυπική μορφή device ID (οικογένεια LookCam): PREFIX-######-CCCCC, συντομεύεται στις apps (π.χ., GHBB-000001-NRLXW → G000001NRLXW). Παρατηρούμενα prefixes: BHCC ("hekai"), FHBB και GHBB ("mykj").

Ανακάλυψη και Εντοπισμός

  • Internet exposure: πολλοί PPPP super-nodes απαντούν σε 32100/UDP probe. Known plaintext και error-string responses τα κάνουν εύκολα αναγνωρίσιμα σε traffic captures και με Internet scanners.
  • LAN discovery: συσκευές συχνά απαντούν σε unencrypted search στο local broadcast. Χρησιμοποιήστε το script του Paul Marrapese για enumeration:
  • https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

Σημειώσεις:

  • Οι εφαρμογές ενσωματώνουν “init strings” που περιέχουν obfuscated server IP lists και protocol keys. Αυτά τα strings εξάγονται trivially από Android/iOS/Windows clients και συχνά επαναχρησιμοποιούνται σε πολλές product lines.

NAT Traversal και Μεταφορά

  • Οι rendezvous servers μαθαίνουν το public mapping της συσκευής μέσω περιοδικών keepalives από τη συσκευή. Οι clients κάνουν query στους servers για το mapping και στη συνέχεια επιχειρούν direct UDP flows χρησιμοποιώντας hole punching. Αν το NAT traversal αποτύχει, το traffic αναμεταδίδεται από καθορισμένους PPPP relay hosts.
  • Το application “stream” υλοποιεί δικό του ACK/retx logic πάνω από UDP· τα retransmission loops είναι διπλογραμμένα σε πολλαπλά code paths και μπορούν να πλημμυρίσουν lossy links.

Αδύναμη “Encryption” και Ανάκτηση Κλειδιού

Υπάρχουν δύο αναποτελεσματικοί μηχανισμοί στο CS2 stack:

  1. Blanket cipher (optional) – P2P_Proprietary_Encrypt
  • Συνήθως απενεργοποιημένο από OEMs που χρησιμοποιούν LookCam.
  • Το app-side “init string” παρέχει το key material που μειώνεται σε ένα effective 4-byte key (~2^32 space).
  • Practical known-plaintext: τα πρώτα 4 bytes του MSG_HELLO προς UDP/32100 είναι γνωστά και είναι F1 00 00 00. Η παρατήρηση ενός μόνο encrypted handshake επιτρέπει ταχεία ανάκτηση ή validation του κλειδιού.
  • Μερικά control messages (π.χ., MSG_REPORT_SESSION_READY) είναι πάντα encrypted με ένα library-hardcoded key κοινό μεταξύ των apps.
  1. 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.

Simple keystream recovery for PPPP_CRCEnc (Python):

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)])

Ασυμφωνία στο μοντέλο απειλών: Το CS2 υλικό επικεντρώνεται στην αποτροπή DoS μέσω ψεύτικων εγγραφών συσκευών, όχι στην εμπιστευτικότητα. Αυτό εξηγεί την επιλεκτική «encryption» της εγγραφής ενώ το video/control παραμένουν προαιρετικά ή σε cleartext. Ιστορικοί PPPP servers δεν εφαρμόζουν rate limiting, επιτρέποντας brute-force/abuse σε μεγάλη κλίμακα.

Επίπεδο Ελέγχου: JSON Commands και Auth Bypass

Πολλά firmwares καμερών PPPP ανταλλάσσουν JSON μηνύματα μόλις ανοίξει η συνεδρία. Παράδειγμα του “login” που στέλνει ο client:

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

Common vulnerability in LookCam-class devices:

  • Το firmware αγνοεί τόσο τη ροή LoginDev όσο και τα πεδία pwd ανά αίτημα (CWE-287, CWE-306). Η συσκευή δέχεται εντολές λειτουργίας χωρίς να επικυρώνει κωδικό πρόσβασης.
  • Exploitation: μην στέλνετε LoginDev ή αγνοήστε το αποτέλεσμα· στείλτε τις εντολές απευθείας.

Useful commands observed:

  • searchWiFiList – εκτελεί εξωτερικά το iwlist; αφήνει το raw output στο /tmp/wifi_scan.txt.
  • DownloadFile – arbitrary path read primitive χωρίς περιορισμούς στο path.

Ροή εργασίας για αποανωνυμοποίηση τοποθεσίας μέσω παροδικών artifacts:

  1. Στείλτε {"cmd":"searchWiFiList"}.
  2. Διαβάστε το /tmp/wifi_scan.txt μέσω DownloadFile.
  3. Υποβάλετε τα BSSID MACs σε ένα geolocation API (π.χ., Google Geolocation API) για να εντοπίσετε την κάμερα με ακρίβεια δεκάδων μέτρων.

Από Memory-Safety σε RCE σε Embedded Firmware

Τυπικό unsafe pattern (pseudocode από handlers):

c
char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check
  • Προκαλεί: οποιαδήποτε συμβολοσειρά cmd > 255 bytes προκαλεί stack buffer overflow (CWE-120/121).
  • Προστασίες: no stack canary; DEP/NX και ASLR συχνά απενεργοποιημένα σε αυτές τις builds.
  • Επίπτωση: straightforward single-stage shellcode ή classic ROP/ret2libc στο CPU της συσκευής (π.χ., ARM) για πλήρη compromise και LAN pivoting.

See also:

Stack Overflow

Ret2lib

Κατάχρηση Cloud Storage (HTTP, Device-ID only)

Πολλές firmware με την επωνυμία LookCam ανεβάζουν εγγραφές στο api.l040z.com (apicn.l040z.com για BHCC) μόνο μέσω HTTP. Παρατηρήσεις:

  • Δεν υπάρχει TLS στο firmware· η μεταφορά είναι σε cleartext HTTP.
  • Η API “authentication” είναι μόνο device-ID: οποιοσδήποτε γνωρίζει το ID μπορεί να fetch recordings.
  • 5 MiB chunking είναι hardcoded.
  • Remote enablement: κατά το boot η συσκευή καλεί http://api.l040z.com/camera/signurl; η απάντηση του server αποφασίζει αν θα ξεκινήσουν uploads. Η mobile app μπορεί να δείχνει cloud “disabled” ακόμη και όταν γίνονται uploads. Ένας τρίτος μπορεί να purchase/enable cloud για ένα victim ID και να συλλέγει σιωπηλά το υλικό.

Αυτό είναι κλασική cleartext sensitive μεταφορά (CWE-319) με έλλειψη server-side authZ.

Device-ID Enumeration and Guessing

  • Μορφή ID: PREFIX-######-CCCCC και app-shortened form (π.χ., GHBB-000001-NRLXW → G000001NRLXW).
  • Prefix families: BHCC (hekai servers), FHBB και GHBB (mykj servers). Κάθε prefix maps σε τρεις rendezvous servers για HA.
  • Ο 5-letter verifier χρησιμοποιεί αλφάβητο 22 uppercase letters (A, I, O, Q εξαιρούνται) → 22^5 ≈ 5.15M combos ανά numeric base.
  • Προηγούμενες εργασίες παρατήρησαν no server-side rate-limiting, καθιστώντας το distributed guessing πρακτικό. Ο αλγόριθμος του verifier είναι bespoke και πιθανότατα guessable ή μπορεί να αποκτηθεί με reversing των apps/firmware.

Πρακτικές πηγές των IDs:

  • Εμφανίζονται σε όλη την επίσημη app και συχνά leaked σε user screenshots/videos.
  • Το AP mode SSID ισούται με το device ID· πολλές συσκευές εκθέτουν ένα open AP κατά το onboarding.

Forcing Remote Reachability

Κάποια firmware κάνουν reboot σε loop έως ότου οι rendezvous servers γίνουν reachable. Αν το egress μπλοκαριστεί, η συσκευή θα παραμείνει σε κύκλο reboot, ουσιαστικά εξαναγκάζοντας τους ιδιοκτήτες να την αφήσουν Internet-reachable και εκτεθειμένη στο PPPP rendezvous.

Practical Exploitation Playbook (for repro/defense testing)

  1. Obtain device ID
  • Από app UI ή AP SSID· αλλιώς enumerate PREFIX+number και brute τον χώρο του 22^5 verifier.
  1. Establish PPPP session
  • Χρησιμοποιήστε CS2 PPPP client ή custom code· εξάγετε server IP lists και init keys από το app init string· δοκιμάστε UDP hole punching· fallback σε relay.
  1. Bypass auth
  • Skip LoginDev ή αγνοήστε το αποτέλεσμα του· στείλτε operational JSON απευθείας.
  1. Exfiltrate files / geo-locate
  • Στείλτε {"cmd":"searchWiFiList"}· μετά DownloadFile "/tmp/wifi_scan.txt"· υποβάλετε BSSIDs σε geolocation API.
  1. Achieve RCE
  • Στείλτε cmd > 255 bytes για να προκαλέσετε το stack overflow· φτιάξτε ROP/ret2libc ή drop shellcode (no canary/DEP/ASLR).
  1. Cloud access
  • Αλληλεπιδράστε με τα endpoints του api.l040z.com χρησιμοποιώντας μόνο το device ID· σημειώστε το 5 MiB chunking· η ενεργοποίηση cloud ελέγχεται από /camera/signurl ανεξάρτητα από την κατάσταση του app UI.

554,8554 - Pentesting RTSP

Pentesting Wifi

References

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks