Przejdź do treści

Suma kontrolna nagrania: jak sprawdzić, czy kopia ma te same bajty

4 lutego, 2022Artykuły

Suma kontrolna nagrania: jak sprawdzić, czy kopia ma te same bajty

Suma kontrolna nagrania pozwala sprawdzić, czy kopia pliku ma taką samą zawartość jak plik źródłowy. Oblicz SHA-256 dla obu plików i porównaj całe wyniki: zgodność daje bardzo mocne praktyczne potwierdzenie identyczności bajtów, a różnica oznacza, że zawartość jest inna. Sama nazwa nagrania, jego długość czy podobne brzmienie nie wystarczają do takiego porównania.

Co sprawdza suma SHA-256 pliku audio

Suma kontrolna jest krótkim zapisem obliczonym na podstawie danych pliku. SHA-256 to algorytm, który daje wynik zapisywany jako 64 znaki: cyfry od 0 do 9 i litery od a do f. Tę wartość nazywa się też skrótem lub hashem. Obliczenie obejmuje cały wskazany plik, niezależnie od tego, czy nagranie trwa minutę, czy godzinę. Dla tych samych bajtów algorytm zawsze daje ten sam wynik. Nie trzeba przy tym odtwarzać rozmowy ani znać formatu jej dźwięku.

To przydatne, gdy masz dwa pliki o nazwie rozmowa.wav, znajdujące się w różnych katalogach. Mogą wyglądać identycznie w menedżerze plików, ale jeden mógł zostać ponownie zapisany przez program audio. Porównanie sum obejmuje również takie różnice, których nie słychać podczas odsłuchu. Z kolei dwa pliki o różnych nazwach mogą mieć dokładnie tę samą zawartość.

Poradnik ARSC, stowarzyszenia zajmującego się ochroną i badaniem nagrań dźwiękowych, opisuje obliczanie i późniejsze porównywanie sum jako sposób kontrolowania niezmienności plików. Podobną zasadę porównania danych źródłowych i skopiowanych przedstawia NIST SP 800-86. W poniższych przykładach używamy SHA-256; MD5 i SHA-1 to przestarzałe rozwiązania, których nie wybieramy do nowych porównań.

Najpierw ustal, które dwa pliki porównujesz

Zapisz lub sprawdź pełne ścieżki obu nagrań. Jedno będzie punktem odniesienia, drugie sprawdzaną kopią. Upewnij się, że zapis nagrania już się zakończył i żaden program nie zmienia pliku podczas obliczeń. Sumę należy liczyć dla konkretnego pliku audio, a nie dla skrótu prowadzącego do niego ani dla archiwum ZIP, w którym się znajduje.

Ścieżki są umowne: zastąp je własnymi, zachowując zwykłe proste cudzysłowy otaczające ścieżkę. Dzięki nim spacje w nazwie katalogu lub nagrania nie zostaną potraktowane jako rozdzielenie argumentów polecenia. Wybierz instrukcję dla swojego systemu; nie musisz wykonywać wszystkich trzech wariantów.

Windows: PowerShell i Get-FileHash

W systemie Windows otwórz PowerShell. Dla pliku źródłowego wpisz:

Get-FileHash -LiteralPath „C:\Nagrania\rozmowa.wav” -Algorithm SHA256

Następnie oblicz sumę drugiego pliku:

Get-FileHash -LiteralPath „D:\Nagrania\rozmowa.wav” -Algorithm SHA256

Wynik zawiera nazwę algorytmu, skrót w polu Hash oraz ścieżkę pliku. Porównujesz wartości Hash. Parametr -LiteralPath wskazuje dokładną ścieżkę, a -Algorithm SHA256 jednoznacznie określa metodę obliczeń. Dostępność Get-FileHash zależy od wersji PowerShell; polecenie jest dostępne od wersji 4.0. Wpisuj je w PowerShell, nie w zwykłym Wierszu polecenia.

macOS: shasum w Terminalu

W Terminalu systemu macOS użyj shasum z wyborem algorytmu 256. Przykładowa ścieżka do pierwszego pliku wygląda tak:

shasum -a 256 „/Users/jan/Nagrania/rozmowa.wav”

Dla drugiego nagrania, znajdującego się w innym katalogu, polecenie może mieć postać:

shasum -a 256 „/Users/jan/Porownanie/rozmowa.wav”

Każdy wynik zawiera ciąg znaków sumy i nazwę wskazanego pliku. Porównaj same sumy. Nie pomijaj parametru -a 256: sam wybór programu shasum nie oznacza jeszcze wyboru SHA-256.

Linux: sha256sum

W systemie Linux z zainstalowanymi narzędziami GNU coreutils skorzystaj z sha256sum. W terminalu wykonaj kolejno:

sha256sum „/home/jan/Nagrania/rozmowa.wav”

sha256sum „/home/jan/Porownanie/rozmowa.wav”

Nazwa tego narzędzia wskazuje używany algorytm, więc nie dodajesz osobnego przełącznika wybierającego SHA-256. Wynik zawiera skrót i nazwę pliku. W minimalnych instalacjach zestaw dostępnych narzędzi może być inny; komunikat o braku polecenia oznacza brak narzędzia, a nie problem z nagraniem.

