Meituan Android resource obfuscation protection practices

Meituan Android resource obfuscation protection practices
Preface

APK security in Android applications has been criticized, and the market is filled with various cracked or Chinese applications, hackers can easily decompile, crack, and convert an APK using a cracking tool, in this way, the logic of the original code can be modified, new code can be added, resources can be added or modified, or even more viruses can be implanted, thereby compromising the security and user experience of the original APK, it eventually hurts users and existing developers.
Things have two aspects: yundun, yundun, and various solutions for Android Application security have emerged. Everyone is familiar with various shell reinforcement tools, we can use these tools to protect our APK. Shell reinforcement is another topic. We will not introduce shell reinforcement here. If you have the opportunity, we will discuss it separately, during the development process, we can use ProGuard or DexGuard to protect our code and implement relative code security. But what about our resources? We often ignore the protection of resource files. Here we will share with you the protection of resource files in the APK in the conventional way.

Resource Security

The topic of resource security is currently not very important. In comparison, we are more concerned about code security. Currently, all types of apps on the market use ProGuard to protect code security, however, the protection of resource files is not very powerful. In fact, resource files have a large security risk. What security risks will the resources pose? The following is a simple example to illustrate the importance of protecting resource files.

We first use the most common apktool tool to decompile an application and run the following command to decompile the application;

    apktool d -s xxx.apk

After successful decompilation, let's take a look at the structure of the decompilation file (SEE );

Through the directory structure in, we can see that the application's resource files are probably anim, drawable, layout, menu, values, etc. We can modify the resource files in these folders, you can use apktool for back-compilation (apktool B command) to create a modified APK application, for example, the layout file marked by the red horizontal line in the modification, you can add some of our own items to the original APK payment information (guess the layout intent Based on the Resource Name;

This problem is mainly because we advocate naming standardization during the development process. Generally, we need to be well known during naming so that we can understand and maintain it easily, at the same time, this makes it easy for the attacker to guess the intention and role of the file based on the file name, so as to make destructive changes.

Through this example, we can see the importance of resource security. How can we achieve resource security? Security is relative and there is no absolute security. Next we will discuss how to protect our resources in a way similar to Proguard. We mainly protect resources by modifying the AAPT tool. To facilitate understanding, let's first talk about how Android apps find resources.

Android resource search process

In Android systems, many resources are usually configured for each application to adapt to screens of different density, sizes, and directions, as well as to adapt to different countries, regions, and languages. These resources are automatically adapted according to the current configuration information of the device when the application is running. That is to say, given the same resource ID, different resources may be found under different device configurations.
This search process is completely transparent to applications. This process is mainly completed by the Android resource management framework, the Android resource management framework is actually implemented by the AssetManager and Resources classes. The Resources class can search for Resources by ID, while the AssetManager class looks for Resources by file name. In fact, if a resource ID corresponds to a file, the Resources class first finds the resource file name based on the ID, then, the file name is handed over to the AssetManager class to open the corresponding file. The basic process is as follows:

We can see that Resources converts the Resource ID into the name of the Resource source file through resources. arsc and then submits it to AssetManager for loading.
Resources. the arsc file is stored in the APK package. It is generated by the AAPT tool during the packaging process. It is a resource index table, the relationship between the maintainer resource ID, Name, Path, or Value. Through this index table, AssetManager can find the file or data corresponding to the resource through the resource ID.

AAPT Introduction

AAPT is the abbreviation of Android Asset Packaging Tool. It is stored in the tools/directory of the SDK. AAPT is powerful and can be used to view, create, and update compressed files (such. zip file ,. jar file ,. apk file). It can also compile resources into binary files and generate resources. arsc and AAPT play an important role in the APK packaging process. In the packaging process, AAPT is used to package resources used in the APK. Here we will not discuss the AAPT tool too much, the AAPT package process is as follows:

AAPT is mainly used in the packaging process:

