一、题目介绍

通过 USB 直接连接电脑，可以同时满足 badge 的供电和串口通信，因此我们调节 Badge 开发板侧边开关拨至 RF1 而非 SW1 以设置板子为 USB 供电而非电池供电，然后通过 USB 串口以 38400 波特率连接上开发板，会看到如下的题目信息（如果使用电池供电，则会提示电压不足，不会显示题目信息）：

开发板关键信息介绍：

我们只关注 AES 侧信道攻击获取密钥这个实验。由题目和开发板介绍，可知是希望通过侧信道/故障注入的方式恢复 AES 密钥，通过串口发送 'AES'，芯片会进行 AES 加密运算，AES 加密过程中 PB11 作为触发信号会先拉高再拉低。实验以电压故障注入为例，打在 AES 第九轮运算的位置，产生足够多的错误密文，从而通过 DFA 恢复密钥。最后输入正确的 flag 即可成功点亮 PB0。

二、逻辑接线图

这张图展示的是电压故障注入攻击的硬件接线方案，核心设备是左侧的 PowerShorter。
整体攻击流程： 电脑通过串口触发 AES → PB11 输出触发信号 → PowerShorter 在精确时刻短路 3.3V 电源 → MCU 计算出错 → 电脑读取错误密文 → 与正确密文配对用于 DFA 分析。

• E1+（红线）：连接目标板的 3.3V 电源线，用于在精确时刻将电源瞬间短路到地，制造电压毛刺，使 MCU 在执行 AES 运算时产生计算错误。
• RELAY1（蓝线）：连接目标板的 NRST（复位引脚），通过继电器控制目标板复位。当 glitch 导致芯片挂死时，可以远程重启，对应代码中的 restart() 函数。
• GND（绿线）：共地，保证信号参考电平一致。
• E1-Tri（粉线）：连接目标板的 PB11 引脚，这是 AES 加密的触发信号。目标板开始 AES 运算时拉高此引脚，PowerShorter 检测到后，经过设定的 glitch_delay 延迟，发出持续 glitch_pulse 宽度的短路脉冲。
• 功耗采集（青色线）：接示波器，用于观察功耗波形，辅助定位 AES 运算的精确时间窗口。
• 串口（右侧）：接电脑，用于发送 AES 指令（ser.write(b'AES\n')）并读取加密结果。

三、实物接线图

通过示波器以 PB11 为触发信号，采集功耗波形可以大致看出 AES 第九轮运算时间在触发后 2.3ms 左右：

四、编写故障注入代码

# 引入库
from power_shorter import *
import faultviz, time, random,serial
import numpy as np
from osrtoolkit.dfa import aes as dfaaes

# 初始化PowerShorter端口和串口端口
ps = PowerShorter('COM4')
ser = serial.Serial("COM19", 38400, timeout=0.5)

# 启动一个故障注入结果的实时可视化界面服务
faultviz.start_view_service(port=12345)
vt = faultviz.ViewWidget()

# 定义重启函数
def restart():
    ps.relay(RELAY.RELAY2,1)
    time.sleep(0.5)
    ps.relay(RELAY.RELAY2,0)
    time.sleep(0.5)

# 获取一次正常（无故障注入）的 AES 加密结果，作为后续 DFA 攻击的参考基准
ser.reset_input_buffer()
ser.write(b'AES\n')
c = ser.read(32)
c_correct = bytes.fromhex(c.decode())
c_correct

# 初始化一个空列表，用来收集所有满足 DFA 攻击条件的正确密文与故障密文配对
fault_list_pair = []

# 执行一次完整的电压毛刺故障注入尝试的函数
def STM32F303_attack():
    glitch_pulse = random.randint(14, 18)
    glitch_delay = random.randint(229500, 232500)
    ps.engine_cfg(Engine.E1, [(0, glitch_delay), (1, glitch_pulse), (0, 1)])
    ps.arm(Engine.E1)
    time.sleep(0.5)
    
    ser.reset_input_buffer()
    ser.write(b'AES\n')
    line = ser.read(32)
    
    try:
        c = bytes.fromhex(line.decode())
        s = ps.state(Engine.E1)
        if s == "glitched":
            if dfaaes.DfaAESSubFunctions.check_fault_pair(c_correct, c) == 9:
                status = "SUCCESS"
                fault_list_pair.append((c_correct.hex(), c.hex()))
            else:
                status = "NORMAL"
            vt.update(state = status, delay = glitch_delay, pulse = glitch_pulse, result = c.hex())
    except:
        restart()

