(轉)IE劫持原理 BHO

爲何「瀏覽器劫持」可以如此猖狂呢？放眼衆多論壇的求助貼，咱們不時能夠看到諸如「個人IE被主頁被改了，我用殺毒工具掃了一遍都沒發現病毒，我把主頁改回本身的地址，但是一重啓它又回來了！」、「個人系統一開機就跳出一個廣告，我明明用了最新版的殺毒軟件的啊！」等這類關於IE異常問題的求助，80%的提問者都表示納悶，他們已經安裝了殺毒軟件，但是IE仍然被「黑」了，這又是爲何？
其實這些都是典型的「瀏覽器劫持」現象，可是受害者不是已經安裝了殺毒軟件嗎？爲何瀏覽器依然躲不過這隻黑手？許多用戶對這個領域都存在一種誤區心理：瀏覽器劫持？我有最新的殺毒軟件，我不怕！
因而，當他們遭遇「瀏覽器劫持」時，驚訝了。
要知道，殺毒軟件自身也只是一種輔助工具，它不可能徹底保護系統的安全，更況且，殺毒軟件用戶必須知道一個事實：「瀏覽器劫持」的攻擊手段是能夠經過被系統承認的「合法途徑」來進行的！殺毒軟件只能經過「特徵碼」的形式來判斷程序是否合法，但這是創建在人爲定義之後的，而實施「瀏覽器劫持」的程序能夠有不少，防不勝防。
爲何說「瀏覽器劫持」能夠說是合法的呢？由於大部分瀏覽器劫持的發起者，都是經過一種被稱爲「BHO」（Browser Helper Object，瀏覽器輔助對象）的技術手段植入系統的。
BHO是微軟早在1999年推出的做爲瀏覽器對第三方程序員開放交互接口的業界標準，它是一種可讓程序員使用簡單代碼進入瀏覽器領域的「交互接口」（INTERACTIVED Interface）。經過BHO接口，第三方程序員能夠本身編寫代碼獲取瀏覽器的一些行爲（Action）和事件通知（Event），如「後退」、「前進」、「當前頁面」等，甚至能夠獲取瀏覽器的各個組件信息，像菜單、工具欄、座標等。因爲BHO的交互特性，程序員還可使用代碼去控制瀏覽器的行爲，好比常見的修改替換瀏覽器工具欄、在瀏覽器界面上添加本身的程序按鈕等操做，而這些操做都被視爲「合法」的，這就是一切罪惡根源的開始。
BHO的出現幫助程序員更好的打造個性化瀏覽器或者爲本身的程序實現了方便簡潔的交互功能，能夠說，若是沒有BHO接口的誕生，咱們今天就不能用一些工具實現個性化IE的功能了。從某一方面來看，BHO的確是各類繽紛網絡互動功能的幕後功臣，可是一切事物都是有兩面性的，這個恆古不變的真理一樣對BHO有效，因而就有了今天讓安全界頭痛的「瀏覽器劫持」的攻擊手段誕生。
看看前面我提到的BHO接口特性，你想到了什麼？BHO能夠獲知和實現瀏覽器的大部分事件和功能，也就是說，它能夠利用少許的代碼控制瀏覽器行爲。程序員能夠設計出一個BHO按鈕以實現用戶點擊時通知瀏覽器跳轉到某個頁面完成交互功能，固然就能夠進一步寫出控制瀏覽器跳轉到他想讓用戶去的頁面，這就是最初的「瀏覽器劫持」的成因：BHO劫持。
在描述BHO劫持以前，咱們先要對BHO接口的啓動作個簡單介紹：符合BHO接口標準的程序代碼被寫爲DLL動態連接庫形式在註冊表裏註冊爲COM對象，還要在BHO接口的註冊表入口處進行組件註冊，之後每次IE啓動時都會經過這裏描述的註冊信息調用加載這個DLL文件，而這個DLL文件就所以成爲IE的一個模塊（BHO組件），與IE共享一個運行週期，直到IE被關閉。
IE啓動時，會加載任何BHO組件，這些組件直接進入IE領域，而IE則成爲它們的父進程和載體，今後IE的每個事件都會經過IUnknown接口傳遞到BHO用以提供交互的IObjectWithSite接口裏，這是BHO實現與IE交互的入口函數。
BHO接收到IE接口傳遞來的參數後開始判斷IE正在作什麼，理論上BHO能夠獲取IE的大部分事件，而後根據程序員編寫的代碼，BHO持有對特定事件作出反應的決定權，例如一個能夠實現「中文網址」的BHO，就是經過GetSite方法獲取到IE當前打開的站點URL（或經過IURLSearchHook接口來獲知），若是BHO發現獲取到的URL和內置的判斷條件匹配，該BHO就會啓用SetSite方法強制IE跳轉到程序員設定的頁面去，這個過程就是利用about:blank篡改主頁的「瀏覽器劫持」方法之一，它的實現原理其實很簡單，程序員編寫一個惡意BHO組件，當它獲取到IE窗口的當前站點爲「about:blank」時就強制IE內部跳轉到指定的廣告頁面，因而鬧出了不久以前沸沸揚揚的「IE空白頁劫持事件」。
瞭解了這種相似惡做劇的做案手段，要解決它就容易了，只要找到並刪除這個隱藏在系統裏的BHO程序便可。
除了這類「廣告軟件」性質的BHO，還有一種利用IURLSearchHook接口實現的另外一類更隱蔽的BHO，這種BHO從某些方面來講大概不算BHO，由於它並非響應IUnknown，而是等待IE建立IURLSearchHook來啓動。IURLSearchHook被瀏覽器用來轉換一個未知的URL協議地址，當瀏覽器企圖去打開一個未知協議的URL地址時，瀏覽器首先嚐試從這個地址獲得當前的協議，若是不成功，瀏覽器將尋找系統裏全部註冊爲「URL Search Hook」（資源搜索鉤子，USH）的對象並把這個IE不能理解的地址發送過去，若是某個USH對象「認識」這個地址，它就返回一個特定的標識告訴IE它知道怎麼打開這個地址，而後IE就根據約定的方法調用它，最終打開這個地址。其實USH對象並不陌生，咱們一些偷懶的用戶就常常爲了省事而不輸入「http://」，可是IE最終仍是能認出並打開某個地址，就是USH的功勞，可是這一點又被惡意程序員拿來磨刀了，經過建立本身的USH對象，惡意程序員可以命令IE在找不到一些網站時自動跳轉到事先設置的站點裏，若是這個站點帶毒或者掛馬，用戶就完了。
這類BHO的解決方法和前面同樣，只是它比較隱蔽，除非用戶常常偷懶，不然可能直到系統崩潰也不會知道本身已經感染了這種東西。也許你會說，只要用戶的輸入永遠不會讓IE沒法識別，這種滲透不就白費了？可是事實不容樂觀，咱們沒法得知BHO做者還會不會經過其餘方法攔截IE，說不定每隔一段時間就讓IE彈出一個廣告呢？
上面說了這麼多BHO和IE合做搞破壞的事例，可能會給讀者形成一種「BHO必須在IE傳遞數據後才能行動」的誤解，然而事實並不是如此，瀏覽器自身也是一個標準的可執行程序，而BHO只是借用這個程序進程啓動的DLL，它並不是API那種要用的時候就讓你過來忙活，忙活完了就一腳踹開的奴隸形態DLL，前面說過了，BHO是一種在瀏覽器加載時一同啓動的例程，它至關於一種自身運行邏輯不太明確的子進程（裏面都是對IE事件的響應和操做代碼），這個特性就形成了BHO DLL和API DLL本質的區別，BHO並不須要全部事件都必須依賴這個你們夥，它能夠有本身決定的權利，只要適當的修改，就能用BHO實現相似DLL木馬的功能，固然，這並非說咱們就能在IE眼皮下公然的肆無忌彈幹壞事的，因爲BHO自身是做爲IE子進程啓動的，它就必須受到一些限制，例如程序員不能在裏面本身建立網絡鏈接，這樣會致使IE報錯崩潰並供出你寫的DLL，懼怕BHO成爲另外一種後門的用戶能夠鬆口氣了，要在BHO裏實現Winsock大概只能在IE休息的時候才能夠，可是會有哪一個用戶開着個開空IE什麼事情都不作呢？
但這並非說BHO就必定能無害了，雖然用它不能作到遠程控制，可是別忘記，BHO能看到IE的全部東西，也就能任意的訪問用戶文件和註冊表，在這個條件成立的前提下，入侵者能夠編寫代碼查找用戶隱私，而後在適當時候經過SetSite提交出去——誰叫如今Webmail這麼流行呢？這就是爲何許多廠商發佈諸如「中文網址」、「網絡搜索」、「IE定製」、「IE監視」這些功能的BHO的同時都保證「不蒐集用戶隱私」的緣由，只要你想要，BHO就能獲得一切。
有些人也許會想，既然BHO是微軟瀏覽器的權利，那我不用IE了，我用Opera、Firefox不行？對於這點當然無可厚非，可是你用不用Windows？用不用共享軟件？若是你用Windows，那麼，你仍然可能處於被BHO接觸到的世界，由於Windows自己就是和IE緊密結合的，這就把「IE進程」的範圍給擴大了，細心的用戶大概會發現，IE裏能直接訪問「個人電腦」，「個人電腦」窗口也能迅速變成IE，由於它們實質都是依賴於IE內核的，正由於這個緣由，BHO能夠在你打開一個文件夾時跟着偷偷啓動。同時，如今的網絡正處於一種「共享軟件捆綁戰略」大肆實施的時代，你再當心也不能避免某些共享軟件固定捆綁了BHO的行爲，安裝後你纔會發現文件夾上又多了個什麼「助手」、「搜索」了。要想完全逃開BHO的圍困，大概只能放棄使用Windows了。
Hook，你鉤住瀏覽器了
正如《侏》裏的這句話同樣，入侵者也在不斷尋找他們的新出路，雖然上面我說了這麼多BHO的負面事例，可是真正的危機並非只有BHO的，在一些使用BHO行不通的場合裏，入侵者開始投擲他們的鉤子。
什麼是鉤子？讓咱們先看看它的官方定義：
鉤子（Hook），是Windows消息處理機制的一個平臺,應用程序能夠在上面設置子程以監視指定窗口的某種消息，並且所監視的窗口能夠是其餘進程所建立的。當消息到達後，在目標窗口處理函數以前處理它。鉤子機制容許應用程序截獲處理window消息或特定事件。

