我們在第一篇文章中提到，要在Wii上面執行未授權軟體是很困難的
不過這當然無法阻擋駭客(Hacker)想在Wii上面執行自製(HomeBrew)軟體
的決心。當然，他們成功了，這邊先介紹一些相關的知識
1. 緩衝區溢位(Buffer Overflow)
可以說大多數的安全漏洞都是出自緩衝區溢位
起因是，我們最常使用的C語言，並沒有檢查緩衝區(Buffer)的大小
我們常常會在程式中設定一個固定大小的陣列(array)當做緩衝區
例如說用40個字元來儲存使用者姓名
在一般的狀況下，是沒什麼問題的
不過如果原始資料故意輸入超過40個字元
C語言在讀取的時候，依然會依序將它拷貝進陣列
結果，超過40個字元的部份，就會蓋寫記憶體中其它用途的地方
而造成所謂的Stack Overflow，或Heap Overflow
駭客就利用這點，來執行一些原本系統不允許的的動作
2. Twilight Hack
Wii上面，最早也最有名的一個緩衝區溢位攻擊
利用特殊的存檔，造成薩爾達傳說：曙光公主的緩衝區溢位問題
結果就是可以不經由正常的程序，執行自製的程式
由於是利用漏洞的關係，所以可以跳過檢查機制，執行任何你想要的程式
(基本上都是執行SD上根目錄的boot.elf或boot.dol)
SYSMENU ----------> 曙光公主 ---------------> 自製程式
光碟頻道 Twilight Hack
由於是利用有問題的存檔
所以後來的系統選單會檢查有問題的存檔並刪除，進而封住這個漏洞
在4.0系統選單的系統無法使用Twilight hack
3. Indiana Pwns/Smash Stack
在曙光公主被封住之後，還有二個漏洞被發現
一個是LEGO Indiana Jones(無日版)，一個是大亂鬥美版
Indiana Pwn同樣是利用存檔的漏洞，理論上也可以被修復
(目前為止未被修復)
Smash Stack則是遊戲本身去讀取SD造成的問題
所以會非常不容易被修復，甚至有可能永遠存在
不過前述的這種方式，需要這三片遊戲其中一片
而且要進入遊戲玩一下，才能執行自製程式，不是很方便
所以主流是另一種BannerBomb的方式
4. BannerBomb
BannerBomb是利用SD資料管理(3.0~4.1)
或SD Menu(4.2)的緩衝區溢位來執行自製程式
這個方法，只需要一張SD卡，不需要特別的遊戲即可執行，相當方便
(但是系統選單必須是3.0以上，這就是為什麼軟改需要升到3.0以上的原因)
只要進入特定的系統選單位置，如SD Menu
就可以選擇執行自製程式了
(目前沒有4.3上面可用的BannerBomb)
5. Trucha Bug
單單可以執行程式，駭客們當然是不能滿足的
如果可以安裝成頻道，多方便啊！
但是任天堂在你安裝程式的時候，會檢查簽章，該怎麼辦呢？
這時候有人發現了一個bug，也就是有名的Trucha Bug
在比對你的RSA憑證(不懂請看本系列第一篇)是否有效時
任天堂犯了一個很嚴重的錯誤
在驗證憑證的有效性時，我們曉得需要Hash = Hash'(第一篇中有詳述)
但是很不幸地，任天堂使用了「字串比對」，而不是「記憶體比對」
字串比對有什麼問題？C語言中，字元值0代表字串的結束
只要遇到0，不管後面還有沒有，他都會停下來
所以，如果Hash中有0，它的有效長度被縮短了！
駭客也就可以比較輕易地偽造出一個假的憑證和簽章
也就是說，這個演算法，其實並沒有被破解
但是它的檢查機制卻有漏洞！
這個漏存在於當時所有的IOS和boot1之中
可以偽造簽章之後，也就大開了Wii軟改的方便之門
自製頻道(HBC)、自製的IOS、自製的Boot2
不管你想裝什麼東西進Wii，都可以
多彩多姿的Wii軟改世界，也就此展開了
(關於Trucha bug的攻防戰，後面再做說明)
--
不過這當然無法阻擋駭客(Hacker)想在Wii上面執行自製(HomeBrew)軟體
的決心。當然，他們成功了，這邊先介紹一些相關的知識
1. 緩衝區溢位(Buffer Overflow)
可以說大多數的安全漏洞都是出自緩衝區溢位
起因是，我們最常使用的C語言，並沒有檢查緩衝區(Buffer)的大小
我們常常會在程式中設定一個固定大小的陣列(array)當做緩衝區
例如說用40個字元來儲存使用者姓名
在一般的狀況下，是沒什麼問題的
不過如果原始資料故意輸入超過40個字元
C語言在讀取的時候，依然會依序將它拷貝進陣列
結果，超過40個字元的部份，就會蓋寫記憶體中其它用途的地方
而造成所謂的Stack Overflow，或Heap Overflow
駭客就利用這點，來執行一些原本系統不允許的的動作
2. Twilight Hack
Wii上面，最早也最有名的一個緩衝區溢位攻擊
利用特殊的存檔，造成薩爾達傳說：曙光公主的緩衝區溢位問題
結果就是可以不經由正常的程序，執行自製的程式
由於是利用漏洞的關係，所以可以跳過檢查機制，執行任何你想要的程式
(基本上都是執行SD上根目錄的boot.elf或boot.dol)
SYSMENU ----------> 曙光公主 ---------------> 自製程式
光碟頻道 Twilight Hack
由於是利用有問題的存檔
所以後來的系統選單會檢查有問題的存檔並刪除，進而封住這個漏洞
在4.0系統選單的系統無法使用Twilight hack
3. Indiana Pwns/Smash Stack
在曙光公主被封住之後，還有二個漏洞被發現
一個是LEGO Indiana Jones(無日版)，一個是大亂鬥美版
Indiana Pwn同樣是利用存檔的漏洞，理論上也可以被修復
(目前為止未被修復)
Smash Stack則是遊戲本身去讀取SD造成的問題
所以會非常不容易被修復，甚至有可能永遠存在
不過前述的這種方式，需要這三片遊戲其中一片
而且要進入遊戲玩一下，才能執行自製程式，不是很方便
所以主流是另一種BannerBomb的方式
4. BannerBomb
BannerBomb是利用SD資料管理(3.0~4.1)
或SD Menu(4.2)的緩衝區溢位來執行自製程式
這個方法，只需要一張SD卡，不需要特別的遊戲即可執行，相當方便
(但是系統選單必須是3.0以上，這就是為什麼軟改需要升到3.0以上的原因)
只要進入特定的系統選單位置，如SD Menu
就可以選擇執行自製程式了
(目前沒有4.3上面可用的BannerBomb)
5. Trucha Bug
單單可以執行程式，駭客們當然是不能滿足的
如果可以安裝成頻道，多方便啊！
但是任天堂在你安裝程式的時候，會檢查簽章，該怎麼辦呢？
這時候有人發現了一個bug，也就是有名的Trucha Bug
在比對你的RSA憑證(不懂請看本系列第一篇)是否有效時
任天堂犯了一個很嚴重的錯誤
在驗證憑證的有效性時，我們曉得需要Hash = Hash'(第一篇中有詳述)
但是很不幸地，任天堂使用了「字串比對」，而不是「記憶體比對」
字串比對有什麼問題？C語言中，字元值0代表字串的結束
只要遇到0，不管後面還有沒有，他都會停下來
所以，如果Hash中有0，它的有效長度被縮短了！
駭客也就可以比較輕易地偽造出一個假的憑證和簽章
也就是說，這個演算法，其實並沒有被破解
但是它的檢查機制卻有漏洞！
這個漏存在於當時所有的IOS和boot1之中
可以偽造簽章之後，也就大開了Wii軟改的方便之門
自製頻道(HBC)、自製的IOS、自製的Boot2
不管你想裝什麼東西進Wii，都可以
多彩多姿的Wii軟改世界，也就此展開了
(關於Trucha bug的攻防戰，後面再做說明)
--
All Comments