SCIENTIFIC-LINUX-USERS Archives

November 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Tue, 5 Nov 2013 08:43:59 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
If you're in a rush, comparing the file sizes and the "sum" command
output, rather than the computationally intense md5sum, gives a much
faster verification of two orthogonally related components. While not
as certain as md5sum, the orthogonal verification of the size adds
considerable verification.

However, in this case, it's pointless to use checksums. Simply use the
"cmp" command, which compares the bytes of the files in question.

On Mon, Nov 4, 2013 at 8:07 PM, Yasha Karant <[log in to unmask]> wrote:
> On 11/04/2013 04:53 PM, ToddAndMargo wrote:
>>
>> On 11/04/2013 04:21 PM, Yasha Karant wrote:
>>>
>>> I need to do a media comparison between a data DVD and the .iso file
>>> that purportedly contains the image of the exact DVD (including any
>>> bootable or autoload binary files, not for an Intel instruction set
>>> architecture).
>>>
>>> When burning to the DVD, applications such as K3B and Nero (for Linux)
>>> will do a verify of the burned media.  My understanding is that these
>>> applications go through the device driver and device controller
>>> hardware/firmware that may be applying error correction to the raw bit
>>> stream; any such detected "hardware media" errors typically are reported
>>> by the driver to a log file, but typically (if corrected) do not cause
>>> the application to fail.
>>>
>>> If one mounts the .iso file, by a command similar to that below,
>>>
>>> # mount -t iso9660 -o ro,loop=/dev/loop0 /files/dvdimage.iso
>>> /media1/virtualdisc
>>>
>>> and likewise has the physical DVD in the DVD drive and mounted from,
>>> say, /dev/sr0
>>>
>>> will a diff /dev/loop0 /dev/sr0 suffice?
>>>
>>> Is there a utility that will do the same thing that Nero would do as it
>>> verifies after burning, but not requiring the burn -- that is, verify a
>>> DVD against an ISO image file?
>>>
>>> If /dev/sr0 were mounted on, say, /media/someDVD, and the ISO image
>>> file on
>>> /media1/virtualdisk , is there a utility or script to do a "bit by bit"
>>> comparison via the mount points (not just the "raw" mount as /dev/sr0 )?
>>>
>>> Yasha Karant
>>>
>>
>>
>> Hi Yasha,
>>
>> Check the DVD as a raw device.
>>
>> After you burn the ISO, eject the DVD (clears out something,
>> I don't know what, but had to learn the hard way):
>>     /usr/bin/eject /dev/sr0
>>
>> Then inject the DVD (close the door).  Can be on the same
>> line.
>>     /usr/bin/eject -t /dev/sr0
>>
>> Then make an MD5SUM of each
>>     md5sum /files/dvdimage.iso /dev/sr0
>>
>> Eyeball the sums.  One will be on top of the other.
>>
>> If you like, I have some leftover code I can send you.
>>
>> -T
>>
>>
>
> From http://en.wikipedia.org/wiki/Md5sum
>
> As with all such hashing algorithms, there is theoretically an unlimited
> number of files that will have any given MD5 hash. However, it is very
> unlikely that any two non-identical files in the real world will have the
> same MD5 hash, unless they have been specifically created to have the same
> hash.
>
> End quote.
>
> I explain the above reality to my students, although I do use MD5SUM myself.
> I was hoping for a utility that did a true bit-by-bit comparison of the two
> files.
>
>
> Aside:  Note that a (very) clever attacker can embed specific issues into a
> file such that the corrupted (and perhaps infected) file will pass a MD5
> hash test.  Note that USA NSA and other entities often do employ such clever
> persons (do recall the cyber attack on the fissile material enrichment
> facilities of a Middle Eastern nation state not in full agreement with USA
> foreign policy, albeit an attack not specifically limited to this
> mechanism).  I am not suggesting that the DVD and ISO image file I am using
> are subject to this sort of clever corruption; but, it is important to
> understand the limitations of certain techniques.
>
> Yasha Karant

ATOM RSS1 RSS2