32100/UDP - Pentesting PPPP (CS2) P2P 摄像头

Reading time: 12 minutes

概述

PPPP（又名 “P2P”）是 CS2 Network 的专有设备连接栈，广泛嵌入在低成本 IP cameras 和其他 IoT 设备中。它提供 rendezvous、NAT 穿透（UDP hole punching）、在 UDP 之上实现的应用层“可靠”流以及基于 ID 的寻址方案，允许移动/桌面应用仅凭设备 ID 就能在互联网上任何地方访问设备。

与攻击者相关的关键特征：

• 设备按 ID 前缀向三台厂商运营的 rendezvous 服务器注册。客户端查询相同服务器以获取设备的外部/中继地址，然后尝试 UDP hole punching。存在中继回退机制。
• 默认服务器监听端口可通过 UDP/32100 访问。一个最小的 “hello” 探测就足以指纹化服务器和部分设备。
• 存在可选的 blanket cipher 和一个特殊的 “CRCEnc” 模式，但设计上很弱，且在流行生态（例如 LookCam）中通常被禁用。
• 控制平面通常是在 PPPP stream 上传输的 JSON commands，常见缺乏认证或存在内存安全漏洞。

典型设备 ID 格式（LookCam 系列）：PREFIX-######-CCCCC，应用中常被缩短显示（例如 GHBB-000001-NRLXW → G000001NRLXW）。观测到的前缀：BHCC ("hekai")、FHBB 和 GHBB ("mykj")。

发现与枚举

• Internet 暴露：许多 PPPP super-nodes 会对 32100/UDP 探测作出响应。已知的明文和错误字符串响应使它们在流量捕获和 Internet 扫描器中容易被识别。
• LAN 发现：设备通常会对本地广播的未加密搜索作出响应。使用 Paul Marrapese 的脚本进行枚举：
• https://github.com/pmarrapese/iot/tree/master/p2p/lansearch

注意：

• Apps 嵌入了包含混淆的服务器 IP 列表和协议密钥的 “init strings”。这些字符串可从 Android/iOS/Windows 客户端中轻易提取，并经常在许多产品线上重用。

NAT 穿透与传输

• Rendezvous 服务器通过设备周期性的 keepalives 学习设备的公网映射。客户端查询服务器以获取该映射，然后尝试使用 hole punching 建立直接的 UDP 流。如果 NAT 穿透失败，流量会由指定的 PPPP relay 主机中继。
• 应用层的 “stream” 在 UDP 之上实现了自己的 ACK/retx 逻辑；重传循环在许多代码路径中重复出现，可能会淹没丢包链路。

弱“加密”和密钥恢复

在 CS2 栈中存在两种无效的机制：

1. Blanket cipher（可选）– P2P_Proprietary_Encrypt

• 通常被使用 LookCam 的 OEM 禁用。
• App 端的 “init string” 提供密钥材料，该材料被约简为有效的 4 字节密钥（约 2^32 空间）。
• 实用的已知明文：发送到 UDP/32100 的 MSG_HELLO 的前 4 字节已知为 F1 00 00 00。观察到一次加密握手就能快速恢复或验证密钥。
• 一些控制消息（例如 MSG_REPORT_SESSION_READY）总是使用库中硬编码的密钥在应用间共享并加密。

2. 注册“加密” – PPPP_CRCEnc

• 尽管名称如此，这并不是 CRC。它是一个固定重复的 XOR keystream，带有一个 4 字节的填充校验（未认证）。
• LookCam 网络通常只在设备 → 服务器注册（MSG_DEV_LGN_CRC）时使用 CRCEnc。大多数其他流量保持明文。

PPPP_CRCEnc 的简单 keystream 恢复（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，而不是保密性。这解释了为什么注册会被选择性地“加密”，而视频/控制仍然是可选或明文。历史上的 PPPP 服务器没有速率限制，允许大规模的暴力破解/滥用。

控制平面：JSON 命令 和 Auth Bypass

许多 PPPP 摄像头固件在会话建立后交换 JSON 消息。下面是客户端发送的“login”示例：

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

