Przejdź to tekstu

Weryfikacja sum kontrolnych nagranego obrazu .iso

Kategoria: Artykuły, etykiety: suma kontrolna, dvd, cd, sha512sum, sha256sum, sha1sum, md5sum, iso

Dodany przez: morfik, 2013-03-07 23:39 (zmodyfikowany: 2013-10-31 14:47)

Wyświetleń: 11082

Sumy kontrolne dają możliwość sprawdzenia czy dane zawarte w pliku nie zostały zmienione podczas transferu z jednego medium informacyjnego na inne. Dane przesyłane przez sieć są dzielone na małe pakiety. Jedna z maszyn, ta wysyłająca dane, tworzy sumę kontrolną i dołącza ją do pakietu. Komputer odbierający pakiet postępuje podobnie - poza wygenerowaniem sumy kontrolnej, musi jeszcze porównać utworzoną przez siebie sumę z tą zawartą w pakiecie. W przypadku gdy sumy się nie zgadzają, mamy do czynienia z błędami przesyłu - pakiet został uszkodzony po drodze od jednej maszyny do drugiej. W takim przypadku maszyna odbierająca dane prosi o ponowne przesłanie uszkodzonego segmentu. Gdyby maszyny łączyły się ze sobą bezpośrednio i to zabezpieczonym połączeniem, tak by nikt z zewnątrz nie mógł się podłączyć, wszystko by było fajnie. Problemy są jednak dwa. Pierwszy z nich to taki, że pakiety przechodzą przez szereg maszyn. Możemy sprawdzić jak wygląda trasa przykładowego pakietu za pomocą traceroute:

$ traceroute google.com
traceroute to google.com (173.194.40.69), 30 hops max, 60 byte packets
1  192.168.22.33 (192.168.22.33)  13.150 ms  13.217 ms  15.708 ms
2  192.168.22.33 (192.168.22.33)  19.670 ms  26.397 ms  31.732 ms
3  88-199-232-137.tktelekom.pl (88.199.232.137)  37.674 ms  41.584 ms  46.527 ms
4  war-rp2-pos-2-0-2.tktelekom.pl (88.199.219.73)  49.909 ms  50.004 ms  50.051 ms
5  war-rp2-pos-2-0-2.tktelekom.pl (88.199.219.73)  50.221 ms  50.263 ms  50.392 ms
6  war-b2-link.telia.net (213.248.97.117)  50.059 ms  11.505 ms  13.075 ms
7  ffm-bb1-link.telia.net (213.155.134.212)  35.976 ms  40.125 ms  44.289 ms
8  ffm-b7-link.telia.net (80.91.249.105)  48.069 ms ffm-b7-link.telia.net (80.91.251.52)  51.763 ms ffm-b7-link.telia.net (80.91.254.249)  56.064 ms
9  google-118152-ffm-b7.c.telia.net (213.248.102.234)  60.609 ms google-ic-127674-ffm-b7.c.telia.net (213.248.89.38)  60.191 ms  60.414 ms
10  72.14.238.46 (72.14.238.46)  60.296 ms  60.551 ms  60.651 ms
11  72.14.232.121 (72.14.232.121)  68.698 ms  66.980 ms  66.779 ms
12  66.249.94.157 (66.249.94.157)  59.385 ms  39.845 ms  41.703 ms
13  zrh04s06-in-f5.1e100.net (173.194.40.69)  47.801 ms  49.154 ms  52.844 ms

Generalnie trasy o 30+ hopach są niezbyt efektywne i w przypadku wystąpienia takiej trasy, system jest zmuszony poszukać innej. Tak czy inaczej, na każdym hopie istnieje możliwość świadomej zmiany pakietu.

Drugim problemem jest pobieranie pliku z niezaufanych źródeł. Mamy szereg mirrorów, jak i również obrazy .iso na torrentach. Załóżmy, że poszukujemy obrazu .iso debiana. Co po pobraniu pliku należałoby zrobić, by mieć pewność, że jest on dokładnie taki jak oczekujemy? Trzeba sprawdzić jego sumę kontrolną. Dodatkowo, większość z nas pobiera obrazy .iso, nie tylko z debianem, by je wypalić na cd/dvd. Jak zatem sprawdzić czy wypalony obraz cd/dvd również nie zawiera błędów?

W przypadku weryfikacji sumy kontrolnej obrazu .iso, sprawa jest banalna. Mając pobrany obraz .iso, przechodzimy na http://www.debian.org/CD/http-ftp/ i szukamy płytki, którą rzekomo mamy na dysku. Zwykle obok obrazów .iso mamy podane pliki o nazwach: MD5SUMS, SHA1SUMS, SHA256SUMS, SHA512SUMS. Co oznaczają nazwy plików i jaka jest ich zawartość? Nazwy plików zawierają algorytm za pomocą którego zostały wygenerowane sumy kontrolne obrazów. A tak wygląda przykładowy plik SHA256SUMS:


