How to calculate signature (checksum) of DDP images?

[casejustin80]

Hi!. I downloaded a DVD DDP image, consisting on this folder:
. "\NAME OF THE PRODUCT\L0_737B.FE7E.311F"
with these five files:
. "DDPID"
. "CONTROL.DAT"
. "MAIN.DAT"
. "Checksum.chk"
. (has 8 hex characters for each of the three files above)
. "L0_737B.FE7E.311F.esg" (161 bytes long)
. (contains value 79E61870382BD1DE8545737BFE7E311F among other things)
And the uploader e-mailed me its Eclipse Signature:
. "737B.FE7E.311F"
I don't have the EclipseSuite to calculate back the Signature (in order to detect corruptions).
Is it possible to use general purpose utilities such as AccuHash, etc.?. As far as I know they get the CRC32, MD5, etc. but for individual files, not a folder.
On top of this, I see the Signature value is stamped on the folder and *.esg names and content, so I guess the Signature is calculated not taking into account these (otherwise we get an infinite loop).
Can anybody help me?. Thanks!.

[rik1138]

Sounds like Checksum.chk has CRC32 values for DDPID, CONTROL.DAT and MAIN.DAT. Single layer disc image?

I'd just use a CRC32 creator, generate the CRC of the 3 files, and see if it matches what's in the Checksum.chk file. If those files are fine, you should be good. The other two files I think are only used by Eclipse, so if you don't have that you can't do much with them... But if the main DDP files are okay, then you shouldn't have a problem replicating.

[casejustin80]

rik1138, many thanks for your suggestion!. Yes, I think the "signature" is an Eclipse proprietary means of checking a bundle of files.
Your alternative idea is indeed very suitable for my needs, as long as all images contain a file with the checksums.
As to the contents of "Checksum.chk", you came close, but though they are 8 hexadecimal characters (that is, 4 bytes), sorry, it's not CRC32, nor Adler32, FCS-32, G-hash32, SizeHash32.
The authoring was made with Sonic Scenarist, I hope these checksums are not proprietary too... Do you know of another posibility?.
Thanks again!

[rik1138]

Can you post the contents of the checksum file? It is just a text document, right? A CRC32 checksum would look like this:
E7D48C34
8-digit string of hexadecimal numbers... That sounds like what you are describing...

I can't imagine anyone using anything other than CRC32, MD5 or SHA-1 for checksums (and MD5/SHA-1 create huge character strings).

Scenarist itself doesn't create checksums, so if the project was made in Scenarist, the other files were created separately. It's possible that Eclipse creates the Checksum file too, but it's probably not Eclipse specific...

[casejustin80]

rik, sorrrry I forgot to come back to check for answers!.
These are the contents of file "Checksum.chk":
. [Checksum]
. Version=1.00
. DDPID=B4708FD1
. CONTROL.DAT=D7302A51
. MAIN.DAT=938FC6EE
As an example I have also attached file "DDPID" (the uploader refuses filenames with no extension, so I renamed it to "DDPID.txt", this does not change the hash). The CRC-32 for this is 3EBE9DA3 instead of B4708FD1.
Sounds like they used another xxx-32 algorythm.
Please see the check file has .CHK extension as opposed to .TXT as used e.g. with Gear. BTW, if I rename it to .TXT, Gear says CRC is no successfully verified.