Obfuscate the plugin

We recommend obfuscating your paid plugin before uploading it to JetBrains Marketplace. Every application can be hacked, but proper obfuscation makes doing so much harder.

Here are some of the most popular Java obfuscators:

ProGuard
JODE
JavaGuard
RetroGuard
jarg
yGuard
ALLATORI
DashO
Zelix KlassMaster

Zelix Klassmaster

At JetBrains, we have a lot of experience with Zelix Klassmaster, so we are sharing some information about how to configure it. Information about Zelix configuration and tips for regarding the features is provided by Eugene Zhuravlev, the IntelliJ IDEA developer who implemented the licensing mechanism and JetBrains Marketplace support in IntelliJ IDEA.

You can find the full documentation here, and we have been using the script file (not the UI tool.)

This is the configuration for the obfuscator we use for IntelliJ IDEA based products:

trim deleteSourceFileAttributes=false
        deleteDeprecatedAttributes=false
        deleteAnnotationAttributes=false
        deleteExceptionAttributes=false
        deleteDebugExtensionAttributes=true
        deleteUnknownAttributes=false
        ;

        obfuscate
        changeLogFileOut="ChangeLog.txt"
        keepInnerClassInfo=ifNameNotObfuscated // should be true to allow use of OpenAPI inner classes
        keepGenericsInfo=true
        aggressiveMethodRenaming=true
        obfuscateFlow=aggressive
        exceptionObfuscation=heavy
        encryptStringLiterals=enhanced
        legalIdentifiers=true
        lineNumbers=keep
        hideFieldNames=false
        hideStaticMethodNames=false
        randomize=true
        methodParameters=keepVisibleIfNotObfuscated
        localVariables=keepMethodParametersIfNotObfuscated
        methodParameterChanges=flowObfuscate
        obfuscateReferences=normal
        ;

And these are the most important features:

trim removes unused fields, methods, and classes. It’s a useful feature, but you should use it carefully. Normally we limit the scope to the licensing packages only. For example, static final constants are normally inlined by the compiler, but the fields and their values are preserved in the code. It might give additional "hints" to those analyzing the bytecode of your plugin.

obfuscateFlow=aggressive can tangle the control flow in the method, which complicates the addition of hacking code.

encryptStringLiterals=enhanced is very important. It encrypts the string literals, which also masks reflection calls, hardcoded signatures, and certificates.

methodParameterChanges=flowObfuscate is an additional protection level that complicates the decryption of scrambled string literals. It creates additional dependencies and connections between classes, which results in protection against getting classes from IntelliJ IDEA Community Edition (open source) and putting it in IntelliJ IDEA Ultimate Edition, expecting them to work.

obfuscateReferences=normal is important to configure for some packages and classes. If you are calling a method of an object from some package, let's say javax.security.*, the obfuscator will mask this call changing it to the reflection with the encrypted name of the method. With this feature, you are hiding the places where some important libraries are called, and without this feature, it would be very easy to locate these pieces of code via links to the libraries.

We certainly recommend reading the full documentation to understand how obfuscation works. We believe that the plugins can use more aggressive obfuscation/scrambling than we do in IntelliJ IDEA, as we have a lot of APIs that we have to preserve on our side. Don't be shy about scrambling the code – it increases the protection a lot.

ProGuard

We have tried getting the same result with ProGuard (as it's free), and one of the major drawbacks was the lack of String Obfuscation support (Zelix option encryptStringLiterals=enhanced). Some users complement ProGuard with an additional paid string obfuscator (e.g.https://jfxstore.com/stringer/), see this article

By default, ProGuard can shrink, optimize, obfuscate, and preverify, and all four options are recommended.

We would also recommend using -overloadaggressively for more aggressive obfuscation and -applymapping ChangeLog.txt to keep a log of changes. You can learn about more options here.

Other

Similar features surely exist in other Java obfuscators, including free/open-source ones.

As of now, we haven’t been able to find any Kotlin obfuscators or Java obfuscators with Kotlin support, so we can't recommend much here. We are looking into the situation, and we’ve started working with the Kotlin team to make sure that support for Kotlin is provided on the obfuscator’s side.

Last modified: 11 September 2023