NDS Slot-1 Clean ROM no-patch Tester

[openchip]

Interestingly enough, I ran it from EZ4 with madden 2005 in slot 1
Slot-1 ROM tester ver 1.0
Chip ID: C20F0000
Clean ROM no-patch play: NO
(I get identical chip ID when I try with EZ5 and MK4-mini in the DS slot and run it from EZ4)
DSlink gives this:
Chip ID: 77B01F84
Clean ROM no-patch play: NO

Your program acts like homebrew and not a commercial ROM. Most cards have to use an entirely different loading mechanisms to load homebrew, they do not conform to commercial ROMs.

I won't argue though, any card that is loading a DS game from a TF or similar card would need to have it's access' patched somewhere along the line (be it on loadup or in the card's processor).

uups, I replied too quickly did not pay attention to dslink results.
incorrect chip may mean that the clean rom test is not reliable.
I can add more test to have more reliable results
eg emulator check
slot-2 check (if run from)
and nand-flash better check

 

[Monkey01]

It says YES in no$gba but completely crashes DeSmuME

Here it doesn't crash, results:
iDeaS 1.0.0.8c, Clean ROM no-patch play: YES
DeSmuME v0.5.0, Clean ROM no-patch play: YES
No$GBA ver.2.3, Clean ROM no-patch play: YES

But, do you by any chance know how ds-x manages to support games like mario kart for download play, which doesn't work for other carts, while it seems to patch just like the rest... Is it somehow possible to patch differently to not break download play, and how comes that download play gets corrupted by patching anyway? Cause they shouldn't be bothered by quick responding through some cart protocol, cause they're gotten by wifi and loaded in ds's own ram?

 

[cory1492]

uups, I replied too quickly did not pay attention to dslink results.
incorrect chip may mean that the clean rom test is not reliable.
I can add more test to have more reliable results
eg emulator check
slot-2 check (if run from)
and nand-flash better check

As far as I know, DSLink has no real ROM on the 4 pin bus at bootup (it does not act as a DS card in the DS menu). If I understand the documentation right, MK2/3 and DSLink all load their initial menu program through the save chip I/O. It would be interesting to actually find something that replies YES (other than an emulator) to be certain your check is working, though.

Monkey01: DS-X probably does additional patching to the download/play ROM (generally .srl file within the ROM) that the others do not.

edit:/ openchip: if you want any testing done from slot 1 just let us/me know. I'm sure someone will be happy and able to

 

[noda]

I don't find this program very relevant:

-first I would like to know how it's working (simply reading arm9&7 binaries loaded in ram & calculates checksum or something like that?) because without the source or the method explained, I won't trust such a program.

-then I don't think "patching" is the appropriate word to say what are doing current slot1 cards: actually, it's not "patch" in the traditional way we know it (like slot-2 supercard, m3 or so), otherwise the compatibility would not be 100%, with new rom support.

The way the actual slot1 cards works (AFAIK): the arm9&7 binaries are copied in ram like any commercial game, and the only changes are made dynamically: all card access are interpreted in a custom 'processor' (located in the FPGA or these cards) who translates standard rom calls to the rom file located on the sd/internal memory.
So I don't think the biniries are 'patched', there is only a system to interpret rom read calls dynamically.

 

[MaHe]

Oh, my dream SLOT-1 solution:

- a microSD adapter
- 128 MB of SDRAM where the game is loaded

This RAM could also be used in homebrew (particulary DSLinux), which is the only reason i'm still using SLOT-2 based solutions ... :/

 

[openchip]

I don't find this program very relevant:

-first I would like to know how it's working (simply reading arm9&7 binaries loaded in ram & calculates checksum or something like that?) because without the source or the method explained, I won't trust such a program.

-then I don't think "patching" is the appropriate word to say what are doing current slot1 cards: actually, it's not "patch" in the traditional way we know it (like slot-2 supercard, m3 or so), otherwise the compatibility would not be 100%, with new rom support.

The way the actual slot1 cards works (AFAIK): the arm9&7 binaries are copied in ram like any commercial game, and the only changes are made dynamically: all card access are interpreted in a custom 'processor' (located in the FPGA or these cards) who translates standard rom calls to the rom file located on the sd/internal memory.
So I don't think the biniries are 'patched', there is only a system to interpret rom read calls dynamically.

