MKS-TFT are a series of touchscreens used by 3d printers.
The interface icons / pictures can be changed by loading .bin files from an sd-card.
The .bin files contain picture data.
The firmware used by MKS-TFT is partially open source.
Unfortunately, the picture implementation is non-free / proprietary.
In this project I’ll try to reverse engineer the .bin format and implement a simple commandline picture converter.
RegularRoadmap™ :
(1) Reverse engineer the .bin format:
Procure sample .bin files (note: make sure they are open source / free, so that we don’t violate anything)
Analyze the .bin file:
Header
Picture data, raw or compressed? (note: Because MKS-TFT is an embedded system, the pixel data is probably stored in some RAW format.)
If anything fails, abandon ship and pick a new project.
(2) Implement a simple picture converter from some standard picture format:
Depending on the .bin format, pick:
license(s), language
picture format & library (unless I write my own parser/writer)
The rest .bin files are 16224 bytes. If the bin files contained compressed data, they would probably have different filesizes.
Another bit of information from: Bin · Issue #10 · majurca/MKS-TFT28-NEW-PICTURES · GitHub
The display has a resolution of 320x240 (76800 pixels)
The buttons have a resolution of 78x204 (8112 pixels)
There is also a mention of 16-bit color.
Over the next months I’ll refactor and test the code, and write documentation.
I’ll test it in various linux distros, non-glibc void, FreeBSD, HaikuOS, OpenIndiana and RedoxOS.
I also want to try out input fuzzing with AFLplusplus.
Theoretically speaking, the maximum BMP file size is 2^32-1.
The header takes up at least 66 bytes, leaving up to 4294967229 bytes for the picture data.
Accounting for 2 bytes per pixel, we get 2147483614 pixels.
For a square picture the maximum resolution is 46340 x 46340.
Let’s try to generate such a picture:
Gimp:
The dying plug-in may have messed up GIMP’s internal state.
Krita:
Allocated 20GB of ram and crashed during export
The header had bad data caused by two bugs.
After another 1m 45s I had a 4GB bmp picture.
Gnome Image Viewer returns: ‘bogus header data’
Shotwell: ‘Photo source file missing’
¯\_( • - • )_/¯
Krita: ‘The file format cannot be parsed’
GIMP: ‘is not a valid BMP file’
I haven’t found any program that will display it.
Now let’s do the reverse:
./pixmap565 -i max.bmp -o max2.bin
There was a false assert.
2m later, I had a 2nd bin file.
test the BMP format using file max.bmp with the extended info options. It sounds like your header creation is not 100%, be aware of “maximum value lengths” as well as byte order. Triple check your header construction against multiple definition sources, BMP is pretty old now, so it should be well defined across many sources.
Bad news everyone:
Integers can have padding bits.
The padding bits may be used for parity checks.
I’m not even sure if the value bits are contiguous.
sizeof returns the entire size (including value and padding bits)
I created a 100x100 bmp image.
The x/y resolution is stored using signed values.
With a hex editor we can change the positive resolution:
64 00 00 00 (= 100)
to a negative one:
9c ff ff ff ff (= -100)
(assuming that the signed representation system is 1’s complement)
If we do this on the vertical resolution, we will get a working bmp image.
If we do this on the horizontal resolution:
