Created 04/12/2019 at 06:00PM

Setting the brightness

The 3DxWare control panel has a slider that allows the user to change the LCD brightness. Moving it to different values and then examining the Wireshark USB capture data showed that it was sending a USB control transfer containing a single 16-bit word with the format:

0x11 0x<brightness>

The brightness byte contained a value from 0 - 100, however the screen backlight only seems to have a few discrete brightness values available, regardless of the value of the second byte.

Examining the bitmap data

Looking at the captured bulk data stream, it seemed to show some sort of pattern. The data started with about 48 bytes of something, then the word 0x8e73 repeated to pad the data out to 512 bytes, and then the rest of the data. The header always seemed to start with either the word 0x110f or 0x180f.

I couldn't see any pattern to the data that was being sent after the header; It just looked random. I had heard of a program called Binwalk, which was used to try and identify different types of data inside of firmware files, so I thought I would give it a try.

Binwalk has an option to scan for compressed data. When I ran the LZMA option, it found nothing, but the deflate option found a large number of possible compressed areas. There were too many, packed too close together, for them to all be correct, but it always seemed to find something just after the 512-byte position.

I searched for ways to try and decompress deflated data. Gzip can do it, but since it expects a specific header I found a method that adds the header using shell printf:

{ printf "\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x00"; dd skip=512 if=<file> bs=1 status=none count=<size>; } | gzip -d

This managed to decompress some form of data which had enough regularity to suggest that it was bitmap data. I had a look at the specification for a .BMP file, and then created a bitmap header to which I attached the decompressed data.

After a few tries with different resolutions and formats, I managed to get something recognisable by using settings for R5G6B5 with a resolution of 640 x 150, albeit that the image was upside down and the colours were wrong.

Something is not right

Still, progress.

RGB?

I had a hunch that the colour issue may be due to the screen expecting data as BGR instead of RGB, since the green element in the decoded images seemed about right, and I know that some of the small LCD displays that are commonly used with microcontrollers sometimes use BGR format.

I wrote a small c snippet to read the raw bitmap data and convert it. Since the decompressed data is little-endian and the bitmap needs to be big-endian, I converted it in the same program.

This proved successful, and the image captured from the USB can now be decompressed and displayed correctly.

Now to try and reverse the process.

Part 3...

SpaceLCD repository