DFU-Tools：把 Apple Configurator 的 DFU 恢復流程包成 macOS GUI（但無授權檔，先看清楚再用）

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

當 Apple Silicon Mac 或搭載 T2 安全晶片的機種突然開不了機，連長按電源鍵進恢復模式都進不去時，往往得走 DFU 模式這條更深的路。Apple 官方在這條路上提供了 Revive 與 Restore 兩種操作，但條件不輕：要第二台正常的 Mac、要 Apple Configurator、要按對按鍵時機。XRSec 這個 GitHub 組織帳號維護的 DFU-Tools，做的事情是把官方流程裡那條 cfgutil 命令列包成一個 macOS 原生視窗，47 顆星、Swift 寫成、原始碼公開。它沒有 LICENSE 檔，嚴格來說不是開源，也不會讓你少準備一台 Mac。先把這兩件事講在前面，再談它究竟能幫上什麼忙。

把官方流程包成視窗：DFU-Tools 在 cfgutil 上多蓋了一層

DFU-Tools 是 XRSec 這個 GitHub 組織帳號下的一個 macOS 桌面應用，倉庫 XRSec/DFU-Tools，2023 年 12 月建立，最近一次實質更新落在 2026 年 4 月（釋出 1.2.0 版），語言是 Swift，原生 Cocoa 不是 Electron。XRSec 本身登記為 Organization，公開成員只有一人，沒有對外揭露公司法人資訊，定位上比較接近個人 side project 而非有正式公司背書的產品線。

它做的事情其實很單一：把 Apple Configurator 那條命令列工具 cfgutil 包進一個視窗。整個工具圍繞著四個動作編排（DFU、Reboot、Restore、Revive），但比起按鈕本身，更實用的是它在畫面上常駐顯示「目前接上的設備處於什麼狀態」，並把 cfgutil 每一步的 log 印在下方視窗，讓你不用再切回終端機翻訊息。

Pin

這裡有一個容易誤會的地方要先講：DFU-Tools 不能脫離 Apple Configurator 單獨運作。它的 Restore 與 Revive 按鈕背後呼叫的是 cfgutil，所以你這台負責操作的 Mac 仍然必須先從 Mac App Store 裝好 Apple Configurator，DFU-Tools 比較像是「在已經裝好 Configurator 的前提下，幫你省下背指令與查 log 的功夫」，而不是取代官方工具。

先分清楚 Revive 與 Restore：一個保留資料，一個清空整台

會走到 DFU 這一步的設備通常已經很慘，但這兩個按鈕按下去的後果差很大，看清楚再點是整個流程裡最關鍵的判斷。

標準排序是把 Revive 擺在第一個。它的目標只有一個：把開不了機的機器拉回可開機狀態，過程不碰使用者的檔案。多數「突然黑屏、進不去恢復模式」但硬體本身沒壞的案例，Revive 成功之後資料還在原處。這個排序不是 DFU-Tools 自己的建議，Apple 官方文件也是同樣的優先順序。

Restore（恢復）是另一個量級的操作，等於整台重灌，硬碟裡原本的東西會全部消失，機器回到剛出廠的狀態。除非 Revive 確定救不回來、或你本來就打算全清重灌，否則不要輕易走到這一步。DFU-Tools 在畫面上把這兩個按鈕並排，視覺上沒有特別警示，所以操作前自己心裡要先有這條紅線，不要因為點得到就亂試。一個比較保險的習慣是，每次點下去之前再把游標移回按鈕上唸一次名字，確認自己要按的是 Revive 還是 Restore，多唸一次能擋下相當一部分按錯的情況，這在介面沒有防呆設計時是實用的自我保護。

剩下的 DFU 與 Reboot 兩個按鈕，前者強制讓目標設備進入 DFU 模式（需要管理員權限），後者單純重啟設備。兩者在 cfgutil 裡都有對應指令，DFU-Tools 只是把它們搬進圖形介面。

