Etherealm EasyTool Bridge：面向 SMI SSD Controller 的 Agentic 硬件 Harness

数据时间：2026-06-28 Asia/Shanghai
研究对象：Etherealm EasyTool Bridge、ezt_hook、Silicon Motion NVMe SSD Controller、EasyTool / MPTool 工程链
报告类型：存储芯片产品路线、Agentic 硬件 Harness 与实现路径专题
资料来源：Etherealm EasyTool Bridge README / RPC contract、SM2268XT2 MPTool DumpISP 路径、SMI NVMe MPISP patcher 文档索引、既有 EasyTool / ROMDEBUG / Health Percentage 存储芯片专题

样本边界：

当前产品基线来自 ezt-hook/0.7 与已验证的 SM2268XT2、SM2267XT EasyTool profile；SM2269XT 和其它厂商主控属于后续扩展方向，RVA、ABI 与 helper 假设均需重新验证。
Bridge 的默认策略是 observe-first 和 read-first。writeBlock、eraseBlock、drive.resetToRom、mpisp.download 这类会改变设备状态的能力，仅在明确授权、完整备份、回读验证和可回滚方案存在时进入流程。
ezt_hook 定位为 EasyTool runtime bridge。MPISP 固件 patch、控制器 SRAM/RAM 读写和通用 Data-Out opcode 发送分别归入其它专用链路；当前 RPC 暴露 opcode.read，写侧 opcode 以固定语义接口处理。
本文讨论产品化和工程路线；实验样本上的地址、函数名、opcode 行为均按样本坐标处理，跨 Silicon Motion 全系列使用前需要重新确认。

核心判断

Etherealm EasyTool Bridge 的产品价值，是把上一代 Win32/VCL 原厂工具里的隐含能力，转换成 Agentic 时代可调用、可审计、可复现、可限权的硬件 Harness。

Silicon Motion SSD Controller 的现场研究长期卡在三个断点：原厂工具能做事，脚本化能力弱；host command 能观察，稳定证据包薄弱；AI 能读代码和推理路径，需要一层安全控制面隔离写坏设备的动作。Bridge 正好填这个空位：它把 EasyTool 进程变成一个受 profile 约束的本机 JSON-RPC target，让 agent 通过明确定义的方法去看、读、记录、比对，并在授权后执行有限动作。

这意味着 ER 面向存储主控的产品方向可以从“工具集合”升级成“硬件实验控制面”：

维度	传统逆向/恢复工具	Etherealm EasyTool Bridge
工具入口	人手点 UI、读弹窗、看二进制 log	`ping`、`info`、`ui.`、`captures.`、`listSysBlocks`、`readBlock`、`opcode.read`
证据形态	截图、零散 bin、一次性脚本输出	`events.jsonl`、`summary.json`、command capture、raw+spare、manifest、hash
AI 参与方式	事后看材料、写分析、猜下一步	通过能力 contract 读取事实、生成 runbook、触发只读流程、要求人类授权高风险动作
安全边界	靠操作者临场克制	profile、方法白名单、dangerous action gate、前置证据检查、回读比较
可扩展性	每个 EasyTool 版本重做一套经验	profile 化 RVA / ABI / capability，跨 SM2268XT2、SM2267XT，再扩展到 SM2269XT 和其它厂商

Bridge 的长线形态应该是硬件层面的 AI Harness：给 agent 一个可控实验台，把高风险动作收进带保险的执行通道。

现有工程已经具备的产品骨架

当前 ezt_hook 已经从 MP2 子项目附属 hook 拆出，成为独立的 Etherealm EasyTool Bridge runtime，核心形态是：

text

ezt_hook_launcher.exe
  -> 启动或注入 EasyTool
  -> 设置 log dir、RPC port、profile、token、console、危险开关

ezt_hook.dll
  -> 进入 EasyTool 进程
  -> 匹配 profile
  -> 安装 IAT / inline observe hook
  -> 启动 127.0.0.1 JSON-RPC server
  -> 写 events.jsonl / summary.json / optional command buffers

