我相信它没有被压缩或加密。0.8 的熵对于任何体面的加密或压缩来说都非常糟糕。这些区域更有可能是代码。

考虑到这一点，让我们看一下偏移量 0x00001000 处的第一个高熵区域区域中的 hexdump -

00001000:  76 86 65 77 01 01 00 24 FF FF FF FF 00 10 FF FF  v.ew...$........
00001010:  00 00 21 26 00 00 00 00 00 00 00 00 00 00 38 10  ..!&..........8.
00001020:  76 9C 07 9D E5 9F 00 28 EE 01 0F 10 E5 9F D0 24  v......(.......$
00001030:  EA 00 00 0B E5 9F 00 20 E5 9F 10 20 E3 A0 20 00  ....... ... .. .
00001040:  E5 80 10 00 E5 80 10 04 E5 80 20 08 E5 80 20 0C  .......... ... .
00001050:  E1 A0 F0 0E 00 00 1F 74 04 00 20 00 90 00 02 00  .......t.. .....
00001060:  00 00 55 55 E2 8F 80 C4 E8 98 00 03 E0 80 00 08  ..UU............
00001070:  E0 81 10 08 E2 40 B0 01 E1 50 00 01 0A 00 00 13  .....@...P......
00001080:  E8 B0 00 70 E1 54 00 05 0A FF FF FA E3 14 00 01  ...p.T..........

几乎每个第 4 个字节都有一个高半字节的事实E强烈表明 32 位 ARM 代码。

这确实留下了为什么区域看起来乱码的问题。例如

000128B0:  47 18 BC 08 65 48 20 3A 6D 20 70 61 72 6F 6D 65  G...eH :m parome
000128C0:  6F 63 20 79 70 75 72 72 00 64 65 74 20 74 75 4F  oc ypurr.det tuO
000128D0:  68 20 66 6F 20 70 61 65 6F 6D 65 6D 00 00 79 72  h fo paeomem..yr

我认为正在发生的事情是一些字节序混淆，可能与闪存与 SOC/MCU 的接口方式有关，或者可能与您用来转储闪存的程序设置有关。

因此，再次查看偏移量 000128B0 处的区域，但首先反转每组 4 个字节。这给你——

000128B0:  08 BC 18 47 3A 20 48 65 61 70 20 6D 65 6D 6F 72  ...G: Heap memor
000128C0:  79 20 63 6F 72 72 75 70 74 65 64 00 4F 75 74 20  y corrupted.Out 
000128D0:  6F 66 20 68 65 61 70 20 6D 65 6D 6F 72 79 00 00  of heap memory..

这更有意义。通过这种转换，其他明显的字符串也变得可读。

我建议你把它应用到整个文件，看看会给你带来什么。

您是否已经尝试使用 binwalk 之类的工具分析转储？
如果不是，我会建议先这样做。这可能已经澄清了您的情况。
您还可以使用 binwalk 检查熵以验证这是否真的被压缩或加密。

除此之外，我问你你是如何转储固件的？您确定转储本身是正确的吗？
这让我想起了不久前我正在做的一个项目。我的脚本中有一些错误。这些错误使转储看起来很奇怪（例如，它正确启动，几个字节后我只有 0xFF 字节，这就是我问的原因）。

至少只是通过查看图片，它在我看来不像 .zip、.xz、.gzip。如果我没记错的话，这三个的标题格式看起来不同（假设您的图片显示了文件的开头）。但我不是 100% 确定这一点，我可能是错的。