Reverse Engineering of Mobile Apps

Contributor - 10 March 2017 - 12min
Contributor - 10 March 2017 - 12min
Introduction:
Reverse engineering is the processes of extracting knowledge or design information from anything man-made and re-producing it or re-producing anything based on the extracted information. The process often involves disassembling something (a mechanical device, electronic component, computer program, or biological, chemical, or organic matter) and analyzing its components and workings in detail.
The reason for employing such techniques might vary from penetration testing to criminal actions. When developing an application for some business, developers and testers should be aware of what reverse engineering actually entails, what techniques are used and what tools are employed.
This document is aimed at shedding light at some of the techniques that hackers use in order to break into your application and steal data. Please note that these are also techniques used for penetration testing to determine the vulnerability of an application. So, without further ado, let’s just dive in.
What do hackers look for in your application to start reverse-engineering it?
Objective-C and Java programs contain rich information about themselves. Both language compilers will embed definitions of the class interfaces and the relationships among the classes in the binaries. Such information is one of the first things an attacker will seek when attacking an app.
In the example below, an attacker extracts class interfaces from the binary using the class-dump-z tool. The tool is specifically built for reverse-engineering. Below is a class interface extracted from a real-world iOS banking app:
In this particular interface, which describes the underlying architecture and design of the application, an attacker is going to immediately identify the jailbreak status method as a particularly attractive target for modification. If the attacker can successfully disable this method, an attacker will force the app to run in a particularly insecure perform that allows for subsequent attacks.
Mitigation:
2. API Monitoring:
The Objective-C runtime lets an application modify its mapping from a selector (method name) to an implementation. In doing so, an application can patch a method and execute additional methods each time the original method is invoked by the runtime engine. This is typically done when an organization cannot inspect or modify the original method.
An attacker can take advantage of this feature to create a log of method calls invoked by the application. An attacker will be able to understand the control of flow of an application without decrypting the binary and analyzing it through the use of tools like IDA Pro.
Mitigation:
As an illustration of the amount of information these symbols can reveal, below is a partial list of the symbols found on a real-world iOS banking app (the list was produced by nm, a symbol-dumping command-line tool):
In this example, the application declares sensitive data fields (about authentication and credit card information) and accurately describes what they will contain at runtime. Symbol names and locations reveal the internal assets of the application.
Mitigation:
3. Cryptographic Key Interception:
Consider an application that uses cryptographic operations provided by system libraries. The application must pass appropriate keys to these libraries in order to decrypt the data. At runtime, attackers may choose to monitor the system library interface and intercept calls to decryption methods. The application will pass the appropriate key as a parameter to these methods and the attacker will successfully grab the key.
As another example, imagine an application that tries to mitigate this risk by implementing its own cryptography or statically links to a third-party library. In response, the attacker will examine the application’s symbol table and look for cryptography-related method names (including the words “key”, “crypto”, “encrypt”, “sign”, “AES”, “MD5”, and so on).
Mitigation:
4. Algorithm decompilation and analysis:
Algorithms encoded in intermediate languages such as Objective-C or Java are particularly vulnerable. Decompilers have made it simple to turn low-level assembly code to a high-level source- like pseudocode. The Hex Rays Decompiler, a plugin to IDA Pro, is an excellent example. Widely used by adversaries and security researchers, it can decompile almost any ARM or x86 code into its original form with startling accuracy.
Mitigation:
5. Application Decryption:
To reverse-engineer an iDevice application, the attacker must attach a debugger to the relevant process and capture an unencrypted form of the application to disk.
Typically, attackers use tools like clutchmod to decrypt an application and store it to disk. This tool starts the application and attaches a debugger to it while it is running. At this point, iOS has decrypted the application and is executing it in memory.
Mitigation:
Conclusion:
When applied appropriately, these self-defenses can make a mobile application highly resilient against attacks, even on rooted or jailbroken (compromised) devices. For example, self-checksum and self-repair code equips your app with self-awareness, self-repair, and tamper-response capabilities.
It is important to layer these defenses and implement them in a networked fashion such that the protection does not cover just the vulnerable application code, but also the protection mechanisms themselves. This is a multi-layered, defense-in-depth approach that has been proven highly effective against hacking attempts.
Leave a Reply