從原始碼結構來看，DFU-Tools 內部有幾個分工明確的 Swift 模組：USBDeviceMonitor 負責監聽 USB 設備的插拔與狀態、DeviceBindingManager 負責把偵測到的設備綁定到畫面清單、SecureDFUManager 與 ProcessOutputReader 負責呼叫底層命令並把輸出抓回來、LogManager 則把這些輸出整理進下方的 log 視窗。整個流程其實是「偵測、觸發、回報」三件事的自動化，沒有自己實作任何韌體恢復邏輯，這也是為什麼它必須依賴 Apple Configurator 才能完成 Restore 與 Revive。

Pin

它跟直接用 Apple Configurator 的差別：把 cfgutil 包給反覆跑流程的人

Apple Configurator 2 本身就有圖形介面，也能做 Revive 與 Restore，那 DFU-Tools 多了什麼？從倉庫原始碼來看，最明顯的差別是把「設備目前在哪個狀態」做成主畫面常駐顯示。原廠 Configurator 比較偏向裝置管理與佈景部署，介面資訊密度高，救磚只是它其中一個功能；DFU-Tools 把範圍收窄到只剩 DFU 流程會用到的幾個動作，並把 log 拉成獨立視窗。

但這個差別值不值得你為此多裝一個未簽署的第三方 App，要看你跑這套流程的頻率。對一輩子大概只會做一次的人來說，學一套只會用一次的 GUI 不見得划算，直接用已經裝好的 Apple Configurator 反而省事。真正能從 DFU-Tools 拿到價值的，是每個月可能要跑好幾次 DFU 的人，這時候省下切換終端機、查 log、確認設備狀態這幾道手續，累積起來才有感。

幫你把這幾條路徑擺在一起比，會更容易看出各自的責任歸屬：

要誠實說的是，47 顆星的規模代表社群關注度有限，目前沒有第三方實測報告佐證它在大批量或邊界情境下的穩定性，把它當成熟工具看待之前，這點要先放在心上。它的優勢目前是奠基在「作者把 cfgutil 包得不錯」這個相對主觀的判斷上，而不是被廣泛驗證過的社群口碑。

Pin

授權狀態：原始碼公開，但不是開源

這是我建議你在執行前最該查清楚的一件事。DFU-Tools 的 GitHub 倉庫沒有任何 LICENSE、COPYING 或 NOTICE 檔案，GitHub 的 /license API 回傳 404，repo metadata 的 license 欄位是 null。

在沒有授權檔的情況下，預設是「保留所有權利」（all rights reserved）。作者把原始碼放在 GitHub 上讓你看得到、也抓得到編譯檔，但這跟「以開源授權釋出、允許你自由使用修改散布」是兩回事。嚴格講，連「下載執行」這個動作在法律上都沒有被作者明示授權。

實務上多數人會把它當作作者默許個人使用的小工具，但如果你的情境是企業內部大量部署、或想在商業流程裡依賴它，這層授權模糊就值得先跟法務確認過再決定。對照之下，Apple Configurator 是 Apple 官方免費提供且有明確授權條款的工具，這也是為什麼「DFU-Tools 只是輔助、底層仍要 Configurator」這個定位需要講清楚。

變磚與資料風險：系統級操作，權限與 Gatekeeper 都要留心

DFU 流程本質上是系統級、低階的韌體操作，任何一步出錯都可能讓設備狀態變得更糟，這不是 DFU-Tools 特有的問題，而是這類操作的天性。但 DFU-Tools 加上幾個值得知道的細節。

最關鍵的一點是權限與來源的組合。DFU 與 Reboot 需要管理員權限，這代表它會要求你輸入管理者密碼。一個未經簽署與公證的第三方 App 拿著管理者權限執行系統級命令，是你在按下同意前應該意識到的信任成本。同樣的道理也適用在任何要求 admin 權限的系統工具上，差別在於 DFU-Tools 的來源是 XRSec 這個沒有對外揭露公司資訊的 GitHub 組織，而不是有明確公司在背後擔保的軟體廠商。這也是為什麼像 Mac Sai 這類系統清理工具 我們會一併檢查授權與簽章：在同樣標榜「給 Mac 用」的背景下，授權清楚與否、有沒有簽章，往往比功能列表更值得當判斷起點。

