Wie kann ich eine Archivdatei kontrolliert beschädigen?

Ich habe eine Funktion geschrieben, die mithilfe einer CRC-Prüfsumme nach einem beschädigten Archiv sucht.

Zum Testen habe ich gerade das Archiv geöffnet und den Inhalt mit einem Hex-Editor verschlüsselt. Das Problem ist, dass ich nicht glaube, dass dies der richtige Weg ist, eine beschädigte Datei zu generieren.

Gibt es eine andere Möglichkeit, eine "kontrollierte Beschädigung" zu erstellen, damit sie nicht völlig zufällig ist, sondern simulieren kann, was mit wirklich beschädigten Archiven passiert? Ich musste nie absichtlich etwas beschädigen, daher bin ich mir nicht sicher, wie ich das tun soll, abgesehen vom zufälligen Verwürfeln von Daten in einer Datei.

Ich habe auch nicht viel Fuzz-Tests gemacht , aber hier sind zwei Ideen:

Schreiben Sie einige Nullen in die Mitte der Datei. Verwenden Sie ddmit conv=notrunc. Dies schreibt ein einzelnes Byte (Blockgröße = 1 Anzahl = 1):

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

Die Verwendung /dev/urandomals Quelle ist ebenfalls eine Option.

Alternativ können Sie auch mehrere 4k-Löcher mit stanzen fallocate --punch-hole. Sie können sogar fallocate --collapse-rangeeine Seite ausschneiden, ohne ein mit Nullen gefülltes Loch zu hinterlassen. (Dies ändert die Dateigröße).

Ein Download, der an der falschen Stelle fortgesetzt wird, entspricht dem --collapse-rangeSzenario. Ein unvollständiger Torrent entspricht dem punch-holeSzenario. (Sparse-Datei oder vorab zugewiesene Speicherbereiche, die entweder an einer noch nicht geschriebenen Stelle als Null gelesen werden.)

Ein fehlerhafter Arbeitsspeicher (auf dem System, von dem Sie die Datei heruntergeladen haben) kann zu Beschädigungen führen, und optische Laufwerke können auch Dateien beschädigen (deren ECC ist nicht immer stark genug, um perfekt von Kratzern oder Verblassen des Farbstoffs wiederherzustellen).

DVD-Sektoren (ECC-Blöcke) sind 2048B groß , es können jedoch Einzelbyte- oder sogar Einzelbitfehler auftreten. Einige Laufwerke geben Ihnen wahrscheinlich die fehlerhaften, nicht korrigierbaren Daten anstelle eines Lesefehlers für den Sektor, insbesondere wenn Sie im unformatierten Modus lesen oder wenn er aufgerufen wird.

Die anderen Antworten scheinen hauptsächlich mit Hardwarefehlern zu tun zu haben. Lassen Sie mich einige durch Software verursachte Fehler auflisten:

• LF durch CRLF ersetzt.
• CR entfernt. (Auch wenn nicht gefolgt von LF)
• Zusätzliche Null-Bytes eingefügt.
• Zusätzliches Unicode "Byte Order Mark" eingefügt.
• Zeichensatz konvertiert von UTF-8 nach Latin-1 oder umgekehrt.
• DOS EOF-Zeichen (# 1A) gelöscht, auch wenn nicht am Dateiende.

Diese Dinge sind ziemlich harmlos, wenn sie mit Textdateien geschehen, aber im Allgemeinen tödlich, wenn sie auf Binärdateien angewendet werden.

Verwenden Sie dddiese Option, um die Datei zu kürzen, oder verwenden Sie einen Binäreditor hexer, um einige Fehler zu bearbeiten und einzuführen.

Beispiel für das Abschneiden einer Datei mit dd

Erstellen Sie eine 5MB-Datei

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

Schneiden Sie 10 Bytes am Ende ab

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

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.

Vorschlag:

Beginnen Sie mit dem Schreiben in ein Archiv und beenden Sie das Schreiben, bevor es abgeschlossen ist. Dies kann bei Stromausfällen und anderen Szenarien auftreten.

Reales Szenario:

Ich habe einmal eine Zip-Datei beschädigt, indem ich versucht habe, mehr Daten darauf zu kopieren, als auf das Medium passen würden. Windows (dies war Windows 7 im abgesicherten Modus, ftr) hat versucht, die Aktion abzuschließen, bevor herausgefunden wurde, ob genügend Speicherplatz vorhanden ist, und bis es herausgefunden hat, war die Datei zur Hälfte vollständig und daher beschädigt. Ich hoffe, sie haben dieses Problem in späteren Versionen von Windows behoben, oder das war nur eine Sache im abgesicherten Modus.

Eine andere häufige Art der Beschädigung ist das Bit-Twiddling: Ein einzelnes Bit (oder mehrere Bits) wird in einem Datenstrom umgeschaltet.

So ein Byte 1111 0000werden könnte, sagen, 1111 0010oder 1011 0000oder 1110 1100oder was auch immer.

Paritäts- und Count-the-One-Prüfsummensysteme haben Probleme mit Dingen wie der 1110 1000gleichen Anzahl von Mengen und Unmengen, da sowohl die Parität als auch die Anzahl von Einsen gleich bleiben.

Das Ersetzen aller Instanzen eines zufälligen Zeichens durch sein Inverses, z. B. 0x57 bis 0x75 ('9' bis 'K') oder umgekehrt, ist möglicherweise nicht erkennbar. Für Systeme mit mysql gibt es den Befehl "replace" für genau diesen Zweck:

replace K 9 < goodInputFile > corruptedOutputFile

Sie können auch versuchen, die Buchstaben K und 9 zu vertauschen. Dies ist ein besonders guter Test, wenn beide gleich oft in der Datei vorkommen:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Verwenden Sie man replacefür weitere Informationen.

Zufällige Änderungen an fehlerhaften Testdaten sind kein guter Ansatz, da Sie das Beispiel nicht reproduzieren können, um die Tests erneut auszuführen.

Ich würde mich über nur 3 Samples freuen, die nur 1 Bit im ersten Byte, im letzten Byte und in einem beliebigen mittleren Byte ändern. Aber nur 1 Bit, nicht das ganze Byte.

Das beste Testmuster wäre jedoch eines, bei dem Sie Samples generieren könnten, indem Sie jedes einzelne Bit der Datei vom ersten bis zum letzten Byte ändern. Dies kann (normalerweise) nicht mit üblichen Werkzeugen erreicht werden, man muss eines bauen (denke ich).

Mit diesem Ansatz isolieren Sie viele Möglichkeiten, einschließlich Endianess, wenn Ihr Algorithmus auf einer Art von Endianess basiert. In anderen Händen kann die Verarbeitung einer großen Probe viel Zeit in Anspruch nehmen.

Zuletzt werden Ihre Tests durch Abschneiden oder Hinzufügen von Bytes abgeschlossen.