固件分析和文件系统提取？

我正在尝试分析NAS设备的固件映像。

我使用了各种工具来进行分析（binwalk，deezee，signsrch，使用binwalk AFAIK的firmware-mod-kit），但所有例如，binwalk似乎对gzip压缩数据和Cisco IOS实验性微代码产生了误报。

Scan Time:     2013-08-27 14:52:15
Signatures:    196
Target File:   firmware.img
MD5 Checksum:  4d34d45db310bf599b62370f92d0a425

DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
80558935        0x4CD3B57       gzip compressed data, ASCII, has CRC, last modified: Fri Oct  4 17:37:33 2019
82433954        0x4E9D7A2       Cisco IOS experimental microcode
145038048       0x8A51AE0       gzip compressed data, ASCII, extra field, last modified: Mon May 26 20:11:40 2014

>尝试解压缩数据时，使用gunzip / gzip出现以下错误

gzip: 4CD3B57.gz is a multi-part gzip file -- not supported

根据gzip常见问题解答（http://www.gzip.org/#faq2 ）这是由于未以二进制方式进行的传输已损坏了gzip标头。

从binwalk看来，这似乎是误报，主要是因为用于标识gzip数据的幻数很容易触发误报和日期错误。

我还运行了字符串和hexdump命令，以了解文件的内容并尝试识别已知的模式，但并没有太大帮助远（我可能在这方面没有经验）。

唯一不乱码/可识别的字符串位于固件映像的末尾。

00000000  f5 7b 47 03 d5 08 bf 64  ba e9 99 d8 48 cf 81 18  |.{G....d....H...|
00000010  b1 69 1e 2c c2 f3 46 6b  53 2b b7 63 e8 ce 78 c9  |.i.,..FkS+.c..x.|
00000020  87 fd b8 68 41 4d b2 61  71 cb cc 75 eb 8c e0 75  |...hAM.aq..u...u|
00000030  25 d1 ec bd 6d 46 e8 16  37 c6 f5 2e 2a e0 dc 07  |%...mF..7...*...|
00000040  65 b1 ce 7f 20 57 7c d7  cb 1d 91 fc 05 25 ad af  |e... W|......%..|
00000050  58 56 ff 13 4d 03 95 7f  ad 58 0e 84 85 2f 73 5c  |XV..M....X.../s\|
00000060  d9 19 d4 d4 2c 27 be c6  45 f2 9f a4 b1 e1 04 f1  |....,'..E.......|
00000070  c1 28 17 9c e1 f7 9d 2b  63 c3 7d e1 95 56 06 05  |.(.....+c.}..V..|
[...]
09ec9d60  4b 29 75 20 46 6e fb e3  0f 14 d4 93 54 8e 4f bb  |K)u Fn......T.O.|
09ec9d70  4b ab 91 bf e7 8a b9 4e  c8 ff 87 17 93 19 e9 3f  |K......N.......?|
09ec9d80  70 fe a6 9f d3 36 48 83  34 48 83 34 48 83 34 48  |p....6H.4H.4H.4H|
09ec9d90  83 34 48 83 34 48 83 34  48 83 34 48 83 34 48 83  |.4H.4H.4H.4H.4H.|
09ec9da0  34 48 83 34 48 83 34 48  83 34 48 83 34 48 83 34  |4H.4H.4H.4H.4H.4|
09ec9db0  48 83 34 48 83 34 48 83  34 48 83 34 48 83 24 a7  |H.4H.4H.4H.4H.$.|
09ec9dc0  ff 07 e9 0d 37 73 00 20  08 0a 69 63 70 6e 61 73  |....7s. ..icpnas|
09ec9dd0  00 00 10 00 54 53 2d 35  36 39 00 00 00 00 00 00  |....TS-569......|
09ec9de0  00 00 00 00 33 2e 38 2e  33 00 00 00 00 00 00 00  |....3.8.3.......|
09ec9df0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
09ec9e14

