APK package reinforcement means collection (shallow)

---

To secure the code logic within the APK application, you need to do certain APK hardening operations. The common operations for hardening are:

• confusions
• encrypted
• harbor (i.e. keep sth hidden)
• sensing
• ...

If you use third-party reinforcement services, such as 360 reinforcement, Tencent LeGu, etc., the vendor is nothing more than a series of obfuscation, encryption, concealment, detection and other technologies combined and packaged for you to use.

Prevent APK from being debugged

shell

APK package shelling is a common method of application protection by adding a protective shell to the outer layer of the APK package to prevent reverse engineering and debugging. This technique is mainly used to protect the application's code and resources from being easily cracked and tampered. Below is the basic principle of APK package shelling:

1. Shell code injection:
   Shelling tools inject shell code into the original APK package. This shell code is usually a launcher that runs first when the app starts and is responsible for initializing and decrypting the real app code.

2. Encrypt raw code and resources:
   The code and resource files in the original APK package are encrypted. The encryption algorithm can be symmetric (e.g. AES) or asymmetric (e.g. RSA) to ensure that only the shell code can decrypt these resources.

3. Shell code loading and decryption:
   When the user launches the app, the shell code runs first, it decrypts the code and resources in the original APK package and then loads the decrypted code into memory to run.

4. Dynamic loading:
   The decrypted code is usually not written back to disk, but loaded directly into memory for execution. This dynamic loading prevents static analysis tools from reading the decrypted code from disk.

code obfuscation：

utilizationProGuardmaybeR8and other tools obfuscate the code, making the decompiled code difficult to understand.

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(''), ''
        }
    }
}

debugger：

Detect the presence of a debugger at runtime. If a debugger is detected, the application can take appropriate action, such as quitting or displaying a warning.

public boolean isDebuggerConnected() {
    return ();
}

if (isDebuggerConnected()) {
    // Exit or handle the detection
    (0);
}

Use of anti-debugging techniques：

Utilize various anti-debugging techniques such as detecting debug ports, debug flags, etc.

public boolean isBeingDebugged() {
    return (() || 
            ());
}

if (isBeingDebugged()) {
    // Exit or handle the detection
    (0);
}

Environmental testing：

Detect whether the environment in which the application is running is normal, such as determining whether it is running on an emulator.

public boolean isEmulator() {
    String brand = ;
    String device = ;
    String model = ;
    String product = ;

    return (("generic") || ("generic") ||
            ("google_sdk") || ("Emulator") ||
            ("sdk") || ("sdk_google"));
}

if (isEmulator()) {
    // Exit or handle the emulator detection
    (0);
}

Using Native Code：

Move critical code to the native (native) layer, write it in C/C++ and compile it with the NDK. This can make reverse engineering more difficult.

multilayer protection：

Combine these multiple methods to create a multi-layered protection system that increases the difficulty of cracking and debugging.

Prevent APK tampering

signature verification：

Signature is to give the individual files within the APK Hash, to achieve the second packaging by people can be found, so what is the principle?

The signature mechanism of Android applications has undergone several evolutions, mainly including V1, V2 and V3 signature schemes. Each signature method has different characteristics and application scenarios:

V1 Signature mechanism

It has been cracked and is an insecure signature.

The V1 signature (based on JAR signatures and compatible with all versions) approach has a number of inherent flaws that make it not considered secure enough for modern applications. The following are the main reasons why V1 signatures are not secure:

V1 signatures work:
The V1 signature method signs each file within the APK package individually and stores this signature information in the META-INF/ and META-INF/ files.

• : Contains a hash value for each file.
• : Contains a hash of the file, signed by the developer's private key.
• OR: Contains the signing certificate and signing information.

security issue

1. Overall integrity cannot be guaranteed:
   V1 Signature only signs individual files, not the entire APK file. Therefore, an attacker can add, remove or replace files in the APK (such as resource files or DEX files) without affecting the signature integrity of other files.
   For example, an attacker could add a new file to the APK that would not be referenced in it, thereby bypassing signature verification.

2. Easily repackaged:
   An attacker can unpack the APK file, modify the contents (e.g. replace certain files or add malicious code), then repackage it and generate a new signature. This approach can completely replace the original signature, making it difficult for users to realize that the APK has been tampered with.

   The signature information for the V1 signature method is stored in and files, which themselves can be modified or replaced by an attacker.

   Signature file tampering:
   If the signature files (e.g., and ) are themselves incorrectly included in the signature scope, then an attacker can invalidate the original signature by tampering with these files, generating new signature information and replacing the original signature.
   For example.An attacker can generate a new signing certificate and signature information to replace the file, making the entire signature verification process based on the attacker's certificate and signature information.

V2 Signature Mechanism

The V2 Signature (only supports Android 7.0 and above) scheme prevents replacement and tampering by signing the entire APK file. It works as follows:

1. Overall signature
   The V2 signature scheme signs the entire APK file (except the signature block) to ensure the integrity of the APK. The specific steps are as follows:

   1.1 Generate APK Signature Block：
   - Creates a signature block containing hashes and other signature information for all files in the APK. The signature block is located in the APK file'sZIP Central Directorybefore and not included in the signature calculation.

   1.2. Calculate the hash value of the APK body：
   - Calculates a hash value for the body of the APK (excluding the signature block). This hash value ensures that the contents of the APK cannot be tampered with after signing.

   1.3. signature message：
   - The above hash is signed using the developer's private key to generate a signature message. This signature information is also stored in the signature block.

   1.4. signature block structure：
   - The signature block contains signature information, certificate, public key, etc. to ensure the integrity and verifiability of the signature.

2. verification process
   When the device installs the APK file, the system performs the following verification steps:

   1. Read Signature Block：

      • The system reads the signature block in the APK file and extracts the signature information, certificate and public key from the signature block.

   2. Verify Signature：

      • The signature message is verified using the public key in the signature block to ensure that the signature message was generated by the corresponding private key.

   3. Verify the hash：

      • Calculates the hash value of the APK body (excluding the signature block) and compares it with the hash value stored in the signature block to ensure that the APK body has not been tampered with.

   4. Authentication Certificates：

      • Check the validity of the certificate in the signature block and compare it with the app store or expected certificate to ensure the legitimacy of the signature.

Mechanisms to prevent substitution and tampering
The V2 signing scheme prevents the APK from being replaced or tampered with by the following mechanism:

1. Overall hash value checksum：

   • Since V2 Signature calculates and signs the hash for the entire APK file (excluding the signature block), any modification to the APK file (e.g., adding, deleting, or replacing the file) will change the hash value, resulting in a signature verification failure.

2. signature block protection：

   • The signature block is located in the APK file'sZIP Central Directorybefore and not included in the signature calculation, so the signature block itself cannot be tampered with. Any modification of the portion of the signature block outside of the signature block destroys the integrity of the signature.

3. irreplaceability：

   • The signature information in the signature block is generated by the developer's private key, and only the person with the corresponding private key can generate a valid signature. A tamperer cannot generate a signature message that matches the original signature.

4. Certificate Validation：

   • The certificate in the signature block can be used to verify the legitimacy of the signature and ensure that the signature was generated by a trusted developer.

V3 Signature mechanisms

Version control and key rotation features have been added to V2 to further enhance security, but only Android 9.0 and above are supported.

Dynamic Integrity Check：

Code and data are regularly checked to ensure they have not been tampered with.