The Principle of Modifying File Hashes
Typical cryptographic hashes include MD5, SHA-1/256, etc. The core feature of cryptographic hash function design is the "avalanche effect" - any tiny change in the input leads to a huge change in the output. This means that even modifying just one byte will result in a completely different hash value. For example, if you write a 2000-word document and save it as a Word file, changing just a single character, such as adding a space, will completely alter the file's MD5 hash. Therefore, "changing a file's hash" essentially means changing the file's content itself, not external attributes like the file name. This characteristic makes file-level hash modification relatively easy to implement.
Different systems and formats have different definitions of "metadata": If metadata is embedded in the file data (such as tags in JPEG/video containers), modifying it will change the hash; if metadata is stored in external file system data streams or attributes, modifying it will not affect the hash computed based on the file content. This explains the common phenomenon where "renaming a file does not change its hash, but modifying embedded metadata does."
Video Platform Transcoding and "Detecting Whether Hashes Were Modified"
When a user uploads a video to a video platform, the platform performs the following on the video:
Receive the original file
Format inspection and validation
Transcoding processing (format conversion, resolution adjustment, compression)
Keyframe extraction
Multi-layer Hash Calculation
This is a transcoding pipeline of "demultiplexing → decoding → processing → re-encoding → multiplexing," which produces multiple versions for adaptive streaming at various bitrates/resolutions. This process inherently changes the file's byte sequence and any cryptographic hash computed before upload.
Regarding file hashes: The platform regenerates the file during transcoding, so the original file hash naturally changes. Therefore, any pre-modification of the file hash by the user becomes meaningless after transcoding. Hence, the platform does not bother to check whether the file's MD5 or other hashes have been modified - it is completely irrelevant!
Deduplication/copyright detection does not rely on the uploader's file hash. Instead, the platform computes its own "audio/video fingerprint/perceptual hash" on the decoded content and compares it with reference fingerprints in the database. For example, YouTube's Content ID "fingerprints" the uploaded content and matches it against references provided by rights holders.
Therefore, the platform does not "detect that the hash was modified"; rather, it "ignores the uploaded hash, recalculates the content fingerprint, and performs matching." This means that solely modifying file bytes or container metadata to change MD5/SHA cannot bypass content-based detection.
[tool:60]