NDS Slot-1 Clean ROM no-patch Tester

[OSW]

I don't think that's quite right with acekard, because the roms are not altered at al, it just has a program to transfer them to the acekar file system.

 

[Opium]

As long as the games work and start up quick, I don't think anything else matters. But it's still interesting to know

 

[openchip]

Without solid information about how this tester works, the test is pointless. If just transforming the memory addresses makes the tester say the rom is being patched, then only genuine carts will ever pass the test.

Until the author of this tool explains how he prevents false positives the results should be ignored.

Hi

I am the author, I can explain what the utility does.
The only test done is 1 Slot-1 read access to read a block of itself.
If the Slot-1 device is clean, then it would read back correct contents.
If the Slot-1 device can not read the Slot-1 without patched read routines the readback will not match.

The utility DOES say yes if executed in emulator as emulators do deliver correct readback on command 0xB7.

There is nothing Slot-1 makers can do, the Slot-1 protocol requires valid data be present on random reads within 4 microseconds.
Only NOR flash or ROM is that fast, NAND flash response time is also too long (about 12 microseconds)

Please feel free to ask more question, I am deep technical personal so I may explain in terms not understood sometimes.

Antti

 

[MaHe]

The idea that patching breaks download play doesn't make any sense. The DSX has the best download play and it patches on the fly.

I doesn't have PERFECT support for DS Download Play ... even some games on SLOT-2 adapters work with DS Download Play (in fact, the compatibility is around the same). However the patchers aren't game specific, therefore they accidentally patch the binary the games sends and breaks it's RSA encryption.

DS-Xtreme patches in a different way, so some games that work with Download Play on other adapters, don't work on it, but some games that don't work elsewhere work.

 

[openchip]

It says YES in no$gba but completely crashes DeSmuME

Try older version of DeSmuME on my machine 0.5.0 exe distribution crashes with most stuff

 

[openchip]

It says YES in no$gba but completely crashes DeSmuME

Perhaps it says YES partly because it runs encrypted roms (I would think).

You have a point about the protection Costello, which brings me to the point that we're not exactly running the "cleanest" dumps - the encryption check (or whatever you call it) is simply being bypassed/emulated/whatever by the carts themselves, just the same as the nopass devices do. This is a necessity seeing as the dumps everyone is using have a decrypted secure area (part of the reason why the earlier passmes - before the decryption routine was figured out - required an original game). I have no idea if this has any bearing on the results of this little app though, I'm just guessing. More information on the inner workings of this little piece of homebrew would indeed be welcome

As soon as roms with encrypted secure areas can be run (if this is possible) without on-the-fly patching, then we'll be up to the level of GBA flash carts. Yes I am aware it is an unfair comparison from a technical standpoint, but that doesn't make it untrue

secure are or not doesnt matter.
it is easy to provide clean read of secure are as the card response time is long enough.
the main are read is what is complicated.

the utility does not check secure area acces at all. it only test main area normal read access.
that is it tests if the slot-1 card does return random block reads withing the ROM access time.
if it does, then no patched ROMs can work.
if it does not then anything that runs and works has been patched.
on the fly or not, it has to be patched.

 

[openchip]

I don't think that's quite right with acekard, because the roms are not altered at al, it just has a program to transfer them to the acekar file system.

Acekard patches as well. The fact that you do not see it doesnt make a difference.
Only cards with 128MB fast access non-volative memory (like NOR flash) could really run non-patched ROM's.
ASFAIK there are no such slot-1 devices on the market yet.

BTW Acekard is somewhat interesting, it uses an FPGA with no internal memory at all, and the Slot-1 protocol requires about 4KByte of unrolled blowfish key memory be available. So the design must be quite clever to overcome the shortcoming of the FPGA being used in acekard.

 

[openchip]

You can never have a flashcart that uses MicroSD cards that runs CLEAN ROMS without patching, unless a flashcart company builds a flashcart exactly like the official development cart every slot1 cart that claims to run CLEAN ROMS will require patching

Correct.
no patch play from sd-card is not possible.
no patch play from any NAND flash (from those known today) is not possible.

its not the sd-card protocol that makes the issue, sd-cards still use nand-flash technology and nand-flash just is to slow. thats it, there is nothing that can be done about it.

there are very choices today to make a true no-patch card
1) 128MByte NOR Flash on card. This is not feasible as of today, to large PCB and to expensive
2) SPI serial flash as ROM storage, largest chip is 8MByte, so we would need 16 memory chips!
3) 128MByte SDRAM + very fast preload from NAND flash
4) 128MByte SDRAM preloaded from NAND flash + 4Mbyte SPI flash for the first 4MByte

