分析未知格式的打包文件，如何继续？答案

【问题标题】：analysing packed file of unknown format, how to continue?分析未知格式的打包文件，如何继续？
【发布时间】：2015-07-13 17:39:06
【问题描述】：

我有兴趣深入了解 Behringer X32 调音台的固件，因此我从 (http://www.behringerdownload.de/X32/X32_Firmware_2.10.zip) 下载了实际文件并启动了 IDA pro。里面包含的 .update-file 以某种时间戳开头，下面的字符串表看起来几乎是一个目录列表，我假设这些文件是以某种方式连接到固件更新文件中的文件。比如有字符串

seg000:00005480: logo/X32RACK.bmp

但由于没有类似位图的结构，我假设这是压缩数据。我怎样才能从这里继续？有没有办法解释各种打包和/或连接的文件格式猜测和尝试/错误格式。

或者——甚至更好——有人知道使用这种结构的打包器吗？

64    bytes c-string
24    bytes zero, probably reserved
DWORD with some index, increasing thru the file but not always +1
DWORD of files Size
32    bytes additional data

到目前为止我发现了什么：

00000000  db '"2.10 23db64e4672e (Thu, 20 Nov 2014 14:50:29 +0100) (clean)"',0,0,0; UpdateID
00000000  dd 6 dup(0)  ; reserved
00000000  dd 181   ; NumberOfContainedFiles
00000000  dd 12380    ; SomeUnknownValue
00000000  dd 44B026A4h, 0BA3708DBh, 4DD38F6Eh, 0F7C30159h, 31D6B225h; Data
00000000  dd 0DAA98CD6h, 26BF22F1h, 0BD9644B1h; Data
00000080  db 'binary/cheditC_C.bin', 45 dup(0); fileName
00000080  dd 6 dup(0)  ; reserved
00000080  dd 46    ; someValue
00000080  dd 4704  ; fileSize
00000080  dd 0DF3241E4h,  89FA54F6h,  12151762h; Data
00000080  dd 5D8FCCCAh,  19A58A36h, 0C47912D5h; Data
00000080  dd 0A629BC65h, 0C8706863h; Data
00000100  db 'binary/cheditP_P.bin', 45 dup(0); fileName
00000100  dd 6 dup(0)  ; reserved
00000100  dd 56    ; someValue
00000100  dd 4896  ; fileSize
00000100  dd 7567F90Fh,  94027A93h,  131CEDFCh; Data
00000100  dd 6D712A26h,  8CD5722Bh,   35D860h; Data
00000100  dd 3BF0E937h,  8BDAFFE2h; Data
00000180  db 'binary/cheditR_R.bin', 45 dup(0); fileName
00000180  dd 6 dup(0)  ; reserved
00000180  dd 66    ; someValue
00000180  dd 5024  ; fileSize
00000180  dd 97B9D746h,  6FF72013h,  6FC5761Bh; Data
00000180  dd 333181A9h, 0EF312D82h, 0CD39570Bh; Data
00000180  dd 0DE1D71F7h,  4B6047DAh; Data

（……相似的数据……）

00005A80  db 'styles/ablesque.rsrc.z', 42 dup(0); fileName
00005A80  dd 6 dup(0)  ; reserved
00005A80  dd 7111  ; someValue
00005A80  dd 2697635   ; fileSize
00005A80  dd 2B368721h,  929F40Eh, 0DE923A1Bh; Data
00005A80  dd 152F06D2h,  86D758BBh,  0B73DC55h; Data
00005A80  dd 0F418E36Ah, 0D03D2C4Ah; Data

然后是压缩数据。

这个小程序有助于分析它：

struct descriptor
{
    char  zName[64];     // filename or update name
    UINT32 reserved[6];  // unused
    UINT32 lIndex;       // kind of index?

    // size of file, in update:
    // datastart + chunksize / chunk_block_size
    // = file_size in blocks á 512 bytes
    UINT32 lFileSize;

    // unknown but shared between some files
    // it seems to be infact a 128-bit structure, as
    // those data records sharing the first sig have the
    // 2nd sig also equal.
    UINT64 signature[2];
    // unknown but probably also a "UINT128"
    // for some records, sig and data are completely the same
    UINT64 data[2];
};

int _tmain(int argc, _TCHAR* argv[])
{
descriptor dsc;
if (argc < 2)
{
    printf("ERROR: missing filename.");
    return 0;
}

std::ifstream fin;
fin.open(argv[1], std::ios::binary);

if (fin.fail()) {
    printf("ERROR: cannot open file\n%S", argv[1]);
    return 0;
}

fin.read((char*)&dsc, 128);

printf("firmware update version\n%s\n", dsc.zName);
int iFiles = dsc.lIndex;
long lSize = 0;
printf("containing %d files.\n\n", iFiles);

printf("index\t    size\tname\t\n");
printf("------------------------------------------------\n");
while (iFiles-->0)
{
    fin.read((char*)&dsc, 128);
    if (fin.fail())
    {
        printf("ERROR: read-error\n");
        return 0;
    }
    printf("%5d\t%8d\t%s\n", dsc.lIndex, dsc.lFileSize, dsc.zName);
    lSize += dsc.lFileSize;
}
fin.close();
printf("------------------------------------------------\n");
printf("%8d bytes in total.", lSize);

return 0;
}

【问题讨论】：

我写了一个分析档案的小程序。我仍然不知道如何提取任何文件，但你可以在这里下载：shadowtec.de/xd/X32chkupd.exe
确实，你有某种有线结构和一个压缩部分（熵非常高），但在进一步尝试之前，请告诉我这是打算使用哪种类型的处理器，所以我知道我正在寻找哪种类型的操作码
很遗憾，Behringer 不会告诉我，而且处理器深埋在混音器内（您必须完全拆解硬件才能看到它）。
顺便说一句，我写的工具有一个源代码存档：shadowtec.de/xd/X32chkupd.src.zip
我刚刚建立的专门用于破解 X32 的 facebook 小组现在提供了许多不同的技术信息：facebook.com/X32Hack

标签： reverse-engineering compression unpack firmware

【解决方案1】：

我找到了一些继续的方法，即使我没有设法解密数据，我现在至少确定它必须被加密/压缩，因为它具有非常高的熵。

我编写了一个从文件数据块创建四个位图的工具。我以字和字节为基础分析文件，计算某些字节/字的所有出现次数并得到这两个直方图，较小的是 Σ(b) = h(x + y*16) 较大的是 Σ(w) = h(x + y*256)。这些是直方图签名：

出现次数最多的字节是 0x62 (Σ=25136)，最少的是 0x33 (Σ=24176)，出现次数最多的词是 0x80b7 (Σ=81)，最少的是 0x77a5 (Σ=22)。

另外两个文件是数据的直方图，在这里发布它们太大了，但它们没有任何明显的结构。

【讨论】：