Atmosphère 架構拆解：Switch 自製韌體如何一層層換掉任天堂的系統

Atmosphère 自製韌體分層架構示意

很多人以為 Atmosphère 就是「Switch 破解」本身，下載下來丟進 SD 卡就能用。這個理解錯得滿徹底的：Atmosphère 裡面一行漏洞利用程式碼都沒有。它是一套乾淨的、GPLv2 授權的作業系統元件重寫計畫，本身拿不到主機的控制權，得靠別的東西把它「送進去」。

我把 Atmosphère 的 GitHub 原始碼和官方文件從頭讀了一遍。讀完最大的感想是：這不像一個 hack，比較像一場對 ARM TrustZone 架構的公開解剖課。這篇從硬韌體工程師的角度，把它怎麼運作、要搭配哪些軟硬體、為什麼大家都在講 Hekate，還有「一定要買 RCM loader 嗎」這個常見問題，一次講清楚。

本文版本基準（2026-10-16）

Atmosphère 1.12.1（第 94 個正式版，2026-10-16 發布），支援 Horizon OS 23.0.0
Hekate v6.5.4／Nyx v1.9.4
前置知識：知道 bootloader、ARM Exception Level（EL0～EL3）、IPC 大概是什麼就夠了
本文只談架構與合法的 homebrew 用途，不涉及任何盜版相關操作

先搞懂一件事：破解入口和 CFW 是兩回事

要讓一台消費電子產品跑你自己的程式，一定要先解決「第一行非官方程式碼怎麼開始執行」。Switch 的 secure boot 從晶片 ROM 一路驗簽到作業系統，信任鏈每一環都會檢查下一環。只要第一環沒破，後面寫得再漂亮也沒用。

Switch 社群把這件事拆成兩層：

層	負責什麼	代表
入口（exploit / 硬體）	拿到第一行程式碼的執行權	Fusée Gelée（RCM 漏洞）、Picofly modchip
Bootloader	開機選單、選要開什麼系統	Hekate、fusee.bin
CFW 本體	取代官方系統元件、加入功能	Atmosphère
應用層	homebrew 程式、背景服務	hbmenu、sys-clk、Tesla-Menu

Atmosphère 只負責第三層。所以「我的機器能不能跑 Atmosphère」問的其實是第一層：你的機器有沒有入口。

Atmosphère 的分層架構：照 ARM 特權等級一層層換

ARM 特權等級與 Atmosphère 元件

Atmosphère 的元件命名很浪漫，都用大氣層的分層：fusée（火箭）、exosphère（外氣層）、mesosphère（中氣層）、stratosphère（平流層）、troposphère（對流層）。命名之外，背後的工程邏輯其實很硬：它是照 ARMv8 的 Exception Level，由高權限往低權限，一層一層把任天堂的元件換成自己的。

Atmosphère 元件與 ARM 特權等級架構圖

逐層來看：

fusée 是 Atmosphère 第一個在硬體上跑起來的程式，官方文件講得很直白：它是一個要透過 RCM、利用 CVE-2018-6242 啟動的獨立 payload。它負責所有低階硬體初始化、建立密碼系統（key derivation）、掛載或模擬 eMMC、修補系統模組，最後把控制權交給 exosphère。以前它分成 fusee-primary 和 fusee-secondary 兩段，現在已經合併成單一的 fusee.bin。每一版 release notes 都會用粗體提醒「fusee-primary 已經不能用了」，可見還是很多人踩到。

exosphère 是我覺得整個專案最精彩的部分。Switch 的 Secure Monitor 跑在 EL3，也就是 ARM TrustZone 的最高權限，負責所有敏感的密碼運算與 CPU 電源管理。Atmosphère 直接把它整個重寫，還加了一些自訂 SMC（Secure Monitor Call），例如 smc_ams_iram_copy（在 DRAM 和 IRAM 之間搬一頁資料）、smc_ams_get_emummc_config。官方的 ConfigItem 查詢也被擴充了，從 ID 65000 開始多出 EXOSPHERE_VERSION、HAS_RCM_BUG_PATCH（判斷這台機器是不是已修補版）、SHOULD_BLANK_PRODINFO（把主機序號與憑證清空）等。細節都寫在 exosphère 官方文件裡。

