Or just you know open source... people cant leak stuff if its already out there and other devs can improve upon or fork your code there is so many reasons why open source is better so just use it."strong".
Jd GUI crashes now for even normal non obfuscated java 8 (and sometimes even java 7) code, it is just old decompiler made for java 5/6.
And changing all strings to this stuff is not a good idea in some places, as this can decrease performance a lot, and it is still pretty easy to break. Especially if you use reflection-based mode, where it does encrypt string based on line numbers - this can make code just too slow to use on server.
Good obfuscation should make some use of illegal class names, it is then funny how Class.forName(MyClass.class.getName()) throws error as java can't even understand that name.
Some of them are not empty packages too, just weird unicode names that renders just as space or nothing.
(PS: that 2 separate classes needed to be in more valid package as they were used by reflections, I just had a lot of annotations to control classes/method to obfuscate in given way (or remove debug methods that would simplify decompiling) to simplify code development process)
And that would be still pretty easy to crack, but already much harder, as like trying to obfuscate this again in proguard will fail - so it is not that easy to change that illegal names to something that can be imported into IDE. But if someone would want to decompile that - few days would be probably still enough.
(this is AutoIn plugin available on spigot, no longer maintained, also obfuscation was stronger some time ago, but sadly for cauldron support I needed to make it weaker as forge was not able to load that classes)
Obfuscation is only a time barrier, if plugin is shit then you can even put source code on github and still no one would steal it, if it is something more interesting then if anyone would want to crack it - they will. It is just about "do I want to waste x hours to do this".
And I would not also consider my obfuscation as "Strong" one, so your one is just most basic thing.
Also you left eclipse project files that would make decompiling a bit easier too... and preserved packages so it is even easier to later guess original names of everything, anyone would be able to decompile something like this in about a hour.
Change invocation of every method to invokedynamic instructions, and still apply all other obfuscation methods. Then maybe it will be close to something "Strong":
Wow that is very resoursful. I'll change some settings here on my obfuscator to make it stronger."strong".
Jd GUI crashes now for even normal non obfuscated java 8 (and sometimes even java 7) code, it is just old decompiler made for java 5/6.
And changing all strings to this stuff is not a good idea in some places, as this can decrease performance a lot, and it is still pretty easy to break. Especially if you use reflection-based mode, where it does encrypt string based on line numbers - this can make code just too slow to use on server.
Good obfuscation should make some use of illegal class names, it is then funny how Class.forName(MyClass.class.getName()) throws error as java can't even understand that name.
Some of them are not empty packages too, just weird unicode names that renders just as space or nothing.
(PS: that 2 separate classes needed to be in more valid package as they were used by reflections, I just had a lot of annotations to control classes/method to obfuscate in given way (or remove debug methods that would simplify decompiling) to simplify code development process)
And that would be still pretty easy to crack, but already much harder, as like trying to obfuscate this again in proguard will fail - so it is not that easy to change that illegal names to something that can be imported into IDE. But if someone would want to decompile that - few days would be probably still enough.
(this is AutoIn plugin available on spigot, no longer maintained, also obfuscation was stronger some time ago, but sadly for cauldron support I needed to make it weaker as forge was not able to load that classes)
Obfuscation is only a time barrier, if plugin is shit then you can even put source code on github and still no one would steal it, if it is something more interesting then if anyone would want to crack it - they will. It is just about "do I want to waste x hours to do this".
And I would not also consider my obfuscation as "Strong" one, so your one is just most basic thing.
Also you left eclipse project files that would make decompiling a bit easier too... and preserved packages so it is even easier to later guess original names of everything, anyone would be able to decompile something like this in about a hour.
Change invocation of every method to invokedynamic instructions, and still apply all other obfuscation methods. Then maybe it will be close to something "Strong":
There are also so many reasons it's bad. Like for proprietary projects.
why bump this old thread? Anyway, for "proprietary projects" (the correct term is proprietary software but whatever) 99.95% of them are already on sites like that spigot leak site (sure your know what one im talking about) and obfuscating them isn't gonna stop people from re-uploading them... server owners can probably get a good 70-80% of there plugins from these sites and the rest custom but apart from the 10 year old kids most of them don't, they pay for them as they know supporting the developer by buying the plugin means they will continue to update it and provide support. It took me ages to figure out how to pull a plugin from git and compile it myself and im sure 99.999% of people don't know how to so if server owners can get better support continued updates and not waste there time by paying a few bucks they are still going to. The few people who would be scummy enough to compile it aren't either they are just going to go find a reupload of it somewhere.