4170c5968e38dff7f0e367aa1c763f16442e52b00bc64f67740668fad4d3d1e3  debian-testing-i386-DVD-1.iso
90266555fe028df29e40f99dfe663fa4e80087f9181b50a0ff45b4a0de0d3117  debian-testing-i386-DVD-10.iso
39725045d05dd74a41fb715f5bcd198c330933bf53228f90eb10ff1211d7d8b6  debian-testing-i386-DVD-2.iso
fbc024157698307ba07b9e83d88b01fe009427245cad547c9f44089ad8ac877a  debian-testing-i386-DVD-3.iso
e0dbb7e4d4ec302be2cd3d2595f164a2307557ed0d28163404e1c0c8d9802d29  debian-testing-i386-DVD-4.iso
52210892c7ad53916dfeb4343d0cd4efad9e99a90e91cd6dc39297b2a48755dc  debian-testing-i386-DVD-5.iso
262d7135205aabe9f269e65978fd23bba80f1aabd1140cddd4a6cb49e501fcdd  debian-testing-i386-DVD-6.iso
dc810bf09d97d97fa1ee923affd435f93ca57ac67d5d1bdb49de176ed0ce487f  debian-testing-i386-DVD-7.iso
bc454a1a0fda28e6e10ff04448b946fe64acf8152761411bc264732db02a9f66  debian-testing-i386-DVD-8.iso
a848ba0501f12be0853f3760197ce8f7af0b703105fd68575e28f9143960d639  debian-testing-i386-DVD-9.iso

Lewa kolumna zawiera sumy kontrolne wygenerowane za pomocą sha256sum, prawa zaś odpowiadające im pliki.

Ok, to mamy już punkt oparcia - sumę kontrolną. Jak teraz sprawdzić czy pobrany przez nas obraz .iso posiada dokładnie taką samą sumę kontrolną, która widnieje na serwerze? Najprościej jest odpalić sha256sum, podając w argumencie ścieżkę do obrazu .iso. W tym przypadku zostanie wyrzucony ciąg znaków, który następnie trzeba porównać z tym na stronie. Trochę to niezbyt praktyczne. Ja zwykle porównywałem dwa pierwsze i dwa ostanie znaki. Jeśli się zgadzały, zakładałem, że suma kontrolna się zgadza. xD Innym rozwiązaniem jest pobranie pliku z sumami z serwera (SHA256SUMS.txt) na dysk, do folderu z plikiem .iso i wydać polecenie sha256sum -c SHA256SUMS.txt . W przypadku gdy w pliku z sumami jest zdefiniowanych wiele linijek, dostaniemy sporo błędów. Dlatego też ze względów estetycznych najlepiej posiadać w pliku wpis od określonego obrazu lub obrazów .iso. Istnieje również skrypt, którym można się posłużyć.

Poniżej znajduje się przykład porównania sum kontrolnych:

$ sha256sum -c SHA256SUMS.txt 
debian-testing-i386-netinst.iso: DOBRZE

$ sha256sum -c SHA256SUMS.txt 
debian-testing-i386-netinst.iso: NIEPOWODZENIE
sha256sum: UWAGA: 1 policzona suma się NIE zgadza

Dla tych, którzy nie przepadają za konsolą są i graficzne narzędzia. Mi osobiście bardzo przypadł do gustu - GtkHash. Co w nim takiego ciekawego? Potrafi liczyć zarazem kilkadziesiąt sum, wystarczy wskazać mu plik lub listę plików albo nawet wpisać jakiś tekst, po czym wybrać interesujące nas algorytmy, a ten program nam to wszystko ładnie wyliczy. Dodatkowo nie musimy sprawdzać sum kontrolnych znak po znaku. Możemy po prostu skopiować sumę kontrolną z serwera i wklepać ją do programu. Jeśli przy którejś z wygenerowanych sum pojawi się zielona ikonka - integralność danych w obrazie .iso nie została naruszona.

Mamy zweryfikowany obraz .iso, czas go wypalić na cd/dvd. Po wypaleniu obrazu, można dość do wniosku, że sprawdzenie sumy kontrolnej zawartości płytki jest niemożliwe - przecie są tam setki plików, a nie jeden plik jak w przypadku obrazu .iso, który wypalaliśmy. Fakt, ale to tylko z naszej, ludzkiej perspektywy tak wygląda. Dla maszyny jest to zwyczajnie ciąg znaków, i jej wszystko jedno czy ma do czynienia z danymi w obrazie .iso na dysku czy danymi na płycie cd/dvd.

