同一源码构建的 APK 摘要不同：从变体到签名的分层归因

先把问题拆成字节差异、构建差异与发布身份差异

两个 APK 的 SHA-256 不同，只能确定文件字节不完全相同，不能直接推出源码变化、构建被入侵或签名错误。差异可能来自合法的变体选择、依赖解析、资源生成、编译顺序、ZIP 元数据或签名，也可能来自未受控输入。调查的第一步不是寻找一个看起来合理的解释，而是保护两个原始文件，记录各自摘要、文件长度、取得时间和构建任务，再让每份后续报告引用对应摘要。

归因需要区分三个问题。字节层回答哪些区域不同；构建层回答哪些输入或工具步骤产生这些字节；发布层回答哪个文件才是经过批准、由正确证书签署并允许交付的候选。发现只有签名块不同，不等于可以任选一个发布；发现 DEX 相同，也不等于资源、Native 库或 Manifest 相同。每层都必须形成独立结论，不能用局部一致替代完整候选身份。

调查期间不要对原始 APK 执行会改写文件的操作。解压后重新压缩会改变条目顺序、压缩结果、时间字段、对齐和中央目录，重签名则会替换身份相关材料。需要展开内容时，应把只读解析结果写到独立工作目录，并同时保留工具版本与命令参数。若原始文件已经被覆盖，只能把证据状态标记为不完整，不能把重建文件冒充最初候选。

为每个 APK 建立不可混用的构建证据包

SLSA Provenance v1.1 把产物主体、构建者、构建类型、外部参数和解析后的依赖材料纳入构建证明。对 APK 差异排查而言，这些字段不是装饰信息，而是重放构建条件的入口。源码提交相同，但 Gradle 任务、product flavor、build type、版本号注入、环境变量或依赖解析不同，产物自然可能不同。证据包应逐项记录实际值，未知字段保持未知，禁止事后按印象补齐。

in-toto Attestation Statement v1 使用主体摘要与有类型的声明负载建立绑定，这提醒团队把报告与确切 APK 对齐。一个通用的构建日志即使内容真实，如果没有引用产物摘要，也可能被错误附到另一个候选上。工程上可为每次构建生成只读索引，列出 APK SHA-256、源码提交、流水线运行、构建任务、工具链摘要和证明文件摘要，再由后续门禁以这些标识取数。

NIST SP 800-218 SSDF 把来源、构建、验证和变更证据放入安全开发实践。落实到本次调查，需要同时保留源码状态、依赖锁定、构建容器或主机基线、生成步骤、测试回执和审批变更。SSDF 不会替你指出某个字节为何变化，但它提供了避免证据断裂的组织边界。没有这些记录时，可以继续做二进制差分，却不能声称已经证明构建过程完整可信。

先核对 build variant，再讨论编译器是否不确定

Android build variants 由 build type、product flavor、source set、applicationId 和签名配置等输入组合形成。同一仓库中的 release、staging、地区渠道或客户 flavor 可以选中不同资源、Manifest 片段、BuildConfig 值和签名配置。排查时要从流水线实际执行的 Gradle task 反推出完整 variant，而不是只看分支名或产物文件名。文件名可以被复制和重命名，variant 只能由构建记录和产物内容共同确认。

依赖解析是第二个高频分叉点。动态版本、变化模块、不同仓库响应、锁文件未提交、插件间接依赖和本地缓存都可能让相同源码得到不同 classpath。应导出与候选对应的解析依赖图，记录仓库与校验信息，并比较最终进入运行时、编译器和打包任务的坐标及摘要。只比较顶层 build.gradle 声明不够，因为实际选择版本可能来自约束、平台依赖或解析规则。

工具链和生成步骤也要进入比较。JDK、Gradle、Android Gradle Plugin、Build Tools、aapt2、D8 或 R8、NDK、CMake 以及代码生成器版本变化，都可能影响资源表、DEX、Native 对象或容器布局。时间、随机标识、绝对路径和不稳定遍历顺序若被写入生成文件，也会破坏重复构建。正确做法是先证明两次构建输入相同，再把剩余差异归入工具不确定性；不能从源码相同直接跳到编译器有问题。

ZIP 容器相同与条目内容相同是两种结论

APK 采用 ZIP 容器，但比较不能止于解压目录。两个 APK 可以包含相同条目内容，却因条目顺序、压缩算法或级别、时间字段、额外字段、文件属性、对齐填充和中央目录布局不同而得到不同摘要。规范化条目清单适合先回答内容是否一致：按条目名排序，记录未压缩内容 SHA-256、长度、CRC、压缩方式和容器元数据，再把整个文件摘要作为独立字段保留。

