String encryption

Why it matters

Compiled Java keeps every string literal in the clear inside the constant pool. A license message, an API endpoint, a permission node, an error string — all of it is one strings command away, and each one is a signpost to the code around it. Encrypting them doesn't just hide the text; it removes the map an attacker uses to navigate.

You turn it on with a single field in techniques:

{ "techniques": { "stringEncryption": "POOL" } }

Every example below is real engine output — one small method, encrypted with each mode, then decompiled back to Java with a standard decompiler so you can see exactly what ships. The original:

public String tier(int n) {
    if (n >= 500) {
        return "gold";
    }
    return "standard";
}

The four modes

stringEncryption takes one of four values. They differ in where the encrypted data and the decrypt routine live — which is what changes how hard it is to hook or lift:

All three encrypted modes share one property: the key is derived from the runtime caller(see callerBinding), so copying an encrypted string and its call into a different class makes it decrypt to garbage. There is no single "decrypt everything" routine to run.

PER_METHOD

The literal disappears; in its place is a call to a generated decrypt method (Sample.ahere) that takes the ciphertext and per-string parameters. The readable text is gone from the constant pool — what remains is an opaque payload of characters, shown here as \uXXXX escapes. Use theshow characters toggle on the block to flip between the escapes and the raw glyphs:

public String tier(int n) {
    if (n >= 500) {
        return "gold";
    }
    return "standard";
}

public String tier(int n) {
    if (n >= 500) {
        return Sample.a("_", "\u23e4\u23e5\u23fd\u23fc", 9, 2, 6);
    }
    return Sample.a("_", "\u2300\u230d\u2306\u2303\u233f\u2320\u233d\u2351", 10, 6, 29);
}

INLINE

No helper method at all: the decryption — a per-string XOR schedule over the ciphertext — is written straight into the method, so there's no shared routine to hook and every use site looks different. The plain strings "gold" and "standard" are nowhere to be found:

public String tier(int n) {
    if (n >= 500) {
        return "gold";
    }
    return "standard";
}

public String tier(int n) {
    if (n >= 500) {
        char[] cArray = "\u2787\u2785\u2799\u279b".toCharArray();
        int n2 = cArray.length * 29;
        for (int i = 0; i < cArray.length; ++i) {
            int n3 = i;
            cArray[n3] = (char)(cArray[n3] ^ (18208 + 1653 ^ 0x6A01 ^ i * 10 ^ i >> 1 ^ n2));
        }
        return new String(cArray);
    }
    char[] cArray = "\u2ba8\u2ba7\u2baa\u2bad\u2b9f\u2b92\u2b99\u2b87".toCharArray();
    int n4 = cArray.length * 26;
    for (int i = 0; i < cArray.length; ++i) {
        int n5 = i;
        cArray[n5] = (char)(cArray[n5] ^ (12523 + 9927 ^ 0x7CB9 ^ i * 8 ^ i >> 6 ^ n4));
    }
    return new String(cArray);
}

POOL

The strongest for footprint and separation: literals are lifted out of your class entirely into a shared pool class (ab here) and fetched by index. Your method keeps no string data at all — just an accessor call:

public String tier(int n) {
    if (n >= 500) {
        return "gold";
    }
    return "standard";
}

public String tier(int n) {
    if (n >= 500) {
        return ab.ba("x", 0);
    }
    return ab.aa("x", 0);
}

It works through concatenations too — here a greeting built from two literals and a variable. The literals become two pool lookups, and only the variable you passed in survives:

public String welcome(String string) {
    String string2 = string;
    return (String)((Object)ab.aa("x", 2)) + string2 + (String)((Object)ab.ab("x", 2));
}

Options

Sensible defaults cover almost everyone; these fine-tune how the decryptor behaves: