EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: Matty on December 30, 2023, 07:01:14 pm

Title: What decompression/zip type is this
Post by: Matty on December 30, 2023, 07:01:14 pm
I have dumped the firmware from a cheap scope Kiprim (a reworked Owon?) and I found a compressed part of the main firmware in it.
I've emulated (ARM9-EL) the decompression routine and got the decompressed kernel?.  But I was wondering if anyone know what it is.
I would like to adjust the firmware, but I can not recompress the kernel back again.

The first 4 bytes are the length.  It appears to have "OWON" in the header.  And the data starts @ 0x1C
I have a feeling that this is not a proprietary method, they must have copied something.
7zip didn't save me.
Title: Re: What decompression/zip type is this
Post by: brucehoult on December 30, 2023, 09:50:20 pm
The code of the decompression routine would be a much better clue!!!
Title: Re: What decompression/zip type is this
Post by: Matty on December 30, 2023, 11:28:25 pm
Oh yeah, that does help.
Title: Re: What decompression/zip type is this [closed]
Post by: Matty on January 14, 2024, 06:08:23 pm
I see that it uses the LZ77 method/algorithm, but I could not find which implementation it uses.
So I made a crude re-compressor (in VB6).  It is just good-enough to make the file fit in the allocated space.

I think the info might be useful to someone in the future.

tag search: OLWIOLNLCINP1U2T
Title: Re: What decompression/zip type is this
Post by: m k on January 15, 2024, 06:55:07 am
Uncompressed is 0x48 longer than [0x18], first 0x48 is very rational code.

How uncompressed ends?
Title: Re: What decompression/zip type is this
Post by: Matty on January 15, 2024, 06:18:13 pm
oh yes,
when I copied the decompressed file from emulated RAM. I also copied the last 0x48 bytes as well, because that is what it created.
* Now looking back... it appears that I decompressed 8 bytes too many, oooops - might have been a typo? *

I remember a different decompressor which output'ed a bit more data than expected.  But luckily it does not matter because it will be ignored.
Also the decompressed size [0x18] is totally ignored anyway.  So I just left the original value in there.

It finishes the decompression routine based on the value at [0x0] - the header size + compressed size.