January 3, 200917 yr 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.
January 4, 200917 yr Is there a specific need for that software? I personally use the HashTab (freeware) shell extension for comparing hashes http://beeblebrox.org/hashtab/
January 4, 200917 yr Author 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.
January 5, 200917 yr PE Explorer http://www.heaventools.com/overview.htmI 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
January 5, 200917 yr 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, 200917 yr by crahak
January 5, 200917 yr 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
January 5, 200917 yr There are a bunch of good Hash calculating/verifying apps availableWriting 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).
May 14, 201412 yr 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 VALIDit'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
May 14, 201412 yr 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.
May 14, 201412 yr 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
May 17, 201412 yr 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
May 17, 201412 yr 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
May 17, 201412 yr 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: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]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* 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 how exactly the ExclCRC val is used and calculated is to be found 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 printedjaclaz [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, 201412 yr by jaclaz
May 17, 201412 yr 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.
Create an account or sign in to comment