CRC Verifycation Utility, Version 3.00

[heustess]

Does anyone have a copy of Microsoft's CRC Verifycation Utility, Version 3.00 that was once at http://tacobell.iexbeta.com/longhorn/crc.exe? I have version 3.05 but need version 3.00. If anyone can send it to me or provide a working link, I would greatly appreciate it.

[DigeratiPrime]

Is there a specific need for that software? I personally use the HashTab (freeware) shell extension for comparing hashes

http://beeblebrox.org/hashtab/

[heustess]

Is there a specific need for that software? I personally use the HashTab (freeware) shell extension for comparing hashes

http://beeblebrox.org/hashtab/

Thanks for the reply and link to HashTab. I did locate version 3.00. I thought I remembered it able to handle larger files than version 3.05, but I was wrong.

[enuffsaid]

PE Explorer

http://www.heaventools.com/overview.htm

[DigeratiPrime]

PE Explorer

http://www.heaventools.com/overview.htm

I had to check, PE Explorer shows the Real Checksum (real) and the Link Checksum (header) and can update the latter to match. Of course it does much more than that

[CoffeeFiend]

They're completely different beasts. PE explorer is an expensive tool that lets you see (and fix if needed) the "special" hashing used by PE exe's.

Hashtab (and md5sum and what not) all perform plain old standard file hashing (not the same thing at all).

Edited January 5, 2009 by crahak

[Martin H]

There are a bunch of good Hash calculating/verifying apps available(i prefer the command-line fsum.exe), and IMHO, then the only need for Msft's CRC verification tool, is if wanting to verify the AutoCRC value of MSDN ISO's, or other ISO's made with cdimage.exe's -x switch, and for that, then v3.05 is just fine...

Just my 2 cents, though

[CoffeeFiend]

There are a bunch of good Hash calculating/verifying apps available

Writing a basic md5 or sha-1 hashing cmd line util only takes like 5 minutes anyways

the only need for Msft's CRC verification tool, is if wanting to verify the AutoCRC value of MSDN ISO's, or other ISO's made with cdimage.exe's -x switch, and for that, then v3.05 is just fine...

As long as the ISO is under 4GB, that is (it's like 12 years old, no surprises here).

[jaclaz]

Possibly one of the hugest bumps in the history of msfn.org, but just checked, and the file is available through Wayback Machine:

https://web.archive.org/web/20060915000000*/http://tacobell.iexbeta.com/longhorn/crc.exe

 

Just for information, the output of CRC.EXE (version 3.0) on a valid .iso image created with cdimage.exe -x switch is:

CRC Verification Utility, Version 3.00Copyright (C) Microsoft, 1992-1996100% completeAutoCRC signature for file TEST.ISO is 0x003D685EAutoCRC indicates the file TEST.ISO is VALID

it's output for the SAME .iso created without the -x switch (and that is 2 sectors, i.e. 4096 bytes, smaller) is:

CRC Verification Utility, Version 3.00Copyright (C) Microsoft, 1992-1996100% completeCRC of file TEST.ISO is 0x8EE79268

"Normal" CRC32 of the first is FFFFFFFF, whilst the one of the second is 8EE79268.

 

In my test there is an inserted sector @Sector 321 and one appended at the end of the image.

 

322 sectors x 2048= 659.456 which in hex is 0xA1000.

 

In other tests this "inserted sector" is in other places, like 0x6D000, or 0x29800 (I did only a few "random" tests to get the "feeling" of it).

 

It would be interesting to understand how exactly this "inserted sector position is calculated/implemented, as at first sight it seems a "queer" behaviour, but of course the relevance of this piece of info for all practical uses amounts to 0 (zero).

 

 

jaclaz

[dencorso]

It has to do with the addition of the rather cryptic ExclCRC and AutoCRC in those same sectors, to fudge up the final CRC-32 value...

 

As for MS CRC-32 v. 3.0, MDGx offers yet another link, which is a direct download link (also preserved through the wayback machine), among his rather comprehensive collection of checksum tools.

[jaclaz]

It has to do with the addition of the rather cryptic ExclCRC and AutoCRC in those same sectors, to fudge up the final CRC-32 value...

 

Sure, I know.

 

The point I was trying to make is that the info in the above link is "partial".

 

The ExclCRC and AutoCRC are not only inside an added sector at the end, there are TWO instances of them, one in a sector appended and one in a sector "inserted" at a variable address inside the .iso.

 

If you prefer, UNlike what would have been "logical" the difference between a same .iso created with or without the -x switch is not just an appended sector.

 

Just another case of the good MS guys using the secret 7 on the dice :

http://homepage.ntlworld.com./jonathan.deboynepollard/Humour/microsoft-monopoly.html

 

jaclaz

[jaclaz]

To finalize this thread, I checked.

The additional sector is inserted at the end of the "file/directory records" and before the first actual file/directory contents.

Still remains to be understood what the "ExclCRC" data refers to.

I'll see if I can find an explanation.

jaclaz

[submix8c]

I can't seem to find what I had dug up at one time in reference to the EXCLCRC value. :dammit:

Here's a reference you probably  already have to AutoCRC though -

http://social.msdn.microsoft.com/Forums/en-US/4e7be6a3-5c9f-4fcd-aa34-6f3e687025b4/failed-downloading-net-framework-35-sdk-for-4-times?forum=windowssdk

[jaclaz]

Yep , that one is another one containing only partial (and partially wrong ) info.

The idea is to (hopefully) get complete and correct info INSTEAD.

Points are:

1. there is not a sector with the ExclCRC and AutoCRC values appended to the ISO file but TWO sectors, one "inserted" after the directory structure and one appended to the end of the .iso ^[1]
2. the "scope" of the AutoCRC value is "clear" and surely represents *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF*
3. the "scope" of the ExclCRC can only be guessed as *area to exclude from the calculation* but there are no real "proofs" that this guess is correct
4. how exactly the ExclCRC val is used and calculated is to be found
5. the CRC.EXE changes it's behaviour and can provide THREE types of output, if a valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered VALID, if a non valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered CORRUPT, if NO AutoCRC "label" is found in the last few bytes of the file the "normal" CRC32 is printed

jaclaz

 

^[1] I already verified that if the file is truncated after the inserted sector this initial part by itself will give a CRC32 of 0xFFFFFFFF

Edited May 17, 2014 by jaclaz

[dencorso]

the "scope" of the ExclCRC can only be guessed as *area to exclude from the calculation* but there are no real "proofs" that this guess is correct

 

No.

 

Since any application (I use the great Cody Batt's HashTag, but any other that calculates CRC-32 by the book will do) not aware of ExclCRC and AutoCRC does reach the target value of 0xFFFFFFFF, when calculating the CRC-32 of those images, it cannot be an "area to exclude". ExclCRC must instead be a fudge-factor included in the CRC-32 calculation, adjusted so that it gives the target value of 0xFFFFFFFF. Four bytes is all that's needed to fudge the CRC-32 seven ways to Sunday, as the little application HackCRC32 found on this page can nicely illustrate.