Wake 没报 tx.origin：检查 detector 来源、过滤和屏蔽
链小知 · 进阶 · 核验 · 依官方文档整理
定位 Solidity 静态检测的扫描覆盖，并区分授权钓鱼风险与账户抽象兼容问题。
开始前准备
- 准备可以编译的 Solidity 工程副本、Wake 实际版本与既有扫描结果；编译器/依赖已在本地准备。
- 只使用静态 detector 路径；不要执行工程中的部署或钱包脚本。源码仍须人工检查，扫描零报告不是安全证明。
1. 确认命令与 detector 来源
在项目目录查看 wake detect --help 与 wake detect list，确认存在 tx-origin，并记录加载来源。本地 ./detectors 或全局同名插件会优先覆盖包内 detector；名字相同不保证执行的是官方实现。先解决编译错误，再判断扫描是否真的完成。
检查结果：tx-origin 可用、来源明确；无未解决的编译错误。
2. 对目标文件运行指定检测器
使用 wake detect tx-origin 检查该项目，或按帮助给出目标合约路径。对比全项目 wake detect all 的结果时，把扫描路径、min-impact 和 min-confidence 一起记录；只扫 utils 或设高阈值可能将相关合约/发现排除。
检查结果：扫描范围覆盖实际授权函数，阈值没有隐式改变比较口径。
3. 沿着发现位置读授权条件
找到报告对应函数、源码行和条件。如果用 tx.origin == owner 作为授权，按调用链推演：owner 调用中间合约，再由中间合约调用目标，tx.origin 仍为 owner。报告提示应进一步检查权限设计；不能仅把 tx.origin 字符串替换后便宣布修复。
检查结果：每个发现有实际可定位的源码条件和调用链解释。
4. 区分影响与置信度、兼容分支
Wake 消息第一标签为 impact、第二为 confidence，不能把二者互换。tx-origin 也会提示 tx.origin == msg.sender 等 EOA 限制对 ERC-4337 用户的影响；account-abstraction 检查默认开启。若该分支被关闭，应在结果里说明未覆盖这一类问题。
检查结果：记录两类标签，并明确钓鱼授权与账户抽象兼容发现各自的条件。
5. 核对隐藏报告的配置再复验
搜索目标文件附近 wake-disable-line、wake-disable-next-line、wake-disable 及匹配 detector 名称，同时检查 wake.toml 的 detector 设置。无名称屏蔽会覆盖所有检测；编译错误却不能被这种注释忽略。调整有依据的配置或代码后比较扫描结果，保留人工判断和剩余覆盖限制。
检查结果：对零报告能说明路径、阈值、屏蔽、detector 来源与编译状态，不以零报告代替审计。
怎样确认完成
- 完整保留 detector 来源、扫描范围、编译状态、标签和屏蔽配置。
- 官方文档核对未包含实际编译、执行或合约漏洞利用测试。
常见错误与边界
- 同名自定义 detector 的行为可能不同，不能只看命令名字。
- 关闭 account-abstraction 分支不等于修复兼容问题。
- 静态 detector 提示需结合授权语义与调用路径，扫描通过不能证明资金安全。