Got a great idea on how to improve GodMode9?
With https://github.com/d0k3/GodMode9/pull/722, we found that in NTR titles require an extra 0x88 bytes to be dumped for DS Download Play to function properly when trimmed.
Not all DS Download Play compatible titles have this extra key appended to the ROM image. Currently, we just dump the extra 0x88 without any extra checks, since it's less than a kilobyte of difference that the average user can share. Either way, this means with some games it's not truly trimmed down.
Provided are a few screenshots of NTR game hex dumps, where I scrolled to end of ROM as defined in the NTR header. We see a game with 0xFF bytes (or zero-bytes), and a game with exactly 0x88 bytes of data:
Pokemon Dash (USA):
MKDS (USA):
Looking at a few other examples of games with appended RSA keys, the magic number appears to be 0x00016361 in little-endian. (or maybe it's 0x6361, and the next 2 bytes are just header entries? But the 3 games I checked with available keys seemed to be identical in the first 4 bytes.) Or is there a magic number? It's just a consistency I've found.
Describe the feature you'd like
Ideally, for trimmed NTR games we should check if the keys actually exist before dumping it in trimmed format.
NDSTokyoTrim, a popular Windows-based trimming software, is known to implement this. However, it's PC-based, and with the assumption that the ROM is already fully present on the PC, it is a simple matter to just fopen and scan the end of ROM.
However, in GodMode9, we cannot assume this will be the case. It is very likely the end user is dumping from the cartridge, and there would very likely be latency involved if we had to check the header entry and do the entire unlock sequence just to check if there is valid data at the end of the ROM...
Describe alternatives you've considered
There aren't really any alternatives I can think of.
It's also not really necessary to do this, we can just leave 0x88 of blank bytes and call it a day, what's an extra 88 bytes going to cost anyone?
Got a great idea on how to improve GodMode9? With https://github.com/d0k3/GodMode9/pull/722, we found that in NTR titles require an extra 0x88 bytes to be dumped for DS Download Play to function properly when trimmed.
Not all DS Download Play compatible titles have this extra key appended to the ROM image. Currently, we just dump the extra 0x88 without any extra checks, since it's less than a kilobyte of difference that the average user can share. Either way, this means with some games it's not truly trimmed down.
Provided are a few screenshots of NTR game hex dumps, where I scrolled to end of ROM as defined in the NTR header. We see a game with 0xFF bytes (or zero-bytes), and a game with exactly 0x88 bytes of data:
Pokemon Dash (USA):
MKDS (USA):
Looking at a few other examples of games with appended RSA keys, the magic number appears to be 0x00016361 in little-endian. (or maybe it's 0x6361, and the next 2 bytes are just header entries? But the 3 games I checked with available keys seemed to be identical in the first 4 bytes.) Or is there a magic number? It's just a consistency I've found.
Describe the feature you'd like Ideally, for trimmed NTR games we should check if the keys actually exist before dumping it in trimmed format.
NDSTokyoTrim, a popular Windows-based trimming software, is known to implement this. However, it's PC-based, and with the assumption that the ROM is already fully present on the PC, it is a simple matter to just fopen and scan the end of ROM.
However, in GodMode9, we cannot assume this will be the case. It is very likely the end user is dumping from the cartridge, and there would very likely be latency involved if we had to check the header entry and do the entire unlock sequence just to check if there is valid data at the end of the ROM...
Describe alternatives you've considered There aren't really any alternatives I can think of.
It's also not really necessary to do this, we can just leave 0x88 of blank bytes and call it a day, what's an extra 88 bytes going to cost anyone?