鉤子其實是一個處理消息的程序段，經過系統調用，把它掛入系統。每當特定的消息發出，在沒有到達目的窗口前，鉤子程序就先捕獲該消息，亦即鉤子函數先獲得控制權。這時鉤子函數便可以加工處理（改變）該消息，也能夠不做處理而繼續傳遞該消息，還能夠強制結束消息的傳遞。
可能上面的官方定義對一部分讀者理解有點困難，其實，鉤子就像是一切程序的「先知」，一個實現了鉤子的程序自身雖然也是普通程序，可是它總能在別的程序獲得數據以前就已經知道了一切，這是爲何呢？對Windows系統有必定了解的讀者應該知道，Windows系統是一個經過「信息處理機制」運做的系統，在這個系統裏傳遞的數據都是經過「消息」（Message）的形式發送的，各個消息都遵循了官方的約定，不然就不能讓系統產生迴應。並且這個傳遞步驟是顛倒的，例如咱們關閉了某個程序，咱們可能會認爲是程序本身關閉後通知系統的，其實否則，當用戶點擊關閉按鈕的時候，Windows就會把一個叫作WM_CLOSE的消息傳遞給這個程序，程序接收到消息後就執行卸載自身例程的操做。理解了這點，就能知道鉤子的原理了，所謂鉤子程序，就是利用了系統提供的Hook API，讓本身比每個程序都提早接收到系統消息，而後作出處理，若是一個鉤子攔截了系統給某個程序的WM_CLOSE消息，那麼這個程序就會由於接收不到關閉消息而沒法關閉自身。除了消息之外，鉤子還能夠攔截API，像咱們都熟悉的屏幕翻譯軟件就是Hook了一些文本輸出函數如TextOutA而達到了目的。
技術讓編程人員能夠輕鬆獲取其餘程序的一些有用數據或傳遞相關數據，像如今常見的一些遊戲外掛，它們就是利用Hook技術鉤住了遊戲窗體，而後就能夠識別遊戲裏面的行爲和模擬發送按鍵鼠標消息，最終實現電腦本身玩遊戲的功能。把這個技術應用到瀏覽器上面，就成了另外一種控制瀏覽器行爲的方法。
鉤子有兩種，本地鉤子（Local Hook）和全局鉤子（Global Hook），本地鉤子只在本進程裏起做用，故不屬於討論範圍；全局鉤子代碼必須以DLL形式編寫，以便在鉤子生效時被其它進程所加載調用，所以咱們看到的大部分Hook程序都是DLL形式的。
其實以前提到的BHO也能夠視爲一種針對IE的鉤子，它鉤的是IE的事件，這就是IE與BHO交互的起點，可是對於再複雜一點的操做，例如判斷IE下載的是GIF圖片仍是JPEG圖片，BHO無能爲力，由於它僅僅知道IE的事件爲DownloadBegin和DownloadComplete，對於具體內容，IE自己是不會告訴它的，不然IE豈不是要忙死了？至少我也沒見過哪一個領導還須要向祕書彙報中午吃了雞肉仍是鴨肉的吧，BHO可不是IE的老婆，或者說IE沒有氣管炎。
因此，爲了獲得IE的更多數據，程序員開始鉤IE了。與BHO不一樣，鉤子不須要被動的等待IE事件，它直接和IE造成上司對下屬的關係，此次輪到IE要作什麼都得通過它批准了。Hook形式的控制不須要DLL文件必須與IE的註冊表入口產生組件關係，它能夠是一個獨立的DLL，經過Rundll32.exe或自帶的Loader EXE啓動，並且因爲它屬於Hook形式，在鉤子有效的狀況下會被系統自動插入其餘程序的進程中，是否是有點像DLL木馬呢？
IE鉤子程序載入進程後便能獲知全部的消息類型、API和內容，一旦發現某個符合要求的消息，如IE執行了某個事件，或者用戶輸入了特定內容，鉤子的處理代碼就開始工做了，它先攔截系統發送給IE的消息，而後分析消息內容，根據不一樣消息內容做出修改後再發給IE，就完成了一次Hook篡改過程。用著名的3721實名搜索作例子，一些人會覺得它是採用了BHO或者IURLSearchHook完成中文域名的識別跳轉的，其實它是用了可以第一個獲得Windows消息的Hook技術，這樣一來就能夠避免被其餘的競爭對手搶先解析域名了：3721的主程序就是一個Hook DLL，它監視IE地址欄的消息，一旦用戶輸入的是中文，它便在其餘BHO類插件工做以前攔截了這個消息，並調用自身代碼完成中文域名到英文URL的轉換工做，而後返回（也可能與本身的BHO DLL配合）一個讓IE跳轉到英文URL的消息，完成域名的翻譯任務。
IE鉤子能幫助程序員用少許代碼完成更多的IE交互工做，可是一旦這個鉤子被用於犯罪，其後果也是嚴重的，惡意程序員能夠寫一個攔截IE輸入的鍵盤鉤子，達到竊取密碼的做用，這樣不管你是用HTTP明文協議仍是SecurityHTTP加密協議都不能逃避密碼被盜的下場了，由於它抓的是你在IE裏的輸入，後面的數據傳輸已經不重要了。
Winsock LSP
全稱爲「Windows Socket Layered Service Provider」（分層服務提供商），這是Winsock 2.0纔有的功能，它須要Winsock支持服務提供商接口（Service Provider Interface，SPI）才能實現，SPI是一種不能獨立工做的技術，它依賴於系統商已經存在的基本協議提供商，如TCP/IP協議等，在這些協議上派分出的子協議即爲「分層協議」，如SSL等，它們必須經過必定的接口函數調用，LSP就是這些協議的接口。
經過LSP，咱們能夠比分析基本協議更簡單的獲得咱們想要的數據內容，如直接獲得系統上運行的瀏覽器當前正在進行傳輸的地址和內容，無論這個瀏覽器是IE，仍是Opera或Firefox，由於LSP是直接從Winsock獲取信息的，即便不用微軟生產的汽車，至少你這輛汽車一直是在微軟建造的公路上跑的吧。
LSP用在正途上能夠方便程序員們編寫監視系統網絡通信狀況的Sniffer，但是如今常見的LSP都被用於瀏覽器劫持，使用戶又多了個噩夢。
亡羊補牢，仍是居安思危？
也許大部分家庭用戶都是在經歷過一次入侵或中毒事件後才知道安全防範的重要性的，能亡羊補牢固然是好事，可是若是能對本身的要求提升一點，作到未雨綢繆豈不是更好？咱們老是依賴於別人的技術，依賴於模式化的殺毒手段，但那些始終都是別人的東西，控制權不能掌握在本身手上，這並非很好的事情，也許，該是暫時放棄遊戲掛級、蒐集明星電影，好好研讀一下安全方面和系統原理書籍的時候了，不然在這個不安全的網絡中，咱們隨時可能會迷失本身。
可能有人會想，又在發感慨了。也許是的，由於清除「瀏覽器劫持」通常都須要手工進行，雖然如今已經有了多個檢測瀏覽器劫持的工具如HijackThis、Browser Hijack Recover等軟件面世，可是若是你抱着和以往使用殺毒工具那樣「一開掃描就安枕無憂」想法的話，你會發現本身真的會迷失了，因爲BHO的特殊性（別忘記，它是合法的），這些工具只會把系統的進程、BHO項目、啓動項、LSP等須要有必定技術基礎方能理解的東西顯示給你，而後由你本身決定IE的明天，若是你未曾重視過安全技術，那麼就會以爲這些工具如同另外一種折磨你的病毒了。
學，仍是不學？這是個必須考慮的問題……