Jak porównać wyniki bez pomyłki

Porównanie ma sens tylko wtedy, gdy oba obliczenia zakończyły się poprawnie i używały SHA-256. Komunikat o odmowie dostępu lub nieistniejącej ścieżce nie jest sumą. Sprawdź również ścieżki widoczne w wynikach: łatwo uruchomić to samo polecenie dwa razy i przez nieuwagę porównać plik z nim samym.

  1. Odczytaj pełne 64 znaki pierwszej sumy.
  2. Odczytaj pełne 64 znaki drugiej sumy.
  3. Porównaj cały ciąg, bez nazw plików, nagłówków kolumn i odstępów dodanych przez program.
  4. Zanotuj zgodność albo niezgodność wraz ze ścieżkami obu plików.

Wielkie i małe litery w zapisie szesnastkowym oznaczają te same wartości: A odpowiada a, B odpowiada b i tak dalej. Nie wymagaj więc identycznej wielkości liter między programami. Nie wystarczy natomiast zgodność kilku pierwszych lub ostatnich znaków. Jeśli okno pokazuje ucięty wynik, najpierw zadbaj o odczyt pełnej wartości.

Zgodne sumy pozwalają w praktyce uznać pliki za identyczne bajt po bajcie. Teoretycznie różne dane mogą dać ten sam skrót (kolizja), więc nie jest to matematyczna gwarancja, ale przy sprawdzaniu kopii SHA-256 jest bardzo mocnym narzędziem kontroli. Suma kontrolna potwierdza zgodność porównywanych danych, ale nie prawdziwość rozmowy ani datę jej nagrania.

Różne sumy, przy poprawnym obliczeniu tym samym algorytmem, oznaczają różną zawartość. Nawet zmiana jednego bajtu może spowodować zupełnie inny wynik. Skrót nie wskazuje miejsca ani rozmiaru zmiany: nie powie, czy brakuje fragmentu wypowiedzi, czy zmienił się tylko opis zapisany wewnątrz pliku. Sama niezgodność nie rozstrzyga też, który z dwóch plików jest właściwy.

Dlaczego to samo brzmienie może dawać inną sumę

Typową pomyłką jest porównywanie nagrania WAV z plikiem MP3 powstałym po konwersji. To dwa różne pliki, nawet jeżeli zawierają tę samą rozmowę. Także konwersja do formatu bezstratnego zmienia zapis pliku. Suma całego pliku służy do kontroli jego bajtów, więc nie jest narzędziem do oceny podobieństwa dźwięku.

Różnicę może również spowodować edycja metadanych wewnątrz nagrania, na przykład dopisanie tytułu. ARSC zwraca uwagę, że zmiana informacji osadzonych w pliku wpływa na jego niezmienność. Inaczej działa sama zmiana nazwy w katalogu: jeśli bajty pliku pozostają nietknięte, suma się nie zmieni. Sama zmiana daty modyfikacji przechowywanej przez system plików nie zmienia sumy, ponieważ data ta nie należy do bajtów pliku.

Gdy wyniki są różne, najpierw sprawdź, czy wybrano odpowiednią parę nagrań, ten sam algorytm i pełne wyniki. Następnie ustal, czy któryś plik przeszedł konwersję lub zapis w edytorze. Ponowne obliczenie sumy zmienionego pliku nie przywraca zgodności z pierwotnym punktem odniesienia – opisuje jego nową zawartość.

Jak zachować wynik odniesienia

Najlepiej zapisać w osobnej notatce nazwę algorytmu, pełną sumę, ścieżkę pliku i datę obliczenia. Sam ciąg 64 znaków bez opisu łatwo przypisać do niewłaściwego nagrania. Jeśli zmienisz nazwę pliku, zachowaj informację pozwalającą powiązać go z zapisanym wynikiem.

Nie trzymaj jedynego zapisu sumy w folderze, którego zawartość regularnie edytujesz i zastępujesz. Samo umieszczenie notatki obok nagrania nie zmienia jego sumy; problemem jest możliwość równoczesnego nadpisania pliku i jego wyniku odniesienia. NIST SP 800-92, omawiając integralność dzienników systemowych, zaleca ochronę pierwotnych skrótów przed zmianą. Tę zasadę można zastosować również do notatki o nagraniu, przechowując ją oddzielnie i chroniąc przed przypadkowym nadpisaniem.

Źródła

  • Association for Recorded Sound Collections, ARSC Guide to Audio Preservation, CLIR Publication 164, maj 2015, rozdział 7, s. 132–133, www.clir.org/wp-content/uploads/sites/6/pub164.pdf
  • National Institute of Standards and Technology, Guide to Integrating Forensic Techniques into Incident Response, NIST SP 800-86, sierpień 2006, sekcja 4.2.2, nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-86.pdf
  • National Institute of Standards and Technology, Guide to Computer Security Log Management, NIST SP 800-92, wrzesień 2006, sekcja 3.2 i przypis 25, nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

Zdjęcie: Ivan Radic, CC BY 2.0 (creativecommons.org/licenses/by/2.0/), Wikimedia Commons, commons.wikimedia.org/wiki/File:MicroSD_card_between_two_fingers.jpg