super
super copied to clipboard
ProGuard obfuscating - performance
Hi, I've read the documentation about your tool and I have a question: If I have an APK that has some of its code obfuscated by ProGuard, can your tool still make reverse engineering on it? And if it does what can I expect from its performance?
Thanks
Hello!
Unfortunately, nowadays SUPER is not considering obfuscated APKs to be analysed. Detection rules might succeed depending on how ProGuard obfuscate code (partial or complete obfuscation, files involved, etc...). Have you tried to scan the APK yet? If you have so, would you mind to report us which vulnerabilities have been detected? I think all rules regarding to AndroidManifest.xml analysis should succeed.
Thanks for contacting us!
Hi,
I have not had the opportunity to scan an obfuscated file with SUPER. Regarding the tool's performance, should I expect an infinite loop or the affected set of rules will just be ignored?
Thanks, When I scan an obfuscated APK, I will gladly report the results, Patryck
Hi Patryck,
SUPER would not get into an infinite loop for scanning the obfuscating app as no matching rules will be ignored during scanning process.
We are looking forward to know about your results. Best regards!
I should add that even though SUPER shouldn't crash in those cases, it might happen that one of the Java dependencies had trouble. The worst that I think it could happen would be for SUPER to just stop and return an error. If this is the case, we would love to know about it. We are looking into removing all Java dependencies, but until we do, it's best if we can try and fix some of the issues.
It might also happen that some rules detect false positives or negatives, which makes sense given that the code is obfuscated. If you find one of these cases, please, report them, since we might be able to improve the detection.
Hi Sorry for the delay,
Most of the obfuscated APKs that I've analyzed with SUPER had a similiar result:
Starting analysis of com-linkedin-android-108420-37309735-492a36aa3a87dff6873c42401558147d. Application decompressed. Error: Application analysis failed Caused by: Conversion from DEX to JAR failed Caused by: The .dex to .jar conversion command returned an error. More info: dex2jar dist/com-linkedin-android-108420-37309735-492a36aa3a87dff6873c42401558147d/classes.dex -> dist/com-linkedin-android-108420-37309735-492a36aa3a87dff6873c42401558147d/classes.jar
Detail Error Information in File ./classes-error.zip (->There are 140 methods fail to translate.) Please report this file to one of following link if possible (any one). https://sourceforge.net/p/dex2jar/tickets/ https://bitbucket.org/pxb1988/dex2jar/issues https://github.com/pxb1988/dex2jar/issues [no attachment support, not preferred] [email protected]
There were also some Java exceptions, for example:
Starting analysis of com-hermes-superb-booster-235-36664739-3ca39296e42898a3b8d04a98cad5764e. Skipping decompression. Error: Application analysis failed Caused by: Conversion from DEX to JAR failed Caused by: The .dex to .jar conversion command returned an error. More info: dex2jar dist/com-hermes-superb-booster-235-36664739-3ca39296e42898a3b8d04a98cad5764e/classes.dex -> dist/com-hermes-superb-booster-235-36664739-3ca39296e42898a3b8d04a98cad5764e/classes.jar java.nio.file.NoSuchFileException: dist/com-hermes-superb-booster-235-36664739-3ca39296e42898a3b8d04a98cad5764e/classes.dex at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) at java.nio.file.Files.newByteChannel(Files.java:361) at java.nio.file.Files.newByteChannel(Files.java:407) at java.nio.file.Files.readAllBytes(Files.java:3152) at com.googlecode.dex2jar.tools.Dex2jarCmd.doCommandLine(Dex2jarCmd.java:105) at com.googlecode.dex2jar.tools.BaseCmd.doMain(BaseCmd.java:290) at com.googlecode.dex2jar.tools.Dex2jarCmd.main(Dex2jarCmd.java:33)
There was also something that happened, when using SUPER, on an APK where the conversion from DEX to JAR failed and it was caused by the .dex to .jar conversion command returned an error. If I executed the command again this time I would get a json report, but in cli appears something like:
Skipping decompression.
Skipping .jar file generation.
Application decompiled.
Results struct created.
And then all this skipping results in warnings starting with: 'Error analyzing file ....'.
I will post other results, Again sorry for the delay
So, this is clearly an issue with the dex2jar Java dependency. We are working to replace this dependency in the future with a dalvik parser, but for now we depend on their accuracy.
It seems to be a duplicate of #115, and would be solved by fixing #24. In any case, you can try to open an issue in one of the links you posted above, since we cannot really do much about it.
In any case, did you try the latest code in the develop branch? We have fixed some issues decompiling some APKs like the LinkedIn APK you show above. Probably not this one, though.
Well actually those results were not from the latest version. But I am using the latest branch now. I also have reported the dex2jar issues to their team. Since you guys are dependent on their updates I think there is no point in opening an issue.
That is great news. Do you have a link to the issue you opened? We can that way track the progress, and update our dependency if a fix is implemented.
I do not keep track of those links. I am currently working with several static analysis tools that also depend on the dex2jar module, so whenever a classes-error.zip is generated I usually report the issues to their team.