Is ProGuard really a good way to protect the android application? I do not think. Please see the following images:
Compile Code
Decompile_Code
Also the variable names did not change and the code is readable easily.
Activity classes are not completely obfuscated. This is because the activities are listed in the manifest and classes referenced there are automagically kept. This is needed because the Android framework accesses these app entry points via reflection.
Read more from here:
The build process runs the tool aapt to automatically create the
configuration file bin/proguard.txt, based on AndroidManifest.xml and
other xml files. The build process then passes the configuration file
to ProGuard. So ProGuard itself indeed doesn't consider
AndroidManifest.xml, but aapt+ProGuard do.
Related
I have an application that's written with Unity. It uses a custom Application and Activity class. Previously this has worked just fine but I've recently switched to using gradle to perform the build instead of Unity's deprecated internal build process. My Application and Activity classes are located in a library that's in the form of an aar file. The custom classes are referenced from a the and tags of a custom AndroidManifest.
I can see that the classes are present in the aar. I can see that the generated AndroidManifest references these class. I can see the dependency on this library in the generated build.gradle file. I can tell that the build process is actually referencing this library in some form. However, these classes are not present in the resulting APK, resulting in a crash on launch.
I do not have proguard or anything similar enabled. I can tell that this is a new problem because older versions of the APK do have those classes. What could be causing these classes to not be included in the resulting APK?
The package that contained those classes had the same name as the one generated by Unity. I changed the package name and everything seems to be working now.
I am creating one SDK for android which include the Activity, Services and Broadcast receivers.
Problem is when i generate the AAR file from my project and import it to other sample project my All the Activity, Services and Receivers names are visible from Manifest of my AAR file.
I don't want to expose any of my class name to users of My AAR file, Please provide proper way to hide my confidential code and classes.
Remember one thing "Everything is hackable" and java classes are decompilabel.
You can use the Proguard to Obfuscate your code
Have a look
https://developer.android.com/studio/build/shrink-code
With Proguard, it will also shrink your code and reduces the size of you AAR file
and change the names of the classes, then it is hard to recognize the functionality of your lib file.
Learn more about Obfuscation: https://en.wikipedia.org/wiki/Obfuscation_(software)
I've been doing Android development for a little bit and I'm getting to a point in one of my projects where I would like to use Proguard to shrink the size of my APk and help with the dex limit. Unfortunately, I am getting a few errors and stack overflow has answers but they seem to be targeted for those with more experience.
My question is what is the relationship with your proguard-android.txt and proguard-rules.pro? Why are there two separate files and why are they in separate formats? When are the statements in these files called and in what order? I am just looking for an explanation of the overall context of using Progurad in a development environment.
Thank you in advance.
ProGuard manipulates Java bytecode the way you tell it with your configuration files and the rules they contain. ProGuard can do many things. And it can completely break your app so you have to make sure to add the correct rules.
I assume you use Gradle based builds for your apps. Then you've probably encountered this snippet that enables ProGuard for release builds of your app (or Android library):
android {
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile(‘proguard-android.txt'),
'proguard-rules.pro'
}
}
...
}
In the config the list proguardFiles tells the build what files that contain ProGuard rules it has to use. This list can contain any number of files.
Why are the files (proguard-android.txt and proguard-rules.pro) defined differently?
The magical getDefaultProguardFile(‘proguard-android.txt') loads file named proguard-android.txt from the standard location in the Android SDK (the location is ${ANDROID_SDK}/tools/proguard/).
Other config files are resolved locally, so file proguard-rules.pro is expected to be at the root of the current Gradle module.
Why are there two separate files? And what is the relationship between proguard-android.txt and proguard-rules.pro?
ProGuard configuration is additive. You can define some rules in one file and other in other files. The rules are internally concatenated into single list of rules.
File getDefaultProguardFile(‘proguard-android.txt') contains several general rules for all Android apps (check them yourself, in the file in your SDK). The local proguard-rules.pro is expected to contain rules specific for your own app. For example you want to make sure that a class is not stripped away when you use it only through reflection (I'll get to that later).
Note that having multiple local files is very useful. For example you can use two local config files for debug builds - one with the release rules for your app and the second containing rules disabling obfuscation.
Also note that the additive behaviour of the configurations can be a bit troubling. If you add a rule in one config file, you cannot remove it in another. So be careful with very general rules (e.g. imagine adding -keep class ** { *; }).
When are the statements in these files called and in what order?
You can define them in any order, there's no difference. And you can define the same rule in multiple files, it doesn't matter. The order of the specified files doesn't matter either.
ProGuard itself is run as a single job within the Android build (single Gradle task to be precise). The task is provided all the inputs:
classes to manipulate
library classes to use but not manipulate
output path for generated processed jar
ProGuard rules specifying the manipulation
output paths for various output information (what was removed, mapping, …)
And then it processes the files and generates an output which is further processed by the Gradle build.
How does ProGuard actually work? And why do I need the rules?
ProGuard traverses the whole call graph of classes/methods/fields/…. It starts with the classes/methods/… defined by the provided rules. Then traverses the call graph and marks classes/methods/fields/… as necessary and keeps them for the output. So if you call it with no matching keep rules it will generate an empty output (or maybe it will throw an error and tell you to define some, I don't remember now). ProGuard doesn't recognize calls done via reflection, so you have to add some rules to handle that. There are many other cases that require you to add some rules, check the documentation for that.
Final notes
If you check ProGuard documentation you can find various rules
you can use. But not all of the rules are good for Android (ProGuard is a general Java tool).
Some rules are generated by Android build itself, you don't have to define them yourself. There are 2 types of such rules:
General config rules like -injars, -libraryjars, …
Rules generated from AndroidManifest.xml and resources (layouts). Android build (aapt tool) generates rules to keep classes mentioned in the manifest (activities, services, receivers, …) and custom views used in layouts. You can check these generated rules in build/intermediates/proguard-rules/${PRODUCT_FLAVOR}/${BUILD_TYPE}/aapt_rules.txt
Some rules can come from aar libraries. The libraries can contain ProGuard config necessary for the library to work (there can be proguard.txt file inside).
When writing Android libraries yourself be extremely careful with the rules you want to add to the aar. Because of the additive nature of the rules, it can cause problems for the app that bundles the library.
We are using android-maven-plugin to build a multidex application targeting Jelly Bean (4.3.x) with greater than 65k methods. The approach described here helps create a MainDexList.txt file, but does not automatically include classes that will be loaded by reflection.
Are any tools or processes available that can create a MainDexList.txt file with reflection support? [The majority of the classes we are loading via reflection are named via String constants...]
We are attempting to avoid manually running the app and dealing with NoClassDefFoundError messages one at a time.
To deal with the NoClassDefFoundError, you just need to add the MainDexList.txt to each of your projects. This should solve your initial errors right away. However, since your MainDexList.txt will still be empty, you will run into further issues.
To load the MainDexList.txt with a script instead of doing it manually, you can use this open source script by Google which will generate the exact class names that should be included in MainDexList.txt. Here is a link to the actual commit by Google:
https://android.googlesource.com/platform/dalvik/+/2bb6fe45bf620525ba34bd7303d7ecb597aa0689
To learn more (and also my source of information):
http://blog.osom.info/2014/10/generating-main-dex-list-file.html
Notes: This unfortunately does not support reflection however, DexClassLoader loads classes from .jar and .apk files containing a classes.dex entry. This may be worth looking at as well.
Hope this helps!
I have enabled Proguard by uncommenting the following line in project.properties file:
proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
When I tried to extract the classes and resources using dex2jar , I was able to extract them as it is. Do I have to change some other files / properties / configurations in my project to prevent direct extraction of classes? Should I add some configuration parameters in the project.properties(project root location) or proguard.android file(SDK location)?
It seems you're using the "standard" Proguard obfuscator properties file. Try using the "advanced" Proguard obfuscator properties file. It's here:
proguard.config=${sdk.dir}/tools/proguard/proguard-android-optimize.txt
Your codes will be obfuscated a bit further, but not all. For example, activities, services, Java classes you've declared in the manifest file, or declared with -keep directives in Proguard, will not be completely obfuscated.
On a side note: Even if you use the commercial DexGuard, you're still not 100% protected from decompilation. Experienced hackers can use smali/baksmali techniques to reverse engineer your codes, read it, modify it at will. Remember, if codes can be read as 0s and 1s, it can be hacked.
Did this occur after you built your application in release mode and exported it using valid certificate and the Export Wizard in Eclipse ? If no - do the steps: right click on your project, choose "Export", type "export android application", Next, then choose "Use existing keystore" or "Create new keystore", finish the wizard. ProGuard runs only when you build your application in release mode.
There is no way to prevent the decompilation of classes and resources. Obfuscation, such as proguard, are tools to make reverse engineering of java harder through name munging, string munging, and flow control changing. Though as stated before, everything can always be reverse engineered. Obfuscation is used to make the barrier to entry higher, and to deter people from wanting to reverse engineer your code due to level of effort.