Extracting ARM Boot zImage

Question

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.