在旧版本的 Ledger Ethereum 应用中，根本原因是显示内容和底层缓冲区中存储的交易之间存在竞争条件。 一个简化的例子： 1. 向设备发送交易 A，例如发送 0.01 ETH 到 0x111...111。 2. Ledger 解析交易 A 并在屏幕上显示。 3. 当用户仍在审核交易 A 时，发送交易 B，例如对 0x111...111 的无限授权。 4. 交易 B 可以覆盖底层交易缓冲区中的交易 A。 用户仍然看到的是交易 A，但设备最终签署的是交易 B。 实际攻击涉及 P1_FIRST + BASIC，随后是第二个 P2_STORE。STORE 是在之前的 Ledger 版本中引入的，使这种覆盖路径成为可能。 Ledger 在 1.22.3 版本中修复了这个问题，通过在现有交易仍在处理中时拒绝新交易来解决。 为什么这不会影响 OneKey？ OneKey 从一开始就以这种方式工作。当一个交易正在等待确认或签署时，设备不会接受另一个交易。 因此，没有窗口让第二个交易覆盖当前正在审核的交易。 换句话说，Ledger 在 1.22.3 中新增的行为，早已是 OneKey 的默认行为。