Resource [Tutorial] How to deobfuscate a plugin using java-deobfuscator

Discussion in 'Spigot Plugin Development' started by MiniDigger, May 9, 2016.

  1. MiniDigger


    Hi there,

    I recently saw a post by @Vinc0682 on how to obfuscate a plugin using ProGuard.
    Since I deeply believe that everybody should open source their stuff to share cool hacks they came up with I decided to post a tutorials showing to deobfucscate using java-deobfuscator.
    Note: this will not do much to ProGuard obfuscated plugins. They are pretty readable anyways. But this tool can crack zelix klassmasters and stringers string encryption which is very handy. A deobfuscator can't restore the method and var names but they are not needed in most cases to understand a plugin.

    1. download the tool from the ci: (seem to be down @Janmm14 is hosting a mirror )
    2. open a terminal/command line
    3. navigate to the folder the plugin jar that you want to deobfuscate is in
    4. choose a transformer (
    5. locate the path to your rt.jar (its "C:\Program Files (x86)\Java\jre1.8.0_72\lib\rt.jar" for me)
    6. create a config for the obfuscator and save it as config.yaml, example:
    Code (Text):
    input: plugin.jar
    output: plugin-deobf.jar
     - path/to/rt.jar
     - your transformers
    7. execute the following command: java -jar deobfuscator.jar --config config.yaml
    (8.) you can add spigot and other dependencies of the plugin to the path but that is not necessary for most cases
    9. decompile plugin-deobf.jar using a good decompiler (I recommend fernflower or procycon, you can use luyten as drop in replacement for jd-gui ;))
    10. DON'T COPY-PASTE CODE FROM OTHERS. Just because you can, it doesn't mean you should. Use this if you want to know how someone did something and then apply that to your own code. Copy-pasting IS STEALING.
    11. Open Source your plugins. Really, its beneficial to everyone. You, as a developer, get help from the commuity fixing bugs, a server owner has better chances on long term support because a plugin an be easily continued after the official author discontinued it, and every other developer because your code can teach them how to do stuff and bring this community to new heights.

    Now, you should be able to view the deobfuscated source of every plugin.
    Please post any problems / improvements into the thread.

    Hope it helps you,

    since ppl are contacting me as some sort of obfuscation/deobfuscation guru now, let me drop this here:
    #1 MiniDigger, May 9, 2016
    Last edited: Oct 23, 2017
    • Agree x 11
    • Informative x 10
    • Like x 5
    • Useful x 3
    • Funny x 1
    • Winner x 1
    • Optimistic x 1
  2. AAC is gonna die :D
    The problem is that putting a anticheat open source is the same as telling Hack coders how to bypass it, that's why I set up my obfuscation. And btw. using a 2048 characters long replacement will make everyone ragequit since it will make you scroll sideways all the time :)

    Very good tutorial, totally agree with point 9 and really agree with point 10 in most cases!
    #2 Vinc0682, May 9, 2016
    Last edited: May 9, 2016
    • Agree Agree x 7
    • Optimistic Optimistic x 5
  3. MiniDigger


    I know the problem with anticheats. But if you can bypass a anticheat by looking at its source code, your anticheat is not good. A good protection should not be bypassable even if you know how it works.
    • Agree Agree x 17
    • Optimistic Optimistic x 4
    • Like Like x 2
  4. For sure, that's applies to some checks like BoatFly, but there are some Hacks that are in fact not 100% fixable, Killaura for example, @konsolas worked really hard on fixing it, used several methods like Bots flying arround you, heuristics analysing combat, etc.

    If someone has access to the accuracity heuristics (no, it doesn't analyse the miss quote), he could easily find out whuch criteria AAC has while everyone else fails by not knowing what the check actually does.
    Btw. Someone will find out someday, hack coders are creative... And often write ugly code!
  5. MiniDigger


    getting access to these heuristics is not hard. I don't own aac so I can't test it but I will bet that java-deobfuscater manages to make the plugin readable enought to locate the heuristics in the code (my route would be: locating the main class using the plugin.yml, locate the listeners and search them) and do stuff with them.
    • Optimistic Optimistic x 1
  6. In regards to the hacked client thing, if someone can code a functional Minecraft client that is automatic and robotic, I doubt it's hard to drobfuscurate (how ever you spell it) a little, compared to a full client, Minecraft plugin
    • Agree Agree x 1
  7. MiniDigger


    drobfuscurate lol.
    writing a client isn't hard. has all the documentation you need, there is a big community that helps you and in most cases you don't write a new client from scratch anyways but just mod the offical client.
    But just because someone can write a client doesn't mean he knows how to deal with obfuscation. they are two different topics that require some practise. But I agree with you that if you are a experienced developer in java (not the typical minecraft plugin dev) then it is not hard to learn.
    • Like Like x 1
    • Optimistic Optimistic x 1
  8. I actually coded a hacked client for 4 month, but I never had to really mess arround with obfuscation (MCP does a lot and what falls behind is called var1, var2, etc). I tried to reverse engineer my own plugin which was really easy since I know my code, I asked a client developer to reverse engineer, that guy failed, he even had made bis own anticheat before...
  9. The thing is in the end the hack will always win.

    Some hacks you can prevent but those hacks are most likely abusing an exploit which would require the exploit to be fixed. In the end the hack client will always beat the anticheat. Especially in minecraft.

    Being able to look at how the anticheat works just gives the hack client creator knowledge of what he can or can't do.. It will give the limit of what is possible.

    The anticheat will also require the most updating as the hack client is the one showing them what is possible.
  10. MiniDigger


    just looked at your code. I have no idea how anti cheats or hacks work (I couldn't care less) but I think if I would know I could understand how your plugin works very easily. The only thing that makes your code hard to read is the dictionary used. java-decompiler currently can't rename classes/methods/variables but I bet there are other tools that can do excatly that.
    Your code is very easy to read because you have strings in it. For example every check you have has a string with his name in it (in the super constructor call) and a permission to bypass. Using these strings you can locate every check and work around that. Your obfuscation is basicly worthless.
    • Agree Agree x 1
    • Optimistic Optimistic x 1
  11. JamesJ


    I don't think you know a lot about anticheats...
    • Funny Funny x 3
    • Agree Agree x 1
  12. MiniDigger


    I know excatly nothing about anticheats, as stated above.
    • Like Like x 1
    • Optimistic Optimistic x 1
  13. If someone decided to keep their anti cheat private, I bet that hack clients developer wont be able to figure out how to bypass that hack detection. So the best way is to keep your code private.
    I do my own obfuscation without an obfuscator too but that just took me much time and it is not worth it to.
  14. A friend of mine wrote a script that took the characters found in a class which used a charset that didn't really work on windows and dumped the right into Javac. Not entirely sure how it worked myself, but yea basically, there is nothing you can do to hide your source. If someone wants to know how you did something they can find out.
  15. I hope this post persuades some developers to stop obfuscating their plugins. Just because your plugin is premium does not mean it has to be obfuscated. Obscurity != security. Honestly, obfuscating plugins has to be one of my least favorite trends in the past ~2 years. It makes it a pain in the ass to debug any non-trivial issue with the plugin, and makes me depend on the plugin author for patches/solutions. What if the plugin author is on a 2 week vacation and there's a bug? If the plugin is important to the server, I'm now forced to work with and patch obfuscated code, despite being a paying customer. It's just stupid.
    • Agree Agree x 5
  16. MiniDigger


    thats exactly the reason why I made this post as soon as I saw the post on obfuscation. But I don't think that it will change anything. People don't understand that a filled github repo can help you get a job. People don't understand the power the open source community can bring to your project.
    If I would be a server owner, I would only use plugins that I have source code access to. The risk, that a plugin breaks and the author does not respond is just to high.
    • Agree Agree x 4
  17. Yeah, I know that string problem, I'm looking foreward to integrate my own string encryption which will make the java-decompiler unusable.
  18. Please, String encryption can be broken within 10 or so minutes.

    The only good protection for plugins, is quality.
    • Agree Agree x 11
    • Winner Winner x 2
  19. IANAL, but I'm pretty certain it's to do with the fact that when you distribute a plugin, you're not distributing spigot... and therefore don't have that licensing issue. Something like that, some smarty pants who likes to read all that law gibberish please correct me :)
    • Agree Agree x 5