APK V2签名存储位置及PmsHook适配API28+技术问询

一、API28+签名验证Hook的替代方案 #

Android API28后GET_SIGNATURES被弃用，替代为GET_SIGNING_CERTIFICATES，需调整Hook逻辑适配新API：

• Hook上层PackageManager.getPackageInfo：拦截该方法，当传入的flags包含PackageManager.GET_SIGNING_CERTIFICATES时，构造包含原签名的SigningInfo对象返回。由于SigningInfo的构造方法非公开，需通过反射实现：

// 反射构造合法的SigningInfo示例
Class<?> signingInfoClz = Class.forName("android.content.pm.SigningInfo");
Constructor<?> constructor = signingInfoClz.getConstructor(boolean, List.class);
// certList为预存的原APK签名证书列表（X509Certificate集合）
SigningInfo fakeSignInfo = (SigningInfo) constructor.newInstance(true, certList);

• Hook底层验证逻辑：若想绕过上层API差异，可直接HookPackageParser.collectCertificates或PackageManagerService.verifyPackageSignatures这类底层方法，从源头替换签名验证结果，适配所有API版本。

二、APK重签名后的痕迹 #

重签名操作会留下多个可追踪的痕迹：

• 签名载体差异：V1签名下META-INF目录的.RSA/.SF/.MF文件会被替换为重签名文件；V2/V3签名下，APK的签名块会被完全替换，可通过apksigner verify --verbose命令查看签名信息变更。
• 文件哈希不匹配：被修改过的APK文件哈希值会与原APK不一致，原签名的哈希校验会失败（除非重签名时重新计算全量文件哈希）。
• Manifest篡改痕迹：部分重签名工具会修改Manifest（如添加权限、注入组件），或在Manifest中留下工具标识。
• 签名链/算法差异：重签名使用的密钥对、签名算法（如原用SHA256withRSA，重签名用SHA1withRSA）与原APK不符，可通过签名信息对比发现。
• V3签名验证链断裂：V3签名包含多渠道验证链，重签名后该链会被替换，无法与原签名链匹配。

三、V2/V3签名存储位置及Hook可行性 #

签名存储位置 #

V2/V3签名存储在APK文件的**签名块（Signature Block）**中，该块属于ZIP格式的扩展区域，位于ZIP中心目录之前，不属于APK的文件系统内容，因此不会出现在META-INF目录内。签名块包含全量文件哈希、签名证书、签名算法等核心验证信息，apksigner工具直接读取该块完成签名验证。

Hook返回原签名的可行性 #

仍可实现，但需调整原签名的获取方式：

1. 预存原签名信息：开发阶段提取原APK的签名证书（X509Certificate）或完整签名块数据，加密存储在APP的安全区域（如native层加密文件）。
2. 适配Hook逻辑：除了适配API28+的SigningInfo构造，若遇到工具直接读取APK签名块的情况，需在native层拦截APK文件的读取操作，返回预存的原签名块数据，或HookZipFile相关的文件读取方法，替换签名块内容。

内容的提问来源于stack exchange，提问作者Viewed