0

Context: I'm currently re-engineering an old (2015) E-paper display tag just for the fun of it. For the curious ones, I'm using Ghidra to disassemble and decompile, and trying to make up some sense of the results. The tag uses an ARM Cortex M0 based MCU and a 1.44 inch EPD, and receives its display content via NFC.

After receiving some (RLE compressed) KB of data and inflating that data, the application interprets the data. This is my current knowledge about the contents:

  • There is potentially a header of 16 bytes ignored by the application.

  • After the header there is an undetermined number of elements. The application stops at the end of the received data.

  • Each element is marked with a single byte (byte 0 in the table), followed by a length byte (byte 1 in the table, counted without these first two bytes)

  • After these two bytes more bytes can follow, depending on the element's type:

    My finding so far byte 0
    (element
    type)
    byte 1
    (# of bytes
    to follow)
    byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 ...
    set geometry 0x01 3 x offset y offset rotation
    (0..3 = 0°/ 90°/ 180°/ 270°)
    - - -
    define colors 0x02 2 color1 color2 - - - -
    fill completely
    with background color
    0x03 0 - - - - - -
    invert image 0x04 0 - - - - - -
    draw line 0x11 4 x1 y1 x2 y2 - -
    draw text 0x12 # x y font opaque centered text...
    draw pixels 0x13 # x y w h bits per pixel data...
    draw rectangle 0x14 5 x1 y1 x2 y2 filled -
    draw circle 0x15 4 x y radius filled - -
    stamp image 0x17 3 x y index - - -
    prepare pixel data 0x20 # data... - - - -

Element type 0x20 is special. Each data chunk is appended to a buffer. When finally element type 0x13 is used, its data are also appended, and then the whole buffer is the image to draw.

I spent several hours in web research but could not find any hint. The "usual suspects" like CGM, EMF, EPS, SVG, WMF or Gerber do not match. I looked into few others, too.

What (file) format of a (simple) vector graphic is this?

The application is a mix of apparently assembler, C, and C++ code. Specifically all drawing functions receive the same pointer, which is certainly this. There is also a function pointer table in the structure pointed to, known as vtable. This makes me conclude that libraries are used.

Currently I'm at a bit-block transfer function that supports 16 colours. It can be that this is a proprietary format, but it makes no sense to support more than the two colours of EPDs of that time. That's why I think it is some more generic format.

9
  • 1
    could be custom file format
    – jsotola
    Commented Oct 3 at 5:12
  • (These are only assumptions). Since the device has a simple display and that basic shapes are specified by a single byte of the protocol I would try to find a correlation between packet bits and the actual visual result. This may be as simple as 1/0 to paint/clear pixel. Expect a checksum of the packet and/or parity bits inbetween.
    – Yotamz
    Commented Oct 3 at 7:37
  • @jsotola Thanks for your hint, it's true, however, even though I'm in CS for decades and always learning, I cannot know all file formats. :-D If it is a known file format, it would make my reengineering a lot simpler. Currently I need to interpret each element type's function in detail. Commented Oct 3 at 8:08
  • @Yotamz Thanks for your suggestions, I will surely verify my findings with experiments. Currently the device is still in its code-readout fixture and I still need to find a way to communicate with NFC. Commented Oct 3 at 8:15
  • 1
    True. I meant to say that it may be a common format for this type of embedded device - but not necessarily a well known graphics file format that is seen in PCs (for reducing overhead, memory use etc.). It makes identifying them harder, for lack of headers/magic values and so on
    – Yotamz
    Commented Oct 11 at 12:18

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.