any question
i use r4 card and european version game, the problem isn't MoD but the language...
...the european is multi5 but me work only ENG lang (vs firmw of card is ENG?!?)
where is the method of setting and change lang?!? (es change offset...)
thx
i use r4 card and european version game, the problem isn't MoD but the language...
...the european is multi5 but me work only ENG lang (vs firmw of card is ENG?!?)
where is the method of setting and change lang?!? (es change offset...)
thx
I was not quite sure where to post it, so I'll post it here.
And before starting, cheers to cracker.
Some (wrong) things have been said about the "protection" Square-Enix (US) put in the US(/EU) FFCC games (like it was checking if the executables have been modified), so after an afternoon of researches here is the "truth" about it :
The protection is based on the ARM9 DMA3 source address, and not the game CRC.
While the game starts (NDS power on), it launches timer0, and then a bit later it reads its value. This 32-bits value is written to 0x020FB594. The game also checks the DMA3 source address's value (0ed or not 0ed ; the value should be 0ed on the real hardware, not 0ed if the game is run from some devices that don't clean up their mess).
After that the game makes 0x100 - (sum of 3 first bytes of timer0) (+0x80 if the DMA3 source address is 0ed), and writes that byte at 0x020FB597. So if the DMA3 source value is zeroed, the sum of all bytes at 0x020FB594~0x020FB597 ends with 0x80. If the DMA3 source address is not zeroed, it ends with 0x00.
Then, when going through some doors (like going back in the village after seing the mogs at the start of the game), the game verifies that the sum of the 4 bytes at 0x020FB594 ends with 0x80. If not (ie. if DMA3 source address was not zeroed), if checks since how much time the game has been powered on/reset. If that time is >18mn12seconds (ie. if the counter is >= 0x8000), it triggers the "MSoD" and resets. Note that the way the game checks the values at 0x020FB594~0x020FB597 looks weird because the timer0 value is used but not checked... So I guess it is used to "randomize" the 32-bits value at 0x020FB594.
And if you reset the game (Start+Select+L+R), the DMA3 value won't be zeroed for the real game anymore. So to avoid blocking the real game, upon resetting the game saves/restores the protection status value (enabled/disabled), and set a 'has been reset' flag. Then, when the game restarts, and after the DMA3 source has been checked, the game looks if the reset flag is set. If yes, it recomputes the value using the "original" (ie. upon start up) DMA3 source state (zeroed/not zeroed).
All of that means the real way to "manually patch" the game would be to make the game think the DMA3 source value is 0ed. That means for exemple changing the value at 0x020286FC (ram address) to 0x4280.
The patch/codes/devices firmwares upgrades that have been released just "kill" the counter that triggers the "MSoD". However, that counter is used for other in-game things (it is checked during FMVs for exemple, and it seems people report problem in shops), so it is definitly pretty dangerous to kill it. The real fix for the "devices" that get "blocked" would be to simply clear the DMA3 registers (actually clean anything they changed) before running the game...
And as AR codes are executed after the DMA3 source check is executed, killing that check is not possible with such codes.
So here is a code that will kill the protection (when you go through doors) :
Kill Protection
1202876A 0000429B
(that code also works for the EU game btw).
That's all.
And before starting, cheers to cracker.
Some (wrong) things have been said about the "protection" Square-Enix (US) put in the US(/EU) FFCC games (like it was checking if the executables have been modified), so after an afternoon of researches here is the "truth" about it :
The protection is based on the ARM9 DMA3 source address, and not the game CRC.
While the game starts (NDS power on), it launches timer0, and then a bit later it reads its value. This 32-bits value is written to 0x020FB594. The game also checks the DMA3 source address's value (0ed or not 0ed ; the value should be 0ed on the real hardware, not 0ed if the game is run from some devices that don't clean up their mess).
After that the game makes 0x100 - (sum of 3 first bytes of timer0) (+0x80 if the DMA3 source address is 0ed), and writes that byte at 0x020FB597. So if the DMA3 source value is zeroed, the sum of all bytes at 0x020FB594~0x020FB597 ends with 0x80. If the DMA3 source address is not zeroed, it ends with 0x00.
Then, when going through some doors (like going back in the village after seing the mogs at the start of the game), the game verifies that the sum of the 4 bytes at 0x020FB594 ends with 0x80. If not (ie. if DMA3 source address was not zeroed), if checks since how much time the game has been powered on/reset. If that time is >18mn12seconds (ie. if the counter is >= 0x8000), it triggers the "MSoD" and resets. Note that the way the game checks the values at 0x020FB594~0x020FB597 looks weird because the timer0 value is used but not checked... So I guess it is used to "randomize" the 32-bits value at 0x020FB594.
And if you reset the game (Start+Select+L+R), the DMA3 value won't be zeroed for the real game anymore. So to avoid blocking the real game, upon resetting the game saves/restores the protection status value (enabled/disabled), and set a 'has been reset' flag. Then, when the game restarts, and after the DMA3 source has been checked, the game looks if the reset flag is set. If yes, it recomputes the value using the "original" (ie. upon start up) DMA3 source state (zeroed/not zeroed).
All of that means the real way to "manually patch" the game would be to make the game think the DMA3 source value is 0ed. That means for exemple changing the value at 0x020286FC (ram address) to 0x4280.
The patch/codes/devices firmwares upgrades that have been released just "kill" the counter that triggers the "MSoD". However, that counter is used for other in-game things (it is checked during FMVs for exemple, and it seems people report problem in shops), so it is definitly pretty dangerous to kill it. The real fix for the "devices" that get "blocked" would be to simply clear the DMA3 registers (actually clean anything they changed) before running the game...
And as AR codes are executed after the DMA3 source check is executed, killing that check is not possible with such codes.
So here is a code that will kill the protection (when you go through doors) :
Kill Protection
1202876A 0000429B
(that code also works for the EU game btw).
That's all.
Like an afternoon.
Hopefuly, thanks to your researches, I knew there was a counter that triggered the protection.
That saved me some time, and gave me a place to start
It was "hard" to find it on the emulator, because the emulator wasn't triggering the protection.
But after a lot of tests/tries, I found it was doing "stranges things" at 0x020FB594.
From there, it was just a matter of studying/backtracing/testing, and I figured it out.
Hopefuly, thanks to your researches, I knew there was a counter that triggered the protection.
That saved me some time, and gave me a place to start
It was "hard" to find it on the emulator, because the emulator wasn't triggering the protection.
But after a lot of tests/tries, I found it was doing "stranges things" at 0x020FB594.
From there, it was just a matter of studying/backtracing/testing, and I figured it out.
It's part of their protection i assume. There exists a valid DLDI section within the binary which the game checksums at the main menu. If altered you will not be able to select any option there, they will all be greyed out and disabled. I've not seen any reports on this so that's why i said it was failed - no cards fell for the trap.
bunsy said:
Looks like a funy protection, and I guess it's a good thing no cards fell for the trap (actually, I wonder why they added such protection if it doesn't block any device. I mean, they should have put it for a purpose, and have tested it on something...).
No, I didn't saw it, but I've to admit I was only looking at the protection triggered by the timer.
Maybe I'll give it a look, just for the fun...
Edit : Indeed, I saw the DLDI protection.
- Joined
- Dec 17, 2006
- Messages
- 921
- Trophies
- 0
- Location
- I was here... before...
- Website
- www.neuronball.com
- XP
- 187
- Country
