# NDS Slot-1 Clean ROM no-patch Tester



## zatelli (Jan 20, 2007)

*NDS Slot-1 Clean ROM no-patch Tester*

on the fly patching? Find out.








An application developped by programmer openchip has been floating around lately. It supposedly helps you find out whether your slot-1 flashkit truly supports clean roms or at the contrary patches the clean rom on the fly without you noticing. We have tested this application on various flashcards using formatted microSD & latest loader for every flashkit we tested  & the results aren't encouraging:
SC DS: Clean ROM no-patch play:NO
DS-X  : Clean ROM no-patch play:NO
EZ- V: Clean ROM no-patch play:NO
X9 TF: Clean ROM no-patch play:NO
Acekard: Clean ROM no-patch play:NO
R4: Clean ROM no-patch play:NO
M3 DS Simply: Clean ROM no-patch play:NO



			
				openchip said:
			
		

> If this tool reports that Clean ROM no-patch play is not supported, then the NDS Slot-1 device cant really directly play any NDS ROM's. The ROM's can not access the Card using their own native access routines, those some sort of ROM or firmware patching is taking place before the ROM's are actually started.





Give this little application a shot & discuss your results.




Homepage




Clean ROM no-patch Tester ver 1.0


----------



## shadowboy (Jan 20, 2007)

Well...  Its just supercard, right?  Hopefully g6 simply and the other ones are clean, otherwise I may keep slot 2.


----------



## tjas (Jan 20, 2007)

I think only the slot 1 solutions with internal memory such as the ds-x will have 100% clean roms... everything with memory cards wil have patched roms...


----------



## H8TR (Jan 20, 2007)

M3 DS Simply and R4 got a No. So they don't work with all roms. Just most of them.


