I'm wondering what happens if we try to run a jar through Proguard that has already been obfuscated by another obfuscator or Proguard itself? Will the obfuscated class names and methods names be changed by the new obfuscator?

For example, I would like to have those names renamed to something simpler such as a or aab rather than unicode characters. Will another obfuscator change the names?

enter image description here

  • 5
    Why don't you just try it out? Mar 16 '15 at 17:26
  • Proguard is used on Java code, so you'd have to run a JAR through JAD (or similar decompiler) first before you could even attempt this. Assuming nothing fails in this process (which depends on the obfuscator) you could reprocess the decompiled code with proguard, though I'm unsure this would result in the desired "simpler" names.
    – diff
    Mar 19 '15 at 1:25

It's reasonable to assume ProGuard (or any other alike software) cannot tell if a name is deliberately unclear or not. If it could, it would be reversible -- create 'sensible' names for those that it deemed unclear.

(Which would be a useful program. I have seen "plain" code with such bad names that it already looked quite obfuscated. Some of it was my own. My younger self did not think my older self would ever need to understand his code.)

Even if obfuscating 'again' may change the names (again), it will not add an entire new "level of obfuscation".

  • Thanks for pointing that out. I've edited the question to include a specific example. That was basically my question. I would like to achieve the desired effect of changing the class names in the jar to use ASCII rather than UTF-8 chars in the names.
    – Nederealm
    Mar 17 '15 at 3:54

It all depends on what the obfuscator does. Proguard is a relatively weak obfuscator - it basically only renames things and strips out unused methods. So running Proguard on the same application twice is pretty much useless, but it won't cause any ill effects.

If you use a stronger obfuscator however, things will almost certainly break. For example, Allatori and Stringer both encrypt constant strings with a key derived from the class and method name of the caller. At runtime, the string decrpytion function uses various hacks to get the name of the caller and then decrypts the string with that.

If you then run Proguard on the obfuscated application, Proguard will blindly rename the classes, meaning that when the string decryption functions are called, the decryption key will be incorrect and the application will get garbage strings at best or much more likely just crash.

  • Last paragraph assumes reflection is being applied to load classes dynamically?
    – Nederealm
    Mar 17 '15 at 18:14
  • @Nederealm No the reflection is used by the string decryption functions. Presumably it's intended to stop people from decrypting the strings by just calling the functions blindly though it's easily circumvented.
    – Antimony
    Mar 18 '15 at 2:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.