Performing Binary Exploitation  and Reverse Engineering with Radare2

Binary exploitation is a niche but essential part of pen testing applications, especially when testing native mobile applications. This blog post aims at introducing the basic concepts of reversing binaries and shows a small glimpse into vulnerabilities it can expose in native mobile applications.

This series will primarily be aimed at reversing binaries and identifying exploits using radare2, as radare2 has a steep learning curve we will primarily look at basic concepts using this tool to familiarize ourselves and get used to the interface.

Introduction

Radare2 is an open-source framework for reverse engineering and binaries analysis that implements a rich command-line interface for disassembling, analyzing data, patching binaries, comparing data, searching, replacing, visualizing, and more. It has great scripting capabilities, it runs on all major platforms.

More information on the tool and the documentation can be found on the official website

This post will not dwell on the deeper concepts and commands of radare2 as it is very vast and difficult to cover all in a single post. As we progress with complex binaries we will look at the different features the tool has to offer in-depth.

Radare2 Installation

Radare2's development is pretty quick – the project evolves every day, therefore it’s recommended to use the current git version over the stable one.

$ git clone https://github.com/radare/radare2.git
$ cd radare2
$ ./sys/install.sh

The installation is fairly simple and straightforward, based on the OS you are using you can obtain the binaries here https://www.radare.org/r/down.html

Getting Started with Radare2

As with most command-line utilities, the best approach to reveal the list of the possible arguments is to execute the program with the -h flag.

Now that we have a basic understanding of what radare2 is and how to install it let us look at a use case of this tool while pen testing mobile applications.

Recently when doing penetration testing for an android application for a client I came across a very unusual behavior in the application. While looking at the traffic from the application using BurpSuite there is an initial request that is sent from the application with a password, this password always remained the same which made me suspect it was hard-coded somewhere in the apk.

However, after opening the apk with jadx and going through the code I was unable to find a password or any other sensitive data within the apk.

This was very unusual as mobile applications written in java have the hard-coded data within the apk which is sent to the server to obtain a valid token.

At this point, I had to look for other ways in which data can be stored in the application other than hard-coding it in the apk. While I was going through the rest of the code to get a better understanding of the application I noticed a load library method being used in several places.

Seeing the official documentation tells us that the load library method loads the dynamic library with the specified library name. A file containing native code is loaded from the local file system from a place where library files are conventionally obtained. The details of this process are implementation-dependent. The mapping from a library name to a specific filename is done in a system-specific manner.

This tells us there are binaries that are used by the application that also contain code and other data.

Decompiling the application using apk-tool we can see all the resources and libraries that are within the apk.

apktool d tmp.apk

After we decompile the apk and go into the directory we see a lib/ directory which will contain all the libraries used by the application. Navigating into it we see a couple of binaries that are being used.

The libexported-generic-keys.so look very interesting so we will open this binary using radare2 and see if we can find anything interesting.

x86_64 r2 libexported-generic-keys.so
-- Too old to crash
[0x00000d60]> aaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[x] Check for objc references
[x] Check for vtables
[x] Type matching analysis for all functions (aaft)
[x] Use -AA or aaaa to perform additional experimental analysis.

After loading the binary in r2 we use the aaa command to analyze and auto-name all the functions in the binary, this is usually not recommended when working with large binaries as it is extremely resource-heavy and time-consuming. As this is a very small binary we can use this command to quickly understand what the binary contains and see if we can find any sensitive data. After analyzing all functions we can list the functions using the afl command.

Here we can immediately see the auto naming of the functions gives all data that was stored as strings in the library. Disassembling any of the functions above using the pdf command along with the memory location of the function that is displayed next to it, we get the hard-coded string that is stored in the binary in a base64 encoded format. Decoding this data we obtain passwords, secret keys, and API keys that are hard-coded.

To confirm this is where the password was being taken from we can go back to the decompiled java and search for all the load library methods in the code and we get the following result.

Conclusion

There are easier methods to obtaining this data from the binary but the aim of this post was to familiarize ourselves with the interface and commands of r2 so we can look at reversing complex binaries in the posts to come.