|
|
Posted on 08-01-11, 07:47 pm
|
|
☭ coffee and cream
 Karma: 10542 Posts: 96/2780 Since: 06-26-11 |
The NSMB ROM doesn't exactly end at the offset specified at 0x80. It actually ends 136 bytes further. A few other ROMs I looked into (MKDS, SM64DS and others) have the same thing.
Today, I was reading stuff about NDS multiboot (dowload play) on GBAtek. The RSA signature embedded in the RSA frame is 136 bytes, just like that mysterious block at the end of official NDS ROMs. So I figured that this block may be the RSA signature for download play. From what I could see in NSMBe's code, the editor uses the value at 0x80 as-is, and would overwrite that signature if the ROM had to be expanded. That'd be bad for download play. _________________________ Kuribo64 - zrghij |
|
|
Posted on 08-01-11, 07:51 pm
|
 Super Mario( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 455/4458 Since: 06-08-11 |
WOW. Really?
That'd explain completely the problems we were having with DS Download Play... Can someone with access to two DS's help us check it? Please do this: Grab a clean NSMB ROM, test if it works with DS Download Play. Then hex edit it, replace those 136 bytes with 0's (or whatever) and test again. If the first one works and the second one doesn't, then we have the secret 
|
| luckwii |
Posted on 08-01-11, 07:54 pm
|
 Buster Beetle Karma: 379 Posts: 136/464 Since: 06-29-11 |
Posted by Dirbaio WOW. Really? That'd explain completely the problems we were having with DS Download Play... Can someone with access to two DS's help us check it? Please do this: Grab a clean NSMB ROM, test if it works with DS Download Play. Then hex edit it, replace those 136 bytes with 0's (or whatever) and test again. If the first one works and the second one doesn't, then we have the secret I won't be able to test until this weekend. But if nobody else is able, I can do it then. |
|
|
Posted on 08-01-11, 07:57 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 457/4458 Since: 06-08-11 |
Cool, thanks
|
|
|
Posted on 08-01-11, 08:03 pm
|
|
☭ coffee and cream
Karma: 10542 Posts: 97/2780 Since: 06-26-11 |
I just tested it.
Clean NSMB ROM: DLP connection works fine. NSMB ROM with the 136 last bytes replaced with 0xFF: DLP client sees NSMB, downloads and freezes on a Nintendo logo. Host says that the connection was interrupted. Turns out I was right about that RSA signature thing. Now, however: Posted by GBAtek The RSA frame format (type 0x03) sends a table of information about the game being downloaded (most of it redundant with the NDS header, see Appendix), as well as the RSA signature for the DS. I have not looked into computing the signature, as homebrew developers are not privy to Nintendo's private key, making signing a fruitless activity, but it is my understanding that the signature is a 128 byte public key and an 8 byte SHA-1 message digest over the NDS header, ARM9 binary, and ARM7 binary. Notably: the RSA frame itself is not included as part of the data being signed, bringing up various security issues and making Nintendo's firmware engineers look amateurish at best. Turns out that modifying the ROM header (or binaries) may also break DLP 
_________________________ Kuribo64 - zrghij |
|
|
Posted on 08-01-11, 08:09 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 458/4458 Since: 06-08-11 |
Yay! Awesome
And yeah, we already knew that the header couldn't be modified. That's where the "change the rom size in header or not" bullshit comes from. We change it? DLP is broken. We don't change it? Then NSMB breaks with some cards that only load the ROM up to the rom size in the header. Since the ROM is actually bigger, this breaks the game itself. So, even with this find, I think our options to expand ROM's without breaking DLP are still limited 
|
|
|
Posted on 08-01-11, 08:15 pm
|
|
☭ coffee and cream
Karma: 10542 Posts: 98/2780 Since: 06-26-11 |
The worst thing is that we can't even disable the signature check. According to GBAtek, it's coded in the firmware itself.
Eventually, we could obtain the public key, but we'd actually need the private key... the one key which is being kept secretly in Nintendo's high-security basement. _________________________ Kuribo64 - zrghij |
|
|
Posted on 08-01-11, 08:23 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 460/4458 Since: 06-08-11 |
Well, there's FlashMe, a firmware mod that disables the signature check. I have it, and it works perfectly. It allows any hacked ROM to be downloaded.
Also, there's this which is basically the FlashMe firmware as a .nds file, which you can use to download hacked ROM's without flashing your DS. If we want it to work with the original firmware, we'd have to either get the actual private key, which is really hard (in some cases it might be possible, see what happened to Sony), or find a bug that allows us to skip/hack the check (See the good old Wii's trucha bug). Both things would be ultra hard or impossible to do. |
|
|
Posted on 08-01-11, 09:11 pm
|
|
☭ coffee and cream
Karma: 10542 Posts: 99/2780 Since: 06-26-11 |
Getting the private key would require somehow hacking into Nintendo.
As for a trucha bug, the signature begins with: 61 63 01 00 I tried replacing the data coming after that zero -> connection broken. That is, no good ol' trucha bug here. Also, Sony's private key was leaked out because they did a terrible job at implementing ECDSA. _________________________ Kuribo64 - zrghij |
|
|
Posted on 08-01-11, 09:13 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 462/4458 Since: 06-08-11 |
Yeah
So better forget about this and move on. Making the ROM bigger and having it still work is Officially Impossible™... |
|
|
Posted on 08-02-11, 10:55 am
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 469/4458 Since: 06-08-11 |
I think I got THE solution.
Overlays are probably NOT signed. (gbatek doesn't say so. Anyways, checking it is easy) but overlays are executable code, right? Fine, let's take advantage of that. Let's make NSMBe write the true ROM size to the header. The CRC will get modified too. This way, the ROM will load fine on ALL cards. Then, put some code in an overlay. This code will run when the ROM is booted up, and will modify the header in RAM: Will put the ROM size and the CRC back to the original setting. The original header will be sent, and everything will work  (The header is sent from RAM, I'm pretty sure, since the header can only be read from the gamecard on bootup) |
|
|
Posted on 08-02-11, 12:55 pm (rev. 1)
|
|
☭ coffee and cream
Karma: 10542 Posts: 100/2780 Since: 06-26-11 |
I can confirm from being into SM64DS hacking, that overlays aren't signed. That sounds like a nice idea, we just need to find an appropriate place for that code.
However, you have to be careful about one detail when modifying the header in RAM: when loading the minigame menu, NSMB reads the ARM9 entry address from RAM and jumps there. _________________________ Kuribo64 - zrghij |
|
|
Posted on 08-02-11, 03:47 pm (rev. 3)
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 470/4458 Since: 06-08-11 |
Hmmm... Overlays have a "static initializer" thing that is run as soon as the overlay is loaded. Maybe we can put our code there, in overlay 0, since it's always lodaded from the game boot.
I'll try to look at it. EDIT: Wait wait wait. I think overlays are signed too... Look at this code. It's run right after an overlay is loaded. So, basically: If the overlay isn't signed -> BAD
If the overlay ID is out of table -> BAD
If the overlay doesn't match against the stored hash -> BAD
If BAD -> zerofill the overlay.
else -> Decompress, flush cache and do static init. We're screwed. (probably) You say you're sure overlays aren't signed in SM64DS. Are you completely sure? If so, we should check it again on NSMB. EDIT: Maybe there's a way around this. We have to find out which overlays are sent, and put the code that restores the header in one that isn't sent, but is still loaded on startup. I'm going to try getting the list of overlays loaded on startup right now And, congratulations on 100 posts
|
| LeWario |
Posted on 08-02-11, 04:21 pm
|
|
Banned for being a complete idiot.
Karma: 529 Posts: 49/987 Since: 07-09-11 |
And, r178 fixes this problem?
|
|
|
Posted on 08-02-11, 04:30 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 476/4458 Since: 06-08-11 |
Nope, not yet. This is just one step more.
But we still don't know if it's possible. It might be impossiible at all. |
|
|
Posted on 08-03-11, 08:23 pm
|
|
☭ coffee and cream
Karma: 10542 Posts: 101/2780 Since: 06-26-11 |
Oh well, SM64DS doesn't appear to check overlays... at least, I can get added overlays to load... previous versions of SM64DSe would directly modify the existing overlays and it would work as well. Now, this is NSMB we're talking about. Nintendo may have improved their security in the meantime.
Another possible way around would be to change the entry adress in the header outside of the ARM9 binary space, making it point to code that would modify RAM at 0x027FFE00 and then jump to the actual entrypoint. _________________________ Kuribo64 - zrghij |
|
|
Posted on 08-04-11, 11:06 am
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 517/4458 Since: 06-08-11 |
Well, the overlay validation code is only being run on download play, so maybe it's also in SM64DS and you haven't noticed...
Could you test this out: Modify a single byte of overlay 0 and test download play? That way we'll be completely sure. And, the entrypoint hack would be really nice, but it has two main problems: - Some cards (like mine) always use the entrypoint as 0x02000800 no matter what's in the header. (Yeah, I know it makes no sense, but that's the way it is.) - Ignoring that, how do we load the code in RAM without using either the arm9/7 bins or the header? |
|
|
Posted on 08-04-11, 03:09 pm
|
|
☭ coffee and cream
Karma: 10542 Posts: 104/2780 Since: 06-26-11 |
)|
|
Posted on 08-04-11, 05:19 pm
|
|
Super Mario ( ͡° ͜ʖ ͡°) Karma: 10081 Posts: 531/4458 Since: 06-08-11 |
Cool.
I'll wait for you to test that before coding anything
|
| coolas1 |
Posted on 08-07-11, 02:57 am
|
 PorcupoDid you win the game? Karma: 226 Posts: 46/322 Since: 06-28-11 |
Dirbaio could you please tell me the RAM offset of the header when running nsmb.
|