Love encryption Android APk principle analysis

Love encryption Android APK shell principle Analysis

first, what is the Packers?

Packers are a piece of code that is implanted in a binary program, giving priority to the control of the program at run time and doing some extra work. Most viruses are based on this principle. The process of adding a shell to a PC EXE file is as follows:

second, the role of adding shells

Shell procedures can effectively prevent the disassembly of the program analysis, in order to achieve its ulterior purpose. This technique is also used to protect software copyrights and prevent software from being cracked.

Third, Android Dex file Shell principle

The PC platform now has a large number of standard shell and shell tools, but Android as an emerging platform has not yet appeared apk shell tool. Android Dex files use a lot of references to add a certain degree of difficulty, but in theory, Android APK Shell is also feasible.

In this process, three characters are involved:

1. Shell procedure: Encrypt the source program to solve the shell data, assemble and unpack the shell data

2, the shell program: Decrypt the shell data, and the runtime through the Dexclassloader dynamic loading

3. SOURCE program: Protected code requiring shell handling

Based on the different distributions of the shell data in the shell program Dex file, this paper presents two implementations of the Android Dex Packers

Case.

(a) The shell data is located at the end of the unpacking program file

This kind of method is simple and practical, the combined Dex file structure is as follows.

Shell procedure Workflow:

1. Encrypt source program apk file for Shell data

2, the shell data is written to the end of the shell program Dex file, and add the size of the shell data at the tail of the file.

3. Modify the checksum, signature and File_size header information in the Shell program Dex header.

4, modify the source program Androidmainfest.xml file and overwrite the shell program Androidmainfest.xml file.

Workflow for the Shell Dex program:

1. Read the end data of Dex file to get backdoor data length.

2. Read the shell data from the Dex file and decrypt the shell data. Save the decrypted data as a file to a. APK file

3, dynamic loading a.apk through Dexclassloader.

(ii) The shell data is located in the Unpacking program file header

This approach is relatively complex and the combined Dex file structure is as follows:

Shell procedure Workflow:

1. Encrypt source program apk file for Shell data

2. Calculate the length of the shell data and add the length to the end of the shell Dex file header and continue to unpack the data to the end of the file header.

(The location where the data is inserted is 0x70)

3, modify the shell program Dex Head Checksum, signature, file_size, Header_size, String_ids_off, Type_ids_off, Proto_ids_off, Field_ids_off,

Method_ids_off, Class_defs_off, and Data_off related items. Analyze Map_off data and modify the associated data offset.

4, modify the source program Androidmainfest.xml file and overwrite the shell program Androidmainfest.xml file.

Workflow for the Shell Dex program:

1. Read the data length of the shell from the 0x70.

2. Read the shell data from the Dex file and decrypt the shell data. Save the decrypted data as a file to a. APK

3, dynamic loading a.apk through Dexclassloader.

Love encryption Implementation steps:

1. Encrypt the original Classex.dex with an unknown encryption algorithm to Assets/ijiami.dat

2. Replace the pre-written JNI code with the corresponding Classex.dex to the original location

3. After the program is installed, run the Love encryption shell program , and dynamically load the original Classex.dex code in the JNI, in order to achieve the purpose of shell protection.

4. Source Classex.dex hidden, in the static time there is no way to crack it.

5. As for the dynamic operation, it is best to work in your own code. such as memory encryption.

APK Advanced Protection Method (i)

Run-time validation run-time validation, mainly refers to the code when the start of the local acquisition of signature information, and then verify the signature information to determine whether their own application is genuine, if the signature information is not genuine is to suggest piracy or crash directly.

Its principle: the only identity of the APK is based on the package name + signature, the package name information is written to die in the Android manifest.xml, but the signature is tied to the APK, once the APK is anti-compiled signature will automatically disappear. The signature of the APK requires a signature file, and the MD5 value of the signature file is basically not forged.

The method of signature verification can also be subdivided into 3 types:

1) Java Layer Validation

The methods for obtaining signature information and authentication are written on the Java layer of Android. This protection method of protection is not significant, because after the source code is compiled by the keyword search will soon be able to find a block of verification, a slight modification of this verification protection is completely invalid.

2) Server Authentication

At the Java layer of Android, the signature information is obtained, the upload server signs the service and returns the verification result. This protection is not as useful in pure Java layer validation as it does without network authentication protection. The signature information obtained by using the Android method can also be obtained by using Java method, the verification is stored on the server is also to protect the correct signature information value, but the meaning of protection does not have any effect, the same crack after the global search keyword and then forge a correct signature information can be perfectly cracked.

3) NDK technology bottom-up for signature and verification

The signature information is obtained and verified at the bottom by taking one of the Context,activity,packagemanager,packageinfo four objects as a parameter to the bottom. Because the method of acquiring and validating is enclosed in a more secure so library, it can play a certain role in protection. However, this protection can be perfectly cracked by the Java Layer Hook technology. But the significance and value of this protection is even greater compared to the first two.

4) Love encryption app security

It uses fingerprint verification to protect the files in the APK, and all files in the APK will have a unique fingerprint. Each time the APK is run, the internal fingerprint will be generated again, if the resulting fingerprint and the original fingerprint is not the same, it is judged to be two times packaged apk, the program will automatically exit or crash directly. This method can prevent the resource files, the main configuration files from being modified or deleted, so as to guarantee the APK security completely.

APK Advanced Protection The second Method--folder Confusion (ii)

Folder confusion mainly refers to the use of Windows,linux,android three system Environment folder name of the particularity to confuse the source folder, so that the confusing folder in window seems to lose the original logic, but does not affect its operation on the Android system.

The principle is that the name of the folder under Windows and Linux is not case-sensitive, but it is case-sensitive in Android: 2 is a special symbol in Linux, So the folder name added in. 2 is ignored, but Windows. 2 is a very common string.

How to: Decompile the completed apk, find the last folder in the package directory (for example: package name is com.example.test2222, find the folder where test2222 is located), Modify the test2222 folder name to test2222.2 and create the folder Test2222, then feel free to store a valid Smali file inside the Test2222, then rewrite the package into the APK signature. Such as:

This method can achieve a good protection, but developers generally do not have the extra time and energy to do the reinforcement protection. Basic time, technology and other reasons, love encryption for the APK developer to provide free technical support, the APK shell hidden source code, thereby preventing the anti-compilation. It can be two-time signature protection of XML main files, protect so files from being cracked and applied, and can protect the APK from being packaged two times!

The Third Way--Flower instruction

Flower instructions are some of the instructions in the program, specially conceived by the designer, hoping to make the disassembly error, so that the cracker can not clearly and correctly disassemble the contents of the program, lost direction. The word "flower instruction" is derived from assembly language, and its thought is very good, and its other purpose is to use the Anti-compilation tool vulnerability to make the tool unusable.

Next, we'll make the "flower instruction" in the Java code so that the Anti-compilation tool (Jd-gui) cannot decompile and query your Java code. Jd-gui Bug actually quite a lot of, many special code block or field set can let it crash cannot decompile source code.

Like what:

private static final char[] WJ = "0123456789abcdef". ToCharArray ();

public static String IMSI = "204046330839890";

public static String p = "0";

public static string keyword = "phone";p ublic static string Tranlatekeyword = "%e7%94%b5%e8%af%9d";

By adding the above fields to each class, you will find the following result of the anti-compilation class being viewed through Jd-gui:

Let's look at love. Encryption three layer protection technology, namely Dex shell Protection, DEX instruction dynamic load protection, advanced obfuscation protection, can ensure the dynamic security and static security of the app, hackers will not have the opportunity to do any hack.

After the encrypted apk we decompile to see if there is any effect!

Love encryption Android APk principle analysis