Decompiling a .jar (secrets in bytecode)

Un fichero .jar (Java Archive) es, por dentro, un ZIP que empaqueta clases Java compiladas (.class) más recursos y un manifiesto. El .class no es código máquina nativo: es bytecode de la JVM, un formato intermedio que conserva nombres de métodos, campos, cadenas y estructura. Eso lo hace reversible casi a su forma original.

La técnica

Antes de descompilar, unzip + strings ya suele soltar lo fácil (URLs, rutas, credenciales en claro); si hace falta el código, un descompilador reconstruye el bytecode en Java legible:

unzip -o playercounter.jar -d out          # abrir el JAR (es un ZIP)
strings out/**/*.class | grep -iE 'pass|pwd|secret|token|rcon'   # cribado rapido
# descompiladores de linea de comandos (mas fieles que ver .class a pelo):
java -jar cfr.jar playercounter.jar --outputdir src_cfr
procyon -jar playercounter.jar -o src_procyon
# o GUI para inspeccionar a ojo: JD-GUI / jd-cli

CFR, Procyon y Fernflower son descompiladores de línea de comandos; JD-GUI/jd-cli es el gráfico, rápido para mirar a ojo.

Por qué importa en una intrusión

Los desarrolladores incrustan secretos en el código pensando que el binario es opaco: contraseñas de bases de datos, tokens de API, claves de cifrado, credenciales de servicios internos. Descompilar los deja a la vista. En Crafty, un plugin a medida de un servidor de Minecraft (playercounter.jar) se autenticaba contra un servicio RCON local con la contraseña del Administrator hardcodeada; abrirlo con JD-GUI bastó para recuperarla y, de ahí, ejecutar como Administrator.

No es exclusivo de Java

El mismo principio aplica a otros formatos que conservan metadatos: ensamblados .NET (con dnSpy, ILSpy), APK de Android (jadx -d out app.apk), o incluso bundles de JavaScript minificado. Cualquier artefacto que se distribuya con el cliente o caiga en manos del atacante es auditable.

Requisitos

Tener el artefacto (.jar/.dll/.apk) en disco. No hace falta nada más: la descompilación es offline y no toca ningún servicio. El valor depende de que el desarrollador haya dejado secretos dentro.

Cómo detectarlo. El análisis es offline en la máquina del atacante y no deja telemetría en la víctima. La detección se sitúa antes (la exfiltración del artefacto: una descarga del .jar de un share o del webroot, un 4663/5145) y después (el uso del secreto recuperado, por ejemplo un login con la credencial hardcodeada desde un host inusual). Un binario propietario copiado fuera de su ubicación normal es la señal temprana.

Defensa. No incrustar secretos en el código (usar gestores de secretos, variables de entorno o vaults); si hay que distribuir lógica sensible, ofuscar (ProGuard) reduce la legibilidad pero no es protección real contra un analista decidido. La regla de oro: un binario en manos del cliente es un binario público. Alimenta el rastreo de credenciales y la reutilización de credenciales.