当前能力可以分成五层。

层	已有能力	产品意义	边界
存活与身份	`ping`、`info`、`profiles.list`	确认连到当前 DLL、当前 EasyTool、当前 profile 和能力开关	旧 DLL、旧进程、fallback profile 必须显式暴露
UI 复用	`ui.tree`、`ui.getText`、`ui.setText`、`ui.click`、`ui.check`、`ui.comboSelect`、`flash.click*`	对未知页面和隐藏页做 smoke test，复用 EasyTool 控件	依赖窗口文本、页签、语言和当前状态
命令观察	`captures.list/get`、`events.jsonl`、可选 `commands/`	记录 EasyTool 实际发出的 IOCTL、NVMe CMD、Features CMD	observe-only，参数和返回值保持原样
只读硬件事实	`listSysBlocks`、`readBlock`、`opcode.read`	读取系统块、raw+spare、D1 telemetry、SMART LID、`C2/0x53` PE/EC	`opcode.read` 限定 Data-In；`C2/0x53` 是读侧视图，写入语义需另行证明
受控状态改变	`writeBlock`、`eraseBlock`、`drive.reset`、`drive.resetToRom`、`mpisp.download`	为后续受控实验预留执行通道	常规自动流程保持只读；状态改变由 policy、备份、回读和人类授权包住

两个 profile 已经给产品化提供了样板：

profile	目标	当前能力含义
`sm2268xt2-easytools-y0408a`	SM2268XT2 / Y0408A-compatible	直接 Flash helper、`opcode.read`、NVMe CMD observe、Features CMD observe、reset、MPISP download
`sm2267xt-easytools-t0831a`	SM2267XT / V2.7.10_T0831A	SM2267 ABI 下的 Flash read/write/erase、Features CMD helper、`opcode.read`、reset、MPISP download
`generic-easytools-ui`	未识别 EasyTool	只保留 IAT、UI 和 RPC 的安全观察面

这套 profile 机制很重要。它让 Bridge 放弃“一个 hook 通吃所有 EasyTool”的幻觉，把每个 EasyTool 版本的 SHA、image size、helper RVA、Flash ABI、dangerous gate 都落成可审计的能力声明。Agent 接触能力 contract，进程内存访问收在 runtime 内部。

为什么 EasyTool 是第一个好切口

SMI 主控研究里已经存在三条线：

MP2 / Secondary MPTool hook：适合观察生产流程、runmode、MessageBox、vendor command、退出点。
MPISP / ISP patcher：适合做设备侧 payload、container hash 修复、CustomerId / Health 这类固件语义实验。
EasyTool / EZT hook：适合复用官方 Flash RW helper、Features CMD helper、UI 隐藏页和系统块读写路径。

三条线各有分工。MPTool 更接近量产流程，MPISP patcher 更接近设备侧语义，EasyTool 更适合作为 agent 的交互桥。原因很现实：

EasyTool 已经把许多底层 helper 包在 UI 功能里，包括 Flash RW、Features CMD、WPRO / DBS / DPS、Reset CPU 等入口。
EasyTool 的页面和按钮非常适合先观察，再逐步把稳定动作升级成 direct RPC。
EasyTool 面向工程调试，相比 MPTool 量产流程，对完整生产配置的依赖更轻。
Agent 更适合执行小步事实采集和可复跑 runbook；完整 MP 流程留给受控工作流。

从这个角度看，Etherealm EasyTool Bridge 是把原厂调试工具变成硬件控制面的第一块楔子。MPTool 保持量产流程角色，MPISP patcher 保持设备侧语义实验角色，Bridge 负责把设备现场变成可查询、可记录、可自动化的状态空间。

Agentic 硬件 Harness 的抽象

下一代硬件层面 AI Harness 至少要有五个部件。

