Analysis and Implementation of Android APK Signature Scheme v2

Android Studio 2.2 introduced many new features, among which the new APK Signature Scheme v2 was integrated into the Gradle Plugin (starting from version 2.2). This scheme is supported on Android 7.0 (Nougat) and later, and is expected to become the default signing method as Android versions evolve.

The v2 signing mechanism is enabled by default in Gradle Plugin 2.2+. It speeds up signature verification by eliminating the need to decompress the original files and strengthens the integrity of the APK because any modification to the signed package after signing will cause installation to fail on Android 7.0+ devices.

The article demonstrates how to write custom information into the v2 signature block, read it back, and delete it, proving that additional data can be stored in the block while still passing v2 verification.

Origin – the old v1 scheme : The traditional signing method stores three files in the META‑INF directory (MANIFEST.MF, CERT.SF, CERT.RSA). The verification process requires decompressing the original files to recompute SHA‑1 digests, which is time‑consuming, and the integrity check can be bypassed by modifying unrelated parts of the APK (e.g., zipalign padding).

The v2 scheme addresses these two problems:

Performance : No need to decompress original data, resulting in faster verification.

Integrity : The signature is computed over the entire binary content of the APK; any change to the three original sections or any other byte will cause verification to fail.

Because of this strictness, the v2 scheme can be disabled if needed. In build.gradle you can turn it off with:

v1SigningEnabled false
v2SigningEnabled false

Alternatively, the command‑line tool apksigner (the jarsigner tool does not support v2) can be used to sign APKs.

Detailed structure of the v2 signing block : A new "signature block" is inserted between the original file data and the central directory. The block contains size fields, a magic string "APK Sig Block 42", and a series of ID‑value pairs. The v2 specific ID is 0x7109871a. The format can be seen in the source class ApkSignerV2.java and is illustrated by the following snippet:

ID:0x7109871a
value:0x00000665
// ... further parsing shows signature algorithm ID 0x00000103 (RSASSA‑PKCS1‑v1_5 with SHA2‑256)

Locating the signing block in an APK : By searching for the end‑of‑central‑directory signature 0x06054b50 and the offset to the central directory ( 0x01fc3ef2 in the example), the signing block can be found 16 bytes before the central directory magic. The block size ( 0x068d) and the magic string APK Sig Block 42 confirm its location.

Verification process :

Check that the two size fields in the signing block are equal.

Ensure the third part (EOCD) and second part (central directory) are adjacent and that no extra data follows the EOCD.

Locate the v2 block with ID 0x7109871a. If absent, fall back to v1 verification.

For each signer, select the strongest supported algorithm, verify the signature with the public key, compare algorithm IDs, recompute chunk digests, and validate the certificate chain.

Embedding channel information into the v2 block : The article provides a Java method that appends a custom channel identifier to the v2 signing block while preserving the block’s size and magic fields. The method constructs a new block, writes the original v2 scheme bytes, adds the channel ID and bytes, and returns the modified block array.

public byte[] getAfterWriteChanaelSignatureBlock(byte[] v2SchemeBlockBytes, String chanael) throws ApkParseException {
    // ... (implementation omitted for brevity) ...
    return result.array();
}

Usage example:

java -jar AndroidSignApkToolV2-1.1.0.jar -input 原apk -output 签名后apk -chanael 渠道号名字

The author notes that modifying an APK after v2 signing will cause installation failures on Android 7.0+, and suggests writing additional data into the unsigned part of the signing block as a workaround.