An Introduction to CobraDroid 1.0

I'm finally happy to say that the beta for my ongoing project called "CobraDroid" is fully released!  The project was actually released back in March on my website, but the source was just pushed to GitHub recently.  I wanted to talk a little about what CobraDroid is, what it can do for analysts, and what you can expect in the upcoming months.

What Can CobraDroid 1.0 Beta Do?

CobraDroid is a modified Android emulator image designed for individuals who want to perform application security assessments or analyze malware for the Android platform. It is not a service where you upload an application and receive a summary of activity, and it is not a black-box (there are plenty of those out there).  It should help you with performing your analysis, but keep in mind it will not perform all the analysis for you. It is released under the Apache Software License 2.0, so you are free to download, modify, and use the source.  The beta is mostly a teaser for what is to come, but it includes:

• Configurable radio values (MIED, MDN, IMSI, SIM card serial number, and voicemail number)
• Dynamically configurable “build.prop” values
• Configurable SSL certificate validation bypassing 
• Enhanced proxy capabilities
• Additional user-space utilities

This should be enough to get you started, and already provides more functionality than the standard Android emulator.

What's Next?

The beta version of CobraDroid 1.0 is still lacking in terms of functionality and features.  Luckily, I've been hard at work on lots of new features.  I don't want to give away all the fun, but from a high level you can expect 1.0 to include:

• A newer, hand-ported kernel (say goodbye to the 2.6.29 Goldfish kernel)
• Full Bash shell + Busybox
• Application specific packet-capturing
• Java bytecode instrumentation
• Mercury and LiME integration 
• ..and more!

Many of these features are actually already implemented, but in a state of QA.  CobraDroid 1.0 should be ready to roll by the end of the summer, so stay tuned!

BruCON 2013

If by chance you are attending BruCON 2013, come check out my talk on CobraDroid and see a demo of the tool!  Hopefully I'll be presenting the tool in the states soon as well sometime soon.

If you are interested in trying CobraDroid, check out the getting started page.  Of course, feedback and comments are always welcome.

-jakev

Fixing Resource Identifiers in Disassembled Apps

If you have ever attempted to reverse an Android application, you've probably noticed that resource identifiers (think "R" values) show up as cryptic constants in disassembled smali code. This can be frustrating when attempting to reverse and understand the application's flow.  A rather contrived example of this issue is demonstrated below.

Imagine we write an application with a single activity. This activity simply inflates and shows a defined layout, which I've called "my_layout".

We defined this layout in our "res/layout/" directory. Its contents are not really important, but they are listed below anyways.

Once we start reversing this application, we will likely use apktool (or just baksmali) to disassemble the DEX bytecode. If we then examine the disassembled "ExampleActivity.smali" file, we notice that the "onCreate" method looks as follows:

What does the value 0x7f03 mean? What I didn't show before was that while we were coding away, Eclipse was helping us by bridging the gap between our resource files and our Java sources with the "R" class. This class creates an anonymous class for each resource type, and sets an integer value for every resource we define. We can then access our resources in our Java code with the syntax like "R.layout.my_layout", or "R.string.secret_message".  When compiled, this value is replaced with the integer value.

To make the mapping, we could inspect the various R$*.smali anonymous classes, but there is actually a better place to find these value. These values also appear in the "res/values/public.xml" file created by the Android application packaging tool ("aapt") during the build.

Since "public.xml" is an XML file, we can parse it using python with relative ease. This is where "fix_resources.py" comes in. "fix_resources.py" will parse the "public.xml" file, then search for instances of resource identifiers in our smali sources.  It will append a useful string on these lines, to make our job a little easier.

It will also resolve any string-type resource identifiers from the "res/values/strings.xml" file.  Let's say that we changed our "onCreate" method to copy a string from a resource file (no idea why you would want to do this), and print the value to the log:

Now, when we run apktool and "fix_resources.py" on our app, we will see that "fix_resources.py" has actually included the string's value in the code (it will truncate the string if it is too long).

I don't expect many applications to use this technique to obfuscate or hide sensitive strings, but overall "fix_resources.py" is a quick and painless way to add some addition annotations to your disassembled code.  Because the modifications are comments, apktool/smali will have no problem repackaging the code if you want to modify and rebuild the application.

"fix_resources.py" requires the lxml python module to run, but it's a pretty straightforward install.  You can grab the "fix_resources.py" script from my GitHub account.  Feel free to report any bugs or comments with the code!

-jakev