部件	在 EasyTool Bridge 中的对应	Agent 能做什么
感知层	`info`、`events.jsonl`、`captures.*`、UI tree、command observe	知道当前工具、设备、profile、最后命令、错误点
读取层	`opcode.read`、`listSysBlocks`、`readBlock`、live baseline 脚本	采集 SMART、D1 telemetry、PE/EC、SysBlk、raw+spare
行动层	`drive.reset*`、`mpisp.download`、`writeBlock`、`eraseBlock`	只在授权后执行状态改变或写擦动作
记忆层	session manifest、hash、raw/spare bundle、analysis JSON、报告	把每次实验变成可复核证据包
策略层	profile、method safety level、precondition、policy gate	限制 agent 的动作集合，要求危险动作先满足门槛

这个 Harness 的核心目标，是让 AI 在硬件实验中拥有结构化感知和受限行动能力，同时让每个动作都能被人类审计、重放和拒绝。

可以把一次 Bridge session 设计成下面的状态机：

text

identify
  -> ping / info / profile / EasyTool module identity

observe
  -> UI tree / captures / events / command helper status

baseline
  -> SMART LID 0x02 / D1 telemetry / C2-0x53 / listSysBlocks

dump
  -> readBlock raw+spare / manifest / hash / scan

analyze
  -> compare baseline / scan WPRO-DBS-DPS / locate candidate records

propose
  -> agent writes runbook and required preconditions

authorize
  -> human approves a bounded action set

act
  -> reset / download / write / erase under policy

verify
  -> immediate readback / byte compare / reconnect / power-cycle / repeated baseline

Agentic 能力应该主要释放在 observe -> baseline -> dump -> analyze -> propose 这五步。act 保持后置、窄口、可审计。

产品形态：Bridge Runtime、Control Plane 与 Evidence Bundle

Etherealm EasyTool Bridge 可以拆成三个产品层。

1. Bridge Runtime

Runtime 是现在已经存在的 DLL / launcher / profile / RPC 层。它应该继续保持小而硬：

只监听本机环回地址。
启动时明确 profile、版本、模块身份和危险开关。
已知 profile 才开放 direct flash、reset、MPISP download。
fallback profile 只保留 UI / IAT / capture 观察面。
command observe 默认只落摘要；显式 --dump-command-buffers 时才写 commands/。
opcode.send 留在封闭侧，写侧能力拆成具有固定语义的窄接口。

Runtime 的产品质量指标以方法质量衡量。每个方法都要能回答：

它读还是写？
它是否改变设备状态？
它依赖哪个 profile？
它调用 EasyTool 哪个 helper？
它失败时会返回什么错误？
它的输出能否进入 evidence bundle？

2. Bridge Control Plane

Control Plane 是下一层应该新增的 agent-facing 包装。JSON-RPC 原语收在内部，对 agent 暴露一组更高层的任务接口：

任务接口	底层方法	输出
`session.probe`	`ping`、`info`、`profiles.list`	session identity、capability matrix、risk flags
`baseline.capture`	`opcode.read`、`listSysBlocks`	SMART、D1、PE/EC、sysblk list、summary
`sysblk.dump`	`listSysBlocks`、`readBlock`	raw+spare、hash、coordinate manifest
`dumpisp.reconstruct`	`readBlock`、`opcode.read`、offline builder	ISP package、MicroCode、manifest、CSS hash status
`events.tail`	`events.jsonl`、`captures.*`	timeline、last command、failure point
`proposal.writePlan`	offline analysis only	写/擦前置条件、目标字段、验证矩阵，仅生成计划

这层可以做成 Node CLI、MCP server 或本地服务。关键是它把“低层 RPC 方法”升级成“带前置条件和输出 contract 的实验动作”。Agent 调用 baseline.capture 时，直接拿到带时间、profile、二进制 hash、数据 hash 和限制说明的 bundle。

3. Evidence Bundle

Evidence Bundle 是 Bridge 能成为产品的核心资产。推荐标准结构：

text

