www.makemkv.com

Small update.

Thanks again to RibShark — the RAM dump and the relocation pseudocode were the missing pieces.

The decompression side now looks much more solid. The packed block at 0x158000 appears to decode as:

firmware packed block
-> canonical Huffman + LZ-style decode
-> raw pre-fixup ...

Thanks again — I spent more time comparing the stock 1.00 firmware decode against the RAM dump, and there is a much better update now.

The short version is that the decompression side now looks effectively solved for the bytes covered by the RAM dump. The remaining raw differences are not random ...

Thanks, that RAM dump was exactly what was needed.

I agree with your correction: my original decoder had the two header fields interpreted the wrong way round, and it also had at least two semantic mistakes in the LZ/Huffman layer.

The original interpretation I was using was:

field0 = compressed ...

Small update / WIP.

I made some progress on the 0x158000 packed block in BU40N 1.00.

The original table split still looks correct:

0x158008 288-byte literal/length code-length table
0x158128 32-byte distance code-length table
0x158148 compressed bitstream

I now have an experimental Python ...

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:
BU40N_1.00_stock.bin
MD5 ...