故障注入模拟（一）

1背景

2故障攻击

• 干扰设备正常运行
• 各种硬件技术允许
• 还有一些软件或微架构方法：Rowhammer、LVI、V0LTpwn等。。。

3故障影响

• 对CPU的影响可能在许多方面有所不同：
  – 跳过指令
  – 寄存器/内存读取/写入损坏
• 实际上取决于硅、断层类型。。。

•  故障是第一步，但寻找实用的漏洞是另一步
•  不总是访问源代码
•  并非总是很容易模拟固件
•  硬件故障活动可能很长
•  对于代码审计捕获一些漏洞很有用

问题？

现有工具

• Lazart（格勒诺布尔大学VERIMAG实验室）

• FiSim（Riscure）公司

4用于故障模拟的ESIL

途径

• 使用R2的ESIL模拟部分固件
  

• 使用r2pipe和Python检测VM

GLitchoz0r 3k

• Python模块
• 轻松设置

故障模型及条件

• 所有故障模型都作为一个功能实现
• 将故障模型添加到模拟中
• 每个模拟一个故障模型

5结果

• 跳过for循环会使密码检查返回正确的值。

深层检查

• If语句是分支

更深层检查

对AES的故障攻击

• 众所周知并记录在案的故障攻击
  – 适用于嵌入式设备
• 至少有4个出现故障的密文，可以恢复AES密钥。
• 如果我们能够生成良好的故障密文并恢复密钥，则故障模拟生效。

著名的巴尔达测试

• “如果它模拟AES，ESIL就足够接近了”
  – 很好的例子（内存读/写、算术运算、循环…）
• 问题：ESIL在x86上工作正常，但在ARM或RISC-V上不工作
  – 错误结果，或无限循环

6ESIL/ASM差异

目标

• 针对真实设备验证ESIL实施
• 改进嵌入式架构（如ARM）的ESIL支持
• 自动化以下各项的比较过程：
  – 少量指令/功能
  – 完全二进制执行
• 架构不可知论

Diffosaurus

• 使用Python（r2pipe）检测Radare2
• 同时打开两个线路

  – 调试

     QEMU

• 递增并比较寄存器，直到出现差异……或不出现差异

举例

• 编译的二进制文件
  – 固件中的特定功能
• Unit tests

特征

• 显示上一条和当前指令
• 突出显示寄存器之间的差异
• 同步DEBUG和ESIL管道之间的寄存器
• 与DEBUG/ESIL管道交互

演示

• 1 PR进行中
  – 修复ARM IT模块（#17509）
• 7个PR合并
  – ARM修复（#17347/#17058）
  – RISC-V修复（#17115/#17078/#17005/#16996/#16962）
• 多个问题已修复
• AES现在在ARM32/Thumb/RISC-V上运行

7最终测试及结论

• 在AES上应用故障模拟器
• 如果故障允许恢复AES密钥，则成功

最终测试结果

后续工作

• 在同一模拟过程中实施多个故障
• 添加故障模型
  – 模拟激光诱发故障的单位翻转指令
• 增强其他架构的ESIL

结论

• 在真实硬件上再现的故障模拟
• 能够识别固件中的潜在故障注入点
• Radare2允许快速*添加新架构，而无需更改模拟代码
  – *如果ESIL工作正常

8使用ESIL的指令跟踪

• 由于我们可以模拟完整的AES，因此可以使用ESIL信息
• 检索内存读/写
  – 我们可以生成/绘制内存访问轨迹
• 我们可以应用“CPA”攻击来恢复密钥
  – 工具：https://github.com/SideChannelMarvels/Daredevil