Author: Yang Kongming Date: 2019-9-10
One, foreword
One of the most common issues facing Android developers is cracking and repackaging. As security becomes more and more important, more and more Android developers are looking for ways to protect themselves. Take a look at the pictures below:
1.1
1.2
1.3
Two, what is the shell?
The development of mobile platform attack and defense technology is basically along the development track of THE PC side, from the Windows platform to the android platform APK reinforcement, anti-debugging code confusion, strengthening the shell
Shell is in the binary program to implant a piece of code, at the time of running the program to take control of the priority, do some extra work. This is how most viruses work. The process of packing the PC EXE file is as follows:
Three, coating and classification
Function:
The shell program can effectively prevent disassembly analysis of the program to achieve its ulterior purpose. This technique is also used to protect software copyright from being cracked by software.
Classification:
From the point of view of App reinforcement technology, the mainstream is divided into DEX encryption and SO encryption. At present, it is more important to protect DEX files, because Java code after dex decompilation is more readable.
4, Android Dex file shell principle
4.1.APK file structure
The following table describes the functions of each file and folder.
| File or directory | instructions |
|---|---|
| Assets folder | Directory for storing resource files |
| Lib folder | Store NDK compiled so file |
| Meta-inf folder | Cert. RS stores the certificate and authorization information of the application. Cert. SF stores the sha-1 information resource list |
| Res folder | Directory for storing resource files |
| AndroidManifest.xml | A manifest file that describes the application name, version, permissions, registered services, and so on. |
| classes.dex | Java source code compiler Dalvik bytecode file generated after compilation, which is the main part of the code running on the Dalvik VIRTUAL machine |
| resources.arsc | Compiled index of binary resource files. |
4.2DEX File Format
4.2.1 What is a DEX File?
It is the executable file of the Android system, containing all operation instructions of the application and runtime data
As Dalvik is a Java virtual machine specially designed for embedded devices, dex files are fundamentally different from standard class files in structure design
After Java program is compiled into class, dx tool is also needed to integrate all class files into a dex file, so that each class can share data, which reduces redundancy to a certain extent and makes the file structure more accurate. Experiments show that dex file is about 50% of the size of traditional JAR file
4.2.2 Dex File Structure
The overall structure of the Dex file is as follows:
Dex file structure:
| The name of the data | explain |
|---|---|
| dex_header | The dex header records the attributes of the dex file |
| string_table | String data index, which records the offset of each string in the data area |
| type_table | Similar to the data index, it records the string index for each type |
| proto_table | The prototype data index, which records the string of method declarations, the return type string, and the parameter list |
| field_table | Field data index, which records the class, type, and method name |
| method_table | Class method index, which records the name of the class to which a method belongs, method declaration and method name |
| class_def | A class defines a data index that records information about the specified class, including interfaces, superclasses, and class data offsets |
| data_section | Data area, save the real data of each class |
Here is the DEX file directory:
There are three members that we need to pay special attention to, which will be used in the later hardening. They are checksum, signature, and fileSize.
The checksum field
The checksum field is a 4bytes checksum field. It is used to check whether the data from the field (excluding the checksum field) to the end of the file is complete. It uses alder32 algorithm to check.
Signature field
Signature indicates the sha-1 signature field, which takes 20bytes and is used for integrity verification. The reason for the two integrity check fields is that the checksum field can be used to quickly check the dex file for errors before the second, more computation-heavy check code is used.
The fileSize field
Bytes, save the total length of the classes.dex file.
When we modify the dex file, the values of these three fields need to be updated, otherwise errors will be reported when loading to Dalvik VM.
Why do we only need to focus on these three fields?
Since we need to write a file (the encrypted source Apk) to the Dex, we definitely need to change the file checksum. Because he was checking the file for errors. So signature is also the algorithm that uniquely identifies files. There is also the need to modify the size of the dex file.
However, one more operation is needed here, which is to mark the size of Apk we encrypt, because we need to know the size of Apk when we unshell, so as to get Apk correctly. So where do I put this value? This value can be placed directly at the end of the file.
So to sum up, we need to do: modify the three file headers of Dex, and append the size of the source Apk to the end of the shell Dex.
4.3APK packaging process
The tools involved in the figure are as follows:
| The name of the | Function is introduced |
|---|---|
| aapt | Package the resource files, including the resources in the res and Assets folders, the Androidmanifest.xml file, and the Android base class libraries |
| aidl | Convert. Aidl interface files to. Java files |
| javaComiler | Compile Java files to generate.class bytecode files |
| dex | Convert all third-party libraries and. Class files to the. Dex files supported by the Dalvik VM |
| apkbuilder | Package generates an APK file, but not signed |
| jarsigner | Sign an unsigned APK file |
| zipalign | The signed APK file is processed |
4.4 Hardening Principles
Dex files are hardened as follows:
Three objects are involved in this process, as follows:
L source program
The main changes are the classes.dex and androidmanifest.xml files in the original APK file.
L shell program
Shell program is mainly used to decrypt the encrypted DEX file, load the decrypted original DEX file, and start the original program normally.
L encryption program
The encryption program encrypts the dex file. The encryption algorithm can be simple xOR operation, reverse operation, RC4, DES, and RSA.
The reinforcement process can be divided into the following four stages:
(1) Encryption stage
(2) Synthesize a new DEX file
(3) Modify the original APK file and repackage the signature
(4) Run the shell program to load the original dex file
4.4.1 Encryption Phase
The encryption phase is mainly about the classes.dex file extracted from the original APK file through the encryption program for encryption. If the DES symmetric encryption algorithm is used during encryption, you need to handle the key properly. Similarly, if asymmetric encryption is used, there is also the problem of public key preservation.
4.4.2 Synthesizing a dex file
In this stage, the encrypted dex file generated in the previous step is merged with our shell dex file, the encrypted dex file is appended to the shell DEX file, and the size value of the encrypted dex file is appended to the end of the file
Inside the shell, there is an important class: the ProxyApplication class, which inherits the Application class and is the first class the Application runs. So, we are in this class, before the original program runs, some decryption dex file and load the original dex file operations.
4.4.3 Modifying the original APK file and packaging the signature
In this phase, we first unpack apK and see the six files and directories shown below. There are only two files that need to be modified: classes.dex and Androidmanifest.xml. The rest of the files and file addition need not be modified.
First, replace the original classes.dex file in the apk directory with the new classes.dex file that we synthesized in the previous step 0x02. Then, because when our program runs, the first load is actually the ProxyApplication class in the shell. Therefore, we need to modify the androidmanifest.xml file and specify application as ProxyApplication, so as to find the ProxyApplication class and run the shell program normally.
4.4.4 Run the shell program to load the original dex file
The Dalvik virtual machine loads our new classes.dex file, which has been modified, and runs the ProxyApplication class first. Within this class, there are two key methods: attachBaseContext and onCreate. ProxyApplication displays the attachBaseContext method followed by the onCreate method.
In the attachBaseContext method, there are two main tasks:
-
If the size of the encrypted dex file is recorded at the end of the classes.dex file, the position of the encrypted dex file in the new classes.dex file is len(new classes.dex file) -len (encrypted dex file size). Then read the encrypted dex file, decrypt it, and save it to the resource directory
-
Then use the customized DexClassLoader to load the decrypted dex file
The onCreate method does two things:
-
Modify the ActivityThread class with reflection and point Application to Application in the original dex file
-
Create the original Application object and call the original Application’s onCreate method to start the original program
Five, shell and shell code implementation
5.1. Shell program Project:
5.2. Core Code
Six, common reinforcement platform
Bang Bang reinforcement, love encryption, 360 reinforcement, Tencent reinforcement
After the common reinforcement tools on the market, they will encrypt your dex and SO in APK, and then run the shell code first, which will solve the original dex and SO and load them. Different manufacturers have their own solutions, which are slightly different, but most of them are based on this idea at present.
7. Advantages and disadvantages of App reinforcement
Positive:
1. Protect their core code algorithms and improve the difficulty of cracking/piracy/secondary packaging
2. Mitigate code injection/dynamic debugging/memory injection attacks
Negative:
1. Compatibility is affected
2. Affect the efficiency of program operation.
3. Some rogue viruses will also use shell technology to protect themselves
4. Some app markets will reject the packaged app
Viii. Future prospects of App security
The assembly line of an APP, from development to internal testing to platform to consumer to crack to platform to consumer, so every link should not be taken lightly!!
Nine, App security summary
| The name of the risk | risk | The solution |
|---|---|---|
| 1.App prevents decompilation | Decompiled exposed client logic, encryption algorithms, keys, etc | strengthening |
| 2. Java layer code source code decompilation risk | Decompiled exposed client logic, encryption algorithms, keys, etc | Reinforce, confound |
| 3. So file cracking risk | The core code leaks. | So file hardening |
| 4. Risk of tampering and secondary packaging | Modify file resources, add viruses, ads, or steal payment passwords, SMS interception, etc | The resource file obfuscates and verifies the hash value of the signature |
| 5. Risk of resource file leakage | Obtain pictures, JS files and other files, through the implantation of viruses, phishing pages to obtain user sensitive information | Resource confusion, hardening, etc |
| 6. Risk of application signature not being submitted | Decompile or repackage, add virus code, malicious code, upload pirated App | Verify the App signature certificate |
| 7. Code for confusion risk | Business logic exposure, encryption algorithms, account information and so on. | Confound (Chinese confound) |
| 8. Webview plaintext password storage risk | The user uses the default webView storage password to access the Database/webView. db root mobile phone to view the WebView database and obtain sensitive user information | The wenVIEW password storage function is disabled |
| 9. Risk of plaintext digital certificates | APK uses digital certificates to verify server validity and ensure data confidentiality and completeness. The certificate stored in plaintext is tampered to obtain data | The client verifies server domain names and digital certificates |
| 10. Debug log function call risk | Logs contain sensitive user information | None Example Disable the debug log function to delete the printed logs |
| 11. The AES/DES encryption method is insecure | When using AES/DES encryption, ECB or OFB mode is used, and encrypted data is selected for plaintext attack | Use CBC and CFB mode, etc |
| 12. The RSA encryption algorithm is insecure | Sensitive user information is leaked due to plaintext attack and man-in-the-middle attack | Keep the password short and use the correct working mode |
| 13. Key hardcoding risk | The key used by the user for the encryption algorithm is set to a fixed value, resulting in key leakage | Dynamically generate encryption keys or store the key process in segments |
| 14. Dynamically debug attack risks | Attackers use GDB and IDA to debug tracking programs and obtain sensitive user information | So file in the implementation of the debugging process monitoring |
| 15. Arbitrary backup of application data | AndroidMainfest allowBackup=true attackers can use ADB commands to back up APP data and leak user data | allowBackup=false |
| 16. Risks of global access to internal files. | Realize data sharing between different software, set internal file global read and write so that other applications can also read or modify files | (1). Create internal storage files using MODE_PRIVATE mode (2). Encrypt and store sensitive data. 3. Do not store plaintext or sensitive information in files |
| 17.SharedPrefs global access to internal files risk. | Files are read or modified by other applications | Use the correct permissions |
| 18. Global read/write risks of Internal Storage data | Setting MODE_WORLD_READBLE or Android :sharedUserId causes sensitive information to be read by other applications | Set the correct mode, etc |
| 19. GetDir Data global read-write risk | Setting MODE_WORLD_READBLE or Android :sharedUserId causes sensitive information to be read by other applications | Set the correct mode, etc |
| 20. Java layer dynamic debugging risk | Debug tags in AndroidManifest can be debugged using JDB to steal sensitive user information. | Android: debuggable = “false” |
| 21. Residual risk of Intranet test information | Through the test Url, test account to attack the official server and so on | This section describes how to clear logs on the test Intranet, or do not use the same log on the test server and production server |
| 22. Risk of unsafe use of random numbers | In the use of SecureRandom class to generate random numbers, in fact, is not random, resulting in the use of random numbers and encryption algorithm is cracked. | (1) Do not use the setSeed method (2) use /dev/urandom or /dev/random to initialize the pseudorandom number generator |
| 23.Http data transmission risk | Unencrypted data is obtained by a third party, causing data leakage | The use of Hpps |
| 24.Htpps does not verify the server certificate risk, Https does not verify the host name risk, Https allows any host name risk | The client does not verify the identity integrity of the server, causing a man-in-the-middle attack | (1). Verify the server in the checkServerTrusted method of X509TrustManager (2). Check whether the certificate is expired (3). Use the HostnameVerifier class to check whether the host name in the certificate is the same as the host name that uses the certificate |
| 25. Webview bypasses certificate verification risk | The URL encrypted by THE WEBView using HTTPS does not verify the server, resulting in a man-in-the-middle attack | The server certificate is verified correctly |
| 26. Interface hijacking risk | When the user input password is blocked by a fake page to obtain user information | (1). Use third-party professional anti-interface hijacking SDK (2). Verify whether the current page is your own |
| 27. Enter monitoring risk | User information is monitored or key positions are monitored, resulting in user information leakage | Custom keyboard |
| 28. Screenshot attack risk | Screenshot or record the interface during APP operation to obtain user information | Add getWindow().setflags (FLAG_SECURE) to prevent users from capturing and recording screenshots |
| 29. Dynamically register Receiver risk | The default life cycle of a dynamically registered Receiver can be exported and accessed by any application | Register for dynamic broadcasts using the registerReceiver API with permission verification |
| 30.Content Provider Data leakage risk | User information is generated due to incorrect permission Settings | Correct access rights |
| 31. Risk of exporting Service, Activity, Broadcast, and Content Provider components | When the Activity is accessed by a third-party application, it is invoked maliciously by any application | Custom permissions |
| PendingIntent Incorrect use of Intent risks | With a PendingIntent, if an empty Intent is used, malicious users can hijack and modify the Intent | Disallow constructing PendingIntent with an empty Intent |
| Intent component implicit invocation risk | The use of implicit intents that do not restrict the receiver leads to the hijacking of sensitive information | 1. Restrict the receiving end. 2 |
| 34. URL attack risk of an Intent Scheme | Webview calls App maliciously | Security restrictions on intEnts |
| 35.Fragment Injection attack risk | The subclass of the PreferenceActivity does not add the isValidFragment method to verify the fragment name. Attackers may bypass the restriction and access unauthorized interfaces | If an Activity component does not need to export, or if the component is configured with the Intent filter tag, it is recommended to set the “Android: Exported” attribute to false. Rewrite the isValidFragment method to verify the source of the fragment |
| 36. Webview remote code execution risk | Risk: the WebView addJavascriptInterface methods registered for JavaScript call Java objects, through reflection calls other Java classes, etc | It is recommended not to use the addJavascriptInterface interface. For Android operating systems with an API Level of 17 or higher, Google allows functions to be called. You must declare an @javascriptInterface annotation on a Java remote method |
| 37. Directory traversal risk of decompressing zip files | Java code uses the getName() method of the ZipEntry class to extract the ZIP file if the ZIP file contains “.. /, if getName() does not filter out the “.. / “string, continue the unzipping operation, the unzipped file will be created in another directory | (1). Verify the digital signature of important ZIP files and decompress them only after the verification succeeds. (2). Check whether the file name obtained using zipentry.getName () in the Zip package contains “.. / “or”..” , check “.. / “do not Decode urIs (in case urIs are encoded”.. %2F “to circumvent), tests find zipentry.getName () for Zip packages with”.. The %2F “file path is not processed. |
| 38.Root Device running risk | Mobile phones that have root access to sensitive information about applications | Check whether the mobile phone is root and forbid the application to start |
| 39. Emulator operation risk | Brush, simulate virtual location, etc | Do not run on a virtual machine |
| 40. Load Dex and SO risks from SDcard | Dex and So files were not verified for security, integrity and integrity, resulting in replacement and disclosure of sensitive user information | (1). Put it in the private directory of APP (2). Verify the file completion. |
## 10. Reference
From source code to APK
Dex File format description
Talk about android app reinforcement that matter
Android APK Shell Technology solution [1]
Android APK Shell Technology solution [2]
ANDROID principle decryption APK generation process
Android signature mechanism – Detailed description of the signature verification process