Board index | NDS forum


 Back to the forum.

 NDS Header Problem?
 
Argument: ROM data , Reference: generic , Closed by: root
asapy @ 2010-01-08 13:42:30

According to the nfo of Der_Bauernhof_EUR_GERMAN_READNFO_NDS-BAHAMUT, almost of all the NDS dumps after DSi launch are bad.
Actually, checking the header, the rom has data in 0x330~0x38F and 0xF80~0xFFF which is usually filled with 00s.

I don't know if their dump is good. If it's right, we need to check more than 1000 games...
What do you guys think?
z.g @ 2010-01-08 15:06:38

Session Start: Sun Aug 30 14:20:38 2009
Session Ident: xuom2
[14:20] Session Ident: xuom2 (EFNet, zg)
[17:55] btw
[17:55] new games that produced starting july 2008
[17:55] must contain digital sign for code
[17:56] but i don see anything that may digital sign in dumps
[17:56] so may be we have about 1300 of bad dumps
[17:57] :\*/
[17:57] but it only speculation :)
kazumi213 @ 2010-01-08 16:58:13

I suggest trying sample redumps from things like Pokemon Pt (Nintendo) to probe how far we should mark as [b].

I don't understand why a dumping program is designed so it makes assumptions about data contents...
z.g @ 2010-01-08 17:23:30

games that has non-zero byte at 0x1b0 offset — has dsi specific data.
the another problem, that looks like some dumpers dont dump 0x200 of header, but only 0x160.
btw at 0x330~0x38F there are two sha-1 hashes of code. 1st: arm7+arm9+header+optionally banner. 2nd: overlay data. theoreticaly this can be reconstructed.
0xF80~0xFFF data looks like digital signature of header. and this can be reconstructed only if we know nintendo private key.
xuom2 @ 2010-01-08 19:53:34

please note my competent reply :P :P
Tori @ 2010-01-08 19:59:42

Not really related, but now that PEGI logos have changed (they have colours, now : green for 3 and 7, orange for 12 and 16, and red for 18), some old titles have new boxarts (with the new PEGI logos), and it's then impossible to know if the ROMs are identical or if it's a new Rev of the ROM...
I believe most of old games won't have new boxart, but I already saw new boxarts for old games (The Legend of Zelda: Phantom Hourglass, for example).

Tori.
z.g @ 2010-01-08 21:14:54

btw. if dump whole header, unique only 1st 0x1000 bytes. 0x1000-0x3fff contain mirror of this ones. we must also deside how store this.
kazumi213 @ 2010-01-08 23:26:43

Before proceeding, if possible I would like to know:

- are the missing bytes caused by limitation when using a NDS instead of a NDSi to read the card, or is it actually the current public dumping software just ignoring data in the range 0x200 - 0x3FFF?

- if the second one above, is there any technical reason that prevents reading that range?

Regarding standard NDS games, and by following z.g hint on the 0x1B0 offset value, I've noticed something about value at 0x1BF

- at some point between release 2300 and 2500, it changes from 0 to 40_h (this assumes that public dumpers so far were *at least* reading from 0x0 to 0x1FF)
- at some point between release 4000 and 4200, it changes from 40_h to 60_h (current value, used in Bahamut dump)

We can quickly check whether old public dumpers were reading 200_h in size by redumping some new title. Then focus on the 0 -> 40 or 40 -> 60 transition to determine whether they are indicators of missing data. Let's hope only the 40 -> 60 is (if any :( )
z.g @ 2010-01-09 00:24:48

- are the missing bytes caused by limitation when using a NDS instead of a NDSi to read the card

at least on ds lite missing bytes dumped successfully.

- or is it actually the current public dumping software just ignoring data in the range 0x200 - 0x3FFF?

at least rudolph tools read only 0x200 bytes of header. i think the reason the very simple — nds firmware reads only 0x200 bytes :)

- if the second one above, is there any technical reason that prevents reading that range?

no.