Jak uszkodzić plik archiwum w kontrolowany sposób?

Napisałem funkcję, która sprawdza uszkodzone archiwum za pomocą sumy kontrolnej CRC.

Aby to przetestować, właśnie otworzyłem archiwum i zaszyfrowałem zawartość edytorem szesnastkowym. Problem polega na tym, że nie wierzę, że jest to właściwy sposób na wygenerowanie uszkodzonego pliku.

Czy istnieje inny sposób na stworzenie „kontrolowanej korupcji”, aby nie była całkowicie losowa, ale mogła symulować to, co dzieje się z prawdziwymi uszkodzonymi archiwami? Nigdy nie musiałem specjalnie uszkodzić czegoś, więc nie jestem pewien, jak to zrobić, oprócz przypadkowego mieszania danych w pliku.

Nie przeprowadziłem też wielu testów fuzz , ale oto dwa pomysły:

Wpisz kilka zer na środku pliku. Użyj ddz conv=notrunc. Spowoduje to zapisanie jednego bajtu (wielkość bloku = 1 liczba = 1):

dd if=/dev/zero of=file_to_fuzz.zip bs=1 count=1 seek=N conv=notrunc

Użycie /dev/urandomjako źródła jest również opcją.

Alternatywnie, wybij wiele otworów o wielkości 4k za pomocą fallocate --punch-hole. Możesz nawet fallocate --collapse-rangewyciąć stronę bez pozostawiania dziury wypełnionej zerą. (Spowoduje to zmianę rozmiaru pliku).

Pobieranie wznowione w niewłaściwym miejscu byłoby zgodne ze --collapse-rangescenariuszem. Niekompletny torrent pasuje do punch-holescenariusza. (Rzadki plik lub wstępnie przydzielone zakresy, odczytywane jako zero w dowolnym miejscu, które nie zostało jeszcze zapisane).

Zła pamięć RAM (w systemie, z którego pobrałeś plik) może powodować uszkodzenie, a dyski optyczne również mogą uszkadzać pliki (ich ECC nie zawsze jest wystarczająco mocne, aby idealnie odtworzyć się po zadrapaniach lub blaknięciu barwnika).

Sektory DVD (bloki ECC) to 2048B , ale mogą wystąpić błędy jednobajtowe lub nawet bitowe. Niektóre dyski prawdopodobnie zapewnią złe dane, których nie da się naprawić, zamiast błędu odczytu dla sektora, szczególnie jeśli czytasz w trybie surowym lub w / e to się nazywa.

Inne odpowiedzi wydają się dotyczyć głównie błędów sprzętowych. Pozwól mi wymienić kilka uszkodzeń spowodowanych przez oprogramowanie:

• LF zastąpiono CRLF.
• CR usunięty. (Nawet jeśli nie następuje LF)
• Wstawiono dodatkowe bajty zerowe.
• Wstawiono dodatkowy „znak bajtu”.
• Zestaw znaków przekonwertowany z UTF-8 na Latin-1 lub odwrotnie.
• Usunięto znak DOS EOF (# 1A), nawet jeśli nie znajduje się na końcu pliku.

Te rzeczy są dość nieszkodliwe w przypadku plików tekstowych, ale generalnie zabójcze w przypadku plików binarnych.

Użyj dddo obcięcia pliku lub wypróbuj edytor binarny, np. hexerEdytuj i wprowadzaj pewne uszkodzenia.

Przykład obcięcia pliku przy użyciu dd

Utwórz plik 5 MB

# dd if=/dev/zero of=foo bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 0.0243189 s, 216 MB/s
# ls -l foo
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
#

Obetnij 10 bajtów od końca

# dd if=foo of=foo-corrupted bs=1 count=5242870
5242870+0 records in
5242870+0 records out
5242870 bytes (5.2 MB) copied, 23.7826 s, 220 kB/s
# ls -l foo foo-corrupted
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
-rw-r--r-- 1 root root 5242870 Aug 12 20:14 foo-corrupted
#

Strona podręcznika Hexer

HEXER(1)                              General Commands Manual                             HEXER(1)

NAME
   hexer - binary file editor

SYNOPSIS
   hexer [options] [file [...]]

DESCRIPTION
   hexer  is  a  multi-buffer  editor  for  viewing  and  manipulating binary files.  It can't
   (shouldn't) be used for editing block devices, because it tries to load the whole file into
   a  buffer (it should work for diskettes).  The most important features of hexer are:  multi
   buffers, multi level undo, command line editing with completion, binary regular expressions
   (see  below).   The  user  interface  is  kept similar to vi, so if you know how to use vi,
   you'll get started easily.

Sugestia:

Zacznij pisać do archiwum i przestań pisać, zanim skończy. Może to wystąpić podczas przerw w dostawie prądu i innych scenariuszy.

Scenariusz z życia:

Kiedyś zepsułem plik zip, próbując skopiować do niego więcej danych, niż mieściłoby się na nośniku. Windows (to był Windows 7 w trybie awaryjnym ftr) próbował zakończyć akcję, zanim zorientował się, czy jest wystarczająca ilość miejsca, a zanim się zorientował, plik był w połowie kompletny, a zatem uszkodzony. Mam nadzieję, że rozwiązali ten problem w późniejszych wersjach systemu Windows lub że był to tylko tryb bezpieczny.

Innym powszechnym rodzajem korupcji jest kręcenie bitów: gdy jeden bit (lub wiele bitów) przełącza się w strumieniu danych.

Tak bajt 1111 0000może stać się, powiedzmy, 1111 0010lub 1011 0000lub 1110 1100lub cokolwiek.

Systemy 1110 1000kontroli parzystości i liczenia mają problemy z takimi rzeczami, jak na przykład taka sama liczba zestawów i rozbrojenia, ponieważ zarówno parzystość, jak i liczba pozostają takie same.

Dlatego zastąpienie wszystkich wystąpień losowego znaku odwrotnością, powiedzmy od 0x57 do 0x75 („9” do „K”) lub odwrotnie, może nie być wykrywalne. W systemach, które mają mysql, istnieje właśnie polecenie „replace” w takim właśnie celu:

replace K 9 < goodInputFile > corruptedOutputFile

Możesz także spróbować zamienić litery K i 9 wokół, co będzie szczególnie dobrym testem, jeśli oba pojawią się w pliku tyle samo:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Użyj, man replaceaby uzyskać więcej informacji.

Losowe zmiany w uszkodzonych danych testowych nie są dobrym podejściem, ponieważ nie można odtworzyć próbki w celu ponownego uruchomienia testów.

Byłbym zadowolony tylko z 3 próbek, zmieniając tylko 1 bit w pierwszym bajcie, w ostatnim bajcie i dowolnym bajcie środkowym. Ale tylko 1 bit, nie cały bajt.

Ale najlepszą próbką testową byłaby taka, w której można wygenerować próbki zmieniające każdy bit pliku od pierwszego do ostatniego bajtu. Tego nie da się (zwykle) uzyskać zwykłymi narzędziami, trzeba je zbudować (tak myślę).

Dzięki takiemu podejściu izolujesz wiele możliwości, w tym endianess, jeśli twój algorytm opiera się na jednym rodzaju endianess. W innych rękach duża próbka może zająć dużo czasu na przetworzenie.

W końcu niektóre przykładowe obcięcie lub dodanie bajtów zakończy testy.