05 de septiembre de 2026 · Por YasKad
gommzystudio/device-activity-tracker

device-activity-tracker: un PoC para vigilar si un teléfono está activo, en reposo u offline por WhatsApp y Signal

gommzystudio/device-activity-tracker · 5.150★ · 704 forks

Una demostración de concepto (PoC) que implementa en TypeScript el ataque académico «Careless Whisper» (Gegenhuber et al., RAID 2025, Best Paper): mide el tiempo de ida y vuelta (RTT) de las confirmaciones de entrega de WhatsApp y Signal para inferir, solo con un número de teléfono, cuándo el dispositivo está en uso, en reposo o desconectado. A 1 de septiembre de 2026 lleva 5.107 estrellas.


Qué es device-activity-tracker

device-activity-tracker es una herramienta de código abierto (MIT) que implementa la investigación del paper «Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers» de Gabriel K. Gegenhuber, Maximilian Günther, Markus Maier, Aljosha Judmayer, Florian Holzbauer, Philipp É. Frenzel y Johanna Ullrich (Universidad de Viena y SBA Research). El propio README lo enmarca con un aviso: «Proof-of-concept for educational and security research purposes only. Demonstrates privacy vulnerabilities in WhatsApp and Signal».

No es un servicio de mensajería ni una app comercial: es un PoC de seguridad que demuestra una vulnerabilidad de privacidad real. Envía probes (mensajes de sondeo) a un número objetivo y mide el RTT (el tiempo entre el envío del probe y el CLIENT ACK de la plataforma) para clasificar el estado del dispositivo:

  • 🟢 Online — RTT por debajo del umbral: el dispositivo se está usando activamente.
  • 🟡 Standby — RTT por encima del umbral: el dispositivo está en reposo/bloqueado.
  • 🔴 Offline — no se recibe CLIENT ACK: el dispositivo está desconectado o inaccesible.

Además, según el README, puede inferir patrones de actividad en el tiempo y, de forma menos fiable, posibles cambios de red (datos móviles frente a Wi-Fi). El proyecto soporta WhatsApp y Signal, con una interfaz web (React) y un modo CLI (solo WhatsApp).

El origen: un PoC sobre un paper galardonado en RAID 2025

El repositorio fue creado el 7 de diciembre de 2025 por Gommzy (cuenta gommzystudio, creada en 2020, 196 seguidores, 27 repositorios públicos, sin empresa ni bio en el perfil) y el último push data del 31 de diciembre de 2025. La rama por defecto es master.

La autoridad del proyecto no viene de una empresa, sino del paper académico que implementa. Según la página de arXiv (2411.11194, v1 el 17 de noviembre de 2024 y v4 el 31 de octubre de 2025), el trabajo fue presentado en el 28º Simposio Internacional sobre Investigación en Ataques, Intrusiones y Defensas (RAID 2025) y fue «Distinguished with the Best Paper Award» (galardonado como mejor paper). El resumen del paper sostiene que las aplicaciones de mensajería instantánea (más de 3.000 millones de usuarios) permiten, mediante mensajes específicamente diseñados, disparar delivery receipts para «pinguear» a cualquier usuario sin su conocimiento ni consentimiento; al hacerlo en alta frecuencia, un atacante puede extraer información privada como el estado online/actividad (pantalla encendida/apagada), inferir el número de dispositivos activos y su sistema operativo, y lanzar ataques de agotamiento de recursos (batería o datos) sin generar ninguna notificación en el destino.

Una visualización cyberpunk oscura del origen académico del proyecto: un artículo de investigación brillante estilo arXiv flotando en un laboratorio digital, rodeado de símbolos de revisión por pares, líneas de citación, una insignia de conferencia RAID 2025 y un sello dorado de Best Paper Award emitiendo luz neón suave, con un icono de repositorio de GitHub cercano sugiriendo la traducción ejecutable de la investigación académica en código