这是我第一次进行这种锻炼，因此我不确定下一步该怎么做。图片似乎以某种方式被混淆了（这可能是一个错误的假设）。

您是否有建议/技巧可以帮助我取得一些进步？

#1 楼

一段时间以来，我一直在剖析另一种嵌入式设备的固件，并想知道是否能找到任何东西。几个小时后，我想通了！只有在摸索出艰难的道路之后，我才能找到一种艰难的道路和一种容易的道路。这是一篇很长的文章，但我希望它能对其他类似的企业有所帮助。同一wiki上的另一页，其中包含“命令行示例”，用于“手动更新固件”。 NAS上有几件事...

NAS操作系统具有用于处理固件更新映像的脚本：

# /etc/init.d/update.sh /mnt/HDA_ROOT/update/TS-209_2.1.2_build1031.img

二进制文件中嵌入了一个校验和，然后输出中存在以下行：

"Using 120-bit encryption - (QNAPNASVERSION4)"

我去了向下的2条路径：困难的方法和非常简单的方法...

困难的方法（但有一些有用的技巧）

我下载了TS-569完整系统恢复来自“固件恢复”页面的图像，耗时近2个小时，耗时500MB。现在，我必须弄清楚我正在使用什么软件：

# file F_TS-569_20120628-1.2.2.img
F_TS-569_20120628-1.2.2.img: x86 boot sector; GRand Unified Bootloader, ...

完整的磁盘映像如下：

$ fdisk -l F_TS-569_20120628-1.2.2.img
                      Device Boot      Start         End      Blocks   Id  System
F_TS-569_20120628-1.2.2.img1              32        4351        2160   83  Linux
F_TS-569_20120628-1.2.2.img2   *        4352      488959      242304   83  Linux
F_TS-569_20120628-1.2.2.img3          488960      973567      242304   83  Linux
F_TS-569_20120628-1.2.2.img4          973568     1007615       17024    5  Extended
F_TS-569_20120628-1.2.2.img5          973600      990207        8304   83  Linux
F_TS-569_20120628-1.2.2.img6          990240     1007615        8688   83  Linux

分离分区（或者您可以将映像写入备用磁盘）：

# dd if=F_TS-569_20120628-1.2.2.img bs=512 of=part1 skip=32 count=2160w
# dd if=F_TS-569_20120628-1.2.2.img bs=512 of=part2 skip=4352 count=242304w
# dd if=F_TS-569_20120628-1.2.2.img bs=512 of=part3 skip=488960 count=242304w
# dd if=F_TS-569_20120628-1.2.2.img bs=512 of=part5 skip=973600 count=8304w
# dd if=F_TS-569_20120628-1.2.2.img bs=512 of=part6 skip=990240 count=8688w  
... which gives  
-rw-r--r-- 1 root   root     2211840 2013-08-30 15:41 part1
-rw-r--r-- 1 root   root   248119296 2013-08-30 15:42 part2
-rw-r--r-- 1 root   root   248119296 2013-08-30 15:42 part3
-rw-r--r-- 1 root   root     8503296 2013-08-30 15:42 part5
-rw-r--r-- 1 root   root     8896512 2013-08-30 15:42 part6

分区3是分区2的镜像，通过以下方式验证md5sum。分区5和6是空的，可能有暂存空间。分区1是/ boot / grub，其中包含用于引导和硬件配置的模块等。因此，让我们看一下分区2，即启动分区。使操作系统运行
qpkg.tar为NAS提供了各种软件包
rootfs2.bz是一些/ home，/ lib和/ usr文件的压缩tarball
rootfs_ext.tgz是/ opt / source的另一个ext2文件系统的压缩tarball，用于apache，php5，mysql，并且似乎是NVRAM设置的备份。

所有的魔法都在initrd文件系统映像。凝视着我们得到：

