Co to są sumy kontrolne plików i do czego mogą nam się przydać?

Dziś temat, który będzie pomocny przy pobieraniu dużych plików – sprawdzimy, czy pliki te nie uległy uszkodzeniom ani przekłamaniom podczas transmisji przez sieć i zapisu na dysk. W teorii nie musimy tego robić bo sieci TCP/IP korygują błędy transmisji a dyski twarde są niezawodne. W praktyce warto zerknąć na sumy kontrolne bo sieci TCP/IP niemal perfekcyjnie korygują błędy transmisji a dyski twarde są prawie niezawodne.

Sumy kontrolne przydadzą się też zawsze wtedy, gdy chcemy zweryfikować lub zagwarantować zgodność kopii pliku z oryginałem.

Łyk historii czyli skaczemy do lat ‘80

Dawno, dawno temu, dane między systemami informatycznymi transmitowano za pomocą modemów czyli urządzeń, które pozwalały na przesyłanie informacji poprzez łącza tradycyjnej telefonii analogowej. Takiej z kablami, centralami telefonicznymi i dziesiątkami drutów ciągnących się wzdłuż szosy. Do gniazdka w ścianie – zamiast ebonitowego aparatu z tarczą – podłączona była mała skrzyneczka, która podczas działania emitowała charakterystyczne modulowane piski, pozwalające na przesłanie – zamiast głosu rozmówców – kilkuset bajtów na sekundę.

Łącza analogowe transmitowały dźwięk przeciętnej jakości. Gdy spadł deszcz i kable w studzienkach zamokły, normą były szumy, stuki i trzaski. Każde tego typu zakłócenie wprowadzało przekłamania w transmisji danych prowadzonej przez modemy. Jedynki zamieniały się w zera, zera w jedynki, dane ulegały uszkodzeniu.

W transmisji modemowej (oraz innych asynchronicznych łączach szeregowych, np. w dalekopisach) stosowano więc tak zwany bit parzystości, dodawany do każdego transmitowanego bajtu (bajt to 8 bitów, bit parzystości to dziewiąty symbol zera lub jedynki). Niósł on informację dotyczącą tego, czy w przesłanym właśnie bajcie liczba jedynek była parzysta czy nieparzysta – dzięki temu przekłamanie pojedynczego bitu mogło zostać wykryte a transmisja powtórzona. Niestety, jednoczesna zamiana dwóch albo czterech bitów pozostawała niezauważona.

Łyczek historii, czyli lata ‘90

Modemy przyspieszyły kilkadziesiąt razy, użytkownicy przesyłali sobie pliki liczące kilkaset kilobajtów, jakość łączy telefonicznych poprawiła się jednak tylko trochę. Potrzebne były lepsze algorytmy korekcji danych – by zagwarantować spójność przesyłanych informacji.

Protokoły takie, jak ZMODEM dzieliły dane na bloki po kilka tysięcy bajtów, każdy opatrzony był osobną wartością cyklicznego kodu nadmiarowego (CRC) pozwalającą na wykrycie znakomitej większości usterek w transmisji. Pominiemy arytmetykę dzielenia wielomianów – dość powiedzieć, że popularny kod CRC-32 pozwalał na wykrycie wszystkich usterek jedno- i dwubitowych, świetnie radził sobie też z dłuższymi przekłamaniami (np. w przypadku nieprawidłowych czterech bitów szansa na przeoczenie usterki to mniej niż 1 na 90000). Jeśli poprawność odebranego bloku nie została potwierdzona przez odbiorcę, nadawca transmitował go ponownie, aż do skutku. Spowalniało to transmisję, jednak zwiększało jej niezawodność.

Z powrotem w teraźniejszość

W dzisiejszych czasach – paradoksalnie – kontrola poprawności transmisji w sieciach TCP/IP wcale nie jest skuteczniejsza, nie ma zresztą takiej potrzeby. To jakość okablowania i osprzętu sieciowego poprawiła się na tyle, że przekłamania umykające algorytmom korekcji zdarzają się bardzo rzadko, zaś zbyt liczne wykryte błędy transmisji mogą być raportowane użytkownikowi bądź administratorowi sieci.

Znacznie częściej usterki w zapisanych plikach będą skutkami “podkręcania” nominalnej częstotliwości pracy procesora lub kości pamięci. Układy te nie zawiodą od razu, lecz – pracując w zbyt wyśrubowanych warunkach – zaczną generować błędy. Mając wielkiego pecha możemy też doświadczyć sytuacji, w której wysokoenergetyczna cząsteczka promieniowania kosmicznego zmieni wartość bitu w pamięci RAM, co uszkodzi blok danych przeznaczony do transmisji lub zapisania na dysku.

