APK v1 签名怎样发现未覆盖或异常 ZIP 条目

先给结论：验签结果与条目覆盖清单要同时保存

APK v1 签名采用 JAR 风格的逐条目摘要材料。发布门禁不能只记录 apksigner verify 返回成功，还要从最终候选枚举 ZIP 条目，并把有效负载与 META-INF/MANIFEST.MF 中的 Name 段落对应。这样才能发现清单未登记、清单指向不存在对象、重复名称和路径规范化冲突等需要复核的结构问题。

独立清单工具不能替代 Android 平台验签。它只回答候选包含什么、v1 清单声明覆盖什么以及结构是否存在歧义；签名方案有效性、证书身份和目标系统兼容仍由 apksigner 与真实安装路径验证。门禁应把两类回执并列保存，不把自写脚本的 pass 写成平台已接受。

现代 APK 还可能包含 v2 及更高签名方案。v1 的条目模型与 v2 的 APK Signing Block 覆盖方式不同，不能用一份 MANIFEST.MF 清单推导整包签名结论。发布报告应记录目标最低系统、各方案验证结果、最终证书和候选摘要，明确哪些结论属于 v1 覆盖审计，哪些属于平台签名验证。

先理解 MANIFEST.MF、SF 与签名块的不同职责

v1 签名材料通常位于 META-INF。MANIFEST.MF 以分段形式记录条目名称和摘要属性，SF 文件与相应签名块承担签名材料角色。覆盖审计重点是解析 MANIFEST.MF 的 Name 段落并与 ZIP 有效负载比较，不应把 SF、RSA、DSA、EC 或其他签名元数据本身当作普通业务负载再次要求同样记录。

解析不能只用逐行正则搜索。Manifest 属性可能存在续行，段落由空行分隔，名称需要在解折叠后读取。工具应保存原始字节并严格处理编码错误，遇到重复 Name、空名称或无法解析的段落时失败关闭。静默忽略异常段落会把未知覆盖状态伪装成完整。

条目存在清单摘要不等于摘要算法和签名链已经被平台接受。自写工具若进一步计算摘要，也只能检查文件内容与清单值的关系，不能复现全部平台验证规则。更可靠的边界是结构审计负责条目对应，apksigner 负责签名方案和证书验证，设备测试负责目标安装与升级路径。

最终 APK 条目清单要先消除名称歧义

ZIP 可以包含重复文件名，解析库和下游工具对重复项的选择可能不同。覆盖审计应使用 infolist 保留所有物理条目，先检查完全重复名称，再检查移除多余分隔、点段或反斜线后的规范化冲突。发现冲突时不应猜测哪个条目生效，也不应靠清单中出现一次名称就放行全部重复对象。

路径安全也属于结构门禁。绝对路径、父目录段、空名称和反斜线混用都需要报告，工具绝不能把 APK 条目直接解压到工作目录。审计只读取中央目录与必要的 MANIFEST.MF 字节，限制条目数量和清单大小，避免把异常包当成普通输入处理。公开代码应以只读方式工作。

条目分类要基于规则并保存原因。目录项、Manifest 和签名元数据进入 metadata；其余代码、资源、原生库和 assets 进入 payload。某些工具链可能产生额外 META-INF 业务元数据，不能简单把整个目录排除。规则应只排除明确的签名材料，其余条目仍进入覆盖比较或人工复核。

未登记、悬空与重复 Name 都需要失败关闭

payload 条目存在于 APK，却没有对应 MANIFEST.MF Name 时，结构审计应输出 uncovered。它不立即声称平台一定接受未签名内容，因为实际结果还受签名方案和平台验证影响，但发布不能忽略这个差异。团队需要确认该条目为何缺失、目标最低系统如何处理，以及 v2 及更高方案是否按预期存在。

MANIFEST.MF 中出现 Name，但 ZIP 找不到对应条目，应输出 dangling。它可能来自构建残留、名称编码差异或后处理删除。即使 apksigner 对目标系统范围给出通过，悬空段也说明构建链与清单不一致，至少需要来源解释和可重复构建证据，不能把异常当作无害噪声长期保留。

重复 Name 段落会让结构语义不清，重复 ZIP 名称则让物理条目选择不清。门禁应分别报告 manifestDuplicates 和 zipDuplicates，并拒绝用集合去重掩盖。只有修复构建输入并重新生成、对齐、签名和验签，才能产生新的 publish-ready 候选；手工删除一项会改变文件身份和签名状态。

apksigner 结果必须覆盖方案、证书和系统范围

