As a pen tester and avid Android user, I'm keenly interested in the security of Android applications. Even without looking at the code, we can gain a tremendous understanding of what happens in the deep, dark corners of an application. All we need to do is dig away at the Android resources.
Evaluating Android applications is more than just looking at the decompiled source or runtime analysis of packet capture data. When I'm examining applications, for example, the stuff other than code ("resources" in Android terms) can help me figure out the purpose of the application itself. Josh Wright found the same thing to be true when he examined a number of "ghost detection" Android apps over the summer.
As a general rule, if the app includes 10,000 MP3 files of creepy sounds, it probably isn't "tapping into the non-corporeal aether."
Background
While we commonly think of resources as files, they can just as well be strings or any arbitrary data. For internationalization (commonly abbreviated "i18n") application developers will commonly include the strings of an application in many forms, so that they don't hard-code English text, for example. Similarly, it's convenient to extract some constants such as URL's, local HTML, and images from being included in the code itself and put it into a resource, instead.
Unzipping an APK
All that resource information is bundled together in a binary file named "resources.arsc" and stored in the final .APK file. Since an APK file is just a .zip file that has been renamed, you can use the "unzip" utility to open it up and take a look:
jeff@blue:~/example$ <strong>unzip mobile-release.apk</strong>
Archive: mobile-release.apk
inflating: AndroidManifest.xml
inflating: META-INF/CERT.RSA
inflating: META-INF/CERT.SF
inflating: META-INF/MANIFEST.MF
inflating: build-data.properties
inflating: classes.dex
inflating: jsr305_annotations/Jsr305_annotations.gwt.xml
inflating: res/anim-v21/design_bottom_sheet_slide_in.xml
[...skipping a lot of output...]
inflating: res/transition-v21/lb_vertical_grid_return_transition.xml
inflating: res/xml/allowed_media_browser_callers.xml
inflating: res/xml/automotive_app_desc.xml
**extracting: resources.arsc**
jeff@blue:~/example$ Here I extracted an APK file that I built from Google's open source project.
Unfortunately, I wouldn't recommend looking around in these folders manually as a regular activity (feel free to do so for the first few applications you extract, though).
Why? Because production applications have a lot of files.
Really. A lot of files:
$ unzip mobile-release.apk >/dev/null
$ find . -type f | wc -l
1392In other words, it's easy to get lost exploring these dark passageways, and even more difficult to thoroughly inspect all of the data manually.
Since today's topic is resource files, let's take a look at those in particular. I'll take a great idea from our DFER friends and look for the least-frequently occurring file types with some Bash command line kung-fu below:
$ cd res
$ find . -type f -exec file -b {} \; | cut -d, -f1 | sort | uniq -c | sort -n
4 Ogg data
380 Android binary XML
999 PNG image dataIn this command, "find" identifies files (not directories and such, that's what "-type f" is for) and runs "file -b" on each filename, in case of mislabeled file extensions. The first "cut" command takes just the output from"file -b" before a comma, since "file" gives information about image resolution and such. The "sort" command sorts the output from the previous command, which is necessary for "uniq -c", which counts the sorted input. Finally, I used "sort -n" to show the output in numerically-sorted form, so we see the least frequently occurring file types first.
The "Android binary XML" output that the "file" command returned tells us that those XML files aren't actually plain text. They are a binary representation that is a lot more hassle to deal with. Fortunately, we don't have to go file system spelunking manually; we can rely on other tools to help with the analysis.
Decoding an APK
First up is Apktool, a command-line utility that works very reliably to decode Android application data. If other, perhaps more automated tools are failing you, I'd highly recommend going back to Apktool for your Android application analysis needs.
Here is the basic usage of Apktool against an APK file:
jeff@blue:~/example$ ls *.apk mobile-release.apk jeff@blue:~/example$ apktool d mobile-release.apk I: Using Apktool 2.2.1 on mobile-release.apk I: Loading resource table... I: Decoding AndroidManifest.xml with resources... I: Loading resource table from file: /home/jeff/.local/share/apktool/framework/1.apk I: Regular manifest package... I: Decoding file-resources... I: Decoding values */* XMLs... I: Baksmaling classes.dex... I: Copying assets and libs... I: Copying unknown files... I: Copying original files...
We can see that Apktool loaded and decoded the resource files (including that "binary XML" we saw before) and wrote them to the filesystem. Let's verify that using the same "find" usage as before:
jeff@blue:~/example$ cd mobile-release/res/
jeff@blue:~/example/mobile-release/res$ find . -type f -exec file -b {} \; | cut -d, -f1 | sort | uniq -c | sort -n
4 Ogg data
544 XML 1.0 document
999 PNG image dataSweet! Not only did we get more files, the XML files are now in plain text. What treasures shall we find inside? Well, for quick analysis of the application, I like to search in the decoded strings.xml file as follows:
jeff@blue:~/example$ cd mobile-release/res/values
jeff@blue:~/example/mobile-release/res/values$ less strings.xml Of course, if you're looking for back-end web services, you could also try to find URLs inside some of those XML files.
What else do we have to work with? If you're looking for a GUI and you're willing to accept a little less reliability, there are two tools I commonly reach for that I'd like to recommend.
First up: JadX. I like JadX for a more thorough examination of the code inside the application itself, as it gives you an IDE-like viewer of the decompiled code, like in the following image:
Another tool I like is called APK Studio. If I ever plan to edit the source code to an Android application, I like to use APK Studio, because it makes re-zipping the resources, signing it with a certificate (that you unfortunately have to create outside of APK Studio), and installing it onto your Android device very easy. Here's a screenshot of the application itself:
Whew! That was a lot of content for one blog article, but I hope it helps you get a good start to examining Android applications.
Next time you're evaluating an Android app, make sure you investigate the app resources. You never know what unexpected and exciting speleothem you may find.
Happy hacking!
