100% dump

I now dumped the secure area correctly of the Metroid demo. The CRC for that reports OK (0xC44D). I have put the tests on idle, since I don't know if they will be of any more use. Still need to figure out how the encryption on the first few commands work.

First test complete

At about 80% of the first test, the correct value was found. This proves my theories and allows me to take the next few steps :). Thank you all for participation.

Distributed cracking

I would like to conduct some test(s) on data that has been captured from a cartridge. Because I know how the PRNG works, I made a simple distributed cracking tool to find the correct values for a given set of null-data.
If you want to help out, check out http://darkfader.net/ds/stats.php

Encryption

I stopped the Real Time Clock in the DS and proved the encryption bases its random number generator on the time and the 4-character gamecode in the header. The game does not start when the gamecode is altered. Most of the bios code has been dumped and we found some others things on the encryption.
I've analyzed the random number generators and can reproduce the numbers, but unfortunately the initial numbers are in a locked part of the bios. The are ways to read it though :)
I'm currently making some program that calculates the LFSR values from the stream in reverse direction... challenging ;)

Romdumps

I've dumped the Metroid demo and Mario 64 DS.
This could be done by capturing commands to the cartridge and then play them back and alter the first byte to turn a normal read into an ID command. The difference in data resulted in the original data.
This gave me the idea of running two cartridges at the same time. One using normal commands and other ID commands. But since I didn't got a 2nd GBC connector and am too lazy to make one myself, I haven't tried this method yet. And it's not required anymore.
Unfortunately, the first part of the ARM9 executable uses some other encryption method. This part has been dumped from the RAM but is not the original data. The rest of the cartridge was dumped by issueing the ID command instead of the read command and save the data difference.

My pass-through ran the first code!

So... when I got my DS and games, I started to make an FPGA (a programmable logic chip) -based pass-through that would let me capture and alter the cartridge traffic. An etched PCB goes into the DS and a cut GBC-connector holds a DS cartridge. Once this worked, I tried fiddling with the header and found out that it could run own code from the GBA slot. There is even a bit that automatically starts the program without user-interaction at the boot screen. For this, I made a utility called ndstool that fixes the CRC values in the header.
After I could run my own code, I made a small program that modified a text in memory of the Metroid demo and then continued executing.
Commercial games might be playable from GBA cartridge with some code patching, but it's also possible to attach a flashchip to the DS slot to put game files on. In fact, no GBA cartridge is even required for the pass-through trick. Just execute some small loader that is stored in the unencrypted header.

The begin of .hack//DS

After a few weeks the Nintendo DS was out, I found someone that was willing to ship me one at a nice price from USA to NL. One thing was on my mind... to hack it. I had looked at inside pictures of the cartridge and DS. I guessed the pinout rather nicely. Others started to capture the traffic of the cartridge. We then saw the header data and encrypted data. We somehow knew it was encrypted before we started looking, but the "RSA" on the back does not apply to the cartridge.