"Hidden espionage" -- uses NDK NativeActivity technology to implement Android reinforcement and ndknativeactivity

"Hidden espionage" -- uses NDK NativeActivity technology to implement Android reinforcement and ndknativeactivity

Recently, Baidu security lab found a new code reinforcement method used by different virus families, this code reinforcement method cleverly utilizes the NativeActivity feature provided by the Android system to deploy malicious code. Currently, the Code logic of the mainstream reinforcement solution is divided into java layer and native layer. This reinforcement method implements all native code, and the java layer does not contain any code logic. Comparison between the traditional reinforcement solution and the new reinforcement solution is as follows:
 

Mainstream Reinforcement Schemes new Reinforcement Schemes

 
 
I. Introduction
 
After Google launched the NDK (Native Development Kit), many developers using C/C ++ started to use this more efficient method for Android program Development. In Android 2.3, Google began to gradually relax the NDK function. The new NativeActivity class allows Android Developers to use C/C ++ to process the Activity lifecycle in the NDK environment. For details about the NaviteActivity development process, refer:
Http://api.apkbus.com/reference/android/app/NativeActivity.html
 
The execution logic of viruses in this development mode can be divided into two parts:
1. DEX loader libdexloader. so: Implements decryption and dynamic loading of Payload DEX files.
2. Payload DEX: executes malicious behaviors. Payload DEX is stored in the assets Directory. The method commands in DEX are encrypted.
 
The DEX loader is developed using the Android NativeActivity development mode. The NativeActivity provided by the system acts as the java endpoint of libdexloader. so to trigger the logic of libdexloader. so. Libdexloader. so:
1. Load the Payload DEX file to the memory.
2. parse the Payload DEX file and decrypt the method commands in the DEX file.
3. Load the decrypted Payload Dex data in the memory. Load these DEX data, can achieve the file system without decryption DEX files exist (Note: Memory loading is only suitable for android4.0-android4.4 version, related technology can refer to: http://blog.csdn.net/androidsecurity/article/details/9674251 ).
4. Call malicious code.

 

 
Ii. Malicious case code analysis
 
In the malicious sample family reinforced by this type of development mode, we select one of the families that steal user contacts for analysis and decompile classes. dex shows that the code for major malicious behaviors is not in classes. dex:
 

Classes. dex class structure, without any meaningful code

 

The logic of the virus is as follows:

 
 

1. Entry

This program registers "android. app. NativeActivity" in the AndroidManifest. xml file, configures the name and value of meta-data, and loads the ELF executable file as the entry:

 

After the ELF file is loaded, the entry function android_main will be executed. This function will start methods in the DexService and DexLoader classes to decrypt and load the dex file:

 

2. The file type in assets is dex. However, the ushort insns part of the method structure is encrypted and therefore cannot be loaded directly. Method instructions for encryption of the exec_post method of MainActivity:

Encrypted method command

 

3. After libdexloader. so is run, decrypt the ushort insns part of the DEX file, recombine the file into a correct DEX file, and load the file to the memory for running. Correct DEX method commands after restoration:

Restored method command

 

4. After decryption, the complete JAVA-Layer Code is obtained:

 

The analysis shows that the main behavior of the virus is to read the contact information and then send the information to the specified URL:

Read contacts and local numbers

 

Send to remote address