记一次固件提取
date
Jun 8, 2022
slug
h3c-takeout-source
status
Published
tags
固件安全
summary
在h3c的官网上找到一个固件，研究了一下
type
Post
在h3c的官网上找到一个固件，研究了一下
踩坑记录
当下载到一个固件时一开始的操作就是解压里面的文件系统然后再去进行分析，解压分析固件的最好工具就是binwalk，所以我上来就是使用binwalk自动解压的功能：
binwalk -Me SecPathF1000C8102-CMW710-E6472.BIN但是等来的结果却是不停地解压，然后电脑就直接黑屏了。。。。。
等到第二次继续尝试自动解压功能的时候，等binwalk执行到一半我就把它给停了，去瞅一眼看看是否存在cpio压缩文件然后再去解压，因为之前遇到过类似的情况；但是这次不一样，这次里面整出来是一个lzo文件，问了几个搞固件的舍友，说有可能是vxworks或者是rtos文件系统的东西
但是根据单纯binwalk出来的信息进行分析，发现并不是vxworks或者是rtos文件系统，应该还是Linux，白花了时间找怎么vxworks提取固件。。。。还是得关注一下binwalk里面的信息
但也在binwalk信息里面发现另外的一些东西，看到这了这一句话：
Ubiquiti firmware additional data ，然后猜测是不是这个系统的，然后网上找了两篇文文章测试：都需要将UBI文件提取出来才能进行后续的操作，但是首先得找到UBI的分布，跑了一下文章里的脚本，发现这个固件并不符合UBI的文件偏移分布，没有任何输出，思路又匮乏了
后来还是我舍友给了两个思路，果然是搞IOT的大佬：
- 直接上手调试binwalk，看看binwalk在哪里嵌入了循环，然后再从那里入手
- 还是得配合binwalk里面的信息，dd手动提取，然后再分析
我感觉第一个思路太麻烦了，就选择了第二个思路分析，在binwalk的分析结果里，存在多个gzip文件头，可以考虑将gzip文件一个个抠出来，然后分析，选择从第二个开始扣，因为第一个gzip文件头后还跟着一堆很乱的东西，而第二个后面刚好就是一堆xz压缩内容，这一个应该是比较正常的压缩被容
然后把固件放到16进制编辑器里面看，看一下这个位置前后是不是对应gzip文件头，而且偏移是不是感觉对，没错，就是感觉一下，gzip文件标志头想到Java反序列化部分场景了
1F8B08 ，base64之后是H4sl，
dd操作起来：
dd if=SecPathF1000C8102-CMW710-E6472.BIN bs=1 skip=$((0x98D4D0)) of=secgzip2.gzip然后得到
secgzip2.gzip 之后解压再次binwalk分析一下，此时里面已经出现了cpio文件
打开文件夹里面的内容，里面已经是文件系统的内容了
但是！！！这并不是放置源码的文件系统，这里面还有一个文件系统
rootfs.squashfs ，我们需要进一步分析解压猜得到真正的固件源码
再找找对应路由确认一下就是这个固件了
总结
- 多瞅瞅binwalk的分析再去思考🤔
- 人工分析多食用dd配合（多找找最大的文件dd？），提取出来之后再使用binwalk分析，当然binwalk的特性很有可能会存在误导。分析的文件大小越大，越有可能出错
这是因为，在偶然情况下，一个普通的文件也可能会有 binwalk 能解析的 magic bytes 。在这种情况下，就意味着 binwalk 报告的结果是无效的。
这种靠猜的感觉有点CTF的味道了～～～～～～