Bir arşiv dosyasını kontrollü bir şekilde nasıl bozabilirim?

Bir CRC sağlama toplamı kullanarak bozuk bir arşivi denetleyen bir işlev yazdım.

Test etmek için arşivi yeni açtım ve içeriği bir hex editörüyle karıştırdım. Sorun, bunun bozuk bir dosya oluşturmak için doğru yol olduğuna inanmıyorum.

“Kontrollü bir yolsuzluk” yaratmanın başka bir yolu var mı, bu yüzden tamamen rastlantısal olmayacak, ancak gerçek bozuk arşivlerle olanları simüle edebilir mi? Bir şeyi bilerek bozmak zorunda kalmamıştım, bu yüzden bir dosyadaki verilerin rasgele karıştırılmasının yanında nasıl yapılacağından emin değilim.

Ben de çok fazla tüyo testi yapmadım , ama işte iki fikir:

Dosyanın ortasına bazı sıfırlar yazın. Kullanım ddile conv=notrunc. Bu tek bir bayt yazar (blok boyutu = 1 sayım = 1):

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

/dev/urandomKaynak olarak kullanmak da bir seçenektir.

Alternatif olarak, birden fazla 4k deliği ile delin fallocate --punch-hole. fallocate --collapse-rangeSıfır dolu bir delik bırakmadan bir sayfayı bile kesebilirsiniz. (Bu dosya boyutunu değiştirir).

Yanlış yerde devam ettirilen bir indirme --collapse-rangesenaryo ile eşleşir . Eksik bir torrent punch-holesenaryo ile eşleşecektir . (Seyrek dosya veya önceden ayrılmış uzantılar, henüz henüz yazılmamış bir yerde sıfır olarak okunur.)

Bozuk RAM (dosyayı indirdiğiniz sistemde) bozulmaya neden olabilir ve optik sürücüler de dosyaları bozabilir (ECC her zaman boyadaki çiziklerden veya solukluklardan tamamen kurtulabilecek kadar güçlü değildir).

DVD sektörleri (ECC blokları) 2048B'dir , ancak tek bayt ve hatta tek bit hataları olabilir. Bazı sürücüler, özellikle ham modda veya w / e denirse, sektör için bir okuma hatası yerine size hatalı, düzeltilemez veriler verecektir.

Diğer cevaplar çoğunlukla donanım hataları ile ilgilidir. Bazı yazılım kaynaklı bozulmaları listelememe izin verin:

• LF, CRLF ile değiştirildi.
• CR kaldırıldı. (LF tarafından takip edilmese bile)
• Eklenmiş Null bayt.
• Ekstra Unicode "Bayt Sipariş İşareti" eklendi.
• UTF-8'den Latin-1'e dönüştürülen karakter kümesi veya bunun tersi.
• DOS EOF karakteri (# 1A), Dosya Sonunda olmasa bile silindi.

Bunlar metin dosyalarına geldiğinde oldukça zararsız, ancak ikili dosyalara uygulandığında genellikle ölümcül.

ddDosyayı kesmek için kullanın veya hexerbazı bozulmaları düzenlemek ve tanıtmak gibi bir ikili düzenleyici deneyin .

Dd kullanarak kısaltmalı dosya örneği

5 MB dosyası oluştur

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

Sonundan 10 bayt keser

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

Hexer man sayfası

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.

Öneri:

Bir arşive yazmaya başla ve işi bitirmeden önce yazmayı durdur. Bu, elektrik kesintileri ve diğer senaryolar sırasında ortaya çıkabilir.

Gerçek hayat senaryosu:

Bir keresinde, ortama sığacak olandan daha fazla veri kopyalamaya çalışarak bir zip dosyasını bozdum. Windows (bu, Windows 7'nin ftr güvenli moduydu), yeterli alan olup olmadığını anlamadan önce işlemi tamamlamaya çalıştı ve bunu anlayıncaya kadar, dosya yarı yarıya tamamlanmıştı ve bu nedenle bozuktu. Umarım bu sorunu daha sonraki Windows sürümlerinde çözdüler ya da bu sadece güvenli mod bir şeydi.

Başka bir yaygın yolsuzluk türü de bit bükmedir: tek bir bitin (veya birden fazla bitin) bir veri akışında geçildiği yer.

Böylece bir bayt 1111 0000, söylenebilir 1111 0010veya 1011 0000veya 1110 1100veya her neyse olabilir.

Eşlik ve sayma sağlama toplamı sistemleri 1110 1000, eşitlikteki kümelerin ve düzensizliklerin olduğu yerler ile ilgili sorunlara sahiptir , çünkü hem parite hem de sayı aynı kalır.

Bu nedenle, rastgele bir karakterin tüm örneklerini tersiyle değiştirmek, 0x57 ila 0x75 ('9' - 'K') demek veya bunun tersi tespit edilemeyebilir. MySQL'e sahip sistemler için, "change" komutu sadece böyle bir amaç için var:

replace K 9 < goodInputFile > corruptedOutputFile

Ayrıca dosyada K ve 9 harflerini değiştirmeyi deneyebilirsiniz; bu, her ikisi de dosyada aynı sayıda görünürse, özellikle iyi bir test olacaktır:

replace K 9 9 K < goodInputFile > corruptedOutputFile

man replaceDaha fazla bilgi için kullanın .

Bozuk test verilerindeki rastgele değişiklikler iyi bir yaklaşım değildir, çünkü testleri yeniden çalıştırmak için örneği çoğaltamazsınız.

İlk baytta, son baytta ve herhangi bir orta baytta sadece 1 bit değiştiren sadece 3 numuneden memnun olurum. Ama sadece 1 bit, bütün bayt değil.

Ancak en iyi test örneği, dosyanın her bir biti ilk bayttan değiştirerek numune üretebileceğiniz bir örnek olacaktır. Bu (genellikle) olağan araçlarla elde edilemez, bir tane oluşturmanız gerekir (sanırım).

Bu yaklaşımla, eğer algoritmanızın bir türden bir köklülüğe dayanıyorsa, kuşçuluk da dahil olmak üzere bir çok olasılıktan yararlanabilirsiniz. Diğer ellerde, büyük örnek işlem için çok zaman alabilir.

Sonunda, bazı örneklerin kesilmesi veya bayt eklenmesi testlerinizi tamamlayacaktır.