BU40N MT1959 firmware format: packed region at 0x158000 (compression method known?)
Posted: Mon Jun 22, 2026 12:40 pm
I'm comparing BU40N 1.00 and 1.03 firmware internals while investigating OmniDrive behaviour and noticed a large packed-looking region that differs almost completely between firmware versions despite having a very similar header structure.
Firmware images examined:
The 1.00 image is the original LG firmware. The 1.03_MK image is the MakeMKV/LibreDrive patched firmware based on LG 1.03.
Looking at the raw firmware images, there appears to be a module beginning at offset 0x158000.
BU40N 1.00
BU40N 1.03_MK
The start of the region looks like:
and the corresponding structure in 1.03_MK is almost identical.
After the first 8 bytes there is approximately 0x140 bytes of highly structured low-valued data, followed by a high-entropy stream that differs almost completely between firmware versions.
The interesting part is that the 0x140-byte structure does not appear random. Treating it as code-length data produced the following result:
First 288 entries → Kraft sum = 1.0
Last 32 entries → Kraft sum = 1.0
Entire 320-byte table → Kraft sum = 2.0
This suggests the region contains two complete prefix-code (Huffman-like) tables, arranged as:
The table structure is nearly identical between 1.00 and 1.03_MK, while the compressed stream contents are almost entirely different.
I extracted the stream and tested the obvious formats:
All failed.
I also looked at MediaTek's documented ALICE firmware compression (used in some MTK products). While there are some conceptual similarities (table-driven compressed instruction streams), this BU40N format does not appear to be a standard ALICE container.
Questions:
Firmware images examined:
Code: Select all
BU40N_1.00_stock.bin
MD5: edb28fcd7a239281ace26a468d382a9c
BU40N_1.03_MK.bin
MD5: 74ebaf627d2aac5f899191d6caceb54cLooking at the raw firmware images, there appears to be a module beginning at offset 0x158000.
BU40N 1.00
Code: Select all
offset: 0x158000
field 1: 0x00072464 (468,068)
field 2: 0x0004E98F (321,935)
region end: 0x1A698FCode: Select all
offset: 0x158000
field 1: 0x00071C60 (466,016)
field 2: 0x0004E3B1 (320,433)
region end: 0x1A63B1Code: Select all
0x158000:
00072464
0004E98F
07060605
07070706
08070706
08080808
...After the first 8 bytes there is approximately 0x140 bytes of highly structured low-valued data, followed by a high-entropy stream that differs almost completely between firmware versions.
The interesting part is that the 0x140-byte structure does not appear random. Treating it as code-length data produced the following result:
First 288 entries → Kraft sum = 1.0
Last 32 entries → Kraft sum = 1.0
Entire 320-byte table → Kraft sum = 2.0
This suggests the region contains two complete prefix-code (Huffman-like) tables, arranged as:
Code: Select all
0x158000 size field
0x158004 size field
0x158008 288-byte code-length table
0x158128 32-byte code-length table
0x158148 compressed bitstreamI extracted the stream and tested the obvious formats:
Code: Select all
zlib
raw deflate
gzip
bzip2
lzma/xzI also looked at MediaTek's documented ALICE firmware compression (used in some MTK products). While there are some conceptual similarities (table-driven compressed instruction streams), this BU40N format does not appear to be a standard ALICE container.
Questions:
- Has anyone identified the compression/packing method used for this MT1959 firmware block?
- Does the decompressor reside inside the firmware itself, or in MT1959 boot ROM / mask ROM?
- Does this region contain executable ARM code, servo/DSP microcode, or some other firmware component?
- Has this area ever been reverse engineered by the LibreDrive / MakeMKV developers or anyone working on MTK optical drive firmware?