对固件进行逆向工程。有人可以帮助我吗?

逆向工程 二元分析 固件 解密 解压
2021-07-07 16:06:49

我目前正在尝试对固件文件进行逆向工程以了解该主题,但我有点卡住了。

我试图用来binwalk获取有关该文件的更多信息,但这并没有产生任何有用的信息。以下是binwalk使用 -I 参数运行的输出,该参数显示标记为无效的结果: 在此处输入图片说明

通过使用stringshexdump分析文件几乎没有发现有用的信息该文件似乎已加密或打包。有没有人有任何想法可以帮助我继续调查这个问题?也许建议使用一些好的工具?

1个回答

查找:NGA_FW_CURRENT.BIN是压缩的Videx微芯片固件映像文件。

初步说明

关于问题中据称是固件的文件的评论中给出了相互矛盾的背景信息。

authorizer.tar.gz位于https://70.60.240.178:8443/Cyber​​AuditWeb/services/nga/download/的名为“NGA 软件”链接的标题“Web Authorizer”下的gzip 压缩数据文件包含一个名为NGA_FW_CURRENT.BIN. 该文件与firmware.BINhttp://s000.tinyupload.com/?file_id=33872947945158763451 中找到的文件不同

这是第二个文件,firmware.BINbinwalk在问题的图像中运行。的来源firmware.BIN未知,因为提供了有关不同文件的信息NGA_FW_CURRENT.BIN

比较这两个文件表明它们可能是相关的,因为它们的大小相同,均为 61445 字节并且具有相似的结构: 差异部分 1

差异部分 2

差异部分 3

差异部分 4

差异部分 5

其中一些信息可能在随后的分析中被证明是有用的。由于NGA_FW_CURRENT.BIN该位置的文件被声明为源文件,因此将进一步分析该文件而不是firmware.BIN.

NGA_FW_CURRENT.BIN解析

binwalk未检测到任何压缩签名NGA_FW_CURRENT.BIN

$ binwalk NGA_FW_CURRENT.BIN

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

熵分析基于 devttys0 在他的文章Differentiate Encryption From Compression Using Math 中所做的工作,表明文件被压缩而不是加密。

  • 较低的 chi 值 (< 300) 和较高的 pi 误差 (> .03%) 表示压缩。
  • 较高的 chi 值 (> 300) 和较低的 pi 误差 (< .03%) 表示加密。

熵分析使用ent

$ ent NGA_FW_CURRENT.BIN
Entropy = 7.997014 bits per byte.

Optimum compression would reduce the size
of this 61445 byte file by 0 percent.

Chi square distribution for 61445 samples is 253.82, and randomly
would exceed this value 50.92 percent of the times.

Arithmetic mean value of data bytes is 127.6737 (127.5 = random).
Monte Carlo value for Pi is 3.126171875 (error 0.49 percent).
Serial correlation coefficient is 0.028565 (totally uncorrelated = 0.0).

253.82 的卡方分布和 0.49% 的 pi 误差值在压缩数据的预期范围内。

这是由 生成的熵图binwalk熵图

上面的这个图表明了以下几点:

  1. 从偏移量 0x00 开始而不是进一步进入文件的高熵意味着没有清晰可辨的文件头结构,这是不寻常的。
  2. 熵线粗糙而不是平坦,表明压缩而不是加密。粗线反映了firmware.BIN的差异所暗示的文件的非统一结构NGA_FW_CURRENT.BIN文件中的某些块的熵低于其他块。
  3. 偏移量 ~60000(十进制)处熵的急剧下降表明文件末尾有一个非常低熵的字节块

使用binvis.io将可视化NGA_FW_CURRENT.BIN与 Linux 实用程序ls支持上述建议。

 ________ NGA_FW_CURRENT.BIN _______   ________________ ls _______________ 
|                                   | |                                   |
v                                   v v                                   v

文件结构可视化 文件熵可视化 ls结构 ls 熵

        ^         ^          ^                ^                  ^
        |         |          |                |                  |
        |     small area     |             obvious          low  entropy
        |      of low        |            structures         throughout  
        |      entropy       |                                  file
        |               high entropy
   No structure        throughout file