apksigner 可以验证 APK 的签名方案和证书，并根据目标 SDK 范围评估验证结果。发布流水线应固定工具版本，保存完整原始输出、退出状态、证书摘要和各方案结果。只截取最后一行 success 会丢失警告、方案覆盖和 signer 信息，也无法在后续调查中还原当时输入。

条目扫描与 apksigner 的关系是交叉核对。扫描器报告 v1 清单结构，apksigner 判断平台签名验证；两者结果不一致时，门禁保持 blocked 并调查工具输入、最低系统和候选摘要。不能修改扫描规则去迁就一次验签，也不能用自写摘要计算替代 apksigner。

签名有效只证明完整性与签名者身份范围，不证明业务代码安全。攻击面还包括应用内授权、服务端校验、运行时输入和分发渠道。文章不会把 v1 覆盖完整写成无法重打包，也不会把验签失败写成所有风险已被阻断。结论只描述实际工具与候选观察。

v2 及更高方案要和 v1 分层记录

APK Signature Scheme v2 使用 APK Signing Block 覆盖文件主体，并包含防止降级到较弱方案的机制。它与 v1 的逐条目清单模型不同。现代发布不能因为 MANIFEST.MF 对应完整就忽略 v2 及更高方案，也不能因为 v2 验证通过就删除 v1 兼容审计，具体要求取决于应用支持的系统范围。

方案矩阵应以目标最低系统为输入，记录 v1、v2 和候选包含的更高方案分别是否存在、验证是否通过以及 signer 是否符合允许策略。报告需要区分 absent、verified、failed 和 not-required，不能把所有状态压成一个 signed 布尔值。系统范围改变后要重新计算门禁。

降级保护是平台签名方案能力的一部分，不是项目已阻断所有重新打包的证明。分发渠道、用户安装来源、包名模仿和服务端接入仍有独立风险。签名门禁只负责官方更新身份和候选完整性证据，业务系统仍要核对账号、设备、版本和授权。

对齐、签名和渠道处理的顺序不能颠倒

Android zipalign 文档要求在 apksigner 之前完成对齐，并可单独验证对齐结果。对齐会改变 APK 字节布局，签名之后再次执行会使原签名回执失效。发布流水线应固定顺序为构建、必要后处理、对齐、签名、验签和归档，不能为修复条目问题直接编辑已签名包。

渠道元数据和资源处理也必须发生在身份冻结之前。任何注入、删除、重压缩或重排都可能改变文件摘要和签名状态。若渠道必须产生多个最终包，每个包都需要独立条目清单、对齐回执、apksigner 回执和候选摘要，不能共用母包证据。

构建顺序正确仍不证明密钥治理正确。Android 发布文档区分应用签名密钥、上传密钥和证书责任，Play App Signing 还可能让上传对象与设备交付对象具有不同角色。条目覆盖报告必须标明 artifactRole，避免用上传包或中间包替代最终设备 APK。

用只读代码生成 v1 条目覆盖差异

自动扫描器应只读取最终 APK，不解压文件到磁盘。它先检查 ZIP 条目数量、重复名称和不安全路径，再读取受限大小的 MANIFEST.MF，处理续行并提取 Name。签名元数据采用明确规则分类，其余 payload 与 Name 集合比较，输出 uncovered、dangling、duplicates 和 collisions。

下面的 Python 示例使用 zipfile.infolist 保留重复物理条目，通过 PurePosixPath 检查路径，并解析 MANIFEST.MF 段落。它不读取私钥、不修改 APK、不执行条目内容，也不尝试复现 Android 签名验证。发现结构异常时输出 JSON 后失败，便于流水线保留证据并阻止自动发布。

脚本通过只表示清单对应关系在该规则下没有发现异常，不表示 v1 摘要值、证书或其他签名方案有效。正式门禁仍要运行 apksigner，并把工具输出、候选摘要、系统范围和允许证书绑定。若自定义工具链产生特殊 META-INF 条目，需要在规则中逐项登记理由，不能直接排除整个目录。

from pathlib import Path, PurePosixPath
from collections import Counter
import json
import sys
import zipfile

if len(sys.argv) != 2:
    raise SystemExit("usage: audit_v1_entries.py application.apk")

apk_path = Path(sys.argv[1]).resolve()
if not apk_path.is_file():
    raise SystemExit(f"APK missing: {apk_path.name}")

def is_signing_metadata(name):
    upper = name.upper()
    if upper == "META-INF/MANIFEST.MF":
        return True
    if not upper.startswith("META-INF/"):
        return False
    leaf = upper.rsplit("/", 1)[-1]
    return leaf.endswith((".SF", ".RSA", ".DSA", ".EC")) or leaf.startswith("SIG-")

