By Light & 胡一米
本文内容较长,所以将目录整理在最前面,用于方便各位读者查阅,目录如下:
app分析与解密
固件程序的编写
总结
下面就开始正文:
近期翻阅之前的工作,发现在考勤门禁机系列的安全研究里,有一篇很早就整理好但是没发出来的文章,考虑到相关设备的漏洞已经提交了快两年了,想必该修复的也修复了,遂将文字重新整理了一番,发出来希望能给读者一些帮助。依照惯例,我们还是只聊这个设备的分析过程,着重描述一下这个设备的固件解密,至于漏洞则点到为止。
IoT设备的安全分析中,分析人员的主要工作是分析设备的逻辑功能及其代码实现,从而挖掘设备中的漏洞。大多数分析工作是从解析固件开始的,如果这一步就不顺利的话,后续可能会更加麻烦。不巧的是,这次的设备在起步阶段就很曲折:固件被加密了,并不能直接开始分析。
在此我们再简单总结一下那些常见IoT设备的启动流程,如下图所示:
图2-1 IoT设备大致的启动流程
上图大致可以分为4个阶段:
(1)首先,芯片上电后首先运行的是boot rom,执行完毕后会跳转到bootloader,如果设备启用了固件签名,那么此处会对固件进行校验;
(2)然后,bootloader的作用类似于PC启动过程的引导,主要功能就是为操作系统的运行做准备工作,在复杂的设备中,bootloader会进一步分成多个阶段;
(3)此时,操作系统就开始接管对MCU的控制,上图中把操作系统和app分成了两个部分,是为了对标PC方便大家理解,实际上在有些设备里跑的操作系统和app是混合在一起的,甚至可能没有操作系统;
(4)最后,各个app被加载运行,开始执行设备的逻辑功能,此处往往是我们想要着重分析的地方。
上图中,bootloader、kernel和app这三个阶段的代码通常是由开发者编写并烧录到Flash中的,我们所说的固件指的就是这部分内容。请将此图放在脑海中,后续所有工作都将以此图为模板展开分析和叙述。
PS:本次分享讨论的是固件可以提取但是无法分析的情况,一些由于读保护机制导致固件不被提取的情况,暂不在本篇的讨论范畴中。
通过热风枪可以取下Flash芯片,然后通过编程器可以拿到Flash中的固件,这些基本功各位一定已经非常熟悉了,这里就不再赘述。固件文件包含一个FAT12格式的文件系统,可以通过7z工具直接提取出文件系统中的所有内容,提取内容截图如下:
图3-1 固件文件系统内容
显而易见,上图中的App文件夹中肯定包含了这款门禁考勤机的主程序。不过,事情肯定没有那么顺利,该文件夹内只有一个文件是可以解析的ELF格式,其他文件均不可解析,仅存在可解析文件叫main.bin,用IDA加载之后,内容看起来也有些过于简单,截图如下:
图3-2 main.bin程序内容
上图中,虽然函数符号都还在,可以大概推断出函数的作用,但是函数看起来很古怪,比如RT_CreateProcess函数内容是下图中的样子:
图3-3 RT_CreateProcess函数内容
上图中的gFuncEntryKern看起来有点像虚表指针,指向一个函数地址表,而这个指针在程序启动时被赋值。
程序main.bin很短,很快就逆完了,看起来最后创建了一个新的进程,但除了main.bin程序之外,其他程序全都无法解析。即便是main.bin自身,看起来也不太正常,很多函数只有跳转stub,缺少实质内容,看起来像是PC中加了保护导入表的壳。那么,接下来还是从头开始啃一下这个设备固件吧。
按照图2-1所示,我们决定先看看bootloader,在解压获得的完整文件系统中,可以看到Product.ini文件,从里面能够找到设备的分区表,如下图所示:
图4-1固件分区表
我们此前解压缩得到的FAT12文件系统即为0x20000偏移处,顺便吐槽一下binwalk,为啥binwalk识别不出FAT12文件系统,因为太古老了吗?
结合设备上电后串口的输出字符串,可以推断出0x20000之前的固件内容即为程序的bootloader,接下来用IDA载入bootloader部分代码进行分析,并结合串口的输出日志,可以定位到关键位置,如下图:
图4-2 bootloader加载kernel文件的过程
上图中,我们根据串口打印出来的字符串来定位程序的关键位置,找到了kernel文件其实就是rootfs中的Rtbio_3760_R4502文件,且串口打印出来的信息包含了kernel的加载基址和入口地址,根据这些信息,可以分析kernel文件了。
使用IDA加载kernel文件之后,IDA导航条如下图所示:
图4-3 直接解析Rtbio文件时的IDA导航条
可以看到此时kernel只被解析出了一小部分,绝大多数内容都是unexplored状态,实际上这部分内容还是处于加密或压缩状态。由于执行流程已经离开bootloader而进入kernel阶段,那么kernel代码肯定是自解密或自解压的,这很正常,一般情况下linux kernel都是自解压的,但我们没办法直接解压就很奇怪。通过逆向分析,可以在入口点附近看到多处异或解密代码,如下图所示:
图4-4 异或解密代码
上图中,0x79E1即为异或解密使用的密钥,类似上图中的异或解密代码在多个位置都有出现,原来再自解压之前还有一步自解密过程,所以没法直接解压。
耐心分析这些已经解析的代码,可以将kernel的启动流程整理为下图所示内容:
图4-5 kernel文件的解密过程分析
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入!
最后于 2023-7-24 17:01
被Lightal编辑
,原因: 重新添加图片