CRC Verifycation Utility, Version 3.00

[jaclaz]

Yes and No.

 

The CRC32 hash of a .iso made with the -x switch is 0xFFFFFFFF, including BOTH (actually all 4 of them) the values of ExclCRC and AutoCRC.

If you prefer the the CRC32 hash of the WHOLE iso is 0xFFFFFFFF.

 

It is clear (or clear enough) that the 4 bytes of the AutoCRC value (last four bytes of the .iso) are an integral part of this calculation leading to 0XFFFFFFFF, and that this 4 bytes value is the - as defined above - *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF*.

 

The hackcrc32 app you mentioned is not seeemingly working in the same way, or it uses a different algorithm.

 

If you actually try it (on a .iso stripped of the last 4 bytes) you will find out that it fails to produce a 4 byte value identical to the one that the -x produced, it instead produces an 8 byte value that, once appended to the .iso makes it having a value of "normal" CRC32 of 0xFFFFFFFF, but obviously this .iso results as CORRUPT in the MS CRC.EXE.

 

The algorithm (whatever it is) that CRC.EXE uses is seemingly "better" than the one used in the hackcrc32 tool, in the sense that manages to provide always a 4 bytes value.

 

The guess (which remains a guess) is that the algorithm used by the -x switch and by the CRC.EXE, *somehow* makes use of the 4 bytes value of ExclCRC and my guess (which is as good as anyone else) is that the actual "correction" to the "normal" CRC32 happens making use of both the 4 bytes value of ExclCRC and of the 4 bytes of the AutoCRC, as an example, let's say that the value in ExclCRC is the hash of all sectors (or bytes, or words, or whatever) up to a given address and that of AutoCRC is that of some other area(s) + the "complement" between this value and the final value of  0xFFFFFFFF.

IF this is the case, the calculation of the actual value of AutoCRC is based NOT on the whole image, but rather on an area (or *whatever* ) "starting" from the value of ExclCRC.

 

 

jaclaz

[dencorso]

I think that CRC-32 has the following interesting property: if the CSC-32 of an arbitrary binary "fileA" is 0xFFFFFFFF and that of another  arbitrary binary "fileB" is 0xFFFFFFFF, then the CRC-32 of "fileC", resulting from:

 

copy /b fileA+fileB  fileC

 

will also be 0xFFFFFFFF. Is this true?

 

And, BTW, what about the "undocumented command-line switch"  "-xx" ?  Myth or fact?

[jaclaz]

Is this true?

Why don't you try it yourself? 

 

It is a rather straightforward experiment.

 

For your convenience, find in the attachment two very small files, "random filled", both having a CRC32 of 0xFFFFFFFF.

 

jaclaz

2xFFFFFFFF.7z

[dencorso]

Is this true?

Why don't you try it yourself? 

 

It is a rather straightforward experiment.

It's not true!

 

For your convenience, find in the attachment two very small files, "random filled", both having a CRC32 of 0xFFFFFFFF.

jaclaz

Thanks a lot for the test files! You rock!

[jaclaz]

Whenever something is beyond  one's capabilities or knowledge  , there is often anyway a solution, which is - obviously - cheating^[1]!

 

As a teaser , please find attached a copy of fdboot.img, the Freedos 1.0 boot floppy available at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img transformed to have CRC32 of 0xFFFFFFFF and VALID using CRC.EXE.

 

 

 

 

jaclaz

 

[1] By definition in love and war (and MS computing) ALL is fair, or, if you prefer, "Improvise, Adapt, Overcome"

fdbootCRCFF.7z

[dencorso]

 "Improvise, Adapt, Overcome"

 

 

[jaclaz]

Small update.

There are a set of programs here:

https://web.archive.org/web/20130605132922/http://www34.brinkster.com/dizzyk/index.html

https://web.archive.org/web/20130913081713/http://www34.brinkster.com/dizzyk/crc32.asp

That allow, besides calculating the CRC32, to change it by inserting a number of bytes in the file.

These programs are not good, because they use a sort of "brute force" and thus they are slowish.

 

There are tens (if not hundreds) of pages on the internet of CRC32, which can be divided mainly in:

1. useless (for practical uses)
2. pompous and useless (for practical uses)
3. only potentially useful

 

#1 tend to be of the kind, "ok, let me explain how the CRC32 algorithm works", a few lines of mumble-jumble about the algorithm, and a few lines of source code (rarely "original" work).

#2 tend to be of the kind, "ok, I am very smart, I will show off a bit telling you what I accomplished related to CRC32, but I won' t give you anything but some mathematical definitions, a few hints and absolutely nothing you can replicate at home without having first achieved a degree in Math and one in Programming"

#3 tend to be, "ok here is the CRC32 algorithm, I use instead of method "mumble-jumble" method "some other mumble-jumble", followed by some lines of code, in a compiled language like Perl, Python or Java 

 

 

Luckily enough there are a few exceptions, I found the nice crcmanip / crc manipulator:

http://myanimelist.net/forum/?topicid=495063

https://github.com/rr-/CRC-manipulator

https://github.com/rr-/CRC-manipulator/releases

Current:

https://github.com/rr-/CRC-manipulator/releases/download/0.26/crcmanip-0.26.bin.zip

which is (besides the stupid .NET  based GUI) a simple, working command line program to insert (or replace) a "corrective" set of 4 bytes to have any files' CRC32 set to a given value, instantly.

One of the tools (the command line only) that do deserve a place in the box.

 

And this (IMHO extremely complex, but very, very nice  ) CRC reveng thingie:

http://reveng.sourceforge.net/

I am (and will presumably be for the next several days/weeks ) trying to understand it's use, but it is promising.

 

I also found an interesting (though difficult to follow because of the way it is written) description of the manual way to calculate a CRC32, which I am pretty sure that once got rid of the ortography/spelling errors and slang, I may be able to understand and replicate:

http://www.gamerzplanet.net/forums/gunz-hacks-bots-discussion/233326-release-tut-how-to-reverse-crc.html

 

Now back to the MS AutoCRC, it is not yet clear at all how the tool (CDIMAGE or whatever) calculate the values of ExclCRC and AutoCRC.

The actual CRC.EXE, given that:

• the "labels" ExclCRC and AutoCRC do exist at the end of the file
• the "real" CRC32 of the file is 0xFFFFFFFF

will accept as VALID the file.

Pretty lame, if you ask me, as a "verification method"  .

Example with a "handcrafted" file with BOTH ExclCRC and AutoCRC set to 0x0000000:

CRC Verification Utility, Version 3.00
Copyright © Microsoft, 1992-1996

100% complete

AutoCRC signature for file AFILEMOD.ISO is 0x00000000

AutoCRC indicates the file AFILEMOD.ISO is VALID

 

Example with a "handcrafted" file with BOTH ExclCRT and AutoCRC set to 0xFFFFFF

CRC Verification Utility, Version 3.00
Copyright © Microsoft, 1992-1996

100% complete

AutoCRC signature for file AFILEMOD.ISO is 0xFFFFFFFF

AutoCRC indicates the file AFILEMOD.ISO is VALID

 

 

It is possible that the MS thingy uses a different polynomial from the "standard" 04c11db7 one, or a different check value, it seems like there are several CRC32 versions:

http://reveng.sourceforge.net/crc-catalogue/17plus.htm

 

Now, if I only could manage to understand  the usage of CRC reveng .... 

 

jaclaz