Come corrompere un file di archivio in modo controllato?

Ho scritto una funzione che verifica la presenza di un archivio danneggiato utilizzando un checksum CRC.

Per provarlo, ho appena aperto l'archivio e ho mescolato il contenuto con un editor esadecimale. Il problema è che non credo che questo sia il modo corretto di generare un file danneggiato.

Esiste un altro modo per creare una "corruzione controllata", quindi non sarà del tutto casuale ma può simulare ciò che accade con archivi realmente corrotti? Non ho mai dovuto corrompere qualcosa di proposito, quindi non sono davvero sicuro di come farlo, a parte la confusione casuale di dati in un file.

Neanche io ho fatto molti test fuzz , ma ecco due idee:

Scrivi alcuni zeri nel mezzo del file. Utilizzare ddcon conv=notrunc. Questo scrive un singolo byte (dimensione del blocco = 1 conteggio = 1):

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

L'utilizzo /dev/urandomcome fonte è anche un'opzione.

In alternativa, eseguire i fori multipli di 4k con fallocate --punch-hole. Potresti anche fallocate --collapse-rangetagliare una pagina senza lasciare un buco pieno di zero. (Questo cambierà la dimensione del file).

Un download ripreso nel posto sbagliato corrisponderebbe allo --collapse-rangescenario. Un torrent incompleto corrisponderà allo punch-holescenario. (File sparso o estensioni pre-allocate, leggere come zero ovunque non sia stato ancora scritto.)

Una RAM difettosa (nel sistema da cui hai scaricato il file) può causare corruzione e anche le unità ottiche possono corrompere i file (il loro ECC non è sempre abbastanza potente da recuperare perfettamente da graffi o sbiadimento del colorante).

I settori DVD (blocchi ECC) sono 2048 B , ma possono verificarsi errori a byte singolo o anche a bit singolo. Alcune unità probabilmente forniranno i dati errati non corretti invece di un errore di lettura per il settore, specialmente se leggi in modalità raw o se viene chiamato.

Le altre risposte sembrano principalmente riguardare errori hardware. Vorrei elencare alcune corruzioni causate dal software:

• LF sostituito con CRLF.
• CR rimosso. (Anche se non seguito da LF)
• Inseriti byte null aggiuntivi.
• Inserito "Segno ordine byte" extra Unicode.
• Set di caratteri convertito da UTF-8 a Latin-1 o viceversa.
• Carattere EOF DOS (n. 1A) eliminato, anche se non alla fine del file.

Queste cose sono abbastanza innocue quando si verificano file di testo, ma generalmente sono mortali se applicate a file binari.

Utilizzare ddper troncare il file o provare un editor binario come hexermodificare e introdurre alcune corruzioni.

Esempio di troncamento del file mediante dd

Crea file da 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
#

Troncare 10 byte dalla fine

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

Pagina man di 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.

Suggerimento:

Inizia a scrivere in un archivio e smetti di fare la scrittura prima che finisca. Ciò può verificarsi durante interruzioni di corrente e altri scenari.

Scenario di vita reale:

Una volta ho corrotto un file zip provando a copiare più dati in esso di quanto si adatterebbero sul supporto. Windows (questo era Windows 7 in modalità provvisoria) ha provato a completare l'azione prima di capire se c'era abbastanza spazio, e quando lo aveva capito il file era mezzo completo e quindi corrotto. Spero che abbiano risolto questo problema nelle versioni successive di Windows o che fosse solo una cosa in modalità sicura.

Un altro tipo comune di corruzione è il bit-twiddling: in cui un singolo bit (o più bit) viene attivato / disattivato in un flusso di dati.

Così un byte 1111 0000potrebbe diventare, per esempio, 1111 0010o 1011 0000o 1110 1100o qualsiasi altra cosa.

I sistemi di checksum con parità e conteggio di quelli hanno problemi con cose come 1110 1000dove c'è un uguale numero di insiemi e disinserzioni, poiché sia ​​la parità che il numero di quelli rimangono gli stessi.

Quindi, sostituendo tutte le istanze di un personaggio casuale con il suo inverso, diciamo che da 0x57 a 0x75 (da '9' a 'K') o viceversa potrebbe non essere rilevabile. Per i sistemi che hanno mysql, il comando "sostituisci" esiste proprio per questo scopo:

replace K 9 < goodInputFile > corruptedOutputFile

Puoi anche provare a scambiare la lettera K e 9 in giro, il che sarà un test particolarmente buono se entrambi appaiono lo stesso numero di volte nel file:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Utilizzare man replaceper maggiori informazioni.

Le modifiche casuali ai dati di test corrotti non sono un buon approccio, poiché non è possibile riprodurre l'esempio per rieseguire i test.

Sarei felice con solo 3 campioni, cambiando solo 1 bit nel primo byte, nell'ultimo byte e in qualsiasi byte intermedio. Ma solo 1 bit, non l'intero byte.

Ma il miglior esempio di test sarebbe quello in cui potresti generare campioni cambiando ogni singolo bit del file dal primo all'ultimo byte. Questo non può essere (di solito) ottenuto con i soliti strumenti, è necessario crearne uno (immagino).

Con questo approccio isola molte possibilità tra cui l'endianess se il tuo algoritmo si basa su un tipo di endianess. In altre mani, un grande campione può richiedere molto tempo per l'elaborazione.

Alla fine, alcuni esempi di troncamento o aggiunta di byte completeranno i test.