VMP 后异常语义验证：类型、传播、资源释放与错误码一致性检查

为什么 VMP 可能改变异常语义

虚拟机保护将部分代码编译为自定义字节码并在虚机内执行，改变了原始方法的控制流与指令序列。异常处理依赖精确的栈展开、类型检查及 catch 块匹配，若虚机未完整实现这些语义，原本应被捕获的异常可能逃逸或发生类型失配。虚机还可能未正确处理异常表，导致 catch 类型匹配失败，让异常直接终止协程而未被上层捕获。

保护工具插入的完整性校验、反调试和环境检测代码也可能打断正常传播。当这些辅助逻辑在异常发生时执行，可能使 finally 块执行顺序错乱或资源未释放。尤其在协程取消等协作式异常中，额外检测易导致挂起点的恢复行为偏离预期，从而引发难以追踪的清理失效。

此外，VMP 可能导致异常对象的类型信息缺失或类加载器变更，使 instanceof 判断失败，破坏基于类型的异常路由。代码包裹边界被打乱后，原宿主的错误码映射可能被截断或返回不一致值。如果虚机内方法重排或常量池合并，整型错误码也可能映射到错误值，必须通过对比测试才能发现这些潜在畸变。

• 审查 VMP 配置是否针对异常抛出点做了特殊优化，可能导致符号丢失。
• 检查保护后 DEX 中 catch 类型描述符是否保持完整。
• 确认是否有全局异常处理器被新增或剥离。

构建异常契约测试集

构建可重复执行的异常契约测试集需覆盖普通协程传播、监督作用域隔离、finally 执行和资源清理等关键场景。每个用例必须使用公开可访问的 API 编写，不依赖项目自身业务逻辑或外部服务，确保测试结果在未保护和 VMP 保护两种形态下都能独立复现，避免因环境或依赖变化引入假阳性。

测试应设计为断言式验证，既检查异常类型和传播链长度，也记录副作用如资源关闭标志。若 VMP 在虚机内重写了异常实例化或传播规则，通常会导致 catch 块匹配失败或 cause 链断裂，契约测试必须能捕获这类偏差。通过精确断言可定位虚机实现中的语义漏洞。

先在未保护 APK 中执行普通 launch 与 supervisorScope 两类契约用例，再对保护版本运行同一套用例。普通 launch 应按既定关系传播异常，supervisorScope 应隔离兄弟任务；资源释放、错误码与 cause 链也要逐项断言。本节的 Python 脚本只读取测试产生的 JSON 报告并核对这些结果，不代替 Kotlin 测试本身。

• 测试用例必须是纯公开代码，不依赖项目内部秘钥或私有组件。
• 每个用例应明确自身状态分离，避免测试间污染。

#!/usr/bin/env python3
import sys
import json
from pathlib import Path

def load_verification_report(file_path: str) -> dict:
    """Load the public JSON verification result file."""
    path = Path(file_path)
    if not path.exists():
        raise FileNotFoundError(f"Report file not found: {file_path}")
    content = path.read_text(encoding="utf-8")
    return json.loads(content)

def validate_exception_semantics(report: dict) -> None:
    """Validate exception semantics based on input-derived variables."""
    # Extract input-derived variables from the report
    exception_type_match = report.get("exception_type_match", False)
    propagation_correct = report.get("propagation_correct", False)
    resource_released = report.get("resource_released", False)
    error_code_consistent = report.get("error_code_consistent", False)
    test_count = report.get("test_count", 0)
    
    # Condition 1: Ensure tests were actually executed
    if test_count <= 0:
        raise SystemExit(2)
    
    # Condition 2: Exception type must match expected contract
    if not exception_type_match:
        raise SystemExit(2)
    
    # Condition 3: Propagation behavior must be correct per scope rules
    if not propagation_correct:
        raise SystemExit(2)
    
    # Condition 4: Resources must be released even on failure paths
    if not resource_released:
        raise SystemExit(2)
    
    # Condition 5: Error codes must remain consistent after VMP transformation
    if not error_code_consistent:
        raise SystemExit(2)