mesosphère 重寫的是 EL1 的 Horizon 微核心。1.12.0 為了跟上 23.0.0，把 42-bit 位址空間、新的 ShadowStack 記憶體區、改用 CTR-DRBG 的核心亂數產生器都實作了一遍。一套作業系統核心被第三方 clean-room 重寫到可以無縫替換官方版本，這工程量想到就頭皮發麻。

thermosphère 打算利用官方完全沒用到的 EL2 做 hypervisor，目前還在開發中。

stratosphère：微核心架構給的超大槓桿

真正讓 Atmosphère「好用」的是 stratosphère。理由在 Horizon 的設計：它是微核心，檔案系統、程序管理、服務註冊這些都不在核心裡，而是由一堆使用者層的 sysmodule 透過 IPC 互相提供服務。

這種架構對安全性是好事，但也代表只要控制幾個關鍵的 sysmodule，就能控制整個系統。stratosphère 重寫了 loader、pm、sm、spl、ncm、ro、fatal、creport 等官方模組，然後在兩個地方加料。

加料一：loader 的 exefs 替換

loader 的官方文件說明，建立程序時，Atmosphère 版的 loader 會先看 SD 卡上有沒有替代檔：

/atmosphere/contents/<program id>/exefs.nsp        ← 整個 exefs 分割區替換
/atmosphere/contents/<program id>/exefs/main       ← 單一 NSO 替換
/atmosphere/contents/<program id>/exefs/main.npdm  ← 權限描述
/atmosphere/contents/<program id>/flags/boot2.flag ← 開機時由 boot2 自動啟動

所有第三方 sysmodule 都是靠這個機制掛進系統的。以超頻工具 sys-clk 為例，它的核心模組就放在 /atmosphere/contents/00FF0000636C6BFF/exefs.nsp，再加一個 boot2.flag，開機就會自動載入。概念上很像 Linux 的 systemd unit，只是被塞在 loader 這一層。

加料二：ams_mitm 中間人攔截

這是 CFW 功能的主力。ams_mitm 會在 IPC 通道上插一層，攔截某些程式對某些服務的呼叫：

mitm 模組	攔截對象	做到什麼
`fs_mitm`	檔案系統	LayeredFS：遊戲讀素材時，偷偷換成 SD 卡上的版本（模組、翻譯、自訂主題）
`set_mitm`	系統設定	版本號顯示成 `23.0.0\|AMS 1.12.1\|E`，E 代表 emuMMC、S 代表 sysMMC
`bpc_mitm`	電源控制	按「重新開機」時改成重開進 payload
`dns_mitm`	DNS 解析	用 hosts 檔把任天堂伺服器導到黑洞
`ns_mitm`	應用控制	讓 homebrew 能呼叫網頁 applet

LayeredFS 的原理講穿了很簡單：攔截 fs 服務的「開檔」請求，看看 SD 卡上有沒有同路徑的檔案，有就回傳 SD 卡那份，沒有就照常轉給原本的服務。熟悉 OverlayFS 的人應該會覺得眼熟。不過 LayeredFS 只做「同路徑換檔」，沒有 OverlayFS 那套目錄合併、whiteout 刪除的完整語意，類比只到概念層。

踩坑：防護會悄悄失效

1.12.1 的 release notes 寫了一件有點可怕的事：23.0.0 讓大部分 sysmodule 改用新的 c-ares 非同步 DNS 指令，而 dns_mitm 只攔舊指令，導致 host 重導向「完全沒套用，而且沒有任何警告」。在 1.12.0 + 23.0.0 的期間，依賴 DNS 封鎖來隔離任天堂伺服器的人，其實是在裸奔。1.12.1 已經重新實作 c-ares 序列化並攔截新指令，這個問題修好了，但教訓還在：中間人攔截的天生弱點，就是上游只要多開一條新路，你沒攔到，就等於沒擋。

入口一：Fusée Gelée，一個救不回來的 bootROM bug

Fusée Gelée RCM 緩衝區溢位示意

回到第一層：怎麼拿到第一行程式碼的執行權？

