ImgBurn as gold standard for ISO confirmations by HASH?

[molecule]

It happens that I purchased a MS XP Professional CD that I and others suspect might be irregular. I bought it eyeball-to-eyeball at a big box store. To verify I am comparing SHA1 and MD5 hash values of my ISO with others of known origin, for confirmation that it's genuine.

 

The question is, Is there a gold standard for ripping an ISO, for purposes of computing a hash value for the CD?

 

For hash computation my iso was ripped with ImgBurn ... inspecting the ISO file in HxD editor, there are 32,767 null-bytes (0x00007FFF 0x00's) before the first non-null byte (which starts something like 0x01,C,D,0,0,1 ? from memory so might be wrong) and there are 311,296 null-bytes after the last non-null byte.

 

Are these lead-in and tail-out null-bytes a critical or reproducable part of the rip? How are they computed ... do they change, depending on how they are burned in? ... can there be a gold standard for computing hash values for an ISO of a CD?

 

The leading and trailing nulls might not (or they might!) affect operation. I don't know. But they will affect the computation of hash MD5 and SHA1, possibly making hash comparisions moot. If there's not a gold standard, then ... well, how about it ... let's do it!

 

edit ...

 

for those who are curious, the hash that I get for my XP pro SP3 OEM CD using ImgBurn is

Label: GRTMPOEM_EN.ISO

Size: 618,065,920

md5: cf044066e4a9193b388f628fa0c1be7e

sha1: 2bcaaf437bac27ddf6816b0f415fcef9bd85463f

 

The CD says its XP pro Version 2002 includes SP3. The setup program is however, XP Home, and when installed it looks like, XP Home. But the CD and the COA and the packaging all say XP Professional. I can't find confirmation for the hash values ... so wondering ...

 

Edited October 5, 2012 by molecule

[LIGHTNING UK!]

This isn't a suggestion (is it?) so I'm not sure why you posted it in the 'Suggestions' forum?

 

You'd be MD5'ing all of the sectors on the disc. They start from LBA 0 and run until 1 less than what's show for the size of the disc (The 'Sectors' value under 'Disc Information' in the box on the right).

 

So if that 'Sectors' value said 10, you'd read sectors (LBA) 0 - 9.

[molecule]

yes, I was thinking Suggestion ...

 

I'm hoping it would probably be a pretty simple to add (total noob here)

 

it would be a nice feature

AFAIK ImgBurn would be the first

 

the EZ-mode > Verify page is already setup for it and ready to go

 

under [select source CD drive] section

there already is a checkbox for Verify

[_] Verify against an image file

 

add two checkboxes under option for compute hash

[_] Compute MD5 hash value for this CD

[_} Compute SHA1 hash value for this CD

 

I think the exe's are both relatively small and open source ... maybe they could go in the ImgBurn directory?

 

user enters CD, selects hash options, presses the [verify-go] button

 

ImgBurn then opens a popup box with progress bar

reads CD, computes the hash(s), and displays results

after progress bar and results are displayed

the popup offers user options (previously greyed-out)

[_] save hash value(s) to file [name...] [browse...]

[_] copy hash results to clipboard

 

user can verify CD hash without ripping iso, and finding and running hash exe ... then deleting files to clean hdd, etc.

 

by being the first CD tool to add this, ImgBurn would become the gold standard for CD verification by hash computation ...

 

I think it would be a nice option to add! I'm pretty sure lots of others would also feel the same way.

 

===

 

you mentioned build iso from sectors 0 to (x -1) where x is number of sectors

 

is that what ImbBurn does automatically?

 

IF that's the case, then hash computed on ImgBurn iso should be the hash value for the CD. That's what I wanted to confirm. That the [0 to X-1] should be the standard for computing CD hash values.

 

(I didn't see where I could select start and end points to pull an iso. Don't want to if I don't have to ... just want a hash to verify my hologram CD is not corrupt one. If I gooogle on a valid SHA1, there will be lots of answers ... if google of hash is null, it's a probably a bad CD ...)

 

Also just curious ... any idea what would happen if I hex edited the leading and trailing 0x00's from the iso file, and then tried to burn the iso to CD and run it without leading and trailing 0x00s?

 

Thanks!

 

==

 

ps ... sorry if this is a duplicate post ... I must have done something wrong on the first

[LIGHTNING UK!]

You can already get ImgBurn to display the MD5 of an image it creates by reading a disc or whatever.

 

Tools -> Settings -> General -> Page 2 -> Calculate MD5 Hash Values.

 

The values then get written to the log window.

[molecule]

I understand from this site http://twiki.org/cgi-bin/view/Wikilearn/CdromMd5sumsAfterBurning that some CD burners automatically add 0x00 padding after the End of CD code. Apparently some kernels crash if they can't look ahead or something.

 

So in linux this fellow got his hash values to work consistently by computing hash only from sectors 1 to EOCD by running them through pipes

$ dd if=/dev/cdrom | head -c 682575872 | md5sum
1333162+0 records in
1333161+0 records out
7a0479dc917d35bd822cecb558c8d432

 

one of the patrons at msfn.org got different md5 values from iso files pulled from same cd. Nero and MagicIso gave standard results per internet and google ... ImgBurn gave a different hash result. I assume your iso is exact image of CD, including padding of trailing 0x00s, and he was verifying hash from the pulled ISO.

 

MD5 and SHA1 really belong with other verify functions ... why hide them under page 2 of General Tab, so my suggestion still stands. People will find them quicker under the Verify Tab? (which is a great tab to have!)

 

Also, for some reason unbeknownst to me, but SHA1 seems to be what everybody is using for CDs ... arghhh! they use MD5 for everything else. So, it would be nice if you could add an either-or choice, MD5 or SHA1 to verify. Then the ISO rip could exactly replicate the CD including trailing 0x00s (which some burners apparently add to keep kernel look-ahead from crashing ... I'm actually clueless ... noob here talking) and meanwhile, MD5 and SHA1 could stop computation right at the EOCD marker.

 

edit -- also nice to show results in a small popup called verify hash or something, rather than buried in the log file (it scrolls too fast, not intuitive to look there for verify hash value ...)

 

thanks!

Edited October 9, 2012 by molecule

[molecule]

just curious ... for computing hash values, are there standard codes or hex strings that I could look for, that would mark the "formal" (arghhh) beginning of a CD file system, and the end of the CD file system inside an iso file that has leading and/or trailing 0x00 padding (that different burners might add for whatever reason ... to make the CD disk more universally compatible with the technology of different CD drives?)

 

would those start codes and end codes occur exactly at the beginning or end of the respective CD sector? --edit2-- or of the 16x or 32x multiple of sectors (depending on media the iso was written to) per the excellent reading CD and writing CD guides on this forum. Since padding is variable, depending on choice of burner or media, it seems like it should be excluded from the hash value?

 

edit1 -- when ImgBurn computes MD5 does it include just the file system within the CD, excluding 0x00 padding added by burners for drive compatibility, or, does it compute hash for the entire CD itself (CD-sector 0 to CD-last sector) including the 0x00 padding?

 

thanks

Edited October 9, 2012 by molecule

[LIGHTNING UK!]

You should start at the first byte in Sector 0.

 

There is no end marker, that's why you just go by the 'capacity' of the disc.

 

If programs choose to limit what they read to a value written in a file system within the image, that's down to them. Doing so isn't fool proof though and that's why I don't do it - unless reading from a DVD+RW / BD-RE where it can actually make a massive difference (because the disc capacity is always reported as the full/maximum capacity of the disc).

 

When ImgBurn is used to 'Build' an ISO, it always does so in a way that drive padding isn't an issue/used.