walkgirl/FILE_FORMAT.txt

   1 File Formats used by MP3 File Manager v2 & upward
   2
   3 Introduction
   4
   5 MP3FileManager v2 uses a simpler obfuscation algorithm than v1.x, but
   6 uses more complex structures to describe the device contents. The
   7 files are still, as with v1.x, obfuscated MP3 files. Note, I have
   8 indications that this doesn't work for all v2 devices, and even that
   9 there are now devices which do not obfuscate the file in any
  10 meaningful way at all beyond changing the header from ID3 to EA3.
  11
  12 File Mechanism and Layout
  13
  14 Please note that this describes v2.0 and later versions of the
  15 MP3FileManager application, and reverse-engineering of this is not
  16 complete. For v1.x, see FILE_FORMAT.txt.
  17
  18 V2.0 uses more files and a more complex layout, but a simpler
  19 obfuscation algorithm. The files on the device are as follows:
  20
  21 * A file called DvID.dat is created in the same directory as the
  22   MP3FileManager executable. There is a correlation between this file
  23   and the scrambling key, which k Kryss has figured out: the
  24   significant bytes are the 11th to 14th inclusive, which are then
  25   used in a keying function along with the track ID to generate the
  26   scrambling code.
  27
  28 * All other files go into a folder on the device called OMGAUDIO.
  29
  30 [device root]
  31 |
  32 +-OMGAUDIO
  33   |
  34   +- 10F00    ** 1XXXXXXXX.OMA files go here
  35   |
  36   +- 00gtrlst.dat
  37   +- 01treeXX.dat (minimum XX = 01 to 04)
  38   +- 02treinf.dat
  39   +- 03ginfXX.dat (minimum XX = 01 to 04)
  40   +- 04cntinf.dat
  41   +- 05cidlst.dat
  42
  43 Specifics of File Formats
  44
  45 General
  46
  47 As with v1.x, data is bigendian and text strings are UTF16BE. I have
  48 not as yet put a lot of effort into understanding the non-music files
  49 on the device, but all appear to be constructed similarly:
  50
  51 [16-byte file header, including object count]
  52 [block of 16-byte object pointers]
  53 [objects]
  54
  55 The file header consists of 4 bytes of magic to describe the file,
  56 what appears to be a constant 4 bytes, 1 byte indicating the number of
  57 object pointers, and padding out to 16 bytes.
  58
  59 Object pointers consist of 4 bytes of magic to describe the object
  60 type, a 32-bit file offset to the start of the objects (which are
  61 stored contiguously), a 32-bit data length, and padding to 16 bytes.
  62
  63 Objects start with 4 bytes of magic which match the pointer for the
  64 object, a 16-bit record count, a 16-bit record size, and padding to 16
  65 bytes.
  66
  67 Further investigation on the actual meaning of the various objects and
  68 records is required.
  69
  70 00GTRLST.DAT
  71
  72 This file contains two object types: SYSB and GTLB. SYSB seems to
  73 contain little to no useful data; I've only one sample file where it's
  74 not entirely filled with NULLs. The GTLB sections contain ID3 tag
  75 names (TPE1, TALB, and TCON) in various combinations. This may
  76 indicate which files on the device have which tags available. Each
  77 record looks something like this:
  78 2-byte record number
  79 2-byte record group?
  80 pad to 16 bytes
  81 2-byte # tags
  82 2-byte zeroes
  83 4-byte*#tags tags
  84 pad to record size with zeros
  85
  86 If "record group" is non-zero, there will be a 03GINFXX.DAT file
  87 corresponding to the record number? (may be a bitfield) The record
  88 numbers aren't necessarily in sequence.
  89
  90 01TREEXX.DAT
  91
  92 magic: TREE; GPLB and TPLB objects. GPLB records are 8 bytes each; all
  93 samples look like
  94 2 bytes track #
  95 2 bytes 0100
  96 2 bytes track #
  97 2 bytes 0000
  98 TPLB records are 2 bytes each and are simply the track number.
  99
 100 02TREINF.DAT
 101
 102 The file magic is GTIF. Contains GTFB objects. Records correspond to
 103 GTR or TREE? Sample non-null record:
 104 [zero padding][0a 5a9c 0001 0080] <= 16 bytes
 105 TIT2[0x0002]ATRAC AD1 Database: New Tracks[zero padding] <= remainder
 106 0x0002 is the ID3 encoding used - utf16be
 107
 108 03GINFXX.DAT
 109
 110 magic: GPIF; contains GPFB objects, which appear to be hold ID3 tags
 111 describing the source albums (i.e. you may have put the music into a
 112 folder named "New Folder", but this records the original album
 113 tagging). Objects start with a 16-byte header:
 114 4 bytes 00000000
 115 4 bytes 00000000
 116 4 bytes # of mp3 frames
 117 2 bytes # tag records
 118 2 bytes tag record size
 119
 120 Tag records consist of raw ID3v2(.4?) tags - 4 bytes indicating the
 121 tag type, 2 bytes to indicate the encoding, and the encoded data up to
 122 the size of the tag record. I don't know if the record size increases
 123 to cope with longer tags, or if the tags just get truncated. Current
 124 default appears to be 128-byte records, giving a 61-character maximum
 125 size.
 126
 127 04CNTINF.DAT
 128
 129 magic: CNIF; contains CNFB objects. Each object starts with a 16-byte header:
 130 4 bytes [0000 fffe] (file type? would be MPEG-1 Layer 1, which is wrong)
 131 4 bytes track size in ms
 132 4 bytes # of mp3 frames
 133 2 bytes number of tag records
 134 2 bytes size of each tag record (0x80)
 135
 136 Tag records consist of raw ID3v2(.4?) tags - 4 bytes indicating the
 137 tag type, 2 bytes to indicate the encoding, and the encoded data up to
 138 the size of the tag record. I don't know if the record size increases
 139 to cope with longer tags, or if the tags just get truncated. Current
 140 default appears to be 128-byte records, giving a 61-character maximum
 141 size.
 142
 143 05CIDLST.DAT
 144
 145 magic: CIDL; contains CILB records, one per track. Each record is 48
 146 bytes. Record format:
 147 six longwords which appear as-is in the corresponding track:
 148 0000 0000 [constant]
 149 010f 5000 [constant]
 150 0005 0004 [constant]
 151 00a0 8ddd [varies with track]          003f 2d76
 152 ca19 9809 [varies with track]          278e f5f0
 153 44b4 730b [varies with track]          befc 1727
 154 zero-padding to 48 bytes
 155
 156 OMA files
 157
 158 These are the actual MP3 files. The file starts with a tag "ea3";
 159 replacing the "ea" with "ID" turns this into an ID3 block, complete
 160 with size tag, which can be read with a standard ID3 library. So far
 161 all sample files have had 3072 bytes of ID3 data on the device,
 162 regardless of the amount in the input files. After the ID3 tag there
 163 is a second block starting with either "ea3" or "EA3" (not sure why
 164 there's a case difference, nor whether it changes between
 165 versions). The next byte, 0x02, is probably part of this
 166 signature. The next 16-bit word is the size of the header including
 167 the 4-byte signature. Immediately after the header is the mp3 data,
 168 obfuscated in 8-byte blocks. If the MP3 data does not fit exactly into
 169 8-byte blocks, the left-over bytes are copied "in the clear". The
 170 obfuscation is a simple XOR with a 4-byte pattern (repeated twice to
 171 obfuscate 8 bytes, obviously). The 4-byte pattern can be determined
 172 from already-written files through brute force, but this is obviously
 173 no help with writing. With access to the DvID file, you can use the
 174 following algorithm to generate the scramble key:
 175
 176   dvid = bytes 11 - 14 of DvID.dat
 177   n    = track id
 178   key = ( 0x2465 + n * 0x5296E435 ) ^ dvid
 179
 180 The key can also be retrieved by sending a command sequence directly
 181 over USB to the device. The sequence is as follows:
 182
 183 /* Thanks to Ricardo Ferreira (from the GYM project) for this byte sequence */
 184 const char g_query_device_dvid[] =
 185 {
 186   0x55, 0x53, 0x42, 0x43, 0xB0, 0x0B, 0x9E, 0x81,
 187   0x12, 0x00, 0x00, 0x00, 0x80, 0x00, 0x0C, 0xA4,
 188   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xBC, 0x00,
 189   0x12, 0x3F, 0x00, 0x00, 0x00, 0x00, 0x00
 190 };
 191
 192 You can use usb_bulk_write to write it to the device, usb_bulk_read to
 193 get the response (should be 18 bytes), and the bytes you're looking
 194 for are at offset 12 in the response (bytes 12, 13, 14, 15).
 195
 196 Credits:
 197 Waider <waider@waider.ie> (staring at hex dumps for many hours)
 198 Grégory 'GaLi' Cavelier / Romain 'Mayem' Tavenard (sample files, suggestions)
 199 Joe (jmk)        (sample files)
 200 tor              (sample files)
 201 k Kryss                  (DvID -> scramble key algorithm)
 202 Ricardo Ferreria (USB commands to fetch key)
 203 Jul Otias                (some further work on index files)