我仍在处理上一个问题的二进制图像，并且已经发现我的“损坏”数据实际上只是被压缩了。但是现在我有另一个问题，因为我不知道使用了什么压缩类型。
我已经知道的：
数据至少由 9 个字节组成。第一个字节总是一个“标志”，它用 8 位来描述接下来的 8 个字节是否被压缩。压缩的“字节”存储为两个字节。
例子：
ß\DB\cóA\c
ß -> DF -> 11111011 (MSB) -> 6th byte encoded
这意味着“óA”实际上代表“ache”，但我还没有找到“ache”实际存储在内存中的位置。
有问题的图像可在此处获得：https : //we.tl/t-tpG9EjpSbr
基本
我已经查看了您的图像文件，正如您对上一个问题的回答所说，压缩类似于 LZSS。
具体来说，压缩数据以标志字节开始。每个位依次（从位 0 到位 7）表示下一个解压缩字节由 -
（当标志位为 0 时）从解压缩数据流中的早期复制 3 到 18 个字节。这些字节的长度和位置在压缩数据流中编码为 2 个字节。
假设这 2 个字节是（使用虚拟字符的十六进制）0xPQ和0xRS
然后
3 + 0xS18 + 0xRPQ （使用无符号整数算术模 0x1000）例子
让我们看一下将图像中偏移量 0x0008D38E 处的数据解压缩到地址 0x0006E720 处的存储（假设先前的数据已经解压缩。）
compressed data decompressed data
0008D68E: 7D (flag byte 0b01111101)
45 literal byte 0x0006E720: 45
D2 60 3 bytes from 0x6E4 0x0006E721: 6D 65 72 (i.e. copied from 0x0006E6E4)
67 65 6E 63 79 literal bytes 0x0006E724: 67 65 6E 63 79
DA 50 3 bytes from 0x5EC 0x0006E729: 20 4C 6F (i.e. copied from 0x0006E5EC)
0008D699: FF (flag byte 0b11111111)
6F 70 20 54 65 73 74 20 literal bytes 0x0006E72C: 6F 70 20 54 65 73 74 20
0008D6A2: 33 (flag byte 0b00110011)
4F 4E literal bytes 0x0006E734: 4F 4E
08 7F 18 bytes from 0x71A 0x0006E736: 0D 0A 00 00 00 00 45 6D 65 72 67 65 6E 63 79 20 4C 6F
1A 76 9 bytes from 0x72C 0x0006E748: 6F 70 20 54 65 73 74 20 4F (i.e. copied from 0x0006E72C)
46 46 literal bytes 0x0006E751: 46 46
65 22 4 bytes from 0x277 0x0006E753: 0D 0A 00 00 00
06 35 8 bytes from 0x318 0x0006E758: 45 30 34 0D 0A 00 00 00
看看我们看到的解压数据——
0x0006E720: "Emergency Loop Test ON\r\n"
0x0006E73C: "Emergency Loop Test OFF\r\n"
0x0006E758: "E04\r\n"
文件结构
整个文件似乎没有被压缩，而是包含几个以偏移量0x00010000和0x00040000.
每个压缩区域似乎以包含压缩数据长度的 4 字节/32 位值开始。这些长度之后是如上所述的压缩数据。
奖金说明
对相关设备名称和“主板”进行图像搜索会产生清晰可见的 Renesas R8A77240D500BGY 结果。这是 Renesas SH7724 系列中的 MCU，包含 SH-4A RISC CPU 内核。