[鐵人賽] Day 25：Ghidra × IoT 韌體安全審查 — 從逆向到防守的實戰指南

📅 資安院獎金獵人倒數 。今天，我要準備進入「逆向工程」階段。
隨著台灣越來越多中小型自製韌體、驅動與燒錄程式廠商投入 IoT 市場，這也是紅隊最該掌握、藍隊最該防守的區域。

🎯 為什麼 Day25 要從逆向開始

IoT 裝置幾乎都帶有：

• 專屬的燒錄或更新工具；
• 自家驅動（USB、UART、SPI）；
• 或在 Windows / Linux 上執行的控制軟體。

這些程式通常：

• 沒有嚴謹的金鑰管理；
• 沒有數位簽章；
• 驗證流程寫在本地；
• 更新包沒有簽章驗證。

🧰 工具與環境準備（防守方用）

💡 合法性提醒：
僅分析自家產品或明確授權樣本。
保留 hash、來源與版本紀錄以備追蹤。

🧩 Ghidra 快速上手（防守視角）

1. 建立 Project
   每個韌體或驅動建立獨立 Project，方便版本對比。

2. 匯入樣本
   Ghidra 會自動識別架構（x86、ARM、MIPS…）。若是韌體映像，先用 binwalk 分割出可執行區段再匯入。

3. 主要介面區塊

   • CodeBrowser：反編譯視窗，可讀取類 C 語法。
   • Function List / Symbol Tree：快速定位初始化、驗證、授權等函式。
   • Strings Window：找明文字串（license、key、serial、dongle…）。
   • Decompile 窗格：閱讀邏輯、條件判斷、呼叫關係。

4. 自動化分析
   使用 Scripts 或 Headless 模式批量掃描可疑字串、API 呼叫、或未簽章的更新函式。

🔍 防守導向分析流程

不做破解、不 patch、不繞過，只觀察「風險點」。

① 樣本登錄

• 檔名、版本、hash、簽章狀態。
• 來源：官方下載或內部版本庫。

② 字串掃描

• 搜尋關鍵詞：license, dongle, serial, key, update, challenge, server.
• 標註任何明文金鑰、API URL 或硬編碼密碼。

③ 函式定位

• 追蹤加密、簽章、網路、USB I/O 函式。
• 用 xrefs 看呼叫鏈（如驗證 → 授權 → 回傳）。

④ 驗證流程檢查

• 是否僅在本地檢查授權？
• 是否缺少伺服器二次驗證？
• 是否使用固定金鑰、靜態回應？
  → 若答案是，是高風險。

⑤ 通訊安全檢查

• 網路：是否 TLS？token 是否有時效？
• USB：是否允許未授權命令？
• 若是 OTA：更新檔是否有簽章驗證？

⑥ 驅動層面檢查

• IOCTL 請求是否檢查權限？
• 是否存在 buffer overflow 或 over-privileged 驅動？
• Kernel 模組是否經簽章？

⑦ 匯總風險

⚖️ Ghidra vs IDA Pro (Free)

💬 結論：
Ghidra 的「開源 + 反編譯 + 批次掃描」特性，非常適合企業做內部韌體稽核與授權安全檢查。
若需大規模自動化、多人共用分析結果，Ghidra 性價比遠高於 IDA Free。

🧾 審查報告建議格式

1. 技術摘要

   • 產品名稱、版本、hash、簽章狀態
   • 高風險項摘要（本地驗證、未簽章更新…）

2. 細節報告

   • 每項發現附上：函式名稱、反編譯片段、字串位置、風險等級
   • 附修補建議（短期 / 中期 / 長期）

3. 改善路線圖

   期程	建議	責任單位
   短期	修補硬編碼金鑰	開發
   中期	引入簽章驗證機制	研發 / 資安
   長期	改 server 驗證架構	系統整合

🚫 常見誤區與提醒

❌ 「混淆就安全」 → 混淆只是延遲時間，不是防禦。
❌ 「驗證放本機比較快」 → 攻擊者逆向後可輕易繞過。
✅ 把驗證邏輯搬上伺服器 + 使用非對稱簽章。
✅ 更新必須簽章驗證。
✅ Dongle 通訊應有 challenge-response 與 nonce。

🧠 小結：Ghidra 是 IoT 安全的顯微鏡

• 快速發現硬編碼金鑰；
• 找出驗證漏洞；
• 檢查更新機制；
• 形成修補路線圖。