1. Package all resources in the "assets" and "res/raw" directories (the files are compressed or not compressed based on different file suffixes ), other Resources in the "res/" directory are compiled or processed (the specific processing method varies depending on the file suffix, for example :". xml "will be compiled into binary files ,". png "files will be optimized, etc.) before packaging;
2. A resource ID constant is assigned to all resources except assets resources, and a resource index table resources. arsc is generated;
3. Compile AndroidManifest. xml into a binary XML file;
4. Save the result generated in the preceding three steps in a *. ap _ file, and define the resource ID constants in an R. java file;

   . The ap _ file will be placed in the APK package when the APK is generated ,. the ap _ file is a ZIP package containing resources. arsc, AndroidManifest. xml, assets, and all resource files are UNZIP:
   
   We can see the content in the *. ap _ file. The file is stored in the build/intermediates/res Directory, which is the path where the file is stored:
   

   Resource Protection

   Here, we refer to the Proguard Obfuscator method to replace the resource file name in the APK with a brief and meaningless name, which makes it difficult for the cracker to ensure resource security. Through the above analysis, we can see that by modifying AAPT, resources are generated. arsc and *. when ap _ is used, the name of the resource file is replaced to protect the resource.
   By reading the AAPT compilation Resource code, we found that modifying the source code of AAPT in processing Resource files can replace the Resource file name. below is the Resource. the modified code snippet of makeFileResources () in cpp:

       static status_t makeFileResources(Bundle* bundle, const sp& assets,                                      ResourceTable* table,                                      const sp
       
        & set,                                      const char* resType)    {        String8 type8(resType);        String16 type16(resType);        bool hasErrors = false;        ResourceDirIterator it(set, String8(resType));        ssize_t res;        while ((res=it.next()) == NO_ERROR) {            if (bundle->getVerbose()) {                printf("    (new resource id %s from %s)\n",                       it.getBaseName().string(), it.getFile()->getPrintableSource().string());            }            String16 baseName(it.getBaseName());            const char16_t* str = baseName.string();            const char16_t* const end = str + baseName.size();            while (str < end) {                if (!((*str >= 'a' && *str <= 'z')                        || (*str >= '0' && *str <= '9')                        || *str == '_' || *str == '.')) {                    fprintf(stderr, "%s: Invalid file name: must contain only [a-z0-9_.]\n",                            it.getPath().string());                    hasErrors = true;                }                str++;            }            String8 resPath = it.getPath();            resPath.convertToResPath();            String8 obfuscationName;            String8 obfuscationPath = getObfuscationName(resPath, obfuscationName);            table->addEntry(SourcePos(it.getPath(), 0), String16(assets->getPackage()),                            type16,                            baseName, // String16(obfuscationName),                            String16(obfuscationPath), // resPath                            NULL,                            &it.getParams());            assets->addResource(it.getLeafName(), obfuscationPath/*resPath*/, it.getFile(), type8);        }        return hasErrors ? UNKNOWN_ERROR : NO_ERROR;    }
       

   The above code modifies the name of the resource file when adding the resource file to ResourceTable and Assets. This can replace the name of the resource file, in this way, we use the modified AAPT tool to compile resources and package the resources. We then use the tool apktool mentioned above to decompile the resources after decompiling:
   

   Have you found any changes? The familiar layout, drawable, anim, menu and other folders in the res Directory have disappeared. Where have they gone? Because the apktool has put them in the unknown folder, see:
   
   Let's take a look at the unknown folder. You will find that the resource file name has been replaced by a brief and meaningless name, which will make it difficult for the non-compiler to understand, the decompiler needs to spend some time figuring out the functions of these resource files. Another benefit of resource obfuscation is that it can significantly reduce the size of the APK, resource obfuscation can protect the security of resource files and reduce the size of the installation package. Why not?

   By modifying AAPT, we can achieve relative resource security without modifying the code. Of course, security is relative and there is no absolute security.