Tegra X1 有一個叫 RCM（Recovery Mode）的 USB 救援模式，原本是給工廠刷機和維修救磚用的，只接受有簽章的映像。2018 年，Kate Temkin／ReSwitched 揭露了 Fusée Gelée ，fail0verflow 也同時獨立發現，並以 ShofEL2 為名發表。漏洞編號是 CVE-2018-6242 。

bug 的本質是一個長度由攻擊者控制的 memcpy：

透過 RCM 協定送大量資料，bootROM 會把它們放進 payload 緩衝區（從 0x40005000 或 0x40009000 開始）
傳輸完成之前，插一個 USB 控制請求 GET_STATUS，把長度欄位填得很大
bootROM 處理這個請求時，照著你給的長度做 memcpy，範圍一路蓋到正在執行的 stack
return address 被蓋掉，BPMP（開機與電源管理用的 ARM7 處理器）就跳去執行你的程式碼

這個 bug 慘在三點同時成立：發生在任何 lock-out 生效之前；bootROM 沒有 stack canary 之類的緩解措施；而且它在 mask ROM 裡，出貨後就沒辦法用軟體修。整條信任鏈的根直接失守，bootROM 本身和所有金鑰都能 dump 出來。後來 NVIDIA 用 ipatch 把 USB 控制請求的長度限制在 255 bytes，2018 年中以後出廠的 Switch 就是所謂的「已修補」機。

對做嵌入式的人來說，這個案例幾乎可以直接放進教科書：救援用的 USB 通道、簽章驗證之前的解析程式碼、沒有任何緩解措施的 ROM，三個風險因子湊在一起。如果你手上的產品有 DFU 或 USB 救援模式，回頭檢查一下長度欄位的邊界，絕對不吃虧。

入口二：modchip 與電壓故障注入

Switch modchip 焊接示意

Mariko 版（2019 年後的新版續航款）、Switch Lite 和 OLED 都換了晶片，RCM 漏洞被修掉了。這些機型沒有軟體入口，只能動硬體。

做法是電壓故障注入（voltage glitching）：在 CPU 執行簽章驗證的那一瞬間，精準地讓核心電壓掉一下，讓驗證「判斷錯誤」，然後由 modchip 韌體裡的 sdloader 從 SD 卡讀 payload.bin，取代原本的 BOOT0。NH Switch Guide 的 modchip 介紹寫得很清楚，社群只支援完全開源的 Picofly（基於 RP2040）。來源可疑的商用晶片，很多是盜版集團做的，指南明確表示不協助。

這條路的門檻很實際：要在主機板上焊非常細的漆包線，OLED 還要焊 DAT0 adapter。常見的失敗是晶片不再觸發 glitch、3.3V 掉電、走線被刮斷。手不穩的人建議找有經驗的維修師傅，不然很可能直接把主機板報廢。

Hekate：開機選單兼瑞士刀

入口拿到之後，通常不會直接把 Atmosphère 的 fusee.bin 推進去，而是先推 Hekate 。

Hekate 是 CTCaer 維護的通用 bootloader（2018 年最早由 naehrwert 和 st4rk 寫成），圖形介面叫 Nyx，支援觸控。它跟 fusee 的差別在於：fusee 只會開 Atmosphère，Hekate 則是一個能選擇要開什麼的開機選單，順便兼任救援工具。

功能	說明
多系統開機	Atmosphère（sysMMC／emuMMC）、官方韌體、Android（switchroot）、L4T Linux、其他 payload
建立 emuMMC	把內部 eMMC 複製一份到 SD 卡（獨立分割區或檔案）
備份與還原	BOOT0／BOOT1／整顆 eMMC 的 RAW 備份
USB 大量儲存	把 SD 卡或 eMMC 分割區掛成隨身碟，不用拔卡
自動更新 payload	第一次開機時，自動更新 dongle 或 modchip 裡的 reboot payload

開機選項寫在 bootloader/hekate_ipl.ini。下面是 Hekate 官方範本精簡後的寫法：

[config]
autoboot=0
bootwait=3

; 純官方韌體：不打核心補丁、不載入 CFW kip
[Stock]
pkg3=atmosphere/package3
stock=1
emummc_force_disable=1

