Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Reverse engineering index.dat (Read 670 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Reverse engineering index.dat

So I'm sure I'm not the only one that wants my playlists to update elsewhere with foobar being the point of truth for them.  To that ends I've been working with a friend (he'll probably show up) to reverse engineer the index.dat file so i can figure out what my playlist file name is.

This is necessary because the playlist filename will change, we think based on a hash of the file or track list.  We think this because adding a track changes it, removing it will change it back.

So here's what we have so far.

The first 24 bytes are header info:

Code: [Select]
    Header
        MagicSignature  35 47 5E 2A 60 1B 4B 4B 82 57 5C 8E 61 26 FD F6
        PlaylistCount   06 00 00 00
        LVEnabled       01 00 00 00         # LV is Library Viewer


Then here is an example of a standard playlist:

Code: [Select]
        Name Length     0C 00 00 00 
        Name            43 6C 61 73 73 69 63 20 52 6F 63 6B
        SelectedTrack   DE 01 00 00
        MetadataLength  6D 00 00 00
                        04 00 00 00 # start of metadata
                        32 51 65 52 # playtime?
                        57 8F 56 4C 9A EE 17 52 5C 67 9A 5D
                        10 00 00 00
                        EB 4B 6B 7E E0 C6 61 40 BE 7F 2D 84 29 5F DE 8A
                        43 61 37 F4 79 4D E7 47 90 2E 10 A6 7B B5 57 0F
                        04 00 00 00
                        84 23 00 00
                        72 03 AA E3 5E 85 22 44 9A 5A 60 0B 13 38 5B B1
                        04 00 00 00
                        00 00 00 00
                        EE BC 6F 0C EC 8E 87 4F 8F E4 25 C2 3D 90 21 36
                        01 00 00 00
                        01 # end of metadata
        FileCount       01 00 00 00
        Filename        AA 59 31 90 6D DE 84 31 51 3D CB 1B 8E 40 22 21

And an example of a dynamic playlist
Code: [Select]
        Name Length     0F 00 00 00 
        Name            4C 61 73 74 20 46 6F 75 72 20 57 65 65 6B 73
        Current Track   00 00 00 00
        MetadataLength  A9 00 00 00
                        04 00 00 00 # start of metadata
                        32 51 65 52 57 8F 56 4C 9A EE 17 52 5C 67 9A 5D
                        10 00 00 00
                        AC EB 9F 75 13 8F D5 4E 92 DA EF C6 61 AF D8 D4
                        43 61 37 F4 79 4D E7 47 90 2E 10 A6 7B B5 57 0F
                        04 00 00 00
                        00 00 00 00
                        55 65 F1 82 CB 7A 8C 43 9C 4B 55 E1 D8 4D 15 64
                        3D 00 00 00
        ForcedSort      00 00 00 00
                        F4 53 B6 51 D7 A2 10 48 99 BD 06 72 47 12 17 5A
        QueryLength    21 00 00 00
        Query           25 6C 61 73 74 5F 70 6C 61 79 65 64 25 20 44 55 52 49 4E 47 20 4C 41 53 54 20 34 20 57 45 45 4B 53
                        00 00 00 00
                        72 03 AA E3 5E 85 22 44 9A 5A 60 0B 13 38 5B B1
                        04 00 00 00
                        00 00 00 00 # end of metadata
        FileCount       01 00 00 00
        FileName        62 A6 D9 1E 38 89 97 04 0A 0E D8 73 0C AF B6 E7

If all you care about is getting the filename from a playlist name, I have a script to do that here:
https://github.com/topherhead/FoobarIndexParser
Please don't judge my trash code  :))  :))  :))

But in the interest of completeness, I would like to try and get all the properties figured out.  There are several 16byte strings that are consistent between all playlists.  Even across computers.  Sorry there is probably some slop in the byte labels etc.  editing in a browser not super fun.

So anyone know what the other fields are in metadata?

Re: Reverse engineering index.dat

Reply #1
All objects are preceded by an identifier indicating what object it is. This identifier is always a GUID, which is 16 bytes.

Re: Reverse engineering index.dat

Reply #2
Do we know a mapping of which guid goes to which object type?

Re: Reverse engineering index.dat

Reply #3
I do not.

 

Re: Reverse engineering index.dat

Reply #4
Next major update (after 1.6.x) goes full plaintext+sqlite for this.
Whatever work you do on reverse engineering current binary formats will be obsolete then.
We are the bork. Your software bugs will be added to our own. Resistance is futile.

Re: Reverse engineering index.dat

Reply #5
Next major update (after 1.6.x) goes full plaintext+sqlite for this.

Wow, that's exciting news! Will SQLite include only tags (manually edited metadata) or more/all metadata (codec, bitrate, replaygain et al.)?

Re: Reverse engineering index.dat

Reply #6
Next major update (after 1.6.x) goes full plaintext+sqlite for this.
Whatever work you do on reverse engineering current binary formats will be obsolete then.

lol!  welp, /thread I guess.  I'll just do it all over again when the update releases then.  But it will hopefully be much MUCH easier then.

 
SimplePortal 1.0.0 RC1 © 2008-2021