Niemniej jednak trzeba zapamiętać dwie rzeczy. Pierwsza, by poddawać sprawdzeniu dane raw, a druga to fakt, że obraz ma określony rozmiar, w bajtach. A płytki cd/dvd mieszczą z reguły więcej danych niż obrazy .iso. Co jest logiczne, gdyż w przeciwnym wypadku obraz .iso by się na płytę nie zmieścił.

Najprostszym sposobem na sprawdzenie integralności danych na płycie jest nakarmienie programu sha256sum danymi z urządzenia /dev/sr0. Ale, jak już wspomniałem, w tym przypadku, zostałaby wygenerowana suma kontrola całego nośnika, czyli wypalonego obrazu .iso z danymi oraz pustego miejsca. W wyniku czego uzyskalibyśmy inną sumę kontrolną.

Biorąc pod uwagę fakt, że dla maszyny jest wszystko jedno czy ma do czynienia z zerami czy jedynkami, to musimy wskazać jej miejsce, w którym ma skończyć liczyć sumę kontrolną nośnika cd/dvd. Jak to zrobić? Musimy sprawdzić jaki rozmiar w bajtach ma pobrany obraz .iso. Używamy do tego ls -l.

$ ls -l debian-testing-i386-netinst.iso 
-rw-r--r-- 1 morfik morfik 289406976 mar  6 15:50 debian-testing-i386-netinst.iso

289406976 - mamy rozmiar obrazu .iso w bajtach. Co dalej? Musimy nakarmić sha256sum danymi z /dev/sr0 o takiej długości. Posłuży nam do tego stary dobry dd.

$ dd if=/dev/sr0 bs=1 count=289406976 | sha256sum

Trzeba przy tym zauważyć by zwiększyć odpowiednio parametr bs, gdyż przy wartości 1, sprawdzanie sumy kontrolnej potrwa bardzo długo. Przy obrazach .iso można zastosować wielokrotność bs=2048. Przy czym trzeba pamiętać by liczbę bajtów podzielić przez wartość parametru bs, w tym przypadku będzie to 289406976/2048=141312. Odpalamy dd, dając bs=2048 i count=141312 i po chwili suma kontrolna zostanie wygenerowana. Porównujemy ją z sumą kontrolną obrazu .iso, jeżeli się zgadzają, to wszystko jest ok. W przypadku gdyby sumy się nie zgadzały, została naruszona integralność danych na nośniku i trzeba płytkę wypalać jeszcze raz.

Jeszcze taka uwaga: zarówno dd jak i sha256sum (czy w ogóle programy liczące sumy kontrolne) nie posiadają paska postępu i tak naprawdę nie wiadomo ile czasu zostało do zakończenia operacji. Jeśli mamy do czynienia z małymi plikami, problem może się wydawać nieistotny, ale co w przypadku gdy liczymy sumę kontrolną większego obrazu albo kopiujemy partycję przy pomocy dd, która może mieć przecie parędziesiąt GiB? Natknąłem się na narzędzie, które umożliwia lepszy wgląd w sytuację podczas wykonywania powyższych czynności. Jest to pv i znajduje się w pakiecie o tej samej nazwie.

Jego obsługa jest dość prosta jeśli chodzi o pokazanie progress bara przy zliczaniu sumy kontrolnej pliku:

$ pv obraz.iso | md5sum
 238MB 0:00:08 [32.7MB/s] [>                                ]  1% ETA 0:08:09

Jak widać na powyższym przykładzie, mamy prędkość z jaką postępuje operacja oraz szacowany czas do jej zakończenia.

Problem jednak zaczyna się gdy w grę wchodzi obsługa dd -- pv trzeba dodać po parametrze if=:

$ dd if=/dev/sdb bs=2M | pv | md5sum
 214MB 0:00:12 [  18MB/s] [                 <=>                             ]

Jak widzimy, nie ma tam szacowanego czasu do zakończenia operacji. Można oczywiście wnioskować po prędkości i ilości przetworzonych danych ale jeśli nie chce nam się tego liczyć i przy tym znamy przybliżony rozmiar urządzenia/obrazu (w tym przypadku 16GB/14,5GiB), możemy dodać odpowiedni parametr i program wyliczy szacowany czas za nas:

dd if=/dev/sdb bs=2M | pv -s 15G | md5sum
  88MB 0:00:05 [  18MB/s] [>                                ]  0% ETA 0:14:27

Tekst powstał w oparciu o artykuł HowToMD5SUM, który znajduje się pod adresem https://help.ubuntu.com/community/HowToMD5SUM.

OSnews Wykop Blip Flaker Kciuk Śledzik Facebook Identi.ca Twitter del.icio.us Google Bookmarks