El dato narrativo relevante es la tensión entre la herramienta y las apps: el propio hilo de Hacker News sobre el paper (20 puntos, 4 comentarios) muestra la reacción a que «la fundación» (Signal Foundation) no había respondido al hallazgo (v. «Cómo lo recibió la comunidad»). Este PoC es la traducción ejecutable de esa investigación.

Filosofía y principios

Las ideas verificables que atraviesan el README, el CONTRIBUTING.md y la LICENSE:

  • Demostrar una vulnerabilidad real, no construir un producto. El README y la licencia (MIT con disclaimers adicionales) insisten en que el objetivo es «educational and security research purposes only», y advierten que «this tool demonstrates real security vulnerabilities that affect millions of users».
  • Basarse en un trabajo revisado por pares. En lugar de un ataque inventado, la implementación parte de un paper con Best Paper Award (RAID 2025), lo que ancla el método en literatura verificable y citable (el README incluye la cita BibTeX).
  • Medición pasiva y silenciosa. El mecanismo se apoya en delivery receipts que el receptor no nota («silent delivery receipts»); el valor de la demo está en extraer un side-channel (RTT) que no deja notificación en el dispositivo objetivo.
  • Transparencia sobre mitigaciones y límites éticos. El README dedica una sección a «How to Protect Yourself», aclara que desactivar las confirmaciones de lectura no protege contra este ataque concreto y que, a diciembre de 2025, la vulnerabilidad seguía siendo explotable en WhatsApp y Signal; además pide no rastrear personas sin consentimiento («this may violate privacy laws»).

Una imagen de investigación de seguridad ética mostrando la frontera entre demostración y mal uso, con un emblema en forma de escudo hecho de líneas de código y una insignia de licencia MIT brillando suavemente, una etiqueta de advertencia que dice "educational and security research purposes only", paneles translúcidos alrededor mostrando consejos de protección de privacidad, requisitos de consentimiento y notas de divulgación responsable, un usuario desactivando las confirmaciones de lectura con una pequeña X roja indicando que esto no protege completamente, y una línea de frontera legal/ética separando la investigación autorizada de la vigilancia no consentida

Cómo funciona

El flujo técnico documentado (README, src/, package.json y docker-compose.yml):

  1. Autenticación: para WhatsApp se escanea un código QR con la app (vía la librería @whiskeysockets/baileys); para Signal se usa el servicio signal-cli-rest-api en modo json-rpc, conectándose por WebSocket para recibir los receipts.
  2. Enviado de probes: el tracker envía sondas al número objetivo. Dos métodos:
    • Delete (por defecto): envía una solicitud «delete» para un ID de mensaje inexistente.
    • Reaction: envía un emoji de reacción a un ID de mensaje inexistente.
    • En Signal los métodos son reaction y message (según src/signal-tracker.ts).
  3. Medición del RTT: se mide el tiempo entre el envío del probe y la recepción del CLIENT ACK (estado 3) como RTT.
  4. Clasificación por umbral dinámico: se calcula un umbral como el 90 % de la mediana del RTT; valores por debajo indican uso activo, por encima indican reposo. Las mediciones se guardan en un historial y la mediana se actualiza continuamente para adaptarse a distintas condiciones de red.
  5. Interfaz: la web (React + Tailwind + Recharts) muestra mediciones en tiempo real, detección de estado y patrones, con un desplegable para cambiar el método de probe; el modo CLI (solo WhatsApp) imprime un panel con JID, estado, RTT, media (3), mediana y umbral.

Un diagrama técnico detallado mostrando cómo funciona device-activity-tracker: un dispositivo emisor a la izquierda emite un pequeño mensaje "probe" hacia un smartphone objetivo a la derecha, mostrado en corte transversal semitransparente con batería, CPU y capa de servicio de mensajería, una regla de tiempo entre ambos midiendo el RTT como un haz horizontal brillante, con marcadores para probe enviado, delivery receipt y CLIENT ACK, y un nodo procesador central calculando un umbral dinámico desde una mediana móvil

