Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Towards SMAZ decompression #1

Open
abridgewater opened this issue Aug 29, 2019 · 44 comments

Comments

@abridgewater
Copy link

commented Aug 29, 2019

After four days of attempting to figure out this compression scheme without reference to actual hardware, this is what I have:

The compressed data stream consists of control bytes and data bytes, interleaved, with the first byte being a control byte. Interpreting each control byte consumes some number of data bytes, after which the next byte will be another control byte.

The decompressor can be modeled as a state machine with two states, currently the "default" state and the "alternate" state, starting in the default state (hence the names).

Control bytes are divided into four "dibits" (two-bit units) from most significant to least significant, and the interpretation of these dibits is state-dependent. To be explicit about the "dibit" mapping, the byte 0x1b would be dibits "00", "01", "10", and "11", in order.

In the default state, the dibits appear to have the following meaning:

  • 11: Copy two data bytes from the compressed data stream to the output.
  • 10: Copy one data byte from the compressed data stream to the output and transition to the alternate state.
  • 01: Transition to the alternate state.
  • 00: Extended operation (see below).

In the alternate state, the dibits appear to have the following meaning:

  • 11: Interpret a backreference byte from the compressed data stream (see below).
  • 10: Interpret a backreference byte from the compressed data stream (see below) and transition to the default state.
  • 01: Copy one data byte from the compressed data stream to the output and transition to the default state.
  • 00: Extended operation (see below).

Backreference bytes have two (or three?) interpretations. If the low bit is 0, the high seven bits indicate an earlier position in the output stream from which to copy two bytes (specifically, shift the backreference byte right by one bit, add one, and subtract this value from the current position). If the low bit is 1, the same applies, but copy three bytes. There may be a special semantic if both the low and high bits are 1, or there may not.

Extended operations are signaled by a 00 dibit in the control stream and consume a second dibit to select an operation to perform (technically, this means that the state machine has three or four states, especially since the extended operations occasionally seem to be split across a control-byte boundary).

The extended operations are currently believed to be:

  • 00 11: Extend the length of the next backreference by two bytes.
  • 00 10: Read a data byte, shift left three bits, copy that many bytes from the end of the last backref to the output.
  • 00 01: Unknown
  • 00 00: Unknown, possibly consumes a byte from the compressed data stream and another dibit.

Overall, the two-state-and-dibit model seems to be fairly solid, while the specific extended operations are considerably sketchier.

@jhol

This comment has been minimized.

Copy link
Owner

commented Aug 30, 2019

Hi - I'm very impressed with the puzzling you've done here. I've spent quite a lot of time working on this, but I've been quite busy lately so it's been hard to concentrate, and I ended up banging my head on a brick wall.

It's going to take me a few days to release the next part of the video, but I'll mention what I discovered... when the system boots, it uses a built-in boot-ROM to load firmware from the flash memory. The ROM passes the firmware through a hardware unit called the DPU, that decompresses the SMAZ data and computes the checksum.

I was able to write some software that is able to load SMAZ data into RAM, and trigger the DPU and print the results. I used this method to fuzz the DPU with a python script. This is quite slow, because I couldn't figure out how to reset the DPU without a hardware reset, so I have to hard-reset the system every test, so every test takes about 20-seconds. The script logs the results in msgpack format which is easy to load in python.

