檔案簽名表快查單是一份精簡的參考資料,將每個常見的檔案格式與其十六進位前綴配對——也就是在真實檔案的偏移位址零處出現的固定位元組。十二個經來源查證的前綴涵蓋了開發人員在檔案上傳流程、事件回應與二進位檢查中實際會遇到的格式:JPEG、PNG、兩種常見的 GIF 標頭、PDF、ZIP、GZIP、7-Zip、RAR 4、RAR 5、ELF,以及 SQLite 3。這份表列出以空格分隔的大寫十六進位位元組,讓您可以直接將值複製到十六進位檢視器、libmagic 規則或事件分析筆記中,無需再從不同表示法重新輸入。快查單的數值不一定是可信的;前綴是多項訊號之一,最實用的表格會直接標示出歧義之處,而非暗示位元組相符就等於已驗證的檔案類型。因此,檔案簽名表快查單最正確的理解是作為快速查詢工具,而非完整的偵測器——它是一個起點,您還需搭配結構化剖析、大小限制與安全性控管,才會在接收上傳前完成驗證。

檔案簽名快查單應包含的內容
一份實用的快查單包含四個欄位:格式名稱(JPEG、PNG、ZIP)、與之相關的常見副檔名(jpg 和 jpeg、png、zip 以及 docx、xlsx、jar、epub)、偏移位址零處的精確十六進位前綴,以及一段關於歧義性的簡短說明。說明欄是最被低估的欄位。ZIP 的說明是「容器」,因為相同的前綴也出現在 DOCX、XLSX、JAR、EPUB 及其他 Office Open XML 套件中;JPEG 的說明是「JFIF 或 EXIF 變體」,因為 JPEG 可能以數種合法的標頭開端,視相機是否寫入 EXIF 區塊而定;PNG 的說明是「簽名加上 IHDR」,因為這八位元組的前綴是 PNG 簽名的一部分,且其後必定接著 IHDR 區塊。若缺少這些說明,快查單會讓使用者過度信任位元組相符結果,並將 DOCX 檔案誤判為原始 ZIP 下載。
完整的參考資料還會記錄前綴長度,並以空格分隔的大寫十六進位標示位元組。位元組長度告訴您在做出判斷前需要讀取檔案的多少內容,而統一的間距格式則可讓您直接將前綴貼入十六進位傾印,無需重新排版。值得交叉查證的來源包括 file 指令的 magic 資料庫 以及 GCK 檔案簽名表;兩者皆以版本控管維護項目,並記錄諸如 RAR 新舊格式等邊緣情況。位元組 50 4B 03 04 為 ZIP 本機檔案標頭,所有以 ZIP 為基礎的套件皆共用此前綴;但 RAR 在 4 與 5 版本之間變更了其簽名,因此快查單必須同時列出 RAR 4(52 61 72 21 1A 07 00)與 RAR 5(52 61 72 21 1A 07 01 00),而非將其合併。
| 格式 | 偏移零處的十六進位前綴 | 說明 |
|---|---|---|
| JPEG | FF D8 FF | JFIF 或 EXIF 變體 |
| PNG | 89 50 4E 47 0D 0A 1A 0A | 簽名加上 IHDR 區塊 |
| GIF87a | 47 49 46 38 37 61 | 較舊的變體 |
| GIF89a | 47 49 46 38 39 61 | 動畫 GIF 變體 |
| 25 50 44 46 | 標頭 ASCII 為 "%PDF" | |
| ZIP | 50 4B 03 04 | 容器 — 亦為 DOCX、XLSX、JAR、EPUB、APK |
| GZIP | 1F 8B | 串流,非記錄 |
| 7-Zip | 37 7A BC AF 27 1C | 歸檔容器 |
| RAR 4 | 52 61 72 21 1A 07 00 | 舊版 RAR 歸檔 |
| RAR 5 | 52 61 72 21 1A 07 01 00 | 現行 RAR 歸檔 |
| ELF | 7F 45 4C 46 | Linux 或 Unix 可執行檔 |
| SQLite 3 | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | 標頭 ASCII 為 "SQLite format 3" |
如何查詢並比對前綴與快查單
- 依格式、副檔名、十六進位前綴或「容器」等說明,在 檔案簽名(魔術位元組)表 快查單中搜尋。比起捲動瀏覽更快,特別是當您已知副檔名而想取得位元組,或已有位元組而想查詢格式時。
- 在可信的二進位檢視器中開啟可疑檔案,例如 xxd、hexdump、編輯器中的十六進位面板,或串流式十六進位檢視器。移至偏移零處並讀取前幾個位元組。
- 將這些位元組與快查單的列進行比對。來自維護良好來源的空格分隔大寫十六進位字串可直接用於該比對,無需重新排版。
- 將前綴複製到偵測規則、文件片段或事件分析筆記中。統一的間距格式可避免日後有人將該值貼回正規表示式或常數表時發生失誤。
- 在信任或處理該檔案之前,以維護良好的剖析器確認其完整結構。將前綴相符視為假設,而非定論。
讀取可疑檔案的前幾個位元組
實務工作流程如下:上傳請求進入您的流程,伺服器讀取前十六個位元組,並與快查單中預期格式的列進行比對。假設上傳檔案的副檔名為 .pdf。您讀取前四個位元組,看到 25 50 44 46,快查單確認 PDF 以 25 50 44 46 開頭,即 ASCII 字串 "%PDF"。接著您檢查接下來的四個位元組是否有 PDF 版本標記(例如 1.4 版為 2D 31 2E 34),並在檔案末端附近尋找 EOF 標記(25 25 45 4F 46)。僅有前綴相符是必要條件,但並非充分條件——若缺少版本行與 EOF 標記,該檔案可能已截斷、損毀,或是多格式檔案。
將同樣的工作流程套用於圖片上傳:您讀取前八個位元組,並以 FF D8 FF(JPEG)、89 50 4E 47 0D 0A 1A 0A(PNG)或兩種 GIF 簽名之一(47 49 46 38 37 61 為 GIF87a,47 49 46 38 39 61 為 GIF89a)進行比對。對於歸檔檔,50 4B 03 04 為 ZIP 本機檔案標頭,1F 8B 為 GZIP,37 7A BC AF 27 1C 為 7-Zip,52 61 72 21 1A 07 00 為 RAR 4,而 52 61 72 21 1A 07 01 00 為 RAR 5。對於原生 Linux 二進位檔,請讀取 7F 45 4C 46;對於 SQLite 資料庫,53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 即拼出 ASCII 字串 "SQLite format 3"。上述每次比對僅需數毫秒,這正是快查單在事件分類時發揮價值的原因。
容器歧義及前綴無法告訴您的內容
使用檔案簽名快查單時,最常見的錯誤就是讀到位元組 50 4B 03 04 便斷言「這是 ZIP 歸檔」。雖然它確實是 ZIP 本機檔案標頭,但它同時也是 DOCX、XLSX、PPTX、JAR、EPUB、APK 及許多其他以 ZIP 為基礎套件的前綴。若要識別容器內部的應用程式格式,健全的偵測器必須讀取必要的內部套件檔案(OOXML 的 [Content_Types].xml、JAR 的 META-INF/MANIFEST.MF、EPUB 的 mimetype),並檢查中繼資料、關聯與 Content-Type 宣告。快查單應明確標示此點;若未標示,您將把每個 DOCX 視為通用 ZIP 下載,從而破壞仰賴實際檔案格式的工作流程。
容器偵測也涉及安全性考量。以 ZIP 為基礎的檔案可能是解壓縮炸彈,可能包含路徑遍歷項目(例如 ../../etc/passwd),也可能含有巨集或指令碼等主動內容。識別容器並不代表其內容是安全的,位元組前綴也無法證明內容甚至是格式正確的。合理的上傳流程應接受該前綴,以維護良好的剖析器開啟容器,在解壓縮前強制大小限制、清理項目路徑,並以 Content-Disposition: attachment 及安全的 MIME 類型提供下載,而非以內嵌方式呈現。
從快查單列到正式環境的偵測規則
取得前綴與說明後,您可以將該列編碼為偵測規則。常數查詢是最簡單的形式:對前四個位元組進行 switch 判斷,回傳預期格式。這種方式快速且清晰,適合只需拒絕明顯錯誤類型的上傳流程。若需更豐富的偵測,請使用維護良好的程式庫,例如 libmagic——其規則支援間接偏移、遮罩、數值端序、字串與巢狀條件。快查單僅涵蓋偏移零處的前綴;file 指令的 magic 資料庫則涵蓋長尾的 magic 規則。若規則存於程式碼中,請將來源常數納入版本控管,將規則版本與判定結果一併記錄,並加入包含已接受格式與對抗性近似相符樣本的回歸測試。
第二條實用原則是:絕不僅因前綴相符就授權上傳。前綴可能被貼在惡意酬載的開頭,檔案可能已截斷,或該格式可能允許多個簽名。請以維護良好的剖析器驗證完整檔案、強制白名單、於伺服器端重新命名檔案、隔離儲存空間,並在適當情況下封鎖主動內容。針對高風險工作流程,請於傳遞前執行防毒或沙箱分析。偵測程式庫與解碼器必須保持更新,且規則應針對畸形、多格式、超大與巢狀樣本進行測試。請同時記錄觀察到的位元組與剖析器的判定結果,以便日後審查者區分前綴相符與已驗證的檔案結構。
快查單未涵蓋的內容
十二列的快查單並非全貌。它不包含 Windows 的 PE/COFF 或 macOS 的 Mach-O 等可執行檔子類型,亦不包含媒體編解碼器(MP4、MKV 與 WebM 各自使用位於檔案較深處的 box 或 EBML 結構)、磁碟映像(例如 ISO 9660 的磁碟區描述子自 0x8001 處開始)、字型檔、郵件格式,或所有歸檔變體(TAR 完全沒有魔術位元組;BZ2 為 42 5A 68,但僅在兩個可選的前導位元組之後)。通用的 libmagic 可透過讀取其他偏移、間接偏移、遮罩與字串來涵蓋這些情況。請將快查單作為高頻率的首道篩選,再參考維護良好的程式庫處理長尾,並在實作正式環境的偵測時重新查閱格式規範。
快查單本身也不會掃描您的檔案。例如檔案簽名(魔術位元組)表工具在瀏覽器中執行,僅複製所顯示的大寫十六進位序列,從不請求、讀取、上傳或剖析本機檔案。在敏感的案件回應中,樣本無法離開主機,此種區隔至關重要。請將查詢與在分析師自有機器上執行的維護良好之剖析器搭配使用,並在案件筆記中同時保留觀察到的位元組與剖析器的判定結果,以便日後審查者區分前綴相符與已驗證的檔案結構。