On Android security risks and preventive measures


A lot of risk problems have been detected by the detection tools. Do you feel that your efforts have been wasted? Today, let’s talk about the security of Android.

1、 Let’s start with security checks

1. Source file security

1.1 risk of tampering and secondary packaging

1.2 risk of application signature not verified

1.3 java code decompilation risk detection

1.4 code confusion risk detection

1.5 risk detection of resource document leakage

2. Data storage security

2.1} WebView plaintext storage password risk detection

2.2 global read / write risk detection of internal storage data

3.3 risk of unsafe use of encryption algorithm

4.4 log data leakage risk

4.5url hard coding risk

3,Component risk

3.1 activity component export risk

3.2service component export risk

3.3content provider component export risk

3.4broadcast receiver component export risk

3.5 WebView Remote Code Execution Vulnerability

3.6 intent scheme URL attack risk

4,Safety protection capability

4.1 Java layer code dynamic debugging risk

4.2c layer code dynamic debugging risk

4.3 dynamic injection attack risk

4.4 simulator operation risk

4.5 start hidden service risk

4.6 root equipment operation risk

5,Content risk

5.1 custom vocabulary

5.2 sensitive text

5.3 sensitive pictures

This type of risk exists in publishing articles or information applications. Words and pictures such as “pornographic”, “gambling” need to be identified or filtered for sensitive content. In order to save costs, you can manually review the information. Of course, this workload is too heavy. If money is available, you can intervene in professional work

Detect the company’s API to make the content security of the application more rigorous.

2、 Let’s see what we can do when we have no money

1. When packaging an application, we basically need to add confusion. Of course, we have to create another signature file

2. If our application is large, we can compress the resource file again. I use andresguard

3. No money, no way. Let’s have a free reinforcement service.

Do we all think that I did the same. Yes, generally our program will do these basic operations, but what else can we do?

In case 1, the application is decompiled and packaged twice – APK generates a hash signature after formal packaging and saves it on the server. After the application starts each time, check whether the current application hash is consistent with that saved by the server, so as to check whether the application is legal. Hey, hey, is it a way to solve the problem

Upper Code:

 *Obtain the corresponding hash value according to APK MD5 summary
 * @param context
 * @return
public static String getApkHashValue(Context context) {
    String apkPath = context. getPackageCodePath(); //  Get APK package storage path
    try {
        MessageDigest dexDigest = MessageDigest.getInstance("MD5");
        byte[] bytes = new byte[1024];
        int byteCount;
        FileInputStream fis = new FileInputStream(new File(apkPath)); //  Read APK file
        while ((byteCount = fis.read(bytes)) != -1) {
            dexDigest.update(bytes, 0, byteCount);
       /* BigInteger bigInteger = new BigInteger(1, dexDigest.digest()); //  Calculate the hash value of APK file
        String sha = bigInteger.toString(16);*/
        //Solve the problem of MD5 losing 0 under special circumstances
        StringBuffer buf = new StringBuffer();
        byte[] b = dexDigest.digest();
        int i;
        for (int offset = 0; offset < b.length; offset++) {
            i = b[offset];
            if (i < 0) {
                i += 256;
            if (i < 16) {
        return buf.toString();
    } catch (NoSuchAlgorithmException e) {
        return "";
    } catch (FileNotFoundException e) {
        return "";
    } catch (IOException e) {
        return "";

Case 2; Most of the time, APK is decompiled or destroyed, and it is often operated through the simulator or by obtaining root permission

I can’t help but say goodbye to the simulator. After the program is officially released, the code checks whether the running device is an emulator. If so, it won’t run. The verification logic like the root device is simple and rough!!!

However, there is no official or authoritative detection code for root or simulator detection. There is no way to make Android brands too complicated. If we really encounter this compatibility problem, it’s OK. We can check the logic again and verify it on the server,

The server controls this version or whether a user can go through this part of the verification logic amount ~ ~ ~ ~, and the latter can be solved by itself.

Case 3, dynamic debugging, memory reading

Consistent with case 2, it is to detect whether there are debugging tools in debugging the program through code, and then make corresponding judgment and treatment

Other situations are more common. Baidu can find a solution casually. There is no wordiness here. hey

Finally, if your company is rich, don’t consider so much. Come to a professional organization to encrypt, and the risk will be minimized as long as there is money~

There is no absolute security. What we can do is to minimize the security risk, Ouli!

The above is the details of Android security risks and preventive measures. For more information about Android security risks and preventive measures, please pay attention to other relevant articles of developeppaer!

Recommended Today

04 project architecture – componentization – detailed explanation

1、 Background With the gradual expansion of the project, there are more and more business functions, more and more code and more developers. During this process, have you ever had the following troubles? There are many and complex project modules. Compile for 5 minutes or even 10 minutes at a time? Too slow to bear? […]