網頁插件 BHO啓動,查找.刪除

查找BHO
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects
能夠找到全部的BHO
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\
中能夠找到BHO對應的註冊項
其中的InprocServer32的默認值爲BHO所對應的dll文件.

刪除BHO

關閉IE瀏覽器.
運行regsvr32 /u XXX.dll
刪除對應的dll文件

BHO原理：

BHO就是Browser Helper Object(瀏覽器輔助對象)

BHO關聯原理 (BHO關聯的是SHDOCVW,也就是說不僅關聯IE,下面所有用IE來講明)

1.IE的窗口打開時,先尋找HKLM下的SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\ 裏的CLSID,這些CLSID,都對應着相應的BHO插件，而後根據這個CLSID到HKCR下的CLSIDs裏找到此插件的信息，包括文件位置等。
2.IE根據找到的CLSID信息建立 BHO 對象,而且查找 IObjectWithSite 接口. (這個接口很是簡單,只有SetSite和GetSite兩個方法)

3.IE把IWebBrowser2(瀏覽器插件)傳到 BHO 的 SetSite 方法，用戶在此方法中可掛載本身的事件處理方法。

4.窗口關閉時,IE把 null 傳到 BHO 的 SetSite 方法，此方法用來去掉掛載的事件處理方法。

編寫BHO流程
一、建立IObjectWithSite顯式接口，建立 COM 類型，實現繼承IObjectWithSite接口
二、實現此接口並在SetSite方法里加上所要掛載的事件
三、處理事件
四、註冊此BHO到註冊表中HKLM下的Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Browser Helper Objects;(HKCR下的CLSIDs是根據上面的路徑自動註冊的)
五、.net 下須設置此BHO項目的 配置屬性_>生成 中爲Interop註冊爲True，這樣才能將.net 類庫文件註冊到COM

 

http://hi.baidu.com/fanyu_fei/item/696a3e262fed5e0276272c03#