zeromus wrote:using USA Portrait of Ruin for example, the CRC of the file is actually 0x96df4c4d. You can confirm this by searching for that CRC online.
I traced through the code that does the CRC back to early 2013 and it doesnt seem like the algorithm ever changed.
The cheats database has 0x0d153ac2. And if you search online you find many cheat databases with this crc for this game.
Crazymax added the CRC mismatch error message in december 2013. I assume he had a reason. I am not going to remove the error message.
Please tell me what the CRCs in the cheat database mean, if they're not the CRC of the NDS file. Am I supposed to use a different polynomial CRC?
The checksum in question is CRC-32 of the first 512 bytes in a decrypted ROM, but with NOT operation applied to the calculated value.
Taking USA Portrait of Ruin for example, CRC-32 of the first 512 bytes of the decrypted .nds is 0xF2EAC53D. Doing NOT with F2EAC53D in Windows Calculator yields D153AC2 seen above, which is also found in the cheat database.
This worthless nag window has finally annoyed me to the point of finding the checksum calculation code in R4CCE. The function responsible for this in R4CCE is sub_41FD3C as IDA calls it, which is found in the memory of r4cce.exe at virtual address 41FD3C. It takes the pointer to the source buffer (0x200 bytes) from the stack and returns the checksum in EAX.
I hope that no one will have to see that f*** nag again, thanks.
That would explain everything. I was told that it was part of the game ID, something "internal" years ago, though I never figured out how to determine such ID, I just rolled with it. R4CCE isn't open source unfortunately and I don't have the tools to poke about it to see how any of it works, I was SOL. One thing that did stick out to me all these years though was the fact that the data looked a lot like a CRC-32 hash, what made me question it more was the fact that I document hash for various dumps for No-Intro, one of the pieces of information needed is the CRC-32, obviously none of them ever matched the databases, but it started to make me rethink about it more. Funnily enough I have been looking into ways to take software apart so I could maybe disassemble R4CCE to see how it was coded to work, this data was one of the first things I wanted to loot at. You beat me to the punch though obviously lol. Thanks for setting the information straight and out in the open for everyone to know. I did the math myself just to double check, you made a small error by forgetting to include the 0 in front of D153AC2, the real result is 0D153AC2. Even so the fixes were spot on, good work Zeromus for the fixes on that, and thanks again fuubar for the information that cleared up everything.
]]>zeromus wrote:using USA Portrait of Ruin for example, the CRC of the file is actually 0x96df4c4d. You can confirm this by searching for that CRC online.
I traced through the code that does the CRC back to early 2013 and it doesnt seem like the algorithm ever changed.
The cheats database has 0x0d153ac2. And if you search online you find many cheat databases with this crc for this game.
Crazymax added the CRC mismatch error message in december 2013. I assume he had a reason. I am not going to remove the error message.
Please tell me what the CRCs in the cheat database mean, if they're not the CRC of the NDS file. Am I supposed to use a different polynomial CRC?
The checksum in question is CRC-32 of the first 512 bytes in a decrypted ROM, but with NOT operation applied to the calculated value.
Taking USA Portrait of Ruin for example, CRC-32 of the first 512 bytes of the decrypted .nds is 0xF2EAC53D. Doing NOT with F2EAC53D in Windows Calculator yields D153AC2 seen above, which is also found in the cheat database.
This worthless nag window has finally annoyed me to the point of finding the checksum calculation code in R4CCE. The function responsible for this in R4CCE is sub_41FD3C as IDA calls it, which is found in the memory of r4cce.exe at virtual address 41FD3C. It takes the pointer to the source buffer (0x200 bytes) from the stack and returns the checksum in EAX.
I hope that no one will have to see that f*** nag again, thanks.
im glad you knew that it was.
]]>using USA Portrait of Ruin for example, the CRC of the file is actually 0x96df4c4d. You can confirm this by searching for that CRC online.
I traced through the code that does the CRC back to early 2013 and it doesnt seem like the algorithm ever changed.
The cheats database has 0x0d153ac2. And if you search online you find many cheat databases with this crc for this game.
Crazymax added the CRC mismatch error message in december 2013. I assume he had a reason. I am not going to remove the error message.
Please tell me what the CRCs in the cheat database mean, if they're not the CRC of the NDS file. Am I supposed to use a different polynomial CRC?
The checksum in question is CRC-32 of the first 512 bytes in a decrypted ROM, but with NOT operation applied to the calculated value.
Taking USA Portrait of Ruin for example, CRC-32 of the first 512 bytes of the decrypted .nds is 0xF2EAC53D. Doing NOT with F2EAC53D in Windows Calculator yields D153AC2 seen above, which is also found in the cheat database.
This worthless nag window has finally annoyed me to the point of finding the checksum calculation code in R4CCE. The function responsible for this in R4CCE is sub_41FD3C as IDA calls it, which is found in the memory of r4cce.exe at virtual address 41FD3C. It takes the pointer to the source buffer (0x200 bytes) from the stack and returns the checksum in EAX.
I hope that no one will have to see that f*** nag again, thanks.
its different for every rom though
]]>http://hp.vector.co.jp/authors/VA013928/soft_en.html
Tutorial are here! https://www.youtube.com/watch?v=tCC8_BK_7PY
Update! Visit here if you are playing on real DS mode!
https://gamefaqs.gamespot.com/ds/925329 … ame-id-plz
Enjoy!
]]>Great! now you only have to tell me what the hell a "game ID" is.
I want to datomatic.no-intro.org, searched for portrait of ruin, and don't see "game id", "gameid" or 0D153AC2
The Game ID is the serial ID of the game. Example, if you have ever purchased or owned any NDS game cartridges in general, you would see that each game cartridge has a serial ID at the bottom of the sticker and on the back of the cartridge. Lets take Pokemon - Black Version 2 for example, the game/serial ID is TWL-IREO-USA, IREO being the games alphanumeric serial ID that you see. If you were to have say 10 of the same DS games all from the same region (say USA), they will all have the same exact alphanumeric serial ID. So for the game you tested, Castlevania - Portrait of Ruin (USA), the ID of the cartridge would be NTR-ACBE-USA, ACBE being the games alphanumeric serial ID. As for this portion of the ID "0D153AC2", this is part of the game/serial ID however this is an internal ID. This can actually be different depending on certain situations, some people may not dump ROM's very well and end up breaking the header or something along the lines, thus making this internal ID change but the actual game ID you see in general will remain the same. Dat-o-Matic does NOT contain any information about the internal ID's because they do not base their information off of those ID's, they base it off of the hash data and game/serial ID's of the games/applications.
If you were confused on what NTR and or TWL means, these are actually abbreviations, NTR being NITRO and TWL being TWELVE or TWILIGH, these are related to the consoles codename.
]]>