Reverse Engineering led.dat file communicating with STC Micro Controller

[elliottveares]

I have a Chauvet LED Motion Drape what basically is 2x3 meter DMX controlled LED star cloth.  The unit has a number of programs built into it what are stored on a 128MB SD card inside the controller.

The 128MB SD card just contains a single 1.75MB led.dat file on it. Trying to decode/reverse engineer it so can learn how it works and make my own programs.

The unit just has two IC's, the main micro controller (STC 12C5A60S2) on the main board with the SD card, and another one on lcd/front panel board what has no markings. Pictures and led.dat file below.





http://www.grottotree.com/photos/Chauvet-Motion-Drape/led.dat


One if welcome to try and decode/reverse engineer the led.dat file themselves if they wish, however what should one look for when trying to decode/decompile such a file . I get noting useful with a hex decoder and opening it up in Notepad++ just gives me nonsense.

Regards: Elliott.

[luiHS]

 
Forget about trying to apply reverse engineering to that file, it is not a program file, but a data file.

The program is stored in the internal flash of the microcontroller, and unless you get a dump of that program, you can not find out what the structure of the data file is to add new data groups to create new effects or modify the current ones.

[amyk]

Forget about trying to apply reverse engineering to that file, it is not a program file, but a data file.

The program is stored in the internal flash of the microcontroller, and unless you get a dump of that program, you can not find out what the structure of the data file is to add new data groups to create new effects or modify the current ones.

No, this is even easier...

Opening the file in a hex editor reveals lots of repetitive patterns, so it is likely raw bitmap data. The first 512 bytes are certainly a file header of some sort. Every 512 bytes there is what looks like a header, and the 3rd byte of that increments. That could be a frame counter, and each frame is 512 bytes.

The repetitive pattern seems to be clustered in groups of 2, i.e. 2 bytes per pixel, and starts at 8 bytes into each frame. The last 12 bytes of each frame appear to always be 0, i.e unused. That leaves 492 bytes of pixel data in each frame, or 246 pixels.

A quick visit to the product manufacturer's page shows that it has a 16 x 11 RGB LED array, or 176 pixels in total. That doesn't fit quite right with the 492 bytes of data, but I don't have the product so I can't investigate any more. I opened the file in an image editor using 512 x 3590 8bpp + 512 byte header and got something vaguely recognisable... the rest is up to you. Modify some bytes and test. Note that each line in the attached image is 512 bytes, so would be one whole frame of data.

[archwisp]

Elliot,

You are awesome for sharing this info! Your finding of the SD card with the file on it nudged me along. And I was also able to get the chip label that was rubbed off of mine from your photos!

amyk,

You did some excellent initial analysis without having seen one of these devices! You were spot-on with the 512 byte frame size and the 2 bytes per pixel. The number of pixels v.s. the number of bytes is explained by two things: 1) This device was created with 2 configurations, one of which comes with an additional facade that has more LEDs on it. The horizontal break you see in the data from your bitmap marks the beginning of the data for the facade. 2) There are a few null byes at the end of each segment.

Anyway, I was able to crack this and I wrote up most of the info here: https://twitter.com/archwisp/status/1099406624077332481

I'll be releasing the script I wrote to help convert text-based dot art to this thing soon! Have fun!

Archwisp