LookCam-class 设备的常见漏洞：

• 固件同时忽略 LoginDev 流程 和 每次请求的 pwd 字段（CWE-287，CWE-306）。设备在不验证密码的情况下接受操作命令。
• 利用方法：不要发送 LoginDev 或忽略其结果；直接发送命令。

Useful commands observed:

• searchWiFiList – 调用外部程序 iwlist；将原始输出写入 /tmp/wifi_scan.txt。
• DownloadFile – 任意路径读取原语，无路径限制。

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

• 触发：任何长度大于 255 字节的 cmd 字符串会导致 stack buffer overflow (CWE-120/121)。
• 防护：没有 stack canary；这些构建通常禁用 DEP/NX 和 ASLR。
• 影响：可在设备的 CPU（例如 ARM）上使用单阶段 shellcode 或经典的 ROP/ret2libc，实现完全妥协并进行 LAN pivoting。

See also:

Stack Overflow

Ret2lib

Cloud Storage Abuse (HTTP, Device-ID only)

许多 LookCam 品牌的固件仅通过 HTTP 将录制上传到 api.l040z.com（BHCC 使用 apicn.l040z.com）。观察：

• 固件中没有 TLS；传输为明文 HTTP。
• API 的“authentication”仅基于 device-ID：任何知道该 ID 的人都可以获取录音。
• 5 MiB 的分块是硬编码的。
• 远程启用：启动时设备会调用 http://api.l040z.com/camera/signurl；服务器的响应决定是否开始上传。移动应用可能会显示云服务“disabled”，但上传仍会发生。第三方可以为受害者 ID 购买/启用云服务并悄然收集录像。

这属于典型的敏感明文传输（CWE-319），并且缺少服务器端的 authZ。

Device-ID Enumeration and Guessing

• ID 格式：PREFIX-######-CCCCC 和应用缩短形式（例如 GHBB-000001-NRLXW → G000001NRLXW）。
• 前缀家族：BHCC（hekai servers）、FHBB 和 GHBB（mykj servers）。每个前缀映射到三个 rendezvous 服务器以实现 HA。
• 5 字母 verifier 使用 22 个大写字母的字母表（排除了 A、I、O、Q）→ 22^5 ≈ 5.15M 种组合，每个数字基底。
• 先前研究观察到服务器端没有速率限制，这使得分布式猜测变得可行。verifier 算法是定制的，可能可猜测或可通过反向工程应用/固件获得。

Practical sources of IDs:

• 在官方应用中随处可见，且经常在用户截图/视频中 leaked。
• AP 模式的 SSID 等于 device ID；许多设备在 onboarding 期间会暴露一个开放的 AP。

Forcing Remote Reachability

一些固件会循环重启直到 rendezvous 服务器可达。如果 egress 被阻断，设备将保持重启循环，实质上强迫所有者将其置于可被 Internet 访问的状态，从而暴露给 PPPP rendezvous。

Practical Exploitation Playbook (for repro/defense testing)

1. Obtain device ID

• 从 app UI 或 AP SSID 获取；否则枚举 PREFIX+number 并暴力尝试 22^5 的 verifier 空间。

2. Establish PPPP session

• 使用 CS2 PPPP 客户端或自定义代码；从 app init 字符串中提取服务器 IP 列表和 init keys；尝试 UDP hole punching；失败则回退到 relay。

3. Bypass auth

• 跳过 LoginDev 或忽略其结果；直接发送 operational JSON。

4. Exfiltrate files / geo-locate

• 发送 {"cmd":"searchWiFiList"}；然后 DownloadFile "/tmp/wifi_scan.txt"；将 BSSIDs 提交到 geolocation API。

5. Achieve RCE

• 发送长度 > 255 字节的 cmd 以触发 stack overflow；构建 ROP/ret2libc 或注入 shellcode（无 canary/DEP/ASLR）。

6. Cloud access

• 使用 device ID 与 api.l040z.com 的端点交互；注意 5 MiB 分块；云服务的启用由 /camera/signurl 控制，与 app UI 状态无关。

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