I. Introduction
With more and more cases of Android applications being cracked and pirated, program security has gradually attracted the attention of users.
In the fierce attack and defense process, security protection methods are not limited to code, but also resource files. This is because the resource files will expose a lot of sensitive information and cracking clues, once tampered or deleted, the program will not run normally.
Reinforcement is one of the important ways to protect the security of the program, and it is also an inevitable requirement for the program to be released in compliance. This article simply sorts out the resource protection (encryption) scheme of the third-party apk to help users better choose and use hardened products.
2. Introduction to resource files
Let's take a look at the explanation of the resource file first. Android resource files generally refer to files under the res and assets directories, and there are certain differences between res and assets resource files in the process of apk compilation and running.
1. res resources
The res directory can only have one layer of subdirectories, and the subdirectories must be predefined, such as res/layout, res/values, etc.
res will generate an index ID in R.java, and unused resources will not be packaged into the apk, except for the res/raw folder.
res is accessed with getResource().
2. assets resources
The assets resource directory can be customized.
The assets resource will be packaged into the apk intact.
Assets are accessed with AssetsManager.
3. Resource file protection scheme
If the packaged apk needs resource encryption, it can only be decrypted through the hook-related function interface during the running process to achieve the protection effect. Resource file protection schemes on the market can be divided into two categories: custom schemes and general schemes. Both options have pros and cons.
1. # Customized Plan #
Custom solutions can be used in various scenarios, and are generally classified according to file types, including scripts and resources. Among them, scripts such as js, lua, and python are encrypted according to different script engines, and at the same time, they are re-parsed and decrypted by using hooks or rewriting the interpreter, while resources such as u3d resources, png, jpg images, etc. may involve resource reading. The encryption method can be selected or based on the image format. After encryption, it needs to be decrypted at a specific time.
# advantage #
a. Highly targeted, only for special types of files, such as js, lua scripts, u3d resources
b. Good compatibility
c. Good performance
# shortcoming#
a. The scope of protection is small
b. Each type of resource needs to analyze the loading principle, and the cost of development and maintenance is high
2. # General Scheme #
# advantage #
a. Wide range of protection
b. Low maintenance cost
# shortcoming#
a. Compatibility cannot be fully guaranteed
b. Difficult to develop
c. Low performance
Since each type of customized protection scheme can be introduced as a separate topic, it cannot be explained simply through a document. The following mainly introduces the implementation and difficulty analysis of general resource protection schemes.
4. General plan
(1) Implementation principle
The apk is essentially a zip format file, and reading the resource file means reading the file in the zip. Therefore, its principle is inseparable from the two processes of reading files and decompressing. If you can hook in the process of reading files or decompressing them, and decrypt the contents of the files, you can achieve the effect of resource protection. Simply speaking, one is for hooking libz.so, and the other is for hooking libc.so.
1、Libz hook
(1) # Advantages #
a. Use standard api, stable features, easy to hook
b. The processing is only limited to libz.so to achieve the goal, simple and efficient
c. Using got hook, the function is stable
(2) # Disadvantages #
a. The user code must meet the compressed data, use the uncompress function in libz to decompress and read the data
b. The third-party sdk or game engine may not meet the conditions of use because libz is statically compiled into so
2、Libc hook
(1) # Advantages #
a. The range of hooks is wide, adapting to more scenarios
(2) # Disadvantages #
a. A full range of hooks will lead to performance degradation
b. Using inline hook may cause compatibility issues
In terms of versatility, the hook libc solution can be compatible with more user scenarios, but as long as users use standard interfaces and do not customize or use third-party unclear SDKs for resource reading, hook libz can also adapt to most resource read.
(2) Difficulty analysis of the general scheme
1. # Four Conditions #
For developers of the hardening function, the premise of developing the resource hardening function is that the resource reading process can be hooked, otherwise the file cannot be decrypted at the right time. It can be seen that when users choose to do resource protection, they need to determine whether the following four conditions are met. The following conditions all revolve around a core, that is, the process of the program reading the resources of the apk needs to be hooked. If the conditions are met, it is theoretically feasible to use common means to protect resource files.
# No third-party sdk is used to read resources, there may be uncertain privacy
# Self-developed so not self-implemented decompression method
# Implement the decompression method in the self-developed so, and directly read the apk through libc
#The decompression method is implemented in the self-developed so, no so reinforcement is done, and the so structure in the memory is complete
2. # Three Questions #
While the user apk implementation meets the above rules, resource encryption also needs to solve the following problems:
(1) # How to encrypt and decrypt files
Answer: The encryption and decryption methods of the file affect the structure of the apk after hardening. It is necessary to define a set of encryption rules to ensure the integrity of the encrypted zip format and the integrity of the decrypted file.
(2) # Check if the decompressed file exists
Answer: Because the zip header of the apk stores the crc and length of the decompressed file, you need to consider whether the crc and length need to be verified after the file is decrypted in some cases.
(3) # How to be compatible with various models in the case of serious fragmentation of Android
Answer: It is necessary to consider the implementation changes of libc and libz under the Android system under different versions to ensure compatibility.
3. # Four types of incompatibility #
It is worth noting that some incompatibilities still exist for functions that perform decryption operations in memory. Here are a few common incompatibility issues.
(1) # Self-developed so realizes the zip decompression method, and uses assembly to read files
Answer: In this case, there is no obvious hook feature, and the file cannot be decrypted normally.
(2) # The user so implements zip decompression, and uses so reinforcement to destroy the memory structure of so
Answer: Under the premise of hooking so, destroying the so structure may not be able to hook and decrypt.
(3) # After the user reinforces the resources, the hot update mechanism is to read the apk package on the server side and compare the hash with the apk read from the memory
Answer: One of the most important effects of resource encryption is that it cannot be analyzed statically, that is, third-party tools will read the ciphertext when reading the apk. However, the apk read in the memory is plain text, which will inevitably cause the file to fail to be verified normally.
(4) # res resources are complex because of their types, and include package names and icon files
Answer: These files need to be read by the system, not decrypted by the apk runtime. Before encryption, it is necessary to filter out which files cannot be encrypted.
V. Conclusion
To sum up, Android programs still face some preparatory work before promoting resource protection, such as checking whether conditions are met and whether there are related problems.
When protecting resources, try to achieve the following two points based on your own product conditions: First, pertinence, resources are related to products, and all resources should not be encrypted blindly, and appropriate reinforcement solutions should be selected based on product characteristics. The second is controllability, standardizing the way of reading and writing resources, and using third-party frameworks to read and write resources may cause compatibility problems.
Program software risk incidents occur frequently. In the process of implementing hardening protection, the importance of giving priority to the protection of resource files is self-evident.