BlueBox Android Challenge

Some weeks (? I don’t even remember the time frame) ago I was made aware by a friend of this challenge. Basically injection of Dalvik code through native code. I found some minutes this morning to look into it and while I’m sure somebody else has already solved it, it’s a nice way of showing a bit of how to reverse engineer Android applications with the Profiler.

The first problem we encounter is that the APK (which is a Zip archive) has been tampered with. It asks incorrectly for a decryption key because all file headers have had their GeneralPurposeBit modifed, e.g.:

A few lines of code to fix this field for all file entries in the Zip archive:

Now we can explore the contents of the APK with the Profiler. We have the usual ‘classes.dex’ file plus the native library ‘lib/armeabi/libnet.so’. Let’s open the library with IDA. You’ll notice the functions it contains aren’t many and just by looking at them we’ll stumble at this function:

It’s clear that at some point during the execution of the Dalvik code this function is triggered which writes the array ‘inject’ into the memory space of the DEX module. We can verify that they are indeed Dalvik opcodes with the appropriate filter. Select the bytes representing the array in the hex view and then open the filter view:

Dalvik filter

The functions called before the actual injection locate the exact position of the code. They help us as well: back to the Profiler, let’s find the method “L-ÿava/lang/String;”:”add”:

Methods

From here we get the class index and name. Just by looking at the disassembled class we’ll notice a method filled with nops:

Method with nops

The code size of the method matches the payload size (111 * 2 = 0xDE):

Classes

Let’s write back the instructions to the DEX module:

Write payload

We could do this with a filter just as well by the way:

And now we can analyze the injected code:

And that’s it. It took much more time to write the post than the rest (about 10 minutes of time if that). Reverse engineering the crackme to find the correct key is beyond the scope of the post, although I’m sure it’s fun as well.

Thanks to BlueBox for the crackme!

Damaged Zip archive (video)

In this video we can see how to inspect a damaged Zip archive using the Profiler in a real-world scenario. Although soon the automatic recovery of damaged Zip archives will be available and it will be possible to perform this sort of task programmatically, it’s still useful to see how to do this kind of thing manually.

Zip bomb

While the Profiler was designed for document analysis and currently has virtual memory limitations, let’s see how it performs with a Zip bomb. 🙂

A friend of mine linked me the Zip file on this page.

The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.

That’s 16^5 or 1048576 files. If we try to scan it with the Profiler, it will just take endless time trying to scan all the files. It won’t crash nor exhaust memory, just take ages. But we want to analyze the file right now, so how do we do it?

It’s very easy. By default the Profiler has quite a huge nesting limit (10), we can decrease that limit from the Setup -> Limits page. The nesting limit tells the Profiler at which depth of embedding/referencing the scan should stop.

Nesting limit

In this case I have decreased it to 1, but 2 or 3 would still have been reasonable. A value of 1 means that only files at the first level will be analyzed. By inserting a value of 0, the file will be opened without any scanning of sub-files.

Zip bomb level 1

But what if we want to analyze more in depth one or more branches in the hiearchy? The nesting limit applies only to automatic analyzes, not to manual ones, which means that we can activate items and get the analysis for them (and their children).

Zip bomb manual analysis

As you can see, we’re now analyzing the Zip bomb at the fourth level of nesting. 🙂

Zip archives support

Among other additions, the new 0.7.8 version of the Profiler features support for Zip archives and an improved interface for displaying the file hierarchy.

Zip Archive

The supported decompression methods are Deflate and BZIP2 (more will be added). All popular encryption technologies are supported: ZipCrypto and WinZip AES. Support for the undocumented and proprietary PKWare encryption technology is still missing.

One of the handy UI improvements is the in depth risk report.

Risk tooltip

In this case the global risk signals that the calculated risk is 45% but could be more because some files could not be analyzed, since their format is not supported. This risk reporting is available both for the global risk and individual files.

Risk tooltip 2

In this case the main file “nested_crypto.zip” was decrypted but the decryption of the embedded file “test.zip” failed, because I didn’t enter the password for it. We can see that “test.zip” has not been decrypted (nor the files it contains) because of the e character next to the risk percentage. The meaning of these kind of characters is explained by the tooltip.

The Zip format covers an enourmous amount of extensions and hugely increases the usefulness of the Profiler. Enjoy! 😉