Pentesting de Android con IA: la Skill de DragonJAR en Hermes

Estimados amigos de Inseguros !!!

Esta semana me lié «5 minutos» a montar una cosa que tenía ganas de probar… y ya sabéis cómo acaban mis cinco minutos. La idea: auditar APK´s de Android dejándole el trabajo sucio a un agente de IA.

La pieza central es la Android Pentesting Skill de DragonJAR, una «skill» que convierte a tu agente en un auditor de aplicaciones Android: decompila, mapea superficie de ataque en el Manifest, caza secretos, traza flujos source-to-sink, puntúa con MASVS y, si tienes dispositivo, hace análisis dinámico con Frida.

Te cuento el montaje real. Con los batacazos, que es lo que no sale en los README 🙂

Qué es una «skill» y por qué esto no es magia

Una skill, en el estándar de agentes, es poco más que un SKILL.md: instrucciones y scripts que el agente carga cuando toca. Nada de modelos nuevos ni brujería. Le dices «audita este APK» y el agente sigue el procedimiento que trae dentro, apoyándose en herramientas que tienen que estar ya en tu máquina: APKTool, JADX, el SDK de Android, Frida…

Yo no uso Claude Code para esto, uso Hermes, el agente de Nous Research, que corre local en mi Mac mini. La skill es compatible, así que sobre el papel era copiar y listo.

Sobre el papel.

Instalar la skill en Hermes (y por qué no me aparecía)

Clono el repo entero en la carpeta de skills y… no aparece por ningún lado. Clásico.

Dos motivos, y los dos son de esos que te comen media tarde:

Uno, la ubicación. En Hermes las skills viven en ~/.hermes/skills/<categoría>/<skill>/. Yo la había dejado colgando directa en la raíz, y el agente la interpreta como una categoría vacía, no como una skill. Al meterla en una categoría (security/) y con el nombre en minúsculas-guiones, a la primera.

Dos, no hay recarga en caliente. Las skills nuevas se cogen al abrir sesión nueva, no con un comando mágico a mitad de conversación. Yo insistiendo con recargas que no existían… xDDDD

mv ~/.hermes/skills/Android-Pentesting-Skill \
   ~/.hermes/skills/security/android-pentesting-skill
# y reiniciar Hermes

hermes skills list y ahí estaba, enabled. Victoria.

El preflight y el fantasma del módulo «google»

La skill trae un preflight-check.py que te dice qué herramientas te faltan. Lo lanzo y revienta:

Error during preflight check: No module named 'google'

Y aquí la cara de tonto. ¿Google? ¿Para auditar Android? Un grep al script y aparece el culpable: hay un helper opcional para bajar APK´s desde Gmail que importa unas librerías de Google… sin protección. Falta una, y en vez de marcarla como «opcional ausente», se cae entero y aborta toda la comprobación.

No es culpa tuya, es un bug del script. Y lo importante: ese google no pinta nada en una auditoría. O lo ignoras y tiras del check a mano, o si te molesta el error, un comando y a otra cosa:

pip3 install --break-system-packages google-auth google-auth-oauthlib google-api-python-client

Al final, lo que de verdad te frena para empezar son las CLI de verdad: JADX, APKTool, Java, adb. Eso es lo que hay que tener en verde.

¿Sandbox o local? Una decisión, no un dogma

Un apunte rápido porque me lo preguntan mucho. Hermes puede ejecutar los comandos del agente en tu shell local o dentro de un contenedor Docker, como «caja cerrada». Para auditar código de terceros ejecutándolo, el contenedor es lo sano.

Para esto yo lo tenía en Docker de otra faena y lo devolví a local con un comando (hermes config set terminal.backend local), porque aquí el emulador y Frida los manejo yo fuera. Cada escenario pide lo suyo… no hay bala de plata.

Montar el laboratorio dinámico: emulador + Frida

El informe me salía con un aviso feo:

Analisis dinamico: NO REALIZADO (sin dispositivo/emulador disponible).

Normal: el dinámico necesita un Android vivo con frida-server dentro. En Apple Silicon lo limpio es el emulador oficial con imagen arm64 rooteable (la de Google APIs, no la de Google Play, que no deja root).

Aquí volví a tropezar un par de veces, para no perder la costumbre:

• avdmanager me soltó un error con el devices.xml porque no reconocía el perfil pixel_6. Solución: crear el AVD sin --device y a correr.
• Luego «el AVD ya existe»… porque se había creado igualmente en el intento fallido 🙂
• Al arrancar, un Unable to connect to adb daemon on port: 5037. Un simple adb start-server y resuelto.

Y el remate, el mejor de todos. Lanzo el bloque que baja el frida-server usando $(frida --version) para que coincida la versión… y descarga un fichero de 9 bytes que unxz no reconoce. ¿Por qué? Porque Frida no estaba instalado en el Mac, la variable salió vacía y la URL quedó rota. Media cascada de errores por no tener la herramienta base. xDDDD

pip3 install --break-system-packages frida-tools
FV=$(frida --version)
curl -L -o /tmp/fs.xz "https://github.com/frida/frida/releases/download/${FV}/frida-server-${FV}-android-arm64.xz"
unxz -f /tmp/fs.xz
adb push /tmp/fs /data/local/tmp/frida-server
adb shell chmod 755 /data/local/tmp/frida-server
adb shell "nohup /data/local/tmp/frida-server >/dev/null 2>&1 &"
frida-ps -U | head

Regla de oro que me llevo: la versión del frida-server tiene que ser idéntica a la de tu Frida de host, o no conecta. Por eso va con $(frida --version), para no fallar a mano.

Qué te llevas de esto

Con frida-ps -U respondiendo, relanzas la auditoría pidiendo el dinámico y la famosa Phase 4 ya se ejecuta: engancha Frida, prueba detectores de root/emulador/RASP y valida en runtime el SSL pinning y todo lo que en estático quedaba como «Needs Dynamic Confirmation».

Un par de avisos de los serios, que esto no es para jugar:

• Esto es para pruebas autorizadas. Analiza APK´s tuyos o con permiso por escrito, y hazlo en emulador o equipo aislado.
• El frida-server muere si reinicias el emulador. No hace falta volver a bajarlo, solo relanzarlo con el nohup de arriba.

Y la reflexión honesta: la IA te monta el andamiaje y te ahorra tecleo, pero si no sabes qué es un bypass de SSL pinning o por qué una actividad exportada es un problema, el informe te lo crees entero, erratas incluidas. La herramienta no sustituye el criterio… lo amplifica.

Y ahí está el quid. Montar esto es fácil; leer los findings con cabeza es lo que marca la diferencia, y eso no se aprende viendo un vídeo suelto un domingo. Si llevas meses con cursos empezados y ninguno rematado, con cero tiempo y sabiendo que solo no te pones, mi membresía de SeguridadSI es justo eso: una ruta, directos cada 15 días y gente que va a lo mismo que tú, a tu ritmo y sin culpa. Dentro tienes el lado ofensivo y el defensivo, y también la parte de IA aplicada y agentes que hace que montajes como este dejen de darte miedo.

Y si lo que quieres es que te lo den «hecho», consulta los SERVICIOS de CIberseguridad.

Espero que te guste y lo pruebes !!!

Gracias por leerme.