; Atmosphère，強制跑在 SD 卡上的 emuMMC
[Atmosphere emuMMC]
pkg3=atmosphere/package3
emummcforce=1

pkg3= 會讓 Hekate 自己拆開 Atmosphère 的 package3 打包檔，取出 exosphère、warmboot、mesosphère 和核心 KIP，再自行啟動，等於跳過 fusee。舊教學常見的 fss0= 在 Hekate README 裡已經標成 Deprecated，照舊文章抄的人要注意。

emuMMC：把 CFW 關進沙盒

emuMMC 沙盒示意

Hekate 開機選單通常有四種組合，SCCM 的整理很清楚，我改寫成表格：

選項	韌體	儲存位置	任天堂伺服器	用途
sysMMC OFW	官方	內部 eMMC	連線	線上遊戲、eShop
sysMMC CFW	Atmosphère	內部 eMMC	封鎖	備份自己的存檔
emuMMC CFW	Atmosphère	SD 卡	封鎖	所有 homebrew 實驗都在這裡
Semi-Stock	官方（略過 fuse 檢查）	內部	連線	救援用

emuMMC 的防護有兩層：exosphère 的 SHOULD_BLANK_PRODINFO 把序號和憑證清空，dns_mitm 再把任天堂網域導進黑洞。前面講過的 1.12.0 DNS 失效事件（1.12.1 已修），剛好證明第二層會跟著上游更新悄悄壞掉。所以第一層的序號清空才是真正的保險，順序不要搞反。

那，一定要買 RCM loader 嗎？

這大概是新手最常問的問題。答案是不一定，而且大多數情況根本不需要。

RCM loader 是那種插在 USB-C 孔上的小 dongle，它只是「推 payload」的其中一種工具。實際要準備什麼，看你的機型：

機型	走不走 RCM	要準備什麼
未修補的初代 V1（約 2018 年中以前出廠）	走	進 RCM 的方法 + 推 payload 的工具
已修補 V1／Mariko／Lite／OLED	完全不走	Picofly modchip，開機直接進 Hekate

已修補的機器就算買了 RCM loader 也沒用。NH Switch Guide 也講得很斬釘截鐵：推完 payload 螢幕維持全黑、工具又顯示 patched，那就是已修補，不是偶發的故障，也沒得討論。

未修補的 V1 要做兩件事，每件都有替代做法。

進入 RCM：最常見的是 RCM jig：插進右側 Joy-Con 滑軌短接特定腳位，再按住音量 + 開機，詳細步驟請看 NH Switch Guide 的 RCM 章節。另一種是 AutoRCM：NH Switch Guide 的 AutoRCM 頁說明，它會在 BOOT0 和 BOOT1 各寫壞一個 byte，讓主機以為自己變磚，每次開機都自動進 RCM。之後不用 jig，但主機再也不能自己開機，每次都要推 payload，等於 tethered jailbreak。拿迴紋針或錫箔去短接？拜託不要，接錯腳位就是在賭主機板的命。

推 payload：TegraRcmGUI 的 README 列出各平台的工具：

工具	平台
TegraRcmGUI	Windows
Fusée Launcher	Linux（Python，可自動化）
NXBoot	macOS、iOS
NXLoader	Android 手機（USB-C 線直連）
Web Fusée Launcher	跨平台，只限 Chrome（WebUSB）
RCM loader dongle	獨立硬體，插上就推

所以只要有電腦或 Android 手機，再加一條 USB-C 線，dongle 就是可有可無的便利品。它的好處只在出門不想帶電腦。

還有一點很多人沒注意到：進一次之後，不一定每次都要重推。CFW 只活在這次開機期間，所以用睡眠代替關機，喚醒時還在 Atmosphère 裡。按「重新開機」也不怕，bpc_mitm 會攔截，直接重開回 SD 卡上的 Hekate。只有完全關機或沒電之後，才要重新進 RCM、重推一次。

搭配軟體總整理

把前面講的全部串起來，從硬體到應用層的完整清單：