ok, here is the source code

// try reading stuff!
command[7] = 0xB7; // READ Slot-1 in main mode
command[6] = 0; // 32 bit address above 0x8000 offset in ROM
command[5] = 0x02; // 24..16
command[4] = 0x7E; // 15..8
command[3] = 0; // 7..0
command[2] = 0;
command[1] = 0;
command[0] = 0;
cardPolledTransfer(flags, buf, 512, command);

on clean/original ROM this would read ROM content from the offset specified.
if the slot-1 can not reply as original ROM this command will return wrong data.

the "custom processor" in FPGA is not required, and if present it would not be able to change anything in the regard of clean ROMs.

when ever the ROM loaded wants to access the ROM with the native nopatched routine using command 0xB7 then the slot-1 has to reply withing 4 microseconds. There is no way to predict what offset will be read so the slot-1 device can not dynamically prefetch.

slot-1 on board processor can make things "better" by translating ROM offset to LBA addressing, and prefetching to speed up sequential access, but it would make the ROM working without the actual code in the NDS RAM being patched. (or redirected to use custom access routines what is essentially the same).

So whenever and ROM loaded from slot-1 devices runs, then the normal processor flow will be changed whenever the ROM is accessed. The patching can be done differently what explains why different devices have different difficulties.

No current slot-1 or even worse slot-2 device can actualy have 100% compatibility. If it has that it means that is able to patch succesfully all known ROMs thats all. Not that it can run clean no patched ROMs.

 

[openchip]

who cares for some odd 3 orders of magnitude

Yes I understood that all roms are patched. What I still don't see is how that patch is solving the 4 µs problem. If I read your earlier posts correctly, the DS expects data back in 4µs and the card's flash can't react that fast. So the read command of the card is patched to not try to get the data (because it would be too slow), but to return garbage data (and this is what your tools tests). So this solves the problem with the 4µs but also means the ds is getting garbage data when reading. Reading garbage data instead of the wanted data should cause a problem?!?

it is patched to use custom commands to wait in loop til ready, then return correct data.
the efficiency of this and the ability of the slot-1 device to prefetch is the factor that defines how fast the ROMs run. If the slot-1 runs the sd-card at max speed and prefetches, then there is almost no penalty for sequential accesses.

 

[OSW]

Wow this thread has been really interesting and informative

Thank you to openchip and all the contributors so far!

I don't find this program very relevant:

-first I would like to know how it's working (simply reading arm9&7 binaries loaded in ram & calculates checksum or something like that?) because without the source or the method explained, I won't trust such a program.

-then I don't think "patching" is the appropriate word to say what are doing current slot1 cards: actually, it's not "patch" in the traditional way we know it (like slot-2 supercard, m3 or so), otherwise the compatibility would not be 100%, with new rom support.

The way the actual slot1 cards works (AFAIK): the arm9&7 binaries are copied in ram like any commercial game, and the only changes are made dynamically: all card access are interpreted in a custom 'processor' (located in the FPGA or these cards) who translates standard rom calls to the rom file located on the sd/internal memory.
So I don't think the biniries are 'patched', there is only a system to interpret rom read calls dynamically.

Although my knowledge of the matters in this topic is little, i like how logical your points seem.

 

[openchip]

Oh, my dream SLOT-1 solution:

- a microSD adapter
- 128 MB of SDRAM where the game is loaded

This RAM could also be used in homebrew (particulary DSLinux), which is the only reason i'm still using SLOT-2 based solutions ... :/

unfortunatly the slot-1 RAM would not be accessible as ARM7/9 accessible memory, so it would be only useable as ram disk for as block device. it could also hold romfs, etc, so it may help a little to run dslinux, but not as much as slot-2 device that expands the ARM accessible memory space.

 

[noda]

openchip: Why do you insist 128MB is the barrier? The addressing can support up to 4Gbit.

If your program acts in the same way as commercial ROM's, why doesn't it's access routines get patched as well? Does your random read method work with an official DS cart?

edit:/ just thought I'd mention, it's very easy to get "garbage data" back from these new slot 1 cards, easier than getting garbage back from a DS cart.

I'm also curious about that ! And thank you for posting the code and answering my questions

 

[openchip]

openchip: Why do you insist 128MB is the barrier? The addressing can support up to 4Gbit.

