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

Yes and No. :yes::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

0

Share this post


Link to post
Share on other sites

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?

0

Share this post


Link to post
Share on other sites

Is this true?

Why don't you try it yourself?  :unsure:

 

It is a rather straightforward experiment. :yes:

 

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

 

jaclaz

2xFFFFFFFF.7z

0

Share this post


Link to post
Share on other sites

Is this true?

Why don't you try it yourself?  :unsure:

 

It is a rather straightforward experiment. :yes:

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! :thumbup

0

Share this post


Link to post
Share on other sites

Whenever something is beyond :blushing: one's capabilities or knowledge  :w00t::ph34r:, there is often anyway a solution, which is - obviously - cheating[1]! ;)

 

As a teaser :whistle:, 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

0

Share this post


Link to post
Share on other sites

 "Improvise, Adapt, Overcome"

 

 

clapping.gif

0

Share this post


Link to post
Share on other sites

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  :ph34r: 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. :yes:

 

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

http://reveng.sourceforge.net/

I am (and will presumably be for the next several days/weeks :w00t:) 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"  :o .

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 :blushing: the usage of CRC reveng .... 

 

jaclaz

 

 

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.