順著簽章問題往下談，官方發布的 DFU-Tools 編譯檔沒有開發者簽章，macOS 的 Gatekeeper 預設會擋下，README 給出的解法是直接執行 sudo xattr -rd com.apple.quarantine /Applications/DFU-Tools.app。這行指令等於把隔離標記整個移掉，是繞過 Gatekeeper 而不是通過它，等於你自己承擔來源可信的判斷。如果你對來源有任何疑慮，比較穩的做法是自己從原始碼編譯，或乾脆用官方 Apple Configurator。這條 Gatekeeper 警示並不是 DFU-Tools 獨有，未簽署的 macOS 工具大多會遇到，例如 Agent Battery 同樣沒有簽章、也需要手動放行，只是它要求的權限比 DFU-Tools 輕得多。

另外要點出兩件容易被忽略的事。一是 DFU-Tools 不會、也無法幫你繞過啟動鎖（Activation Lock）或 MDM 啟用鎖，它只走 Apple 官方合規流程；如果你手上的設備卡在啟動鎖，這工具幫不上忙，請走 Apple 官方管道，換句話說它的設計是在「你本來就有權處理這台設備」的前提下運作，而不是拿來解決產權爭議或解除別人設備鎖。二是線材與接口這件看似的小事，卻是 DFU 流程最容易翻車的硬體環節：DFU 模式對 USB-C 對 USB-C 線的要求比一般充電嚴格，有些線只走充電不傳資料，接了設備也不會出現在 DFU-Tools 清單裡。如果你按了半天設備就是不出現，先換一條確認過能傳資料的線、再檢查是否插對支援資料傳輸的孔，往往比繼續按按鍵有效。

怎麼用：基本流程

走完一次需要的東西不複雜，但前置條件一個都不能少。

1. 準備兩台 Mac：一台是待救的設備（Apple Silicon 或 T2 機種），一台是負責操作的 Mac，兩台都要能正常開機。
2. 在操作的 Mac 上從 Mac App Store 安裝 Apple Configurator。
3. 下載 DFU-Tools 的發布版本，第一次開啟若被 Gatekeeper 擋，自行評估後再決定是否依 README 移除隔離標記，或自己編譯。
4. 用一梊可靠的 USB-C 對 USB-C 線（或轉接需要的接頭），把兩台 Mac 接起來，注意要接在正確的資料傳輸孔。
5. 讓待救的 Mac 進入 DFU 模式（按鍵時機依機型不同，參考 Apple 官方指南）。
6. 打開 DFU-Tools，等待設備出現在清單裡。
7. 先選 Revive 試修，看 log 視窗跑完的訊息判斷結果。
8. 只有在 Revive 確定失敗、且你能接受整台清空時，才考慮 Restore，並準備好對應機型的 IPSW 檔案。

操作前先確認你對設備型號、目前 macOS 版本、以及有沒有備份都心裡有數。DFU 流程一旦走到 Restore，沒有回頭路。

這裡補充一個機型上的差異：DFU 模式適用於 Apple Silicon（M1、M2、M3、M4 系列）的 Mac，以及配備 T2 安全晶片的 Intel Mac（例如 2018 年之後的部分機型）。更早的純 Intel Mac 沒有 T2，用的不是同一套 DFU 流程，也不在 DFU-Tools 與 Apple Configurator 這條路的處理範圍內。動手前先確認你那台待救的機器屬於哪一種，再去 Apple 官方支援文件找對應機型的 DFU 進入方式，按鍵時機在不同機型上不完全相同，這是照著教學做還是會翻車的常見原因。DFU-Tools 在這個環節幫不上忙，它只負責偵測設備有沒有進到 DFU，至於怎麼按出 DFU 模式還是得你自己照官方步驟來。