bridge-session/
  manifest.json
  profile.json
  module.json
  events.jsonl
  summary.json
  captures/
  opcodes/
    smart-lid-02.bin
    d1-telemetry.bin
    c2-53-ec.bin
  sysblocks/
    1st-info/
      raw.bin
      spare.bin
      manifest.json
    1st-isp/
      raw.bin
      spare.bin
      manifest.json
  analyses/
    baseline-summary.json
    health-block-scan.json
    dumpisp-manifest.json
  report.md

每个二进制文件都需要 size、sha256、坐标、option、status、来源方法和采集时间。这样 agent 的后续判断建立在“已落盘事实”上，运行时上下文或 UI 印象只作为辅助线索。

实现路径

阶段 A：把 RPC contract 变成机器可读 schema

当前 RPC contract 已经足够清楚，但产品化需要让方法元数据可被工具读取：

字段	示例
`method`	`readBlock`
`safety`	`read-only`、`state-changing`、`destructive`
`profileRequired`	`directFlash=true`
`preconditions`	device selected、sys_info initialized
`outputs`	dataHex、status、params、exception
`artifactPolicy`	save raw+spare and hash
`humanApproval`	false for read-only, true for write/erase/reset/download

这一步完成后，agent 可以先读取 capability schema，再决定下一步动作。方法进入 schema 后才进入可调用集合。

阶段 B：做 read-only Agent Harness MVP

第一版聚焦四个只读、可复用动作：

session.probe：确认 ezt-hook/0.7、profile、module identity、direct methods、observe hook。
baseline.capture：采集 SMART LID 0x02、D1 telemetry、C2/0x53、系统块列表。
sysblk.dump：按 listSysBlocks 输出的坐标读取 Info / ISP / MPInfo / Log 等条目，保存 raw+spare。
events.collect：整理 events.jsonl、capture ring 和可选 command buffer。

这一版已经能支撑 Health Percentage、WPRO / DBS / DPS、DumpISP 复刻和 MPTool 失败点定位的大部分只读研究。对 Agentic 产品来说，read-only MVP 是最重要的信任基础。

阶段 C：把 DumpISP 做成标准 workflow

现有 SM2268XT2 DumpISP 研究已经证明：EZT 有和 MPTool sub_4B4870 同级别的底层读页方法；MPTool sub_43BA30 + sub_444040 代表更高层的 DumpISP 组装路线。Bridge 的机会就在这里。

标准 workflow 应该复刻 MPTool 的关键规则：

读取 SM2268PARA 参数表，以参数表驱动 page 拆分。
按参数表拆 block/page/ch/plane/die/ce。
记录 option0=0x95、0xC5 等多种视图。
检查 spare/header，例如 Info-like 0xE1、ISP-like 0xE4。
输出 _ori 风格 ISP section、full-container MicroCode.bin / Firmware ISP、CSS hash 状态和 debug 对照。
保留 raw pre-rewrite container，区分 hash repair 与 RSA resigning。

这个 workflow 一旦稳定，Bridge 就从“会读页”升级为“能把原厂 DumpISP 路线变成 agent 可执行的只读流程”。

阶段 D：建立 profile factory

跨主控扩展需要 profile factory，而非复制粘贴 RVA：

步骤	产物
EasyTool 身份采集	文件名、image size、SHA-256、版本字符串
IDA / 静态定位	Flash read/write/erase helper、Features CMD helper、Reset CPU helper、device context、sys_info 表
ABI 描述	参数布局、geometry offset、返回值、异常边界
smoke test	`ping/info`、UI tree、`opcode.read`、`listSysBlocks`、小范围 `readBlock`
profile 入库	id、controller、version、rvas、capability flags、dangerous gate

SM2267XT profile 已经证明同名 RPC 表面可以通过差异化底层 ABI 实现。后续 SM2269XT、其它 EasyTool 版本和其它厂商工具也应该走这条 profile factory，避免单型号脚本持续堆叠。

阶段 E：写擦能力进入 policy gate

Bridge 可以保留写擦能力，产品层面建议把危险动作拆成两层：