# mkdir /mnt/ts2
# mount -r part2 /mnt/ts2 -o loop
# ls -la /mnt/ts2/boot
-rw-r--r-- 1 root root  3982976 2012-06-27 22:17 bzImage
-rw-r--r-- 1 root root       81 2012-06-27 22:17 bzImage.cksum
-rw-r--r-- 1 root root  8890727 2012-06-27 22:17 initrd.boot
-rw-r--r-- 1 root root       85 2012-06-27 22:17 initrd.boot.cksum
-rw-r--r-- 1 root root 73175040 2012-06-27 22:17 qpkg.tar
-rw-r--r-- 1 root root       83 2012-06-27 22:17 qpkg.tar.cksum
-rw-r--r-- 1 root root 33593992 2012-06-27 22:17 rootfs2.bz
-rw-r--r-- 1 root root       85 2012-06-27 22:17 rootfs2.bz.cksum
-rw-r--r-- 1 root root 31160679 2012-06-27 22:17 rootfs_ext.tgz
-rw-r--r-- 1 root root       87 2012-06-27 22:17 rootfs_ext.tgz.cksum
# file -z /mnt/ts2/boot/initrd.boot
/mnt/ts2/boot/initrd.boot: Linux rev 1.0 ext2 filesystem data, UUID=770ce31c-d03f-484e-81e8-6911340bdcbf (gzip compressed data, from Unix, last modified: Wed Jun 27 22:16:58 2012, max compression)

还记得从“固件恢复”页面突出的两件事吗？更新脚本和加密参考：

# gunzip -c /mnt/ts2/boot/initrd.boot >/tmp/initrd.boot.img
# mkdir /mnt/tsinitrd
# mount -r /tmp/initrd.boot.img /mnt/tsinitrd -o loop
# ls -la /mnt/tsinitrd
drwxr-xr-x  2 root root  2048 2012-06-27 22:05 bin
drwxr-xr-x  5 root root 13312 2012-06-27 22:11 dev
drwxr-xr-x 22 root root  2048 2012-06-27 22:15 etc
drwxr-xr-x  3 root root  3072 2012-06-27 22:05 lib
drwxr-xr-x  2 root root  1024 2010-11-03 04:53 lib64
lrwxrwxrwx  1 root root    11 2012-06-27 22:16 linuxrc -> bin/busybox
drwx------  2 root root 12288 2012-06-27 22:16 lost+found
drwxr-xr-x  4 root root  1024 2012-06-27 22:04 mnt
drwxr-sr-x  2 root root  1024 2012-06-27 22:16 opt
lrwxrwxrwx  1 root root    19 2012-06-27 22:16 php.ini -> /etc/config/php.ini
drwxr-sr-x  2 root root  1024 1999-11-02 18:54 proc
lrwxrwxrwx  1 root root    18 2012-06-27 22:16 Qmultimedia -> /share/Qmultimedia
drwxr-xr-x  3 root root  1024 2007-07-18 05:24 root
drwxr-xr-x  2 root root  5120 2012-06-27 22:15 sbin
drwxrwxr-x 29 root root  1024 2006-02-28 00:57 share
drwxrwxrwx  4 root root  1024 2006-02-28 00:57 tmp
drwxrwxrwx  8 root root  1024 2012-06-27 22:15 var

这里有对似乎是加密密钥甚至解密器的引用！
由于此NAS固件映像是基于x86的，并且我在x86 VM中，不妨尝试一下：

# more /mnt/tsinitrd/etc/init.d/update.sh
...
... line 223
    /sbin/PC1 d QNAPNASVERSION4 $path_name ${_tgz};
...

最后： />
所有这些都可以找到一个可执行文件，为我们解密固件映像，一个脚本为我们提供纯文本解密密钥，以及一种在我们想要修改内容时将所有内容打包在一起的方法。 br />
...现在又有了完全不同的东西

非常简单的方法

一旦我走到了“艰难之路”的尽头，我决定通过Google搜索加密密钥“ QNAPNASVERSION4”。第一个结果是针对C语言中的PC1 enc / dec算法，有人已经对它进行了如此友好的修改，以处理针对我们的固件格式细节：http://www.r00ted.com/downloads/pc1.c

