Pages: 1
Posted on 05-06-18, 07:00 pm in Nintendo DS dev hardware! IS-NITRO-EMULATOR & co. (rev. 1 by  Gericom on 05-06-18, 07:01 pm)
Shyguy


Karma: 160
Posts: 72/90
Since: 07-10-12
@Dirbaio I can soon supply you with more information I have gathered and an ida pro database of the firmware. (I'm currently on a holiday) The only thing that is basically left to explore is if video capture over usb is possible with is-nitro-emulator too. The firmware in the video fpga is the same one as used for is-nitro-capture, and there is even some code that seems to be for taking a screenshot, but it seems to hang in an endless loop waiting for the capture status bit to become 0, but that never happens. This causes the device to hang.

Very nice teardown you did there by the way. I only had such pics of the is-nitro-capture until now.

Also, you probably saw I invited you to a repo where some code resulting from my research is stored.

As for the wired-wifi, I managed to write vhdl code to receive and send packets over it. It's basically just baseband wifi signals.
Posted on 10-05-12, 04:58 pm in Mario Kart DS Custom Tracks :)
Shyguy


Karma: 160
Posts: 36/90
Since: 07-10-12

Cool? I used mkds course modifier to export the model with vertex colors!
Posted on 05-12-18, 12:33 pm in Nintendo DS dev hardware! IS-NITRO-EMULATOR & co.
Shyguy


Karma: 160
Posts: 79/90
Since: 07-10-12
Posted by Dirbaio
Posted by Gericom
Cool! Nice found. So this is data that is only needed on an actual cartridge and not on the is-nitro-emulator appearently. Is it known what the exact purpose of that data is?


From what I understand, the DS encryption generates some data tables from the gamecode, then uses them to encrypt/decrypt commands. This data is what's in the rom at 0x1600 and 0x1c00.

You can see the details at gbatek key1 encryption details. This data is called "keybuf" there.

I can think of 2 reasons they did it this way.

1: efficiency. This way the card doesn't need to calculate the table, and doesn't need temporal ram to store it. Why require extra ram if the data never changes, and you have plenty of rom storage already?

2: more security: By doing it this way, deva never needed to encrypt/decrypt anything in their machines, so Nintendo's tools didn't need to have code for that, protecting it from getting reverse engineered.

Nintendo would assign the gamecode to the game, then give the deva the encryption data for that gamecode and the first 0x800 bytes of the secure area, already encrypted for the gamecode too (what they call the "syscall library").

Also interesting is that doing it this way didn't give devs info useful to pirate/dump other games than their own.

Hmm, yes, quite smart indeed. How was it possible to reverse the algorithm? Was it in the bios? If so, that wasn't very smart of them.
Pages: 1