先用一句話抓住這篇
從免費遊戲、自製軟體與平台商的商業動機開始，逐步拆解 PS4、Xbox 360、PS3、3DS 與 Switch 的公開安全案例，再理解 Secure Boot、sandbox、TEE 和 SoC 記憶體隔離各自能解決什麼問題。
先把這篇當成一張閱讀地圖：上方摘要說明問題，圖片先建立直覺，下面文字再補上真正的技術取捨。
如果第一次讀覺得名詞很多，可以先記住比喻與結論；第二次再回頭看名詞，會順很多。
第一次聽到「破解遊戲主機」，很多人想到的是免費玩遊戲；也有人只是想在自己買來的機器上執行自製程式、做實驗，或保存已經停產的遊戲。這些動機並不相同。主機商則有明確的商業理由保護遊戲銷售、授權與平台生態，因此會在媒體、程式簽章、開機流程和系統更新上設計防線。真正值得學習的問題，不是替每一位破解者貼上同一個標籤，而是追問：他能碰到什麼、想取得什麼能力，以及跨過一關後還能不能碰到其他資產。
本課用公開的歷史研究案例，帶讀者從應用程式漏洞、硬體故障、簽章實作錯誤，一路看到晶片裡的 Boot ROM。每一案都會說清楚它影響了哪一道邊界，也會標出未被證明的部分。內容是安全工程課，不是改機或漏洞操作指南；PS4「看照片程式堆疊溢位」的說法目前沒有可靠來源可以確認，所以不會把它當成真實案例。我們改用有研究來源的 PS4 WebKit 漏洞，並把「程式當機、取得程式控制、提升權限、接觸安全區金鑰」分開說明。
1. 為什麼有人想破解遊戲主機？
破解的吸引力，往往來自原本被平台限制的能力。有些人希望不用購買授權就能玩遊戲，這會傷害遊戲開發者、發行商與平台商的收入。另一些人想在自己的硬體上執行自行撰寫的 homebrew，研究作業系統、保存舊軟體，或讓主機做出原廠沒有提供的功能。這些目標可以使用相似的技術，但其合法性、授權狀態與造成的傷害並不因此相同。
站在平台商的角度，主機不是一台孤立的盒子。它連著遊戲授權、商店、更新服務、多人連線、玩家帳號與開發者生態。如果未授權副本大量流通，可能影響遊戲銷售和授權收益；如果不受信任的程式能任意進入系統，也可能影響作弊控制、線上服務、帳號資料或整台裝置的完整性。這是平台投入防拷、簽章驗證和安全開機設計的商業與安全背景，不代表每一道防線都同時解決所有問題。
所以「破解」不是一個足夠精確的技術描述。它沒有告訴我們入口是瀏覽器、媒體解析器、簽章服務，還是晶片的啟動 ROM；也沒有說明跨過入口後是只能執行 homebrew，還是能修改核心、讀取資料或持續控制裝置。讀案例時，我們要把動機、技術能力和實際後果分開查證。
2. 先問威脅模型：主機裡什麼值得保護？
威脅模型不是一張駭客人物設定卡，而是把防守問題具體化的方式。第一步是列出資產：遊戲授權決定哪些內容可執行；存檔包含玩家進度與個人資料；帳號憑證能連到商店和線上服務；裝置金鑰則可能用在加密、裝置識別或安全服務。保護哪項資產，會決定我們採取什麼控制措施，也決定失守時究竟代表什麼。
第二步是描述攻擊者碰得到什麼。遠端網路攻擊需要一條可達的網路服務；瀏覽器或媒體解析器可能接收網頁、圖片、遊戲內容或外接媒體；實體接觸則可能包含拿到主機、連接埠或可更動的硬體。這些能力不能互相替代。證明某項漏洞必須先接觸主機，不等於證明一般網際網路上的攻擊者能遠端利用它。
第三步才是追問可能影響：輸入能不能造成當機？能否影響一個受限的應用程式？是否還有額外弱點讓權限提升？能不能觸及帳號資料、線上服務或安全區金鑰？模型要把前提和後果逐級列清楚。否則一句「被攻破」會把可能性說成已發生的結果，也讓工程師無法判斷還剩下哪些防線。
3. 一張圖片怎麼變成記憶體問題？
讀圖片時，應用程式會把檔案中的位元組交給影像解析器。解析器必須理解檔案標頭、尺寸、色彩資訊和資料區塊，再把處理結果放進記憶體。即使輸入看起來只是照片，程式仍得面對各種長度、格式和邊界。若檢查順序、長度計算或錯誤處理不周，解析器可能在不合預期的記憶體位置讀寫資料。
可以把記憶體想成一排有標籤的格子。程式向系統要到一段空間，應該只在自己的格子裡工作；如果長度計算錯誤，寫入可能超出原先預留的範圍，影響旁邊的資料。這類記憶體安全錯誤可能造成程式當機或資料毀損，也可能在特定條件下影響程式控制流程。比喻只能幫助理解範圍被弄錯，實際記憶體配置與錯誤利用條件更複雜。
最重要的是，不要把不同結果合併成一句「有漏洞就被控制」。程式當機只代表程式無法正常繼續；控制程式代表攻擊者能影響某段程式怎麼執行；提升權限還要跨過作業系統的其他檢查。要再讀寫核心或安全執行環境，通常還需要更高權限、另一個弱點，或錯誤的硬體隔離設定。每一步都需要證據和額外前提。
4. PS4 瀏覽器漏洞會直接控制整台主機嗎？
Synacktiv 研究團隊公開分析過特定舊版 PS4 韌體中的 WebKit use-after-free 漏洞。Use-after-free 是程式釋放一塊記憶體後，卻又透過舊參照使用它的錯誤。這樣的錯誤可能讓攻擊者影響瀏覽器程序的行為，但研究者指出，瀏覽器所在的程序有 sandbox，應用程式層的入口並不自動等於整個作業系統都落入控制。[1]
Sandbox 可以想成一個權限有限的工作區：即使裡面的程序出錯，它平常能讀寫的檔案、使用的服務或碰到的系統功能仍受限制。若要從瀏覽器程序再跨到核心，攻擊鏈還必須找到能跨越下一道邊界的條件。Synacktiv 描述的部分舊韌體完整鏈，還結合了另一個核心漏洞；因此教學上必須把瀏覽器入口與後續提權分開畫。[1]
這個公開案例不能證明 PS4 的 TEE、安全世界或晶片金鑰也已失守。每個邊界都是獨立主張，不能從「瀏覽器可被利用」推論出「整顆 SoC 任意可讀」。另外，使用者記得的 PS4 看照片程式堆疊溢位，目前沒有可信來源足以確認。PS5 的影像函式庫另有不同時間、不同主張的公開記錄，不能拿來替 PS4 的記憶補出一個看似相同的事件。[2]
5. 硬體故障會改變驗證結果嗎？
軟體漏洞不是唯一能影響信任判斷的路徑。Xbox 360 的 Reset Glitch Hack（RGH）是公開的歷史研究案例，展示啟動時的硬體行為也可能影響系統驗證流程。研究者 GliGli 將它描述為利用瞬間硬體故障改變特定啟動判斷的方式；我們只需要理解這個安全概念，不需要複製訊號或改裝步驟。[3]
把驗證想成裁判在關鍵時刻判讀一份資料。平常的流程依序讀取、檢查，再決定是否允許下一段程式執行；若硬體在那個短暫時刻出現偏離，驗證器可能看到錯誤狀態。風險不只在演算法，也在供電、時脈、重置和錯誤回應等實體條件是否被納入安全設計。這是「故障注入」的大方向，並不意味所有故障都能產生相同效果。
案例也有範圍限制：不同 Xbox 360 主機板、晶片修訂和後續防護不一定相同。不能因此說所有型號都受到影響，更不能把需要實體條件的研究敘述成遠端攻擊。設計端可以檢查失敗時的安全狀態、重複驗證、故障偵測與復原行為；研究歷史則聚焦在信任判斷為何不能只看程式碼裡的 if/else。
6. 簽章數學正確，實作仍會出錯嗎？
PS3 的簽章事件常被簡化成「橢圓曲線密碼被破解」。比較精確的教訓是：ECDSA 需要簽章實作正確處理每次簽章所用的暫時性數值；若這個數值被不當重複使用，原本依賴它保密的簽章安全性就會被破壞。27C3 的主題演講和同期技術報導都把重點放在實作錯誤，而不是宣稱橢圓曲線數學突然失效。[4][5]
可把數位簽章想成驗票印章：驗證者相信符合政策的簽章，才讓特定程式繼續執行。印章規則再好，如果簽章者在製作印章時反覆洩露了不該公開的線索，外界仍可能仿造。也就是說，信任不只依靠數學演算法；程式如何實作、暫時值如何產生、金鑰如何保管與輪替，都屬於同一個系統。
所以防禦要分層檢查：選擇合適的演算法、使用經過審查的實作、避免重用敏感暫時值、保護簽章私鑰，並建立金鑰撤銷與更新策略。本課不展開金鑰恢復推導或重現細節；對安全工程的學習來說，知道錯誤發生在哪一層、為何它能摧毀信任邊界，就足以把防護方向說清楚。
7. 如果晶片最早的 ROM 自己看錯資料呢？
Boot ROM 是晶片上電後很早就會執行的一段程式，常被用來建立第一個信任起點，再載入和驗證後續軟體。它的優點是出廠後不容易被一般程式改寫；但「寫在晶片裡」只說明它較難替換，不代表它不會有程式錯誤。早期驗證器若無法正確理解輸入或簽章格式，後續所有信任都可能從錯誤的判斷開始。
一篇作者發表在 arXiv 的 3DS Boot ROM 技術論文，描述 Boot9 在處理 ASN.1 編碼長度時的解析問題，並分析它對簽章驗證的影響。可以把 ASN.1 想成一種帶有長度與型別資訊的資料包裝方式：讀取者必須正確判斷每段資料在哪裡開始、在哪裡結束。若長度檢查不正確，驗證器可能把後續資料邊界理解錯。該論文的會議或正式出版脈絡在目前來源紀錄中尚未確認，因此我們明確標示它是作者技術論文／preprint，而不抬高它的出版身分。[6]
ROM 的修正困難在於，普通系統更新通常不能把出廠時燒錄的那段程式直接改掉。產品設計因此要在早期解析器上採取保守而精簡的做法，嚴格驗證長度與格式，並仔細測試失敗路徑。還要檢查資料被複製到哪裡、誰能改寫相關記憶體，以及下一階段是否會再次驗證。信任根的重要性很高，正因為它一旦有錯，能依靠的後續補救空間可能比較小。
8. Switch 與 Tegra：BootROM 漏洞有什麼限制？
Switch 相關的 Tegra 案例可以用來對照不可一般更新的早期 ROM 風險，但先要讀清楚 NVIDIA 公告的範圍。NVIDIA 說明該 RCM 漏洞需要攻擊者有實體 USB 接觸，並不是只要主機連上網路就能遠端利用；公告也指出 Tegra X2 和更新產品不受影響。[7]
這個限制不是小字附註，而是威脅模型的一部分。攻擊者若必須先取得實體裝置，防守方評估的風險就和遠端攻擊不同；若晶片修訂版不在受影響範圍，相關結論也不能套到它上面。Switch 家族有不同生產時期和硬體版本，不能只看主機外觀或產品名稱，就假定每一部都使用相同晶片或都受到相同影響。
這個例子也說明，Boot ROM 瑕疵與一般系統更新的關係要分開想。更新可以修正可更新的韌體與軟體，也可以加入對特定早期缺陷的補償措施；然而它不能讓已燒錄的 ROM 原始程式碼憑空變成另一個版本。安全設計要盡量讓早期程式精簡，並為硬體修訂差異、復原流程和後續信任接續做好規劃。本課只談公開公告的安全含義，不提供操作復現步驟。
9. 這些案例到底跨過哪一道邊界？
現在把幾個案例放在一起看：PS4 WebKit 是特定韌體下的應用程式入口；Xbox 360 RGH 說明硬體故障可能影響特定啟動驗證；PS3 ECDSA 案是簽章實作與金鑰管理失誤；3DS 與 Tegra 案例則提醒我們，早期 Boot ROM 本身也可能因解析或硬體條件出錯。它們的技術原因並不一樣，適用前提也不能互相搬用。
判讀任何「主機被破解」的報導時，可以逐欄確認：攻擊者從哪裡進入？需要網路、特定媒體、實體接觸或特定韌體嗎？哪個元件的判斷被影響？研究證明了執行能力、核心權限，還是只觀察到當機？哪些資產有證據顯示已遭觸及？問完這些問題，報導標題裡籠統的一個動詞就會變成可以檢驗的技術敘述。
還要記得，技術能力與使用目的不同。能執行 homebrew 的能力可能被用在保存或實驗，也可能被濫用於未授權遊戲或線上作弊；某種漏洞也可能被攻擊者用來散布惡意程式。除非有個案證據，不能從一項技術發現直接推斷每個研究者或玩家的動機。威脅模型幫我們分析風險，不是替人猜心。
10. Secure Boot 能保護什麼？
Secure Boot 的目標是控制裝置從上電到作業系統啟動時，哪些程式可以沿著信任鏈繼續執行。晶片裡的 Root of Trust 開始檢查第一段可驗證程式；通過後，這段程式再檢查下一階段，逐步延伸到 bootloader、作業系統和其他元件。驗證可能依簽章、雜湊和產品政策決定是否接受，細節依平台架構而異。
它的價值在於，攻擊者即使改動儲存裝置上的韌體，也較難讓未經授權或已被竄改的映像不被發現。然而這種保障有明確邊界：驗證器本身也必須可信，信任金鑰要受到保護，版本政策要能處理撤銷和更新；開機成功後，已授權程式仍可能有解析器漏洞或其他執行期缺陷。簽章表示映像符合某個授權政策及完整性檢查，不代表程式毫無 bug。
因此 Secure Boot 不能代替遊戲授權、線上帳號驗證、應用程式 sandbox、記憶體保護或復原策略。它回答的是「下一段程式是否符合開機政策？」而不是「程式是否沒有漏洞？」。設計良好的產品還要想好：偵測到不可信映像時如何安全拒絕、如何安裝修正、如何撤銷有問題的金鑰，以及更新失敗後如何復原。
11. 一般程式碰到記憶體，怎麼不讓它碰到金鑰？
從遊戲主機案例轉到通用 SoC 設計：假設一般世界的圖片程式讀到惡意輸入，我們希望它即使出錯，也碰不到儲存裝置金鑰或安全服務的私密資料。TrustZone／TEE 是一種常見的架構教學例子，能用 Normal World 與 Secure World 說明不同信任狀態；但目前沒有來源能證明本課提到的每一台主機都採用 Arm TrustZone，所以這裡只談一般 SoC 原理，不推論主機實作。[8]
隔離不只是把資料放到另一個「安全世界」名稱下。若兩個世界共用外部 DRAM，硬體 memory firewall 需要依安全設定控制誰能讀寫哪些範圍；而 DMA 控制器、顯示與儲存週邊也可能是 bus master，可以不經 CPU 直接提出存取要求。因此設計必須把相關 master、記憶體區域、設定暫存器和初始化流程一起管起來。只限制一般 CPU，卻忘記能 DMA 的週邊，隔離就可能留下另一條路。
完全獨立的外部安全記憶體看起來直觀，但產品要付出額外元件、腳位、板面與系統整合成本。Arm 的架構文件討論過一種常見取捨：把一份外部 DRAM 用硬體分區，通常比放兩份較小的外部記憶體便宜；若關鍵功能所需容量不大，也能考慮把最敏感的工作集放在片上 SRAM。這不是說分區 DRAM 一定更安全或永遠最佳，而是要依容量、存取路徑和成本決定。TEE 本身仍是軟硬體系統，也需要檢查服務介面和錯誤處理。[8][9]
12. 如果你來設計 SoC，程式、資料與金鑰該放哪？
最後回到開場那張可能有問題的圖片。如果解析器不需要接觸金鑰，就不要讓它直接拿到金鑰；先把它留在權限有限的 sandbox，限制檔案、服務和系統呼叫。若某項功能確實需要使用祕密資料，可以由 Secure World 的狹窄服務代為運算，只接受格式明確、長度有限且經過驗證的請求，而不是把金鑰複製到一般記憶體。
Memory firewall 要限制一般 CPU 與 DMA master 的存取範圍。安全服務仍須檢查長度、狀態與呼叫權限。Secure Boot 則在開機時驗證下一段程式。啟動鏈管理程式來源，sandbox 限制執行期權限，memory firewall 檢查硬體存取；更新與復原處理已發現的缺陷。
檢查位址時，要涵蓋整筆交易。例如安全區從 2048 開始，一筆從 2040 讀取 16 bytes 的請求會跨區。只檢查起始位址會漏掉後半段。互動模型以 4 KiB 記憶體與整筆跨區拒絕政策示範這件事；真實匯流排的 burst、region 優先序與 fault 回報，仍需依硬體規格驗證。
設計完成後，還要用威脅模型逐條測試交界處：如果攻擊者控制了一般世界的圖片程式，能不能透過 DMA 讀取安全區？如果安全服務收到超大或格式錯誤的請求，會安全拒絕嗎？如果 Root of Trust 的金鑰需要撤銷，產品有沒有可行的復原途徑？防線不是貼上幾個安全名詞就會自動成立；我們要驗證每一道邊界由誰執行、如何失敗，以及失敗後會不會把信任交給不該信任的程式。
重點回顧
- 破解動機可能是未授權遊戲，也可能是 homebrew、研究或保存；能力與動機必須分開判讀。
- Threat model 要列出資產、攻擊者接觸範圍、能力、入口與失守影響。
- 當機、程式控制、核心權限與 TEE／金鑰存取是不同結果，每一步都需要額外條件與證據。
- PS4 WebKit、Xbox 360 RGH、PS3 ECDSA 與 3DS／Tegra BootROM 是不同類型的歷史案例；不能用一個「加密被破解」概括。
- Secure Boot 管理開機程式信任鏈；它不會讓已授權程式自動沒有漏洞。
- SoC 的安全記憶體隔離需要涵蓋 CPU、DMA、週邊和安全服務介面，並在安全性、容量與成本間取捨。
名詞整理
Threat model（威脅模型）：列出資產、攻擊者能力、可達入口與可能影響，藉此選擇控制措施。
Sandbox（沙盒）：限制程式能使用的檔案、服務和系統資源，降低單一程式出錯時的影響範圍。
Boot ROM：晶片啟動初期執行、通常不可由一般系統更新改寫的程式。
Secure Boot：依信任根與產品政策逐階段驗證開機程式的機制。
TEE（Trusted Execution Environment）：由硬體與軟體共同建立、用來處理敏感資料或服務的隔離執行環境。
DMA（Direct Memory Access）：週邊不必讓 CPU 搬運每一筆資料，也能向記憶體提出讀寫要求的機制。
Memory firewall：由硬體檢查不同 master 對記憶體範圍的存取權限。
Fault injection（故障注入）：刻意影響硬體行為，以研究錯誤或異常條件如何改變系統判斷。
五題理解檢查
- 玩家在主機上執行 homebrew，是否足以證明他正在散布盜版？請說明為什麼。
- 某 PS4 瀏覽器漏洞影響受 sandbox 限制的程序，這能直接證明核心或 TEE 金鑰已失守嗎？還需要哪些額外條件？
- PS3 ECDSA 案例的主要教訓，是橢圓曲線數學失效，還是簽章實作與暫時值管理出錯？這兩種說法會導向什麼不同防禦？
- 若系統用 Secure Boot 驗證了已簽章的圖片解析器，是否就能保證它不會因惡意圖片出現記憶體漏洞？說明開機信任與執行期安全的差別。
- 一個 SoC 將敏感資料放在 shared DRAM 的隔離區，卻讓 DMA master 不受 memory firewall 管理，威脅模型還漏了哪條存取路徑？
參考資料
- Synacktiv, This is for the Pwners: Exploiting a WebKit 0-day in PlayStation 4 — 特定舊版 PS4 WebKit 漏洞、sandbox 與額外核心漏洞的分層說明。
- PS4 Developer Wiki, Bugs；libpng advisory GHSA-7wv6-48j4-hj3g — 僅用來說明照片／圖片解析可能是輸入面，以及為何 PS5 的相關記錄不能當成 PS4 stack overflow 的證據。
- GliGli, Reset Glitch Hack technical report — Xbox 360 硬體故障注入的原始研究背景；本文不使用其操作細節。
- 27C3, Console Hacking 2010 — PS3 簽章實作案例的原始研究演講。
- Ars Technica, PS3 hacked through poor implementation of cryptography — 同期報導，說明重用 ECDSA 暫時值的實作失誤。
- Scire et al., Attacking the Nintendo 3DS Boot ROMs — 作者技術論文／arXiv preprint；正式出版或會議來源尚未在本課確認。
- NVIDIA, Tegra RCM Security Notice；Fusée Gelée disclosure — 實體 USB 條件、產品世代與漏洞範圍。
- Arm, Building a Secure System using TrustZone Technology — TrustZone/TZASC、共用 DRAM 存取控制與片上 SRAM 取捨。
- Arm and GlobalPlatform, Trusted Execution Environment and TrustZone — TEE、信任世界與 DMA 等隔離邊界的架構背景。
標籤： #ConsoleSecurity #ThreatModel #SecureBoot #BootROM #TEE #MemoryFirewall #HardwareSecurity #ComicClassroom
互動實驗：已簽章的程式能讀哪段記憶體？
先驗開機程式的真實 ECDSA 簽章，再計算一筆 CPU 或 DMA 請求的完整位址範圍。把一般 DMA 排除在防火牆外，看看同一段安全區如何從拒絕變成允許。
這是 4 KiB 固定位址表的政策模型，不是特定主機、Arm TZASC 或 RTL 匯流排模擬。跨區交易整筆拒絕。Master 身分、DMA 覆蓋、解析器漏洞與政策是給定條件；不模擬 cache、IOMMU、側通道或 exploit。簽章不會證明程式沒有執行期漏洞。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 電玩主機防盜拷機制與基本威脅模型
我學會了什麼
- 區分破解動機、能力、利用前提與影響
- 說明應用程式漏洞為何不會自動取得核心或 TEE 權限
- 區分 Secure Boot 與執行期記憶體隔離