Menu ▾ ▴

#826 Final Fantasy Crystal Chronicles - Ring Of Fates (U)

None
closed-fixed
nobody
None
5
2022-07-11
2009-10-26
Scott Nash
No

using svn 2984
here is my save state
http://www.mediafire.com/?sharekey=dcd8013b1cd2775d5bf1f12f1ff3f30a6dc5008733cdf1634ca8d2a77d7aad89
just pick up the crystal and the game resets with the "thanks for playing" message
looking around on the net seems to indicate that it is some copy protection or anti-piracy mode not supported in DeSmuME yet

Discussion

  • Pokefan 999

    Pokefan 999 - 2009-10-26

    you can bypass this security feature by using bios & firmware but not SWI or boot from firmware.

     
  • DottorLeo

    DottorLeo - 2009-10-26

    More information on this thread: http://gbatemp.net/index.php?showtopic=77990

     
  • zeromus

    zeromus - 2009-10-27

    am i supposed to read through 133 pages!? has anyone actually dissected the copy protection instead of just posting a patch?

     
  • Pokefan 999

    Pokefan 999 - 2009-10-27

    It doesn't work with bios & firmware. My AR codes are still active when I test with bios & firmware. At this moment, need AR codes to get pass this scene.

     
  • Scott Nash

    Scott Nash - 2009-10-27

    this is what i found on GBAtemp about the protection
    from someone called Pokemonhacker

    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.

     
  • Scott Nash

    Scott Nash - 2009-10-27
     
  • Pokefan 999

    Pokefan 999 - 2009-10-27

    weird. I use my own game save and test with bios (without AR code), kill the boss and get thru' the crystal part. I test again without the bios & AR code (my own savestate after beating the boss) and get thru' the crystal part.
    with your savestate, I need AR code to get thru'.

     
  • Pokefan 999

    Pokefan 999 - 2009-10-27

    I did another test without bios & AR code, from the entrance to the boss room, kill the boss and get thru' the crystal part.

     
  • zeromus

    zeromus - 2009-10-29

    fancy that, I think I forgot to clear dma source addresses. sloppy, sloppy.

     
  • zeromus

    zeromus - 2009-10-30

    r2989 should fix this. i made it past the point of this savestate... maybe i played faster than you thought and it didnt trigger..

     
  • Scott Nash

    Scott Nash - 2009-10-30

    yep seems to be fixed as i started a new game and have played it for a while and it hasn't had the thank you message

     
  • Scott Nash

    Scott Nash - 2009-10-30
    • status: open --> closed-fixed
     

Anonymous
Anonymous

Add attachments
Cancel