1

(2 replies, posted in General discussion)

You are a great quick tester ;-)

2

(2 replies, posted in General discussion)

Hi,

This is a tool to calculate hashes on parts of a file.

Readme:

What:
 This calculates the crc, md5 and sha1 of parts of a file, or the file as a whole.

How:
 parthash <FILENAME> [PARTSIZE ...]

Why:
 Useful for comparing single file images against the multitrack hashes in the redump.org database.

Compiling:
 Use "make" on any linux/unix/bsd console nearby, or if you must, an msys or cygwin environment.
 You need to use a relatively recent gcc (4.5.0+ ish I guess).

 This software uses crcutil-1.0 for providing fast crc calculations.
 crcutil is made by Andrew Kadatch and Bob Jenkins and can be found on http://code.google.com/p/crcutil/
 Do not contact them for support on this software.
 The Makefile will try to pull in version 1.0 through wget if it is not supplied yet.

 Also, this software makes use of the MD5 implementation of Alexander Peslyak.
 This is found at http://openwall.info/wiki/people/solar/software/public-domain-source-code/md5
 Changes were made for OpenSSL compatibility and a small casting patch for g++ support.
 These changes are released under the same license as the original md5.c file.

 Finally, this software makes use of the SHA1 implementation of Steve Reid, Ralph Giles et al.
 Changes were made for OpenSSL compatibility and using standard c types in the header.
 Also, SHA1HANDSOFF is defined to protect input data.
 These changes are also released under the same license as the original sha1.c file.

Contact:
 At the moment, see the redump.org forum thread where you got this.

-V.

The 64 bit version is around 40% faster if your machine supports it.
The MD5 and SHA1 algorithms I use in this are not the fastest available, I choose them based on their license, readability and compactness.
I made them OpenSSL compatible though, so if you are on linux, you could modify the source to compile with OpenSSL.

Source: parthash-0.1.tar.gz
Win32 binary: parthash-0.1-bin-win32.zip
Win64 binary: parthash-0.1-bin-win64.zip

3

(2 replies, posted in General discussion)

Hi,

This is a tool to combine crcs.

Readme:

What:
 This can be used to combine several crc values into one.

How:
 combinecrcs <CHUNKSIZE> <CRC> [<CHUNKSIZE> <CRC>]...

Why:
 Useful for finding combined crc values of tracks in the redump.org database.

Compiling:
 Use "make" on any linux/unix/bsd console nearby, or if you must, an msys or cygwin environment.
 You need to use a relatively recent gcc (4.5.0+ ish I guess).

 This software uses crcutil-1.0 for providing fast crc calculations.
 crcutil is made by Andrew Kadatch and Bob Jenkins and can be found on http://code.google.com/p/crcutil/
 Do not contact them for support on this software.
 The Makefile will try to pull in version 1.0 through wget if it is not supplied yet.

Small word of caution:
 Relying on a crc for checking a complete image is reasonably robust against data corruption.
 However, it is not robust for data integrity checking.
 Data can easily be faked to produce any crc of ones liking, so a collide is easy to compute.
 If you want to be sure about data integrity, use a crypto hash, such as md5 or sha1.

Contact:
 At the moment, see the redump.org forum thread where you got this.

-V.

Small word of caution:
Relying on a crc for checking a complete image is reasonably robust against data corruption, but not for data integrity checking.
Data can easily be faked to produce any crc of ones liking, so a collide is easy to compute.
If you want to be sure about data integrity, use a crypto hash, such as md5 or sha1.

I updated the 0.1 archives with this warning included in the readme.
Please redownload if yours doesn't contain it.

Source: combinecrcs-0.1.tar.gz
Win32 binary: combinecrcs-0.1-bin-win32.zip

Hi,

This is a new dumping tool for XBOX DVDs.
It is a drop-in replacement for MineSweeper, as this one also dumps the L1 Video layer which MineSweeper did not.
It can also be used for only calculating the hashes of a disc.

Readme:

Usage: FreeCell <DRIVE> [-n|-o OUTPUTFILE] [SECTORFILE]

Dumps an XGD from a compatible drive, padding sectors in SECTORFILE.
The resulting OUTPUTFILE will include all video layers data.
Outputs the crc, md5 and sha1 of the resulting dump.

  -n             don't save to OUTPUTFILE, only calculate and show hashes
                 can not be used together with -o
  -o OUTPUTFILE  use OUTPUTFILE as file to extract to
                 if no -o option is given, it will default to "Track 01.iso"
                 can not be used together with -n

This is windows only, but if there is need for a linux version, let me know.

