MT APK如何保留谷歌签名不被修改？

Question

在使用MT管理器等工具对APK进行反编译、修改或重打包时，一个常见问题是修改后的APK会丢失原始谷歌签名（如META-INF中的CERT.RSA/DSA），导致应用无法通过Google Play Integrity或SafetyNet检测。开发者常问：如何在MT APK修改过程中保留原始签名文件而不被自动替换？关键在于手动备份META-INF目录并在重新打包时排除签名文件的删除，同时避免对已签名部分的代码或资源做破坏性更改。但需注意，任何实质性的APK内容修改都会使原签名失效，仅保留签名文件无法通过平台校验，必须重新签名且无法继承原始谷歌账户授权。

Answer 1

一、APK签名机制基础：理解META-INF与应用完整性校验

在Android系统中，每个APK文件都必须经过数字签名才能被安装和运行。签名信息存储于APK根目录下的META-INF文件夹中，主要包括以下几个关键文件：

• CERT.RSA 或 CERT.DSA：包含公钥和签名算法信息，用于验证APK的发布者身份。
• CERT.SF：签名摘要文件，记录了所有已签名资源的SHA-1或SHA-256哈希值。
• MANIFEST.MF：列出APK中所有受保护的文件及其原始哈希值。

当使用MT管理器进行反编译时，默认行为通常会在重新打包过程中自动清除这些签名文件，以防止签名冲突。然而，这一操作直接导致原始谷歌签名丢失，进而影响Google Play Integrity API或SafetyNet Attestation的通过率。

二、常见问题分析：为何保留原始签名无效？

问题现象	根本原因	技术后果
修改后无法通过Integrity检测	APK内容变更使原签名失效	平台拒绝认证，视为非官方版本
手动保留CERT.RSA仍失败	SF与MANIFEST哈希不匹配新内容	校验链断裂，签名验证失败
重签后包名相同但权限受限	私钥不同，无法继承Google账户授权	无法访问原账号关联服务（如云同步）

由此可见，即使成功保留了META-INF中的签名文件，任何对DEX、资源、清单文件的实质性修改都会改变其哈希值，使得原有签名不再有效。操作系统在加载APK时会重新计算各文件哈希并与.SF对比，一旦发现不一致即判定为篡改。

三、解决方案路径：从备份到可控重打包流程

1. 使用MT管理器进入目标APK，定位并复制整个META-INF目录至外部存储作为备份。
2. 右键选择“解压到”功能将APK解包为可编辑结构，避免直接“反编译”触发自动清理签名。
3. 完成代码或资源修改后，使用Zip工具手动重建APK，确保不解压也不删除原有签名块。
4. 若需重新签名，应使用apksigner工具配合自定义密钥库执行V2/V3签名：

apksigner sign --key mykey.pk8 --cert mycert.x509.pem \
--out signed_app.apk modified_app.apk

注意：此过程生成的是新的合法签名，并非“恢复”原始签名。Google Play的Integrity API依赖JWS响应中的SigningCertificateHash字段，只有原始开发者上传的密钥才能匹配。

四、高级策略与安全边界：自动化脚本与风险规避

graph TD
    A[原始APK] --> B{是否需要修改?}
    B -->|否| C[直接提取签名信息用于比对]
    B -->|是| D[备份META-INF目录]
    D --> E[解压APK结构]
    E --> F[仅修改非签名区域: assets, res, smali*]
    F --> G[重新压缩为ZIP格式]
    G --> H[调用apksigner进行V3签名]
    H --> I[输出新APK]
    I --> J[上传至内部测试轨道验证Integrity]

实践中建议结合zipalign优化与adb install -r强制更新机制，在开发调试阶段快速验证修改效果。对于企业级逆向工程团队，可构建CI/CD流水线集成签名状态检查模块，防止误提交未签名或错误签名版本。