Activity for Eric Lafortune
-
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.
-
You should not just specify the class, but also its methods. The following should work: -keep,allowshrinking class com.myPackage.JVMSpecificCode { *; }
-
Thank you for your contribution. The original behavior was of course intentional: the input must be clean to avoid ambiguities. With your proposed change, class files are written with their fully quailified internal names . This also applies to the more common problem case where the input has unexpected directory prefixes; e.g. WEB-INF/classes/com/test/Data.class would become com/test/Data.class . I don't think this is desirable. We'll have to discuss this internally. Our upcoming renaming functionality...
-
A misjudgment exception occurs while preverifying
-
Thank you for your extensive research. This error typically occurs if ProGuard doesn't have the complete class hierarchy of all classes that are processed. Have you suppressed any warnings with -dontwarn or -ignorewarnings? Can you run ProGuard without these settings? If you get warnings about missing classes, can you add their jars to the input? See https://www.guardsquare.com/en/products/proguard/manual/troubleshooting#superclass
-
ProGuard doesn't support any features that are in the preview format, but not in the final format. At this time, ProGuard works fine with for example java version "13" 2019-09-17 Java(TM) SE Runtime Environment (build 13+33) Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing) We'll support any features that make in into Java 14...
-
support Java 13
-
ProGuard supports Java 13, but you should update your compiler from the beta release of Java 13 to the official release.
-
6.1.1 GUI does not save/use dictionary files entered - "no such file or directory"
-
Thanks for your report. The text fields for the obfuscation dictionaries have been fixed for the upcoming ProGuard 6.2.
-
IllegalAccessError with GSON optimizations on final fields
-
Thanks for your report and sorry about the delay. It sounds like a straightforward issue -- we're looking at it.
-
Backport not fixing “Predicate” in method call parameter
-
Proguard doesn't import shrink - keep libraries
-
This bug has now been fixed for the upcoming ProGuard 6.2.
-
Since processing the class files inevitably invalidates the signatures, a first step would be to remove them, for example by filtering them out: -injars bcprov-jdk15.jar(!META-INF/BCKEY.*) Depending on the way the code is used, there may be further mechanisms that enforce the presence of signatures -- you should check.
-
NPE calling proguard 6.1.0beta2
-
If you want to use the processed jar as a library, you have to keep its public API: -keep public class * { public protected *; } (see the ProGuard manual > Examples > A typical library) Do you have a different use case? The Java compiler creates two versions of these methods: one with Object and one with the actual type for T.
-
Library interface with generics fails
-
Thanks for your report and test project. The behavior looks correct to me -- how does the problem manifest itself? The name of program class MyPojo is obfuscated to c, and all code is adapted consistently. If you want to prerserve its name (for some external reason), you can specify -keep class MyPojo.
-
obfuscated class name does not have consistent capitalization
-
ProGuard consistently distinguishes between similar mixed-case class names (they're just different strings after all), but your file system probably doesn't. Somewhere in your build process, the files must have been unpacked from their jars, with the similarly named files overwriting one another.
-
ProGuard is generic for all types of Java: JSE, JME, Android,...., in all their versions. You therefore need to explicitly specify the appropriate runtime. With older versions of Java SE, this was simply rt.jar. With the new modularized Java, this is a collection of jmod files. Admittedly, it's inconvenient to figure out the required ones. There are tools that print out the dependencies for you (jdeps --list-deps). We may make it more convenient in the future.
-
Non-ascii characters in filenames get broken in obfuscated JAR
-
ProGuard (through the ZipOutput class) uses the character encoding set in Java. You should specify it with e.g. -Dfile.encoding=... so it corresponds to your system's character encoding (or the encoding the tools expect). The default in Java should be your system's character encoding, so maybe it is changed in some configuration.
-
Proguard does not find basic packages and super class
-
With -dontwarn you can indeed trigger the problem that you see, because part of the class hierarchy is missing in the preverification step. Due to the modularization of the java runtime, you need to explicitly specify the relevant jmod files with -libraryjars, e.g. jmods/java.desktop.jmod, in addition to jmods/java.base.jmod.
-
invokedynamic symbolic method reference seems to be not renamed when obfuscating
-
Thanks for your detailed report, and sorry about the delay. I could reproduce the problem with your example. We've fixed the issue for the upcoming ProGuard 6.2 (patch attached).
-
[6.1.0] Method must be overridden in [proguard.optimize.evaluation.SimpleEnumUseChecker] if ever called
-
Thanks for your report. We've now fixed this bug for the upcoming ProGuard 6.1.1.
-
A used method removed for Kotlin coroutine after proguard
-
Thanks for your report. Can you attach your sample project? It seems to be missing at this time.
-
inner class with generic in constructor parameter causes crash
-
inner class with generic in constructor parameter causes crash
-
Thanks for your report. I can't reproduce the issue yet. It seems to be related to ProGuard optimizing the code and removing unused parameters in the constructor. Could you provide (post or mail) a small project that allows us to reproduce and then fix the issue?
-
"Inconsistent stackmap frames at branch target" in funky constructor
-
Thanks for your detailed report. It turns out to be an edge case for the Java bytecode verifier. We've now fixed it for the upcoming ProGuard 6.1.1.
-
The GUI will be fixed, but for the time being, you can ignore the check box. Instead, you can select the entry in the bottom panel and edit it whenever necessary. The resulting configuration file is the relevant reference, and it seems to be okay. Does that make sense?
-
If I'm not mistaken, the gradle code relies on Java 8 libraries, so we've compiled the entire code base with Java 8. We try to go back as far as reasonably possible, but Oracle and the rest of the world are pushing forward. Adapting the target and building ProGuard yourself (with make, bash, gradle, or ant) should be straightforward.
-
ProGuard 6.1.0 still doesn't support multi-release classes. You still need to filter them out of your input jars and library jars. If you add log4j as a library jar, you can add its original jar to the obfuscated application (because it is not processed and included in the output). Hopefully, the presence of the different class versions then avoids this warning.
-
What kind of obfuscation were you not seeing and how are you checking it? Web apps are notoriously difficult to obfuscate, since they rely a lot on reflection. In any case, ProGuard performs basic name obfuscation. Notably, it does not: Insert random code. Remove toString methods. Encrypt strings. The optimization step can remove logging calls, with the proper configuration (-assumenosideffects).
-
What kind of obfuscation were you not seeing and how are you checking it? Web apps are notoriously difficult to obfuscate, since they rely a lot on reflection. In any case, ProGuard performs basic name obfuscation. Notably, it does not: Insert random code. Remove toString methods. * Encrypt strings. The optimization step can remove logging calls, with the proper configuration (-assumenosideffects).
-
Proguard doesn't import shrink - keep libraries
-
Thanks for your report. It appears that, since ProGuard 6.0, configured class names aren't filled out in the text fields for boilerplate options like "Libraries". Instead, the options appear as custom options in the bottom panel. This doesn't introduce any major issues, but it isn't the intention.
-
After a long time of development and testing, we're pleased to announce the official release of ProGuard 6.1.0. This version offers bug fixes and some nice new features: Added support for Java 10, 11 and 12. ProGuard now processes the new constructs for nest access and dynamic constants. Backporting code that uses the Java 8 stream API and time API. You could already use ProGuard to backport your Java 8 code. You can now let it automagically convert calls to these Java 8 APIs, by adding the net.sourceforge.streamsupport...
-
PgoGuard still compiles with Java 7, but the default binaries are compiled for Java 8. You can adapt the target in the build files and recompile ProGuard yourself if necessary.
-
Class merging causes invalid class file
-
We've now fixed the bug for the upcoming ProGuard 6.1.0 (beta3).
-
Thanks for your report. The annotation looks strange indeed, but I can't see how it got there. It would help if you could mail me the original class file and the obfuscated class file (you can use proguard at guardsquare com).
-
Stack size becomes negative after instruction [18] invokestatic #29 in xxx
-
We've now fixed the bug for the upcoming ProGuard 6.1.0 (beta3).
-
Great find, thanks! I had checked and double-checked the list badly, This is the sort of bugs where extra pairs of eyes are so useful.
-
Stack size becomes negative after instruction [18] invokestatic #29 in xxx
-
Thanks for your detailed report and analysis! We can reproduce the problem. It's a bug in the EvaluationShrinker indeed. The exception argument in the invocation e(e, "IOException") is unused, but the code doesn't pop it properly from the stack (popping both arguments instead). We don't have a fix yet, but we're working on it.
-
Missing logLoadLibrary method in the ConfigurationLogger class
-
Thanks for your report. This is an error indeed; the lines below // Resource files. (which refer to logLoadLibrary) are not necessary and can be removed. We've now fixed it for the upcoming ProGuard 6.1.0 beta3.
-
Java.lang verifyError
-
I can't seem to reproduce the problem, working from the code that you provide. Do you perhaps have the option -dontpreverify in your configuration? Can you share a small project that illustrates the problem?
-
ConstantPoolSorter.visitProgramClass: "Comparison method violates its general contract" (6.1.0beta2)
-
ProGuard reads and writes class files inside jar files inside war files inside ear files inside zip files, but not class files inside jar files inside jar files. Could that be the reason? In that case, you need to unpack the outermost jar files.
-
Can you try ProGuard 6.1 (curently beta2)?
-
The bug has now been fixed for the upcoming ProGuard 6.1 beta3. You could already try the attached patch.
-
Thanks for your report. This seems to be the same problem as the recently reported bug #745. Do you also have a statically initialized array of floats or doubles, where one of the elements is an unusual value like NaN, +Inf, or -Inf? Otherwise, can you share a small sample that reproduces the problem?
-
Thanks for your report. I can see a bug that could be triggered by code with a statically initialized array of floats or doubles, where one of the elements is an unusual value like NaN, +Inf, or -Inf. I'll start by fixing that.
-
You should remove all the parentheses: as mentioned in the manual, regular expressions must not contain any capturing groups. If ever necessary, use non-capturing groups instead: (?:...)
-
Logs can have many different shapes and forms. You can compose a regular expression to parse your logs (line by line), amd pass it to retrace with the option -regex. A regular expression can contain wildcards for class names, method names, etc. -- cfr. the manual.
-
MyEnum::valueOf method reference causes crash
-
Thanks for your report and for the helpful sample project. The problem has now been fixed for the upcoming ProGuard 6.1 beta3. For the time being, you can work around it by disabling the optimization of simple enum types: -optimizations !class/unboxing/enum or by keeping this enum type from being optimized: -keep,allowshrinking,allowobfuscation enum com.example.proguardtest.MyEnum
-
ProGuard runs after the compilation, so filtering at that point should be okay.
-
ProGuard doesn't handle classes that are packaged in directories that don't exactly match their package names. In this case, the prefix META-INF/versions/9 is causing problems. ProGuard also doesn't handle multi-version class files. The only solution at this time is to remove these classes from the input: -injars in.jar(!META-INF/versions/**)
-
Thanks for your report. This turns out to be a duplicate of bug #740 (which also contains a patch).
-
Thanks for your detailed report. Incremental obfuscation is a tricky problem that doesn't always have a solution. The current implementation mostly tries to solve the problem of obfuscating a code base that has changed slightly, preserving the original obfuscation mapping. This is a different use case, with an obfuscated library that is integrated in a new context. Omitting -useuniqueclassmembernames in the second obfuscation step may help. I've changed the implementation slightly for the upcoming...
-
You can find a sample configuration in examples/standalone/applications.pro. Notably, it shows the differences for the new runtime modules compared to the old rt.jar.
-
System.exit is the official way to end a stand-alone tool, so it can properly provide a return code -- I can't change that.
-
The beta source code isn't in the mercurial repository, but you can find it in the ProGuard download (src directories inside proguard6.1.0beta2.zip or tar.gz) and in the source code artefacts on Maven Central and JCenter.
-
You can currently find the documentation in docs/index,html > Manual > Gradle Plugin, considering that it is mostly useful for Android developers, although it is more general.
-
Java 11: IllegalArgumentException: Can't remap constant index [63]
-
Thanks. I can now reproduce the issue. It has been fixed for the upcoming ProGuard 6.1.0 beta3. I'm attaching the patch.
-
Error after adding Kotlin to existing Android app
-
With the gradle option --info --stacktrace, you should get more information about the crash. That may not be sufficient though. Do you have a small sample project that reproduces the issue?
-
ProGuard 6.1.0 beta2 (available now) has been compiled for Java 1.8 again. Recent JDKs seem to be pushing for higher versions.
-
ProGuard 6.1.0 beta2 (available now) supports Java 10, 11 and 12.
-
Compatiblity with Java 12
-
ProGuard 6.1.0 beta2 (available now) supports Java 12.
-
Following up on the first beta, ProGuard 6.1.0 beta2 is available. This beta version notably adds: Support for Java 10, 11 and 12. ProGuard now parses the corresponding class file versions and handles new features like nest-based access control and dynamic constants. ProGuard 6.1.0 beta1 already contained bug fixes and some nice new features: Backporting code that uses the Java 8 stream API and time API. You could already use ProGuard to backport your Java 8 code. You can now let it automagically...
-
ConstantParameterFilter doesn't account for 'this' parameter
-
Thanks for the fix. It only seemed to affect the statistics, but it was wrong indeed. I've corrected all similar code on the official branch, which will be available in the upcoming ProGuard 6.1 beta2.
-
Proguard corrupts RuntimeInvisibleParameterAnnotations/RuntimeVisibleParameterAnnotations
-
The problem has now been fixed for the upcoming ProGuard 6.1.0 beta2.
-
Proguard corrupts RuntimeInvisibleParameterAnnotations/RuntimeVisibleParameterAnnotations
-
The problem is caused by JVM correlating the annotations with the method's signature attribute, instead of the method descriptor. This is a long-standing unresolved issue in the JDK, eg. JDK-8024694 and JDK-8062582. We'll see if we can avoid it.
-
Proguard corrupts RuntimeInvisibleParameterAnnotations/RuntimeVisibleParameterAnnotations
-
Oops, I see your example now. We'll investigate.
-
Proguard 6.1 beta fails to run under JDK8/9
-
Thanks, this was indeed a configuration error when building 6.1.0 beta1. ProGuard 6.1.0 beta2 will run on JDK 1.7 and higher. For the time being, you can quite easily build ProGuard yourself for an older JDK, with one of the build scripts.
-
Proguard corrupts RuntimeInvisibleParameterAnnotations/RuntimeVisibleParameterAnnotations
-
Thanks for your detailed report. I can reproduce the output. It appears that javap helpfully prints out its own interpretation of the RuntimeInvisibleParameterAnnotations attribute. Based on the preceding Signature attribute it prints out that Foo is an annotation for parameter #0, although the bytecode does specify that it is an annotation for parameter #2. With ProGuard's raw bytecode dump (-dontshrink -dontoptimize -dontobfuscate -dontpreverify -dump), you can see essentially the same bytecode...
-
Proguard occasionally breaks guava Function.apply java8 bytecode
1 >