CRC detection

  • Thread starter Thread starter therealsstrunks
  • Start date Start date
Status
Not open for further replies.
T

therealsstrunks

Guest
I hope this is in the correct place, my apgs to mod if I posted wrong.

I've read so many posts and pages that my mind is boggled now :x . From what I've seen from Cyb's posts this may be most likely his expertise, but if anyone can help by all means do. I'm tryin to find a PSX game's region of the savefile it performs a CRC on. It appears a debugger is the way to do this. I guess I have 2 choices: be a script kiddie :oops: (BAD) and hope someone has always done that for a game OR the more satisfying way and find it myself. How do you trace through the game to find this as well as the seed polynomial and the CRC polynomial powers used etc?? I am new to this and have started going bald trying to figure this out :isee: . I've been using lunar silver star story complete as my experimental game but crossed over to ff7/ff8 to study what qhimm did with griever. i know the CRC for griever is asm which i don't know, but that doesn't matter since it doesn't help me figure HOW he found the region to use. man I'm off to a slow start.  -_-  Is there some kind of PC run PSX debugger to do this with all games?

_________________________


P.S. I read the thread in which cyberman mentions his work with ff9 and PCSX (http://forums.qhimm.com/viewtopic.php?t=2196&highlight=crc+ff9). I don't know if it can even run Lunar 1 SSC since it looks to be PS2 emu, let alone how to get it to display CRC polynomials. Please help.
 
:o WOW! Josh W, I'm very glad to actually get your input. I've actually read your info on mem cards already. it's what helped get me started. a very good guide, thanks for putting in that time. that gives a very good map of save frame layout. i found that my memory station device (from lik-sang) is likely the save format of the 'unknown' type you couldn't remember the name of (it pulls the save data block plus the adds as a header the TOC info from the first block). i wasn't refering though, to 'region' in terms of euro saves vs north american game versions. i meant it in terms of how DonJuan's fchop utility for GTurismo could take a save file and parse it into a single chunk that you did a simple crc-32 on. i couldn't find in your guide though how to map the region of save data that is used in the CRC. I can usually find where the resulting CRC value is stored, but I'm still stumped on the road to get that value. can you direct me on this?
 
I, sadly, cannot. There is a memcard editor that does the CRC check automaticly. What's funny is I don't really understand the process myself. That secotion of the doc was translated from a Japanese document I found on the web. However some have actully understood it better than I could translate it and have made crc checkers based on my doc.

That's all I know.
 
I hate to tell you this but you really need to know how assembly language works. I actually converted Qhimm's assembly listing in Griever to C, so I could port it to Unix. It just performs CRC calculation based on table lookup.

Anyways, the answer to your question of finding the block that is checksummed is through trial and error. Change one byte, then load the game.

Another approach is to look through the assembly listings of whatever executable you are trying to figure out. But as I stated above, you need to know how assembly works, and how variables are passed. On machines with multiple registers like MIPS, there addresses can be passed in the registers, but on the x86, they are passed by pushing these addresses on the stack. Another problems is that this will generate megabytes of assembly code that is hard to figure out. It is also extremely time consuming. On the computer this is easier because executables have a defined structure and also because there exists debuggers that let you trace each instruction.. For the PSX, you'd have to rely on emulators to provide this debugging feature but I havn't found any that really allow you to do this. The executables on the PSX are in some proprietary Sony format that isn't documented very well. As far as I know, these executables don't have different sections for symbol tables and such which makes it even more difficult to figure out whether you want to trace into a call or step over it.
 
CRC checks are performed with the following criteria.
1: a Polynomial is used (xor'd) to compute the end result this is to make sure there are no zero bit misses in the check. (Otherwise the CRC is useless if it doesn't cover all the bits in the stream of data).
2: Initial value.  The initial value affects the eventual outcome of the CRC computation.
3: sometimes the result is complimented.
4: Scope.. often a section of the data has the CRC computed on it. This can be a royal PITA to find.
5: magnitude. Common are 16 bit CRC's check sums were used in chrono trigger. However 32 bit CRC's and larger are possible.

I've yet to figure out FF9 and chrono cross although I know where the CRC is.

Let us give a typical situation
8192 bytes of which 256 to 512 are used for Icons
7936 bytes of which 2 are needed for storing the CRC that's 7934 bytes.
Of that you have a finite number of variations (7933 of them) in what data was used.
Anyhow the permutations and combinations get staggeringly huge. Fortunately there are only so many good polynomials to use. AND the initial value is normally 0xFFFF for a 16bit CRC (fills all zero bits).  The compliment is easy to check as well. I suppose I could set up a program that compared data a chunk at a time in an area with the CRC

You can compute the CRC using  a shift XOR'd function to create the necessary values.  
Oddly once you have ONE version of this computation working it's MUCH easier to create variations on it. (change the polynomial or the seed value and if the result is complimented).

Cyb
 
Status
Not open for further replies.
Back
Top