作者 | 绿盟科技格物实验室 高剑
背景
前段时间接到一个Ripple 20漏洞研究的任务，配套的设备为DIGI开发板，在研究过程中发生了悲剧的一幕——开发板变砖，为了能够继续顺利进行研究于是决定一定要解救DIGI开发板，本文将救砖的过程进行讲解分享，以供更多的人参考、获取灵感动手救助自己成砖的设备。
实验过程
在2020年6月，由以色列的网络安全公司JSOF研究发现，Treck TCP/IP协议栈存在一系列安全漏洞，命名为“Ripple20”，“Ripple20”共涉及19个漏洞。使用该协议栈的设备数量非常庞大，包括大量的物联网设备，如电网设备、医疗系统、工业设备等等。Treck TCP/IP 协议栈由软件公司 Treck 开发，它最早是在1997年发布的，实现了一个轻量级的 TCP/IP 堆栈，在二十多年里被企业广泛用于实现联网功能。
可以看到该漏洞属于中间件供应链级别的，影响范围甚广，要进一步研究首先得知道受影响的厂家及具体设备，官方披露涉及的供应商包括HP、Schneider Electric、DIGI、Intel、RockwellAutomation、Caterpillar、Baxter等，涉及的产品类型包括打印机、UPS系统、网络设备、IP摄像机、视频会议系统、楼宇自动化设备和工控设备等。
通过研究受影响的厂商和设备后，选取了DIGI的一款开发套件——DIGI ME9120，DIGI ME9210 是一款超紧凑的嵌入式模块系统（SoM），基于Digi强大的新型32位NS9210处理器（ARM9），具有支持10/100以太网的功能。该模块也可以作为中间件使用到其他的设备中充当网络组件，在全球的使用量巨大，而且开发板提供开发环境还可以用来做更多的其他研究。
在拿到开发板后，首先搭建环境，让开发板的基础功能（串口服务器）能够正常运行。安装配套的开发套件ESP（NET OS7.X），创建开发工程，勾选基本网络功能选项，编译后通过开发环境自带的固件更新插件烧写至DIGI开发板中。
烧写成功后，测试串口服务器功能是否正常，如下图所示，验证基本功能正常，网口发送hello world至串口，串口成功接收，串口发送nihao 123至网口，网口成功接收。
但是发现，再次创建工程重新编译下装后网络参数不生效，是否是内部存储影响bin文件的执行，利用JLINK将DIGIME9210的flash清除后再次下装是否会变好，于是进行了JLINK连接开发板清除flash的操作，期望清除后重新下装编译的固件，新的网络参数会生效，但是事与愿违，新下装固件后导致开发板工作异常：网络数据指示灯常亮，连接指示灯熄灭，利用匹配的IP进行Ping测试，网络不通。实验多次亦是如此，至此开发板变成了砖。
救砖指南
经过分析，此前的清除flash操作将ME9210内部的BootLoader一并擦除，没有BootLoader的ME9210在接收到image.bin（应用固件）文件后无法复制到正确的地址空间，因此会变砖。要想救砖就得按照如下三个步骤执行：
• 获取到ME9210对应版本的BootLoader。
• BootLoader文件下装至ME9210并使其正常工作。
• 下装应用固件后使其以太网功能正常工作。
( 1 ) 获取BootLoader
DIGI配套的资料中未曾提及BootLoader等相关信息，因此只能借助于搜索大法开始搜集相关资料，怎奈DIGI在网络上的资料缺失太少，只有在DIGI论坛中能寻找相关线索，找到了有人与我有同样的遭遇，但是官方好像没给出下载BootLoader的连接，只是得知了ME9210中的BootLoader叫做rom.bin文件，有这个信息后，再次在论坛中搜索，找到了一个产生该文件的方法——创建新的平台工程，在平台工程下存在rom.bin文件，至此解决了第一个问题。
( 2 ) 下装rom.bin文件和image.bin文件
开发板自带的开发环境中提供了烧写插件，该插件有提供rom.bin文件的下装烧写功能，因此利用自带的工具进行下装。
下装rom.bin的同时可以下装应用固件imag.bin文件，因此一并下装后期望能够救砖成功，但是经过多次测试后还是不能正常工作。分析后认为应该是烧写的方法或者工具不匹配导致烧写时特殊跳线等配置原因，在论坛中找到另外一种烧写时需要特殊跳线配置的方法，如下所示。根据该方法，烧写rom.bin后通过Xmodem方式传输image.bin文件，但是启动后ME9210依然不能正常工作。
看来通过搜索寻找前人的解决方案行不通了，解决不了第二个和第三个问题。此时只能求助于自己的知识和经验了，根据我们对IoT设备的固件理解，芯片内部的固件结构排布一般是BootLoader后跟着应用固件，但是排布的地址空间却是最为关键的，是否可以找到rom.bin和image.bin在该芯片内部的地址空间分布相关信息，通过查找芯片手册和开发平台的相关编译信息找到一个关键点——flash offset：0x10000，如果这个编译架构与底层芯片匹配那么这个偏移地址也是芯片内存储image.bin的起始地址。rom.bin文件是BootLoader一般都是从0x00000开始的，根据这个推测和经验，利用JINK将rom.bin文件和image.bin文件烧写至对应区域，具体步骤如下：
A. Jlink烧录rom.bin,烧录地址0x0，ARM9设置为BIG endian。
B. 利用JLINK烧录image.bin文件，起始地址选择为0x10000。
C. 烧录完成后，断电重启开发板，启动后串口打印显示：
D. 5s之内按任意键后出现如下信息：
E. 按A接受网络配置信息后，应用程序启动，显示运行结果。如果需要更改配置，则按M键，之后按照提示进行修改：
F. 网络连接测试如下，至此救砖成功。
总结
本次可以救砖成功的主要因素是能成功理解设备内部存储分布及其地址排布信息，找到有用信息通过JLINK仿真器烧录的方式下装文件，而不是一味信任开发套件和前辈的经验，有时候需要自己动脑动手才能解决更有意思的问题，或许当自己不做“伸手党”后，才会发现自己原来也这么厉害。希望本文可以帮助到你，自己动手让那些变砖的设备活过来吧。
转载请注明来自：关键基础设施安全应急响应中心
