You are not logged in.
Pages: 1
recently a guy has been been updating the user cheat data base.
you can get it here
https://gbatemp.net/threads/deadskullzj … es.488711/
I noticed wile importing codes i get a checksum mismatch error can this error be fixed? his cheat file works file with multiple flashcards.
Offline
I don't know what you're talking about.
I dont know how those cheats work. I placed usrcheat.dat and cheat.dat both in my cheats folder and changed the type in the path settings, and opened roms, and didnt see anything about a mismatch error.
I can't find "checksum mismatch" in the code
Online
I also got "CHECKSUMS NOT MATCHING" error since long time ago.... Deleted Desmume.ini file will not fixed problem.
This problem was OK on Desmume version 0.9.11 (official) and after that on any SVN or GIT numbers, the problem was appear.
Offline
Cool. Waiting to hear details that will let me repro it or an explanation of what it even means.
Online
its not in the code is a windows that show up before the cheat database menu comes up. i used super mario 64 ds rev 1.0 put the cheat.dat file in the cheat folder which it the samr file used from the download above
Offline
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?
Online
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?
This is the dump I used for the cheat databases:
File: Castlevania - Portrait of Ruin (USA).nds
CRC-32: 96df4c4d
MD4: ee67a87e45a195041fd490c5837a1f2c
MD5: 2edd57540cae45842fbd19c45a4214f9
SHA-1: 382602e3615b2282eead584014125e71b5b0f033
I can confirm this dump is proper via this link here:
http://datomatic.no-intro.org/?page=sho … =28&n=0735
Now the usrcheat.dat and many other cheat databases work via game ID's, in this case:
Game Title:
Castlevania - Portrait of Ruin (USA)
Game ID:
ACBE 0D153AC2
"0D153AC2" is part of the game ID, this is NOT CRC. If you add the game into R4CCE you will get that exact game ID above, meaning this is the correct game (verified via a reliable source, Dat-o-Matic), this also means it is NOT a problem with the cheat database, it is an issue with DeSmuMe.
Offline
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
Online
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.
Offline
Not good enough. I can't find C23A150D or 0D153AC2 in the ROM. As far as I know, this is a number pulled out of thin air. I need someone to tell me where this game ID comes from.
Online
R4CCE? Get it here! Created by Yasu!
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!
Last edited by AsPoke3172 (2018-04-30 03:32:42)
Offline
the game ID comes from the game rom. its stored on the usrcheat.dat file under every game so the emulator/flashcard can properly pair the correct cheat codes with the corect game.
using r4cce you can see the game ids.
https://imgur.com/a/pJu9lUc
Offline
Is r4cce open-source? That's what I need to figure out how it pulls that number out of thin air. For all I know it's just a custom hash. if you don't mind, I'm going to keep on saying "what the hell is a game id"?
Online
no its not open source drag the rom over to the program and it extract those numbers from the rom.
https://imgur.com/a/My7tKag
Last edited by fintogive (2018-05-01 02:41:07)
Offline
I think R4CCE was closed source.... OR just private mode....
Offline
Great, you pointed at the ASME. now point at the AEA63749.
Online
i dont know much about it. all i know is i changes if the rom has been altered in anyway for example a file has been modified in the game data and then saved/rebuilt. i think its a build id but ill have to do more research on it to find out exactly what its for.
its different for every rom though
Last edited by fintogive (2018-05-01 11:48:40)
Offline
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.
Offline
Thank you. I will investigate this further and fix it within the week if I can confirm your information.
Online
Online
Thanks Zeromus for fixing "checksum error" bug! Thanks Fuubar for founding the bugs! Mission was complete!
Offline
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.
Offline
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.
Last edited by DeadSkullzJr (2019-09-30 23:11:02)
Offline
Pages: 1