def main():
    if len(sys.argv) < 2:
        print("Usage: python verify_semantics.py <report_json_path>", file=sys.stderr)
        raise SystemExit(1)
    
    report_file = sys.argv[1]
    try:
        report_data = load_verification_report(report_file)
        validate_exception_semantics(report_data)
        print("Verification passed: Exception semantics unchanged.")
    except FileNotFoundError as e:
        print(f"Error: {e}", file=sys.stderr)
        raise SystemExit(1)
    except json.JSONDecodeError as e:
        print(f"Invalid JSON format: {e}", file=sys.stderr)
        raise SystemExit(1)
    except SystemExit:
        raise
    except Exception as e:
        print(f"Unexpected error: {e}", file=sys.stderr)
        raise SystemExit(1)

if __name__ == "__main__":
    main()

在真实设备上运行 instrumented 测试并捕获异常

Android 异常行为受运行时、ART 版本、厂商修改和系统 API 影响，只依赖单元测试无法充分反映 VMP 影响。必须在真实设备或模拟器上执行 instrumented 测试，通过 adb 收集日志和异常堆栈。只有真实系统调用才能暴露因 VMP 间接导致的跨进程或 JNI 异常，例如方法 Hook 或资源 ID 冲突引发的未预期崩溃。

instrumented 测试还可调用真机系统服务、内容提供者和硬件特性，捕捉到类加载或资源冲突问题。如果保护导致方法代理或类重定向，这些测试更容易捕获到运行时行为偏离，从而发现静态分析无法检测的语义裂纹。

捕获测试结果时，需同时收集 logcat 输出、未捕获异常处理器日志和测试框架的断言结果。重点对比 VMP 前后两条产物的异常类型名称、堆栈第一帧的类名方法名、异常消息以及伴随的 cause 链。不能只依赖通过/失败标志，要分析传播路径细节，以区分保护引入的语义变化与环境波动。

如果测试涉及时间敏感的协程取消，必须确保设备环境稳定，避免因系统资源争抢导致假阳性。连续运行多轮并剔除异常的时序差异，才能将偏差归因于保护本身。测试中途重启设备可减少缓存和调度干扰，提升结果可信度。

• 确保测试 APK 使用与生产相同的 VMP 配置和签名。
• 基线结果必须与 VMP 版本严格同源，避免代码变动引入噪音。
• 设定失败阈值，一个异常语义偏差即视为阻断。

资源释放与错误码一致性检查

资源释放是异常安全性的关键部分。VMP 如果对 try-with-resources 或 Kotlin 的 use{} 函数进行内联或变换，可能导致 Closeable 对象的关闭顺序出错或未调用 close。必须构造在打开多个资源后抛出异常的场景，检查每个资源的 close 是否被执行，并验证关闭顺序是否符合后打开先关闭的预期规则。

错误码一致性要求对外暴露的错误代码在 VMP 前后完全相同。业务异常通常携带整型错误码，若 VMP 将常量池合并或混淆，可能映射到错误值。需要遍历所有公开的异常类型，捕获后提取错误码并与基线对比，确保客户端错误分支不会因保护而改变。

对于通过 JNI 或 Native 库产生的异常，保护可能影响 Java 异常类的构造或 Native 崩溃信号的翻译。应使用相同的输入调用 JNI 方法，检查抛出的异常类型和附带消息。如果无法在 VMP 版本中提供相同的 native 库，必须标记为无法验证并记录风险，同时考虑服务端补偿监控。

• 确认所有 close 方法是否可能被 VMP 虚机忽略。
• 核查混淆是否重命名了自定义异常类，导致 instanceof 失败。
• 对 Native 异常，若项目未提供未保护 SO，标记为无证据。

处理 VMP 导致的崩溃符号混淆

VMP 和后继的代码混淆会使异常堆栈中的类名和方法名变为无意义符号，导致分析困难。必须保留 VMP 构建产物对应的 mapping 文件，通过 retrace 工具还原 Java/Kotlin 层的堆栈帧。但 retrace 只能恢复编译期存在的符号，无法处理虚机自定义指令区生成的栈回溯。

若崩溃发生在虚机内部，堆栈通常直接指向 VMP runtime 的 stub 函数，此时只能依赖自定义诊断日志，无法还原原始逻辑。对于 Native 堆栈，VMP 修改 SO 文件可能破坏 unwind 信息，导致 native 崩溃完全不可读。应在保护前确认是否保留必要的 .eh_frame 或 .debug_info 节，并测试触发 native 异常时能否成功生成可解析的堆栈。