def normalized_name(name):
    return str(PurePosixPath(name.replace("\\", "/")))

with zipfile.ZipFile(apk_path) as archive:
    entries = archive.infolist()
    if not entries or len(entries) > 200000:
        raise SystemExit("APK entry count is empty or outside the review limit")
    names = [entry.filename for entry in entries if not entry.is_dir()]
    exact_duplicates = sorted(name for name, count in Counter(names).items() if count > 1)
    unsafe_paths = sorted(name for name in names if name.startswith("/") or ".." in PurePosixPath(name.replace("\\", "/")).parts)
    normalized = [(name, normalized_name(name)) for name in names]
    groups = {}
    for original, canonical in normalized:
        groups.setdefault(canonical, []).append(original)
    normalized_collisions = {key: value for key, value in groups.items() if len(set(value)) > 1}
    manifest_candidates = [entry for entry in entries if entry.filename.upper() == "META-INF/MANIFEST.MF"]
    if len(manifest_candidates) != 1:
        raise SystemExit("APK must contain exactly one META-INF/MANIFEST.MF for this v1 audit")
    manifest_entry = manifest_candidates[0]
    if manifest_entry.file_size > 8 * 1024 * 1024:
        raise SystemExit("MANIFEST.MF exceeds the review size limit")
    manifest_text = archive.read(manifest_entry).decode("utf-8", errors="strict").replace("\r\n", "\n")

lines = manifest_text.split("\n")
unfolded = []
for line in lines:
    if line.startswith(" ") and unfolded:
        unfolded[-1] += line[1:]
    else:
        unfolded.append(line)
manifest_names = []
for line in unfolded:
    if line.startswith("Name: "):
        value = line[6:]
        if not value:
            raise SystemExit("MANIFEST.MF contains an empty Name attribute")
        manifest_names.append(value)
manifest_duplicates = sorted(name for name, count in Counter(manifest_names).items() if count > 1)
payload = sorted(name for name in names if not is_signing_metadata(name))
manifest_set = set(manifest_names)
uncovered = sorted(set(payload) - manifest_set)
dangling = sorted(manifest_set - set(names))
report = {
    "apk": apk_path.name,
    "payload_count": len(payload),
    "manifest_name_count": len(manifest_names),
    "uncovered": uncovered,
    "dangling": dangling,
    "zip_duplicates": exact_duplicates,
    "manifest_duplicates": manifest_duplicates,
    "normalized_collisions": normalized_collisions,
    "unsafe_paths": unsafe_paths,
    "next_gate": "run apksigner verify and bind its full output to this APK digest",
}
print(json.dumps(report, ensure_ascii=False, indent=2))
if any((uncovered, dangling, exact_duplicates, manifest_duplicates, normalized_collisions, unsafe_paths)):
    raise SystemExit("v1 entry coverage audit found review-blocking differences")

发布证据要让下一次构建能够复算

NIST SSDF 强调保留来源、构建、验证和变更证据。对应 v1 覆盖审计，证据包包含最终 APK 摘要、ZIP 条目清单、MANIFEST.MF 原文、解析器版本、结构差异、zipalign 回执、apksigner 原始输出、证书摘要、系统范围和构建来源。所有材料必须指向同一候选。

报告要区分事实与限制。可以登记候选有多少物理条目、是否存在重复名称、哪些 payload 缺少 Name、apksigner 对哪些方案给出什么结果；不能写成所有文件绝对可信、无法重新打包、密钥没有泄露或业务授权正确。没有项目数据时也不提供客户、排名、流量和性能数字。

准备实际审计时，可先查看[APK、DEX 与签名完整性指南](/zh-cn/apk-dex-signing-integrity/)，整理最终 APK、目标系统、签名方案、证书允许策略和渠道步骤。需要提交候选，可从[御盾中央平台申请加固服务](https://www.leonadev.com/console/)。材料应脱敏，登录、价格、购买和控制台操作统一由中央平台承接。

• 审计对象是最终 APK，并绑定文件 SHA-256
• ZIP 物理条目与 MANIFEST.MF Name 已双向比较
• 重复名称、规范化冲突和不安全路径均失败关闭
• v1、v2 及候选更高方案分别记录验证状态
• zipalign 位于签名之前，签名后没有任何修改
• 上传、中间、渠道和设备交付对象角色明确
• 结构通过、验签通过和业务安全保持不同边界