Shulou(Shulou.com)06/01 Report--

First, known protection strategy

1. Indispensable confusion

Java is a cross-platform, interpretive language. The class file compiled by Java source code contains a large number of semantic variable names and method names, which can be easily decompiled into Java source code. To prevent this, we can confuse Java bytecodes. Confusion can not only change class names, fields, and method names in the code into meaningless names, protect the code, but also reduce the size of the program by removing useless classes and methods and renaming classes, fields and methods 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 introduction of ProGuard.

Shrink: detects and removes useless classes, fields, methods, and properties (Attribute) from code.

Optimize: analyze and optimize bytecode.

Obfuscate: rename classes, fields, and methods with short, meaningless names like a, b, c, and d.

The above three steps make the code size smaller, more efficient, and more difficult to reverse engineer.

Preveirfy: prechecks the processed code on the java platform.

Generally speaking, the optimization and pre-check options are turned off in Android, and the script is as follows:

-dontoptimize

Indicates that there is no optimization, and this option is recommended, as described in proguard-android-optimize.txt, optimization may cause some potential risks and is not guaranteed to work properly on all versions of Dalvik.

-dontpreverify

Indicates that no pre-check is performed. This pre-check works on the Java platform, which is not needed on the Android platform, and can also be removed to speed up the confusion. (during the installation of apk, the system will check dex and optimize it to odex)

As a protection, the requirement for confusion is Obfuscate, which makes it harder to read the code.

2. Signature verification

Verify the information of various files, such as Wechat's dex file verification, Ali Juji secure signature file verification and other high-intensity operations.

First: do local protection directly, and exit the application directly if you find that the signature is inconsistent.

Second: carry the signature information to participate in the encryption in the request parameters, and the server verifies the signature. If it fails, you can return the error data.

Android's signature mechanism can effectively prevent the installation from not being covered after the application of secondary signature. The specific principle is not analyzed here, but it also leads to the installation of secondary signature apk, which cannot cover the installation of normal signature apk. Therefore, signature verification based on the protection of secondary signature is necessary. Of course, if it is difficult to be decompiled and cracked, it can be considered as appropriate.

3. Anti-debugging anomaly detection

1) so trace debugging is based on the process injection technology, and then uses the ptrace mechanism in Linux to debug the target process.

Ptrace provides a way for the parent process to monitor and control the child process, and it can also change the registers and kernel images in the child process, so it can implement breakpoint debugging and system call tracking

A feature of the ptrace mechanism is that if a process is debugged, there is a field TracerPid in the status file of his process that records the debugger's process id value. You can choose two ways:

1. Check the file: / proc/ [myPid] / status, read the value of the TracerPid field, and find that it is greater than 0, then exit the program immediately.

two。 Generally speaking, a process can only be attached once. When we crack and debug, we will attach the process that needs to be debugged. If we occupy the pit first and the parent process appends itself, then the additional debugging will fail later.

2) debugging status check

1. Check whether the application belongs to debug mode

Directly call the flag attribute in Android: ApplicationInfo.FLAG_DEBUGGABLE to determine whether it belongs to debug mode. In order to prevent the current cracker from decompiling the application in order to debug the application, add the value of the: android:debuggable attribute to AndroidManifest.xml and set it to true. Then you can debug it.

two。 Check whether the application is in debug state

Judge with the help of an api of the system: android.os.Debug.isDebuggerConnected (); this is to determine whether the current application has been debugged

3. Loop check port

Check the tcp port usage of the device cat / proc/net/tcp

For example, the Frida framework, whose port numbers are 27042 and 27043, and the process name is frida-server

4. Reinforcement scheme

The basic steps of reinforcement are as follows:

Get the original apk file from the App original dex file to encrypt the original dex file, and store the encrypted dex file and related files in the assert directory to replace the dex file in the original apk file with the shelled dex file; the shelled dex file has two main functions, one is to decrypt the encrypted dex file. Second, dynamically load the decrypted dex file based on dexclassloader because the original apk file has been modified, so it is necessary to delete the signature information of the original apk, that is, delete the .RSA, .SF and MANIFEST.MF files in the META-INF directory to generate the reinforced apk file to sign the reinforced apk file, and the apk reinforcement is completed.

The main purpose of dex reinforcement is to prevent static decompilation, and then obtain the source code and modify it.

In addition to the above protection schemes with weak business relevance, there are also protection schemes that are closely related to the business, such as anti-capture packet, anti-hook and so on, such as transmission data encryption, anti-cheating and other strategies.

Each of the above protection strategies has a corresponding way to crack. Of course, cracking does not mean it cannot be prevented. Protection only increases the difficulty and time of cracking. * there is no permanent victor, there is civil air defense if someone attacks, and the protection strategy is constantly being upgraded and updated.