# 无限循环地反复尝试故障注入，直到收集到足够多的有效故障对，实际上此实验只需20个左右的有效故障对
while(1):
    STM32F303_attack()
    
# 展示故障注入结果的实时可视化界面
vt.show()

# 用收集到的故障对反推 AES 密钥
DFA_KEY = dfaaes.DfaAES(fault_list_pair)
DFA_KEY.get_master_key()

为什么要在AES的第9轮进行故障

• AES-128 共 10 轮，每轮依次执行 SubBytes、ShiftRows、MixColumns 和 AddRoundKey 四个操作，但最后一轮（第 10 轮）是个例外，它省略了 MixColumns。这个结构上的特殊性，正是第 9 轮成为最佳攻击点的根本原因。
• 如果故障注入得太晚，比如在第 10 轮，由于这一轮没有 MixColumns，一个字节的故障在输出密文中也只影响一个字节。差异信息太少，无法提供足够的数学约束来求解密钥。反过来，如果注入得太早，比如在第 8 轮或更前面，故障会经过多轮 MixColumns 的反复扩散，一个字节的错误最终会蔓延到几乎全部 16 个字节，差异过于复杂，数学上也无法有效建立方程。
• 第 9 轮恰好处于一个平衡点。在第 9 轮 SubBytes 之前注入一个单字节故障后，这个错误依次经过第 9 轮的 SubBytes 和 ShiftRows（仍然只有一个字节受影响），然后经过第 9 轮的 MixColumns，此时一个字节的错误被扩散到同一列的 4 个字节。之后进入第 10 轮，由于第 10 轮没有 MixColumns，这 4 个错误字节各自独立地经过 SubBytes、ShiftRows 和 AddRoundKey，不再进一步扩散。最终密文中恰好有 4 个字节与正确密文不同。
• 4 个字节的差异之所以最理想，是因为通过对比正确密文和故障密文，可以精确定位哪 4 个字节受到了影响，而这 4 个字节直接对应最后一轮轮密钥中的 4 个字节。利用 SubBytes 的差分特性，每个差分方程能把一个密钥字节的候选值从 256 个缩小到大约 2 到 4 个。一组故障对约束 4 个密钥字节，多组故障对覆盖不同的列，通常只需要 2 到 3 组有效故障对就能唯一确定全部 16 个字节的最后一轮轮密钥，再通过密钥扩展的逆运算还原出原始主密钥。

判断每次故障是否为SUCCESS的依据

判断 SUCCESS 的依据：if dfaaes.DfaAESSubFunctions.check_fault_pair(c_correct, c) == 9

• c_correct 是正确的 AES 加密输出（无故障注入时的密文）；
• c 是本次 glitch 攻击后获得的密文（可能已被注入故障）；
• check_fault_pair(c_correct, c) 函数的作用是对比正确密文和故障密文之间的差分模式，反推故障究竟发生在 AES 的哪一轮。不同轮次注入的故障在最终密文中会留下不同的差分特征：如果只有 1 个字节不同，说明故障发生在第 10 轮；如果有 4 个字节不同且符合特定的列结构，说明故障发生在第 9 轮；如果大量字节不同，说明故障发生在更早的轮次。函数通过分析这些差分的结构和位置关系，判断出故障对应的轮次编号，并将其作为返回值。只有当函数判定故障恰好发生在第 9 轮时，才认为这组故障对是有效的。

DFA代码解释

• DFA_KEY = dfaaes.DfaAES(fault_list_pair)：把之前循环中积攒的所有有效故障对（正确密文 + 故障密文的配对列表）传入 DFA 求解器，创建分析实例。
• DFA_KEY.get_master_key()：执行 DFA 数学运算，输出最终的 AES 主密钥。

1. 每组故障对中，正确密文和故障密文的差异反映了最后一轮 SubBytes 的输入差分；
2. 通过多组故障对建立方程约束，逐步缩小每个密钥字节的候选范围；
3. 2~3 组有效故障对通常就能把 16 个密钥字节各自唯一确定（为了稳妥，我们取了 24 组）；
4. 得到最后一轮轮密钥后，通过 AES 密钥扩展的逆运算，还原出原始的 128 位主密钥。

五、实验结果

多次注入得到24个有效故障对：

用收集到的故障对反推 AES 密钥：

最后将恢复出来的密钥裹上 flag{} 得到 flag{3e0d16a0a614c45b423628799b22f3de}，通过串口发送即可点亮 PB0：