DexDrive .N64 format
MPKEdit has basic support for DexDrive .N64 files for importing. It can even scrape comment text, but it doesn't incorporate a full understanding of the format.
So, here's my attempt to document it a bit better. Though much of this is inconclusive.
The .N64 DexDrive format is simply a normal 32,768 byte .MPK file with a 4,160 byte header.
| Offset | Len | Description |
|---|---|---|
| 0x00 | 64 | DexPlorer Header |
| 0x40 | 256×16 | ASCII text comments, 16 distinct chunks respective to each note slot. |
| 0x1040 | 32,768 | The .MPK data |
Unfortunately, much of this header is unknown and changing values has no effect in DexPlorer itself.
| Offset | Len | Description |
|---|---|---|
| 0x00 | 12 | ASCII string 123-456-STD, plus a NULL terminator. |
| 0x0C | 4 | Unknown, appears random, though sometimes 0. |
| 0x10 | 4 | Unknown, but always 00 00 01 00
|
| 0x14 | 1 | DexPlorer program version? Always 0x00 or 0x01. |
| 0x15 | 16 | Unknown. May refer to 16 note slots or comments. Bytes are often set to 0x03 or 0x00. Sometimes 0x81, 0x4E, 0x3B or 0xDE show up in specific areas here. |
| 0x25 | 1 | Unknown, appears random, though sometimes 0. |
| 0x26 | 2 | Unknown. Always 00 00, aside from one edge case (1 in 512 chance not being 0). |
| 0x28 | 1 | Unknown. Most often 0x00, but 0x02 occurs 84 times, 0x82 occurs 19 times. |
| 0x29 | 1 | Unknown. Almost always 0x00, but can be also 0x02 or 0x82. No other values occur here. |
| 0x30 | 22 | Unknown. Bytes are often 0, but can appear quite random. |
- DexPlorer is surprisingly lenient when opening files; it doesn't seem to validate the header.
- NRage's input plugin creates .N64 files that only contain the string '123-456-STD'. Thus based on incomplete information. These are the only files that do not contain
00 00 01 00at0x10. - To detect this format, the string
123-456-STDis more than sufficient due to it being 11 bytes. ALL .N64 files have this. -
d[16] === 0 && d[17] === 0 && d[18] <= 1 && d[19] === 0 && d[20] <= 1is possible, but overly verbose.
So, there are 113 unique 64-byte headers in the dataset. This implies quite a bit of variation. I suspect it may store something regarding the note entries or comment text.
However, one particular area of bytes at 0x10-0x1A is comparatively constant.
Looking at just that area, there are 20 repeating patterns:
-
0000010000 0303030303= 327 matches -
0000010001 0303030303= 57 matches -
0000010001 0000004E00= 69 matches -
0000010001 8100004E00= 12 matches -
0000010001 000000DE00= 10 matches -
0000010001 0001013B00= 5 matches -
0000010001 0000003B00= 4 matches -
0000010001 8100003B00= 3 matches -
0000010001 0000004E4E= 3 matches -
0000010001 8000004E00= 2 matches -
0000010001 1000004E00= 2 matches -
0000010001 FF00004E00= 2 matches -
0000010001 0000000000= 2 matches -
0000010001 8100004E4E= 2 matches -
0000010001 0002024E00= 1 match -
0000010001 0007074E00= 1 match -
0000010001 0000004E3B= 1 match -
0000010001 FE00004E00= 1 match -
0000010001 810000004E= 1 match -
0000010001 8101013B00= 1 match
Still, I don't see any clear logic, One byte seems to often be 0x4E (N), but it can also be 0x3B (;), or 0xDE (Þ)
Here is a byte-by-byte statistical analysis looking for unique values:
| Offset | Possibilities | Notable possibilities |
|---|---|---|
| 0 | 1 | ASCII "1" |
| 1 | 1 | ASCII "2" |
| 2 | 1 | ASCII "3" |
| 3 | 1 | ASCII "-" |
| 4 | 1 | ASCII "4" |
| 5 | 1 | ASCII "5" |
| 6 | 1 | ASCII "6" |
| 7 | 1 | ASCII "-" |
| 8 | 1 | ASCII "S" |
| 9 | 1 | ASCII "T" |
| 10 | 1 | ASCII "D" |
| 11 | 1 | 0x00 |
| 12 | 46 |
0x00×427 |
| 13 | 32 |
0x00×458, 0xE6×8 |
| 14 | 36 |
0x00×440, 0x6E×9, 0x05×8 |
| 15 | 24 |
0x00×459, 0x90×8 |
| 16 | 1 | 0x00 |
| 17 | 1 | 0x00 |
| 18 | 1 | 0x01 |
| 19 | 1 | 0x00 |
| 20 | 2 |
0x00×332, 0x01×176 |
| 21 | 7 |
0x03×375, 0x00×104, 0x81×19, 0x80×2, 0xFF×2, 0xFE×2, 0x10×2 |
| 22 | 5 |
0x03×375, 0x00×123, 0x01×6, 0x02×1, 0x07×1 |
| 23 | 5 |
0x03×375, 0x00×123, 0x01×6, 0x02×1, 0x07×1 (always same as previous?) |
| 24 | 5 |
0x03×375, 0x4E×99, 0x3B×13, 0xDE×10, 0x00×3 (very odd!) |
| 25 | 4 |
0x03×375, 0x00×124, 0x4E×6, 0x3B×1 |
| 26 | 42 |
0x03×375, 0x00×53 |
| 27 | 31 |
0x03×375, 0x00×90 |
| 28 | 23 |
0x03×375, 0x00×93 |
| 29 | 24 |
0x03×375, 0x00×89 |
| 30 | 29 |
0x03×375, 0x00×86 |
| 31 | 24 |
0x03×375, 0x00×96 |
| 32 | 21 |
0x03×375, 0x00×99 |
| 33 | 23 |
0x03×375, 0x00×99 |
| 34 | 23 |
0x03×375, 0x00×92 |
| 35 | 23 |
0x03×375, 0x00×94 |
| 36 | 25 |
0x03×375, 0x00×95 |
| 37 | 39 |
0x00×441 |
| 38 | 2 |
0x00×510 |
| 39 | 2 |
0x00×510 |
| 40 | 10 |
0x00×389, 0x00×84, 0x00×84 |
| 41 | 3 |
0x00×504, 0x02×5, 0x82×2 |
| 42 | 32 |
0x00×457 |
| 43 | 27 |
0x00×463 |
| 44 | 20 |
0x00×473 |
| 45 | 27 |
0x00×468 |
| 46 | 28 |
0x00×467 |
| 47 | 25 |
0x00×480 |
| 48 | 21 |
0x00×474 |
| 49 | 21 |
0x00×470 |
| 50 | 27 |
0x00×468 |
| 51 | 25 |
0x00×478 |
| 52 | 21 |
0x00×482 |
| 53 | 32 |
0x00×440, 0x01×9 |
| 54 | 39 |
0x00×436 |
| 55 | 22 |
0x00×456, 0x01×13 |
| 56 | 53 |
0x00×419 |
| 57 | 36 |
0x00×442, 0x05×9 |
| 58 | 40 |
0x00×438, 0x6E×11 |
| 59 | 17 |
0x00×469, 0x02×11 |
| 60 | 54 |
0x00×417 |
| 61 | 38 |
0x00×427, 0x01×13 |
| 62 | 40 |
0x00×424, 0x6E×9 |
| 63 | 23 |
0x00×458 |
So in conclusion... it's inconclusive. There doesn't seem to be anything important in the data, AFAICT. Serious reverse engineering would be needed to truly determine the purpose of the garbage data. But the important stuff is already done: detection of DexDrive files and extraction of comment text. I was hoping maybe the header controlled ordering of comments, but apparently not.