必须将 mapping 文件、保护后 SO 符号包与版本绑定归档，每次发版前故意触发各层异常，验证还原流程可用。如果发现不可还原的堆栈比例超过可接受阈值，应拒绝发布并要求保护厂商调整配置，避免线上调试陷入无法还原符号的调试困境。

• 每次 VMP 构建必须归档完整的 mapping 和符号包。
• 测试时故意触发各层异常，验证还原流程可用。
• 设定接受阈值，超过一定比例的不可还原堆栈则拒绝发布。

环境与配置依赖对异常语义的影响

在缺少充分设备覆盖时，只能保守评估 VMP 风险。异常测试通过仅表示已验证的组合可接受，未覆盖组合必须提供给决策者作为已知局限。不同 Android API 级别对异常处理机制的内部实现存在差异，ART 的编译优化策略也可能改变栈帧生成方式，VMP 在特定 API 级上的异常表现不能直接推导至其他版本。

芯片架构和厂商实现同样起作用，部分厂商会修改 ExceptionHandler 的行为或植入额外的崩溃监控，导致虚机内异常与原生行为偏离。项目证据尚未接入完整设备矩阵时，应列出测试使用的设备与 API 清单，明确结果只在这些条件下成立，不得推断未测试环境的行为。

推荐在 API 30、33 和 35 上使用 Google Pixel、Samsung 等至少三种厂商设备运行测试，并覆盖 arm64-v8a 和 x86_64 模拟器。模拟器行为不等同真机，只能作为补充，缺失的真机覆盖应记录为残余风险，并在发布说明中明确指出验证边界。

• 记录所有测试设备的 Android 版本、安全补丁级别和内核版本。
• 对于无真机覆盖的维度，明确写为“未测试”，不得推断行为。
• 每次发布时重新确认设备矩阵是否足以代表生产环境分布。

将异常契约集成到持续验证流水线

若项目尚未接入 CI/CD，至少应在 release 候选阶段手动执行核心契约测试。准备未保护和 VMP 保护两个 APK，运行同一套 instrumented test，并按异常类型、cause 链、finally 顺序、资源释放标志和错误码整理差异；任一字段不同都要回到对应保护函数定位。

任何断言失败或堆栈模式变化都应触发阻断，并归档完整对比报告供审查。为了让后续流程可重复，应将基线测试结果与 VMP 配置、目标 ABI 和 API level 绑定存储。如果 VMP 工具链更新，必须重新生成基线，不可复用旧记录，避免忽略保护算法变更带来的语义漂移。

即使尚未接入流水线，也可以建立本地自动化脚本串联安装、测试执行和日志比对步骤，减少人工误判。通过将对比流程脚本化，可逐步过渡到 CI 集成，并为未来扩充测试集留下扩展点。

• 测试 APK 必须与生产构建共享同一份异常契约代码。
• 差异对比流程应输出可读表格，指明每个用例的通过/失败与其对应异常链差异。
• 阻断规则不能因为测试环境波动而放宽，除非能证明偏差来自环境而非保护本身。

决策与行动建议

完成异常契约测试、资源检查和符号还原验证后，逐项比对两份产物的记录。异常类型、传播关系、finally 顺序、资源释放或错误码只要有一项变化，就先缩小对应函数的保护范围并复测；全部一致后，还要确认同一版本的 mapping 与 Native 符号包能够还原故意触发的测试崩溃。

对于没有实测数据的部分，必须明确标记为“未验证”，将其列为残余风险，并讨论服务端防护和活跃监控等补偿措施。不能利用未证实的保护效果作为安全保证，也不得将未测试环境的结论外推到生产全量。

最终决策应在投入收益平衡中权衡：VMP 带来的抗逆向强度提升是否值得接受已知的异常语义变化或受限的测试覆盖。如果异常测试出现偏差，工程判断可能需要降低保护强度或保留特定模块不进入虚机，以优先保证运行时稳定性。

• 发布前必须通过异常契约门禁。
• 未验证部分必须记录在安全发布说明中。
• 每次 VMP 更新后重新执行全部测试。