Prawdopodobieństwo pojedynczej usterki jest tym większe, z im większymi plikami mamy do czynienia. Pliki o rozmiarach gigabajtów nie są dziś rzadkością, a gigabajt to przecież miliard* bajtów. Chcielibyśmy upewnić się, że pobrany plik ma dokładnie taką samą zawartość, jaka została wystawiona do pobrania na zdalnym serwerze.

Wykrywanie złośliwych modyfikacji pliku

Zmiana zawartości pliku względem oryginału może nie być przypadkiem lecz dziełem przestępców. Szczególnie narażeni będą tu amatorzy pirackiego oprogramowania pobieranego z nieautoryzowanych źródeł – mają sporą szansę, że w instalatorze nielegalnej kopii gry lub programu znajdzie się także wirus, malware, ransomware lub inna forma infekcji (terminy te będą wyjaśnione w jednym z kolejnych tekstów).

Jeśli znamy wartość sumy kontrolnej oryginalnego pliku, możemy obliczyć i porównać z nią sumę kontrolną dla pliku zapisanego na naszym dysku. Jeśli wartości te będą identyczne, mamy pewność, że nie doszło do nieautoryzowanej ingerencji w zawartość pliku – nawet, jeśli pobraliśmy plik z alternatywnego źródła.

Jest tylko jedno ale – do takich celów potrzebujemy troszkę lepszych sum kontrolnych niż CRC, bo tu łatwo jest tak spreparować zawartość pliku, że wartość obliczona przez CRC będzie jednakowa dla pliku oryginalnego i zmodyfikowanego. Od tej cechy wolne są tzw. kryptograficzne funkcje skrótu, wykluczające podobne fałszerstwa. Przykładem takiej funkcji jest SHA-256. Do samej tylko kontroli poprawności transmisji nadal wystarcza CRC, gdzie obliczenia są bez porównania prostsze i szybsze.

Pobierałem plik przez godzinę, jak teraz sprawdzić jego poprawność?

Przyjmijmy, że pobraliśmy sobie plik z obrazem instalacyjnym Linuksa Ubuntu w wersji 18.04 LTS czyli wydanie z kwietnia 2018, wariant o przedłużonym okresie wsparcia serwisowego (Long Time Support). Przykład bierze się oczywiście stąd, że ten plik mam już akurat na dysku. Zapisałem go pod oryginalną nazwą ubuntu-18.04.1-desktop-amd64.iso – jest to wersja dla użytkowników końcowych (w odróżnieniu od edycji serwerowej), posiadaczy procesorów 64-bitowych zgodnych ze standardem x86. Rozmiar pliku to 1.8 GB.

Co teraz? Po pierwsze musimy poznać sumę kontrolną obliczoną przez wydawcę tego pliku. Stare edycje Ubuntu są do pobrania tutaj: http://old-releases.ubuntu.com/releases/18.04.1/

Widzimy tam pliki MD5SUMS, SHA1SUMS oraz SHA256SUMS zawierające – odpowiednio – sumy kontrolne obliczone funkcjami MD5, SHA-1 oraz SHA-256. Mamy też pliki o rozszerzeniu GPG, do nich wrócimy kiedy indziej – wówczas okaże się, dlaczego w tym przypadku (wyjątkowo!) możemy bez obaw pobrać pliki przez nieszyfrowane połączenie HTTP.

Zajrzyjmy do pliku http://old-releases.ubuntu.com/releases/18.04.1/SHA256SUMS

Zaznaczona linia zawiera wartość funkcji skrótu SHA-256 dla pliku, który pobrałem jakiś czas temu. Jak mogę policzyć tę wartość dla kopii, którą mam na swoim dysku? Metod jest wiele, pokażę dwie.

Metoda 1 – Total Commander

Menedżer plików Total Commander to oprogramowanie, którego używam od dwudziestu kilku lat (wcześniej był DOS Navigator, przed nim zaś – Norton Commander). Wśród miliona użytecznych funkcji znajdziemy także obliczanie sum kontrolnych: zaznaczamy plik, wybieramy menu Pliki → Utwórz plik(i) sum kontrolnych… (Files → Create checksum file(s)…).

W oknie dialogowym wybieramy algorytm SHA-256 i czekamy chwilę niezbędną na odczytanie z dysku oraz przetworzenie niemal dwóch miliardów bajtów. Po zakończeniu operacji widzimy, że na dysku powstał plik z wyliczoną sumą kontrolną – zgadza się ona z wartością znalezioną uprzednio na stronie WWW.

Metoda 2 – przeglądarka internetowa

