I. Known protection policies

1. Indispensable confusion

Java is a cross-platform, interpreted language, Java source code compiled into a class file contains a lot of semantic variable names, method names information, easy to decompile into Java source code. To prevent this, we can obfuscate Java bytecode. Obfuscation not only protects code by turning class, field, and method names into meaningless names, but also reduces program size by removing useless classes and methods and renaming them with short names.

ProGuard consists of four steps: Shrink, Optimize, Obfuscate, and PreVerify, each of which is optional and can be configured in the script. See the official ProGuard introduction.

  • Shrink: Detects and removes unnecessary classes, fields, methods, and attributes from code.

  • Optimize: Analyze and Optimize bytecode.

  • Obfuscate: Rename classes, fields, and methods using short and meaningless names like A, B, C, and D.

The above three steps make code smaller, more efficient, and harder to reverse engineer.

  • Preveirfy: Prechecks processed code on the Java platform.

  • Optimizations and prechecks are generally turned off in Android, as shown in the following script:

-dontoptimize indicates that optimization is not performed. This option is recommended because optimization may cause some potential risks and cannot be guaranteed to work on all versions of Dalvik, as described in Proguard-Android-optimize. TXT.

-dontpreverify Indicates that preverification is not performed. This prevalidation works on The Java platform, not on Android, and can be removed to speed up obfuscation. (During apK installation, the system will check dex and optimize it into ODEX)

As protection the need for Obfuscate is Obfuscate, making it harder to read the code.

2. Verify the signature

Check the file information, such as WeChat dex file check, ali signature file check high strength safety operation First: directly in local protection, if found inconsistent signature directly to exit the application Second: carry the signature information in the request parameters involved in encryption, server signature check, failure will return an error

The Android signature mechanism can effectively prevent the installation from being overwritten after the application of the second signature. The specific mechanism is not analyzed here, but it also causes that the APK with the second signature installed cannot overwrite the APK with the normal signature installed. Therefore, it is necessary to verify the signature on the basis of the protection that is easy to be overwritten by the second signature. Of course, if it is difficult to decompile crack can be considered.

1) SO trace debugging is based on process injection technology, and then use the Linux ptrace mechanism to debug the target process

Ptrace provides a way for the parent process to monitor and control the child process. It can also change registers and kernel images in the child process, thus enabling breakpoint debugging and system call tracing

If a process is being debugged, a TracerPid field in its status file records the debugger’s process ID. You can use either of the following methods:

Check the file: /proc/[myPid]/status, read the TracerPid value, find that the value is greater than 0, exit program 2 immediately. Generally, a process can only be attached once, we will attach the process that needs to be debugged when cracking the debugging application, if we occupy the pit first, the parent process attached itself, then the following additional debugging will fail

  1. Debug status check

1. Check whether the application is in debug mode

FLAG_DEBUGGABLE = ApplicationInfo.FLAG_DEBUGGABLE = ApplicationInfo.FLAG_DEBUGGABLE = ApplicationInfo.FLAG_DEBUGGABLE = ApplicationInfo. Android: Debuggable property value, set it to true. Then you can debug.

2. Check whether the application is being debugged

With the help of a system of an API to determine: android. OS. The Debug. IsDebuggerConnected (); This is to determine whether the current application is being debugged

3. Periodically check ports

Check the TCP port usage of the device. Cat /proc/net/tcp For example, in the Frida framework, the port numbers are 27042 and 27043, and the process name is frida-server

4. Reinforcement scheme

The basic steps are as follows:

Obtain the original DEX file from the original APK file of App. 2. Encrypt the original DEX file and store the encrypted DEX file and related items in the Assert directory. Replace the dex file in the original APK file with the unhulled DEX file; The decoded DEX file has two main functions. One is to decrypt the encrypted DEX file. Second, load the decrypted dex file dynamically based on DexClassLoader. 4. Because the original APK file has been modified, you need to delete the original APK signature information, that is, delete the meta-INF directory. RSA,.SF, and manifest.mf files 5. Generate reinforced APK files 6. You need to sign the apK file after the security hardening is complete.

Dex hardening is mainly to prevent static decompilation, and then obtain the source code and modify

In addition to the protection schemes with weak service correlation, there are also protection schemes against packet capture and hook, which are closely related to services, such as transmission data encryption and anti-cheating policies.

Each of the above protection strategy has a corresponding way to crack, of course, cracking does not mean that can not be defended, protection only increases the difficulty and time of cracking, there is no eternal victory in attack and defense, someone will attack someone, the protection strategy is constantly upgrading and updating.