適合誰，不適合誰

比較適合的情境可以用一個條件貫穿：你本身就是「反覆跑這套流程」的人。這通常涵蓋常駐在 Mac 韌體排障第一線的角色，例如必須在時限內把一批故障機救回來的 IT 與維修人員，這類工作每個月可能跑好幾次 DFU，把 cfgutil 包成 GUI 在效率與減少按錯上確實有感。前提是手邊本來就有第二台 Mac、看得懂 log 訊息代表什麼，也能接受未簽署 App 與管理員權限這組信任成本。

反過來的情境也可以用一個條件判斷：你這輩子大概只會做這一次。如果你的設備突然出狀況、機器裡還有沒備份的東西、而你在這之前連 DFU 三個字母都沒聽過，與其在壓力下現學一套一年用不到一次的流程，不如直接把設備送 Apple 官方維修或授權維修中心。這不是能力問題，而是風險與時間的權衡：自己做的成本是「可能按錯把資料清空」，送修的成本是「等幾天與一筆檢測費」，多數一次性情境下後者更划算。

把這兩種情境擺在一起看，DFU-Tools 的價值不在「讓一般人也能自己救磚」，而在「讓已經會救磚的人省下查指令與翻 log 的幾道手續」。把它放在這個位置上評估，會比較接近它實際能扮演的角色。

幾個讀者常追問的問題

DFU-Tools 是開源工具嗎？

不是。原始碼看得到，但沒有 LICENSE 檔，預設是保留所有權利（詳見上方「授權狀態」段）。

它可以脫離 Apple Configurator 用嗎？

不能，它依賴 Configurator 附帶的 cfgutil，操作機上必須先裝好 Apple Configurator。

會不會把我的資料清掉？

點 Revive 不會碰檔案，點 Restore 會整台清空重灌。如果不小心已經點了 Restore，這條路沒有回頭，能做的只有停止任何後續操作、盡快找專業資料救援或 Apple 官方評估。

手上的 Mac 卡在啟動鎖，這工具能解嗎？

不能，它只走官方合規流程，不處理啟動鎖或 MDM 啟用鎖，這類需求請直接找 Apple。

三個可以立刻做的下一步

確認你的情境屬於適合的類型後，可以這樣往前推一步。

第一，如果你手上已經有兩台 Mac，先到操作的 Mac 上確認 Apple Configurator 能正常開啟、能讀到接上的設備，再決定要不要在官方流程之外另外裝 DFU-Tools。

第二，如果你判斷 DFU-Tools 對你的工作量真的有幫助，自己從 GitHub 上 clone 一份原始碼下來編譯，會比直接跑未簽章的發布檔更值得信任，也能順便確認它確實只是包 cfgutil。沒有公司背書的小型專案要做到這一點本來就比較吃力，這也是為什麼像 CodexBar 這類採明確 MIT 授權、由具知名度的開發者維護的 Mac 工具 在信任成本上會低一截，把授權狀態納入選擇條件是合理的事。

第三，如果待救機裡有重要資料，且你對流程沒有把握，把預約 Apple 官方維修當成預設選項，不要在沒有備份與沒有把握的情況下直接點 Restore。

最後再提醒一個觀念上的事：DFU 流程是「硬體還活著、但軟體層進不去」的最後一道自己能嘗試的關卡，它救不了真正的硬體故障，例如主機板燒毀、SSD 控制器損壞這類問題。如果你按完一輪 Revive 與 Restore 設備還是沒有任何反應，多半代表問題不在 DFU 能處理的範圍內，這時與其繼續在工具上鑽，不如直接送修讓工程師判斷。把 DFU-Tools 與官方流程理解成「軟體層的最後嘗試」，比較不會對它產生超出實際能力的期待。