If your program acts in the same way as commercial ROM's, why doesn't it's access routines get patched as well? Does your random read method work with an official DS cart?

edit:/ just thought I'd mention, it's very easy to get "garbage data" back from these new slot 1 cards, easier than getting garbage back from a DS cart.


I'm also curious about that ! And thank you for posting the code and answering my questions

a generic patch that would be able to patch unknown-unsupported ROM patching is very hard todo.

only ROMs that are known or have known signatures will get patched.
everything else just doesnt work

 

[enarky]

openchip: Why do you insist 128MB is the barrier? The addressing can support up to 4Gbit.

If your program acts in the same way as commercial ROM's, why doesn't it's access routines get patched as well? Does your random read method work with an official DS cart?

edit:/ just thought I'd mention, it's very easy to get "garbage data" back from these new slot 1 cards, easier than getting garbage back from a DS cart.
I'm also curious about that ! And thank you for posting the code and answering my questions

a generic patch that would be able to patch unknown-unsupported ROM patching is very hard todo.

only ROMs that are known or have known signatures will get patched.
everything else just doesnt work

Or, to answer that question a little bit differently: these generic patchers look for the hashes of specific functions that read from DS carts. Which come from Nintendos devkit and look the same for each version. They replace these functions with their own ones, which read from that vendor specific card alone. That's also why you can't use a Supercard patched NDS ROM with the M3 and vice versa.

In this function an official ROM writes a specific value to a specific address ("B7aaaaaaaa000000h" to the register at 40001A8h, where aaaaaaaa is the adress where the programm wants to read from) to get the content of that specific values address in the NDS ROM - from my understanding this gets encrypted, sent to cart, decrypts there, cart sends encrypted content back, content gets decrypted in the DS.

Now, if you don't patch ROMs, this is also how homebrew on a Slot-1 card should behave and what openchips programm tests. But obviously, openchip didn't use Nintendo's functions for his programm, he wrote his own. Patchers and on-the-fly patchers in Slot-1 cards don't know that function, so they can't patch it and results are random garbage. That proves, that all current Slot-1 cards don't use the official way to access data on Slot-1. And once Nintendo changes their patch function again, these cards will have to be updated, too.

Please correct me if I'm wrong, that's how I *think* it works according to NDS documentation (most notably "DS Cartridge I/O Ports" and "DS Cartridge Protocol" sections).

 

[openchip]

openchip: Why do you insist 128MB is the barrier? The addressing can support up to 4Gbit.

If your program acts in the same way as commercial ROM's, why doesn't it's access routines get patched as well? Does your random read method work with an official DS cart?

edit:/ just thought I'd mention, it's very easy to get "garbage data" back from these new slot 1 cards, easier than getting garbage back from a DS cart.
I'm also curious about that ! And thank you for posting the code and answering my questions

a generic patch that would be able to patch unknown-unsupported ROM patching is very hard todo.

only ROMs that are known or have known signatures will get patched.
everything else just doesnt work

Or, to answer that question a little bit differently: these generic patchers look for the hashes of specific functions that read from DS carts. Which come from Nintendos devkit and look the same with each version. They replace these functions with their own ones, which read from that vendor specific card alone. That's also why you can't use a Supercard patched NDS ROM with the M3 and vice versa.

In this function an official ROM writes a specific value to a specific address ("B7aaaaaaaa000000h" to 40001A8h, where aaaaaaaa is the adress where the programm wants to read from) to get the content of that specific values address in the NDS ROM - from my understanding this gets encrypted, sent to cart, decrypts there, cart sends encrypted content back, content gets decrypted in the DS.

Now, if you don't patch ROMs, this is also how homebrew on a Slot-1 card should behave and what openchips programm tests. But obviously, openchip doesn't use Nintendo's functions for his programm, he wrote his own. Patchers and on-the-fly patchers in Slot-1 cards don't know that function, so they can't patch it and results are random garbage. That proves, that all current Slot-1 cards don't use the official way to access data on Slot-1.

Please correct me if I'm wrong, that's how I *think* it works according to NDSTek (most notably " DS Cartridge I/O Ports" and "DS Cartridge Protocol" sections)

99.99% correct.

