19

I have an ISO file, which I burned to a CD. Now how can I check if the CD is correctly created? I would like a command that calculate the hash sum that I can use to check with the hash sum I calculate on the ISO file. Ideally the command should:

  • Work regardless of the ISO file: that is, I don't want to keep a list of hash sum for each file in the disc, or remember the number of blocks whatever
  • Be relatively short: a one-line command is great, a chain of commands which is two line long is OK, a script that span one page is not
  • Be fairly efficient: for example, dd the disc back to a file then run md5sum on the file is unacceptable

If there is no answer that cannot satisfy all I will appreciate the nearest match too. Even better if you can tell me why it is not so straight-forward.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
phunehehe
  • 20,030
  • 27
  • 99
  • 151

3 Answers3

19

The basic problem is that we want to take the md5sum of the exact same information that was on the ISO originally. When you write the ISO to a CD, there is likely blank space on the end of the disk, which inevitably changes the md5sum. Thus, the the very shortest way:

md5sum /dev/cdrom

doesn't work. What does work (and is common in online documentation) is only reading the exact number of bytes from the device and then doing the md5sum. If you know the number of bytes you can do something like:

dd if=/dev/cdrom bs=1 count=xxxxxxxx | md5sum

where 'xxxxx' is the size of the iso in bytes.

If you don't know the number of bytes off hand, but have the iso on your disk still, you can get them using ls by doing the something like the following (taken from here):

dd if=/dev/cdrom | head -c `stat --format=%s file.iso` | md5sum

There are many other one-line constructions that should work. Notice that in each case we are using dd to read the bytes from the disk, but we aren't piping these to a file, rather, we are handing them to md5sum straight away.

Possible speed improvements can be made by doing some calculations to use a bigger block size (the bs= in the dd command).

Steven D
  • 45,310
  • 13
  • 119
  • 114
  • You can simplify `dd if=/dev/cdrom |` to ` – Gilles 'SO- stop being evil' Nov 05 '10 at 18:26
  • By the way, you (phunehehe) should have the iso size together with the MD5 checksum. This is particularly important for MD5 which is partially broken, but it's a good idea for both security and usability no matter what checksum you use. – Gilles 'SO- stop being evil' Nov 05 '10 at 18:34
  • @Gilles: actually, using `dd` with `bs` of the device cache size can speedup data transfer as opposed to plain input redirection. – alex Nov 06 '10 at 04:51
  • @Gilles: what do you mean by "MD5 which is partially broken"? And why should I keep the file size, when if something is wrong the checksum should tell me right away? – phunehehe Nov 06 '10 at 10:15
  • @phunehehe: There are [known cryptographic weaknesses with MD5](http://en.wikipedia.org/wiki/MD5#Security) (it is not (publicly) known how to generate a collision for a given file, but it could come). Knowing the file size gives you a little more confidence (though not much more). It also gives you immediate feedback for common accidental errors such as truncated downloads. – Gilles 'SO- stop being evil' Nov 06 '10 at 11:56
  • @alex: `dd` with a large `bs` can speed up data **transfers** between two local drives (even more so between two locations on the same local drive) (typically a few MB gives you top speed, though I don't think it's related with any device cache size). Here there is no disk-to-disk transfer, only disk-to-memory, so all the extra `dd` step does is to *add* a (probably negligible) bit of running time (there is no advantage on the disk side, and there is one extra memory-to-memory copy step, but it's dwarfed by the MD5sum calculation). – Gilles 'SO- stop being evil' Nov 06 '10 at 12:00
  • @Gilles: ok, my experience was with using `dd` to backup drive partitions, so you're probably right. – alex Nov 06 '10 at 13:11
  • It is not a correct way, because disk FS contains date of burning, so, you can't validate this md5 against iso's md5. – Jury Jun 06 '16 at 12:30
2

There is program for this task. It's called - checkisomd5. In Ubuntu it can be installed by command:

sudo apt-get install isomd5sum
Денис Проскурин
  • 39
  • 1
  • 5
  • How do you use it? `checkisomd5 /dev/sr0` gives me: The media check is complete, the result is: NA. No checksum information available, unable to verify media. – Torsten Dec 07 '19 at 14:25
  • Checksum should be embeds in iso image with tool "implantisomd5". It's have to done before iso will be write on disk. Utility included in "checkisomd5". – Денис Проскурин Dec 11 '19 at 00:32
1

If the size of the image on the disc is divisible by 2048, whole number, which seems to be very common, then you can get an accurate MD5sum as follows where sr0 is the name of the optical -which can be found using, lshw -C disk- and where 'count' is the dividend of the image size divided by 2048.

dd if=/dev/sr0 bs=2048 count=356352 |md5sum
wsmart
  • 11
  • 2
  • Many CDs likely use "Mode 1" tracks, which [has 2,048 bytes of user data per sector](https://en.wikipedia.org/wiki/CD-ROM#CD-ROM_format). ("Mode 2" stores 2,336 bytes of user data per sector, but lacks the more advanced error detection and correction capabilities offered by Mode 1, causing Mode 2 to be less useful for data where errors cannot be tolerated.) – user Oct 07 '15 at 09:33