To have an in-depth understanding of Android security, we must understand the structure of Android applications.

II. APK (Android PacKage) structure

Assets directory:

It is used to store static files that need to be packaged into APK. Unlike res, the assets directory supports subdirectories of any depth, and users can deploy folder architecture according to their own needs.

Lib directory:

Native library (so library) on which the program depends

META-INF directory:

The directory where the application signatures and certificates are stored. The files include CERT.RSA,CERT.DSA,CERT.SF and MANIFEST.MF, where CERT.RSA is a signature file signed by the developer using the private key to APK, and CERT.SF,MANIFEST.MF records the SHA-1 hash value of the files in the file.

Res directory:

Store the resources of the application. All files stored in this folder will be mapped to the .R files of the Android project. The corresponding ID,res folder can contain multiple folders, of which anim stores animation files, drawable directory stores image resources, and layout directory stores layout files. Values directory stores some eigenvalues, colors.xml stores color color values, dimens.xml definition size values, string.xml definition string values, styles.xml definition style objects; xml folder stores any xml file, which can be read through Resources.getXML () at run time; raw is any file that can be copied directly to the device, and they do not need to compile.

Resources.arsc:

Resource configuration file, which is used to record the mapping relationship between resource file and resource ID, and to find resources according to resource ID

AndroidManifest.xml:

The configuration file of the application, when the program is packaged, the AndroidManifest.xml will be simply compiled to facilitate the identification of the Android system, and the compiled format is in AXML format.

Classes.dex:

Dex executable file, the traditional Java program, first compiles the Java file into class file, the bytecode is saved in the class file, and the Java virtual machine can execute these class files through interpretation. The Dalvik virtual machine is optimized in the Java virtual machine to execute Dalvik bytecodes, and these Dalvik bytecodes are converted from Java bytecodes. In general, Android applications convert Java bytecodes to Dalvik bytecodes through the dx tool in AndroidSDK. Dx tool can merge, reorganize and optimize multiple class files, which can reduce the size and shorten the running time.

For the reverse first entry threshold is dex, understanding the data structure of dex is extremely important for protection and reverse, dex file structure analysis articles are very many, there is not much detail here, do not understand first to understand.

At present, the last popular scheme of Android protection is reinforcement, and some application markets have bound reinforcement to the shelf, indicating that the reverse difficulty of reinforcement is very high.

The basic steps of reinforcement are introduced above, and the reinforcement schemes on the market are more or less the same. the core part is to encrypt-parse-dynamically load apk/dex. There are different ways and algorithms for dex encryption. After understanding the structure of dex and dynamic loading, different reinforcement schemes can be analyzed concretely. However, after analyzing the apk of large factories, it is thought-provoking that there is no reinforcement of dex. Perhaps the protection of the client is only the threshold, and the protection and cheating prevention of the server is the ultimate protection strategy, and reinforcement will increase the probability of collapse. As a large traffic app, the probability of 1/10000 is also very high, and the security of dex reinforcement is not the highest, so there are signs to give up dex reinforcement.

As Android application developers, the code of the navite layer is more challenging, and most Android developers are not familiar with the development of cUnix cymbals +, so the reinforcement of so arises at the historic moment.

Dynamic link library so:

The dynamic link library is the library loaded when the program is running. when the dynamic link library is installed correctly, all programs can use the dynamic library to run the program. The dynamic link library is a collection of object files, and the organization of the target files in the 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 that calls the dynamic library loads.

So files are based on the ELF (Executable and Linking Format) file format. So is a shared target file, so if you want to encrypt so files, you must understand the ELF file format.

The executable Link format (Executable and Linking Format) was originally developed and released by the UNIX Systems Lab (UNIX System Laboratories,USL) as part of the application binary interface (Application Binary Interface,ABI). The tool Interface Standard (Tool Interface Standards,TIS) Committee has selected the developing ELF standard as a portable object file format that can be used in many operating systems on 32-bit Intel architectures.

There are three types of target files:

The relocatable file (Relocatable File) .o) contains code and data suitable for linking with other target files to create executable files or share target files.

The executable file (Executable File) .exe) contains a program suitable for execution, which specifies how exec () creates a process image of a program.

The shared object file (Shared Object File) .so) contains code and data that can be linked in both contexts. First, the link editor can process it with other relocatable files and shared object files to generate another target file. Second, the dynamic linker (Dynamic Linker) may combine it with an executable and other shared targets to create a process image.

The object files are all binary representations of the program and are intended to be executed directly on some processor.

Learn about ELF format analysis step ELF file format and dynamic link / static link and dynamic library / static library.

It is much more difficult to reinforce the reverse by encrypting the section and functions in so, although it is not difficult for people who know so, such as dynamic debugging, or dump out of the dex running in memory, so there is no absolute security, only relative *.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.