Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

CRC Verifycation Utility, Version 3.00

- - - - -

  • Please log in to reply
21 replies to this topic

#1
heustess

heustess
  • Member
  • 7 posts
  • Joined 28-July 05

Does anyone have a copy of Microsoft's CRC Verifycation Utility, Version 3.00 that was once at http://tacobell.iexb...onghorn/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.




How to remove advertisement from MSFN

#2
DigeratiPrime

DigeratiPrime

    MSFN Junkie

  • Patrons
  • 3,550 posts
  • Joined 18-August 04
  • OS:Windows 7 x64
  • Country: Country Flag
Is there a specific need for that software? I personally use the HashTab (freeware) shell extension for comparing hashes :)
http://beeblebrox.org/hashtab/
Recommended Software: KeePass | Microsoft ICE | VisualWget | Vitamin D Video |

#3
heustess

heustess
  • Member
  • 7 posts
  • Joined 28-July 05

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.

#4
enuffsaid

enuffsaid

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 866 posts
  • Joined 26-December 03
PE Explorer
http://www.heaventoo...om/overview.htm

#5
DigeratiPrime

DigeratiPrime

    MSFN Junkie

  • Patrons
  • 3,550 posts
  • Joined 18-August 04
  • OS:Windows 7 x64
  • Country: Country Flag

PE Explorer
http://www.heaventoo...om/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 ;)
Recommended Software: KeePass | Microsoft ICE | VisualWget | Vitamin D Video |

#6
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • Joined 14-July 04
  • OS:Windows 7 x64
  • Country: Country Flag
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, 04 January 2009 - 09:08 PM.

Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#7
Martin H

Martin H

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 802 posts
  • Joined 24-November 06
  • OS:none specified
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 :)

/* Moved to Linux - Thanks for a nice stay all! */
Posted Image


#8
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • Joined 14-July 04
  • OS:Windows 7 x64
  • Country: Country Flag

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).
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#9
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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....onghorn/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.00
Copyright (C) Microsoft, 1992-1996

100% complete

AutoCRC signature for file TEST.ISO is 0x003D685E

AutoCRC 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.00
Copyright (C) Microsoft, 1992-1996

100% complete

CRC 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



#10
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,952 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.



#11
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.ntlw...t-monopoly.html

 

jaclaz



#12
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
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

#13
submix8c

submix8c

    Inconceivable!

  • Patrons
  • 4,331 posts
  • Joined 14-September 05
  • OS:none specified
  • Country: Country Flag

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.m...orum=windowssdk


Someday the tyrants will be unthroned... Jason "Jay" Chasteen; RIP, bro!

Posted Image


#14
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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, 17 May 2014 - 01:53 PM.


#15
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,952 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.



#16
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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



#17
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,952 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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?



#18
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

Attached Files



#19
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,952 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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



#20
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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.o.../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"

Attached Files



#21
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,952 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

 "Improvise, Adapt, Overcome"

 

 

clapping.gif



#22
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,579 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

Small update.

There are a set of programs here:

https://web.archive....zzyk/index.html

https://web.archive....izzyk/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.n...?topicid=495063

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

https://github.com/r...ulator/releases

Current:

https://github.com/r...ip-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.gamerzpla...everse-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.source...ogue/17plus.htm

 

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

 

jaclaz

 

 






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users