Proguard and com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian - android

play-services-base-16.0.1.aar (mvnrepository) has proguard.txt with following content:
# b/35135904 Ensure that proguard will not strip the mResultGuardian.
-keepclassmembers class com.google.android.gms.common.api.internal.BasePendingResult {
com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian mResultGuardian;
}
But you can see in classes.jar that type of mResultGuardian is already obfuscated to BasePendingResult.zaa. I guess that is why I get
Note: the configuration refers to the unknown class 'com.google.android.gms.common.api.internal.BasePendingResult$ReleasableResultGuardian'
How that's supposed to work? I'm new to Proguard and only have very basic understanding of what is going on so please make your answers simple :)
Project details:
gradlew version: 5.4
build plugin: com.android.tools.build:gradle:3.2.0
Unfortunatelly I can't update gradle build plugin to 3.3.* or 3.4.* right now because some of the scripts are incompatible and would require significant refactoring.
app/proguard.txt (from recommendations I've seen):
-keep class com.google.android.gms.analytics.** { *; }
-keep class com.google.android.gms.gcm.** { *; }
-dontwarn com.google.android.gms.**
But that doesn't help.
UPD
I end up upgrading to com.android.tools.build:gradle:3.4.1 (some api changes had to be adapted) which fixed the issue but I still don't get how that's supposed to work with rules like that.

“If the proguard set up in your project it does some jobs for us in the built process : Minification, obfuscation, repackaging and optimisation. Enabling it is straightforward if you’re using gradle, just set minifyEnabled to true for your release buildType in build.gradle and pass the default set of android optimisation rules.
This will help to shrink, speed up and protect your app. However it mainly works by removing code that is never called and renaming what’s left. This is all well and good until you encounter reflection.
Reflection lets you write code that can look up and execute other code based on its name (among other things)”
“You can also use ProGuard if you or any of the libraries in your app use reflection, here you specify rules as to which classes, methods and other parts of your app ProGuard should leave alone. You can list all these rules in a file and pass them to ProGuard via the proguardFiles method back in your build.gradle. The general convention is for this file to be called proguard-rules.pro”
These doc1, doc2 provide you more information on how to work with rules

Related

Avoid decompiling android APK [duplicate]

I'm creating an app for android and ios, and i already know that it's theoretically possible to decompile an android app. The app contains sensitive information that i don't want users to have access to as the app interfaces with a webserver. If a user gained access to some information available in the source code, they could potentially spam my web server with requests.
Is there any way to authenticate a connection between the app and the server, assuming that the source code is accessible, or is there any way to obfuscate my code to prevent a malicious user from spamming my webserver.
Thankss
[UPDATE]
**
When you build your application using Android gradle plugin version > 3.4.0, the plugin chooses R8 to optimize and obfuscate the code. The rules can now be configured on proguard-rules.pro or proguard-app.conf files. the rules to indicate what to exclude from the obfuscation are similar to the ones in proguard.cfg used earlier.
You can import your proguard files in your build.gradle like
buildTypes{
...
release{
proguardFiles getDefaultProguardFile(
'proguard-android-optimize.txt'),
'proguard-rules.pro'
}
}
R8 picks up all the existing proguard rules files as long as they're included in the build.gradle. You can also configure what pieces to obfuscate for different product flavors that you may have.
**
[OLD BUT RELEVANT INFO]
Proguard is a tool that will help you obfusate your code. This comes as part of your android tools and you just need to activate it. This link and this will help further.
Proguard's default configuration (in proguard.cfg) will be enough to sufficiently obfuscate your code. However you might want to tweak your proguard configuration when you have methods/classes that are being dynamically accessed.
For instance, accessing classes/methods with Reflection will need you to have the code to be intact. You might sometimes experience ClassNotFoundException if proguard obfuscates it.
If you have classes that are being accessed in the AndroidManifest/ Layout Files, you should prevent proguard from obfuscating them.
This can be done by adding
-keep public class <MyPackage.MyClass>
to your proguard.cfg.
**
While Proguard makes static analysis harder, DexGuard protects from both static and dynamic analysis. DexGuard is specifially for android applications and is only commercially available while Proguard is open source and is for any java bytecode obfuscation / optimization.
You cannot prevent decompiling android apk, you can just increase the difficulty of decompilation, proguard is the best option.
DexGuard provides even better security then ProGuard but it is NOT free: https://www.saikoa.com/dexguard
DexGuard can even obfuscate String constants.

How Do I Teach ProGuard to Get Rid of Something It Is Keeping That I Am Not Using?

I have an Android project with a proguard-rules.pro file for the app module that contains only the following:
# ProGuard rules
-dontobfuscate
-dontwarn android.arch.util.paging.CountedDataSource
-dontwarn android.arch.persistence.room.paging.LimitOffsetDataSource
I am not keeping anything myself. All -keep rules are coming from something else, whether that is the rules provided by getDefaultProguardFile('proguard-android-optimize.txt') or from rules packaged in libraries.
However, stuff is being kept that I am not using. If I use the Android Studio APK Analyzer on my release build, while lots of things are removed by ProGuard, lots of other things are kept that I am not referencing.
For example: through transitive dependencies, I have the Support Library module that contains ViewPager in the app's dependencies tree. However, I am not (presently) using ViewPager in this app. Despite this, something is causing it to be kept, as the APK Analyzer shows 107 defined methods for android.support.v4.view.ViewPager, including its constructor.
I could use various ProGuard options to track down why this is being kept. However, it is not coming from my rules. There is no -keep of my own that needs fixing — the -keep is coming from somebody else, presumably a Google engineer.
So, how do I get rid of ViewPager? Is there a way that I can override the -keep rule that is causing it to be kept (e.g., using allowshrinking)? If so, how does ProGuard, as invoked by Android Studio, determine whose -keep rule wins?
The ViewPager class isn't kept in a small app that I just checked, so it must be other code or other rules in your project indeed.
You can start with letting ProGuard print out the chain that triggers ViewPager to be kept:
-whyareyoukeeping class android.support.v4.view.ViewPager
You may need to repeat this a number of times for various classes and methods to get to the root cause. ProGuard doesn't print out which rule exactly is responsible -- admittedly, this would be a useful feature.
You can then look for the proguard.txt file in build/intermediates/exploded-aar that contains a matching rule.
As for a solution at that point:
It is not possible to override -keep rules; they only accumulate.
As far as I know, the Android Gradle plugin also doesn't support disabling overly conservative proguard.txt files in libraries, so you'd need to create a custom .aar file with the updated rule, or send a suggestion to the developers of the library.

Cordova android 5.1.1 APK obfuscation with proguard confusion

With tools like dex2jar and jdgui2 it is very easy to inspect the contents of the APK.
We are trying to use Proguard in our Cordova project to "protect" a few classes that contain information we want to keep secret (Mainly keys to decrypt some content we try to protect for our client).
We cannot get it right. The app crashes, or it isn't obfuscated.
We added to our build.gradle :
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
Our proguard.pro contains:
-keep class !com.smartmobilesoftware.** ( *; }
smartmobilesoftware is an inAppPurchases plugin.
In that package we modified a few classes, which works great without proguard.
I found the following "Proguard support missing": https://issues.apache.org/jira/browse/CB-9269
Here Joe Bowser claims the following: "OK, you shouldn't use ProGuard with Cordova, or at least, there's no good reason to use it, since you can't use it with minifyEnabled, which is what actually makes ProGuard work properly. Since Cordova uses Reflection all over the place, this is a good way to blow up Cordova without a proguard-rules.pro file."
We tried to avoid that issue by telling proguard that ALL classes should be left intact except the ones in the com.smartmobilesoftware (-keep class !com.smartmobilesoftware.** ( *; })
I am not sure if this is a problem witih our code (but the code works fine without proguard), the plugin, or proguard itself.
We do not see any meaningful errors.
We released apps before built with Cordova 2.2.0, which used ANT and proguard and another plugin, which worked fine. So we wonder if Cordove is changed in respect to proguard.
Can anybody maybe shed some light on this issue?
It looks like the code in package com.smartmobilesoftware implements a Cordova plugin. In this case you need to keep at least a few more classes, otherwise Cordova will not properly find them at runtime (for a recent Cordova release):
-keep class * extends org.apache.cordova.CordovaPlugin
Cordova application will crash after obfuscation because of the main activity and cordova classes will get obfuscate. So at runtime failed to create the webview and application will crash.
To resolve this you have to add :
-keep class org.apache.cordova.** {
*;
}
-keep public class * extends org.apache.cordova.CordovaPlugin
There's a nice cordova plugin for this nowadays
https://github.com/greybax/cordova-plugin-proguard
This worked out of the box for me, although I had to add this line to prevent building errors:
-dontwarn com.google.android.gms.**
#Erwin Moller For this issue you may need to safe as less as possible files filter from obfuscation so here you can try below proguard rules and try it too run. Good luck
-keep class org.apache.cordova.engine.** { *; }
-keep public class * extends org.apache.cordova.CordovaPlugin

How to integrating proguard in android having other project as library?

I am trying to enable proguard in my application,
which uses my other project as library,
Library project has many 3rd party libs like spring,
while generating signed apk with proguard it gives me reference not found from R$id of library project,
i can not exclude library project from obfuscating...
Help me..
Stuck with this from 1 week...
Most projects will include a list of ProGuard rules they need added in order to function correctly.
If they don't you will need to play some hit and miss until you get a good compile (and decent size reduction).
Are you using this default ruleset?
proguardFiles getDefaultProguardFile("proguard-android-optimize.txt")
That contains a set of rules that will cover all basic requirements for an Android App. You can then add your own rules in an additional config file:
proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"), "proguard.cfg"
If you are getting errors related to R then you are probably not running a correct base config.
For example, in proguard-android-optimize.txt it ensures that R is correctly maintained:
-keepclassmembers class **.R$* {
public static <fields>;
}
You should add rules for all libraries you use.
This is article for Spring.
Some useful information here.
If it's your project you can just keep everything from it
-keep class com.example.project.** { *; }
-dontwarn class com.example.project.**

Unknown classes ILicensingService notes when obfuscating Android project

I'm trying to build an Android release with Ant and ProGuard. I uncommented the following line in project.properties, despite the comment in said file noting that you shouldn't modify it ;):
proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
When obfuscating, I get the following notes:
[proguard] Note: the configuration refers to the unknown class 'com.google.vending.licensing.ILicensingService'
[proguard] Note: the configuration refers to the unknown class 'com.android.vending.licensing.ILicensingService'
I do understand why this is happening. These lines can be found in the default ProGuard config file (${sdk.dir}/tools/proguard/proguard-android.txt):
-keep public class com.google.vending.licensing.ILicensingService
-keep public class com.android.vending.licensing.ILicensingService
I'm not using the Google Licensing Service, so the classes are indeed unknown. I found a solution to get rid of these notes by updating the proguard-project.txt:
-dontnote **ILicensingService
My question: Is this the correct way of handling this? It seems to me that these classes shouldn't be kept by default anyway, since that lib isn't mandatory for an android project. The only way I can think of to achieve this is by copying the default config file to my project, removing the -keep lines and ignoring the default config file in the SDK completely. Which doesn't seem as the proper way to go either. Or am I missing something?
The setting "-dontnote com.google.vending.licensing.ILicensingService" is fine. In fact, it could have been part of the default configuration file.
The -keep option may be necessary for projects that use the library.
The -dontnote option may be nice to suppress the note about the -keep option, for projects that don't use the library. The note is just a gentle reminder that the configuration file could contain a typo, because the specified class doesn't seem to exist. It doesn't affect the processing.

Categories

Resources