智能合约字节码取证：三层验证技术

Wiki 路径

本条目位于 FinWiki 索引下。请与 Fork and Rebrand 项目的五层审计框架 对照阅读；更广义的基础设施边界见 系统基础设施。

[!info] TL;DR 当项目方公开的已验证合约与 GitHub 源码不一致时，链上字节码才是事实基准。三层验证包括：(1) 比对链上部署字节码与 GitHub 源码的本地编译结果；(2) 逆推 4-byte PUSH4-EQ 分发器以提取函数选择器，并比对未验证合约的接口；(3) 使用跨链已验证孪生合约指纹锁定团队身份。

第一层：部署字节码与编译结果差异

• 使用 eth_getCode(addr, "latest") 取得链上运行时字节码。
• 按 GitHub 源码、项目方明示的 solc 版本和优化器设置进行本地编译。
• 若差异非空，即表明链上版本与 GitHub 版本不一致，是需要进一步调查的信号。
• 比对前应剥离 immutable、构造函数参数和元数据哈希造成的差异。

第二层：逆推 4-byte PUSH4-EQ 分发器

• EVM 合约进入分发器时通常以 PUSH4 selector EQ JUMPI 模式分支。
• 即使合约未验证，也可从 opcode 序列中提取全部 4-byte selector。
• 可通过 4byte.directory / openchain.xyz 反查函数签名。
• 若命中 ERC-20、暂停、黑名单、迁移等敏感接口，应视为风险信号。

第三层：跨链已验证孪生合约指纹

• 同一团队向多条链部署时，经常出现一条链已验证、另一条链未验证的情形。
• 将已验证一侧的运行时字节码在剥离元数据哈希后作为指纹。
• 在未验证链一侧实施字节码相似度匹配，例如 SimHash 或 k-gram。
• 命中后可形成“同一团队”的身份锚点；商业化 全球加密资产 forensics vendor 层 —— Chainalysis / Elliptic / TRM / Crystal 比较 已将这一层商品化为跨链集群标签库。

适用场景

• 核心合约（bridge / vault / governance）被有意保持未验证。
• 项目方 GitHub 已删除，但链上合约仍在运行。
• 跨链项目需要识别“表面治理结构”与“真实开发团队”的差异。
• 怀疑存在后门、紧急暂停或黑名单接口；在 DMM Bitcoin 流出事件 详细分析（2024-05）—— 归属 Lazarus 的 4,502.9 BTC、Bybit Lazarus $14.6 億 黑客详细分析(2025-02)— 史上最大加密资产外流 等交易所事件中，攻击者曾部署未验证中继合约。

不适用场景

• 合约已完全验证且源码可信，此时直接阅读源码即可；形式化规格 ↔ 实现 co-design 等规格优先方法更有效。
• proxy 合约应先通过 EIP-1967 storage slot 确认 implementation 后再分析。
• 纯只读 view 合约风险较低，通常无需采用完整三层取证流程。

Provenance

• 案例研究：链上一部分核心合约已验证，但 bridge / vault 系列中的若干合约闭源。三层验证用于逆推未验证合约接口，并通过跨链孪生合约指纹锁定团队身份。