在第1部分描述了APPROTECT攻击之后，这篇文章会介绍如下内容：
· 利用基于nRF52840的真实产品提取固件并重新激活SWD。
· 重现对其他nRF52 SoC的攻击，以确认所有nRF52版本中的漏洞。
0x01 对真实产品进行利用验证
让我们从一个经典的场景开始，在这个场景中，黑客需要访问产品的固件。如果此产品基于nRF52，则可能受到保护以避免固件读出，以防止进行逆向。
目标：Logitech G Pro
为了进行漏洞利用验证，我选择了手头的第一台设备。这是我基于nRF52840的Logitech G Pro鼠标。
注意：我的目标不是在此处攻击Logitech产品。
0x02 获得访问权限
我跳过了拆卸部分，拆卸设备可访问主板：
Logitech PRO G的前PCB，看一下HERO传感器。
SWD引脚（SWDCLK，SWDIO）经过丝网印刷，因此易于识别（红色框）。然后，焊接一些引脚接头，以将目标连接到Segger J-Link调试探针：
目标和JTAG探针之间的SWDCLK，SWDIO，VDD_NRF和GND跳线。由于未连接电池，USB电缆也已插入。
拒绝通过OpenOcd和GDB进行连接的任何尝试：
$ openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -c "transport select swd" -f /usr/local/share/openocd/scripts/target/nrf52.cfg $ arm-none-eabi-gdb
启用了APPROTECT，并且与SWD的连接被拒绝。
此设备上启用了APPROTECT功能。
0x03 APPROTECT Bypass 复现
设备准备
nRF52840位于PCB背面，并充当系统的主处理器。
PCB设计与nRF52840参考设计（在北欧数据表中找到）完全匹配，就像复制粘贴设计一样。
去耦电容器C5和C15被移除，毛刺输出连接到VDD_CPU（DEC1）：
C5和C15被卸下（黑框），VDD_CPU_DEC1（红线）和GND（黑线）。
VDD_CPU（DEC1）通过SMA连接器连接到毛刺器，这是完整攻击设置的视图：
Logitech PRO G的快速设置
故障攻击
通过运行python脚本来启动故障攻击，该脚本负责在每次故障尝试后同步故障系统，示波器并重置设备。
此屏幕截图显示了正常的启动（设备的经典行为）：
正常行为（无毛刺效应）。CH1 = UART，CH2 = VDD_nRF（示波器触发），CH3 = CPU电流消耗，CH4 = VDD_CPU。
然后，在成功的故障注入之后，这是想要获得的结果：
成功的攻击。CH1 = UART，CH2 = VDD_nRF（示波器触发），CH3 = CPU电流消耗，CH4 = VDD_CPU。
板上的VDD_nRF信号用作示波器触发参考。经过特定的延迟后，注入的故障正在破坏nRF52840的正常初始化。
从shell程序的角度来看，外部调试器现在可以连接到鼠标：
调试器连接到nRF52840
0x04 固件提取
连接后，下一步是转储固件和UICR：
#openocd via telnet dump_image FLASH.bin 0x0 0x100000 dump_image UICR.bin 0x10001000 0x1000 #optional dump_image FICR.bin 0x10001000 0x1000
这是闪存中0xE5CD8处的引导加载程序版本和设备名称：
引导程序版本
然后可以执行静态代码分析，以发现漏洞（或只是为了了解漏洞的工作方式）。
调试激活
为了持久地重新激活调试接口，禁用了APPROTECT （请参阅第1部分），并使用提取的FLASH.bin和UICR.bin（当然将APPROTECT修补为0xFFFFFFFF）重新刷新了：
Logitech PRO-G鼠标返回开发模式…
鼠标又回到了“开发模式”，其中动态代码分析具有巨大的优势（尤其是在漏洞利用程序开发期间）。
0x05 权限获取
到目前为止，所有结果均已在nRF52840上获得。
nRF52 SoC共享Cortex-M4 CPU，相同的调试端口，相同的闪存（内存阵列除外）和相同的NVMC。在这种情况下，该漏洞可能是整个nRF52系列SoC系列所共有的。这是我对nRF52生态系统的看法：
查看现有的nRF52平台
经过这次简短的回顾之后，我决定专注于nRF52832和nRF52833，Nordic为这两个平台提供了开发工具包。
0x06 在nRF58232上的结果
在基于nRF52832的 nRF52-DK 上完成了测试。通过移除电容器和焊线来修改开发板：
nRF52832参考原理图
nRF52832细导线焊接至DEC1，红色导线焊接至DEC4。
注意：仅连接到DEC1的细线就足以实现攻击。
示波器用于识别有趣的图案。
我对监控DEC1线路上的功耗进行了一些改进，信号噪声比更高。
根据下面显示的功耗，Flash Controller初始化期间的行为是相同的：
启动过程中的CPU功耗分析。CH1 = UART TX，CH2 = DEC1功耗，CH3 =毛刺命令。
这是成功故障注入的一个示例：
成功故障注入。CH1 = UART TX，CH2 = DEC1功耗，CH3 =毛刺命令。
SWD调试已重新激活：
调试器已连接到nRF52832目标。
这些结果表明nRF52832容易受到APPROTECT攻击。
0x07 在nRF58233上的结果
再次，基于 nRF52833在nRF52833-DK上实现了类似的测试 。
原理图和PCB视图供参考：
nRF52833原理图
nRF52833细导线焊接至DEC1，红色导线焊接至DEC4。
在nRF52833上，闪存控制器的初始化与之前分析过的nRF52等效，在CPU电源线DEC1上执行故障注入：
同样在这里，SWD被重新激活：
调试器连接到nRF52833目标。
nRF52833容易受到APPROTECT攻击。
经过这些测试，发现所有nRF52版本都容易受到攻击。
0x08 漏洞影响
CVSS分数是7.6（严重性=高）CVSS：3.0 / AV：P / AC：L / PR：N / UI：N / S：C / C：H / I：H / A：H。
以下nRF52版本容易受到攻击：
· nRF52810
· nRF52811
· nRF52820
· nRF52832
· nRF52833
· nRF52840
因此，基于nRF52的模块也容易受到攻击。
这些模块可以利用Nordic SoC硬件和软件架构的所有功能来制作“单个模块产品”，而无需额外的微控制器来运行您的应用程序。
Nordic 在此处提供了第三方模块的参考，例如：
· Fanstel Corp.
· Laird
· Minew
· Raytac
· Taio Yuden
· U-blox
· Wurth Elektronik
· Murata
· Dynastream
· Fujitsu
· …. and more
0x09 研究总结
所述APPROTECT绕过漏洞已被证明在商业设备-罗技G鼠标上存在。
在nRF52832和nRF52833上还完成了其他测试。结果表明，这些平台也容易受到攻击，NordicSemiconductor确认其所有nRF52版本均容易受到攻击。
从基于nRF52的产品到第三方模块（使用nRF52平台），这现在正在影响现场的大量设备。
该漏洞位于Silicon中，不进行硬件更新，就无法修补。
还没有评论，来说两句吧...