ファイルハッシュを変更する原理
典型的な暗号学的ハッシュには、MD5、SHA-1/256 などがあります。暗号学的ハッシュ関数の設計における核心的な特徴は「雪崩効果」です。つまり、入力にどれほど小さな変化があっても、出力には大きな変化が生じます。これは、たとえ 1 バイトだけを変更した場合でも、ハッシュ値全体がまったく異なるものになることを意味します。例を挙げると、2000 字の文書を作成して word ファイルに保存した場合、その中の 1 文字を変更する、たとえば空白を 1 つ追加するだけで、このファイルの md5 は完全に変わります。したがって「ファイルハッシュを変更する」ことの本質は、ファイル名のような外部属性ではなく、ファイル内容そのものを変更することです。この特性により、ファイル単位のハッシュ変更は比較的容易に実現できます。
システムや形式によって「メタデータ」の扱いは異なります。メタデータがファイルデータ内に埋め込まれている場合（JPEG や動画コンテナ内のタグなど）、それを変更するとハッシュも変わります。一方、メタデータがファイルシステムの外部データストリームや属性に保存されている場合、それを変更してもファイル内容に基づいて計算されるハッシュには影響しません。これが「ファイル名を変えてもハッシュは変わらないが、埋め込みメタデータを変えると変わる」という一般的な現象の理由です。
動画プラットフォームのトランスコードと「ハッシュが変更されたかの識別」
ユーザーが動画プラットフォームに動画をアップロードすると、プラットフォームはその動画に対して次の処理を行います。
元ファイルの受信
形式チェックと検証
トランスコード処理（形式変換、解像度調整、圧縮）
キーフレームの抽出
多層ハッシュ計算
これは「逆多重化→デコード→処理→再エンコード→多重化」というトランスコードのパイプラインであり、複数ビットレート/複数解像度のアダプティブ再生用バージョンを生成するためのものです。この処理自体がファイルのバイト列およびアップロード前の暗号学的ハッシュを変更します。
ファイルハッシュの観点では、プラットフォームはトランスコードの過程でファイルを再生成するため、元のファイルハッシュは自然に変化します。したがって、ユーザーが事前に変更したファイルハッシュは、トランスコード後には意味を持ちません。そのため、プラットフォームがそのファイルの md5 などが変更されたかどうかを識別することはありません。意味がないからです！
重複排除や著作権検出の段階では、アップロード者のファイルハッシュには依存せず、プラットフォームがデコード後の内容に対して独自の「音声・動画フィンガープリント/知覚ハッシュ」を計算し、データベース内の参照フィンガープリントと照合します。たとえば YouTube の Content ID は、アップロードされた内容を「フィンガープリント化」し、権利者が提供した参照データと照合します。
したがって、プラットフォームが行っているのは「ハッシュが変更されたことを識別する」ことではなく、「アップロード時のハッシュを無視し、コンテンツのフィンガープリントを再計算して照合する」ことです。そのため、単にファイルのバイト列やコンテナのメタデータを変更して MD5/SHA を変えても、コンテンツベースの検出を回避することはできません。
