某设备NandFlash固件分析

前言

        受实际工作启发，在MRCTF2022出了一道固件分析的题目，结果0解……此处记录下该NandFlash固件分析过程。

问题描述

        设备官网提供的固件经过openssl加密，且无相关资料提供解密教程；设备PCB板无相关的调试串口。因此只能首先通过物理方式对固件进行初步分析。主要思路是通过全人工的方法提取识别完整的文件系统或者逆向分析部分程序，发现其中加解密固件的逻辑。

NandFlash存储结构

        NandFlash有特定的存储结构，可分为plane，block以及page。以Spansion S34ML0*为例，其由2快plane组成，每块plane由1024 block组成，每块block由64 page组成，每page有(2048 + 128)=2176字节。其中128字节为OOB区，用作校验和坏块管理，具体管理方式可参考该flash的datasheet。

固件分析

        通过编程器提取该flash固件，可得文件大小285,212,672字节=0x11000000字节=2(plane)*(1024block)*64(page)*2176(byte)，恰好符合datasheet描述。但需要注意的是，此时binwalk并不能有效识别该固件的组成及提取其中的文件系统。这是由于坏块以及OOB的存在，因此固件分析的第一步是筛选坏块并去除OOB区。1. 坏块筛选规则：the 1st byte in the spare area of the 1st or 2nd or last page does not contain FFh is a Bad block. 2. OOB去除，可去除每隔2048字节的128字节校验值。然而，经过上述操作后，binwalk仍不能正确提取识别。 

        初次经过人工分析，所有全0字节内存页中，有如下现象：页起始偏移1040字节的14字节有数据；OOB区的前两字节为FF，后14字节数据为全0。不经让人怀疑是上下两部分的数据区和校验区发生了调换。而事实也却是如此，具体需要了解yaffs2在(2k+128) NandFlash的存储结构以及uboot烧写的yaffs过程[1 2 3]。

图 数据区中的校验值

图 OOB区中的数据

        编写脚本进行处理，可识别提取部分文件系统，但仍未能完全识别提取。幸运的是，在提取出的文件系统通过搜索decrypt、update等关键字发现了固件解密程序，其解密逻辑是以设备型号作为密钥，aes-256-cbc的方式进行解密。

图 第一次识别提取

图 解密逻辑

解密官方固件包，得到完整文件系统

图 官方固件包解密

深入分析

然而固件中其他文件如何存储的仍未知，因为其可能在其他类型的文件系统。在进一步分析的过程中，我们发现如果一页的开头有程序名字，这一页不用的地方会全部0xff填充掉，下一页开始就会是这个程序或文件的内容，利用这个规律把其中的校验值去掉，重新提取服务程序。（后经验证，存放程序名页中的偏移292字节以小端序存放了该程序的大小）

图 页中的文件名与文件大小

图 下一页的文件内容

        因此按页分析考虑文件头与文件名、文件大小间相对距离固定，那就可以通过文件头索引到文件开头，再索引到文件大小和文件名，封装成脚本进行提取。具体细节可参考xyzmpv师傅的提取脚本[4]。

总结

        NandFlash固件提取分析相较NOR Flash难许多，且没有统一的识别提取方法。一个重要的原因在于OOB区域的剔除以及识别所用文件系统烧写过程中的规律。最后感谢L3m0nade师傅在固件分析提供的帮助以及xyzmpv师傅的积极参与和讨论。

参考

[1]https://yaffs.net/yaffs-2-specification [2]https://android.googlesource.com/platform/external/yaffs2/+/master/yaffs2/utils/mkyaffs2image.c [3]https://github.com/devttys0/yaffshiv [4]https://blog.csdn.net/weixin_45209963/article/details/124502211

原文始发于微信公众号（ChaMd5安全团队）：某设备NandFlash固件分析