The traditional App reinforcement technology has undergone four generations of technical changes and the protection level has been improved in each generation, but its inherent security defects and compatibility problems have not been solved. And the next generation of reinforcement technology – virtual machine source protection, applicable to a wider range of code types, App protection level higher, stronger compatibility, can be called the future level of protection scheme.
(Development history of reinforcement technology)
The first generation of reinforcement technology – dynamic loading
The first generation of Android hardening technology is used to protect application logic from reverse analysis. It is widely used in malicious software and is mainly based on the dynamic loading technology provided by Java virtual machines.
The protection process is as follows:
In the development stage, the program is divided into two parts: Loader and Payload, and packaged separately.
(Development stage)
The runtime Loader runs first, unleashes Payload, and Java’s dynamic loading technology loads it and transfers control.
(Startup process)
(Core code)
Remarks (Hardening principle of Multidex) :
Android DEX files are generally small programs when they are designed, so only 65535 function references are allowed when the DEX file is designed. With the development of Android applications, a large number of application code has exceeded the limit of 65535, to solve this problem, Android5.0 native support for loading multiple dex, and for the compatibility of older versions, Android provides multidex component. The implementation principle of this component is the same as described above.
Defects and confrontations
The drawback of the first generation of hardening is that it relies on Java’s dynamic loading mechanism, which requires the Payload to be unpacked and released to the file system, giving an attacker an opportunity to retrieve the file. It can be deleted from a file system using key logic (Payload) to prevent replication, but an attacker can intercept the corresponding deletion function to prevent deletion.
However, an attacker can customize a VM to intercept key functions used by the dynamic loading mechanism and copy key logical Payload files in the file system.
The second generation of reinforcement technology – loading without landing
Compared with the first generation of reinforcement technology, the second generation of reinforcement technology in APK modification has been improved, can achieve zero interference to the development. No special treatment is required during development, only protection is required before final release. In order to achieve this zero-interference process, Loader needs to handle the life cycle of Android components well.
Main process:
1) Loader is loaded by the system.
2) The system initializes StubApplication in 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) Replace all references to StubApplication objects in the system with the original Application. This step is implemented using JAVA’s reflection mechanism. 6) Normal life cycle management of other components is carried out by Android system.
(Start process after hardening for development with zero interference)
On the other hand, the non-landing loading technology is improved on the basis of the first-generation hardening technology. It mainly solves the defect that Payload must be released to the file system (commonly known as landing) in the first-generation technology. There are two main technical solutions:
A. Intercepting system IO – related functions (such as read and write) in which transparent encryption and decryption are provided. The specific process is as follows:
Key logic Payload is stored in the APK in encrypted form.
2) The runtime load part sends the Payload to the file system. At this time, the Payload is encrypted.
3) Load part intercept corresponding system IO functions (read, write, etc.).
4) The Loading part invokes the Java dynamic loading mechanism normally. Because the I/O part of the VM is intercepted, the VM reads the decrypted key logic Payload.
(Transparent encryption and decryption scheme process)
B. Directly call the function provided by the VM to load the vm without landing. The specific process is as follows:
Key logic Payload is stored in the APK in encrypted form.
2) The runtime loads the Payload into the memory.
3) The load part invokes the internal interface of the VM for loading.
(Loading process without landing)
The key system functions are as follows:
compatibility
The transparent encryption scheme of scheme A uses inline hook or got hook to intercept IO functions of the system, which brings compatibility problems
The non-landing loading scheme of scheme B has compatibility problems because it needs to call the internal interface of the system, but this interface is not exported, and various manufacturers have their own customized modifications during implementation.
Defects and confrontations
The second generation of hardening technology has to deal with a large number of encryption and decryption loading operations when the application is started, resulting in suspended animation (black screen) for a long time and poor user experience.
There is no essential difference in the implementation of reinforcement technology. Although it can prevent the defect that the first generation of reinforcement technical files must be copied, it can also be fought from the following aspects:
For example, the DEX header in memory is cleared to prevent it from being found in the dump file. The DEX file structure is damaged. For example, some incorrect data is added, which increases the recovery cost.
After the Payload is loaded, the Payload is continuous in the memory. After debugging tools such as GDB are used to dump the memory, the Payload can be directly found. After simple processing, 100% of the Payload file can be recovered.
As with the first generation of hardening technology, it does not work against custom VMS without landing loads. The Payload can be recovered by intercepting the above key functions and writing out the corresponding memory segment. Note that since IO related functions are intercepted, it is not possible to directly call read/write functions for direct reads and writes. You need to use syscall functions to bypass this.
Although manufacturers may implement the above functions themselves to bypass the above function interception. However, the Android class loader must be able to find the appropriate structure for normal execution. An attacker can use the class loader as a starting point to find the location of the corresponding Payload in memory.
The third generation of reinforcement technology – command extraction
Because second-generation hardening only encrypts the file level, the problem is that the Payload in memory is continuous and can be easily accessed by an attacker. The third generation of hardening technology improves this part and reduces the protection level to functional level.
The main process is as follows: In the release stage, the function contents (Code Item) in the original DEX will be cleared and separately removed to a file.
(Release stage)
The run phase restores the function contents to the corresponding function body. The timing of recovery can be done in several ways:
A. Restore the function contents to the memory area where the DEX shell resides after loading
(Operation stage)
B. Restore the function content to the internal structure of the VIRTUAL machine after loading: after the VIRTUAL machine reads the DEX file, there is an internal structure for each function, and there is a pointer to the function content (CodeItem) on this structure. The corresponding function content can be modified by modifying this pointer.
C. Intercept functions related to searching for executing codes in the VM and return the function content.
compatibility
The instruction extraction technique uses a lot of virtual internals and undocumented features, which, combined with Android’s complex vendor customization, creates a lot of compatibility issues.
Defects and confrontations
Some schemes of instruction extraction technology conflict with JIT performance optimization of virtual machines and cannot achieve optimal performance. The Java virtual machine is still used to execute the function content. An attacker can customize the Android VIRTUAL machine to record the contents of a function (CodeItem) in the interpreter code. The next step is to iterate over all functions to get the full function content. Eventually reassembled into a complete DEX file. There are already automated tools that can dictate the removal of the shell in the extraction technology.
(Unshell process of third-generation hardened DEX files)
Fourth generation reinforcement technology – instruction conversion /VMP
The third generation of hardening protects at the functional level, using the Android virtual machine interpreter to execute code that may cause defects to be recorded, and the fourth generation of hardening uses its own interpreter to avoid the third generation of defects. The custom interpreter cannot call other functions in the Android system directly, and must use the JAVA JNI interface to call. There are two main implementations:
Functions in the A. dex file are marked as native, and the content is extracted and converted into a dynamic library that meets JNI requirements. The dynamic library interacts with the Android system through JNI.
The function in b. Dex file is marked as native, and the content is extracted and converted into A custom instruction format, which is executed with A custom receiver and needs to be called by JNI and Android system just like A.
compatibility
The fourth generation VMP hardening technology is generally used in conjunction with the third generation hardening technology, so all the compatibility issues of the third generation, instruction conversion /VMP hardening also exist.
Defects and confrontations
No matter use instruction transformation/VMP reinforcement plan A or plan B, it must provide A JNI interface through the virtual machine and virtual machine interaction, an attacker can directly transfer instructions/VMP reinforcement scheme as A black box, with custom JNI interface object, to detect, record and analysis was carried out on the black box inside, and then get complete DEX program.
(DEX file restoration for the fourth generation hardening)
In addition, the fourth generation OF VMP reinforcement technology only realizes Java code protection, does not use VMP technology to protect C/C++ and other codes, security protection ability is insufficient.
Next generation hardening technology – virtual machine source protection
With the fourth generation of VMP reinforcement technology, virtual machine source protection reinforcement is to use virtual machine technology to protect all code, including Java, Kotlin, C/C++, Objective-C, Swift and other code, with high compatibility; Make App get higher security level protection, more stable operation.
Virtual machine source protection provides users with a complete set of tool-chains, which first compile the core code to be protected by the user into intermediate binary files, and then generate a unique virtual machine source protection execution environment and running programs that can only be executed in this environment.
The virtual machine source protection will isolate a separate execution environment within the App in which the core code runs. Even if the App itself is cracked, this core code remains invisible.
(Virtual machine source code protection and reinforcement process)
The virtual machine source protection has a unique variable instruction set, greatly improving the difficulty of instruction tracking, reverse analysis. At the same time, virtual machine source protection also provides anti – debugging capabilities and monitoring capabilities. Virtual machine source protection can sense the change of the environment through its probe, real-time detection of the environment of the outside debugging, injection and other abnormal execution process changes, debugging action into the program trap, and alarm, and then real-time update, improve security intensity.
Strengthening technology development and change of attack-defense, rising along with the Internet technology development, we are convinced that the evil can’t win, while the virtual machine source protection as the leading technology, reinforcement is obtained in the future for a long time, can provide enough strength to protect for App, the escort for the business development of enterprise and developer.