壓縮檔（ZIP／RAR）內容遭竄改如何用雜湊值舉證

當你收到一個 ZIP 壓縮檔，懷疑裡面的內容已經遭到他人替換、修改或刪除時，最核心的問題往往不是「我覺得它被動過」，而是「我能不能拿出技術證據，向對方或第三方證明這個檔案在某一刻之後被竄改了」。壓縮檔因為具備打包多個檔案的特性，使得竄改行為可能發生在容器層級（例如重新壓縮、替換其中的某個檔案、刪除特定檔案）或內部檔案層級（例如修改壓縮包內的某份 PDF 契約內容後再重新打包）。要證明這類竄改，最可靠的技術手段是透過密碼學雜湊值（cryptographic hash）進行前後比對，因為 SHA-256 等雜湊函數具有單向性與抗碰撞特性，即使壓縮檔內只有一個位元組被改動、時間戳記被重設、或是整個壓縮包被重新封裝，最終產出的雜湊指紋都會截然不同。這篇文章將以實務流程說明如何透過逐步提取壓縮檔及其內部檔案的中繼資料與雜湊值，建立一份能夠說明檔案狀態是否一致的技術紀錄，並且解釋這些技術證據能證明什麼、不能證明什麼，避免在後續爭議中過度宣稱。 證明壓縮檔內容遭到竄改的第一步，是先釐清「容器層級」與「內容層級」這兩種不同的驗證層次。容器層級指的是將整個 ZIP 檔案視為一個獨立的二進位檔案，直接對整個檔案計算 SHA-256、MD5 或 CRC32；如果這個壓縮檔在首次交接時已經記錄下完整的雜湊值，事後只要重新計算一次，發現雜湊值與原始紀錄不同，就能在技術上確認「這個壓縮檔的某處已經不再是當初交接時的那一份」，但這個層級的證明無法指出究竟是哪一個內部檔案被改動、加入了什麼、或刪除了什麼。內容層級的驗證則需要解壓縮之後，針對壓縮包內的每一個個別檔案分別計算雜湊值，再與原始版本的個別檔案雜湊進行比對，這樣才能精確指出「contract.pdf 被替換了」「附圖 IMG_001.jpg 的 EXIF 拍攝時間被修改了」「report.docx 被加入了額外段落」等具體事實。在實務爭議中，這兩個層級通常要同時進行：容器層級的雜湊差異可以快速證明「檔案確實被動過」，內容層級的逐檔比對則可以進一步解釋「具體被動的是哪些檔案」。 假設有一個名為 project-deliverable-v2.zip 的壓縮檔，內含設計稿、合約掃描檔、照片素材與一份說明文件。你在三月一日收到這個壓縮檔時，應該立刻對整個 ZIP 檔計算並記錄其 SHA-256 值，同時解壓縮後對內部的每個檔案分別記錄 SHA-256 與關鍵中繼資料（例如照片的 EXIF 拍攝時間、PDF 的建立與修改時間、文件的作者欄位）。幾週後，對方宣稱「同一個檔案」但重新寄送了一份 project-deliverable-v2.zip，你懷疑內容遭到替換。此時的正確做法是：先對新收到的整個 ZIP 計算 SHA-256，與三月一日記錄的容器雜湊比對；若兩者不同，技術上已經可以確認「這不是同一個壓縮檔」。接著解壓縮新檔案，對內部的每個檔案計算 SHA-256，逐一與原始版本的個別檔案雜湊比對。假設最終發現 design-final.png 的雜湊值與原始版本不同，而 contract-scan.pdf 的雜湊值一致，你就可以具體陳述「壓縮檔內的設計稿被替換或修改過，但合約掃描檔與原始版本完全一致」。這種逐檔比對的紀錄，就是後續無論是內部爭議處理還是外部仲裁時，最具說服力的技術證據。 在處理上述比對流程時，使用 FilesAudit 這類線上數位鑑識與檔案驗證平台可以大幅簡化紀錄產生的工作。將壓縮檔上傳至 FilesAudit 首頁 的驗證介面後，系統會自動提取壓縮檔本身的中繼資料（包括檔案大小、建立時間、修改時間、壓縮工具資訊等），並計算出 SHA-256、MD5、CRC32 等多種雜湊值，最終產出一份包含時間戳記與密碼學指紋的專業 PDF 報告。這份報告的價值在於它不是你手動截圖或自行填寫的表格，而是由獨立第三方平台依據當時上傳的檔案狀態所產出的技術紀錄，能夠作為「在某個特定時間點，這個檔案的雜湊值與中繼資料狀態如下」的客觀佐證。如果需要驗證壓縮檔內特定類型的檔案，例如封裝在壓縮包內的 JPG 照片是否具有一致的 EXIF 與 GPS 資訊，可以參考 JPG 中繼資料分析指南 了解具體可提取的欄位；若懷疑被替換的是 PDF 合約檔案，則 PDF 被竄改檢測完整教學 詳細說明了如何透過雜湊驗證與中繼資料比對來判斷 PDF 是否遭到修改。 值得注意的是，壓縮檔本身會記錄一些看似可以佐證竄改的中繼資料，例如每個內部檔案的「最後修改時間」（last modified time）、「最後存取時間」（last accessed time）以及「建立時間」（creation time），這些時間戳記在某些情況下確實能提供線索，但它們本質上是可被修改的，並不具有密碼學上的不可竄改性。舉例來說，攻擊者可以在替換壓縮包內的檔案後，使用特定工具將新檔案的修改時間調整為與原始檔案一致，使得壓縮包在檔案總管中看起來「沒有任何變化」。因此，時間戳記可以作為輔助觀察的參考，但絕對不能單獨作為證明檔案未被竄改的依據；真正能夠在技術上證明檔案是否一致的，只有密碼學雜湊值的比對結果。在實務操作中，當你發現一個壓縮檔的整體 SHA-256 與原始紀錄不同，但內部所有檔案的個別時間戳記卻完全一致時，這本身已經是一個強烈的竄改跡象 —— 時間被刻意保留了，但檔案內容的位元層級已經改變。 另一個在壓縮檔竄改爭議中常見的技術細節，是壓縮方式與壓縮工具資訊。ZIP 格式允許使用不同的壓縮演算法（例如 Deflate、Deflate64、BZIP2、LZMA 等）和不同的壓縮等級，不同壓縮工具（如 7-Zip、WinRAR、Windows 內建壓縮、macOS 封存工具）產生的 ZIP 容器結構也會有差異。如果某人解開壓縮檔、替換了內部檔案後再重新壓縮，即使使用的檔名完全相同、內部檔案的時間戳記被調整為一致，壓縮工具欄位與壓縮方式欄位可能會暴露重新封裝的事實。例如，原始壓縮檔是由 7-Zip 產生並使用 LZMA 壓縮，但重新封裝後變成 Windows 內建工具產生的 Deflate 壓縮，這種中繼資料差異就可以作為「壓縮包被重新封裝過」的佐證。不過要特別強調，這些中繼資料的差異只能說明「壓縮包的封裝條件與原始版本不同」，至於這是否等同於「惡意竄改」仍需要結合其他證據與情境判斷，因為對方也可能主張只是「重新整理壓縮檔而未修改內部檔案」。此時，內部檔案的個別 SHA-256 比對才是決定性的技術證據。 在建立完整的竄改證明文件時，建議的紀錄結構包含以下幾個層面：首先是原始壓縮檔在首次交接時的整體 SHA-256、MD5 與 CRC32 值，以及當時提取的壓縮檔中繼資料；其次是原始壓縮檔解壓縮後，每個內部檔案的個別 SHA-256 值與關鍵中繼資料（包括文件類型、檔案大小、建立與修改時間、作者欄位、EXIF 資料等）；第三是待驗證壓縮檔的對應紀錄；第四是逐項比對結果，明確標示哪些檔案的雜湊值一致、哪些不同、哪些是新增加的、哪些是消失的。FilesAudit 產生的 PDF 報告可以直接作為第一項與第三項的技術紀錄來源，而對於壓縮