正如我们所看到的,结构的可视化NGA_FW_CURRENT.BIN看起来像白噪声,并且始终具有高熵,而ls具有清晰的结构(ELF 标题、部分)和相对较低的熵。

表明压缩而不是加密的其他证据是缺乏来自 ARM ELF32 二进制文件的加密/解密库和例程FWLoader,其目的是在启动期间加载设备固件(见下文)。

NGA_FW_CURRENT.BIN 是固件镜像文件吗?

简短的回答是肯定的(可能)。

最直接的证据可以在S85_check_firmwaresystem/rc3.d/ 目录中的 POSIX shell 脚本找到

这里是源代码S85_check_firmware

#!/bin/sh

cd /firmware

#Since this script happens very early in the boot process we the opportunity to
#  tell the user we are actually still booting as opposed to the keypad showing it's default
# "READY" message.
ngautil -p "CHECKINGFIRMWARE"

#This script checks the videx microchip firmware and reflashes it if necessary

#the FWLoader program must be executable
#and the LBServer.ini file must exist
if [ -x ./FWLoader -a -e ./NGA_FW_CURRENT.BIN ]
then

        #increment the number of checks
        echo checking >> checks.log
        NUM_CHECKS=`grep -c checking checks.log`

        #don't do the FW check if we've already checked many times with this FW version.  This prevents
        #endless an endless cycle of firmware loading and rebooting in case the firmware file is corrupt
        if [ $NUM_CHECKS -lt 16 ]
        then
                echo "Executing firmware check #$NUM_CHECKS"

                ./FWLoader NGA_FW_CURRENT.BIN
                #The above call to FWLoader will only attempt to load the firmware if the version in the chip
                #is lesser than in the file.  If the chip is already in boot-load mode (because fw loading was interrupted
                # previously) it will force loading of the firmware.
                #If fw is reloaded succesfully the device will be rebooted
                echo "Firmware check complete"
        else
                echo "Firmware checking skipped (has already been checked $NUM_CHECKS times)"
        fi
else
        echo "Firmware check skipped (missing FWLoader or NGA_FW_CURRENT.BIN)"
fi 

由于FWLoader通常“只有在芯片中的版本低于文件中的版本时才会尝试加载固件”,因此在这种情况下的文件是NGA_FW_CURRENT.BIN,解压的关键NGA_FW_CURRENT.BIN必须在FWLoader.

分析了 的.rodata部分时FWLoader,几乎立即发现了一个线索:

Hex dump of section '.rodata':
  0x000123cc 01000200 4e474120 4669726d 77617265 ....NGA Firmware
  0x000123dc 204c6f61 64657220 7625730a 00000000  Loader v%s.....
  0x000123ec 322e3000 55736167 653a205b 2d2d666f 2.0.Usage: [--fo
  0x000123fc 7263655d 203c7061 74682074 6f206669 rce] <path to fi
  0x0001240c 726d7761 72652066 696c653e 0a000000 rmware file>....
  0x0001241c 4e6f7465 3a206669 726d7277 61726520 Note: firmrware 
  0x0001242c 66696c65 206d7573 74206265 20707265 file must be pre
  0x0001243c 70656e64 65642077 69746820 76657273 pended with vers
  0x0001244c 696f6e20 62797465 20616e64 20342062 ion byte and 4 b
  0x0001245c 79746520 43524320 61732069 74206170 yte CRC as it ap
  0x0001246c 70656172 7320696e 204c4254 6573742e pears in LBTest.
  0x0001247c 696e690a 00000000 4661696c 65642074 ini.....Failed t
  0x0001248c 6f207265 61642063 68697020 6669726d o read chip firm
  0x0001249c 77617265 20766572 73696f6e 2e202853 ware version. (S
  0x000124ac 7475636b 20696e20 626f6f74 6c6f6164 tuck in bootload
  0x000124bc 206d6f64 653f290a 00000000 63526561  mode?).....cRea
                     < output snipped >

“注意:固件 [sic] 文件必须以版本字节和 4 字节 CRC开头,因为它出现在 LBTest 中。” (旁注:在authorizer.tar.gz提取所有这些文件的下载网站上,版本号为 37.3.3)。

这基本上放弃了。如果/当我隔离实际的解压代码时,我会发布更新。