Droidwatch dentro de tu asistente de IA
Analiza un APK sin salir del chat en el que ya estás. Pregunta «¿esta app es maliciosa?», suelta el fichero, y recibes un veredicto, el C2 del atacante si lo hay, y los hallazgos que importan.
Qué es
Un cliente fino — un fichero de Python, sin dependencias. Sube, sondea y trae el resultado. Todo el análisis ocurre en nuestros servidores.
Es deliberado, y no sólo porque el analizador no se distribuye: un agente
manejando jadx y semgrep en tu portátil sólo ve lo que esas herramientas
ven. No se puede improvisar «he visto diez mil muestras». La inteligencia de
amenazas, un modelo entrenado sobre un corpus y el histórico para correlacionar
campañas son cosas que viven en el servidor o no existen.
Instalar
git clone https://github.com/<tu-org>/droidwatch-skill
export DROIDWATCH_API_KEY=dw_... # opcional
Apunta tu asistente a la carpeta. Lo único que hace falta es Python 3.
Funciona sin clave, en modo anónimo y con límites. Es la forma de probarlo antes de decidir nada.
La clave se crea en droidwatch.app → Mi perfil → Claves de API, con ámbito
read + analyze. Con read only el servidor responde 403.
Límites
| Cómo la uses | Análisis/día | Tamaño máx. |
|---|---|---|
| Sin clave (anónimo) | 3 | 150 MB |
| Cuenta gratuita | 5 | 200 MB |
Pro (con clave dw_) |
100 | 500 MB |
| Team | 500 | 750 MB |
| Enterprise | sin tope | 1 GB |
La skill no está restringida. Lo que necesita plan Pro es la clave, que levanta los límites — no la skill. Cualquiera puede probarla en anónimo.
Usar
python3 scripts/droidwatch.py analyze sospechoso.apk
python3 scripts/droidwatch.py summary <run_id>
python3 scripts/droidwatch.py lookup evil-c2.example.com
Un análisis tarda de 1 a 10 minutos según el tamaño.
Qué devuelve
JSON compacto — unos 8 KB, frente a un informe completo de hasta 740 KB, así que cabe en el contexto de un modelo y le queda sitio para razonar:
| Campo | Qué es |
|---|---|
veredicto |
Benign · Low Risk · Suspicious · High Risk · Malicious, con puntuación |
hallazgos.graves |
Lo crítico y lo alto, ya priorizado |
iocs.c2 |
La infraestructura del atacante, descifrada de la muestra |
attack |
Técnicas MITRE ATT&CK Mobile |
masvs |
Boletín de postura de seguridad |
defensas_runtime |
Si la muestra pelea contra el análisis |
sin_analizar |
Etapas que no completaron |
bloqueado_por_plan |
Secciones que el análisis sí produjo y tu plan no incluye |
Lo que no hace
Responde «¿esto es malicioso y quién está detrás?», no «¿tiene mi app una vulnerabilidad?». Para auditar tu propio código, ésta no es la herramienta.
Y no analizará algo que no tengas derecho a analizar.
Por qué importan los tres últimos campos
sin_analizar y las marcas de truncado existen para que un asistente no pueda
darte una falsa tranquilidad. «No se encontró» y «no se pudo buscar» son
frases distintas, y un resumen que esconde la diferencia es peor que no tener
resumen. Las instrucciones de la skill obligan al modelo a decir cuál de las dos
es.
Lo mismo con defensas_runtime: si la muestra se cierra al detectar la
instrumentación, un informe dinámico vacío no es prueba de inocencia — y se
te dirá.
Y lo mismo con bloqueado_por_plan. Autenticidad de app —typosquatting,
comparación del icono con la ficha de Play, señales de reempaquetado— es una
sección de pago, así que en un plan gratuito no viaja. Lo que el resumen no
hace es fingir que no encontró nada: los hallazgos bloqueados siguen contando en
hallazgos.total, y el campo dice cuántos son. Un candado que se ve es honesto;
uno silencioso es un informe que se lee como completo y no lo está.