Na stronie https://md5file.com/calculator (jak i w wielu innych miejscach) znajdziemy kalkulator funkcji skrótu napisany w Javascripcie czyli języku programowania uruchamianym w przeglądarce. Do działania nie wymaga on kontaktu z serwerem, wszystkie obliczenia zostaną przeprowadzone lokalnie na naszym komputerze.

Domyślnie kalkulator policzy jednocześnie wartości kilku funkcji skróty z rodziny SHA. Po wybraniu pliku (lub przeciągnięciu go do okna z kalkulatorem) rozpoczynają się obliczenia, których wynik wygląda następująco:

Widzimy, że również ta metoda potwierdza poprawność pobranego pliku.

Nigdy nie sprawdzam sum kontrolnych, co jest nie tak z moim życiem?

Nie sprawdzasz bo… nie musisz. Kontrola poprawności danych jest zazwyczaj wbudowana w instalatory oprogramowania. Co więcej – ten proces często uwzględnia także sprawdzanie zgodności podpisu elektronicznego, którym wydawca opatrzył plik instalacyjny. W praktyce więc wielokrotnie korzystałeś/aś z weryfikacji integralności pobranych danych nawet o tym nie wiedząc. Także algorytmy kompresji danych (pobrane z sieci dane często są spakowane) kontrolują poprawność wejściowego strumienia danych.

Dawniej, gdy dane były rozprowadzane na dyskietkach (które stosunkowo często ulegały uszkodzeniu), często stosowano formaty przechowujące informacje w sposób nadmiarowy, pozwalające na odzyskanie części danych. Przykład – dane mieszczące się na 10 nośnikach były zapisywane na zestawie 11-12 dyskietek, dzięki czemu informacje z kilku uszkodzonych ścieżek jednej dyskietki były rekonstruowane z nadmiarowych zapisów na pozostałych nośnikach.

Format plików ISO z obrazami dysków nie zawiera jednak żadnych danych kontrolnych, więc tu dość często można się spotkać z publikacją sum kontrolnych jako metody weryfikacji, czy wszystko podczas pobierania poszło jak należy.

Czasem zdarza się, że stuprocentowa poprawność danych nie jest aż tak istotna. Weźmy na przykład pliki z klipami wideo – jeśli do modułu dekodowania trafią przekłamane bajty, w losowym miejscu ekranu pojawi się mały prostokąt z zakłóceniami, który zniknie po sekundzie. Dawno minęły już czasy, w których błędne dane wejściowe skutkowały zamrożeniem wideo albo zawieszeniem się odtwarzacza.

Należy pamiętać, że dowolna modyfikacja pliku skutkuje zmianami sum kontrolnych. W przypadku dokumentów Worda, które rejestrują łączny czas edycji i datę ostatniej zmiany, przy każdym zapisie zawartość pliku się zmieni – także wtedy, gdy w jego treści nie zaszły żadne zmiany. Ta sama uwaga dotyczy wielu innych formatów, które zależą od daty zapisu, nazwy komputera, informacji pobranych z sieci itp.

Ciekawostka

W informatyce śledczej nie pracuje się z komputerami, których zawartość stanowi materiał dowodowy, bo samo uruchomienie takiego komputera prowadziłoby do zmian w systemie plików. Zamiast tego wymontowuje się dysk twardy, podłącza do urządzenia blokującego zapis i kopiuje całą zawartość dysku do pliku na którym biegły prowadzi dalsze prace. Dla tak utworzonego obrazu obliczana jest suma kontrolna, która trafia do protokołu – wiadomo wówczas, że nikt nie spreparował dowodów, bo w każdej chwili można potwierdzić zgodność bieżącej sumy kontrolnej z pierwowzorem.

Podsumowanie

Dowiedzieliśmy się, co to są sumy kontrolne plików, jak je tworzyć i jak weryfikować. Choć nie są one używane zbyt często przez zwykłych użytkowników komputera, dobrze wiedzieć o ich istnieniu i w razie potrzeby skorzystać z tej wiedzy.

---

ad *) tak naprawdę gigabajt (1 GB) to 1024 megabajty czyli 1 073 741 824 bajtów. Miliard bajtów to gibibajt (serio, gibibajt, nie ma tu literówki, skrót to 1 GiB) a producenci dysków twardych zwyczajnie ignorują standardy nazewnictwa przedrostków i dysk 256 GB to w rzeczywistości 256 GiB czyli 238.4 GB*

ad **) w Polsce powinniśmy używać przecinka jako separatora dziesiętnego, ale po wielu latach programowania staje się to trudne. Wszystkie języki programowania używają konwencji pochodzącej z krajów anglojęzycznych, gdzie części dziesiętne oddziela od jedności kropka. W niniejszym bloku proszę raczej spodziewać się kropek.