QUOTE(tjas @ Jan 19 2007 said:


> I think only the slot 1 solutions with internal memory such as the ds-x will have 100% clean roms... everything with memory cards wil have patched roms...


I don't think that is true. I believe that this program test the chip, processor or whatever is in the flash cart. Not the flash memory or NAND solid state memory. Clean or not, as long as the rom works, via drag and drop like in the R4DS and M3DSS, I don't really care what this program says.


----------



## Dirtie (Jan 20, 2007)

This reveals a lot - it's something I've wanted to know since the first slot-1 carts were released, now I have my answer.

It seems DS carts still aren't quite up there when compared with GBA ones 
	

	
	
		
		

		
		
	


	




 (in this respect)


----------



## peepoop (Jan 20, 2007)

QUOTE(H8TR @ Jan 19 2007 said:


> Clean or not, as long as the rom works, via drag and drop like in the R4DS and M3DSS, I don't really care what this program says.



Totally.  If I can just drag and drop a clean rom onto my slot 1 card, that's clean enough for me.  If the flashcart wants to do its own internal patching behind the scenes to make it work, who really cares?  As long as I don't have to patch it, cool.


----------



## fischju_original (Jan 20, 2007)

the problem is the nature of patching; because this is true, slot-1s will have less compatibility with future games without needing an update


----------



## 111111111 (Jan 20, 2007)

I think the point is, that if a cart does on-the-fly patching it requires constant updates whenever a game comes out that works differently (and we all know that nintendo do this quite often).

If the company that makes your flashcart suddenly stops supporting their hardware then you no longer have a cart you can just drag/drop with - but one that you manually have to patch every game you play.

atm, otf-patching seems to be the only/best solution.


----------



## Little (Jan 20, 2007)

Well, I'm guessing the point here is that as long as they games have some form of external influence on them, they will never have full compatibility and  never run at full speed etc. If a slot-1 cart truly 100% runs without patching, then full compatibility is achieved as its just like having the real cart. In theory, if you're running completely clean roms with no patching, you'd never need a firm ware update etc.


----------



## Katalyst (Jan 20, 2007)

Guess this explains how R4 was able to implement soft-reset without the need of patching a rom.


----------



## Destructobot (Jan 20, 2007)

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.


----------



## adgloride (Jan 20, 2007)

The slot 1 cards will have to patch on the fly so you can read from the MicroSD card.  It looks like we'll all have to rely on constant firmware updates though


----------



## zone97 (Jan 20, 2007)

Guys... we should all be thankfull that we have the level of compatability and playablity that we have.. as it stands as a whole we have about 98% perfection. Thats good enough for me, Im not overly greedy.


----------



## rice151 (Jan 20, 2007)

So, the above mentioned flashkits report NO Clean-Roms, which would make sense as none of them have perfect DS Download Play compatibility...


----------



## Destructobot (Jan 20, 2007)

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.


----------



## Normmatt (Jan 20, 2007)

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


----------



## Costello (Jan 20, 2007)

QUOTE(Dirtie @ Jan 20 2007 said:


> This reveals a lot - it's something I've wanted to know since the first slot-1 carts were released, now I have my answer.
> 
> It seems DS carts still aren't quite up there when compared with GBA ones
> 
> ...



I disagree. The DS is different hardware, it is protected! Roms need to be patched in order to work. The GBA wasn't protected like that.
You can't really compare anyway, the systems are too different.

And yeah I wouldn't take these results seriously until we know what this program actually does.
As far as we know, this app could just be a program that says "Clean ROM no-patch play: NO".
We at least need to find one for which the program says "YES" ... maybe emulators?


----------



## Normmatt (Jan 20, 2007)

It says YES in no$gba but completely crashes DeSmuME


----------



## corbs132 (Jan 20, 2007)

how are the load times on these cards compared to patching cards?


----------



## Dirtie (Jan 20, 2007)

QUOTE(Normmatt @ Jan 20 2007 said:


> 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*


----------



## OSW (Jan 20, 2007)

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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(destructobot @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(destructobot @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(Normmatt @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(Dirtie @ Jan 20 2007 said:


> QUOTE(Normmatt @ Jan 20 2007 said:
> 
> 
> > It says YES in no$gba but completely crashes DeSmuME
> ...


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 (Jan 20, 2007)

QUOTE(OSW @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(Normmatt @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(openchip @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(Bongloads @ Jan 20 2007 said:


> QUOTE(openchip @ Jan 20 2007 said:
> 
> 
> > Acekard patches as well. The fact that you do not see it doesnt make a difference.
> ...


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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(Jeda @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

What sort of memory do commercial carts use?


----------



## openchip (Jan 20, 2007)

QUOTE(quartercast @ Jan 20 2007 said:


> What sort of memory do commercial carts use?


custom roms: eg small ASIC + ROM in same package


----------



## Jeda (Jan 20, 2007)

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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(Jeda @ Jan 20 2007 said:


> who cares for some odd 3 orders of magnitude
> 
> 
> 
> ...


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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


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


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.


----------



## openchip (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


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


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 (Jan 20, 2007)

QUOTE(Normmatt @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(openchip @ Jan 20 2007 said:


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


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 (Jan 20, 2007)

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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(noda @ Jan 20 2007 said:


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



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 (Jan 20, 2007)

QUOTE(Jeda @ Jan 20 2007 said:


> who cares for some odd 3 orders of magnitude
> 
> 
> 
> ...


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 (Jan 20, 2007)

Wow this thread has been really interesting and informative  
	

	
	
		
		

		
		
	


	



Thank you to openchip and all the contributors so far!



QUOTE(noda @ Jan 20 2007 said:


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



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


----------



## openchip (Jan 20, 2007)

QUOTE(MaHe @ Jan 20 2007 said:


> Oh, my dream SLOT-1 solution:
> 
> - a microSD adapter
> - 128 MB of SDRAM where the game is loaded
> ...


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 (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

QUOTE(noda @ Jan 20 2007 said:


> QUOTE(cory1492 @ Jan 20 2007 said:
> 
> 
> > openchip: Why do you insist 128MB is the barrier? The addressing can support up to 4Gbit.
> ...


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 (Jan 20, 2007)

QUOTE(openchip @ Jan 20 2007 said:


> QUOTE(noda @ Jan 20 2007 said:
> 
> 
> > QUOTE(cory1492 @ Jan 20 2007 said:
> ...


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 (Jan 20, 2007)

QUOTE(enarky @ Jan 20 2007 said:


> QUOTE(openchip @ Jan 20 2007 said:
> 
> 
> > QUOTE(noda @ Jan 20 2007 said:
> ...



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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


> 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 (Jan 20, 2007)

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 (Jan 20, 2007)

QUOTE(cory1492 @ Jan 20 2007 said:


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



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 (Jan 20, 2007)

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 (Jan 20, 2007)

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 (Jan 20, 2007)

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.


----------



## gbasho (Jan 21, 2007)

just wanted to say that i enjoy this thread.
that is all.


----------



## openchip (Jan 21, 2007)

QUOTE(t0m1th3 @ Jan 20 2007 said:


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



I am getting too old. I assumed 1GBit NOR Flash is out of the question still, but I was wrong. Excuse my previous comment that NOR Flash is not feasible for the card design.

My last design where I used parallel flash was true clean room implementation of FilmNet digitial sound decoder back many years. The design used Z80, 13 GAL's (was cheaper than XC2018 back then),  2KB SRAM for CPU, 8 KB SRAM for sound samples, and 27C256 (32KByte EEPROM, largest obtainable non volatile memory at that time!) for Z80 software and for digital transmittion hamming code correction.

This was the last time I designed in any parallel flash. But some time has pasted, and Spansion announced 1GBit NOR in 2005, Intel has similar announcement. And I hadnt paid attention to those technical news yet. So 1GBit NOR Flash is also defenetly an feasibly option.


----------



## cory1492 (Jan 21, 2007)

QUOTE(openchip @ Jan 20 2007 said:


> 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


So your 1.1 header comparison just checks the header that is in memory, correct? (I know reset did not change the header in memory in my tests, which had essentially the homebrew's header in it).

You still don't catch my point though. At least with EZ5, they have to do something special to allow uncorrupted data to be accessed from the TF card after booting homebrew, if the gamecode is not correct than I am assuming all data coming from the EZ5 will be corrupted.

Some 1.1 results: 
header patched? / ID / no-patch play / test data

From EZ4 (renamed to .bin for EZ4 to use PSRAM to load)
EZ5: no /00A0FFFF/ NO / FFFFFFFF FFFFFFFF
MK4-Mini: no / EEB7E4ED / NO / 3FB82405 FA6BE515
DSLink: no / 2E0000EA / NO / FFFFFFFF FFFFFFFF
Madden 2005: no / 3C21CCE8 / NO / E621FDA1 E01B3C6F
these results were identical when run from a different flashcart than EZ4, ds.gba version and .nds version both booted without a problem.

Run from:
EZ5: yes / none /* YES */ 020275D58 00000000  (successive runs returned same test data)
DSLink: yes / 0068FFFF / NO / FFFFFFFF FFFFFFFF

Not sure why the results are so different from the previous one's, nor why the EZ has no patch play... perhaps it goes back to the thing I was talking about with the header? Here, I'll patch the homebrew to have gamecode PASS like EZ5 expects for homebrew and see what happens when I run it again...

EZ5: yes / none / NO / E2011102 E0900FA3 (successive runs returned same test data)

I hope I illustrated my point there... EZ5 uses a special gamecode to detect homebrew which would use the FAT lib, and returned different results, including a NO for no-patch play. EZ5 uses a simple (and incorrect in my opinion) method of detecting homebrew... most likely the other cards use a method similar to ndstool's check for multiboot/homebrew/commercial.
aka: if it's built like a homebrew ROM breaking many of the rules of commercial ROM's, and has homebrew identifiers in the header, the cards are going to treat it differently unless they are extremely unintelligent in their detection method. It's either that... or you made an error in the program update?

edit:/ what is the correct test data supposed to be anyway?


----------



## DavePS (Jan 21, 2007)

Anyone tried runningthis program against a REAL game cartridge? I'd be interested to see if it says they are patched as well!


----------



## cory1492 (Jan 21, 2007)

Uhmm, read my post a little more carefully - I tested from an EZ4 against real carts that were not used as the bootup medium. What you are asking is _technically_ impossible though, since we don't have any method to make a real DS cart with this app on it to confirm it's operation is 100% correct.


----------



## openchip (Jan 22, 2007)

QUOTE(cory1492 @ Jan 22 2007 said:


> QUOTE(openchip @ Jan 20 2007 said:
> 
> 
> > sure, your testing was correct.
> ...


hi cory.

thanks a lot for testing - the results are interesting 
	

	
	
		
		

		
		
	


	



well first thing I need to add - the testing when the ROMTester.nds is _not_ loaded from the slot-1 device are rather pointles, the utility does not check if card in slot-1 at time of testing is ok, and looks like real rom, it only checks if it can read _itself_ from slot-1, if it ROMTester.nds itself was not originally on slot-1, then it can not read itself from slot-1 obviously so the test should fail. Of course should some slot-2 system patch succesfully the ROMTester.nds _then_ it would report YES also when run from slot-2.

Now more details on ver 1.1
The based check is the same, a simple raw read to slot-1 using native command 0xB7
additionally is added check if header is patched, I dont know why it should be, but as example microninjads does patch the header
additional check for emulators (detects most except no$gba)
additional check if there is RAM in GBA slot
if either emulator or GBA card detected additional warning is displayed - it basically says that results are more-or less meaningless.
changed, if ROM id is correct/default (C2 0F 00 00) no print, only when something else is read the ID read is displayed.

Now what is really interesting is the fact that EZ5 does say YES and returns valid data.
So either EZ5 looks 100% like real ROM from hardware point of view, or it was able to patch ROMTester.NDS

cory - I think I understand the things, no-patch detect result will be yes only if either ROM _is_ 100% compatible or my test is patched. And clean ROMs can only play if 100% true hardware or properly patched. The header patch detect is just additional goodie.

It is very interesting both ways


----------



## openchip (Jan 22, 2007)

QUOTE(cory1492 @ Jan 22 2007 said:


> Uhmm, read my post a little more carefully - I tested from an EZ4 against real carts that were not used as the bootup medium. What you are asking is _technically_ impossible though, since we don't have any method to make a real DS cart with this app on it to confirm it's operation is 100% correct.


be careful what you say about technically impossible!

first during card initial start the on-board firmware is started in clean rom mode, so placing ROMtester in place of slot-1 boot firmware would yield in YES result.

second I do have card(s) where I can place ROMtester to be boot-firmware, and I can also make slot-1 clean emulator (it would not fit the slot-1 though at the moment)


----------



## cory1492 (Jan 22, 2007)

I'd still like to know, does the header compare with what is in the DS memory (secure area/header copied to memory) or... ? I'm only trying to understand if there is a possibility of false YES/NO. Also, was there a change to romID? It worked fine in 1.0 from EZ4...



QUOTE(openchip @ Jan 21 2007 said:


> be careful what you say about technically impossible!
> 
> first during card initial start the on-board firmware is started in clean rom mode, so placing ROMtester in place of slot-1 boot firmware would yield in YES result.
> 
> second I do have card(s) where I can place ROMtester to be boot-firmware, and I can also make slot-1 clean emulator (it would not fit the slot-1 though at the moment)


It _is_ technically impossible to make this program onto a _REAL_ game card; at least, not without the help of Nintendo. Both solutions you have available, while interesting, would not produce a REAL game card, only plausibly good fake ones  
	

	
	
		
		

		
		
	


	







 It is a technicality.


----------



## openchip (Jan 22, 2007)

QUOTE(cory1492 @ Jan 22 2007 said:


> I'd still like to know, does the header compare with what is in the DS memory (secure area/header copied to memory) or... ? I'm only trying to understand if there is a possibility of false YES/NO. Also, was there a change to romID? It worked fine in 1.0 from EZ4...
> 
> 
> 
> ...








 ok yes, it is only possible to make a clone that has exact same behaviour as the real one. This _is_ possible.

and yes the ID read check changed from ver 1.0, the later version(s) use more strict correct procedure. On real thing the later revisions should still give proper ID read.

hm did you check version 1.2 ? It is downloadable (even if there is no link right now) ver 1.2 prints out "flags" that are left in the card register when the ROMtester is launched. Version 1.0 used hardcoded values (wrong approuch).


ROMTester doesnt currently do any attempts to reset the slot-1 as to my knowledge many slot-1 flash cards do not wakeup properly after slot-1 reset. The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.

If there slot-1 card has been identified as been seen slot-1 reset (eg responds to mode 1 card ID) then it would be possible to read the header from the card, but again it would be header of the card in slot-1, and it would not match the header in ROMtester anyway.


----------



## openchip (Jan 22, 2007)

Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.

http://nds.truedream.org
http://nds.truedream.org/ROMTester_1_2.nds


----------



## cory1492 (Jan 22, 2007)

1.2 results when run from the EZ5:
Initial flags: 21587F00
Game header is patched!
Header CRC: B671

Arm9 CRC: 362E
Clean ROM no-patch play: YES
Test data: 65722072 6E727574 (concurrent runs produced same data)

From EZ4 with EZ5 in NDS slot (useless, but I figured you'd like to know the results)
Initial Flags: 20000000
Bad/Unknown ROM ID: 0020FFFF
?
Arm9 CRC: 362E
Clean ROM no-patch play: NO
Test data: FFFFFFFF FFFFFFFF


----------



## cory1492 (Jan 23, 2007)

QUOTE(openchip @ Jan 22 2007 said:


> The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.


Is it possible their loading method does not require the _entire_ game header to be replaced in memory (thus only appearing patched)?


----------



## openchip (Jan 24, 2007)

QUOTE(cory1492 @ Jan 23 2007 said:


> QUOTE(openchip @ Jan 22 2007 said:
> 
> 
> > The header patch only checks the header copy in RAM, to my knowledge there is no real reason why it should be pathced, but at least 2 slot-1 devices seem to patch the header area as well.
> > Is it possible their loading method does not require the _entire_ game header to be replaced in memory (thus only appearing patched)?



one more thing about EZ-V, it does use ROM read command 0xB7 as read SRAM (1MByte) so if the ROM was loaded to SRAM then EZ-V should give valid response if sensed within first megabyte of the ROM content.


----------



## cory1492 (Jan 25, 2007)

Would 1MB be enough data to deal with the random commands you mention in commercial ROM's? It would explain the long initialize time before a game loads... if the data had to be copied to 2 places instead of just into memory. (AFAIK the 8Mbit SRAM is used strictly for saver data)

EZ5's kernel itself runs like homebrew and accesses the SD card. Unfortunately they ripped the code from the source that calls "cleanROM mode" and it will not launch .nds files at all (though it probably wouldn't be that tough to isolate with a compare between the source kernel and the official kernel).

I'm assuming in homebrew mode, _all_ the commands do something different than in clean ROM or hybrid mode... could be wrong on that though.


----------



## ralff (Jan 25, 2007)

QUOTE(openchip @ Jan 22 2007 said:


> Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.
> 
> http://nds.truedream.org
> http://nds.truedream.org/ROMTester_1_2.nds




Ok, here are my results using version 1.2:


UFP512:  2118000 - 362E - Yes - 65722072 6E727574
AceKard: reported as Emulator !
NinjaDS Sticky: 21406000 - Patched Header 1FEF - 362E - No - E3A05301 E1A01421
DSLink: unknown ROM ID - Patched Header AFA4 - 362E - No - FFFFFFFF FFFFFFFF
DSOne: 27180000 - Patch Header 1427 - 362E - No - D0044213 42A66803
EZV: 21587F00 - Patched Header B671 - 362E - Yes - 65722072 6E727574
X9: no able to start ! randomly hung or boot Slot 2 !
R4DS: 21586000 - 362E - No - 46C04718 46C0B5F8
DSX: unknown ROM ID - Patched Header 6B85 - 362E - No - AC45FE39 F5B2ADF5

Ralf


----------



## openchip (Jan 25, 2007)

QUOTE(ralff @ Jan 25 2007 said:


> QUOTE(openchip @ Jan 22 2007 said:
> 
> 
> > Version 1.2 now available - sorry it was online and then it wasnt as the server admin tool trashed the domain root for me as firendly service.
> ...



emulator check is
1) check if writeable memory in GBA slot
2) initial values of slot hardware ownership (only good in no$gba, wrong in others) - its not so accurate, and it seems I am not masking the bits correctly, still it should be standard setting if roms are normally started (eg slot hw ownership is ARM7 by defualt)

the UFP seems interesting - the flags setting is 0 init latency, and NO KEY2 encryption. same with DSOne, no KEY2 encryption.

I will have some more advanced tool soon ready..


----------



## openchip (Jan 25, 2007)

QUOTE(cory1492 @ Jan 25 2007 said:


> Would 1MB be enough data to deal with the random commands you mention in commercial ROM's? It would explain the long initialize time before a game loads... if the data had to be copied to 2 places instead of just into memory. (AFAIK the 8Mbit SRAM is used strictly for saver data)
> 
> EZ5's kernel itself runs like homebrew and accesses the SD card. Unfortunately they ripped the code from the source that calls "cleanROM mode" and it will not launch .nds files at all (though it probably wouldn't be that tough to isolate with a compare between the source kernel and the official kernel).
> 
> I'm assuming in homebrew mode, _all_ the commands do something different than in clean ROM or hybrid mode... could be wrong on that though.


no, the 1MByte is not sufficient. Any ROM loaded may immediatly request and block for reads anywhere in the ROM space, and the slot-1 device has about 4 microseconds to deliver that sector. unless the NDS slot-1 hw latency setting has changed, in which case (it this is possible) there is more time to respond (but still not enough time to fetch sector from SD card).


----------



## ralff (Jan 25, 2007)

QUOTE(openchip @ Jan 25 2007 said:


> emulator check is
> 1) check if writeable memory in GBA slot
> 2) initial values of slot hardware ownership (only good in no$gba, wrong in others) - its not so accurate, and it seems I am not masking the bits correctly, still it should be standard setting if roms are normally started (eg slot hw ownership is ARM7 by defualt)
> 
> ...




Oh, sorry
Every test ( exception is UFP512 ) was done using an original NDS Lite ( UEH1134xxxx ) with an EZFlash IV Lite Deluxe inside Slot-2.
I'll remove it on further tests.
The UFP512 is NOT available to run in my new NDSL ( but still runs using my older orginal Lite ( UEF1099xxxx ) or my Phat ) so the test was run on both older devices.
The initial flags are: 21180000 not 2118000.

AceKard without Slot 2 Card:

BAD EXMEMCNT initval. Emulator ?
initial Flags: 29406300
ARM9 CRC: 362E
Either emulator or Slot-2,
results likely meaningless!
Clean ROM no-patch play: YES
Test data: 65722072 6E727574

Ralf


----------



## openchip (Jan 25, 2007)

QUOTE(ralff @ Jan 25 2007 said:


> QUOTE(openchip @ Jan 25 2007 said:
> 
> 
> > emulator check is
> ...



things are getting eve more interesting 
	

	
	
		
		

		
		
	


	




sure all cases during test slot-2 should be EMPTY, the test doesnt stop but can issue warning.

the emu test that is incorrect on acekard, well am checking for the CR_WAIT register to have known standard value
(not masking off the slot ownership bits) so it may be less accurate, but again the slot-1 device has no reasons to 
leave this register in non-default state before running the loaded ROM.

question, why doesnt the UFP run on new NDSL? its a slot-1 flash card so should work? (or you meant you are unable to test)
haa acekard seems to the ony one that uses slower slot-1 clock rate

I will work on update tonight


----------



## ralff (Jan 25, 2007)

QUOTE(openchip @ Jan 25 2007 said:


> things are getting eve more interesting
> 
> 
> 
> ...



Slot-2 is EMPTY :-)

The new NDSL hungs during boot the UFP every time. I don't know why....

Ralf

EDIT: I've dumped the firmware of the two DS Lite. They are different. I think Nintendo has modified something to exclude the UFP.


----------



## openchip (Jan 27, 2007)

Hi,

the new update to romtester is delaying a bit, but it will have more advance features i hope. In the meanwhile I can only confirm that I have witnessed at least 2 slot-1 devices really do the patching thing:

R4DS - ARM9 code IS patched before execution
ninjaDS  - ARM9 code IS patched before execution
(if contains known signature)

I made a small utility that converts NDS compiled as homebrew into "game rom like" one, by moving the arm9,arm7 above 0x8000 and cleaning up the header, then I appended a copy of arm9 code from commercial game to the romtester code (and extended the arm9 size). After this the CRC check of itself displays ARM9 code being manipulated before execution.

I cant publish this NDS (as it does contain the code of game rom), and I cant yet publish the utility (it includes support for LPT port interface with 11 resistors to read slot-1 cards with homebrew adapter), but I hope to have "publishable" version soon.

I am still very interested in more testing with "linker" and nand-flash cards (eg slot-1 devices that boot from internal memory not sd-card), please PM if interested in early testing utility.


----------



## ralff (Jan 27, 2007)

Another result for the 1.2 version:

MicroNinja ( just received ) : White Screen :-(

Bye,

Ralf


----------



## openchip (Jan 27, 2007)

QUOTE(ralff @ Jan 27 2007 said:


> Another result for the 1.2 version:
> 
> MicroNinja ( just received ) : White Screen :-(
> 
> ...



check your microninja, shoudl defenetly have no white screen, works ok here.

ah just got another patch test results, to big surprise both tested devices R4DS and microninja
say that they patched equal size of words (5997) at same first and last patched word adresses
with a little different number of non-0 patched words (131 vs 134)
and both display same CRC16 (with BIOS function), 
but different checksum if using non-bios checksum method.


----------



## ralff (Jan 27, 2007)

QUOTE(openchip @ Jan 27 2007 said:


> ...
> check your microninja, shoudl defenetly have no white screen, works ok here.



Ok, suddenly it works fine ...

Ralf


----------



## cory1492 (Jan 28, 2007)

QUOTE(openchip @ Jan 27 2007 said:


> I made a small utility that converts NDS compiled as homebrew into "game rom like" one, by moving the arm9,arm7 above 0x8000 and cleaning up the header, then I appended a copy of arm9 code from commercial game to the romtester code (and extended the arm9 size). After this the CRC check of itself displays ARM9 code being manipulated before execution.
> Now that sounds like a much more reliable test
> 
> 
> ...


It is possible to boot any program from NOR in place of the homebrew moonshell bootloader on EZ5, just let me know if you want me to try it (requires specific file name "ez5upldr.bin" and specific gamecode (-g "APRE" "01" "EZ5NDS_LDR")). I haven't experimented with replacing the full bootstrap (yet), but it is quite possible that could be done too.


----------



## openchip (Jan 28, 2007)

QUOTE(cory1492 @ Jan 28 2007 said:


> QUOTE(openchip @ Jan 27 2007 said:
> 
> 
> > I made a small utility that converts NDS compiled as homebrew into "game rom like" one, by moving the arm9,arm7 above 0x8000 and cleaning up the header, then I appended a copy of arm9 code from commercial game to the romtester code (and extended the arm9 size). After this the CRC check of itself displays ARM9 code being manipulated before execution.
> ...


Hi

last test was not testing "is clean possible" but "is ARM9 patched", and the resuts are so far that the ARM9 binary is defenetly being patched on the fly. I will release more info soon

a


----------



## openchip (Jan 28, 2007)

QUOTE said:
			
		

> Hi
> 
> last test was not testing "is clean possible" but "is ARM9 patched", and the resuts are so far that the ARM9 binary is defenetly being patched on the fly. I will release more info soon
> 
> a



uuups - my bad, I had appended 2 copies (that I compared to each other) directly after romtester code.
the first image overlapped the compiler work are, thos appeared as patched.

so for the moment only additional test results are that r4ds,microninja say no clean, when NDS is romlike (not homebrew like) thats all. no direct witness of anything actually being patched in RAM

sorry


----------



## cory1492 (Jan 28, 2007)

Have you got a card emulation done up well enough that you can test your app  when it is run like a normal DS card? That was my thought with looking into the NOR on EZ5...


----------



## RENI (Jan 29, 2007)

A friend of mine has an N-Card.And here's the result:


			
				QUOTE said:
			
		

> Initial Flags: 27180000
> ARM9 CRC: 362E
> Clean ROM no-patch play: NO
> Test data: FFFFFFFF FFFFFFFF


----------



## pelago (Feb 4, 2007)

It's nice to read such an intelligent technical thread. Just one question to openchip - are you willing to publish the source code?


----------



## Kyuzumaki (Feb 4, 2007)

How do we know the software works?? Has the maker released any info on how he is checking for patching?


----------



## Monkey01 (Feb 4, 2007)

QUOTE(Kyuzumaki @ Feb 4 2007 said:


> How do we know the software works?? Has the maker released any info on how he is checking for patching?


If you care, then why don't you read the thread?


----------



## GBA_Temper (Apr 13, 2007)

*GBA-Temp_DS-Real Clean ROM no-patch play:YES


----------



## iamwhoiam (Apr 18, 2007)

Apparently, the G6 reports:

Clean ROM no-patch play:NO

http://www.scdev.org/forum/viewtopic.php?t=9772


----------



## Fieryshadowz (Apr 18, 2007)

is there a list of Slot 1 / 2 solutions that has clean rom no patching play?


----------



## iamwhoiam (Apr 19, 2007)

there is none that exists


----------

