tr4m0ryp/wa-activity-collector

# wa-activity-collector [](LICENSE) [](https://nodejs.org) [](https://github.com/WhiskeySockets/Baileys) [](https://arxiv.org/abs/2411.11194) []() **通过 RTT 送达回执侧通道实现的多账号 WhatsApp 活动追踪器。** 以 2Hz 的频率向每个目标发送静默删除探测，将每次探测及其确认（ack）记录到 SQLite 中，并提供一个极简的管理 UI 来添加账号（QR 码配对）和目标手机号码。没有分类，没有推理——仅保留原始计时数据，因此分析工作完全留在分析层进行。 重新实现了 [Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers](https://arxiv.org/abs/2411.11194)（Gegenhuber 等人，RAID 2025 最佳论文）中的数据收集部分。对于每个追踪目标，收集器以 2Hz 的频率为一个不存在的 message ID 发送“删除”探测；WhatsApp 会从目标的任一已链接在线设备生成送达回执；记录并存储的便是该往返时间（RTT）。 ## 数据格式 ``` probe_events: id, target_id, probe_msg_id, sent_at_ms, ack_at_ms, rtt_ms, ack_type, ack_jid, timed_out ``` `ack_jid` 是多设备情况下的基本事实：`31...@s.whatsapp.net` 是主手机，`@lid` JID 是目标已链接的会话（笔记本电脑、iPad、网页端）。这在后续分析需要区分“手机响应”与“任意设备响应”时非常有用。 ## 设置 ``` git clone cd wa-activity-collector npm install npm start ``` 打开 `http://localhost:3000`，点击 `+ account`，在手机上通过 `WhatsApp → 已链接设备` 扫描二维码，然后在账号卡片内添加目标手机号码（需包含国家代码）。 ## 部署 收集器旨在服务器上持续运行。有两种模式： **住宅服务器（适用于活跃账号的首选方案）。** 在通过家庭网络连接的 Mac mini / Raspberry Pi 等设备上运行，仅通过 Cloudflare 隧道暴露管理 UI。WhatsApp 的反滥用机制会对数据中心 IP 进行严格限制——从住宅 ASN 发送出站流量是最安全的模式。 **使用本地配对会话的云 VM。** 如果必须使用云服务提供商： 1. 首先在本地配对 Baileys（使用住宅 IP） 2. 配置 VM（例如 `gcloud compute instances create wa-collector --zone=europe-west4-a --machine-type=e2-small --image-family=debian-12 --image-project=debian-cloud --boot-disk-size=20GB`） 3. 在 VM 上安装 Node 20+ 并运行 `npm install` 4. 停止本地服务器，并运行 `./scripts/sync-to-server.sh` 上传 `data/` 5. 作为 systemd 服务运行；仅通过 SSH 隧道暴露 UI 配对过程带有住宅网络特征；随后的持续探测流量则从 VM 运行。这减轻了冷配对异常，但活动会话仍然源自云 IP，这仍然是一个残留风险。 ## 配置 `src/config.ts`: | 键 | 默认值 | 含义 | |---|---|---| | `PROBE_INTERVAL_MS` | `500` | 每个目标探测的基础间隔 (2Hz) | | `PROBE_JITTER_MS` | `100` | 均匀 `±` 抖动 | | `PROBE_TIMEOUT_MS` | `5000` | 单次探测确认 (ack) 的超时时间 | | `OFFLINE_BACKOFF_FACTOR` | `5` | 当目标显示离线时，间隔乘以此系数 | | `OFFLINE_MISS_THRESHOLD` | `5` | 触发退避策略前的连续超时次数 | 根据 Careless Whisper 论文，WhatsApp 可容忍高达约 20Hz (50ms) 的探测频率而不会出现明显的限速；2Hz 是一个保守的默认值，为持续的 24/7 收集留下了充足的余量。仅在有充分理由时才提高频率，并将每个账号的确认率作为预警指标进行监控。 ## 架构与数据导出 位于 `data/activity.db` 的 SQLite 数据库，采用 WAL 模式。数据表： - `accounts(id, name, phone_number, auth_dir, active, created_at_ms)` - `targets(id, account_id, jid, display_name, added_at_ms, active)` - `probe_events(id, target_id, probe_msg_id, sent_at_ms, ack_at_ms, rtt_ms, ack_type, ack_jid, timed_out)` - `presence_events(id, target_id, observed_jid, presence, observed_at_ms)` - `account_health(account_id, bucket_ms, probes_sent, acks_received, timeouts, ws_disconnects)` — 1 分钟存储桶 进行分析时，将相关表导出为 Parquet/CSV 并加载到任何你喜欢的工具中（DuckDB、pandas 或你常用的 Claude 分析会话）。该架构是有意精简的，以便将聚合选择留在分析层进行。 ## 运维说明 - **认证状态极其重要。** `data/auth//` 包含已链接设备的会话密钥。丢失它意味着你必须从头开始重新配对。请务必备份。 - **不要对同一账号运行两个收集器。** 每个 Baileys 会话会占用一个已链接设备的槽位；对同一账号发起的第二个并发会话将触发 `connectionReplaced`（其中一个会被踢下线，导致你丢失配对）。 - **多设备注意事项。** “收到新确认”意味着目标的某个已链接设备可达，但不一定是他们的手机。每次探测的原始 `ack_jid` 是判断哪个设备响应的唯一可靠来源。 - **手机保活机制。** 已链接设备的会话会在主手机无法连接约 14 天后失效。只要手机每隔几周连接一次 WA，服务器会话就会保持有效。 - **数据量。** 按 2Hz × 5 个目标 × 24 小时计算 = 约 86.4 万个事件/天 = SQLite 中每天约 70MB。无需轮换即可轻松容纳数年的数据收集。 ## 状态 研究/概念验证阶段。不适用于生产级别的对手建模，也不适用于未经他人同意的监控。 ## 技术栈 - Node.js 20+ / TypeScript / [Baileys 7](https://github.com/WhiskeySockets/Baileys) - `better-sqlite3` (WAL) - `express` + `socket.io` 用于管理 UI - 原生 JS 前端，无需构建步骤

标签：Baileys, Careless Whisper, DNS解析, ESC8, GNU通用公共许可证, Node.js, RAID 2025, RTT, SQLite, TypeScript, Websocket, WhatsApp, 主机安全, 侧信道攻击, 即时通讯, 多设备感知, 多账户, 安全插件, 开源项目, 往返时间, 概念验证, 活动追踪, 用户监控, 目录枚举, 研究工具, 社会工程学, 移动安全, 网络协议分析, 网络安全, 自动化攻击, 论文复现, 防御绕过, 隐私保护, 隐私泄露