Bagaimana cara merusak file arsip dengan cara yang terkontrol?

Saya menulis fungsi yang memeriksa arsip yang rusak menggunakan checksum CRC.

Untuk mengujinya, saya baru saja membuka arsip dan mengacak konten dengan hex editor. Masalahnya adalah saya tidak percaya bahwa ini adalah cara yang benar untuk menghasilkan file yang rusak.

Apakah ada cara lain untuk membuat "korupsi terkendali", sehingga tidak akan sepenuhnya acak tetapi dapat mensimulasikan apa yang terjadi dengan arsip yang benar-benar rusak? Saya tidak pernah harus merusak sesuatu dengan sengaja jadi saya tidak begitu yakin bagaimana melakukannya, di samping acak acak data dalam file.

Saya juga belum melakukan banyak pengujian fuzz , tapi inilah dua ide:

Tulis beberapa angka nol di tengah file. Gunakan dddengan conv=notrunc. Ini menulis satu byte (ukuran blok = 1 hitungan = 1):

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

Menggunakan /dev/urandomsebagai sumber juga merupakan opsi.

Sebagai alternatif, pukul beberapa lubang 4k dengan fallocate --punch-hole. Anda bahkan fallocate --collapse-rangedapat memotong halaman tanpa meninggalkan lubang yang diisi nol. (Ini akan mengubah ukuran file).

Pengunduhan yang dilanjutkan di tempat yang salah akan cocok dengan --collapse-rangeskenario. Torrent yang tidak lengkap akan cocok dengan punch-holeskenario. (File jarang atau luasan yang dialokasikan sebelumnya, bisa dibaca nol di mana saja yang belum ditulis.)

RAM buruk (dalam sistem Anda mengunduh file) dapat menyebabkan korupsi, dan drive optik juga dapat merusak file (ECC mereka tidak selalu cukup kuat untuk pulih dengan sempurna dari goresan atau memudarkan pewarna).

Sektor DVD (blok ECC) adalah 2048B , tetapi byte tunggal atau bahkan kesalahan bit tunggal dapat terjadi. Beberapa drive mungkin akan memberi Anda data yang tidak dapat diperbaiki yang buruk alih-alih kesalahan baca untuk sektor ini, terutama jika Anda membaca dalam mode mentah, atau jika itu disebut.

Jawaban lain tampaknya sebagian besar berkaitan dengan kesalahan perangkat keras. Biarkan saya daftar beberapa korupsi yang disebabkan oleh perangkat lunak:

• LF diganti dengan CRLF.
• CR dihapus. (Bahkan jika tidak diikuti oleh LF)
• Byte Null ekstra dimasukkan.
• Unicode Ekstra "Byte Order Mark" dimasukkan.
• Kumpulan karakter yang dikonversi dari UTF-8 ke Latin-1 atau sebaliknya.
• Karakter DOS EOF (# 1A) dihapus, bahkan ketika tidak di End Of File.

Hal-hal ini cukup berbahaya ketika terjadi pada file teks, tetapi umumnya mematikan ketika diterapkan pada file biner.

Gunakan dduntuk memotong file, atau coba editor biner suka hexermengedit dan memperkenalkan beberapa korupsi.

Contoh pemotongan file menggunakan dd

Buat file 5MB

# 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
#

Potong 10 byte dari ujung

# 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
#

Halaman manual yang lebih rapi

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.

Saran:

Mulailah menulis ke arsip dan hentikan kegiatan menulis sebelum selesai. Ini dapat terjadi selama pemadaman listrik dan skenario lainnya.

Skenario kehidupan nyata:

Saya pernah merusak file zip dengan mencoba menyalin lebih banyak data ke dalamnya daripada yang muat di media. Windows (ini adalah Windows 7 dalam safe mode ftr) mencoba menyelesaikan tindakan sebelum mencari tahu apakah ada ruang yang cukup, dan pada saat itu sudah menemukan file itu setengah-lengkap dan dengan demikian korup. Saya harap mereka memperbaiki masalah itu di versi Windows yang lebih baru atau itu hanya hal mode aman.

Jenis korupsi lain yang umum adalah bit-twiddling: di mana bit tunggal (atau beberapa bit) diaktifkan di datastream.

Jadi byte 1111 0000mungkin menjadi, mengatakan, 1111 0010atau 1011 0000atau 1110 1100atau apa pun.

Paritas dan sistem checksum count-the-ones memiliki masalah dengan hal-hal seperti di 1110 1000mana ada jumlah set dan unset yang sama, karena paritas dan jumlah yang tetap sama.

Jadi mengganti semua instance dari karakter acak dengan kebalikannya, katakan 0x57 ke 0x75 ('9' ke 'K') atau sebaliknya mungkin tidak dapat dideteksi. Untuk sistem yang memiliki mysql, perintah "ganti" ada hanya untuk tujuan seperti itu:

replace K 9 < goodInputFile > corruptedOutputFile

Anda juga dapat mencoba menukar huruf K dan 9, yang akan menjadi ujian yang sangat baik jika keduanya muncul beberapa kali dalam file yang sama:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Gunakan man replaceuntuk info lebih lanjut.

Perubahan acak pada data uji yang rusak bukanlah pendekatan yang baik, karena Anda tidak dapat mereproduksi sampel untuk menjalankan kembali tes.

Saya akan senang dengan hanya 3 sampel, mengubah hanya 1 bit di byte pertama, di byte terakhir dan di byte tengah. Tapi hanya 1 bit, bukan seluruh byte.

Tetapi sampel uji terbaik adalah di mana Anda dapat menghasilkan sampel mengubah masing-masing bit file dari byte pertama ke byte terakhir. Ini tidak bisa (biasanya) didapat dengan alat biasa, Anda perlu membangun satu (saya kira).

Dengan pendekatan ini Anda mengisolasi banyak kemungkinan termasuk endianess jika algoritma Anda didasarkan pada satu jenis endianess. Di sisi lain, sampel besar dapat menghabiskan banyak waktu untuk diproses.

Akhirnya, beberapa sampel yang memotong atau menambahkan byte akan menyelesaikan tes Anda.