逆向工程 - 解压并重新打包固件以用作更新版本？ - 吾爱随笔录

解压并重新打包固件以用作更新版本？

逆向工程拆卸固件

2021-07-07 21:07:08

我正在尝试修改 TD-W8961ND 路由器的固件，因为存在一个漏洞，可能允许攻击者下载路由器的配置文件，该文件暴露路由器密码并使其能够在以后控制路由器的设置。我想到了从这里修复它的想法。它能够使用我无法使用的串行端口修改虚拟内存中的固件。

那么，是否有可能应用他在固件中的建议然后更新路由器？

路由器固件已命名，ras并于 2011 年 11 月 25 日发布。

使用 binwalk，很明显该文件是 ZynOS。但是，我真的无法像那里解释的那样提取签名，我真的不知道以后该怎么做。

编辑

binwalk 输出

~$ binwalk ras

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
84992       0x14C00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 66824, compressed size: 16870, uncompressed checksum: 0xF480, compressed checksum: 0xF03A, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
85043       0x14C33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 66824 bytes
128002      0x1F402     GIF image data, version "89a", 200 x 50
136194      0x21402     GIF image data, version "89a", 560 x 50
326749      0x4FC5D     Copyright string: " (c) 2001 - 2011 TP-LINK TECHNOLOGIES CO., LTD.LOGIES CO., LTD."
349184      0x55400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 55931, uncompressed checksum: 0xC892, compressed checksum: 0xC30C, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
349235      0x55433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
405248      0x62F00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 59174, uncompressed checksum: 0x8D2B, compressed checksum: 0x66BC, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
405299      0x62F33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
464640      0x71700     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 52399, uncompressed checksum: 0xA2DE, compressed checksum: 0x917A, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
464691      0x71733     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
517120      0x7E400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 63920, uncompressed checksum: 0xFEC9, compressed checksum: 0xA7FD, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
517171      0x7E433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
581120      0x8DE00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 54909, uncompressed checksum: 0xF811, compressed checksum: 0x3544, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
581171      0x8DE33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
636160      0x9B500     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 61051, uncompressed checksum: 0x36F3, compressed checksum: 0x6A1, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
636211      0x9B533     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
697344      0xAA400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 54463, uncompressed checksum: 0x30D8, compressed checksum: 0x9AB9, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
697395      0xAA433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
751872      0xB7900     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 12440, compressed size: 6879, uncompressed checksum: 0x5C0A, compressed checksum: 0x1945, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
751923      0xB7933     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 12440 bytes
759040      0xB9500     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 3914416, compressed size: 884839, uncompressed checksum: 0xA904, compressed checksum: 0x73E3, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
759091      0xB9533     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3914416 bytes

揭示漏洞的人建议图像中没有 Lzma 压缩数据，因为它看起来是这样，它只是明文中的大块数据。

3个回答

重要的是要知道并非所有 ZyNOS 图像都是平等创建的，适用于 piotrbania 的确切步骤（如您的问题中所述）可能对您不起作用。

首先，ZyNOS 是一个实时操作系统，您可以将整个操作系统视为一个大内核（即，没有用户空间或文件系统或任何类似的易于处理的东西）。根据 ZyNOS 版本、编译器版本、编译器选项、目标架构等，即使是相同的源代码也会编译成不同的字节和指令序列，并且不同版本/风格的 ZyNOS 可能会“打包”非常不同。

在你的情况下，我几乎可以保证那些 LZMA 签名是有效的，并且可能包含一些数据/代码。图像中也可能存在未压缩的原始代码（尝试 binwalk -A 搜索原始可执行代码）。

你需要完成你想要的一些一般步骤：

解压缩所有压缩块并确定哪些块（如果有）包含可执行代码
反汇编所有代码（可能从任何未压缩的代码开始，因为它可能用于引导系统并解压缩固件的其他部分）
反汇编过程的一部分将是识别每个代码段的加载地址；没有这个，数据外部参照就没有意义。查找对绝对内存地址的引用以获取提示（例如，跳转到直接地址、函数表、跳转表等）。
现在您可以开始真正地反转代码，寻找处理 ras 文件请求的代码。如果幸运的话，您将拥有一个反汇编程序无法理解的符号表，因此您必须编写一个脚本来解析符号表并重命名所有符号地址。如果您不那么幸运，则必须手动识别功能。
一旦您确定了需要修补的代码，您就可以以与 piotrbania 类似的方式修补它，但很明显，您的固件映像的细节可能略有不同。
重新压缩并重新打包固件映像部分，更新所有标头校验和，然后上传到您的设备并希望它不会变成镇纸。:)

所以要回答你的问题，是的，这当然是可能的。但是我不知道有一种预构建的解决方案可以让您轻松提取/修补/重新构建固件，因此需要付出一些努力才能完成。显然，对设备进行某种调试访问（例如，UART 或 JTAG）会有很大帮助，正如 piotrbania 的工作所证明的那样。

您可以尝试使用firmware-mod-kit并查看是否有进一步的进展，尽管 firmware-mod-kit 专门针对 Linux，因此它可能没有太大帮助。有时我发现它可以做不能做的事情binwalk（反之亦然）

此外，您可能希望binwalk从最新源构建再试一次。

这有点旧，但我无法执行与 OP 相同的任务——也就是说，找到一个可以正确解压 ZyNOS 固件更新映像的工具。所以我推出了自己的。请抓住并在您的图像上尝试：

https://github.com/dev-zzo/router-tools/blob/master/zynos.py

该工具目前不支持打包图像，但我正在处理它。

其它你可能感兴趣的问题

上一篇尽管有数据执行保护等机制，打包程序如何工作？下一篇IDA Pro 可以自动处理 VM 混淆二进制文件吗？