為什麼“浏覽器劫持”能夠如此猖狂呢？放眼眾多論壇的求助貼，我們不時可以看到諸如“我的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流程
1、創建IObjectWithSite顯式接口，創建 COM 類型，實現繼承IObjectWithSite接口
2、實現此接口並在SetSite方法裡加上所要掛載的事件
3、處理事件
4、注冊此BHO到注冊表中HKLM下的Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Browser Helper Objects;(HKCR下的CLSIDs是根據上面的路徑自動注冊的)
5、.net 下須設置此BHO項目的 配置屬性_>生成 中為Interop注冊為True，這樣才能將.net 類庫文件注冊到COM
http://hi.baidu.com/fanyu_fei/item/696a3e262fed5e0276272c03#
