"Stealth Spy"--using NDK nativeactivity technology for Android hardening

Recently, Baidu Security Laboratory found a new type of code to be used by different virus families to strengthen the way, the code to strengthen the way cleverly using the nativeactivity features provided by the Android system to complete the solution of malicious code. At present, the mainstream reinforcement scheme code logic is divided into Java layer and native layer two parts. This kind of reinforcement implements the full native of the code, and the Java layer does not contain any code logic. The following is a comparison between the traditional reinforcement scheme and the new reinforcement scheme:

New reinforcement scheme of mainstream reinforcement scheme

First, Introduction

After Google introduced the NDK (Native development Kit), many developers using C/D + + began to use this more efficient way to develop Android programs. In Android 2.3, Google began to gradually loosen the NDK functionality, and the new Nativeactivity class allowed Android developers to use C + + to process activity lifecycles in the NDK environment. Specific naviteactivity development process can be viewed:
Http://api.apkbus.com/reference/android/app/NativeActivity.html

Using the development model of the virus, the execution logic can be divided into two parts:
1, Dex loader libdexloader.so: Implement payload Dex file decryption, dynamic loading.
2. Payload DEX: Perform specific malicious acts. Payload Dex exists in the assets directory, where the method directives in Dex are processed encrypted.

One of the Dex loaders is developed using the Android nativeactivity development model. The system-provided nativeactivity triggers libdexloader.so logic as the Java-side entry point for libdexloader.so. The libdexloader.so execution process is:
1. Load payload dex file into memory.
2. Parse the payload Dex file and decrypt the method instructions in the Dex file.
3, Memory load decrypted payload dex data. Load these DEX data, can do the file system without decryption Dex file exists (note: Memory load 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.

Second, malicious case Code Analysis

In a malicious sample family that is hardened with this type of development pattern, we select one of the families that steals the user's contacts for analysis, and the anti-compilation classes.dex is visible, and the code for the main malicious behavior is not in Classes.dex:

Classes.dex's class structure, which does not contain any meaningful code

While actually running, the virus's logic is as follows:

1. Entrance

The program registers "Android.app.NativeActivity" in the Androidmanifest.xml file and configures the value of the name and value of Meta-data to load the elf executable as a portal:

After the elf file is loaded, the entry function android_main is executed, which initiates the decryption and loading of the Dex file by methods in the Dexservice and Dexloader classes:

2. The file type in assets is Dex, but in fact, the ushort Insns part of the method structure is encrypted and cannot be loaded directly. Method directives that are encrypted for the Exec_post method of the Mainactivity:

Encrypted method directives

3, libdexloader.so after running, the Dex file ushort Insns partially decrypted, and re-synthesized a correct Dex file, and then loaded into memory run. Method directives for the correct Dex after the restore:

Post-Restore Method directives

4. After decryption, we draw the complete Java layer code:

Analysis shows that the main behavior of the virus is to read the contact information, and then send this information to the specified URL:

Read contacts and native numbers

Send to remote address

"Stealth Spy"--using NDK nativeactivity technology for Android hardening