如果规范化内容摘要一致而整个 APK 摘要不同，调查范围应收窄到容器布局和签名相关区域，但不能直接宣布只是时间戳。先比较条目顺序与元数据，再定位第一个字节偏移；随后用 Android 签名工具检查签名方案和证书。APK Signing Block 位于 ZIP 条目之外，普通解压工具不会把它显示成 META-INF 文件，因此条目清单一致仍可能伴随签名块差异。

如果某个条目内容摘要不同，应先按责任层分组，而不是立即反编译全包。AndroidManifest.xml 与 resources.arsc 指向清单和资源合并，classes*.dex 指向 Java 或 Kotlin 编译、压缩与优化，lib/* 指向 Native 构建，assets 与 res 指向打包材料，META-INF 中的部分文件与 v1 签名或依赖元数据有关。分组后再选择专用解析器，能让调查保持可复核和可停止。

Manifest、资源、DEX 与 Native 差异要用各自的证据语言

AndroidManifest.xml 是二进制 XML，直接比较原始字节可以发现变化，却不容易解释合并来源。应使用固定版本的解析工具导出规范化结构，比较 applicationId、versionCode、uses-sdk、组件、权限、exported 状态、provider authority 和元数据，同时保留原始条目摘要。若差异来自占位符或 source set，回到 variant 与 Manifest merger 输入；若规范化语义相同但字节不同，再检查属性顺序、字符串池和工具链。

resources.arsc、res 与 assets 需要区分资源身份和内容。资源 ID、压缩策略、语言或密度裁剪、生成图标、渠道配置和依赖资源合并都会改变产物。只比较文件名会漏掉同名内容变化，只比较解码后的图片也会忽略原始编码和资源表引用。调查报告应记录资源表摘要、差异条目、配置限定符和来源模块；无法追溯来源的资源变化必须保持待确认，不能归类为无害。

DEX 与 Native 库属于可执行层，但字节差异不自动等于业务语义变化。D8 或 R8 版本、依赖顺序、混淆映射、优化规则、调试信息和类排序可能改变 DEX；编译器、NDK、链接器、构建标识与符号处理可能改变 .so。应先比较文件摘要和结构清单，再结合 mapping、依赖图、符号与源码变更定位。没有当前候选的运行回归时，只能报告结构差异和待验证影响。

签名差异必须在原始 APK 上独立验证

AOSP app signing 说明 Android 使用应用签名建立更新身份，不同签名方案覆盖不同文件区域与平台版本。两个内容接近的 APK 如果证书不同，可能无法作为同一应用的正常更新；两个证书相同的 APK 仍可能包含不同业务内容。签名因此既是差异来源，也是发布身份门禁，但不是代码安全或加固强度证明。报告应分别记录证书摘要、验证结果和各方案覆盖。

Android apksigner 可以签名并验证 APK 的签名方案和证书，且签名完成后继续修改 APK 会使相关签名失效。调查时应对收到的原始文件运行 verify，并保留工具版本、命令、退出状态、证书摘要与方案结果。不要为了让两包可比较而先用同一密钥重签，也不要从 META-INF 文件存在与否推断全部方案；v2 及更高方案使用的 Signing Block 不等同于普通 ZIP 条目。

签名结果还要回到发布流程。若两个 APK 来自不同阶段，例如一个是加固前输入、一个是渠道重签后的输出，它们摘要不同可能符合流程设计，但仍需一条受批准的转换链把输入、处理步骤、输出和证书绑定。若团队期望同阶段重建可复现，签名时间、密钥选择和签名工具必须进入受控输入。流程解释不存在或与证据冲突时，正确动作是停线调查，而不是把差异标成渠道正常。

把可解释差异、可复现构建和可发布候选分开验收

可解释差异的最低标准是指出变化位于哪个层、由哪个已记录输入或步骤产生，并能用当前证据复核。例如渠道 flavor 增加一项资源、签名阶段更换批准证书，属于有来源的解释。可复现构建的标准更严格：在受控且声明相同的源码、依赖、工具链、参数和签名输入下，独立重建得到相同字节。一次解释成功不能替代重复构建，重复构建相同也不能证明源代码没有安全问题。

发布候选还需要单独的审批闭环。最终交付记录应引用唯一 APK 摘要、版本与 variant、证书摘要、构建证明、差异报告、测试回执和批准人。任何后续复制都再次计算摘要，不允许用相同文件名或目录位置继承身份。若调查发现的差异符合预期但当前摘要未在审批记录中，仍应更新记录或重新批准，不能口头把陌生产物纳入发布。

持续集成门禁应优先减少重复劳动。每次构建自动产出规范化 ZIP 清单、分层摘要、variant、解析依赖和签名验证摘要；只有整体摘要变化时才进入差分，并从首个不同责任层开始。相同来源回执和工具版本可以复用，但每个候选的产物摘要与差分结论必须新生成。这样既能快速确认无变化，也能避免每次都重新反编译全部内容。

• 两个原始 APK 已只读保存并分别计算 SHA-256
• 构建任务、variant、依赖与工具链均绑定候选
• ZIP 容器和条目内容使用不同结果字段
• Manifest、资源、DEX 与 Native 差异分别归因
• 原始 APK 已通过 apksigner 检查并记录证书
• 可解释、可复现与可发布形成三个独立结论

用只读脚本生成规范化条目清单并定位首个分层差异

下面的 Python 脚本接收两个 APK 路径，先计算完整文件 SHA-256，再以只读方式遍历 ZIP 条目。它按路径对条目归入签名元数据、Manifest 与资源、DEX、Native、普通资源和其他层，记录未压缩内容摘要、长度、CRC、压缩方式与 ZIP 时间字段，最后输出第一个不同条目或容器级差异。输入缺失、不是有效 ZIP、出现重复条目名或读取失败时返回非零状态。

脚本不能解析 APK Signing Block，也不能判断两个不同 DEX 是否业务等价。若全部普通条目内容一致而完整 APK 摘要不同，输出会提示继续检查 ZIP 布局和 Signing Block；此时应在原始文件上运行 apksigner，而不是据此断言差异来自签名。时间字段被记录为线索，但不能单独成为根因，仍需与打包任务、条目顺序和第一个字节偏移交叉验证。

申请 APK 商业加固评估前，可准备原始候选、源码提交、构建 variant、解析依赖、工具链、签名证书摘要、规范化差异清单和真实设备回归范围，再从御盾中央平台提交申请。评估资料越精确，越容易明确哪些业务代码、Native 模块和发布环节需要保护；没有当前候选和验证回执时，不宣称差异已消除、攻击被阻断或兼容矩阵已经通过。

• 脚本只读取原始 APK，不解压覆盖和不重打包
• 完整文件摘要与条目内容摘要分别保存
• 重复条目、无效 ZIP 和读取错误产生非零退出
• 首个差异按 Manifest、资源、DEX、Native 或签名线索归类
• 普通条目一致时继续检查 ZIP 布局与 Signing Block
• 脚本结果绑定工具版本并进入人工发布判断

from pathlib import Path
from zipfile import ZipFile, BadZipFile
import hashlib
import json
import re
import sys

def sha256_stream(handle):
    digest = hashlib.sha256()
    for chunk in iter(lambda: handle.read(1024 * 1024), b""):
        digest.update(chunk)
    return digest.hexdigest()

def file_sha256(path):
    with path.open("rb") as handle:
        return sha256_stream(handle)

def layer_for(name):
    if name.startswith("META-INF/"):
        return "signature-metadata"
    if name == "AndroidManifest.xml" or name == "resources.arsc":
        return "manifest-resources"
    if re.fullmatch(r"classes(?:[2-9][0-9]*)?\.dex", name):
        return "dex"
    if name.startswith("lib/") and name.endswith(".so"):
        return "native"
    if name.startswith(("res/", "assets/")):
        return "packaged-resources"
    return "other"

def apk_manifest(path):
    result = {}
    seen = set()
    try:
        with ZipFile(path, "r") as archive:
            for info in archive.infolist():
                if info.is_dir():
                    continue
                if info.filename in seen:
                    raise SystemExit(3)
                seen.add(info.filename)
                with archive.open(info, "r") as handle:
                    content_hash = sha256_stream(handle)
                result[info.filename] = {
                    "layer": layer_for(info.filename),
                    "sha256": content_hash,
                    "size": info.file_size,
                    "crc32": f"{info.CRC:08x}",
                    "compression": info.compress_type,
                    "zipTime": list(info.date_time),
                }
    except (BadZipFile, OSError, RuntimeError):
        raise SystemExit(2)
    return result

def first_difference(left, right):
    for name in sorted(set(left) | set(right)):
        if name not in left:
            return {"entry": name, "kind": "only-right", "layer": right[name]["layer"]}
        if name not in right:
            return {"entry": name, "kind": "only-left", "layer": left[name]["layer"]}
        for field in ("sha256", "size", "crc32", "compression", "zipTime"):
            if left[name][field] != right[name][field]:
                return {"entry": name, "kind": field, "layer": left[name]["layer"]}
    return None

if len(sys.argv) != 3:
    raise SystemExit(2)
left_path, right_path = map(Path, sys.argv[1:])
if not left_path.is_file() or not right_path.is_file():
    raise SystemExit(2)
left_entries = apk_manifest(left_path)
right_entries = apk_manifest(right_path)
left_apk = file_sha256(left_path)
right_apk = file_sha256(right_path)
difference = first_difference(left_entries, right_entries)
if difference is None and left_apk != right_apk:
    difference = {"kind": "container-or-signing-block", "action": "inspect ZIP layout and run apksigner verify"}
print(json.dumps({"leftApkSha256": left_apk, "rightApkSha256": right_apk, "firstDifference": difference}, ensure_ascii=False, indent=2))