!!IMPORTANT NOTE!!
There is a check build in to make sure the Middle Zone A data is all zero padding.
This program will stop the dump if it's not, and instruct you to report this.
If you ever see this message, report it!

download (program + sources):
freecell-0.1.zip

Very nice! Thanks!

About the PIC, it is still  a bit unclear what is needed/wanted.
The original 3k3y stuff only dumped 0x73 bytes of the PIC.

Well, the plan still is to make such an app someday, but interest in that has been lost a bit.
Technically it should be possible.

A Lite-On iHBS112 works, but there are a few others.
The missing steps require at the moment some external hardware, it is at this point not yet known if we can succeed in getting disk id and encryption keys without the extra hardware and/or a ps3.

ol, don't forget a "sync" after a write to usb.
It might be that the first time, the changes were not yet written  to the stick, but were still in cache.

9

(3,493 replies, posted in General discussion)

MrX_Cuci wrote:

Same hashes as cloneCD dump indeed. (different drive) Weird to me. Why were there crackers back in the day when they just could have used clonecd? The only reason I can think of is that a lot of burners couldn't write such an image properly. As posted in the above forum link.

Safedisk 2 has a few sectors in them which were designed to not be writable (due to overloading the writers EFM encoder).
However, some writers were capable of doing this still in those days.
Nowadays, I think all writers are fast enough to be able to do this.
In any case, these are not the bad sectors which you get on read, those are a reading protection (the idea was to make dumping the disk take ages)
Also, safedisk 2 was devised in a time when disk emulators like daemon tools and alcohol were not invented yet (or just barely invented).

10

(3,493 replies, posted in General discussion)

You could check the bad sectors in cdmage to see if they contain the 0x55 pattern?
If not, then changing those sectors to 0x55 should match up Nexy's dump if it's the same.

Thanks.
I used a bit of shellscript for that, but I guess that on windows it would be easier to have that be done by the tool itself.
I'll see what I can do in the next revision, i'll probably add a "slice" tool instead of having it be done by findcrcs itself.

Good to hear! thanks for the testing smile

I just seen a bug in my code because of your post... it should say EDC, not ECD roll.
Will be fixed in a next release.

Thanks, got the bits rotated, sorry about that.
I updated to 0.2, can you recheck if it now works?

As I have no CD-i discs, can you extract a sector for me to test with?

Howdy again,

This is something initially thought up by Jackal and (I think) iR0b0t.
What it does is trying to fix a mode 2 form 2 sector, which can be found on CD-ROM XA discs, like PSX and CD-i Discs.
These sectors have no ECC code, only a EDC code to check the validity of the sector.
We can try to fix these sectors by brute forcing all the data bytes until we find a match.
That is basically what this program is used for.

It can only fix a single byte for 2 reasons:
1. finding 2 random errors on 2 random places takes 6 days, even with the fast crc routines I am using.
2. trying to fix more then 1 byte means that the possible fixes increase to a level where it is just a random guess as to which is the right fix.

Although, if the demand is there, an option to fix 2 consecutive bytes could be added.
The speed hit then will only be x256 (around 2 minutes on my workstation) and false positives would also be more manageable.

The readme:

What:
 This is a not yet idiotproof version of cdxafix.
 It is to be used to try to fix Mode 2 Form 2 sectors in Playstation 1 or CD-i CD images.

How:
 cdxafix <file> <sector>

 File is a PSX, CD-i or other CDXA image file.
 Sector is the sector to try to fix.
 You get the sector number from CDmage or another CD Image checking utility.

 After (or rather, if) cdxafix finds one or more fixes, then you can use applyfix to apply them.

 applyfix <file> <sector> <offset> <new data>

 First off, there is no undo!
 Make a backup first, or re-apply the original data you got from cdxafix (2nd number).

 Offset is the first number you got from cdxafix, new data is the 3th (in hex).

 Try the fix with the lowest number of bits first, or, if it is availiable, an 8 bit fix.
 After fixing, check the image as a whole with redump to see if you get a match.
 If you don't, then:
 - you have a different pressing.
 - and/or there might be other, more subtle errors.
 - and/or the error is part of the image.
 - and/or redump has faulthy (probably not validated yet) information.
 (yes, all 4 could apply too).

 A special case is when cdxafix finds a mismatch in the subheader and it's copy.
 Then you have to apply all the fixes that are in the list (cdxafix will tell you when this happens).

Why:
 Mode 2 Form 2 sectors are only protected by an EDC block and not by ECC.
 This means that data errors can not be fixed, only found by CRC checks.
 What cdxafix does is try to bruteforce every databyte to find some dataset which matches the EDC.

