In this chapter, we will cover the following recipes:
- Compiling from Java to DEX
- Decompiling DEX files
- Interpreting the Dalvik bytecode
- Decompiling DEX to Java
- Decompiling the application's native libraries
- Debugging the Android processes using the GDB server
The previous chapter discussed the flaws in the applications; they can be exploited and discovered without the need to know exactly how they have been developed. Though there were detailed explanations on some common source code that caused this specific issue, we didn't need to read the source code to know that a SQL injection was possible. Largely, our first step in the direction of a successful exploit was to analyze the behavior of an application from a context that is ignorant of the actual details surrounding its behavior. The reverse engineering discussed in this chapter aims to uncover every single detail of an application's inner workings in order to exploit it.
Reverse engineering, when applied to computer software, is the process of learning how something works and developing ways to make use of, or abuse, this information. For example, reading the source code of a kernel driver may lead to finding a potential memory-corruption flaw, such as improper bounds checking for buffers. Knowing this may allow you to develop an exploit, given the context in which this vulnerability exists. Reverse engineering is the most essential skill of any security specialist and is at the heart of all true development exploits. When exploits and vulnerabilities are developed somewhere in the chain of events that lead to successful exploitation, reverse engineering has occurred.
Android applications are not different from other computer software types, and thus, they can be reverse engineered, too. In order to reverse engineer an application, one needs to understand how they are built, what goes where, and why. Not having this information leads to endless, sleepless nights of fuzz testing and brute forcing, which in most cases, will ultimately end in frustration. This chapter discusses a few recipes that you can use for extracting information about the inner workings of an application, and discusses some novel tricks that malware developers and security auditors use to abuse and reverse engineer applications.
Before we get cooking with the recipes, there's just one question that begs to be asked; why would you reverse engineer an Android application?
Here are a few ways to answer that:
- To read the source code: Often, many vulnerabilities stay hidden from attackers, simply because they don't manifest themselves during the "black-box" assessment of an application. This does not mean they are not vulnerable to exploitation; to quote, "the absence of evidence is not the evidence of absence!" Reading the source code of an application is the most effective way to learn its weaknesses and will, more often than not, result in the discovery of more vulnerabilities than a pure black-box analysis. Reading the source code is still the only concrete way to understand an application; you cannot trust anything but the source code; in other words, documentation is a lie until the source code proves otherwise!
- To leak information: Some vulnerabilities in applications don't stem directly from the behavior of the code but from the kind of information stored in the application, for example, static private keys and passwords, e-mail addresses, sign-on tokens, URIs, and other sensitive content. Cracking open an application grants you access to all of its secrets.
- To analyze defense mechanisms: Often, the common vulnerabilities in applications are protected in the most ridiculous ways. Though mitigating common attack paths, whether or not an application is protected from certain attacks depends purely on its source code and configuration. Often, without the source code and internal configuration, it may be extremely difficult, or at times impossible, to uncover how it protects itself. Reading the source code of a large number of apps in the same category can give you quite in-depth and knowledgeable insight into the best and worst ways to protect applications, for example, login apps. Reading a lot of source code from these may teach you how developers create defenses against authentication brute-force attacks, credential sniffing attacks, and other login app-specific defenses.
- To analyze attack techniques: You may be interested in finding out which application and system level exploits the latest and greatest Android malware. The only way to truly find this out, and put yourself on the cutting edge of Android security research, is to reverse engineer Android applications.
With these goals in mind, let's get going with the recipes.