創(chuàng)建時間：2007-05-28
文章屬性：原創(chuàng)
文章提交：
icelord (icelord_at_sohu.com)
Award BIOS Rootkit，universal test
[author ]:icelord
[date ]:2007/05/25
[contact ]:icelord@sohu.com
[申明]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
本文所涉及到的資料，均來自internet...
由此造成的后果，與本人無關
假設您已經(jīng)了解x86和NT的相關知識。
內容僅為個人意見。由于時間倉促，很多細節(jié)沒有驗證，錯誤很多。
如果您有不同意見，可聯(lián)系icelord@sohu.com,歡迎指正。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
[.code]
下面的文字僅為個人想法，目的拋磚引玉
由于時間和環(huán)境問題，暫時沒有機會來驗證，所以沒有demo，可以
在iclord基礎上作簡單修改進行驗證測試
歡迎有興趣的朋友測試驗證
也可能下面的想法估計是完全錯誤的，如果您認為不可行，歡迎指正
'通用'所要面臨的問題：
（1） BIOS效驗和的問題
（2） Rootkit啟動的時機
（3） 程序健壯性問題
（4） BIOS刷新的問題
下面的方法是個很啰嗦的方法，如果您有更好的方法，歡迎指點
brk: boot rk,bios rk...
[設計目標]
要求brk能夠在多種類型的BIOS內植入并啟動
問題：
1.不同類型的bios的'效驗和'位置不同，導致添加自己的brk后，不能正
常啟動.
2.需要在bios啟動過程中啟動自己的brk，不同類型的bios是個難題
3.怎樣重新取得cpu?
4.anti brk chk?這暫時談不到.
[簡單結構]
+--------------------+---[low ROM,Mem 4GB-ROMSize]
| bios mod |
+--------------------+
| |
+--------------------+
| free space |
+--------------------+
| brk rom section2 +-->ESCD better,brk real body
+--------------------+
| free space |
+--------------------+
| |
+--------------------+---[Last Section,Mem 4GB-64KB]
| |
+--------------------+
| brk rom section1 +-->Brk init & restore orig_jmp
+--------------------+
| boot rom |
+--------------------+
| hook far jmp here +-->jmp brk rom section1
+--------------------+---[high ROM,Mem 4GB]
一．BIOS效驗的問題
不知道其它類型BIOS的自我效驗如何，像Award BIOS的自我效驗都
是使用簡單的'效驗和'方式，就是將要效驗的數(shù)據(jù)塊按uchar來相加,與原始效
驗和值比較。
如果你修改了這些數(shù)據(jù)塊中的某些數(shù)據(jù)，將會導致效驗和失敗，BIOS啟動時
就會出現(xiàn)BIOS Checksum Error。
那么怎樣來保證修改后的BIOS效驗和能正常運行？
一直以來都是修改數(shù)據(jù)塊后重新計算效驗和并寫入到原始效驗和的位置。
某天，突然發(fā)現(xiàn)這個問題實在太xx，只要修改后的數(shù)據(jù)塊的效驗和與未修改時
的效驗和相等即可嘛...ft,大腦僵化的結果。
但問題又來了,如果BIOS所采用的效驗方式不是效驗和呢？的確(‘universal’
這一說法要打折扣)，如果要采用別的加密的方法就更麻煩...
先拿award bios來作例子...(假設其它BIOS的驗證都使用效驗和方式...?????)
//contact icelord@sohu.com 如果有不同意見
具體做法就是在BIOS ROM中查找足夠大（與brk的body大小相同）的空閑位置(
全0xFF或0x0)，計算這些空間的效驗和,修正brk的效驗和，與之相等，替換即可。
這包括brk ROM Section1和brk ROM Section2兩部分
其中brk ROM Section1在BIOS ROM最后64KB內查找
其中brk ROM Section2在BIOS ROM中間空閑位置查找
上圖已經(jīng)說明了brk的構造
(1).hook_far_jmp
在安裝時確定并修正此值
(2).brk ROM Section1
此部分作用為進入保護模式，初始化brk的實體brk ROM Section2(安裝時構造)
(3).brk ROM Section2
此部分為BIOS Rk的實體,可以放到brk ROM Section1中，按payload大小而定
(安裝時構造)
解釋一下：
我不知道開機時有多少ROM映射到1MB以內，但是可以確定的是BIOS ROM最后64KB
會映射到0xF000段。
0xF000內一般沒有足夠大的空間，所以將brk ROM Section2放置在BIOS ROM的靠前的
空閑位置非，這樣就導致在0xF000段內無法訪問到brk ROM Section2 (in ROM)（in real mode）.
所以brk ROM Section1的作用是拷貝brk ROM Section2到1MB以下(其實是白拷，BIOS在初
始化過程中會overwrite1MB一下的內存為0，至少Award是這樣做的？？？，所以任務放
到了mbr上)，所以enter PM,訪問brk ROM Section2.(按理BIOS ROM可直接EIP執(zhí)行...,
因為first jmp就是ROM指令...)
---------------------------------
還有一個方法就是將brk放置到ESCD(extend system configuration data)或者DMI區(qū)域中，
在第一條指令直接跳轉ESCD或者DMI區(qū)域。
原因：（拿award來說）
實際發(fā)現(xiàn)ESCD區(qū)域中有很大的區(qū)域未使用（但是發(fā)現(xiàn)Toshiba R100幾乎沒有空閑,jp!），
而且ESCD區(qū)域一般應該不會進行效驗和檢測(award BIOS 沒有),因為當硬件改變時,BIOS會
更新此區(qū)域內容,即開機自檢過程中的 "Updating ESCD..."
(具體可以看看ESCD specification).而且ESCD區(qū)域一般是4KB/8KB或者64KB (unit)????
(不確定...)
問題：
ESCD區(qū)域是否可以在RM下訪問到(without enter PM,嘗試一條指令的hook,在BIOS之前)
實際發(fā)現(xiàn)ESCD在256KB ROM中位于最后64KB,在512KB ROM中位于BIOS ROM起始位置,
這跟BIOS ROM(類型)的sector大小有關,還跟BIOS的layout有關(例如Award 的16K-8K-8K Unit),
即使這樣做，仍然需要一個wrapper來使得在RM下可以訪問到ESCD(胡亂猜測)
/*這里有問題!!!!!*/
二．BIOS Rootkit啟動的時機
BIOS rk需要在pc啟動的過程中獲取執(zhí)行的機會，BIOS之前，過程中，之后，只要
能獲取執(zhí)行即可。
而啟動brk的方式還是老套的那幾種hook,file...(virtualize?)
就選擇最簡單的hook吧，那么，選擇什么位置/代碼來hook才可以達到universal?
最簡單的答案就是BIOS入口處.
x86 CPU在啟動時,CS的不可見部分(Base Addr)為0xFFFF0000,EIP為0xFFF0,第一條
指令為 BIOS ROM最后16字節(jié)內,這個位置是比較universal的hook位置.
一般來說,這條指令都是一個長跳轉指令(也有非長跳轉的，例如dell的某個BIOS),如果想
不被明顯的看出來，可以修改跳轉目的地址的指令，一般都在BIOS最后64KB，這個位
置是直接映射到0xF000段的，長跳轉到此。
現(xiàn)在，brk可以啟動了，而且是在BIOS之前，此時，沒有任何可以使用的BIOS服務.
現(xiàn)在就要發(fā)揮你的想象能力了。你需要作一些事情，然后將CPU交給原始BIOS，使其進行
必要的初始化（硬件，BIOS服務等）.此過程中BIOS 需要改變CPU模式,I/O等.
當前狀態(tài)是16bit RealMode,沒有多任務，沒有BIOS服務，現(xiàn)在要解決的問題就是如何
在放棄CPU后如何重新獲取CPU。
hehe,想了好久，如果還是hook BIOS中間代碼，感覺很復雜，需要很多硬編碼數(shù)據(jù)，
還是使用老套的方式比較好，寫文件。
關于IDE的I/O操作很簡單,一般是對I/O端口0x1F0~0x1F7進行讀寫操作，使用Loop I/O就
更簡單了。
做法就是在MBR中寫入幾個字節(jié)的jmp指令即可.這樣在選擇硬盤啟動后可直接獲取cpu.
//如果您有好的方法，歡迎指點。
但是，這樣的做法將導致程序的健壯性打折扣。修改MBR時如果斷電則是個麻煩...
怎么辦?
三．程序健壯性
其實也談不上健壯。
要處理的問題就是MBR寫入的問題和安裝操作系統(tǒng)的問題
(1).MBR寫入的問題
IDE好說,直接使用cli;Loop I/O的方式讀寫扇區(qū)即可
SCSI/CDROM/Eth Boot,唉,不知道怎么辦了
(2).安裝操作系統(tǒng)的問題
假設安裝winxp,確保在拷貝文件時,BIOS hook已經(jīng)被卸載
//reason:hook read service...,不知道在安裝開始拷貝文件是否使用BIOS svc
還有MBR不能被保存在BIOS中，以防止安裝操作系統(tǒng)后出現(xiàn)新的MBR的問題
所以還得在MBR中找到一個通用的hook code？？
也可在安裝時將MBR備份到MBR和第一個分區(qū)之間的空閑區(qū)域內（至少62個扇區(qū)吧，
估計。安裝nt后還有很多空閑,不知道安裝Grub會怎樣...反正能找到空閑位置）,
在brk啟動時將MBR與備份MBR比較（同時檢查是否為hook過的 MBR,防止重復hook），
如不同則備份。若相同，則讀取mbr，修改MBR,然后寫入MBR.
若發(fā)現(xiàn)MBR不完整(0xaa55),則使用備份MBR來覆蓋MBR，
這樣來防止寫入MBR斷電破壞MBR
(注:'備份MBR'在安裝時寫入，在MBR有效，且MBR與'備份MBR'不一致，則更
新'備份MBR'，根據(jù)實際情況來定了...)
在從硬盤啟動時,恢復MBR為原始狀態(tài)。
/*總之，就是使用備份技術，來降低斷電破壞MBR的幾率*/
待解決...
四．BIOS刷新的問題
這是個老問題了。可使用的方法有
uniflash (open src)
award smi flash
(ami smi flash).
感興趣的可以看看
五. 安裝程序的任務
(1).在OS下Dump BIOS
(2).在BIOS最后64KB查找空閑空間,構造計算并防止jmp_hook和brk rom section1(盡量小)
(3).在BIOS ROM中查找足夠大的空閑空間，構造計算并放置brk rom section2
(4).(釋放驅動)刷新BIOS (最麻煩的問題!!!待高手解決)
六. IcLord2.test流程
(1).PC上電，CS.SegBase=0xFFFF0000 EIP=0xFFF0
(2).在0xFFFF FFF0執(zhí)行被hook的(jmp)指令(in ROM),跳轉到brk rom section1(in ROM)
(3).brk rom section1進入PM(保持一致性),訪問brk rom section2(in ROM)，(拷貝到RAM,
并執(zhí)行)
(4).brk rom section2(in RAM)使用I/O來讀取MBR和磁盤臨時數(shù)據(jù)('備份MBR',sub_routine
sector，hlper_routine sector...等)進行有效性檢查(自定義了)
(5).修改MBR，寫回disk;
寫入磁盤臨時數(shù)據(jù)（如果'備份MBR'無效,如果hlper_routine Sector無效）
(6).恢復狀態(tài)，跳轉原始 BIOS
(7).BIOS初始化（上面說的問題在這里,BIOS檢測內存會用到內存讀寫，如果將brk放置
到內存中的話，可能在這個階段就被破壞了,所以,hehe,需要上面所說的hlper_routine
sector...）
(8).如果Boot From IDE，則MBR被加載到0x7C00位置執(zhí)行，此時執(zhí)行的是我們自己的MBR,
其任務就是加載存放于MBR和第一個分區(qū)之間的hlper_routine sector并執(zhí)行；
hlper_routine為ROM Section2保留內存,進入PM,拷貝ROM Section2到保留內存區(qū)域，Hook
BIOS服務，或者調用保留內存區(qū)域的ROM Section2來I/O操作系統(tǒng)相關的文件（例如，你
可以使用自己的buildin driver寫磁盤文件，如果你想這樣做）
最后，加載‘備份 MBR’到0x7C00,并執(zhí)行
(9).MBR加載PBR(OBR),OBR加載osloader...,此時我們的hooker得到執(zhí)行機會...,然后進行
kernel subvertion...
//
//Win NT相關:
//這里在說一下iclord brk的簡單flowchart:
//hook int 13h-->hook ntldr!BlSetupForNT!'xxxxx',使用堆棧ebp獲取BlLoaderBlock,
//修改內存鏈表屬性，同時hook ndis.sys...-->ndis.sys hooker執(zhí)行，
//初始化ndis,然后初始化自己(展開rootkit .sys文件進行驅動程序(boot driver)初始化),
//返回控制到IopInitializeBuiltinDriver()?
//over
//
(10).Rootkit's "show time" here...
[Anti & 問題]
沒細想過。我備份了一下BIOS而已
由于修改BootROM seg,而且借助(RW)了IDE之類的非固件存儲設備，導致所謂的'universal'在
健壯性和安全性上較差，操作系統(tǒng)重裝沒有解決（可能會出問題）...
由于要修改BootBlock,有的FlashROM對BootBlock作了特殊的限制...
用光盤啟動，檢查；
啟動到dos下檢查；
/**
以上想法有很多疑惑地方，猜測而已。
至于挨罵，那時肯定的，hehe
期待高手斧正...
*/
=============
icelord@2007/05/25
----------
revision @ 07/05/28
PC啟動時有幾個寄存器保留著一些信息
如果PC從睡眠模式恢復...
----------