Warning:
 This software is not yet idiotproof!
 - It does not check arguments for validity yet.

 Also, do NOT, I repeat, DO NOT use this to 'fix' sectors where you have no other means to
 check validity of the data (such as a redump.org entry).
 ESPECIALLY, do NOT use this to actually 'fix' sectors before submitting a result to redump!
 Some CD's deliberately introduce errors in EDC as part of the on disc data,
 for instance for copy protection or other means.
 This also goes for validity / confirmation entries to redump!
 ALWAYS use the proper redump guides to dump images and NEVER rely on fixes like these!

Compiling:
 Use "make" on any linux/unix/bsd console nearby, or if you must, an msys or cygwin environment.
 You need to use a relatively recent gcc (4.5.0+ ish I guess).
 On windows, if you have a 64bit MinGW, you can use "make 64=1" to build a (much faster) 64bit version.

 This software uses crcutil-1.0 for providing fast crc calculations.
 crcutil is made by Andrew Kadatch and Bob Jenkins and can be found on http://code.google.com/p/crcutil/
 Do not contact them for support on findcrcs.
 The Makefile will try to pull in version 1.0 through wget if it is not supplied yet.

Contact:
 At the moment, see the redump.org forum thread where you got this.

-V.

And an example run:

~/cdxafix-0.1$ cdxafix kidclown2.bin 24908
Possible fixes:
771  45 -> 44  (1 bit fix)
1026  0c -> 5d  (3 bit fix)
~/cdxafix-0.1$ applyfix kidclown2.bin 24908 771 44
45 -> 44
~/cdxafix-0.1$ cdxafix kidclown2.bin 24908
Sector ECD matches sector data. No fix required.
~/cdxafix-0.1$ 

Standard disclaimer:
I write my tools mainly for myself to use in a specific way.
If however someone has some issues using this, or has some suggestions, i MIGHT be able to change, fix or add things, but only if time and effort are permitting (which is not usually the case).

ps.
--> READ THE SECOND PART OF THE WARNING IN THE README ABOVE! <--
--> DO NOT USE THIS TO 'FIX' IMAGES WHICH YOU PLAN TO SEND TO REDUMP! <--

Source: http://winaoe.org/redump/cdxafix-0.2.tar.gz
Win32 binary: http://winaoe.org/redump/cdxafix-0.2-bin-win32.zip

I was not aware of those 2 programs, so I tested them against mine.

First off, I ported the thing to windows/MinGW, so no need for cygwin dll's
Updated the initial post for a source and binary release of v.0.2.