I am not sure if variant 3 is actually doable, ah actually it is, it has only to preload 4MByte in 150 milliseconds, the rest 128MByte can be loaded within longer time, so NAND flash could deliver the data fast enough

version 4 would work for sure.

it is technically doable.

 

[Bongloads]

Acekard patches as well. The fact that you do not see it doesnt make a difference.
Only cards with 128MB fast access non-volative memory (like NOR flash) could really run non-patched ROM's.
ASFAIK there are no such slot-1 devices on the market yet.

Well then, I guess we have our answer as to what a perfect Slot1 cart will have to be made of and/or contain, lol. Having 128MB of onboard memory on the cart sounds awful spendy and space-constrained, given that it would also accept Transflash or the like. But I have faith

 

[openchip]

Acekard patches as well. The fact that you do not see it doesnt make a difference.
Only cards with 128MB fast access non-volative memory (like NOR flash) could really run non-patched ROM's.
ASFAIK there are no such slot-1 devices on the market yet.

Well then, I guess we have our answer as to what a perfect Slot1 cart will have to be made of and/or contain, lol. Having 128MB of onboard memory on the cart sounds awful spendy and space-constrained, given that it would also accept Transflash or the like. But I have faith

Right, the slot-1 device would either required to have 12MByte fast non-volatile memory (that has to be programmed) or 128MByte RAM, preloaded fully from some media.

pre-loading 128MByte from micro-sd card requires at least 15 seconds, as the max burst transfer rate is 12.5MByte/seconds. So this much time must be elapsed before the game can be safely started (on slow cards more).

and default ROM auto-start from would really need additional on-board nand flash for fast preload.

when NDS starts the NDS firmware loads the ROM into NDS RAM during the healt-check, so first 4MBytes must be availabe at that time (there is not time to pre-load that from sd-card).

a solution with 128MB RAM and sd-card (no nand flash) is possible, but it cant autostart default game, and it has to preload the NDS RAM from sd card (the way current slot-1 device do) and then preload the full rom into RAM before starting game. this time could be in minutes with slower micro-sd cards.

 

[Jeda]

If slot 1 requires a response time of 4ms, and the card knows it can't provide the data in that time, and reacts by returning something random, how can any game work at all? With getting random data all the time?

 

[openchip]

If slot 1 requires a response time of 4ms, and the card knows it can't provide the data in that time, and reacts by returning something random, how can any game work at all? With getting random data all the time?

not 4ms (ms=milli second) but 4 microseconds!

ALL games are running in "patched" mode and their rom access routines are redirected. this is how they work.

 

[quartercast]

What sort of memory do commercial carts use?

 

[openchip]

What sort of memory do commercial carts use?

custom roms: eg small ASIC + ROM in same package

 

[Jeda]

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?!?

 

[cory1492]

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.

 

[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?!?

actually what matters is some 8 microseconds.
NAND can deliver in 12 us, so that would be enough. 4 us is too little.

no, the card is not returning garbage because it is not accessed the using the native command 0xB7. the slot-1 loader loads the first chunk into NDS and then pathces the RAM to use slot-1 vendor defined commands for card access (other than 0xB7). the newly patched read routine uses 2 commands, one to check if slot-1 is ready to transfer data and other to actually get the data.

if the ROM is not patched, or patched incorrectly it would read garbage and crash.

 

[cory1492]

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).

 

[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.

Thanks, yes actually the barries is not 128MB, but the size of largest released original game of course

I assumed that this is currently 128MByte, but I am not an expert here. Maybe there are larger ROMs already out.

And yes, the random (native 0xB7) read would defenetly work in official cart.
And it would also work in any slot-1 device if programmed to replace the slot-1 firmware.

Slot-1 firmware is 100% ROM compatible, or it would not load

I mean all slot-1 devices are "clean" as long as the firmware loads. Everything above that uses patching. The slot-1 flash card firmware is loaded with normal commands before the health check screen. As soon as the firmware/loader start the card is no longer access with 0xB7 native command that requires 4us response but with some slot-1 flash card vendor defined "custom commands".

 

[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).

Thanks for posting your results. They are correct - its my fault, I should have instructions that the test utility only test correctly if it is loaded loaded itself from slot-1.

If you started it from slot-2 and had original ROM in slot-2 then it will read correct rom ID from slot-1: C2 0F 00 00, this means that command 0xB8 works. The slot-1 native read command 0xB7 also works correctly but because the test utility is not in the slot-1 it will read back not a block of itself but some block from the card that is in slot-1, so it would say NO as result.

I was in a rush, so I have not added additional checks to the utility, it should check if it is run from slot-2 and report correctly.

thank you again for commenting on this, I can now add more checks to the tool.
unfortunatly I have no slot-2 devices, so i cant directly check.