From the test data, I started building a [python smaz decoder](https://github.com/jhol/otl-lkv373a-tools/blob/master/smedia/smaz.py. Have you seen this?

To help me do this, I have a script test-decode.py, that can read the msgpack logs, and can compare them to the behaviour of the DPU.

20190830-test-decode

If the DPU has any error decoding the SMAZ, it will abort but the data it copies back to RAM may not include the last few bytes before the error. Therefore, in my testing, I added some sync chunks like this: FF 00 11 02 03 .... at the end of the input data. So, test-decode.py checks that the sync chunks are present to decide if the DPU decoded the test successfully.

By this method, I was able to make a corpus of >14000 tests. Of these 1457 were decoded successfully by the DPU, and my script is currently able to decode 800. But as you may have seen, my decoder is a complete mess - I keep finding more and more unexpected behavior, and there are several patterns of behaviour that I don't understand correctly.

Here is my collection of test results:
https://opentechlab.org.uk/_media/videos:019:20190830-corpus.tar.bz2

Would you be interested in hacking on the SMAZ decoder?

I am happy to answer any questions. Also, if it would help, I can give you remote access to my rig so that you can run your own tests.

Thanks for looking at this. I was hoping someone would help me figure it out.

Joel

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Aug 30, 2019

Hi folks,

In the past I tried to break the compression scheme of the SMAZ structure. Unfortunately without much progress, comparing to you. However my approach was quite different as I had no access to the hardware decompressor for fuzzing it. Instead I found in compressed buffer a place, where compression worked worst because of a lot of non-repeating input and the data was plain text, so I could easily identify which byte is data, which control stream. That way I was able to decompress few hundred bytes and guess simplest control commands. If someone is interested in the results, I can share my notes (most of them are on paper).

I was doing this kind of black box approach before, on another unrelated compression scheme (also LZSS variation, like here) and I think it is possible to finish it that way. Especially useful might be getting completely decompressed SMAZ structures that are contained in firmware updates, which is now possible thanks to jhol's work. This would allow to confirm the guesswork required to make progress.

By the way, you guys, both, did a really great job!

Regards,
Kamil

@abridgewater

This comment has been minimized.

Copy link
Author

commented Aug 31, 2019

Hi - I'm very impressed with the puzzling you've done here. I've spent quite a lot of time working on this, but I've been quite busy lately so it's been hard to concentrate, and I ended up banging my head on a brick wall.

Well, let's try to spare your head (and the wall) further damage from this compression scheme.

From the test data, I started building a [python smaz decoder](https://github.com/jhol/otl-lkv373a-tools/blob/master/smedia/smaz.py. Have you seen this?

I have seen it, and it's what pointed me to the backref offset being the high seven bits, which might have taken me a bit longer to figure out otherwise. At the same time, you were/are clearly struggling to produce something without having a coherent model of the overall compression scheme. An essentially-stateless approach to an inherently-stateful control scheme.

Looking at it again now, it seems that you have implemented some things that I haven't worked out how to trigger yet, so I'll need to give it a closer reading now that I know more of what I'm looking at.

By this method, I was able to make a corpus of >14000 tests. Of these 1457 were decoded successfully by the DPU, and my script is currently able to decode 800. But as you may have seen, my decoder is a complete mess - I keep finding more and more unexpected behavior, and there are several patterns of behaviour that I don't understand correctly.

Unfortunately, brute force and ignorance doesn't always work, and not having the time to sit down and work out the details doesn't help.

Here is my collection of test results:
https://opentechlab.org.uk/_media/videos:019:20190830-corpus.tar.bz2

Thank you, that gives me a much easier angle than the multi-file differential analysis that I had been considering for the two mostly-ASCII regions that I had found.

From about a day of looking at the corpus data, it appears that the decoder has at least three states, and there's both a backreference offset storage register and a copy length shift register. Looks like you found one of them and brute-forced the other?

Would you be interested in hacking on the SMAZ decoder?

I'm more likely to attempt to write my own decoder, but we'll see how things go.

I am happy to answer any questions. Also, if it would help, I can give you remote access to my rig so that you can run your own tests.

Let's hold off on remote access for the moment. I have enough material to keep me busy for a while.

Thanks for looking at this. I was hoping someone would help me figure it out.

You're welcome. It's been an interesting challenge so far.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 1, 2019

Someone managed to find the SDK:
http://219.87.84.106/log/~bsp2%2Fbr06p.git/br06p

It contains a tool mkrom:
http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Ftool%2Fbin%2Flinux%2Fmkrom

and mkrom.exe:
http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Ftool%2Fbin%2Fmkrom.exe

There are two kinds of compression supported Jedi (old style - what we have been decoding), P9850.

I think this code describes the decompression algorithm:
http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Fsdk%2Fdriver%2Fxcpu_master%2Fdecompress.c#L49

/* Thinned out version of the UCL 2e decompression sourcecode
--
* Original (C) Markus F.X.J Oberhumer under GNU GPL license */
@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 1, 2019

@v3l0c1r4pt0r the CPU core is OpenRISC

@danielkucera

This comment has been minimized.

Copy link

commented Sep 1, 2019

Man, this is some breakthrough!

@abridgewater

This comment has been minimized.

Copy link
Author

commented Sep 1, 2019

Someone managed to find the SDK:
http://219.87.84.106/log/~bsp2%2Fbr06p.git/br06p

Good find!

There are two kinds of compression supported Jedi (old style - what we have been decoding), P9850.

I think this code describes the decompression algorithm:
http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Fsdk%2Fdriver%2Fxcpu_master%2Fdecompress.c#L49

/* Thinned out version of the UCL 2e decompression sourcecode
--
* Original (C) Markus F.X.J Oberhumer under GNU GPL license */

Seems very likely. And that leads to http://www.oberhumer.com/opensource/ucl/ which contains another version. I was already suspecting that there was a drastic simplification to be had with my current model, but I wasn't expecting this. It's bits, until it's suddenly possiblly-unaligned dibits, until it's suddenly "let's read a byte and use that". I'm not finding documentation on the actual compression, though, just source code.

@goosenphil

This comment has been minimized.

Copy link

commented Sep 1, 2019

@jhol Wow, what a find! Sounds like you're going to make another video on this one?

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 1, 2019

/* Thinned out version of the UCL 2e decompression sourcecode
--
* Original (C) Markus F.X.J Oberhumer under GNU GPL license */

Wait, what? I have seen that library in the past. It seems that I was a lot closer to figuring this out than I thought. I can't believe it was that simple. Never mind.

Now this sounds like a lot of new information. I have to start updating my wiki...

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 1, 2019

I attempted at decompressing with original UCL library and for now it is moderate success. I am definitely getting some data that is not garbage, but no SMAZ was decompressed completely:
Screenshot
SDK variant of the decompressor has a hack done in line 248 and I bet this is why I am not getting complete buffer. I didn't look into that yet, though. I created a gist if someone is interested in playing with original UCL. Here is a link: https://gist.github.com/v3l0c1r4pt0r/9acdbca0792cc1c8eece039b6246a537

@danielkucera

This comment has been minimized.

Copy link

commented Sep 1, 2019

Ok guys, I have a feeling that it would be feasible to create a fully open firmware with cool features. Won't you consider creating a team, splitting the work and start a crowdfunding?

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 1, 2019

@danielkucera

I started this because I was interested in the possibility of building a cheapo HDMI->RTSP/RTMP server.

I suspect there is quite a bit about the SDK that is highly sketchy - which is typical for chinese SDKs. Therefore, my approach would be to start building a from-scratch OpenRISC FreeRTOS build and get the major chip features working one by one.

I would also like to know more about MU1 vs U2. Are they both the same chip? Why does the LKV board have two ITE processors on it?

This SDK is legally tricky. Since we needed to read the code to do this work, we can no longer make this a clean-room project. It would be dependent on ITE headers. I guess a user might be able to download the SDK separately, but there are still legal issues to consider. Also, there's a lot of open source software mixed with ITE proprietary information. IANAL, so I don't know what is and isn't allowed.

Also, how do folks feel about this platform? It's an interesting device to play with, but is it really interesting as a development platform? The platform is now quite old. I don't think it can fully capture 1080p . I don't think it can do 60FPS, and I'm sure it can't handle 4K. So I would caution against sinking lots of time into something that may soon go obsolete, unless you are 100% convinced it is a worthwhile long-term effort.

@Robinson-George

This comment has been minimized.

Copy link

commented Sep 1, 2019

I doubt that this stupid decompression algorithm is hard-coded in the DPU. It is much more likely that the microcode at 0x70 contains the instructions for the DPU with this decompression algorithm, written to the shared Memory Management Port (MMP), rather than for some video processing algorithm in a Multimedia Pipeline (MMP). If one of the 0xac0 microcode bytes was altered slightly, I bet it would affect how the DPU decompresses the data.

@danielkucera

This comment has been minimized.

Copy link

commented Sep 2, 2019

I attempted at decompressing with original UCL library and for now it is moderate success. I am definitely getting some data that is not garbage, but no SMAZ was decompressed completely:
Screenshot
SDK variant of the decompressor has a hack done in line 248 and I bet this is why I am not getting complete buffer. I didn't look into that yet, though. I created a gist if someone is interested in playing with original UCL. Here is a link: https://gist.github.com/v3l0c1r4pt0r/9acdbca0792cc1c8eece039b6246a537

@v3l0c1r4pt0r , I took the original code (https://gist.github.com/danielkucera/6ed4266d8095795adf3e225b266f3b75) and tried to decompress the same file:

# ./orig < IPTV_TX_PKG_v4_0_0_0_20160427.PKG | wc -c
header read
magic 5a414d53 5a414d53
malloc 390791680
malloc OK
info: I am about to read 150279 bytes
info: done 150279 bytes
info: 0 yet to be read
error: decompression failed with fffffffe
info: done
169320
# ./smaz < IPTV_TX_PKG_v4_0_0_0_20160427.PKG | wc -c
header read
magic 5a414d53 5a414d53
malloc 390791680
malloc OK
info: I am about to read 150279 bytes
info: done 150279 bytes
info: 0 yet to be read
error: decompression failed with ffffff36
info: done
169320
# 

so I guess the difference is only in the bug handler in do_decompress as you suggested.

@danielkucera

This comment has been minimized.

Copy link

commented Sep 2, 2019

(and it's giving the same results)

@patapovich

This comment has been minimized.

Copy link

commented Sep 2, 2019

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

@patapovich Interesting! It seems to have more implementations of both the SMAZ compressor and decompressor: https://github.com/KennyOP2/JEDI_9910_Fengyun/blob/master/sdk/example/decompress/decompresstest/main.c#L700

@danielkucera

This comment has been minimized.

Copy link

commented Sep 2, 2019

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 2, 2019

@v3l0c1r4pt0r the CPU core is OpenRISC

I am almost sure that I've seen openrisc when trying to identify ISA. It does not seem to be the same as this.

In SDK i found reference to different architecture called sm32: http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Fopenrtos%2Ftoolchain.cmake#L35
Unfortunately internet knows nothing about it and Google insist on finding stm32 instead. However there is a line of DSPs made by Texas Instruments that have names starting with that string. Maybe this is the right direction.

By the way this file mentiones also ARM architecture as chances are, blobs guarded by SMAZ are ordinary ARM code.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

@v3l0c1r4pt0r I was referencing this document for or1k: https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.3-rev1.pdf . I got a hint from someone in my Twitter DMs. The similarity of the 0x38 ALU instruction is particularly noticeable.

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 2, 2019

Ok, this is indeed the same architecture as ours. I have just compiled objdump for or1k architecture. Should be possible to disassemble the firmware code that way.
Edit: it works. Configuring to target or1k-none-elf was enough to disassemble

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 2, 2019

Getting back to the topic, I tweaked my code a little bit and seems that I have complete SMAZ decompressed. Strings call seems to confirm that:

$ strings -8 test3.raw
task_main
ir_protocol: %u
payload len: %u
crc check is failed
key: 0x%X
Update 0x340
Mem Addr (0x3a6) %x
Mem Addr (0x340) %x
Mem Addr (0x342) %x
Mem Addr (0x344) %x
Mem Addr (0x346) %x
Mem Addr (0x348) %x
Mem Addr (0x34a) %x
Mem Addr (0x34e) %x
Mem Addr (0xb4) %x
Timer Init
version: %d.%d.%d.%d.%d.%s
20161104 
iic clock %d !
---Disable HDMITx---
---HDMI TX IC is on board---
!"INIT USBEX FAIL"
E:/lenkeng/case_code/ITE_Extender/FINAL_IPTV_ENCODER_SDK/project/avsender/main.c

Yesterday I forgot that SMAZ is split into multiple compressed chunk, so I was getting only the first chunk. Adding a loop seems to solve the problem :) I updated the code on gist. I have to write the code from scratch, though. Now it is a mess.

@ariankordi

This comment has been minimized.

Copy link

commented Sep 2, 2019

Unrelated but OR1K? Linux kernel for IT9919 when? /s

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

@v3l0c1r4pt0r Amazing! - from the SDK, it looks like the checksum is a CRC32 based on the decoded data. It should be possible to determine the polynomial now that you have decompressed data

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 2, 2019

@jhol, I wasn't able to confirm this. Maybe my output is corrupted somehow. The fact that it seems to be fine does not mean it is.

But I tried to check CRC of whole ITEPKG and I was more lucky with that one. The last 4 bytes of ITEPKG are CRC as calculated by ugCalcBufferCrc function. Here is the output of very simple program calling it:

$ dd if=LKV373A-fw/TX\ firmware/TX_V1.3c_20161104_PKG.PKG bs=1 count=1833930 2>/dev/null | ./crc
b92c4239
0
$ hexdump -C LKV373A-fw/TX\ firmware/TX_V1.3c_20161104_PKG.PKG | tail -2
001bfbc0  04 00 00 00 00 00 00 00  00 00 39 42 2c b9        |..........9B,.|
001bfbce

Note little endian order of bytes.

Edit: I have to check what did they do wrong, so normal crc returns different value. The lookup tables are the same, so it should work, but isn't.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

@v3l0c1r4pt0r

The CRC field is located before the SMAZ signature. It goes:

  • CRC
  • Decompressed length
  • SMAZ
  • Unpacked SMAZ chunk length

...SMAZ Compressed chunks

Looking at the SDK, I think it's a CRC32 of the decompressed data. Though I'm not sure about the bit-order, endianness, or polynomial of the CRC.

@FFY00

This comment has been minimized.

Copy link

commented Sep 3, 2019

I was able to get the specification for the IT985x family.

https://drive.google.com/open?id=1FqdPdRaIyqWa7r1fb6J9qPavFpsRdjQd

@FFY00

This comment has been minimized.

Copy link

commented Sep 3, 2019

Either way, I am pretty sure the device is using a IT978 but sadly there isn't any public information or leaked documents with information about it.

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 3, 2019

@FFY00 The description in this document matches more or less what I've seen inside packages. There is indeed ARM core somewhere and one of SMAZ contains some ARM program (at least decompiling it returns reasonable results). The audio core is, I think, on encoder (uncompressed one), which is weird, because the documentation says about three cores on application(?) SoC. Maybe both processors are in fact very similar, but with different programs?

By the way I made a tool to extract ITEPKG image into chunks (or actually finished what I did years ago). For now only ITEPKG itself, no SMEDIA nor SMAZ, but eases things significantly. I see that I started some work on SMEDIA and SMAZ also, but have to review that before pushing to Github. It is here: https://github.com/v3l0c1r4pt0r/ittk/tree/devel Any feedback, help, pull requests appreciated.

@FFY00

This comment has been minimized.

Copy link

commented Sep 3, 2019

The IT97x and IT985x seem very similar but only the IT978 matches the specs (1080p).

http://soc.ite.com.tw/index.php/products/it970-series
https://www.lenkeng.net/Index/detail/id/149

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 3, 2019

Are you sure LKV373A is capable of 1080p? Mine is by default in 720p mode. I know in some firmware there is a switch, but I never tried if it is possible to use it.

@FFY00

This comment has been minimized.

Copy link

commented Sep 3, 2019

I mean the manufacturer website says so. Maybe it's just a trick in the firmware but it is possible.

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 3, 2019

Yeah, I know they say so. Either way, probably I wouldn't buy it. 720p is a bit too low quality these days. I hope they didn't lie about that. We'll see, I am not so far from knowing the interfaces. All I need to know now is what is the base address for this ARM blob and RISC ones. Then it should be possible to learn what communication channels we have inside.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 3, 2019

I learned quite a bit from this diagram in the datasheet:
20190903-bus-layout

There are two kinds of memory mapping. One is by host view, and other is by RISC view.

On the host view, the memory is divided into two parts. One is mapped to the IT9910 internal registers, which is so-called Memory Map IO (MMIO) space while the other is mapped to the external memory.

On the RISC view, all of address space (MMIO, and memory) is mapped by the linear address. On the base address 0xC000_0000, which is mapped to the MMP’s engine, it should access by 16-bits data type in such address space. On the other address space, it should access by 32-bits data type.

  • We now know the RISC processor is or1k OpenRISC
  • The MMP seems to be a grab-bag of functions including the video engine.
  • The host controller allows an external processor direct access to the system memory via SPI or UART. The LKV373A device seems to be using this - MU1 polls some addresses in U2 through the SPI pins on the header. Software updated are transferred over some other channel. It might be possible to operate the IT9919 without having any firmware in OpenRISC core!
@FFY00

This comment has been minimized.

Copy link

commented Sep 3, 2019

Do you have the datasheet? That is not from the document I sent.

@jhol

This comment has been minimized.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 3, 2019

20190903-or1k-disassem

or1k-elf-objdump works nicely! Just have to package the file into an ELF

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 3, 2019

@v3l0c1r4pt0r - I just tried decompressing some SMAZ with your gist. I seem to get plenty of plausable strings, but also lots of errors:

info: I am about to read 1231 bytes                                                                                                                            
info: done 1231 bytes                                                                                                                                          
info: 0 yet to be read                                                                                                                                         
error: decompression failed with ffffff36                                                                                                                      
info: I am about to write 1579 bytes                                                                                                                           
info: flags are 524288                                                                                                                                         
info: next chunk compressed size is 22142                                                                                                                      
info: I am about to read 22142 bytes                                                                                                                           
info: done 22142 bytes                                                                                                                                         
info: 0 yet to be read                                                                                                                                         
error: decompression failed with ffffff36                                                                                                                      
info: I am about to write 24577 bytes                                                                                                                          
info: flags are 524288                                                                                                                                         
info: next chunk compressed size is 215418                                                                                                                     
info: I am about to read 215418 bytes                                                                                                                          
info: done 215418 bytes                                                                                                                                        
info: 0 yet to be read                                                                                                                                         
error: decompression failed with ffffff36                                                                                                                      
info: I am about to write 242592 bytes                                                                                                                         
info: flags are 524288                                                                                                                                         
info: next chunk compressed size is 162727                                                                                                                     
info: I am about to read 162727 bytes                                                                                                                          
info: done 162727 bytes                                                                                                                                        
info: 0 yet to be read                                                                                                                                         
error: decompression failed with ffffff36                                                                                                                      
info: I am about to write 183000 bytes                                                                                                                         
info: flags are 291140                                                                                                                                         
info: next chunk compressed size is 132377                                                                                                                     
info: I am about to read 132377 bytes                                                                                                                          
info: done 132377 bytes                                                                                                                                        
info: 0 yet to be read                                                                                                                                         
error: decompression failed with ffffff36                                                                                                                      
info: I am about to write 149180 bytes                                                                                                                         
info: flags are 0

Is it confirmed that the compression scheme is 100% compatible with the UCL decompressor?

@Robinson-George

This comment has been minimized.

Copy link

commented Sep 4, 2019

What does the error 0xffffff36 mean ?

@v3l0c1r4pt0r

This comment has been minimized.

Copy link

commented Sep 4, 2019

Is it confirmed that the compression scheme is 100% compatible with the UCL decompressor?

Probably not exactly: http://219.87.84.106/blob/~bsp2%2Fbr06p.git/br06p/ITE_Castor3_SDK%2Fsdk%2Fdriver%2Fxcpu_master%2Fdecompress.c#L248

@Robinson-George I have no idea, I looked into nrv2e code and I don't see where it come from

@Robinson-George

This comment has been minimized.

Copy link

commented Sep 4, 2019

@v3l0c1r4pt0r
Is this error code being generated and returned from the decompress() function?
0xffffff36 = -202 so where is the source code that is responsible for it?

@FFY00

This comment has been minimized.

Copy link

commented Sep 4, 2019

I got a bunch of documents. I will be restricting access to this to avoid legal trouble. Please request access with your public github email address or let me know if you are using a different address.

https://drive.google.com/drive/folders/1bPNHuHfjJrBFBX8AJd7UextwMJE6UX-D

@FFY00

This comment has been minimized.

Copy link

commented Sep 4, 2019

I registered #lkv373a on freenode, if anyone wants to join you are welcome.

@jhol

This comment has been minimized.

Copy link
Owner

commented Sep 8, 2019

I just published my own take on an SMAZ decoder based on code borrowed from the SDK: https://github.com/jhol/otl-lkv373a-tools/tree/master/smazdec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.