アーカイブファイルを制御された方法で破損する方法は？

CRCチェックサムを使用して、破損したアーカイブをチェックする関数を作成しました。

それをテストするために、アーカイブを開き、16進エディタでコンテンツをスクランブルしました。問題は、これが破損したファイルを生成する正しい方法だとは思わないことです。

「制御された破損」を作成する他の方法はありますか。完全にランダムではありませんが、実際の破損したアーカイブで何が起こるかをシミュレートできますか？意図的に何かを破損する必要はなかったので、ファイル内のデータがランダムにスクランブルされる以外に、その方法についてはよくわかりません。

ファズテストもあまり行っていませんが、次の2つのアイデアがあります。

ファイルの中央にゼロを書き込みます。で使用ddしconv=notruncます。これにより、1バイトが書き込まれます（block-size = 1 count = 1）：

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

/dev/urandomソースとして使用することもオプションです。

または、で4kの倍数の穴を開けfallocate --punch-holeます。fallocate --collapse-rangeゼロで埋められた穴を残さずにページを切り取ることができます。（これにより、ファイルサイズが変更されます）。

間違った場所でダウンロードを再開すると、--collapse-rangeシナリオと一致します。不完全なトレントはpunch-holeシナリオに一致します。（スパースファイルまたは事前に割り当てられたエクステント。まだ書き込まれていない任意の場所でゼロとして読み取られます。）

（ファイルをダウンロードしたシステムの）不良RAMは破損を引き起こす可能性があり、光学ドライブもファイルを破損する可能性があります（ECCは、スクラッチまたは染料の退色から完全に回復するほど強力ではない場合があります）。

DVDセクター（ECCブロック）は2048Bですが、1バイトまたは1ビットのエラーさえ発生する可能性があります。一部のドライブは、特にrawモードで読み取る場合、またはそれが呼び出された場合に、セクターの読み取りエラーではなく、不良な修正不可能なデータを提供します。

他の答えは、主にハードウェアエラーに関係しているようです。ソフトウェアによって引き起こされる破損をいくつか挙げてみましょう。

• LFはCRLFに置き換えられました。
• CRを削除しました。（LFが続かない場合でも）
• 余分なNullバイトが挿入されました。
• 追加のUnicode「バイトオーダーマーク」が挿入されました。
• UTF-8からLatin-1またはその逆に変換された文字セット。
• DOS EOF文字（＃1A）は、ファイルの終わりにない場合でも削除されます。

これらのことは、テキストファイルに発生した場合はかなり無害ですが、バイナリファイルに適用した場合は一般に致命的です。

を使用ddしてファイルを切り捨てるか、hexer編集して破損を引き起こすようなバイナリエディターを試してください。

ddを使用してファイルを切り捨てる例

5MBファイルを作成

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

末尾から10バイトを切り捨てます

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

提案：

アーカイブへの書き込みを開始し、終了する前に書き込みを行うことを停止します。これは、停電やその他のシナリオで発生する可能性があります。

実際のシナリオ：

zipファイルを、メディアに収まるよりも多くのデータをコピーしようとすることで破損したことがあります。Windows（これはセーフモードftrのWindows 7）は、十分なスペースがあるかどうかを判断する前にアクションを完了しようとしました。Windowsの以降のバージョンでその問題を修正したか、それが単なるセーフモードの問題であったことを願っています。

別の一般的なタイプの破損はビットトゥイッドリングです。データストリーム内で1つのビット（または複数のビット）が切り替えられます。

したがって、バイト1111 0000は、たとえば、1111 0010または1011 0000、1110 1100または何かになります。

パリティおよび1カウントチェックサムシステムには1110 1000、パリティと1の数の両方が同じであるため、セットとアンセットの数が等しい場合などの問題があります。

したがって、ランダムな文字のすべてのインスタンスをその逆、たとえば0x57から0x75（「9」から「K」）またはその逆に置き換えることは検出できない場合があります。mysqlがあるシステムの場合、コマンド "replace"はまさにその目的のために存在します：

replace K 9 < goodInputFile > corruptedOutputFile

また、Kと9の文字を入れ替えてみることもできます。これは、ファイル内で両方が同じ回数出現する場合に特に適したテストになります。

replace K 9 9 K < goodInputFile > corruptedOutputFile

man replace詳細情報に使用します。

サンプルを再現してテストを再実行することはできないため、破損したテストデータへのランダムな変更は適切なアプローチではありません。

最初のバイト、最後のバイト、および中間バイトの1ビットのみを変更して、3つのサンプルのみで満足です。ただし、バイト全体ではなく、1ビットだけです。

しかし、最高のテストサンプルは、ファイルの各1ビットを最初のバイトから最後のバイトまで変化させるサンプルを生成できるものです。これは（通常）通常のツールでは取得できません。作成する必要があります（推測）。

このアプローチでは、アルゴリズムが1種類のエンディアンに基づいている場合、エンディアンを含む多くの可能性を分離します。一方、大きなサンプルは処理に時間がかかる場合があります。

最後に、バイトを切り捨てたり追加したりするサンプルによってテストが完了します。