ProGuard Java Optimizer and Obfuscator Activity
Java class file shrinker, optimizer, obfuscator, and preverifier
Brought to you by:
guardsquare
Activity for ProGuard Java Optimizer and Obfuscator
-
ProGuard Java Optimizer and Obfuscator released /v7.1.0-beta5/README.md
-
-
-
-
-
-
-
SIRA_PRISE posted a comment on discussion Open Discussion
Forget it. Was looking at the wrong config file. Sorry !
-
I'm using a very basic configuration : -forceprocessing -verbose -dontshrink -dontoptimize -basedirectory ... -injars TEST/bin/tmpserver.jar -outjars ACPT/bin/sp.server.jar -libraryjars ... ... keepcommands here The injar exists, the outjar doesn't. Even despite the -forceprocessing option, I consistently get "output seems up to date" and outjar doesn't get created. What am I doing wrong ? (Oh yes, I'm working via the Ant task.)
-
doomstone123 posted a comment on discussion Help
Proguard in changing the varaible definiton in interal library don't know why code is breaking because of it. **Before obfuscator** private static final Signature GET_DECLARED_METHODS = TypeUtils.parseSignature("java.lang.reflect.Method[] getDeclaredMethods()"); **After obfuscator** private static final Signature GET_DECLARED_METHODS = TypeUtils.parseSignature("java.lang.reflect.Method");
-
Proguard in changing the varaible definiton in interal library don't know why code is breaking because of it. **Before obfuscator** private static final Signature GET_DECLARED_METHODS = TypeUtils.parseSignature("java.lang.reflect.Method[] getDeclaredMethods()"); **After obfuscator** private static final Signature GET_DECLARED_METHODS = TypeUtils.parseSignature("java.lang.reflect.Method");
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Not sure whether i might be happening because of tryping to dependency inject the interface. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Not sure whether i might be related to proxies in spring. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Not sure why i am getting the below exception. This is happenning during spring application context is getting loaded. Running proguard over the executable jar. Exception in thread "main" java.lang.ExceptionInInitializerError at org.springframework.cglib.proxy.CallbackInfo.<clinit>(CallbackInfo.java:60) at org.springframework.cglib.proxy.Enhancer.setCallbackTypes(Enhancer.java:372) at org.springframework.context.annotation.ConfigurationClassEnhancer.newEnhancer(ConfigurationClassEnhancer.java:128)...
-
Eric Lafortune posted a comment on discussion Open Discussion
You should specify the output jar in the "Input/Output" tab > "Add output..." ProGuard doesn't obfuscate the runtime jar rt.jar, but it does need it as a library jar to process your program jar correctly.
-
You generally can't know for sure. ProGuard by default uses names a, b, c,... for classes, fields and methods, but a developer can specify his or her own dictionaries. In the ProGuard examples, the source file name in a stack trace is set to "SourceFile" and many developers adopt that as well.
-
Odata Dev posted a comment on discussion Open Discussion
Hi, I open ProGuard UI and Added input jar and on the final stage i clicked Process! button. Process is completely successfully. Where i see the converted, obfuscated jar file? location of the obfuscated jar file? 2nd question, can i obfuscate the application jar files alone instead of obfuscating rt.jar java file as well? I have one jar and need to obfuscate it and struggling with the steps. I am using MAC OS. Please kindly advise. Thanks.
-
Disha modified a comment on discussion Help
Could someone help me out with how can I identify using code if a stacktrace is obfuscated using Proguard or not?
-
Could someone help me out with how can I identify using code if a stacktrace is obfuscated using Proguard or not?
-
Krunal Charan posted a comment on ticket #191
Hi, I have been through the same situation, and I tried a patch work on a branch of ProGuard 6.2.2 Branch: https://github.com/ckenny/proguard I have also created a Pull Request, https://github.com/Guardsquare/proguard/pull/31 The update introduced 3 new options, -dontresetmembernaming -dontresetclassnaming -dontresetpackagenaming In brief, these options will opt out the naming map's resetting logic and therefore the result will be all classes / packages will have unique names. (Attached the porguard-base-6.2.2.1.jar...
-
Scott W Palmer posted a comment on ticket #757
The test case I provided in the github report is passing now, but I get the exact same error in my actual application. Some case is still causing this problem.
-
This is not fixed. As of 6.2.2 and 6.3.0beta1 I still get the same error. (Using JDK 13.0.2)
-
This is not fixed. As of 6.2.2 and 6.3.0beta1 I still get the same error.
-
randomname posted a comment on ticket #697
The attachment I included in the original report: "proguardoutput", is a text file that has the configuration at the beginning, and after that (separated with some blank lines and a line of equal signs) comes the log.
-
Ville Oikarinen posted a comment on ticket #22
Ah, I just noticed that the dead code analysis can be redirected to a separate file in the proguard conf, by writing "-printusage file" instead of just "-printusage".
-
Optional further solutions: When generating a dead code analysis, at least print a special line that indicates the start of the actual report. Then it will be easy to filter out lines before that marker line. Print the diagnostic messages to stderr and the actual (dead code) analysis to stdout. This is standard behaviour in many applications and what stderr is meant for. This way it will be even easier to separate diagnostics from the report.
-
T. Neidhart posted a comment on discussion Help
This optimization has been fixed in the sense that write-only instance field where not removed anymore which was clearly a bug. Do you maybe have some weak / soft references to avoid some data from being garbage collected until its really needed? If that is the case you probably should keep these fields explicitly like that: -keepclassmembers,allowshrinking,allowobfuscation class { java.lang.ref.WeakReferences ; java.lang.ref.SoftReference ; } That will disable optimization for fields that have this...
-
Humphrey Clerx posted a comment on discussion Help
Disabling the specific optimization seems to fix the problem. How can I zoom in on which fields are optimized this way, so I can zoom in on the specific classes in our application that are involved? And what did version 6.2.x change, such that somehow write-only fields can get GC'ed away? On Tue, Dec 17, 2019 at 11:01 AM T. Neidhart tn100@users.sourceforge.net wrote: In order to disable this specific optimization you can add -optimizations !field/removal/writeonly if this is not the cause, you could...
-
In order to disable this specific optimization you can add -optimizations !field/removal/writeonly if this is not the cause, you could add a keep rule like that to prevent optimization on the affected classes: -keep,includecode class xxx { *; } where xxx refers to the fully qualified classname.
-
Hello, I will create a ticket, but our application is rather large and it's not easy to pinpoint which exact members get "optimized" in such a way that they are GC'ed away after some time running. Is there any way to prevent these write-only fields to be optimized (i.e. some flag to get back the 6.1.1 behavior)? On Tue, Dec 17, 2019 at 8:16 AM T. Neidhart tn100@users.sourceforge.net wrote: Could you create a ticket at the github project and attach possibly the relevant class files when processed...
-
Could you create a ticket at the github project and attach possibly the relevant class files when processed with 6.1.1 and 6.2.x? We have made some changes wrt write-only fields, I wonder if this might be responsible.
-
After upgrading to ProGuard 6.2.x from 6.1.1 we noticed that some of our applications stopped working correctly after a while. The application runs fine until the first GC (minor and/or major) it seems and then stopped working. It seems that Proguard is optimizing some references/members in such a way that they now become elligible for being cleaned up with GC's. The application runs fine with the same .pro file after being obfuscated/optimized/shrunk with 6.1.1 and doesn't with 6.2.0 and 6.2.2....
-
ok please create a separate ticket for this and include all necessary information to reproduce the issue. This does not seem to be related to versioned classes inside jar files.
-
i-pk-pjers-i posted a comment on ticket #671
Hi, Yes, it includes log4j2.xml - log4j2 does attempt to read the log4j2.xml file which is why it throws a warning/error when trying to read the PatternLayout pattern element. I do have keep class for all of the libraries like disruptor and log4j2. Cheers.
-
I dont know the contents of the jar file that you are willing to obfuscate, does it also include log4j2 itself? Log4j2 uses reflection a lot, it is likely that due to obfuscation some things do not work properly anymore, its suggested to add a rule like this: -keep class org.apache.logging.log4j.* { ; }
-
-
-
Hi, If you're replying to my comment, I posted a picture of my issue, as well as the exact configuration of log4j2.xml as well as my ProGuard configuration. The log4j2.xml seems like it is being read properly, which is why it detects that there is a PatternLayout tag. You can see the log4j2.xml exists in the jar here: https://i.imgur.com/eoRjDLU.png Cheers.
-
Guardsquare committed [838948]
Created ProGuard version 6.2.2.
-
Tagged ProGuard version 6.2.2.
-
-
-
Can you share a small sample illustrating your problem? The obfuscated jar would also be helpful. I also dont know what configuration you are using, maybe the log4j2.xml file gets corrupted during processing or is not correctly included in the output jar.
-
I'm still having issues with this even with 6.2.1. I get this lovely output in my console: https://i.imgur.com/kihYzjY.png 2019-12-07 20:00:51,156 main ERROR PatternLayout contains an invalid element or attribute "pattern" when an obfuscated application attempts to read my log4j2.xml file: https://pastebin.com/C0hQkTMY - even though the logger.error("Yes") still prints to the console, as you can see in the picture I linked - it's missing my custom pattern for date/time. Here is my ProGuard configuration:...
-
I'm still having issues with this even with 6.2.1. I get this lovely output in my console: https://i.imgur.com/kihYzjY.png 2019-12-07 20:00:51,156 main ERROR PatternLayout contains an invalid element or attribute "pattern" when an obfuscated application attempts to read my log4j2.xml file: https://pastebin.com/C0hQkTMY - even though the logger.error("Yes") still prints to the console, as you can see in the picture I linked - it's missing my custom pattern for date/time. Here is my ProGuard configuration:...
-
I'm still having issues with this even with 6.2.1. I get this lovely output in my console: https://i.imgur.com/kihYzjY.png 2019-12-07 20:00:51,156 main ERROR PatternLayout contains an invalid element or attribute "pattern" when an obfuscated application attempts to read my log4j2.xml file: https://pastebin.com/C0hQkTMY - even though the logger.error("Yes") still prints to the console, as you can see in the picture I linked - it's missing my custom pattern for date/time. Here is my ProGuard configuration:...
-
Created ProGuard version 6.2.1.
-
Tagged ProGuard version 6.2.1.
-
-
-
The problem with filenames containing utf-8 characters could be reproduced. This is because the general purpose flag ist not properly setup and also the version made by has to be adapted to properly support that, see: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
-
-
-
can't find referenced field java.lang.Boolean default
-
Invalid LocalVariableTable when -dontobfuscate flag is used
-
Tested the sample with ProGuard 6.0.3 and the problem is fixed.
-
ClassFormatError
-
Tested both samples with 6.2.0 and they are correctly processed / executed after obfuscation.
-
Kotlin: can't find enclosing method with private interface method
-
This is not a bug. ProGuard reports that the enclosing method information contained in the class generated by the kotlin compiler is not valid. In general such warnings could be ignored. I tested the sample with a more recent kotlin compiler (1.3.31) and the warning is not printed anymore.
-
java.lang.NoClassDefFoundError
-
DexGuard related question, handled separately.
-
Error instead Warning due to duplicate zip entry
-
Unsupported stack size increment
-
Tested with latest release 6.2.0 and its works fine.
-
AbstractMethodError with -allowaccessmodification
-
Tested the sample also with the latest version 6.2.0 and it works fine.
-
Obfuscation of multiple jars leading to invalid code
-
When using multiple output jars, there is no way to control that only classes belonging to the same input / output jar should be merged together. There is also no intention to support that in the near future, disabling class merging as suggested is the best option.
-
Can't update system properties when running Gradle daemon.
-
There are no plans to make these properties non-static.
-
Main method is removed when it shouldn't be
-
The contents of the main method will still be optimized, even when you specify a keep rule for it. What is prevented are structural optimizations like method inlining, but I guess you dont want that anyways. To completely disable optimization for the main method you can use a rule like that: -keep,includecode class xxx { static void main(...); } That will disable all instruction-level optimizations as well.
-
Support for processing multi-version jars would require a lot of work. The next release 6.2.1 has default filters to exclude META-INF/versions/** by default, to prevent errors. The best option is to use jars that contain the version of the classes that you want to use and process that with ProGuard.
-
Proguard corrupts stack map frames
-
Problem fixed in 6.0.3
-
java.lang.ClassFormatError: LVTT entry for 'elements' in class file org/jf/dexlib2/writer/InstructionWriter does not match any LVT entry
-
No further details have been added, impossible to reproduce.
-
[6.0.1] Multiple "classes" directories when using Gradle plugin
-
Fixed in ProGuard 6.0.3.
-
String[] out of bounds
-
No more input, closing for now.
-
Would you be able to share the configuration with us for inspection?
-
Proguard not copying module-info.class file to output jar.
-
module-info classes have to be explicitly kept. With ProGuard 6.0.3 there was an issue as it was not able to properly process such classes as they contain new constants. This has been fixed in issue 712, ProGuard 6.2.0 should work fine.
-
VerifyError: Bad access to protected data in getfield
-
Thanks for the report and sample project. I verified that the sample runs fine when using ProGuard 6.2.0.
-
A used method removed for Kotlin coroutine after proguard
-
Problem with ClassCastException is fixed since ProGuard 6.2.0. The sample still have some NullPointerException but that also happens when not using ProGuard at all, so its unrelated. Closing this issue as already fixed.
-
Java.lang verifyError
-
Without more details its impossible to figure out what is going wrong. The most likely explanation is that you use -dontpreverify when processing the jar which will omit mandatory stackmap frames.
-
Problem only happens when using conservative optimization. In this case surprisingly more code is removed resulting in a case where a return instruction is removed after a branch instruction leading to the follow up error.
-
inner class with generic in constructor parameter causes crash
-
This problem should be fixed in release 6.2.0.
-
DexGuard uses a ShufflingNameFactory as wrapper to add more entropy between different runs (if there are slight changes).
-
Support class version 51.0 (jdk7)
1 >
