CRCチェックサムを使用して破損したアーカイブを検証する関数を作成しました。
テストするには、アーカイブを開き、16進エディタを使用して内容を混乱させました。問題は、これが破損したファイルを生成する正しい方法だとは思わないということです。
完全にランダムではありませんが、実際に破損したアーカイブで何が起こるのかをシミュレートできるように、「管理された損傷」を作成する別の方法はありますか？私は意図的に何かを壊したことがないので、ファイルのデータをランダムに混乱させる以外に何をすべきかわかりません。
ベストアンサー1
私はまだ多くのことをしていません。ファズテストどちらかですが、ここには2つのアイデアがあります。
ファイルの途中にいくつかのゼロを書き込みます。ddと一緒に使用されますconv=notrunc。これは1バイトを書き込みます（ブロックサイズ= 1個数= 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シーンと一致します。 （まれなファイルまたは事前に割り当てられた範囲は、まだ作成されていないすべての場所から0を読み取ります。）
不良RAM（ファイルをダウンロードするシステム）は損傷を引き起こす可能性があり、オプティカルドライブもファイルを損傷する可能性があります（ECCが傷や染料の変色から完全に回復するほど強力ではありません）。
DVDセクタ（ECCブロック）は2048Bです。ただし、シングルバイトまたはシングルビットエラーが発生する可能性があります。一部のドライブは、特にネイティブモードで読み込んだり読み込んだりすると、セクタの読み取りエラーの代わりに修正できない誤ったデータを提供する可能性があります。