層級	軟體／硬體	必要性
入口（未修補 V1）	RCM jig + TegraRcmGUI／Web Fusée Launcher／NXLoader／dongle	擇一必備
入口（其他機型）	Picofly modchip	必備
Bootloader	Hekate v6.5.4	強烈建議
CFW	Atmosphère 1.12.1 zip + `fusee.bin`	必備
Homebrew 啟動器	nx-hbloader 2.4.5 + nx-hbmenu 3.6.1	Atmosphère 已內附
開發工具鏈	devkitPro（devkitA64）+ libnx	自己寫程式才需要
Overlay	Tesla-Menu + nx-ovlloader	選用
常見 sysmodule	sys-clk、MissionControl、emuiibo	選用
常見工具	JKSV／Checkpoint（存檔備份）、ftpd	選用

SD 卡上大致長這樣：

/
├── bootloader/          ← Hekate 設定、ini、payloads
├── atmosphere/
│   ├── package3         ← exosphère + mesosphère + stratosphère
│   ├── contents/        ← 第三方 sysmodule 與 LayeredFS
│   └── hosts/           ← dns_mitm 規則
├── switch/              ← .nro homebrew、.overlays/
└── emuMMC/              ← 檔案型 emuMMC

常見問題與踩坑

Q：推完 payload 螢幕全黑？
先確認 payload 檔沒有損壞，再看注入工具是不是顯示 patched。如果是，那台就是已修補機，只能走 modchip。另外，TegraRcmGUI 內建的 Hekate 版本太舊，請自己下載最新版再推。

Q：升級 Atmosphère 後開不了機？
十之八九是只換了 atmosphere/ 資料夾，沒換 fusee.bin，或是 Hekate 太舊、不支援新的 HOS。三樣東西要一起升級。

Q：官方韌體可以先更新嗎？
不要。每次大版本更新，Atmosphère 都要追：22.0.0 改了 applet 生命週期管理，整個 homebrew 生態壞掉，靠 am 模組補丁救回來；23.0.0 讓 Atmosphère 能從 applet pool 借到的記憶體少於 7MB，eShop 這類瀏覽器 applet 會崩潰。1.12.0 先補丁瀏覽器 applet，拿回約 9MB，把自訂 sysmodule 的可用記憶體實驗性拉到 16MB；後來發現瀏覽器還是會記憶體不足，1.12.1 改成騙它「還有 1GB 可用」並縮小瀏覽器引擎的 heap，才把自訂 sysmodule 的可用記憶體恢復到 40MB。從官方發布到 CFW 跟上，通常要等幾天到兩週。社群的慣例很簡單：CFW 沒出來之前，別碰系統更新。

Q：Switch 2 能跑嗎？
目前不能。Switch 2 用的 T239 沒有 RCM 這類 bootROM 漏洞，GBAtemp 的技術討論也指出，dual-core lockstep（兩顆核心同步執行再比對結果）讓電壓故障注入困難很多。這是社群判斷，不是定論，但短期內別抱太大期待。

合法性：開源與商業化是兩條路

最後一定要講清楚。Atmosphère 開源、不收費、不散布任天堂的程式碼或金鑰，發展 8 年也沒被下架。反例是商業 CFW SX OS 背後的 Team Xecuter：成員 Gary Bowser 在 2021 年認罪，罪名是串謀規避技術保護措施與販運規避裝置，Ars Technica 報導他在認罪協商中同意支付 450 萬美元。之後的判決與民事賠償，依 Wikipedia 的整理，他另被判賠任天堂 1,000 萬美元、刑期 40 個月。The Guardian 的後續報導則提到，他服刑 14 個月出獄後，背著約 1,400 萬美元的債，每個月都還在還錢。

主流社群刻意和盜版劃清界線，原因就在這裡：技術研究與自製軟體，和商業化的盜版裝置，在法律上是完全不同的兩件事。

下一步

如果你也是做硬韌體的，我推薦按這個順序讀：先看 Fusée Gelée 揭露報告，理解攻擊面；再讀 Atmosphère 原始碼的 exosphere/ 和 stratosphere/ams_mitm；最後試著用 devkitPro 寫一個最小的 sysmodule，放在 emuMMC 上跑。每一步都會讓你回頭重新審視自己產品的 bootloader 設計。

BASHCAT

網頁