Why will App be broken -jie invasion

With the popularization and popularization of hacker technology, App, an important tool to carry our mobile digital work and life, is not only fat meat in the eyes of hackers, but also attracts more netizens’ attention. A Baidu search for “app-jie” has 52.9 million results.

The development of Android App adopts C/C++ coding for some functions, and the rest mainly adopts Java coding to develop functions. The Java source code is eventually compiled into the SMALI character code and stored in the APK of the App as classes.dex.

Java is an interpreted language, powerful and easy to use. Beginners can easily learn Java and write simple applications. And Java’s basic class library (JDK) is open source, which makes many Applications developed in Java reverse broken -jie threshold is very low. At present, there are a large number of reverse break -jie tools on the market, such as: Dex2Jar, JEB, JD-GUI and so on. As long as you understand code programming, you can use these tools to break the weak defense on the market, there are a lot of security vulnerabilities of the App. It is easy to understand why so many people search for “app-jie”.

There have been media reports before, there are network black products specifically from a variety of channels to find the App APK, and then the APK file reverse broken -jie, and then implanted advertising, virus code, and finally repackaged into the open market, when the truth of the unknown users will be with the virus advertising App download, will bring huge economic losses.

Development history of reinforcement technology

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 new 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.

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.

Protect the process

The development phase

In the development stage, the program is divided into two parts: Loader and Payload, and packaged separately.

Start the process

The runtime Loader runs first, unleashes Payload, and Java’s dynamic loading technology loads it and transfers control.

Core code:

note

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.

Protect the 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.

Post-hardening startup process for development with zero interference:

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:

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.

Protect the process

Release phase

In the release stage, the function contents (Code Item) in the original DEX will be cleared and separately removed to a file.

Operation phase

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

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.

The process for removing DEX files of the third generation is as follows:

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.

Protect the process

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:

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.

A new generation of reinforcement 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.

Protect the process

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 broken -jie, this part of the core code is still not visible.

Virtual machine source code protection and reinforcement process:

Against the advantages

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.

— — — — — — — —

For those of you who need reinforcement, see here:

Android application hardening: https://www.dingxiang-inc.com/business/stee

IOS App Hardening:www.dingxiang-inc.com/business/io…