Reverse-engineering philips picture frame file format

Reverse engineering philips 7FF1AW picture frame file format

As no "play list" seems to be stored in the frame, the information of the pictures beeing in the diaporama or not must be in the pictures themselves.

I copied a legit files, when it was added to the diaporama, and copied it again when not in the diaporama. Some xxd and diff later, it appears the magic is in the file header.

"In diaporama" bit

These are the first bytes of the file, when it is in the diaporama:

    0000000: ffd8 fffe 0012 4150 0001 0000 0000 0000  ......AP........
    0000010: 0000 0000 ffd8 ffe0 0010 4a46 4946 0001  ..........JFIF..

...and when not in the diaporama:

    0000000: ffd8 fffe 0012 4150 0000 0000 0000 0000  ......AP........
    0000010: 0000 0000 ffd8 ffe0 0010 4a46 4946 0001  ..........JFIF..

Clearly, the "in diaporama" information is hidden there:

    0000000: ffd8 fffe 0012 4150 0001 0000 0000 0000  ......AP........
    0000010: 0000 0000 ffd8 ffe0 0010 4a46 4946 0001  ..........JFIF..

Frame specific header

This is the header of a "normal" jpeg file (the first JFIF bytes are in green):

    0000000: ffd8 ffe0 0010 4a46 4946 0001 0100 0001  ......JFIF......
    0000010: 0001 0000 ffe1 069e 4578 6966 0000 4949  ........Exif..II

When we compare it to a dpd_XXX.jpg from the frame, we remark a small header has been added (in yellow):

    0000000: ffd8 fffe 0012 4150 0001 0000 0000 0000  ......AP........
    0000010: 0000 0000 ffd8 ffe0 0010 4a46 4946 0001  ..........JFIF..

Putting it all together

If we take a "normal" jpeg, and prepend it to the 20 bytes frame specific header (the one with the "in diaporama" bit set), the file is indeed taken by the frame as beeing part of the diaporama. Bingo!

Here are the 20 bytes of interest, as a binary file.