Efficient and accurate confusion method for Android compilation period
By using Gradle compilation processing technology during the Android APK packaging process, creating a new Class inherited from the original class and modifying the referenced class to its subclass, the problem of not supporting obfuscation of Application classes, four major components and custom View classes during the Android APK packaging process is solved, and efficient and precise obfuscation of these classes is achieved, improving the security of the application.
Patent Information
- Application Number
- CN202411682297.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-22
- Publication Date
- 2025-03-14
AI Technical Summary
During the Android APK packaging process, it is not supported to obfuscate the Application class, four major components and custom View class referenced in the AndroidManifest.xml and layout XML file, resulting in these class names being unable to participate in obfuscation processing, reducing the security of the application.
By creating a new Class inherited from the original class during the compilation period, and modifying the original reference class to its subclass, including references in Class, references in AndroidManifest.xml and references in Layout, the Gradle compilation period technology uses the technology of processing Class and XML files to achieve obfuscation of Application, the four major components and custom Views.
It effectively solves the problem that Android obfuscation does not support the obfuscation of the four major component classes, Application, and custom View classes. It supports Gradle plug-in versions 4.0+~7.0+, does not interfere with the obfuscation process, and does not increase the package size or retain useless code.
Smart Images
Figure CN119621067A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of Android compilation, and more specifically, particularly relates to an efficient and accurate obfuscation method during Android compilation. Background Art
[0002] In the process of packaging an Android application into an APK installation package, the Class files in the source code will be obfuscated. The main purpose of obfuscation is to reduce the size of the application by shortening the names of classes, methods, and fields, and to increase the difficulty of reverse engineering to improve the security of the application. However, Android's default obfuscation behavior retains the Application class referenced in AndroidManifest.xml (Android manifest file), the four major components (including Activity, Service, ContentProvider, and BroadcastReceiver), and the custom View referenced in the layout XML file, which makes these class names unable to participate in the obfuscation process.
[0003] The technical problem solved by the present invention is that the Android APK packaging process does not support obfuscation of the related classes referenced in the AndroidManifest.xml and layout XML files. In order to solve this problem, the inventor proposes a technical solution to achieve obfuscation processing of Application, four major components and custom View.
[0004] When packaging an Android application into an APK installation package, after enabling the obfuscation function, the system will obfuscate the class by default. However, Android's default obfuscation mechanism does not support obfuscation of the Application class, the four major components, and custom Views. In daily development, the names of these classes are usually highly readable, and attackers can quickly identify the key code logic of the corresponding function by decompiling the APK, thereby reducing the difficulty of reverse attacks.
[0005] The current obfuscation technology mainly processes Class bytecodes. It only obfuscates Classes, but cannot automatically replace class names referenced in AndroidManifest.xml (Android manifest file) and layout XML files. Therefore, in the following cases, if the obfuscated class name is different from the class name referenced in the XML file, it may cause runtime errors:
[0006] ·Application: Create an instance by loading the application node declared in AndroidManifest.xml. ·Four major components: When starting, it will check whether the component Class to be started is declared in AndroidManifest.xml.
[0007] Custom View: The instantiation process is to create an instance of the class in the layout file.
[0008] If the above class names are obfuscated and the class names referenced in the XML file are not updated synchronously, the corresponding classes cannot be found when the Application and custom View are instantiated, and errors will occur in which the four major components are not declared in AndroidManifest.xml. Summary of the invention
[0009] In order to solve the above technical problems, the present invention provides an efficient and accurate obfuscation method during Android compilation to solve the above problems.
[0010] An efficient and accurate obfuscation method for Android compile time, including a technology based on Gradle compile time to process Class and XML file obfuscation. A Class inherited from the original class is created during compile time. The Class is named according to custom rules, and the original reference class is modified to be its subclass, including references in Class, AndroidManifest.xml and layout Layout. It can effectively solve the problem that Android obfuscation does not support obfuscation of the four major component classes, Applicaiton, and custom view class. The supported Gradle plug-in versions are: 4.0+~7.0+.
[0011] Preferably, an obfuscation filtering rule file is configured, and a custom configuration rule file is configured according to the App, wherein the rule file includes all classes under a specific package name and specific classes that are not obfuscated, and a custom Plugin is created, wherein the content of the custom Plugin includes: registering the four major components in AndroidManifest.xml, Application scanning and obfuscation tasks, and registering scanning and obfuscation tasks for custom Views in layout layout; registering Class bytecode editing tasks, registering a custom Task to be inserted after the Gradle compilation task process${variant}Manifest is completed to parse Application and confuse AndroidManifest.xml, registering a custom task to be inserted between the Gradle compilation tasks merge${variant}Resources and process${variant}Resources to parse and confuse custom Views in layout, and registering a custom Transform to confuse the Classes corresponding to Application, the four major components, and custom Views.
[0012] Preferably, Applicaiton and the four major components in AndroidManifest.xml are obfuscated, Application and the four major components are parsed, and after the apk packaging task is executed, after the gradle compilation task process$(variant}Manifest is executed, a merged AndroidManifest.xml file is generated, AndroidManifest.xml is obfuscated, and the filtered class name is modified by DOM to obfuscate the class name, and the modified content is output to the merged AndroidManifest file, and the original layout file corresponding to the compiled layout is obtained. After the gradle compilation task merge${variant}Resources is executed, a binary layout file compiled by layout is generated, and all binary layout files compiled by aapt2 are found by matching rules. The compiled binary layout file is parsed with the aapt2 tool provided by didibooster, and the original layout file corresponding to the compiled layout file is obtained. The layout layout file is parsed, and the custom View is obtained and obfuscated. All layout files are parsed by Dom, and the custom View used in the layout is obtained. According to the rules described in the first step, the specified custom View is filtered, and the obfuscation operation is performed on the filtered custom View, and the mapping between the original class name and the obfuscated class name is saved.
[0013] Preferably, confuse the layout file, use a string to replace the custom View class name in the original layout with the obfuscated class name, output the modified content to the original layout file, compile the layout file, use the aapt2 compilation command to recompile the obfuscated layout file, and replace the binary layout file in the output directory of merge${variant}Resources, confuse the Applicaiton, the four major components, and the Class corresponding to the custom View, and insert a custom gradle in the process of compiling from class to dex Transform edits the Class bytecode. The bytecode editing technology used is ASM. It modifies the class reference (including class constant reference and complete class name reference), traverses the classes that the project depends on, and modifies the class references of the four major components, Application, and custom View in the class to the obfuscated class references. Specifically, it uses ASM to modify the visitLdcInsn implementation in MethodVistor, generates obfuscated subclasses of the four major components, Application, and custom View, and uses the obfuscation mapping rules generated in the third and fourth steps to generate a subclass inherited from the original class with ASM. The subclass name is the obfuscated class name, and the modified binary class is output to the specified class file. After the subsequent Android packaging and compilation steps, the apk after successful obfuscation is output.
[0014] Compared with the prior art, the present invention has the following beneficial effects:
[0015] 1. The present invention will not interfere with the obfuscation process, does not require additional obfuscation rule configuration, and will not increase the package size or retain useless code.
[0016] 2. The present invention supports unified configuration of obfuscation class name rules, thereby simplifying the configuration process of special obfuscation rules. BRIEF DESCRIPTION OF THE DRAWINGS
[0017] Figure 1 It is the overall process system framework diagram of the present invention;
[0018] Figure 2 This is a system framework diagram of the compilation task process${variant}Manifest of the present invention;
[0019] Figure 3 This is the system framework diagram of the compilation task merge${variant}Resources of the present invention;
[0020] Figure 4 It is a framework diagram of the registered custom Transform system of the present invention. DETAILED DESCRIPTION
[0021] The following embodiments of the present invention are described in further detail in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the present invention, but are not intended to limit the scope of the present invention.
[0022] See also Figure 1-Figure 4 The present invention provides an efficient and accurate obfuscation method for Android compile time, including a technology based on gradle compile time to process Class and XML file obfuscation. The specific implementation principle is to create a Class inherited from the original class during compile time, and the Class is named according to custom rules. At the same time, the original reference class is modified to be its subclass, including references in Class, AndroidManifest.xml and layout Layout. It can effectively solve the problem that Android obfuscation does not support obfuscation of the four major component classes, Applicaiton, and custom view class. The supported Gradle plug-in versions are: 4.0+~7.0+. The overall process is as follows: Figure 1 ;
[0023] The specific steps are as follows:
[0024] The first step is to configure the obfuscation filtering rule file. According to the App configuration, a custom configuration rule file is configured, and the rule file includes all classes under a specific package name and specific classes that are not obfuscated.
[0025] The rule format is:
[0026] 1. Ignore the specified class: com.example.proguard.test.MainActivity, then com.example.proguard.test.MainActivity will not be obfuscated.
[0027] 2. Ignore all classes under com.example.proguard.test, ignore the first-level class: com.example.proguard.test, then com.example.proguard.test.MainActivity will not be obfuscated.
[0028] Ignore the secondary class: com.example.proguard.test.*, then com.example.proguard.test.activity.MainActivity will not be obfuscated.
[0029] Ignore classes greater than or equal to level three: com.example.proguard.test.**, then com.example.proguard.test.activity.main.MainActivity will not be obfuscated.
[0030] The second step is to create a custom plugin. The content of this custom plugin includes: registering the four major components in AndroidManifest.xml, Application scanning and obfuscation tasks; registering scanning and obfuscation tasks for custom Views in layouts; and registering Class bytecode editing tasks.
[0031] 2.1 Register a custom Task and insert it into the Gradle compilation task process${variant}Manifest to parse the Application and confuse AndroidManifest.xml.
[0032] 2.2 Register a custom task and insert it between the Gradle compilation tasks merge${variant}Resources and process${variant}Resources to parse and obfuscate the custom View in the layout.
[0033] 2.3 Register a custom Transform. Confuse the Class corresponding to the Application, the four major components, and the custom View.
[0034] The third step is to confuse the Applicaiton and four major components in AndroidManifest.xml. The specific steps include:
[0035] 3.1 Parse Application and four major components. After executing the apk packaging task, after the gradle compilation task process$(variant}Manifest is executed, the merged AndroidManifest.xml file is generated. The specific path of the file is:
[0036] project / app / build / intermediates / packaged_manifests / ${variant.name} / AndroidManifest.xml. The custom Task uses DOM (Document Object Model) to parse the file, collect the Applicaiton and four major component class names, filter the specified classes according to the rules described in the first step, generate obfuscated class names for the filtered classes, and save the mapping between the original class names and the obfuscated class names.
[0037] 3.2 Obfuscate AndroidManifest.xml. Use DOM to modify the filtered class name to obfuscate the class name, and output the modified content to the merged AndroidManifest file.
[0038] The fourth step is to confuse the custom View in the layout. The specific steps include:
[0039] 4.1 Get the original layout file corresponding to the compiled layout. After the gradle compilation task merge${variant}Resources is executed, the compiled binary layout file of the layout will be generated. The file path is: project / app / build / intermediates / res / merged / ${variant.flavorName} / ${buildType.name}. Use the matching rules to find all binary layout files compiled by aapt2, and use the aapt2 tool provided by didibooster to parse the compiled binary layout file to obtain the original layout file corresponding to the compiled layout file.
[0040] Note: The matching rule specifically means that the file name of the binary file starts with layout- and ends with .xml.flat.
[0041] 4.2 Parse the layout file, obtain and obfuscate the custom View. Use Dom to parse all layout files, obtain the custom View used in the layout, filter the specified custom View according to the rules described in the first step, perform obfuscation on the filtered custom View, and save the mapping between the original class name and the obfuscated class name.
[0042] 4.3 Obfuscate the layout file. Use the string to replace the custom View class name in the original layout with the obfuscated class name, and output the modified content to the original layout file.
[0043] 4.4 Compile the layout file. Use the aapt2 compile command to recompile the obfuscated layout file and replace the binary layout file in the output directory of merge${variant}Resources. The specific compile command is aapt2compilepath-to-input-files[options]-ooutput-directory.
[0044] Step 5: Obfuscate the classes corresponding to the Applicaiton, the four major components, and the custom View. In the process of compiling from class to dex, insert a custom gradleTransform to edit the class bytecode. The bytecode editing technology uses ASM.
[0045] 5.1 Modify class references (including class constant references and full class name references). Traverse the classes that the project depends on, and modify the class references of the four major components, Application, and custom View in the class to obfuscated class references. This is achieved by modifying visitLdcInsn in MethodVistor with the help of ASM.
[0046] 5.2 Generate obfuscated subclasses of the four major components, Application, and custom View. Based on the obfuscation mapping rules generated in the third and fourth steps, use ASM to generate subclasses that inherit from the original class. The subclass name is the obfuscated class name.
[0047] 5.3 Output the modified binary class to the specified class file.
[0048] Step 6: After the subsequent Android packaging and compilation steps, the obfuscated APK is output.
[0049] The Mess solution directly obfuscates the original class name, while the present invention generates an obfuscated subclass by inheriting the parent class. This solution allows the subclass to replace the parent class in the AndroidManifest and layout files, so that the parent class is only referenced in the code, so that the obfuscation process can be performed normally. The subclass is dynamically generated during the compilation period and uses the obfuscated class name. This method indirectly achieves the obfuscation of the Applicatior class, the four major components, and the custom View.
[0050] The present invention does not interfere with the obfuscation process, does not require additional obfuscation rule configuration, and does not increase the package size or retain useless code.
[0051] The present invention supports unified configuration of obfuscation class name rules, thereby simplifying the configuration process of special obfuscation rules.
[0052] 1. Customized obfuscation rules. The obfuscation class name rules used in the present invention are rules set by individuals, and other customized class name obfuscation rules can also be selected.
[0053] 2. Customize gradleTransform to modify bytecode. The bytecode editing tool used in the present invention is ASM, and other bytecode editing tools can also be used.
[0054] To ensure the normal operation of the Mess plug-in, the dontshrink configuration must be added to the obfuscation rules. This is because Mess will remove the obfuscation configuration related to Application, the four major components, and custom View during the packaging process, resulting in the loss of their constructors, such as Application's <init>() and custom View <init>(android.content.Context,android.util.AttributeSet). Once the constructor is missing, the system will not be able to instantiate these classes correctly, causing the application to crash at runtime.
[0055] However, using dontshrink will increase the size of the APK package. After verification, the original APK size of 26MB increased by about 2MB to 28M after being obfuscated by Mess. In addition, dontshrink will also package unused historical code into the application, increasing the risk of code security. In addition, Mess cannot uniformly configure the class names generated after obfuscation, such as adding a readable naming prefix to the obfuscated class name. To achieve this, it is necessary to configure the obfuscation rules class by class, which is cumbersome.
[0056] 1. Android resource compilation. apk resources include: all files in the res directory, files in the assets directory, AndroidManifest.xml
[0057] Compiling apk resources is a major task in the compilation process. After AGP3.0.0, AAPT2 is used by default to compile resources. AAPT2 (AndroidAssetPackagingTool2) is a build tool that AndroidStudio and AndroidGradle plugin use to compile and package application resources. AAPT2 will parse resources, index resources, and compile resources into a binary format optimized for the Android platform.
[0058] 2. AndroidBuildVariant. Through the BuildVariant (build variant) capability provided by AGP, we can package a single project into different apk or aar. BuildVariant mainly relies on the properties and methods provided by BuildType and ProductFlavor to configure a series of rules to combine code and resources.
[0059] BuildType is used to define the build mode. Debug and release are two different build modes. Through BuildType, we can configure signature information, etc. ProductFlavor can be understood as product variants. Its function is to define different versions of the project, such as free version and paid version, domestic version and international version, etc. The advantage of this is that you only need to maintain one project, and reuse code and resources to the greatest extent.
[0060] 3. Android Gradle Transform. Gradle Transform is a feature introduced in AGP (Android GradlePlugin) 1.5. It is mainly used to modify the Class bytecode at the Class→Dex node during the Android build process. Using the Transform API, we can get all the Class files involved in the build, modify them with the help of bytecode editing tools such as ASM or Javassist, and insert custom logic.
[0061] The embodiments of the present invention are given for the purpose of illustration and description, and are not intended to be exhaustive or to limit the invention to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments are selected and described in order to better illustrate the principles and practical applications of the present invention and to enable those of ordinary skill in the art to understand the present invention and thereby design various embodiments with various modifications suitable for specific uses.< / init> < / init>
Claims
1. An efficient and accurate obfuscation method for Android compile time, including a technology for processing Class and XML file obfuscation based on gradle compile time, characterized by: By creating a class inherited from the original class during compilation, the class is named according to custom rules, and the original referenced class is modified to be its subclass, including references in Class, AndroidManifest.xml and layout Layout. This can effectively solve the problem that Android obfuscation does not support obfuscation of the four major component classes, Applicaiton, and custom view class. The supported Gradle plug-in versions are: 4.0+~7.0+.
2. The Android compilation-time efficient and accurate obfuscation method as claimed in claim 1, characterized in that: Configure the obfuscation filtering rule file, and customize the configuration rule file according to the App configuration. The rule file includes all classes under a specific package name, and specific classes are not obfuscated.
3. The Android compilation-time efficient and accurate obfuscation method as claimed in claim 1, characterized in that: Create a custom Plugin. The content of the custom Plugin includes: registering the four major components in AndroidManifest.xml, Application scanning and obfuscation tasks, registering the scanning and obfuscation tasks of the custom View in the layout, and registering the Class bytecode editing task.
4. The Android compilation-time efficient and accurate obfuscation method as claimed in claim 3, characterized in that: Register a custom Task and insert it after the Gradle compilation task process${variant}Manifest is completed to parse the Application and confuse AndroidManifest.xml. Register a custom task and insert it between the Gradle compilation tasks merge${variant}Resources and process${variant}Resources to parse and confuse the custom View in the layout. Register a custom Transform to confuse the Class corresponding to the Applicaiton, the four major components, and the custom View.
5. An efficient and accurate obfuscation method for Android compilation as claimed in claim 4, characterized in that: Obfuscate Applicaiton and the four major components in AndroidManifest.xml, parse Application and the four major components, execute the apk packaging task, and after the gradle compilation task process$(variant}Manifest is executed, generate the merged AndroidManifest.xml file, obfuscate AndroidManifest.xml, use DOM to modify the filtered class name to obfuscate the class name, and output the modified content to the merged AndroidManifest file.
6. An Android compilation-time efficient and accurate obfuscation method as claimed in claim 5, characterized in that: Get the original layout file corresponding to the compiled layout. After the Gradle compilation task merge${variant}Resources is executed, a binary layout file compiled by layout will be generated. Use the matching rules to find all binary layout files compiled by aapt2. Use the aapt2 tool provided by didibooster to parse the compiled binary layout file and get the original layout file corresponding to the compiled layout file.
7. An Android compilation-time efficient and accurate obfuscation method as claimed in claim 6, characterized in that: Parse the layout file, obtain and confuse the custom View, use Dom to parse all layout files, obtain the custom View used in the layout, filter the specified custom View according to the rules described in the first step, perform obfuscation on the filtered custom View, and save the mapping between the original class name and the obfuscated class name.
8. An efficient and accurate obfuscation method for Android compilation as claimed in claim 7, characterized in that: Obfuscate the layout file, use the string to replace the custom View class name in the original layout with the obfuscated class name, output the modified content to the original layout file, compile the layout file, use the aapt2 compilation command to recompile the obfuscated layout file, and replace the binary layout file in the output directory of merge${variant}Resources.
9. An efficient and accurate obfuscation method for Android compilation as claimed in claim 8, characterized in that: Obfuscate the classes corresponding to Applicaiton, the four major components, and the custom View. During the compilation process from class to dex, insert a custom gradle Transform to edit the class bytecode. The bytecode editing technology uses ASM to modify the class reference (including class constant references and full class name references), traverse the classes that the project depends on, and modify the class references of the four major components, Application, and custom View in the class to the obfuscated class references. Specifically, use ASM to modify the visitLdcInsn implementation in MethodVistor to generate obfuscated subclasses of the four major components, Application, and custom View. Through the obfuscation mapping rules generated in the third and fourth steps, use ASM to generate a subclass inherited from the original class. The subclass name is the obfuscated class name, and the modified binary class is output to the specified class file.
10. An efficient and accurate obfuscation method for Android compilation as claimed in claim 9, characterized in that: After the subsequent Android packaging and compilation steps, the APK with successful obfuscation is output.