CRC mismatch when reconstructing "Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT"

Summary:

Source files have correct CRC, resulting RARs are same size, but I'm getting CRC mismatch

CRC mismatch when reconstructing "Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT"

johnye (guest) 30 Jun 2014 09:20

I'm trying to reconstruct Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT. I placed srr.exe, Red_Dead_Redemption_GOTY_Edition_PS3-ABSTRAKT.srr and BLES01294 in the same folder, then ran "srr Red_Dead_Redemption_GOTY_Edition_PS3-ABSTRAKT.srr -p". This is what I got:

Re-creating stored file: as-rdrgoty.nfo
Re-creating stored file: as-rdrgoty.sfv
Re-creating RAR file: as-rdrgoty.rar
CRC mismatch in file: BLES01294\PS3_GAME\USRDIR\EBOOT.BIN
CRC mismatch in file: BLES01294\PS3_GAME\SND0.AT3
CRC mismatch in file: BLES01294\PS3_GAME\USRDIR\arm00.bik
CRC mismatch in file: BLES01294\PS3_GAME\USRDIR\blk00.bik
CRC mismatch in file: BLES01294\PS3_GAME\LICDIR\LIC.DAT
CRC mismatch in file: BLES01294\PS3_GAME\PS3LOGO.DAT
CRC mismatch in file: BLES01294\PS3_GAME\ICON1.PAM
CRC mismatch in file: as-rdrgoty.rar
Re-creating RAR file: as-rdrgoty.r00
CRC mismatch in file: as-rdrgoty.r00
...
Re-creating RAR file: as-rdrgoty.r46
CRC mismatch in file: as-rdrgoty.r46
Re-creating RAR file: as-rdrgoty.r47
CRC mismatch in file: BLES01294\PS3_GAME\USRDIR\rdr2_layer0.rpf
CRC mismatch in file: as-rdrgoty.r47
...
Re-creating RAR file: as-rdrgoty.r58
CRC mismatch in file: BLES01294\PS3_DISC.SFB
CRC mismatch in file: BLES01294\PS3_GAME\PARAM.SFO
CRC mismatch in file: as-rdrgoty.r58
Re-creating RAR file: as-rdrgoty.r59
CRC mismatch in file: BLES01294\PS3_GAME\TROPDIR\NPWR00867_00\TROPHY.TRP
CRC mismatch in file: BLES01294\PS3_GAME\ICON0.PNG
CRC mismatch in file: BLES01294\PS3_GAME\PIC1.PNG

Release successfully reconstructed.  Please re-check files against the SFV to ve
rify before using.

The resulting RARs have the wrong CRC but the right size, from as-rdrgoty.rar-r58 (150.000.000 bytes) to as-rdrgoty.r59 (4.752.247 bytes). I checked the CRCs from the files inside the RARs against the ones in the www srrdb com/release/details/Red_Dead_Redemption_GOTY_Edition_PS3-ABSTRAKT page and they all match, but I noticed they are compressed, so the RAR is using compression and that is why the resulting CRCs don't match.

I managed to find the original files over a very sloooooooow page that will take weeks to download, I only dled as-rdrgoty.rar and as-rdrgoty.r59, and their CRC matches with as-rdrgoty.sfv from the srr. Is there a way to get information from the RAR header about the WinRAR version and compression method used?

johnye (guest) 30 Jun 2014 10:21

Now trying pyReScene, I know a lot about DOS and command line but nothing about python, so I followed this easy step by step instructions at opgforum net/index.php/topic/15454-how-to-use-pyrescene/ and it's now running, but it seems it will take ages reRARing 15GB over and over.

I still think the fastest method would be getting the info from the original RAR header I have or from the SRR, if that's possible. I once reconstructed a RAR by trial and error using several RAR versions, the only difference was the original file date inside the RAR, I just copied that from the original damaged RAR with an hex editor. But it was a much smaller file…

Re: CRC mismatch when reconstructing "Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT"

Gfy 30 Jun 2014 14:53

Where did you get Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT.srr from? It isn't on srrdb.com. Please do upload any missing files!
Which tool did you try before? If the SRR represents compressed volumes, all reconstruction should fail if it wasn't pyReScene.

Is there a way to get information from the RAR header about the WinRAR version and compression method used?

It uses all possible info from there, but not everything is in there.

I know a lot about DOS and command line but nothing about python

Do python.exe pyReScene\bin\srr. That's all you need to know about Python for this. Now your cli knowledge can kick in ;)

All the RAR meta data (the headers) is included in the SRR file. The problem here is finding the same correct compressed data that is representing the files.

Re: CRC mismatch when reconstructing "Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT"

johnyept 30 Jun 2014 19:16

Where did you get Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT.srr from?

I got it from http://www.srrdb.com/release/details/Red_Dead_Redemption_GOTY_Edition_PS3-ABSTRAKT, it's the EUR version.

The RAR is in fact compressed. From what I gathered by looking at the header from the original .RAR I have, the .SRR and http://www.forensicswiki.org/wiki/RAR, it's a solid archive with best compression and a dictionary of 4096k. The file order is the one in the page above and it was released on 2011/10/26, now all I need to find is the correct RAR version, which must be lower than 2011-10-30_rar410b2.exe. I tried pyReScene but my laptop is not fast enough to cycle through several RAR versions until it finds the correct one.

What RAR version does srr.exe use? It managed to create all RARs with the correct size but with wrong CRC (files were in the wrong order), maybe I can start from there, all I need is to use the same version, the correct file order and then manually fix the metadata (file/folder dates) if needed.

Re: CRC mismatch when reconstructing "Red.Dead.Redemption.GOTY.Edition.EUR.PS3-ABSTRAKT"

Gfy 01 Jul 2014 18:23

johnyept, that's confusing… you want the original RARs but are changing the release name!

The RARs are indeed compressed. It's at the top of the SRR page: "Compression is used".
If it takes really long, it probably has already found the correct rar.exe version and tries to reconstruct. The problem is that it can't find the correct settings to recreate the exact same data.
Pick that one version and let it run until it crashes or finishes.

What RAR version does srr.exe use?

I don't know. What do you see? Which rar executables do you provide the script?

It managed to create all RARs with the correct size but with wrong CRC (files were in the wrong order),

Where did you see that? The wrong order is not possible for the result at all! This makes me think you could mean the intermediate results from the temporary directory. If this is true, this could explain why reconstruction fails.

all I need is to use the same version, the correct file order and then manually fix the metadata (file/folder dates) if needed.

No you don't. This is exactly what pyReScene tries to do. Try figuring out where it goes wrong or what case it doesn't test. That'll be a lot easier.