更新：据报告链接已损坏，这是转储：http://pastebin.com/KHbX85nG

# /mnt/tsinitrd/sbin/PC1
Usage: pc1 e|d "key" sourcefile <targetfile>
where: e - encrypt, d - decrypt & "key" is the encryption key.
The length of the key will determine strength of encryption
If no targetfile, output file name is equal to sourfile name
ie: 5 characters is 40-bit encryption.

现在您有了一个可以解密固件文件的实用程序无需物理访问NAS即可从自己舒适的操作系统中轻松访问。

很棒的同事，我应该在供应商页面上花费更多的时间。谢谢

–胡子
2013年9月2日于13:08

pc1.c链接已损坏。

–提问
2014年8月19日上午10:51

我更新了帖子，以包含指向源代码的pastebin链接。

–大卫
14年8月19日在19:22

#2 楼

该文件确实看起来已加密或模糊。可能可以使用一些密码分析来弄清楚（末尾的34 48 83序列看起来不是随机的），但最好还是去寻找UART或JTAG引脚，或者运行的telnet服务器或其他服务

编辑：在NAS的下载页面上，有一些名为“ Qfix”的较小下载。它们似乎是简单的自解压shell脚本+ tar.gz数据。我建议您尝试使用Shell脚本制作自己的.qfix，该脚本会将文件从设备中复制出来，而不是正常行为。

但是，有文件页脚可能用于完整性检查。 “ SambaFix”旁边的数字看起来像一些校验和。

问题是我只能通过下载的固件映像工作，而无法访问物理设备。可能不是最简单的学习方法。我将查看34 48 83的序列，看看是否可以提出一些建议。任何意见欢迎。

–胡子
13年8月28日在17:06

我认为如果没有物理访问，您不会解决这一问题。

–伊戈尔·斯科钦斯基♦
13年8月28日在17:15

我同意伊戈尔的观点。每个固件版本具有相同的前四个字节（可能具有魔术签名），并在末尾带有一些型号/版本字符串。否则，它们是完全不同的。整个固件中有许多不同的重复字节序列，压缩时可能不会发生，因此会进行加密/混淆。 FWIW，对于XOR编码，熵似乎太高，但是对于诸如AES CBC之类的强加密来说，熵太低。

–devttys0
13年8月29日在4:20

对于我来说可能有点太先进了，无法解决，但确实有用。如果发现值得共享的内容，我将更新线程。

–胡子
13年8月29日在9:16

#3 楼

我知道这是一个比较老的问题，但是我只想在讨论中添加一些更新的信息，以便将来寻求答案。

我也在对此进行试验。较新版本的binwalk具有自动提取功能。只需运行：

binwalk -e ./firmwarefile.bin

它将提取不同的分区并将其分割为单独的文件夹。这比使用dd容易得多，在squashfs中，如果输入的值错误，则gzip / binwalk / ...只会将其视为损坏。

另外，获取Kali或Backtrack linux的副本（Backtrack现在可能已贬值。我认为，Kali是首选）。他们已经安装了binwalk和固件mod utils或在apt软件包管理器仓库中，以方便使用安装。

关于重新打包要上传的固件，我自己还没走那么远。对于我使用的固件，q4312079q也将提取带有签名的文件。其中包含用于验证设备固件的MD5数据。

#4 楼

我找到了一些可以使用固件的工具，但是没有一个工具可以用来“播放”为媒体播放器下载的固件，也许对您更有用：

http：// www.routertech.org/tools/firmware_tool-097b.zip

固件修改工具包：
http://code.google.com/p/firmware-mod-kit/downloads/list

我只想弄清楚哪些网页存储在设备上，哪些可以作为NAS使用，但是我无法访问Linux机器。

编程黑洞网

固件分析和文件系统提取？

#1 楼

评论

#2 楼

评论

#3 楼

#4 楼