私はバイナリファイル形式を最初から設計していますが、簡単に識別できるように、最初にいくつかのマジックバイトを含めたいと思います。どのバイトを選択するにはどうすればよいですか?私はマジックナンバーの中央レジストリを知らないので、たとえば、近くのUNIXボックスのfileコマンドでまだ識別されていない、かなりランダムなものを選択するだけの問題ですか?
2 に答える
超短いマジックナンバーには近づかないでください。バイナリ形式を設計しているからといって、識別子にテキスト文字列を使用できないわけではありません。その後にEOF文字が続きます。追加のボーナスとして、バイナリファイルを猫にしたり入力したりする人は、壊れた端末を取得しません。
普遍的に正しい方法はありません。ベストプラクティスを提案することもできますが、これらは状況に応じて行われることがよくあります。たとえば、電源を入れたときに初期状態が定義されていない揮発性メモリの整合性をチェックする場合、FFF0 00FF F000
ランダムノイズに対して目立つことができるシーケンス(つまり)に多くの0または1を組み込むことが有益な場合があります。
ファイルの大部分がバイナリである場合、一般的な選択肢は、16進エディタのバイナリデータの中で目立つASCIIのようなテキストエンコーディングを使用することです。たとえば、GIFはを使用しGIF89a
、FLACはを使用しfLaC
ます。一方、ランダムテキストファイルでプレーンテキスト識別子が誤って検出される可能性があるため、無効/制御文字が組み込まれる可能性があります。
一般に、それらが何であるかはそれほど重要ではありません。ファイルの検出には、NULLバイトの束でさえ使用できます。ただし、理想的には、余裕のある最長の一意の識別子が必要であり、少なくとも4バイトの長さが必要です。4バイト未満の識別子は、ランダムデータでより頻繁に表示されます。長いほど、誤検知として検出される可能性は低くなります。いくつかの既知の例は40バイトもの長さです。ある意味、それはパスワードのようなものです。
また、オフセット0である必要はありません。ファイルの署名は、最初に処理される場合は最初に保存するのが理にかなっているため、従来はオフセットゼロでした。
とはいえ、単一のファイル署名だけが防御線であってはなりません。実際の解析プロセス自体は、署名が一致している場合でも、整合性を検証し、無効なファイルを取り除くことができるはずです。これは、長さに依存するデータ、値/範囲チェック、特にハッシュ/チェックサム値を使用して、追加のファイル署名で実行できます。