強名稱保護代碼完整性：原理、簽名與驗證全解析

強名稱由組件身分（簡單名稱、版本號、文化特性）、公開金鑰與數位簽名組成。它依賴非對稱加密的金鑰對，確保組件名稱全域唯一、版本沿襲受保護，並提供可靠的完整性檢查。不過，強名稱本身不代表信任等級，也無法阻止惡意程式碼執行。

強名稱的三大核心作用

• 區分不同組件（避免同名衝突）
• 確保代碼未被竄改
• 只有強名稱組件才能安裝至全域組件快取 (GAC)

簽署與驗證流程

簽署時，先對組件（不含 DOS/PE 標頭）計算雜湊值，再以私鑰加密雜湊得到密文，將公開金鑰、公開金鑰標記（SHA-1 雜湊後 8 位元組）與密文存入組件。載入時，CLR 重新計算雜湊（新雜湊值），並用公開金鑰解密密文得到原始雜湊值，兩者相符即通過驗證（如圖 9-7）。

圖 9-7 簽署（上）與驗證（下）強名稱流程

一般簽名與延遲簽名

延遲簽名適用於開發人員僅持有公開金鑰的情況：先編譯並預留簽名空間，此時組件無法正常執行與偵錯，需稍後由持有私鑰者完成簽名。

使用 SN.exe 建立金鑰並簽名

透過 Visual Studio SDK 的 sn.exe -k test.snk 產生金鑰對（如圖 9-8），再以 csc.exe /keyfile:test.snk Program.cs 編譯簽名（圖 9-10）。執行後可透過反射讀取公開金鑰與 Token（圖 9-11）。

圖 9-8 產生金鑰檔

Visual Studio 整合簽名

在專案屬性的「簽名」頁面勾選「為組件簽名」，可選擇現有金鑰檔或建立新金鑰（.pfx），亦可勾選「僅延遲簽名」（圖 9-12、9-13）。

圖 9-12 專案簽名屬性頁

竄改測試

若以文字編輯器修改已簽名的 StrongName.exe（如將變數 aa 改為 bb，圖 9-14），CLR 載入時會因完整性驗證失敗而拒絕執行。

圖 9-14 修改強名稱組件導致驗證失敗

作者：玄魂
出處：https://www.cnblogs.com/xuanhun/