Comment corrompre un fichier archive de manière contrôlée?

J'ai écrit une fonction qui vérifie une archive corrompue à l'aide d'une somme de contrôle CRC.

Pour le tester, je viens d'ouvrir l'archive et de brouiller le contenu avec un éditeur hexadécimal. Le problème est que je ne pense pas que ce soit la bonne façon de générer un fichier corrompu.

Existe-t-il un autre moyen de créer une "corruption contrôlée", de sorte qu'il ne sera pas totalement aléatoire mais pourra simuler ce qui se passe avec de vraies archives corrompues? Je n'ai jamais eu à corrompre quelque chose exprès, donc je ne sais pas vraiment comment le faire, à part le brouillage aléatoire des données dans un fichier.

Je n'ai pas fait beaucoup de tests Fuzz non plus, mais voici deux idées:

Écrivez quelques zéros au milieu du fichier. À utiliser ddavec conv=notrunc. Cela écrit un seul octet (block-size = 1 count = 1):

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

L'utilisation /dev/urandomcomme source est également une option.

Alternativement, percez plusieurs trous de 4k avec fallocate --punch-hole. Vous pouvez même fallocate --collapse-rangedécouper une page sans laisser de trou vide. (Cela changera la taille du fichier).

Un téléchargement repris au mauvais endroit correspondrait au --collapse-rangescénario. Un torrent incomplet correspondra au punch-holescénario. (Fichier clairsemé ou extensions pré-allouées, soit lu comme zéro n'importe où qui n'a pas encore été écrit.)

Une mauvaise RAM (dans le système à partir duquel vous avez téléchargé le fichier) peut entraîner la corruption, et les lecteurs optiques peuvent également corrompre les fichiers (leur ECC n'est pas toujours assez fort pour récupérer parfaitement des rayures ou de la décoloration du colorant).

Les secteurs DVD (blocs ECC) sont 2048B , mais des erreurs sur un seul octet ou même sur un seul bit peuvent se produire. Certains lecteurs vous donneront probablement les mauvaises données non corrigeables au lieu d'une erreur de lecture pour le secteur, en particulier si vous lisez en mode brut, ou w / e, cela s'appelle.

Les autres réponses semblent principalement concerner les erreurs matérielles. Permettez-moi d'énumérer quelques corruptions causées par le logiciel:

• LF remplacé par CRLF.
• CR supprimé. (Même s'il n'est pas suivi par LF)
• Octets supplémentaires nuls insérés.
• "Unicode Order Mark" Unicode supplémentaire inséré.
• Jeu de caractères converti de UTF-8 en latin-1 ou vice versa.
• Le caractère DOS EOF (# 1A) a été supprimé, même lorsqu'il n'est pas à la fin du fichier.

Ces éléments sont assez inoffensifs lorsqu'ils se produisent dans des fichiers texte, mais généralement mortels lorsqu'ils sont appliqués à des fichiers binaires.

Utilisez ddpour tronquer le fichier, ou essayez un éditeur binaire comme hexerpour éditer et introduire des corruptions.

Exemple de troncature de fichier à l'aide de dd

Créer un fichier de 5 Mo

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

Tronquer 10 octets à la fin

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

Page de manuel 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.

Suggestion:

Commencez à écrire dans une archive et arrêtez de faire l'écriture avant la fin. Cela peut se produire lors de coupures de courant et d'autres scénarios.

Scénario réel:

Une fois, j'ai corrompu un fichier zip en essayant de copier plus de données qu'il ne pourrait en contenir sur le support. Windows (c'était Windows 7 en mode sans échec ftr) a essayé de terminer l'action avant de déterminer s'il y avait suffisamment d'espace, et au moment où il l'avait compris, le fichier était à moitié complet et donc corrompu. J'espère qu'ils ont résolu ce problème dans les versions ultérieures de Windows ou que c'était juste une chose en mode sans échec.

Un autre type commun de corruption est le twiddling de bits: où un seul bit (ou plusieurs bits) est basculé dans un flux de données.

Ainsi, un octet 1111 0000pourrait devenir, par exemple, 1111 0010ou 1011 0000ou 1110 1100ou quoi que ce soit.

Les systèmes de somme de contrôle de parité et de comptage ont des problèmes avec des choses comme 1110 1000où il y a un nombre égal d'ensembles et de désensembles, car la parité et le nombre d'unités restent les mêmes.

Ainsi, le remplacement de toutes les instances d'un caractère aléatoire par son inverse, par exemple 0x57 à 0x75 ('9' à 'K') ou vice versa, pourrait ne pas être détectable. Pour les systèmes qui ont mysql, la commande "replace" existe dans un tel but:

replace K 9 < goodInputFile > corruptedOutputFile

Vous pouvez également essayer d'échanger les lettres K et 9, ce qui sera un test particulièrement intéressant si elles apparaissent toutes les deux le même nombre de fois dans le fichier:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Utilisez man replacepour plus d'informations.

Les modifications aléatoires des données de test corrompues ne sont pas une bonne approche, car vous ne pouvez pas reproduire l'exemple pour réexécuter les tests.

Je serais heureux avec seulement 3 échantillons, en changeant juste 1 bit dans le premier octet, dans le dernier octet et dans n'importe quel octet du milieu. Mais juste 1 bit, pas tout l'octet.

Mais le meilleur échantillon de test serait celui où vous pourriez générer des échantillons en changeant chaque bit du fichier du premier au dernier octet. Cela ne peut pas (généralement) être obtenu avec les outils habituels, vous devez en créer un (je suppose).

Avec cette approche, vous isolez de nombreuses possibilités, y compris l'endianess, si votre algorithme est basé sur un type d'endianess. En revanche, un gros échantillon peut prendre beaucoup de temps à traiter.

Enfin, des exemples de tronçonnage ou d'ajout d'octets complèteront vos tests.