The data sent is no really encrypted, (I would not call shift+XOR encrypted) but it is obfuscated by KEY2, yes.
It does get decoded into plain in the DS hardware, so as the result from reading the card is plain raw original data.
I mean any data the ARM7/9 reads is already decoded and ready to use raw data.

 

[cory1492]

Theoretically, (for best compatibility at any rate) a generic patch would, on this type of card, be patching at the hardware access level. CMD B7 would be received, interpreted by the onboard chip, address determined in the FAT offset and the data returned... unless it's in homebrew mode and not expecting slot 1 commands to be issued.

The only thing I don't understand now, is why you are expecting to get valid "not wrong" data back with the B7 command. At what point is the encrypted data that is read by the encrypted data read command... decrypted?

 

[openchip]

Theoretically, (for best compatibility at any rate) a generic patch would, on this type of card, be patching at the hardware access level. CMD B7 would be received, interpreted by the onboard chip, address determined in the FAT offset and the data returned... unless it's in homebrew mode and not expecting slot 1 commands to be issued.

The only thing I don't understand now, is why you are expecting to get valid "not wrong" data back with the B7 command. At what point is the encrypted data that is read by the encrypted data read command... decrypted?

no. it want work that way.

you can reply to 0xB7 with correct data, but the thing is that the NDS hardware expect this to be available withing 4 microseconds from the request. This is the all point. The slot-1 device can not deliver data as fast.

The Slot-1 device may interpret 0xB7 correctly, but the ROM still has to be patched to add a ready polling loop before the 0xB7 is issued to allow the Slot-1 device to retrieve the block from slow media (SD card or NAND flash).

 

[cory1492]

Having a tough time trying to get across my point...
Basically, why would you expect the Slot 1 cards to give the data a DS cart would, when the homebrew ROM itself breaks a tonne of "rules" that DS carts have to follow... like secure area, no program data before 0x4000 etc. Basically with homebrew, it can be copied into memory, ran, and the slot ignored/onboard chips suspended from then on unless the programmer decides to use it.

In essence, this goes back to some testing I did ages ago, where every time I read the header, the data I got back was different _until_ I pulled the card out and reinserted it.

An interesting experiment would be to hook a DS rom to dump the core data access routines after it was done to see if they had been patched on loadup.

 

[openchip]

Having a tough time trying to get across my point...
Basically, why would you expect the Slot 1 cards to give the data a DS cart would, when the homebrew ROM itself breaks a tonne of "rules" that DS carts have to follow... like secure area, no program data before 0x4000 etc. Basically with homebrew, it can be copied into memory, ran, and the slot ignored/onboard chips suspended from then on unless the programmer decides to use it.

In essence, this goes back to some testing I did ages ago, where every time I read the header, the data I got back was different _until_ I pulled the card out and reinserted it.

An interesting experiment would be to hook a DS rom to dump the core data access routines after it was done to see if they had been patched on loadup.

sure, your testing was correct.

if you try reading the header directly after your homebrew starts you will get KEY2 mangled data that changes every time.
You have to reset the card to be able to read the header.
but if you reset the slot-1 flash card you would be reading the header of the slot-1 firmware not of your app

 

[openchip]

http://nds.truedream.org/

Updated version 1.1 is available.
Should detect/warn if being run from emulator or slot-2 device.
Also warns if ROM ID is unknown or Game header is patched.

To add to the test results ninjads reports NO clean, AND Game header patched.
R4DS reports NO clean, but doesnt patch the game header.

Both versions 1.0 and 1.1 have done little testing by me, only checked
on some emulators and R4DS and ninjads.

Test results with ver 1.1 are very welcome, specially results from 1:1 ROM claims
like the N-Card or alike

 

[t0m1th3]

I'm not sure if this has been mentioned, but wouldn't it be possible at some point to have the fast NOR memory, with a micro-sd card, you boot it and copy a game to the NOR, then reset and flick a switch so it reads from the NOR and thinks it's a real game?

 

[Dirtie]

Thanks for explaining that for me.

I was also gonna mention my thoughts that the memory would have to be similar/fast as an original cart if it was not to patch read/write routines in any way, but I was beaten to it.

Now that we have some insight into how this tool works, I will have to congratulate you sir for allowing us to discover what I've wanted to know all along about these so-called "clean rom" carts.

t0m1th3: that's pretty much how the EZ-Flash 3/4 carts work (for GBA), and openchip has already suggested something similar.