fix(3ds): Fix bugs and incorrect documentation #5
Conversation
The 3DS decryptor is reading the title ID as little endian, instead of properly using big endian like other fields. Use proper endianness to fix the issue. Also update some incorrect documentation about 3DS fields on the README.
| release_date: bigint; | ||
| serial_number: bigint; |
There was a problem hiding this comment.
This is a very different change, is this confirmed? 3dbrew is down so I can't verify myself
There was a problem hiding this comment.
This is what it says about the field on 3dbrew (taken from a backup):
The 64-bit number at 0xC may be a serial number which is increased every time someone requested to sign and create a boss container for a file. The 3DS sees the downloaded file as new if this number is different from the previous download (Doesn’t matter if the number is bigger or smaller).
This is supported by the fact that three sample containers I have (Badge Arcade containers from the same time but different regions) have really close values on this field:
- EUR: 4086189
- JPN: 4086185
- USA: 4086187
In any case, this is just updating the documentation to match the existing code, which uses the serial_number name.
There was a problem hiding this comment.
This sounds like the DataId of later iterations of BOSS, I feel like that might be a more accurate name and the wiki might need to be updated to reflect that? Based on that description and the example values it looks IDENTICAL to DataId (which is just a counter on the server used to assign a unique value to the BOSS contents)
There was a problem hiding this comment.
Is the DataId you mention per-container or per-payload? 3DS containers can have multiple payloads, and each of those gets what's called a NsDataId. This serial number is per container though
There was a problem hiding this comment.
I'm honestly not sure how that translates, tbh, since Wii U BOSS and 3DS BOSS files are so different
BOSS on the Wii U doesn't have the whole "multiple payloads" thing. Every BOSS encrypted file always just refers to one single file, it's a much simpler format
In NPTS you can see a list of files from BOSS, and every file has a unique DataId. So on the Wii U a DataId always refers to a single file, I suppose that would be a "container" in this case? This DataId counts up every time a new BOSS file is uploaded, which matches the incremental nature of the examples you gave and they're in about the range I would expect for a DataId
Resolves #XXX
Changes:
The 3DS decryptor is reading the title ID as little endian, instead of properly using big endian like other fields. Use proper endianness to fix the issue.
Also update some incorrect documentation about 3DS fields on the README.