1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Obfuscation - A guide covering all aspects you need to know

Discussion in 'General' started by herby2212, Nov 28, 2017.


What do you think about Obfuscation?

  1. Good

  2. Bad

  3. Depends on the plugin and its purpose

Results are only viewable after voting.
  1. Hey everyone,
    I will talk in this thread about how to obfuscate your plugins and what meaning, benefits it has. I already got some requests, so I decided to make a public thread to it. The idea for this comes from @Lenny :rolleyes:

    So what is obfuscating in general?
    There are several definitions out there, but you can say in general that the following fits well:
    Obfuscation is the act of creating code that deliberately conceal its purpose or logic, by using expressions and code designs that are hard to understand for other humans then the creator, to prevent tampering, reverse engineering, re-publishing or leaking.

    What are the Pro and Con's of Obfuscation regarding plugins?

    • "Protection" of your code
    • Harder to leak or modify by other persons
    • Repellent effect when a unauthorized person see the code, may preventing the person from trying modify the resource
    • Feeling of safety as creator
    • Can improve anti-piracy protection (if integrated into the plugin)
    • Time consuming
    • Inefficient
    • Make working in your code harder
    • Disturb "customers" (Persons who fight for open source, potential leakers/pirates)

    In general it is up to you which of the points mentioned above are more important for you then others. But I recommend to only start obfuscating your plugins if they have a designated range of publicity or contains code, that it very special, or costed a lot of effort to develop.

    A special word for network owners: I recommend that you put your effort and money into reinforcing your network safety and infrastructure, before investing in extra time to obfuscate your plugins. Of course it is up to you at the end, but this just as a tip from money and needed time relation. (If you pay for the plugin development)

    How to obfuscate?
    There are to answers to this question, one quite easy the other one more complex.

    The first one would be to use a program, that obfuscate the code for you. It is easier for you, but also easier to deobfuscate by a other program. Additional it can be that you lose the overview of your plugin though the obfuscation process.

    The second one is to obfuscate your plugin by hand. Yes this will take a lot more time and thinking, but it allows you to develop your own obfuscation methods and structure, which will be a important factor to the efficiency of the plugin and the conceal effect.

    Every developer has his own kind of tricks and methods to obfuscate his plugins, so it is hard to cover them all. So I will tell some of my own methods, that proved to have a good effect:

    • Random/Fake class names: This means that I create a ton of empty fake classes and name them in alphabetic order.
    • Unreadable/Fake packages: Here I use the some tactic as with the classes, by creating a ton of fake packages filled with random classes. Additionally you can use some symbols like $ in the package names, which will prevent some decompilers to see this packages and the classes in it. => Not find able code
    • So it could look later like this:

    This two methods will have the effect that it will take you a lot of time to find even a part of the code, which means that at this point most persons who try to steal your code, will have already surrendered.

    So to conclude this theme, it is like at the topics above a matter of how much time and effort you want to put into it. But I personally out of experience prefer the second method, because it will bring you to deal with your plugin, so you put more time and effort into it. A other good side factor of the second method is that you exactly know how the obfuscation is done and handled.

    Final words:
    Obfuscation is a theme itself, with a lot of depth and possibilities. I covered today just the simple part of it and I hope that this post may helped you finding your own decisions of how and if you want to obfuscate your plugin.

    Also if you have any questions or ideas, that I may missed in this thread, feel free to post them down below ;)

    I also thank you for your attention and for reading this long post until this point.

    Best Regards,
  2. I just signed up to drop this message:
    Ppl often have the question if they should obfuscate their stuff. The answer is almost always: No
    its time consuming, its useless (as the code is still readable or can be made readable with nearly no effort), it can lead to decreased runtime performance, it makes your compiles longer, it makes it harder to debug stack traces you get from customers, its generally shady (why obfuscate when you got nothing to hide -> if you obfuscate you might hide shady stuff).

    If anybody wants to find out how easy it is to make code readable again, check out this post I wrote some time ago (that kinda blew up) https://www.spigotmc.org/threads/tu...cate-a-plugin-using-java-deobfuscator.146248/

    (edit: your spam filter is kinda strange, doesn't let me post an url but let me edit it in :shrug: )
  3. Well, still thanks for your message. You mentioned some cons that I already covered above, but I agree in general that it can make stuff more complicated then it should be.
    But I wouldn't say that it has absolutely something to do with shady stuff. Some people just obfuscate there stuff in general, or do it for example to prevent code stealing or make leaking harder.

    Also the spam filter get disabled after you post 1 message, so then you can input links.
    Works quite well at the moment against all the bot spam.
  4. Oh I totally forgot about Ahead of Time compilation which works well for obfuscation, doesn't cost you any real time and can increase performance in general ;)
    It also doesn't make it harder to debug stack traces as you only compile the finished file for the upload and not your test/work files.

Share This Page