Comment corrompre un file d'archive de manière contrôlée?

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

Écrivez des zéros au milieu du file. Utilisez dd avec 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 

Utiliser /dev/urandom comme source est également une option.

Alternativement, perforer plusieurs trous de 4k avec le fallocate --punch-hole . Vous pourriez même fallocate --collapse-range pour découper une page sans laisser un trou rempli de zéro. (Cela va changer la taille du file).

Un téléchargement repris au mauvais endroit correspondrait au scénario --collapse-range . Un torrent incomplet correspondra au scénario de punch-hole . (Le file Sparse ou les extensions pré-allouées, soit lus comme zéro n'importe où qui n'a pas encore été écrit.)

Une mauvaise memory RAM (dans le système où vous avez téléchargé le file) peut causer de la corruption, et les lecteurs optiques peuvent également corrompre les files (leur ECC n'est pas toujours assez puissant pour se récupérer parfaitement des rayures ou de la décoloration du colorant).

Les secteurs DVD (blocs ECC) sont 2048B , mais des erreurs à un octet ou même à un bit peuvent survenir. Certains lecteurs vont probablement vous donner les mauvaises données incorrigibles au lieu d'une erreur de lecture pour le secteur, surtout si vous lisez en mode brut, ou w / e il est appelé.

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

• LF remplacé par CRLF.
• CR enlevé. (Même si non suivi par LF)
• Octets Null supplémentaires insérés.
• Extra Unicode "Byte Order Mark" inséré.
• Jeu de caractères converti de UTF-8 en Latin-1 ou vice versa.
• DOS EOF-caractère (# 1A) supprimé, même si pas à la fin du file.

Ces choses sont assez inoffensifs lorsqu 'arriver à des files text, mais généralement mortelles lorsqu'il est appliqué aux files binarys.

Utilisez dd pour tronquer le file, ou essayez un éditeur binary comme hexer pour éditer et introduire quelques corruptions.

Exemple de file tronqué utilisant dd

Créer un file 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) copyd, 0.0243189 s, 216 MB/s # ls -l foo -rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo # 

Tronquer 10 octets de 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) copyd, 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 man de 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 sortinges 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 la chose de faire l'écriture avant qu'elle ne finisse. Cela peut se produire pendant des coupures de courant et d'autres scénarios.

Scénario de la vie réelle:

Une fois, j'ai corrompu un file zip en essayant de copyr plus de données qu'il ne le ferait 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 assez d'espace, et au moment où il avait compris que le file é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 bit-twiddling: où un seul bit (ou plusieurs bits) est basculé dans un stream de données.

Ainsi, un octet 1111 0000 pourrait devenir, par exemple, 1111 0010 ou 1011 0000 ou 1110 1100 ou autre chose.

La parité et les systèmes de totalisation de comptage ont des problèmes avec des choses comme 1110 1000 où il y a un nombre égal d'sets et d'annulations, puisque la parité et le nombre de ceux-ci restnt les mêmes.

Donc, replace toutes les instances d'un caractère random par son inverse, disons 0x57 à 0x75 ('9' à 'K') ou vice versa, peut ne pas être détectable. Pour les systèmes qui ont mysql, la command "replace" existe pour un tel objective:

 replace K 9 < goodInputFile > corruptedOutputFile 

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

 replace K 9 9 K < goodInputFile > corruptedOutputFile 

Utilisez man replace pour plus d'informations.

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

Je serais heureux avec seulement 3 échantillons, changeant seulement 1 bit dans le premier octet, dans le dernier octet et dans n'importe quel octet moyen. Mais seulement 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 file du premier au dernier octet. Cela ne peut pas être (généralement) obtenu avec les outils habituels, vous devez en build un (je suppose).

Avec cette approche, vous isoler beaucoup de possibilités, y compris endianess si votre algorithm est basé dans un type de finianess. Dans d'autres mains, un grand échantillon peut prendre beaucoup de time à traiter.

Enfin, certains échantillons tronquant ou ajoutant des octets complèteront vos tests.