Hello, Habr!
My name is Artyom Azariev, I am a team leader for the Android team of the Moscow Credit Bank, and today I want to talk about application security from the point of view of debug libraries. A couple of years I was engaged in freelance, then for 4 years I have been engaged in full-fledged development for a mobile OS. It so happened that in the years of my freelance, in order to improve my own qualifications, I touched on the topic of reverse engineering of Android applications, and gradually it turned into my hobby.
Introduction
It's no secret that for a long time Android Studio did not present any mechanisms for adequately receiving application data from the device: the contents of the database, SharedPrefrences, network requests. Everyone suffered, including giants like Facebook.
It was they who gave the community an extremely useful library for debugging Shetho (https://github.com/facebook/stetho) with very simple integration into the project in just a couple of lines. I won’t talk about the library itself; most likely, many people already know it, but who cares, they read it on their own.
The integration of this library is as follows:
Using the Chrome browser, we have access to the contents of the databases and to the settings stored on the device, and if we connect the plug-in for okhttp3, then also to the contents of network requests.
“But hey, will it be in the release build?” The attentive developer will ask himself. Let us turn to the description of the library - what are we advised about this?
The sample project shows that this library needs to be initialized only in the debug branch by overloading the manifest in one of the build options.
We collect the release assembly with minification enabled (minifyEnabled flag). We check the browser, do not see any application available for debugging and quietly go to sleep.
Minification is a process aimed at reducing the size of the source code by removing unnecessary characters without changing its functionality. The Proguard tool used in Android is also involved in cleaning the project from unused code.
Hackers
Any reverse engineering of the application begins with the study of potential bookmarks and backdoors, which were kindly left by the developers for themselves.
First, we decompile the application in Java as much as possible and study the package tree.
The sweetest thing that can be found in the attacked application is the good old Stetho. The minification set by default does not remove it, and in general, the entire code base of this library simply drags into a production build.
I saw a lot of applications from cool enough and large companies that have left such a library in production builds for many years.
Someone will ask: “And what is it? It is off. Plus, even if you turn it on, try building this app later. ”
True, decompiling in Java almost never gives 100% working code. But there is smali / backsmali.
Smali / backsmali is an assembler / disassembler for the dex format used by dalvik, an implementation of Java VM in Android.
By disassembling our application, we will see that nothing is really included.
But, having added a couple of lines and having all the library code in the project, we, without really straining ourselves, can turn it back on.
For the okhttp3 plugin, support is enabled in a similar way - by adding an Interceptor to OkhttpClient.
Having collected the application back (and it is easy to do it from smali), we see that debugging through stetho is again available, and all your data in the local settings repository, all your api is completely in front of the eyes of cunning hackers.
What to do?
There are many options to exclude package from the final build. Personally, I prefer to write a small wrapper to initialize the Stetho library and decompose its various implementations according to the assembly options.
release
debug
And also indicate that this code base is needed only in the debug build.
Can exhale
I would like to conclude by voicing the basic principles that I use when working in the context of Android application security:
- Minify and, if possible, obfuscate everything you get.
In any case, this complicates the analysis of decompiled code. An additional argument for creating gray hair on the hacker’s head will be the repackageclasses flag, which will move the minified classes into one package. There will be a lot of them. - Explore your own applications.
At least a cursory inspection of the tree of your packages can tell a lot about the structure used in the project, frameworks, libraries. That which obviously does not belong there should be mercilessly removed. - Any tool can sooner or later shoot you in the knee.
When adding something to your project, even for good reasons, think about how to do it correctly and how much you need it at all.
I hope my experience will be useful to you.