层	动作	默认
proposal	生成写/擦计划、列出证据、列出风险和验证矩阵	允许
execution	`writeBlock`、`eraseBlock`、`mpisp.download`、`drive.resetToRom`	需要人类确认和 policy unlock

执行前置门槛至少包括：

目标盘自己的完整 raw+spare 备份。
坐标、option、block/page/ch/plane/die/ce 来源可复核。
body、spare/header、checksum 或 CSS hash 处理规则已说明。
已有 dry-run patch output 和 byte diff。
写后立刻 readBlock 回读并 byte compare。
reset / reconnect / power-cycle 后重复 baseline。
失败时有明确 rollback、重新开卡或放弃路径。

前置条件未满足时，agent 输出应收敛为“继续只读取证”和补充证据清单。

与既有专题的关系

前两篇存储芯片专题分别解决了两类问题。

第一篇 EasyTool / ROMDEBUG / smi-recovery 讨论的是 SM2258XT 恢复导出的重建路径。它证明了恢复工程真正依赖格式、状态和证据边界；目录里的镜像大小只适合作为辅助信号。

第二篇 MP2 / EasyTool Hook / Health Percentage 讨论的是 SM2268XT2 可观测性和健康度机制。它把 MP2 hook、MPISP patcher、EasyTool hook 三层拆开，并把 Health Percentage 从静态 SMART 字节推进到 EC / PE summary、D1 telemetry 和 metadata backing 的证据链。

本文是在这两篇基础上的产品化升级：把这些工程路线抽象成 ER 面向 Silicon Motion SSD Controller 的 Agentic 硬件 Harness。前两篇解决“如何证明”；Bridge 产品解决“如何让证明过程被 agent 安全地调用、复跑和扩展”。

ER 的产品机会

ER 在这个方向上的独特位置，来自把以下资产组合成一条完整工程链：

存储主控逆向能力：IDA、MPTool / EasyTool host flow、MPISP / ISP container、metadata block、ECC / PE / health 机制。
本地工具工程能力：Node CLI、Win32 hook、profile、manifest、hash、report pipeline。
Agentic 工作流能力：把探索、证据收集、假设生成、验证矩阵和报告写作串成可复用流程。
风控文化：默认只读、明确来源、拒绝 silent fallback、危险动作必须被授权和验证。

这让 Etherealm EasyTool Bridge 可以成为一个非常具体的产品，远比泛泛的“AI 硬件助手”更可落地：

产品包	面向用户	交付物
Bridge Lab	内部研究 / 高级工程师	runtime、CLI、profile、evidence bundle、runbook
Bridge Recover	数据恢复 / NAND 取证	只读 dump、sysblk manifest、DumpISP 重构、恢复源评级
Bridge QA	控制器包验证 / 小批量实验	profile smoke test、MPISP download trace、MPTool / EasyTool 流程对照
Bridge Agent	Agentic 硬件 Harness	MCP / JSON-RPC wrapper、policy gate、artifact memory、自动报告

短期最有价值的是 Bridge Lab 和 Bridge Recover。它们的承诺可以聚焦在把黑箱现场变成可复核 evidence bundle，已经足以显著提升研究效率。Bridge Agent 适合在 read-only workflow 稳定后再开放。

关键风险

这条产品路线的风险也很明确。

风险	表现	控制方式
过度泛化	用 SM2268XT2 的 RVA / ABI 套 SM2267XT、SM2269XT 或其它 EasyTool	每个 profile 单独 SHA、image size、ABI、smoke test
host 成功误判	EasyTool helper 返回成功，被写成设备语义已成立	必须有设备侧 readback、baseline 对照和断电后复测
output buffer 当来源	把 `C2/0x53` 或 SMART 输出当成 NAND backing	区分读侧视图、RAM table、metadata record、raw+spare
写擦权限外溢	agent 为了完成目标调用 `writeBlock` / `eraseBlock`	method safety schema、policy unlock、人类审批、日志留痕
UI 自动化脆弱	语言、窗口状态、隐藏页、旧进程导致误点	direct RPC 优先，UI 只做 smoke test 和观察辅助
证据包复用性弱	bin 文件缺坐标、option、hash、采集时间	强制 manifest 和 artifact layout

