Decompiling a .jar (secrets in bytecode)

A .jar file (Java Archive) is, inside, a ZIP packaging compiled Java classes (.class) plus resources and a manifest. The .class is not native machine code: it is JVM bytecode, an intermediate format that preserves method names, fields, strings and structure. That makes it reversible almost to its original form.

The technique

Before decompiling, unzip + strings usually drops the easy stuff (URLs, paths, cleartext credentials); if you need the code, a decompiler reconstructs the bytecode into readable Java:

unzip -o playercounter.jar -d out          # open the JAR (it is a ZIP)
strings out/**/*.class | grep -iE 'pass|pwd|secret|token|rcon'   # quick triage
# command-line decompilers (more faithful than reading .class raw):
java -jar cfr.jar playercounter.jar --outputdir src_cfr
procyon -jar playercounter.jar -o src_procyon
# or a GUI to inspect by eye: JD-GUI / jd-cli

CFR, Procyon and Fernflower are command-line decompilers; JD-GUI/jd-cli is the graphical one, quick for eyeballing.

Why it matters in an intrusion

Developers embed secrets in the code thinking the binary is opaque: database passwords, API tokens, encryption keys, internal service credentials. Decompiling puts them in plain sight. On Crafty, a custom Minecraft server plugin (playercounter.jar) authenticated to a local RCON service with the hardcoded Administrator password; opening it with JD-GUI was enough to recover it and, from there, run as Administrator.

Not exclusive to Java

The same principle applies to other formats that keep metadata: .NET assemblies (with dnSpy, ILSpy), Android APKs (jadx -d out app.apk), or even minified JavaScript bundles. Any artifact shipped with the client or that falls into the attacker's hands is auditable.

Requirements

Having the artifact (.jar/.dll/.apk) on disk. Nothing else is needed: decompilation is offline and touches no service. The value depends on the developer having left secrets inside.

How to detect it. The analysis is offline on the attacker machine and leaves no telemetry on the victim. Detection sits before (the artifact's exfiltration: a download of the .jar from a share or the webroot, a 4663/5145) and after (the use of the recovered secret, for example a login with the hardcoded credential from an unusual host). A proprietary binary copied out of its normal location is the early signal.

Defence. Do not embed secrets in code (use secret managers, environment variables or vaults); if sensitive logic must ship, obfuscation (ProGuard) reduces readability but is not real protection against a determined analyst. The golden rule: a binary in the client's hands is a public binary. It feeds credential hunting and credential reuse.