MRCTF2022 IoT题目之Nand有效数据分析（1）

IoT题目，原题描述：

固件竟然加密了？！
编程器提取出固件S34ML02G200BHI00@BGA63_948.BIN。
你能从中发现解密逻辑吗？

看到文件名：S34ML02G200BHI00@BGA63_948.BIN，通过经验可知是RT809系列的编程器读取的文件形式，这里有意思的地方并不是拿到flag，而是分析编程器读取的数据，那么下面我们主要讲解一下如何分析Nand的有效数据。

首先，根据第一个文件名可知Flash芯片的型号为S34ML02G200BHI00，通过查看芯片的datasheet文件，可以知晓芯片是2Gbit=256MB大小，实际编程器提取的大小为272MB，其中有272MB-256MB=16MB的大小为spare area，也就是OOB区，通常在OOB区存放坏块标记、ECC较验码、文件系统信息(yaffs)等。

根据IO总线的位宽不同，芯片的页大小、块大小、板块大小有着不一样的分布，下面是256MB存储情况下，IO总线位宽为8bits的时候的信息：

分类	单个分类大小 (bytes)	有效数据大小 (bytes)	OOB大小 (bytes)	备注
页	2048+64	2048	128	最小存储形式
块	1281024 + 81024	128*1024	8*1024	1块=64页
板块	12810241024 + 810241024	12810241024	810241024	1板块=1024块

对于S34ML02G200BHI00这款芯片的芯片结构图如下所示：

通过资料可以了解到，每页有2048字节（0x800）有效数据块和128字节（0x80）OOB数据块，那么如何去除OOB数据块获取所有的有效数据块就是最关键的地方！

使用16进制工具查看提取的文件，最开始的部分通常是BootLoader：

按照图解的说明，0x800-0x87F应该是OOB数据块，经过编写脚本自动去除这些数据段，再用binwalk或者使用本站的固件分析工具进行解包，就能得到对应的文件内容，可是并不能完成解包操作，那么到底是如何解呢？

再来看看芯片资料（第1张图），右下角提到了，每528字节（0x210）有4位的ECC校验码，这是什么意思呢？

我们使用16进制工具查看，发现0x210开始的数据块的上方与下方还是有太大的区别的，比如最明显的右边的OD上面是FD，下面也是FD，是不是有些不对应的感觉（这里只是猜测）。

同样，在0x410开始的数据块的上方与下也是有太大的区别的（这里只是猜测）。

由于BootLoader的文件结构没有统一的格式，这里也无法通过这点信息进行分析，那么我们再向文件后面的区域进行分析，能够找到有规律的数据块是最好的，如全是00的数据块、连续字符串的数据块、特殊文件的数据块等等。

这里我们找到了一个BootLoader的配置信息，根据bootcmd、bootm等字符串可以知道此BootLoader为U-BOOT的，这块数据刚好是U-BOOT的配置信息（可以参考之前的文章《U-BOOT命令示例》）。

通常U-BOOT的配置信息是先清0再存储的，且配置区间的大小是比较充足的，那么应该可以找全是00的数据块，再进行分析OOB就比较容易了，这里我们截取了0x89980-0x8A1FF这个区间（0x880大小）。

由于这个区间段有效数据应该全是00，那么不是00的就是OOB区了，通过写脚本或肉眼观察就能简单的得到想要的内容。

通过观察可以清除的看到0x89D90开始的14个字节的数据（块1）、0x8A170开始的2字节数据（块2）以及从0x8A190开始的112字节的数据（块3）是比较可疑的，而块3里面包含00是否是有效数据的一部分呢？

其实块1+块2+块3大小=128字节，是满足于每页的OOB大小为128字节的，再根据其他页的规律可以看出块3的00都存在，基本可以断定我们的猜想是正确的。

知道了OOB区的规律之后，我们可以编写脚本（python版）：

#!/usr/bin/python3

data = open("S34ML02G200BHI00@BGA63_948.BIN", "rb").read()

f = open("fix.bin", "wb")
p = 0x880
for i in range(len(data)//p):
    f.write(data[i*p:i*p+0x410] + data[i*p+0x41E:i*p+0x800] + data[i*p+0x802:i*p+0x810])
f.close()

最终用binwalk就能解开修复的固件fix.bin（命令：binwalk -Me fix.bin）：