这些风险定义了 Bridge 的护城河。硬件 Agentic 产品的门槛在于：让 AI 能做事，同时让证据和授权边界形成硬约束。

近期路线图

最现实的路线可以排成六个里程碑。

固化 ezt-hook/0.7 RPC schema，给每个方法标注 read-only、state-changing、destructive、profile requirement 和 artifact policy。
新增 read-only Bridge CLI / MCP adapter，先只开放 probe、baseline、sysblk dump、events collect。
把 live baseline、WPRO / DBS / DPS 观察、DumpISP 复刻整理成标准 workflow，所有输出统一进入 evidence bundle。
做 profile factory，把 SM2268XT2、SM2267XT 的现有 profile 转成模板，再为 SM2269XT 建 profile 发现流程。
建立危险动作 policy gate：proposal 与 execution 分离，写擦/Reset to ROM/MPISP download 必须显式授权。
做 Bridge Workbench：左侧 session / profile，中间 timeline / sysblk map，右侧 artifact diff / runbook / approval gate。

这条路线的第一阶段聚焦只读取证。更有价值的起点，是让 agent 稳定完成一组过去需要人手反复点 UI、拷文件、算 hash、写记录的任务。

当前结论

Etherealm EasyTool Bridge 可以成为 ER 面向 Silicon Motion SSD Controller 的 Agentic 时代产品。它的起点应是一套把原厂 EasyTool 能力 profile 化、RPC 化、证据化、安全化的硬件控制面。

对下一代硬件 AI Harness 来说，最重要的能力应定义为：AI 在 contract 内感知、采集、解释和提出受控实验。在存储主控这种高风险场景里，read-only、manifest、hash、回读验证和人类授权共同构成产品可信度。

如果 Bridge 继续沿着 profile factory、read-only workflow、evidence bundle、policy gate 和 MCP / Control Plane 走，它会从当前 SM2268XT2 / SM2267XT EasyTool hook，成长为一个可以覆盖多主控、多工具、多场景的硬件实验 Harness。这个方向很适合 ER：工程深、证据硬、自动化价值高，而且足够窄，窄到能做成真正可用的产品。

Etherealm EasyTool Bridge：面向 SMI SSD Controller 的 Agentic 硬件 Harness ​

核心判断 ​

现有工程已经具备的产品骨架 ​

为什么 EasyTool 是第一个好切口 ​

Agentic 硬件 Harness 的抽象 ​

产品形态：Bridge Runtime、Control Plane 与 Evidence Bundle ​

1. Bridge Runtime ​

2. Bridge Control Plane ​

3. Evidence Bundle ​

实现路径 ​

阶段 A：把 RPC contract 变成机器可读 schema ​

阶段 B：做 read-only Agent Harness MVP ​

阶段 C：把 DumpISP 做成标准 workflow ​

阶段 D：建立 profile factory ​

阶段 E：写擦能力进入 policy gate ​

与既有专题的关系 ​

ER 的产品机会 ​

关键风险 ​

近期路线图 ​

当前结论 ​

Etherealm EasyTool Bridge：面向 SMI SSD Controller 的 Agentic 硬件 Harness

核心判断

现有工程已经具备的产品骨架

为什么 EasyTool 是第一个好切口

Agentic 硬件 Harness 的抽象

产品形态：Bridge Runtime、Control Plane 与 Evidence Bundle

1. Bridge Runtime

2. Bridge Control Plane

3. Evidence Bundle

实现路径

阶段 A：把 RPC contract 变成机器可读 schema

阶段 B：做 read-only Agent Harness MVP

阶段 C：把 DumpISP 做成标准 workflow

阶段 D：建立 profile factory

阶段 E：写擦能力进入 policy gate

与既有专题的关系

ER 的产品机会

关键风险

近期路线图

当前结论