I'm trying to analyze the firmware of a system running Linux and connecting various home automation and security devices. Every time it boots, the GM8125 processor running ARMv5TE loads a firmware image from the SPI flash. I connected to the flash with a Bus Pirate and pulled off the firmware image. When I run binwalk on it, I get the following.
$ binwalk spidump.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
271284 0x423B4 Sega MegaDrive/Genesis raw ROM dump, Name: "ETIR_ON", "ECCAS",
744708 0xB5D04 CRC32 polynomial table, big endian
786432 0xC0000 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-04 16:05:57 (bogus date)
917760 0xE0100 Linux kernel ARM boot executable zImage (big-endian)
9306332 0x8E00DC Zlib compressed data, compressed
9307424 0x8E0520 Zlib compressed data, compressed
9308196 0x8E0824 Zlib compressed data, compressed
9309036 0x8E0B6C Zlib compressed data, compressed
9310040 0x8E0F58 Zlib compressed data, compressed
9310220 0x8E100C Zlib compressed data, compressed
9311200 0x8E13E0 Zlib compressed data, compressed
9312104 0x8E1768 JFFS2 filesystem, little endian
9317132 0x8E2B0C Zlib compressed data, compressed
9317428 0x8E2C34 JFFS2 filesystem, little endian
9318332 0x8E2FBC Zlib compressed data, compressed
[...]
If I run binwalk -Mre it gives me nearly 6000 files and several hundred folders of the extracted Zlib and JFFS2 data. After analyzing these, I thought I'd look at the boot image.
I carved out the zImage by running dd if=spidump.bin of=carved.bin bs=1 skip=917760 count=8388572. Running file returns carved.bin: Linux kernel ARM boot executable zImage (big-endian).
So far so good. This is where I get lost.
From reading other posts here and elsewhere, it seems like I should search for the magic bytes of where compression starts--since this is big-endian, I run objdump with a lot of results (only the first few lines listed).
$ arm-none-eabi-objdump -EB -D -m armv5te -b binary carved.bin | grep 1f8b
9b38: 1f8b3c36 svcne 0x008b3c36
1f8b0: bf2e3abe svclt 0x002e3abe
1f8b4: 0811cabb ldmdaeq r1, {r0, r1, r3, r4, r5, r7, r9, fp, lr, pc}
1f8b8: baaee7f4 blt 0xfebd9890
1f8bc: fc3711aa ldc2 1, cr1, [r7], #-680 ; 0xfffffd58
20c38: f3b1f8b9 ; <UNDEFINED> instruction: 0xf3b1f8b9
233c0: d1f8badf ldrsble fp, [r8, #175]! ; 0xaf
2c7d8: 011f8b05 tsteq pc, r5, lsl #22
2d990: e9ff1f8b ldmib pc!, {r0, r1, r3, r7, r8, r9, sl, fp, ip}^ ; <UNPREDICTABLE>
I carve the file starting from the first occurrence of the magic bytes by running dd if=carved.bin of=arm.gz bs=1 skip=39736. file returns arm.gz: gzip compressed data, unknown method, has CRC, extra field, has comment, encrypted, last modified: Mon Sep 15 08:57:49 1975 and gunzip refuses to unzip, saying unknown method 60 -- not supported. Most later occurrences of 1f8b are not aligned at the beginning of a byte, so I assume they are not good candidates for carving and unzipping. It seems like the first occurrence, and subsequent occurrences, might just all be by chance.
Is this truly a zImage, or could binwalk and file be confused? How can I tell? How do I extract it?
Unfortunately, I can't provide the binary for your own perusal.
Update - 6/25/2019
I've included a graph of the entropy of the file, as requested by julian. It does look like the section in question is compressed.
Update - 7/5/2019
Upon further review with an expert, it seems like binwalk misidentified the type(s) of files. It looks like there is a custom unpacker I need to either disassemble or have it run and then take the unpacked image from memory.