To fully understand Android security, you must understand the architecture of Android applications.

2. Android PacKage (APK) structure

Assets directory:

Assets directory is used to store static files that need to be packed into APK. Unlike RES, Assets directory supports subdirectories of any depth. Users can deploy the folder schema according to their own needs

Lib: Native library (so library)

Meta-inf directory:

RSA, cert. DSA, cert. SF, and manifest.mf. Cert. RSA is the signature file used by the developer to sign APK using the private key. Cert. SF, Manifest.mf records the SHA-1 hash of the file in the file

Res directory: resources for storing applications. All files in this folder are mapped to the Android project. In R file, the corresponding ID is generated. The res folder can contain multiple folders, among which anim stores animation files. Drawable directory to store image resources; The Layout directory holds layout files. The values directory holds some characteristic values, colors. XML holds color values, dimens. XML defines size values, String. XML defines string values, and styles. XML defines style objects. The XML folder holds any XML file that can be read at run time with resources.getxml (); Raw is any file that can be copied directly to the device, they do not need to be compiled.

Resources. arsc: resource configuration file, which records the mapping between resource files and resource ids and is used to search for resources based on resource ids

Androidmanifest.xml: the configuration file of the application program. When the program is packaged, the Androidmanifest.xml will be simply compiled for recognition by the Android system. The compiled format is AXML format.

Classes. dex: a traditional Java program that first compiles a Java file into a class file. The bytecode is stored in the class file, and the Java virtual machine can interpret and execute the class file. Dalvik VIRTUAL machine is optimized in Java virtual machine and executes Dalvik bytecode, which is converted from Java bytecode. In general, The Android application converts Java bytecode to Dalvik bytecode when packaged using the DX tool in the AndroidSDK. Dx tool can merge multiple class files, reorganization, optimization, can achieve the purpose of reducing the volume, shorten the running time.

For the first entry threshold of reverse is DEX. It is extremely important to understand the data structure of DEX for protection and reverse. There are many articles on dex file structure analysis, so I will not repeat them here.

At present, the last popular solution for Android protection is reinforcement. Some application markets have already bound reinforcement and shelf, indicating that the reverse difficulty of reinforcement is recognized very high.

The basic steps of reinforcement are introduced above. All the reinforcement schemes on the market are similar with little difference. The core part is encryption-parse-dynamic loading of APK/DEX, and the encryption of DEX has its own ways and algorithms. But the analysis after the giant apk found no reinforcement of dex will ponder, maybe in the client’s protection just threshold, server-side protection and anti-cheating ultimate protection strategy, and strengthening can increase the probability of collapse, as a large flow of app for one over ten thousand of the probability is very high, and for strengthening the security of dex is not the highest, So there’s a reason to give up dex reinforcement.

As an Android application developer, the Navite layer code is more challenging, and most Android developers are not familiar with C/C ++ development, so the reinforcement came into being.

Dynamic link library so:

A dynamic link library is a library that is loaded when a program runs. When a dynamic link library is installed correctly, all programs can use the dynamic link library to run programs. Dynamic link library is a collection of object files. The organization of object files in dynamic link library is formed in a special way. The addresses of functions and variables in the library are relative addresses, not absolute addresses, and their real addresses are formed when the program calling the dynamic library is loaded.

So file is based on THE ELF(Executable and Linking Format) file Format. So is a shared target file, so to encrypt the so file must understand

ELF file format:

Executable and Linking Format was originally developed and published by UNIX System Laboratories (USL), As part of the Application Binary Interface (ABI). The Tool Interface Standards (TIS) committee selected the ELF standard, which is still under development, as a portable object file format that can be used in many operating systems on 32-bit Intel architectures.

There are three types of object files:

** Relocatable File (Relocatable File).o)** Contains code and data suitable for linking with other object files to create executable files or share object files.

The Executable File contains a program suitable for execution that specifies how exec() creates a process image of a program.

The Shared Object File.so contains code and data that can be linked in both contexts. First the link editor can reposition it with others

The file and the shared object file are processed together to generate another object file. Second, the Dynamic Linker might combine it with an executable and other shared objects to create a process image.

Object files are all binary representations of programs intended to be executed directly on some processor.

ELF file format and dynamic link/static link and dynamic library/static library.

By encrypting sections and functions in SO, the reverse hardening will be much more difficult, although it is not difficult for people who know SO, such as dynamic debugging or dumping dex running in memory, so there is no absolute security, only relative attack and defense.