Stacktrace of obfuscated code displays unobfuscated class name?

Question

I'm working with a server-addon for Minecraft, which happens to be obfuscated. I've always thought that, after obfuscation, it's impossible to restore the original class names because they're completely removed, and it's what I've read everywhere. After tinkering with it for a while, I noticed that when an uncaught exception appears in the console, it shows the obfuscated names of the classes (eg. at cratereloaded.aT.d), and then inside parenthesis, where it usually shows the name of the class and the offending line, it shows the original class name, which leads me to believe that it can actually be deobfuscated. But of all tools I've tried, none seems to be able to restore the original class name, even though after some hex examination I've confirmed the original class name IS actually embedded in the compiled '.class' files.

Is there any tool which is capable of using that to restore class names automatically?

Example stacktrace:

[03:49:57] [Server thread/ERROR]: Error occurred while disabling CrateReloaded v1.3.97.1 (Is it up to date?)
java.lang.NullPointerException: null
    at cratereloaded.aT.d(CrateManager.java:303) ~[?:?]
    at cratereloaded.aT.bm(CrateManager.java:298) ~[?:?]
    at cratereloaded.aT.cleanup(CrateManager.java:83) ~[?:?]
    at cratereloaded.aX.disable(Manager.java:27) ~[?:?]
    at cratereloaded.b.cleanup(CrateReloaded.java:122) ~[?:?]
    at cratereloaded.b.onDisable(CrateReloaded.java:109) ~[?:?]
    at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:266) ~[spigot.jar:git-Spigot-596221b-2c5c611]
    at org.bukkit.plugin.java.JavaPluginLoader.disablePlugin(JavaPluginLoader.java:361) [spigot.jar:git-Spigot-596221b-2c5c611]
    at org.bukkit.plugin.SimplePluginManager.disablePlugin(SimplePluginManager.java:421) [spigot.jar:git-Spigot-596221b-2c5c611]
    at org.bukkit.plugin.SimplePluginManager.disablePlugins(SimplePluginManager.java:414) [spigot.jar:git-Spigot-596221b-2c5c611]
    at org.bukkit.craftbukkit.v1_12_R1.CraftServer.disablePlugins(CraftServer.java:342) [spigot.jar:git-Spigot-596221b-2c5c611]
    at net.minecraft.server.v1_12_R1.MinecraftServer.stop(MinecraftServer.java:464) [spigot.jar:git-Spigot-596221b-2c5c611]
    at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:612) [spigot.jar:git-Spigot-596221b-2c5c611]
    at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]

Answer 1

I took a look at CrateReloaded. It appears that although the code has been obfuscated, the author forgot to remove debugging information. Hence, you are seeing the somewhat magically deobfuscation in the stack trace.

There are several standalone decompilers - CFR, Fernflower, JD-Core, JAD, Procryon, etc. that can be used to decompile JARs in to near source code quality. You can also use online resources such as Decompilers online to create sources.

If you use Eclipse, I would recommend adding the Eclipse Class Decompiler plugin via the Eclipse Marketplace. This plugin supports the above mentioned decompilers and will decode class files on the fly. For example, if CrateReloaded is included as a regular dependency or Maven dependency, you can drill down into the JAR via the project explorer. Opening a class renders it in its decompiled form. More importantly, this decompilation works automatically when debugging steps into obfuscated code.

However, I strongly encourage you not to rely on obfuscated Spigot/Bukkit plugins.

• It goes against the GPL. Bukkit is GPL, code that uses Bukkit and is distributed is also GPL. Hence the author, while retaining all rights to the code, must provide a means for others to ... generate, install, and run the object code and to modify the work, including scripts to control those activities. There are some exceptions, such as the author developing code in an obfuscated form rather than using a utility, or have their work considered as a system library. Intentionally obfuscating code sends the wrong message, especially since it is only functional because of code written by many others such as Bukkit, Apache, Google, etc. all of which are open source.

• Plugin authors come and go for one reason or another. I have seen many great plugins go stale because their author lost interest, got a real job, etc. Having source code available, allows server operators to maintain an in-house version for their servers and others to pick up the slack and continue development.

• Despite best intentions, a plugin code may be of low quality. A prudent server operator will always review plugin source code to gauge the experience of the author and the quality of the code.

• Some plugins may contain intentional or unintentional vulnerabilities that could compromise a server. Having source code available allows the operator and the community to scrutinize code.

• Some plugins can suffer from feature creep and start trying to do too much. While a plugin's core capabilities may be desired, other wizbang, neat, cool features added over time may get in the way, requiring more configuration, if at all possible, to disable features not needed. We call this the Swiss Army Knife Syndrome. In such cases, server operators can fork their own version and update code as needed when new server versions are released.

Obviously, if your plugin is intended for a private server not accessible by the public, some of these concerns are not applicable. But if it is, please consider them.