• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            elva

            awd BIOS rk ,'universal' tst

            創建時間:2007-05-28
            文章屬性:原創
            文章提交:icelord (icelord_at_sohu.com)

            Award BIOS Rootkit,universal test

            [author  ]:icelord
            [date    ]:2007/05/25
            [contact ]:icelord@sohu.com

            [申明]

            %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                本文所涉及到的資料,均來自internet...
                由此造成的后果,與本人無關
                假設您已經了解x86和NT的相關知識。
                內容僅為個人意見。由于時間倉促,很多細節沒有驗證,錯誤很多。
                如果您有不同意見,可聯系icelord@sohu.com,歡迎指正。

            %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


            [.code]

            下面的文字僅為個人想法,目的拋磚引玉
            由于時間和環境問題,暫時沒有機會來驗證,所以沒有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的自我效驗都
                是使用簡單的'效驗和'方式,就是將要效驗的數據塊按uchar來相加,與原始效
                驗和值比較。
                如果你修改了這些數據塊中的某些數據,將會導致效驗和失敗,BIOS啟動時
                就會出現BIOS Checksum Error。
                
                那么怎樣來保證修改后的BIOS效驗和能正常運行?
                一直以來都是修改數據塊后重新計算效驗和并寫入到原始效驗和的位置。
                某天,突然發現這個問題實在太xx,只要修改后的數據塊的效驗和與未修改時
                的效驗和相等即可嘛...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中間空閑位置查找
                
                
                上圖已經說明了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執行...,
                因為first jmp就是ROM指令...)
                ---------------------------------
                還有一個方法就是將brk放置到ESCD(extend system configuration data)或者DMI區域中,
                在第一條指令直接跳轉ESCD或者DMI區域。
                原因:(拿award來說)
                    實際發現ESCD區域中有很大的區域未使用(但是發現Toshiba R100幾乎沒有空閑,jp!),
                而且ESCD區域一般應該不會進行效驗和檢測(award BIOS 沒有),因為當硬件改變時,BIOS會
                更新此區域內容,即開機自檢過程中的 "Updating ESCD..."
                (具體可以看看ESCD specification).而且ESCD區域一般是4KB/8KB或者64KB (unit)????
                (不確定...)
                
                問題:
                    ESCD區域是否可以在RM下訪問到(without enter PM,嘗試一條指令的hook,在BIOS之前)
                    實際發現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啟動的過程中獲取執行的機會,BIOS之前,過程中,之后,只要
                能獲取執行即可。
                
                而啟動brk的方式還是老套的那幾種hook,file...(virtualize?)
                
                就選擇最簡單的hook吧,那么,選擇什么位置/代碼來hook才可以達到universal?
                最簡單的答案就是BIOS入口處.
                x86 CPU在啟動時,CS的不可見部分(Base Addr)為0xFFFF0000,EIP為0xFFF0,第一條
                指令為 BIOS ROM最后16字節內,這個位置是比較universal的hook位置.
                一般來說,這條指令都是一個長跳轉指令(也有非長跳轉的,例如dell的某個BIOS),如果想
                不被明顯的看出來,可以修改跳轉目的地址的指令,一般都在BIOS最后64KB,這個位
                置是直接映射到0xF000段的,長跳轉到此。
                
                現在,brk可以啟動了,而且是在BIOS之前,此時,沒有任何可以使用的BIOS服務.
                
                現在就要發揮你的想象能力了。你需要作一些事情,然后將CPU交給原始BIOS,使其進行
                必要的初始化(硬件,BIOS服務等).此過程中BIOS 需要改變CPU模式,I/O等.
                
                當前狀態是16bit RealMode,沒有多任務,沒有BIOS服務,現在要解決的問題就是如何
                在放棄CPU后如何重新獲取CPU。
                
                hehe,想了好久,如果還是hook BIOS中間代碼,感覺很復雜,需要很多硬編碼數據,
                還是使用老套的方式比較好,寫文件。
                關于IDE的I/O操作很簡單,一般是對I/O端口0x1F0~0x1F7進行讀寫操作,使用Loop I/O就
                更簡單了。
                
                做法就是在MBR中寫入幾個字節的jmp指令即可.這樣在選擇硬盤啟動后可直接獲取cpu.
                //如果您有好的方法,歡迎指點。
                
                但是,這樣的做法將導致程序的健壯性打折扣。修改MBR時如果斷電則是個麻煩...
                怎么辦?
                
            三.程序健壯性
                其實也談不上健壯。
                要處理的問題就是MBR寫入的問題和安裝操作系統的問題
                
                (1).MBR寫入的問題
                IDE好說,直接使用cli;Loop I/O的方式讀寫扇區即可
                SCSI/CDROM/Eth Boot,唉,不知道怎么辦了
                
                (2).安裝操作系統的問題
                假設安裝winxp,確保在拷貝文件時,BIOS hook已經被卸載
                //reason:hook read service...,不知道在安裝開始拷貝文件是否使用BIOS svc
                
                還有MBR不能被保存在BIOS中,以防止安裝操作系統后出現新的MBR的問題
                
                所以還得在MBR中找到一個通用的hook code??
                
                也可在安裝時將MBR備份到MBR和第一個分區之間的空閑區域內(至少62個扇區吧,
                估計。安裝nt后還有很多空閑,不知道安裝Grub會怎樣...反正能找到空閑位置),
                在brk啟動時將MBR與備份MBR比較(同時檢查是否為hook過的 MBR,防止重復hook),
                如不同則備份。若相同,則讀取mbr,修改MBR,然后寫入MBR.
                
                若發現MBR不完整(0xaa55),則使用備份MBR來覆蓋MBR,
                這樣來防止寫入MBR斷電破壞MBR
                
                (注:'備份MBR'在安裝時寫入,在MBR有效,且MBR與'備份MBR'不一致,則更
                新'備份MBR',根據實際情況來定了...)
                
                在從硬盤啟動時,恢復MBR為原始狀態。

                /*總之,就是使用備份技術,來降低斷電破壞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執行被hook的(jmp)指令(in ROM),跳轉到brk rom section1(in ROM)
                
                (3).brk rom section1進入PM(保持一致性),訪問brk rom section2(in ROM),(拷貝到RAM,
                并執行)
                
                (4).brk rom section2(in RAM)使用I/O來讀取MBR和磁盤臨時數據('備份MBR',sub_routine
                sector,hlper_routine sector...等)進行有效性檢查(自定義了)
                
                (5).修改MBR,寫回disk;
                    寫入磁盤臨時數據(如果'備份MBR'無效,如果hlper_routine Sector無效)
                
                (6).恢復狀態,跳轉原始 BIOS
                
                (7).BIOS初始化(上面說的問題在這里,BIOS檢測內存會用到內存讀寫,如果將brk放置
                到內存中的話,可能在這個階段就被破壞了,所以,hehe,需要上面所說的hlper_routine
                sector...)
                
                (8).如果Boot From IDE,則MBR被加載到0x7C00位置執行,此時執行的是我們自己的MBR,
                其任務就是加載存放于MBR和第一個分區之間的hlper_routine sector并執行;
                hlper_routine為ROM Section2保留內存,進入PM,拷貝ROM Section2到保留內存區域,Hook
                BIOS服務,或者調用保留內存區域的ROM Section2來I/O操作系統相關的文件(例如,你
                可以使用自己的buildin driver寫磁盤文件,如果你想這樣做)
                    最后,加載‘備份 MBR’到0x7C00,并執行
                    
                (9).MBR加載PBR(OBR),OBR加載osloader...,此時我們的hooker得到執行機會...,然后進行
                kernel subvertion...
                    //
                    //Win NT相關:
                    //這里在說一下iclord brk的簡單flowchart:
                    //hook int 13h-->hook ntldr!BlSetupForNT!'xxxxx',使用堆棧ebp獲取BlLoaderBlock,
                    //修改內存鏈表屬性,同時hook ndis.sys...-->ndis.sys hooker執行,
                    //初始化ndis,然后初始化自己(展開rootkit .sys文件進行驅動程序(boot driver)初始化),
                    //返回控制到IopInitializeBuiltinDriver()?
                    //over
                    //
                    
                (10).Rootkit's "show time" here...
                
            [Anti & 問題]
                沒細想過。我備份了一下BIOS而已
                
                由于修改BootROM seg,而且借助(RW)了IDE之類的非固件存儲設備,導致所謂的'universal'在
                健壯性和安全性上較差,操作系統重裝沒有解決(可能會出問題)...

                由于要修改BootBlock,有的FlashROM對BootBlock作了特殊的限制...
                
                用光盤啟動,檢查;
                啟動到dos下檢查;
                
                
                /**
                以上想法有很多疑惑地方,猜測而已。
                至于挨罵,那時肯定的,hehe
                    
                期待高手斧正...
                */
                
            =============

                icelord@2007/05/25
                
                
            ----------
            revision @ 07/05/28
                PC啟動時有幾個寄存器保留著一些信息

                如果PC從睡眠模式恢復...

            ----------

            posted on 2007-06-01 01:02 葉子 閱讀(494) 評論(0)  編輯 收藏 引用 所屬分類: rootkit

            久久午夜福利电影| 九九久久自然熟的香蕉图片| 精品国产乱码久久久久软件| 97精品国产97久久久久久免费| www性久久久com| 精品综合久久久久久97| 日韩亚洲欧美久久久www综合网| 国产精品无码久久综合网| 亚洲精品无码成人片久久| 亚洲国产天堂久久久久久| 91精品国产91热久久久久福利 | 亚洲综合日韩久久成人AV| 久久国产一区二区| 久久国产一片免费观看| 热综合一本伊人久久精品| 亚洲国产精品综合久久一线| 久久久WWW成人免费毛片| 青青久久精品国产免费看| 国产精品久久久久久五月尺| 伊人久久综合成人网| AV狠狠色丁香婷婷综合久久| 99久久国产综合精品网成人影院| 国产精品99久久久久久www| 免费一级欧美大片久久网| 亚洲精品美女久久777777| 久久精品国产亚洲AV大全| 91麻精品国产91久久久久| 久久人人爽人人爽人人片av麻烦| 久久亚洲AV成人出白浆无码国产| 亚洲嫩草影院久久精品| 色狠狠久久综合网| 久久99国产精品久久99| 日本精品久久久久久久久免费| 久久久久成人精品无码中文字幕| 一级做a爰片久久毛片16| 中文字幕久久精品无码| 婷婷综合久久狠狠色99h| 亚洲香蕉网久久综合影视| 精品乱码久久久久久夜夜嗨| 久久久久亚洲精品天堂| 久久久久国产精品麻豆AR影院|