Sign in to follow this  
Followers 0
heustess

CRC Verifycation Utility, Version 3.00

22 posts in this topic

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.

0

Share this post


Link to post
Share on other sites

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 by crahak
0

Share this post


Link to post
Share on other sites

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 :)

0

Share this post


Link to post
Share on other sites
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).

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

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. :unsure:

jaclaz

0

Share this post


Link to post
Share on other sites

Yep :), that one is another one containing only partial :w00t: (and partially wrong :ph34r:) 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 by jaclaz
0

Share this post


Link to post
Share on other sites

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. :D

 

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.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.