Benchmarking the 3 programs was done on a combined bin (data + audio) of Moto Racer 1.
Image is 574,551,264 bytes big (around 75% of a full CD).
The target crc to find is 9c8f607e with a track size of 46,435,536 (track 6 of this listing: http://redump.org/disc/18266/)

first off: findcrcs

~/findcrcs-0.2$ time findcrcs.exe "Moto Racer 1.bin" 46435536 9c8f607e
348061372  9c8f607e  7ca7c0881f28f2684623b3a2ae53e95b

real    0m5.743s
user    0m0.000s
sys     0m0.047s

Found with the correct md5 on offset / index 348061372.
Meaning bytes 348061372 to 348061372+46435536 correspond to the track 6 in the dump information.

Done in 5.790 seconds.
In these 5.760 seconds, a total of 528,115,728 crcs were checked, making it do around 90,000,000 crcs per second.


Next up: psxt001z

This one was not doable for a complete search of the whole image, took waaay to long.
So instead I let it search -1000 to +1000 around index 348061372 (found above to be correct) to get at least some idea of the speed.

~/findcrcs-0.2$ time psxt001z.exe --track "Moto Racer 1.bin" 348060372 46435536 9c8f607e
psxt001z by Dremora, v0.21 beta 1

File: Moto Racer 1.bin
Start: 348060372
Size: 46435536
CRC-32: 9c8f607e

Offset correction 0 bytes, 0 samples, CRC-32 dbf4a270
Offset correction 0 bytes, 0 samples, CRC-32 dbf4a270
Offset correction 4 bytes, 1 samples, CRC-32 aaeba36a
Offset correction -4 bytes, -1 samples, CRC-32 4abb692b
...
...
Offset correction -992 bytes, -248 samples, CRC-32 a87ee8ab
Offset correction 996 bytes, 249 samples, CRC-32 3607c430
Offset correction -996 bytes, -249 samples, CRC-32 97e367cd
Offset correction 1000 bytes, 250 samples, CRC-32 9c8f607e

DONE!

Offset correction: 1000 bytes / 250 samples

real    2m27.556s
user    0m0.031s
sys     0m0.000s

This was a search of around 500 crcs (it does steps of 4, as also mentioned by gaijin).
Meaning, it does around 3.5 crcs per second.
findcrc's beats this with a factor of 25,000,000.


Lastly: fff
This is faster then psx001z, but still way too slow to do a full image.
So, again, it gets a 2000 byte window, with the default of a 4 byte step.
It can do less bytes per step, but 500 crcs gives us a clear compare to psxt001z.

~/findcrcs-0.2$ time fff.exe -offset=348060372 -size=46435536 -crc=0x9c8f607e "
Moto Racer 1.bin"
FindFileFragment @20100709 / themabus@inbox.lv
----------------------------------------------
Input: Moto Racer 1.bin
Offset: 348060372
Size: 46435536
CRC: 9c8f607e
Shift: both
Step: 4
Range: 20000

Offset correction 0 bytes, CRC-32 dbf4a270
Offset correction 4 bytes, CRC-32 aaeba36a
Offset correction -4 bytes, CRC-32 4abb692b
Offset correction 8 bytes, CRC-32 7ed53192
...
...
Offset correction -992 bytes, CRC-32 a87ee8ab
Offset correction 996 bytes, CRC-32 3607c430
Offset correction -996 bytes, CRC-32 97e367cd
Offset correction 1000 bytes, CRC-32 9c8f607e

Fragment found!

real    0m26.102s
user    0m0.015s
sys     0m0.015s

This was 500 crcs in 26.102 seconds, meaning around 19 crcs per second.
Meaning an increase over psx001z by a factor of around 5, but still 4,700,000 times slower then findcrcs.


So.... yeah....  wink


Anything above an offset of 10,000 is not really doable with fff and out of the question for psx001z.
10,000 is not even that much of an factory offset between different cd presses, so I think findcrcs has a use.

In any case, as said, I updated the initial post for a 0.2 update and windows binary release.
Enjoy.

Howdy,

I am not sure if what I made is new, but searching around didn't turn up anything.
In any case, after not finding anything useful, I made a new crc tool to find (in a fast way) a matching crc in a dump with some offset.
This is whipped up in a few hours, so it is still kind of rough and not idiotproof (no software of mine is idiotproof actually  wink)

Usecase:
Finding an offset in a dump of specific audiotracks to match against the redump database.
If all tracks match with an offset to redump, it is further confirmation that the dump was successful.
This is NOT meant to actually find a drive offset or to be used in a way to matchup a dump to validate an entry!
Use the proper redump guides to dump discs! Different pressings of audio disks have factory offsets which this tool mainly detects.

README:

What:
 This is a not yet idiotproof version of findcrcs.
 It is to be used for finding a block of data which matches a specific crc.

How:
 findcrcs <file> <size of window> <crc> [more crcs...]

 File is a big file which should or may contain the searched for data.
 Size of window is the size of the block of data to find.
 Crc is the crc to find in the file (may be more then 1, but all will be matched on the window size).

 If a match is found it will print out an md5sum of the matched block for further inspection.
 For best results, add some (1MB or so) zero bytes padding around the file first.
 In a future version, this might be a selectable option of this program.

Why:
 Useful for finding audio offsets in disk images together with the redump.org database.

Warning:
 This software is not yet idiotproof!
 - It does not check arguments for validity yet (especially size of window and crc's.)
 - No paddiong option yet.
   if matching audiodata, you should pad the combined audiotracks with zero bytes at the start and end.

Compiling:
 Use "make" on any linux/unix/bsd console nearby, or if you must, an msys or cygwin environment.
 You need to use a relatively recent gcc (4.5.0+ ish I guess).
 This software uses crcutil-1.0 for providing fast crc calculations.
 crcutil is made by Andrew Kadatch and Bob Jenkins and can be found on http://code.google.com/p/crcutil/
 Do not contact them for support on findcrcs.
 The Makefile will try to pull in version 1.0 through wget if it is not supplied yet.

 Also, this program makes use of the MD5 implementation of Alexander Peslyak.
 This is found at http://openwall.info/wiki/people/solar/software/public-domain-source-code/md5
 A small casting patch was made to support g++, this small patch is released under the same license as the original md5.c file.

Contact:
 At the moment, see the redump.org forum thread where you got this.

-V.

Disclaimer:
I write my tools mainly for myself to use in a specific way.
If however someone has some issues using this, or has some suggestions, i MIGHT be able to change, fix or add things, but only if time and effort are permitting (which is not usually the case).

Source: http://winaoe.org/findcrcs-0.2.tar.gz
Win32 binary: http://winaoe.org/findcrcs-0.2-bin-win32.zip