4dsdev
Views: 1,383,837 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 03-28-24 05:55 PM
Guest:

0 users reading NTR chipid bit 31 questions | 2 bots

Main - Reverse-engineering - NTR chipid bit 31 questions Hide post layouts | New reply


Kitlith
Posted on 11-03-16 04:10 AM Link | #1108
Looking on gbatek, this bit appears to only affect key1 commands when talking to a cartridge. However, in wooddumper, there's a change when reading the header -- reading the header in 0x200 byte chunks instead of 0x1000 byte chunks with a comment of "this is magic of wood goblins". Decrypt9WIP does not have this.

I'm working on a tool that uses a Powersaves device to attempt to at least dump the header of a NDS card, based on some c# code that Normmatt linked on IRC. It has this check based on that bit. I ended up getting the check wrong, and incorrectly applied the logic to dump in 0x200 byte chunks to a card that doesn't need it. What I got out was the same 0x200 bytes over and over. So, either gbatek is wrong, and I misimplemented, gbatek is right, and I misread, with the card that supports 0x1000 byte header reads not supporting multiple 0x200 byte header reads... or gbatek is right, and wooddumper is wrong.

nocash, do you know what's up here? Am I misreading/misinterpreting gbatek?

Does anyone else know what's up here?

____________________
/---------------------------------------------------------------------\
| There are 10 kinds of people~... Oh. You've heard this one already? |
\---------------------------------------------------------------------/

nocash
Posted on 11-04-16 05:17 AM Link | #1109
Bit31 should be mainly related to Secure Area (KEY1 commands), but possible that it does also affect the cart header...

For original NDS carts (without DSi features) it doesn't really matter since the NDS header is less than 200h bytes (it should be zeropadded to 1000h bytes, but there's no official code (from Nintendo) for reading that much of header data for NDS carts).

What I am doing for reading both NDS and DSi cart headers is always setting ROMCTRL to AC3F1FFFh (=read 1000h bytes at once).
From what I remember, that setting was required for some NDS cart headers (eg. for Tony Hawk's Sk8land). And I've also used it for dumping two DSi titles (System Flaw and Cooking Coach, one of them having Bit31 set, the other doesn't).
So I guess the 1000h-byte read mode should work for ALL cart headers, no matter if Bit31 is set, and no matter if it's a NDS or DSi title.

Kitlith
Posted on 11-04-16 05:26 AM (rev. 4 of 11-05-16 04:45 AM) Link | #1110
Posted by nocash
Bit31 should be mainly related to Secure Area (KEY1 commands), but possible that it does also affect the cart header...

For original NDS carts (without DSi features) it doesn't really matter since the NDS header is less than 200h bytes (it should be zeropadded to 1000h bytes, but there's no official code (from Nintendo) for reading that much of header data for NDS carts).

What I am doing for reading both NDS and DSi cart headers is always setting ROMCTRL to AC3F1FFFh (=read 1000h bytes at once).
From what I remember, that setting was required for some NDS cart headers (eg. for Tony Hawk's Sk8land). And I've also used it for dumping two DSi titles (System Flaw and Cooking Coach, one of them having Bit31 set, the other doesn't).
So I guess the 1000h-byte read mode should work for ALL cart headers, no matter if Bit31 is set, and no matter if it's a NDS or DSi title.

Thank you, nocash!

I'm currently preforming a 0x4000 byte read (mainly because I'm thinking about ntrcardhax) and it is repeating as it says it should on gbatek. So I guess that answers my questions. That leaves the question though -- why does wooddumper do segments of 0x200 bytes? I don't know.

EDIT: It's possible that it comes from somewhere around here: http://www.kodewerx.org/forum/viewtopic.php?f=11&t=3971&p=78159&hilit=gbatek#p78159

It mentions that "SlowROM" cards have a maximum read limit of 512 bytes, or 0x200 bytes. I can only assume that that is for encrypted data reads, and not for unencrypted header reads? *shrugs* (I going to assume that the inacuracies that were mentioned there have already been fixed, given that what they're saying seems to match what I'm reading)

I think I'm going to put this up on github soon, given that my main goal has been accomplished: reading the header of a 'cartridge'. From there, more can be implemented, and I will probably continue to work on it, but it's not like we really need another dumping tool.

EDIT AGAIN: https://github.com/kitling/powerslaves
There is some noticably... 'off' code. I'm preparing to add options for different behaviors, because the DS, DSi, and 3DS all act slightly differently. And some things take note of that... (https://hackmii.com/2010/02/lawsuit-coming-in-3-2-1/ *cough datel cough*)

____________________
/---------------------------------------------------------------------\
| There are 10 kinds of people~... Oh. You've heard this one already? |
\---------------------------------------------------------------------/


Main - Reverse-engineering - NTR chipid bit 31 questions Hide post layouts | New reply

Page rendered in 0.030 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 69/69, time: 0.012 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.