Stack verificado en package.json: backend en TypeScript 5 + Express 5 + socket.io + pino (logs) + ws; WhatsApp vía @whiskeysockets/baileys (^7.0.0-rc.9); Signal vía el servicio bbernhard/signal-cli-rest-api; frontend en React 18 con Tailwind CSS; empaquetado con Docker Compose (tres servicios: backend, client y signal-api). Los lenguajes que reporta la API: TypeScript (105.143 bytes), HTML (1.721), Dockerfile (1.529), CSS (1.043) y JavaScript (246).

Estructura del proyecto (según el README):

device-activity-tracker/
├── src/
│   ├── tracker.ts         # Lógica de RTT de WhatsApp
│   ├── signal-tracker.ts  # Lógica de RTT de Signal
│   ├── server.ts          # Servidor API (ambas plataformas)
│   └── index.ts           # Interfaz CLI
├── client/                # Interfaz web React
└── package.json

Una imagen de espacio de trabajo de desarrollador cyberpunk representando el stack y arquitectura verificados del proyecto: un diagrama central de Docker Compose con tres contenedores brillantes etiquetados backend, client y signal-api, conectados por flujos WebSocket y REST API, con paneles translúcidos flotantes mostrando TypeScript, Express, socket.io, pino, ws, React, Tailwind CSS y Recharts, y una ventana de terminal con salida CLI mostrando JID, estado, RTT, media, mediana y umbral

Estado oficial / semioficial

  • No es un elemento de marketplace ni un producto: es un PoC autoalojado, sin paquete publicado en ningún registro (el package.json declara private: true, por lo que no existe una versión npm/PyPI/crates.io/Docker Hub del proyecto en sí).
  • Su «aval» es académico, no comercial: la credibilidad proviene del paper subyacente —un trabajo con Best Paper Award en RAID 2025— que esta implementación ejecuta. En la práctica, esto convierte el repositorio en una referencia comunitaria del ataque «Careless Whisper», aunque no hay constancia de que WhatsApp o Signal lo reconozcan oficialmente ni de que algún proveedor lo «certifique».
  • Sin designación formal de las plataformas: el README afirma que, a diciembre de 2025, la vulnerabilidad «remains exploitable in WhatsApp and Signal»; no hay rastro de un parche público o de una declaración oficial de las empresas en las fuentes consultadas.
  • Marco ético/semioficial: la licencia MIT añade disclaimers que eximen a los autores de mal uso, recomiendan la divulgación responsable de vulnerabilidades y desaconsejan el espionaje no autorizado. Esto no es un estatus, pero condiciona cómo debe leerse el proyecto.

El ecosistema

Dependencias del ecosistema sobre las que se construye

RepositorioEstrellas (API de GitHub, 1 sep 2026)Función
WhiskeySockets/Baileys10.950 (3.347 forks)«Socket-based TS/JavaScript API for WhatsApp Web»; la base por la que el PoC habla con WhatsApp sin la app oficial.
bbernhard/signal-cli-rest-api2.821«Dockerized Signal Messenger REST API»; el servicio que el PoC usa para enviar sondas a Signal y recibir receipts.

Reimplementaciones independientes del ataque «Careless Whisper»

La búsqueda de repositorios de GitHub devolvió varios PoC ajenos que replican el mismo ataque (son los «competidores» reales más cercanos). Cifras de estrellas recuperadas en esta ejecución:

RepositorioEstrellasDiferencia verificable
ctrlsam/careless-whisper-python17«Monitoring users via Silent Delivery Receipts Exploit (WhatsApp and Signal)» en Python.
Ti-03/Careless-Whisper14«real-time surveillance tool leverages WhatsApp RTT» — enfoque en vigilancia en tiempo real.
190-785/WhatsApp-Careless-Whisper6«Go-based RTT probe tool for WhatsApp, replicating the Careless Whisper».
milouk/whatsapp-tracker6«Whatsapp side-channel attack and monitoring tool based on the Careless [Whisper]».
xalaetrx/Whatsapp-Tracker4«research POC for WhatsApp OS fingerprinting and presence monitoring» — añade fingerprinting del SO.
moltrus/careless-whisper0«PoC to track any WhatsApp phone number based on delivery receipts + [RTT]».
Ionete-Andrei/careless-whisper-survey0«A technical survey of the Careless Whisper attack (Gegenhuber et al.)» — un estudio técnico, no un PoC.
tr4m0ryp/wa-activity-collector0«WhatsApp RTT side-channel tracker (Careless Whisper / RAID 2025)» con registro (logging).

Forks del propio repositorio

La API listó un total de 699 forks, la mayoría sin estrellas. Los pocos con estrellas registradas: guberm/device-activity-tracker (8), mwakidenis/device-activity-tracker (5), imanbarati/device-activity-tracker (1), HiS515HAM/device-activity-tracker (1) y mikebodojr/device-activity-tracker (1). No se detectó ninguna traducción no inglesa entre los forks; en el historial de incidencias sí aparece una PR (#48, «Translation pipeline for internationalization of the repo», cerrada) que intentó añadir internacionalización.

Una imagen de ecosistema comunitario mostrando múltiples reimplementaciones independientes del mismo ataque de seguridad como una constelación ramificada de GitHub, con un nodo de repositorio central brillante conectado a varios nodos más pequeños etiquetados con iconos abstractos de lenguaje: Python, Go, TypeScript y estudio de investigación, cada nodo mostrando una insignia de conteo de estrellas, líneas de fork y fragmentos de código, formando una red de herramientas PoC descentralizadas

Otros proyectos del autor

La cuenta gommzystudio tiene 27 repositorios públicos, pero ninguno directamente relacionado con la seguridad de mensajería (destacan AldiTalk-True-Unlimited con 55 estrellas y BambuStudio con 2). El autor es, por tanto, un desarrollador generalista; este PoC es su proyecto con diferencia más visible.

Estas cifras provienen de la API de GitHub y de la búsqueda de repositorios durante esta investigación; no son una auditoría de calidad, soporte ni compatibilidad de cada derivado.

Números del repo

Medición: 1 de septiembre de 2026, API de GitHub.

MétricaValor
Estrellas5.107
Bifurcaciones699
Suscriptores64
Incidencias abiertas indicadas por la API33
Lenguaje principalTypeScript
LicenciaMIT (con disclaimers adicionales)
Creación7 de diciembre de 2025
Último push31 de diciembre de 2025
Última actualización de metadatos1 de septiembre de 2026
ReleasesSin releases publicados (endpoint vacío)
Tamaño del repo374 KB

Los principales contribuidores devueltos por la API, por número de contribuciones: gommzystudio (37), robcerda (2) y varios con 1 (AjayAntoIsDev, verynewusername, JathinYadav, onem0). La actividad está muy concentrada en el autor.

Caveats de la API: open_issues_count (33) incluye solicitudes de cambios abiertas, por lo que no debe leerse como un conteo exclusivo de incidencias. El campo watchers_count de la respuesta general replica las estrellas (5.107); por eso se informa por separado subscribers_count (64) como suscriptores reales. No se publicaron releases, así que la versión se gestiona por el código (versión 1.0.0 en package.json) y no por tags.

Un panel de datos hero para métricas de repositorio: un gran panel de analítica en modo oscuro muestra estadísticas de GitHub en tarjetas neón brillantes: 5.107 estrellas, 699 forks, 64 suscriptores, 33 incidencias abiertas, TypeScript como lenguaje principal, licencia MIT, tamaño de repositorio de 374 KB, sin releases, y una línea de tiempo de diciembre de 2025 a septiembre de 2026, con un gráfico de barras 3D central mostrando el crecimiento a lo largo del tiempo

Cómo contribuir

El CONTRIBUTING.md documenta un flujo estándar:

  1. Hacer una bifurcación (fork) del repositorio y clonarlo.
  2. Crear una rama: git checkout -b feature/my-change.
  3. Instalar dependencias: npm install (y cd client && npm install && cd ..).
  4. Hacer los cambios.
  5. Abrir una solicitud de cambios (PR) con una descripción y motivación cortas.

Pautas documentadas: mantener PRs pequeñas y enfocadas, preferir TypeScript y seguir el estilo existente, no commitear datos de autenticación/sesión ni secretos, y respetar las notas éticas/legales del README (solo investigación y educación). No se recuperó un arnés de pruebas/evaluación específico; el historial de incidencias muestra PRs de la comunidad que siguen este flujo (por ejemplo, #88 «fix: WhatsApp QR code not loading in web UI», #66/#61 «Fix Recharts Tooltip labelFormatter TypeScript error», #49 «feat: Implement Smart Adaptive Prediction using K-Means», #53 «Refactor/separate frontend from backend», #56 «Add api port env var»).

Cómo lo recibió la comunidad

El repositorio tiene poca tracción en Hacker News por sí mismo, pero el paper que implementa sí generó debate. Los envíos verificables:

Sobre el paper (arXiv 2411.11194):

  • 46085197 «Exploiting silent delivery receipts to monitor users on instant messengers» — 20 puntos, 4 comentarios (29 de noviembre de 2025). Comentarios concretos:
    • rzl: «This has been making the rounds in privacy-focused forums and whatnot and still no comment from the foundation. That doesn’t inspire a lot of confidence in the Signal Foundation. If nothing else, I would expect that sending delivery receipts to invalid messages be considered a bug to fix…»
    • Stefan-H (respuesta a rzl): «An attacker with a privileged position on the network allowing them to eavesdrop (but not decrypt) traffic could use a bug like this to identify the device on the network associated with a phone number in Signal. Given nation state level adversaries, that seems like a significant privacy issue to me».
    • 8cvor6j844qw_d6 enlazó una lectura relacionada sobre tácticas del FBI (Press Herald).
  • Otros envíos del paper con poca tracción: 46034272 (5 puntos, 0 comentarios), 46466372 (3 puntos, 0 comentarios).

Sobre el repositorio en concreto (todos con 0 comentarios):

  • 46220607 «Device Activity Tracker: WhatsApp Activity Tracker via RTT Analysis» — 1 punto (10 de diciembre de 2025).
  • 46422304 «Exploiting Silent Delivery Receipts to Monitor Users on WhatsApp/Signal» — 1 punto (29 de diciembre de 2025).
  • 46443724 «Exploiting Silent Delivery Receipts to Monitor Users on Instant Messengers» — 3 puntos (31 de diciembre de 2025).

Incidencias y problemas recurrentes (GitHub): el hilo de issues muestra una queja concreta y medible que se repite:

  • El QR de WhatsApp no aparece, pero el de Signal sí: #52 «Signal QR code is working, but WhatsApp’s doesn’t», #74 «Follow up (WA not working)» («signal works and i successfully connected… but qr code for whatsup doesn’t show up… In CLI version it just says qr:undefined»), #67 «QR code is not generating anymore for whatsapp since last 4 hours» y #64 «Verification Failed».
  • Fallo de build del cliente: #68 «Client Build Failed both through docker and npm» con el error TS2322: Type '(t: number) => string' is not assignable… (problema de tipado del tooltip de Recharts, tratado también en #69 y en las PR #66/#61).
  • QR de Signal no visible: #54 «Signal QR Code Not Showing On port 3000» (el usuario copia .env.sample a .env, levanta docker compose up -d/--build, accede a localhost:3000 pero el QR de Signal no se muestra y localhost:8080 da 404).
  • Varios issues sin contenido útil (por ejemplo #79 «Fff», #62 y #60 con solo números de teléfono) y algunos con marcado carácter de spam/no señal (PR #85 «Rename README.md to 0812-9328-1098», PR #79/#87/#86 «Create SECURITY.md»).

Video (búsqueda de YouTube, 1 de septiembre de 2026): se recuperaron títulos claramente ligados al tema; se listan sin cifras de vistas/canal porque no se pudieron capturar de forma fiable: «Explorando Vulnerabilidades de Privacidade no WhatsApp: Device Activity Tracker na prática» (Portugués, explícitamente sobre este repo) y «Track Anyone On WhatsApp | WhatsApp Tracker | Real Time Tracing» (título genérico, no confirmado como de este repo exacto). El resto de resultados de la búsqueda eran apps comerciales de «rastreo WhatsApp» y no corresponden a este proyecto.

No se recuperó evidencia verificable en Reddit (el sitio devolvió contenido no parseable), ni en X/Twitter (bloqueado), ni en Product Hunt; por tanto no se afirman métricas de esas plataformas.

device-activity-tracker frente a otras propuestas

ProyectoEstrellas (API de GitHub, 1 sep 2026)Diferencia verificable
ctrlsam/careless-whisper-python (17)Reimplementación del mismo ataque.Escrita en Python; este PoC es TypeScript con web React + CLI, y soporta Signal de forma integrada.
Ti-03/Careless-Whisper (14)Otro PoC del mismo ataque.Se enmarca como «herramienta de vigilancia en tiempo real»; distinto stack y sin la capa web de este.
190-785/WhatsApp-Careless-Whisper (6)Probe de RTT para WhatsApp.Escrito en Go y limitado a WhatsApp; este soporta también Signal.
milouk/whatsapp-tracker (6)«Side-channel attack and monitoring tool based on Careless Whisper».Enfoque en WhatsApp; distinto stack.
xalaetrx/Whatsapp-Tracker (4)PoC de fingerprinting de SO y presencia.Añade fingerprinting del sistema operativo como objetivo explícito; el README de este solo lo menciona como posible inferencia.
Ionete-Andrei/careless-whisper-survey (0)No es un PoC.Es un estudio técnico del ataque; útil como referencia de fondo, no como herramienta.

La comparación más útil no es por popularidad: este repo destaca porque combina ambas plataformas (WhatsApp y Signal) en una sola app web + CLI sobre las dos dependencias maduras del ecosistema (Baileys y signal-cli-rest-api). Los PoC ajenos suelen limitarse a WhatsApp o a un solo lenguaje. Su desventaja práctica es la inmadurez operativa (los issues sobre el QR de WhatsApp y el build del cliente son recurrentes) y la ausencia de releases/versionado formal.

Guía rápida de uso

Aviso: el README y la licencia lo declaran estrictamente para investigación y educación. No usarlo para rastrear a personas sin consentimiento puede vulnerar leyes de privacidad, de escuchas y de fraude informático.

Instalación y primer arranque

Prerrequisitos: Node.js 20+, npm y una cuenta de WhatsApp (y, para Signal, el servicio signal-cli-rest-api que ya incluye el docker-compose.yml).

git clone https://github.com/gommzystudio/device-activity-tracker.git
cd device-activity-tracker
npm install
cd client && npm install && cd ..

Opción Docker (recomendada por el README):

cp .env.example .env
docker compose up --build

Al arrancar, la app queda disponible en:

  • Frontend: http://localhost:3000 (o el CLIENT_PORT configurado).
  • Backend: http://localhost:3001 (o el BACKEND_PORT).

Para detener: docker compose down.

Setup manual (sin Docker):

# Terminal 1: backend
npm run start:server
# Terminal 2: frontend
npm run start:client

Abrir http://localhost:3000, escanear el código QR con WhatsApp y luego introducir el número a rastrear (por ejemplo, 491701234567).

CLI (solo WhatsApp):

npm start

Seguir las indicaciones para autenticarse e introducir el número objetivo. El resultado se imprime en la terminal como un panel con JID, estado, RTT, media (3), mediana y umbral (el README muestra un ejemplo con estado «Standby» y RTT 1104 ms).

Flujos de trabajo habituales

  • Rastrear el estado de un número en la web: arrancar la app → escanear QR de WhatsApp → escribir el número objetivo → la interfaz muestra en tiempo real RTT, estado (🟢/🟡/🔴) y el patrón de actividad; el resultado se refleja en vivo en la UI (React + Recharts).
  • Cambiar el método de probe: en la interfaz web, usar el desplegable del panel de control para alternar entre Delete (por defecto) y Reaction; en modo CLI se usa «delete» por defecto.
  • Rastrear por Signal: al usar Docker, el servicio signal-api (bbernhard/signal-cli-rest-api) ya corre; en la web se selecciona Signal y se escanea su QR. Los métodos de probe disponibles para Signal son reaction y message.
  • Rastrear desde terminal (WhatsApp): npm start → autenticarse → introducir el número → observar el panel de estado en la consola.

Configuración esencial

Según .env.example y el README, lo que un usuario nuevo toca primero:

  • BACKEND_PORT (por defecto 3001) — puerto del servidor backend.
  • CLIENT_PORT (por defecto 3000) — puerto de la interfaz web.
  • SIGNAL_API_URL (por defecto http://localhost:8080) — URL del servicio de la API de Signal, necesario para el rastreo de Signal.
  • BACKEND_URL (por defecto http://localhost:3001) — URL del backend que consume la frontend.
  • NODE_ENV (por defecto production) — entorno de ejecución de Node.

Trampas frecuentes y soluciones

Según el README, las incidencias y los hilos de la comunidad:

  • No se conecta a WhatsApp: la solución documentada en el README es borrar la carpeta auth_info_baileys/ y volver a escanear el QR. (Nota: el volumen del docker-compose.yml se monta como baileys_auth:/app/baileys_auth_info, con una denominación ligeramente distinta; conviene verificar la ruta real en el contenedor si el estado persiste entre reinicios.)
  • El QR de WhatsApp no aparece pero el de Signal sí (issues #52, #67, #74, #64): es el fallo más reportado. El README no lo resuelve directamente; hay PRs abiertas de corrección (por ejemplo #88 «fix: WhatsApp QR code not loading in web UI»). En la práctica, actualizar a la última rama y regenerar el estado de autenticación son los pasos habituales.
  • Fallo de build del cliente (TS2322 del tooltip de Recharts) (#68, #69, PR #66/#61): el error Type '(t: number) => string' is not assignable… bloquea npm run build tanto por Docker como por npm. Se corrigió en PRs de tipado de labelFormatter; si aparece, hay que aplicar esa corrección o usar una versión del cliente ya corregida.
  • QR de Signal no visible y localhost:8080 con 404 (#54): indica que el servicio signal-api no está listo o no expone el endpoint esperado; verificar que el contenedor signal-api arrancó y que SIGNAL_API_URL apunta al puerto correcto.
  • Desactivar las confirmaciones de lectura NO protege: el README aclara que esta mitigación sirve para mensajes normales pero no contra este ataque concreto; la mitigación más efectiva sugerida es activar «Block unknown account messages» en WhatsApp (Ajustes → Privacidad → Avanzado), aunque WhatsApp no publica qué entiende por «high volume», así que no previene por completo las sondas antes del límite de tasa.
  • Comportamiento no obvio del umbral: la clasificación depende de la mediana móvil; en redes inestables el umbral se recalcula continuamente, por lo que un «Standby» no implica necesariamente que el dispositivo esté apagado, solo que el RTT superó el 90 % de la mediana.

Integraciones y migración

  • Con Baileys (WhatsApp Web): el PoC se apoya en @whiskeysockets/baileys para toda la comunicación con WhatsApp; cualquier integración con WhatsApp Web vía Baileys reutiliza el mismo patrón de sesión (QR + estado local).
  • Con signal-cli-rest-api (Signal): el rastreo de Signal requiere ese servicio (modo json-rpc, WebSocket); es una dependencia externa que corre como contenedor aparte.
  • Con Docker Compose: los tres servicios (backend, client, signal-api) se orquestan juntos; el backend persiste el estado de autenticación de WhatsApp en el volumen baileys_auth.
  • Migración entre PoC del mismo ataque: dado que todos (ctrlsam/careless-whisper-python, 190-785/WhatsApp-Careless-Whisper, Ti-03/Careless-Whisper, etc.) implementan el mismo principio (RTT de receipts), «migrar» equivale a cambiar de lenguaje/stack (TypeScript → Python/Go) y de dependencia (Baileys para WhatsApp); la lógica de umbral por mediana es común al enfoque del paper. No existe un conversor documentado entre ellos.

Casos de uso y a quién puede ayudar este repositorio

  • Investigadores en seguridad y privacidad que necesitan una implementación ejecutable del paper «Careless Whisper»: el PoC traduce el trabajo de RAID 2025 a código listo para probar (con la cita BibTeX del paper), útil para reproducir, validar o extender el ataque en un entorno controlado y con consentimiento.
  • Equipos que auditaban o quieren auditar la superficie de side-channels de sus flujos de mensajería: al mostrar cómo un RTT de delivery receipt revela presencia/actividad, sirve como referencia para entender qué metadatos (estado, red, frecuencia de uso) pueden filtrarse en apps de mensajería.
  • Educadores y divulgadores de seguridad: el disclaimer explícito «research and educational purposes only», la sección «How to Protect Yourself» y los tres estados (online/standby/offline) lo hacen apto como material didáctico para explicar vulnerabilidades de privacidad con un caso concreto.
  • Usuarios que quieren entender cómo protegerse: el README documenta mitigaciones concretas (activar «Block unknown account messages» en WhatsApp; entender que desactivar las confirmaciones de lectura no basta), de modo que una persona puede usar la herramienta para verificar su propia exposición y después aplicar las defensas.
  • Desarrolladores que trabajan con Baileys o signal-cli-rest-api: la app web + CLI + Docker Compose muestra un patrón práctico para combinar ambas dependencias (sesión WhatsApp por QR vía Baileys y receipts de Signal por WebSocket) en un solo backend Express + socket.io.

Una imagen de estado dramática con tres siluetas de smartphone flotantes en composición triangular: el teléfono izquierdo brilla en verde con la etiqueta "Online" y una forma de onda RTT rápida, el teléfono central brilla en ámbar con "Standby" y pulsos de latencia más lentos, el teléfono derecho es rojo con "Offline" y sin señal de confirmación, detrás una gran pantalla de radar mapea patrones de actividad del usuario a lo largo del tiempo con mapas de calor mostrando periodos de uso, reposo y desconexión

Recursos


Nota: este artículo combina el README, CONTRIBUTING.md, LICENSE, package.json, .env.example y docker-compose.yml del repositorio, la página del paper en arXiv (2411.11194), la API de GitHub (repositorio, contribuidores, forks, búsqueda de repositorios), los perfiles de las dependencias y los hilos de Hacker News consultados el 1 de septiembre de 2026. Las cifras cambian con el tiempo. No se pudieron verificar fuentes en Reddit, X/Twitter ni Product Hunt, ni cifras de vistas/canal en YouTube durante esta investigación; esas plataformas quedan expresamente sin afirmar. El proyecto se declara para fines exclusivamente de investigación y educación.

Comentarios