Why should App be protected?
Android’s development language is Java, so the compiled Java language will be decomcompiled to get the source code. A variety of tools make decompilation easier. After obtaining the source code of the project, you can do some special operations that cause the company to lose money.
Protective measures
In order to deal with decompile cracking, there are some countermeasures, which are summarized as follows
- Resources to confuse
- Code confusion
- Signature verification
- Components security
- Webview code execution bug
- strengthening
- Code security
- Dynamic loading
- hook
- Data Storage Security
- Data transmission security
- Memory data security
Resources to confuse
In common decompression tools, it is easy to decomcompile apK packages and obtain resource files. Decompression is easy to obtain information in anim, Drawable, Layout, Menu, values and other folders. You can modify the resource files in these folders. And backcompile with apktool (the apktool B command) to create a modified APK application. Here’s a technical solution, AndResGuard, which is both slimming and confusing
Code confusion
Android development code confusion is a very common means of protection, code confusion includes code compression, optimization, confusion and a series of behavior process. It generally includes the following steps:
- Compression. Remove invalid classes, class members, methods, attributes, etc.
- Optimization. Analyze and optimize method binary code; Follow the configuration in proguard-Android-optimize.txt
- Confusion. Replace class, attribute, and method names with jumbled names;
- Preverification. Add preverification information. Android does not need to
Commonly used obfuscation syntax is relatively correct and relatively simple, interested in their own reference
Get obfuscation file
- Open the confusion
- Import obfuscation files into the same directory as proGuard-rules.pro
- Edit ProGuard-rules.pro and add the following
Relatively easy to implement, using existing obfuscation files github.com/WrBug/Frenz… Or custom
Three – party reinforcement package, pay more useful
Signature verification
The Android system uses the JAR package signature mechanism to protect the integrity of APK, ensuring that the integrity of APK is protected when it is transmitted over insecure networks. However, the Android system does not manage the issuer of the digital signature. Anyone can generate a digital signature and use the signature to re-sign the APK package. If the App itself does not carry out an effective integrity check on its signature source, attackers can tamper with the application (insert malicious code, Trojan horse, backdoor, advertisement, etc.), re-sign and re-publish the application, resulting in the destruction of the integrity of the application
www.jianshu.com/p/5c4a4b1e8…
Components security
The Activity of protection
Activity scheduling mechanism
Android’s switching between different applications is essentially seamless. They switch only one activity to the foreground, while the other application is overwritten and invisible in the background. Activity scheduling is managed by AMS in Android (ActivityManagerService). The activity is started and stopped by AMS. The Activity is stored on the stack
The Activity was hijacked
That is, a normal activity is replaced by a fake activity by an attacker, but the user does not know that it is a fake activity, so the attacker can directly obtain the activity after the user enters relevant information. Login pages, payment pages, and other data-sensitive pages are vulnerable. For example, write a program that starts a background service that keeps scanning, then forges a page and goes back to the user’s information. Solution:
- When our application exits to the background, a pop-up message informs the user that the application has exited to the background.
- Set the Android: Exported attribute. Components that do not need to be called by external applications should add the Android:exported =”false” attribute.
Service hijacking, Service denial of Service
The Service was hijacked
In The Android system, if multiple services receive the same action, the priority value of each Service is determined. If the priority value is higher, the action is started first. If the priority values are the same, start the Service that is installed first based on the installation sequence of the application to which the Service belongs.
- When an Intent is created, the package name and class name of the Service to be launched are displayed.
Service denial of Service
In Android, data is carried through intEnts. However, the system does not deal with the data in the intent internally. For example, the data is empty and there are problems with the data. Once an attacker changes the data in the intent, the program will crash.
- Handles the data attached to the intent of getIntent();
- Null pointer exception;
- Type conversion exception;
- Array out-of-bounds access exception;
- Class undefined exception;
- Other exceptions; The intent of ent() carries empty, abnormal, or malformed data;
Webview code execution bug
There are three main types of vulnerabilities
- Arbitrary code execution vulnerability
- Password plaintext storage vulnerability
- Lax domain control vulnerability
WebView arbitrary code execution vulnerability
- AddJavascriptInterface () interface in WebView
The addJavascriptInterface interface causes remote code execution vulnerability
The vulnerability is caused by: when JS gets the Android object, it can call all the methods in the Android object, including the system class (java.lang.Runtime class), so as to carry out arbitrary code execution. Such as
- Objects in Android have one common method: getClass();
- This method gets the current Class type, Class
- This Class has one key method: class.forname;
- This method loads a class (which loads the Java.lang.Runtime class)
- This class can execute local commands
Solution: Android after version 4.2:
In Android 4.2, Google annotated the called function with @javascriptInterface to avoid vulnerability attacksCopy the code
Before Android version 4.2: Use prompt () to intercept vulnerability repair principle every time a local JS code is loaded before the WebView loading page, the principle is:
- Make the JS call a Javascript method: this method passes the JS information (including the specific identifier, method name, etc.) to the Android side by calling prompt ();
- In Android onJsPrompt (), it parses the passed information and invokes Java object methods via reflection mechanism, thus implementing safe JS calls to Android code.
Detail 1: When to load the JS code described above
OnLoadResource (); DoUpdateVisitedHistory (); OnPageStarted (); OnPageFinished (); OnReceivedTitle (); OnProgressChanged ();Copy the code
Detail 2: Methods that need to be filtered out of the Object class
getClass()
hashCode()
notify()
notifyAl()
equals()
toString()
wait()
Copy the code
Password plaintext storage vulnerability
The WebView enables the password saving function by default. When a user enters a password, a dialog box is displayed asking the user whether to save the password. Password will be definitely confirmed to/data/data/com. The package. The name/databases/webview. Db, so you are in danger of being stolen password solution:
WebSettings.setSavePassword(false)
Copy the code
Lax domain control vulnerability
1. SetAllowFileAccess ()
Webview.getsettings ().setallowFileAccess (true); // The default is true, which allows arbitrary JavaScript code to be executed in the File fieldCopy the code
Js code loaded using the file domain can be accessed using the same origin policy across domains, resulting in privacy information leakage
- Same-origin policy Cross-domain access: Access private directory files
- For IM products, chat information, contacts, and so on are leaked
- For browser software, the leakage is cookie information leakage.
If the file protocol is not allowed, there is no such threat. But it also limits the ability of WebView to load local HTML files
Solution:
- Disable file for applications that do not use the file protocol.
- Disable the File protocol from loading JavaScript for applications that require the file protocol.
setAllowFileAccess(true); If (url.startswith ("file://") {setJavaScriptEnabled(false); } else { setJavaScriptEnabled(true); }Copy the code
2. SetAllowFileAccessFromFileURLs ()
/ / set whether to allow the file url to load the Js code read other local file webView. GetSettings () setAllowFileAccessFromFileURLs (true); // Enabled by default before Android 4.1 // disabled by default after Android 4.1Copy the code
Solution: set setAllowFileAccessFromFileURLs (false);
3. SetAllowUniversalAccessFromFileURLs ()
// Set whether Javascript loaded through the file URL can access other sources (including HTTP, HTTPS, etc.) webView.getSettings().setAllowUniversalAccessFromFileURLs(true); / / in front of the Android 4.1 default allows (setAllowFileAccessFromFileURLs () doesn't work) / / default is prohibited after the Android 4.1Copy the code
Solution set setAllowUniversalAccessFromFileURLs (false);
4. SetJavaScriptEnabled ()
// Sets whether to allow JavaScript for webViews (default is not allowed) webView.getSettings().setjavascriptenabled (true); // However, many applications (including mobile browsers) voluntarily set this value to true in order for WebView to execute HTTP JavaScript.Copy the code
Even if the setAllowFileAccessFromFileURLs () and setAllowUniversalAccessFromFileURLs () is set to false, Javascript loaded through the file URL still has a way to access other local files: symlink cross-source attacks
If the file URL is allowed to execute javascript, that is, webView.getSettings().setjavascriptenabled (true);Copy the code
The file referred to by the symbolic link can be read through javascript’s delayed execution and by replacing the current file with a soft link pointing to another file. Specific attack steps:
- The malicious JS code output to the attack application directory, randomly named xx.html, modify the permission of the directory;
- Sleep for 1s after modification, let the file operation complete;
- Then open the xx.html file in the Chrome application of the system
- Wait for 4s for Chrome to complete the HTML loading, and finally delete the HTML, and use the ln -s command to create a soft link for Chrome’s Cookie file
For applications that do not need file, disable file.
// Disable file; setAllowFileAccess(false); setAllowFileAccessFromFileURLs(false); setAllowUniversalAccessFromFileURLs(false);Copy the code
Disable the File protocol from loading JavaScript for applications that require the file protocol.
SetAllowFileAccess (true); setAllowFileAccessFromFileURLs(false); setAllowUniversalAccessFromFileURLs(false); If (url.startswith ("file://") {setJavaScriptEnabled(false); } else { setJavaScriptEnabled(true); }Copy the code
strengthening
Paid third party reinforcement
Code security
- Important characters should not be hard-coded in the Java layer, because String contents are not obfuscated and can be placed in JNI, and JNI functions can be protected with an additional layer of protection.
- Limit access to variables, make every method final, and try not to clone your class. If cloning is allowed, it may bypass the class and easily copy its properties.
- Serialization is used in many Android applications, so if you think the class is risky, or very secure, try not to serialize it.
Hook protection
www.jianshu.com/p/4ecc288a0…
Data Storage Security
- SharedPreferences Store Encryption and decryption mode: Encrypt keys and values at the same time. The storage type is 2. String.
- File File storage encryption and decryption mode: Encrypts and decrypts data flows.
- SQLite database storage encryption and decryption mode: Implemented based on Sqlcipher.
Data transmission security
It is feasible to use CA to issue certificates, but if combined with the actual situation, time and cost are too high, so this method is seldom used at present. Since the mobile application server is actually fixed, so are the certificates. “certificate or public key lock” can be used to protect against unverified certificate validity.
Memory data security
Important memory data, such as passwords, should not be stored in memory for a long time and should be destroyed immediately after use. If you want to stay for a long time, you can consider encryption and salt.