Things about Android application hardening

Labs Guide

As people become more and more dependent on smartphones, incidents of user information leakage and property loss due to smartphone software security are frequent, and people are beginning to pay more and more attention to the field of App security. From the development perspective, it is the issue of App source code security, based on the code audit level; from the software protection perspective, app security is code obfuscation, resource encryption, and logic reinforcement of the source code; from the user's perspective, it is the security of the App itself, whether it will cause loss of personal privacy and property.

Part 01. Why is reinforcement necessary?

The Android operating system is completely open source. You can unpack the Android application Apk and reverse engineer the DEX file to obtain the original source code and application logic. Through reverse engineering, you can steal the core code of the application, break the program logic restrictions, tamper with the application or inject malicious code, and sniff the application server API interface.

Application hardening can increase the reverse cost of software, protect the interests of software from damage, protect software copyright, prevent applications from being cracked, and protect key information of application programs from being stolen.

Part 02, Principles of Apk Reinforcement

The key information of the application Apk is stored in the DEX file, and the focus of hardening is to protect the DEX file from being reversed. The common idea is to use a private algorithm to change the DEX file structure during packaging, so that the DEX file content cannot be read using conventional means; because the DEX file structure has changed, the host machine cannot read and identify the DEX file, so the application needs to provide a custom loader to complete the decryption and loading of the DEX file.

After Apk is hardened, the original code of the main DEX file can no longer be seen, thus achieving the effect of hardening. However, doing so will cause the Application of the main App to be invalid. You can customize the creation functions attachBaseContext and onCreate in the Application life cycle, and hand over the decrypted DEX to the system for processing in attachBaseContext. During onCreate, the Application of the main App should be created and the Application reference in the system should be replaced, so as to ensure that the Activity is loaded and executed smoothly.

Part 03: Strengthening the development process

Apk hardening technology has undergone four generations of technological changes, and the protection level has been improved in each generation.

3.1 First Generation Hardening: Dynamic Loading

Principle ➪ The first generation of hardening technology is used to protect the logic of the application from being reversed and analyzed, mainly based on the dynamic loading technology provided by the Java virtual machine. During the development phase, the program is divided into two parts: the loader and the key logic (Payload), and packaged separately; at runtime, the loader part (Loader) will run first, release the key logic (Payload), and then use Java's dynamic loading technology to load it and transfer control.

Flaw: The flaw of the first generation hardening technology is that the dynamic loading mechanism requires its key logic (Payload) to be decompressed and released to the file system, which gives attackers the opportunity to obtain the corresponding files. Attackers can use a custom virtual machine to intercept the key function used by the dynamic loading mechanism and copy the key logic (Payload) file in the file system inside this function.

3.2 Second-generation reinforcement: non-ground loading

Principle ➪ The second generation of hardening technology is mainly to solve the problem that the decrypted Payload needs to be written to the file system and stolen. The code takes over the creation of the Application object. The main process is:

1) Loader is loaded by the system.

2) The system initializes the StubApplication in the Loader.

3) StubApplication decrypts and loads the original DEX file (Payload).

4) StubApplication finds the original Application object from the original DEX file (Payload), creates and initializes it.

5) Using the Java reflection mechanism, replace all references to the StubApplication object in the system with the original Application.

6) The Android system performs normal life cycle management of other components.

Disadvantages: The second-generation hardening technology does not store the decrypted DEX in the file system, but it has to process a large number of encryption and decryption loading operations when the application starts, which will cause the application to freeze for a long time (black screen), and the user experience is poor. Compared with the first-generation technology, there is no essential difference. Although it can prevent the defect that the first-generation hardening technology files must be copied on the ground, reverse workers can also find DEX files from the memory, through debugging tools such as GDB, which increases the cost of obtaining DEX compared to the first-generation hardening.

3.3 Third Generation Hardening: Instruction Extraction

Principle ➪ Since the first two generations of hardening technologies are all encrypted at the file level, the Payload of the DEX file in the memory is continuous and can be easily obtained by attackers. The third generation of hardening technology has a deeper protection level at the function level. In the release phase, the function content (Code Item) in the original DEX is cleared and written into a file separately. After the App is started, the function content is restored to the corresponding function body in the running phase.

Disadvantages: Instruction extraction technology uses a lot of virtual internal structures and undocumented features, coupled with Android's complex manufacturer customization, which makes it very difficult to steal DEX files. However, some solutions of instruction extraction technology conflict with the JIT performance optimization of the virtual machine and cannot achieve the best operating performance. An attacker can customize the Android virtual machine, record the content of each function (CodeItem) in the interpreter code, and obtain all the function contents by traversing and triggering all functions, and finally reassemble them into a complete DEX file. At present, there are already automated tools that can unpack instruction extraction technology.

3.4 Fourth Generation Hardening: Command Conversion

Principle ➪ The fourth-generation hardening technology provides function-level protection, but attackers can still obtain DEX files by executing codes with the help of the interpreter in the Android virtual machine. The fourth-generation hardening technology uses a custom interpreter to replace the standard interpreter. Since the custom interpreter cannot directly call other functions in the Android system, it must use JAVA's JNI interface to call.

Flaw: The instruction conversion technology must interact with the virtual machine through the JNI interface provided by the virtual machine. Attackers can directly treat the instruction conversion/VMP hardening solution as a black box, and use custom JNI interface objects to detect, record, and analyze the inside of the black box to obtain a complete DEX program.

3.5 Next-generation hardening: virtual machine source code protection

Principle ➪ Virtual machine source code protection and reinforcement uses virtual machine technology to protect all codes, including Java, Kotlin, C/C++, Objective-C, Swift and other codes, with extremely high compatibility; so that the App can be protected at a higher security level and run more stably. Virtual machine source code protection isolates an independent execution environment inside the App, and the running program of the core code runs in this independent execution environment. Even if the App itself is cracked, this part of the core code is still invisible.

Virtual machine source code protection has a unique variable instruction set, which greatly increases the difficulty of instruction tracking and reverse analysis. At the same time, virtual machine source code protection also provides anti-debugging and monitoring capabilities. Virtual machine source code protection can sense changes in the environment through its own probes, and detect abnormal execution process changes such as debugging and injection of the environment in real time, introduce debugging actions into program traps, and issue alarms, and then perform real-time updates to improve security strength. As the current leading reinforcement technology, virtual machine source code protection reinforcement will be able to provide sufficient protection for App for a long time to come.

Part 04, Conclusion

Apk hardening is a double-edged sword. On the one hand, it can protect the core code algorithm of the App, increase the difficulty of cracking/piracy/repackaging, and alleviate attacks in the form of code injection/dynamic debugging/memory injection. On the other hand, hardening changes the standard execution process and adds many protection mechanisms, which will affect compatibility, affect program operation efficiency, and increase the difficulty of App maintenance. Some application markets will refuse to list applications after being shelled. Therefore, we need to choose a balance point, not pursuing blind security, nor being too open, and protecting our own data and intellectual property rights.