單機版的金山詞霸很難再出什么新花樣了，這是在現實的環境下一個通用軟件產品的生存期規律決定的，隨之而來的，單機版金山詞霸的結構和技術也基本不會有什么大變動了，這其中也包括屏幕取詞——雖然詞霸組從05年開始就一直想對當時的屏幕取詞方式進行升級以適應越來越苛刻的系統安全要求，不過后來由於種種原因一直沒有能夠實施。
金山詞霸的屏幕取詞技術是一種基於Win32API的，只能應用於客戶端的偏底層操作技術，在這個互聯網的時代，在追求注意力，追求現實效益的行業大環境下，金山詞霸的取詞技術不容易再有什么比較大的發展了，短期之內其應用也僅限於一些需要此功能的小型客戶端程序（如詞霸豆豆）以及作為OCX插件來支持 B/S結構產品的用戶體驗提升。至於Windows Vista出來之后在Avalon和GDI+模式下的技術更新，則不是我現在能夠預料得到的了，其可行性將在后面稍作討論。
好了，說了這么多廢話，也該進入正題了，不過在此之前要申明的一點是：本文所涉及的所有細節技術和方法，都是行業內所共知或者從業者通過正規方式能夠獲知和了解的，而宏觀的思路和邏輯也是具有相當技術水平的軟件開發人員通過思考能夠獲得的；因此本文不會侵犯到金山公司的商業機密和知識產權，也不會違反本人與金山公司之前簽署的保密協定。實際上我並不是金山詞霸取詞技術的主要開發人，所以即便我有心說一些什么也無法觸及比較秘密的細節內容，呵呵。僅此。
之前有不少文章來討論或者“揭密”金山詞霸的取詞技術，似乎這樣一種技術瞬間從神秘無比就變成了一層窗戶紙，不過在接觸了實際的代碼之后，我想要說的是，這是一種十分正常的軟件開發技術，這樣一種技術的開發、積累和完善，同許多其他技術一樣也是由簡而繁，從基礎的思路到最終的產品一步步走過來的；那種以為只要懂得了API Hook就了解了屏幕取詞的全部技術的想法是有偏差的。
API Hook是一種常規的核心編程技術，其基礎的實現方式和思路請參照《Windows核心編程》的第22章——順帶說一下，這本書是所有觸及Windows底層應用的程序開發人員應該儲備的工具書之一。
先說說屏幕取詞的基本設計思路。
對Windows編程有所了解的的人都知道，Windows為每個進程分配了2GB的虛地址空間，並使用了一系列的措施來保證每個進程各行其道，不會互相影響——這點就比Linux要好一些，那些說Linux安全性比Windows要高的人很多時候並不知道——原則上進程間的信息交互只能由相互信任的進程采用約定的方法——比如消息傳遞、共享內存、內存映射文件、Socket（Network），甚至磁盤文件系統等等；但是屏幕取詞的要求本質上是要取得一個未知進程里的某個特別操作的執行數據，那么，在沒有標准方法來執行這一點的時候，我們要想辦法將位置的進程編程與我們的取數進程相互信任並且已經約定好數據交互方法的進程——目前看來比較現實的方法，或者說唯一的方法，是讓目標進程執行我們設計好的代碼，這樣，我們的代碼取得宿主進程的執行權限，並了解如何把數據傳遞給我們的取詞進程，如果再能夠獲得特定操作時的數據（例如TextOut），我們的架構就完整了。
對於第一個需求，金山詞霸的操作簡單的就是幾個函數的序列：WriteProcessMemory,CreateRemoteThread, ReadProcessMemory。這是我之前提到幾種方法之一的變形；對於第二個需求，插入進去的代碼會修改程序的運行指令，將需要獲得其操作數據的函數地址強行更改為我們自己編寫的具有相同形式定義的函數，在我們的函數處理完成之后，再調用原本應該處理那些數據的函數去執行，而我們則可以通過事先約定好的方法得到操作數據的一個副本。修改原本函數的執行地址的方法，我們稱為掛接，其表現形式類似於插入一個函數調用。
實際上這種方法很像原先在Windows 9X上使用的外殼DLL的處理方式，有一些程序出於各種目的（有些甚至是為了增強系統安全，但實際上利用了系統的不安全隱患）將系統DLL替換成自己的 DLL文件，並將原來的系統DLL改名，然后在自己的DLL文件中模擬出系統DLL的所有接口，這樣程序調用系統接口的時候自然就會把數據傳到新的DLL 中去，新DLL處理完成后再以同樣的數據去調用那個被改了名的系統DLL中的對應接口。不過由於Win2000內核的逐漸興起，這種方法由於適應性差，工作量大，問題比較多而逐漸被廢棄了。現在使用這個辦法的程序大多只替換一些用戶級的DLL庫，干得一般也不是什么上得了台面的事情。
剩下來的就是一些細枝末節的問題，但卻是比較麻煩的地方。
1、取到需要的數據。並不是所有的目標程序都使用TextOut進行文本輸出，相當多的程序使用自己的緩存DC來進行文本顯示，對於自繪緩存的情況，原則上來說任何方法都不可能覆蓋所有的可能，特別是對於那些帶有排版、閱讀甚至權限控制功能的程序。簡單的對文本輸出函數的掛接常常會得到多到無法篩選處理的數據，要么就是根本監測不到函數調用。對於這種情況，無法繞開的解決辦法是監視所有可能用於繪制的函數調用，並保存所有可能用於繪制的數據，然后根據目標進程的操作來智能判斷有效數據，比如在預計目標進程進行屏幕輸出的時候，監測到一些內存DC的文本繪制操作，接着又監測到屏幕DC的一些BitBlt之類的緩存覆蓋操作，則要判斷當前取詞位置的屏幕DC被哪個內存DC所占有的緩沖區覆蓋了，然后看看這個緩沖區之前曾經輸出過哪些文本數據，如此等等。數據篩選的另外一個問題是定位，知道用戶的鼠標位置處於取到的數據中那一個字符之上是很重要的，是后期的單詞匹配和模式分析所不可缺少的。可惜的是GDI32並沒有提供方便的方法來搞定這件事情，我們只能用一些間接的辦法來實現，比如先獲得字體，再執行模擬排版，這是個很麻煩的事情，對於各種字符的處理都要和 GDI32完全一致。
2、掛接代碼的執行、數據交換。由於是將代碼注入到目標進程去執行，無形中就增加了許多限制。函數地址的計算是個比較大的問題，所有自定義的函數地址都要從一個易於通過系統標准方法獲得的基准地址計算偏移量來獲得，調用任何一個函數的時候都要明確的意識到在目標進程執行的情況，如此等等。而且，隨着對系統安全性越來越高的要求，這種使用WriteProcessMemory進行代碼注入的方式也逐漸暴露出來一些問題，例如在DEP環境下無法執行數據段代碼的問題，取詞時屏幕閃爍的問題，還有某些殺毒軟件對可能造成系統危險的進程間操作進行屏蔽和報警的問題。金山詞霸組曾經有一段時間考慮過使用適應性更好的 DLL注入方式來替換掉掛接模塊，但由於種種原因而沒有實現。同時，對於一些比較復雜的數據對象，有時並不是很容易取到其內部的數據，這樣就往往要輾轉幾次才能迂回的完成任務，有時甚至需要修改系統文件定義才能取到Private成員這樣的東西。
3、現場清理、與其它掛接的兼容性。對於掛接API這樣一種搭車行為，做完要做的事情之后最好是能夠不留痕跡的清理好現場，這既是出於系統執行效率和資源消耗的考慮，也是為了系統安全的目的，用於掛接和數據傳遞的代碼區域在使用完成之后應該進行資源釋放，對於執行失敗甚至異常的操作也應該有相對穩妥的辦法去把垃圾代碼清除掉。金山詞霸掛接了一個不常用的函數作為自身掛接狀態的標記，除了每次掛接任務完成后要執行自身清理之外，每次掛接前還要檢查一下這個標記來確定是否有未解除成功的以前的掛接，並根據需要執行清理。對於其它進程同時進行掛接的情況，如果不加判斷直接將系統API掛接地址修改為自身的函數入口地址，則另外的掛接程序就可能發生不可預知的執行問題。實際開發中發現東方快車、中文之星這樣的軟件在遇到掛接沖突時的確會發生問題。因此比較柔和的辦法是等待其它掛接程序先摘除自身的掛接，再執行我們的操作，同時還要保證我們的掛接代碼被其它程序強行拆掉之后不給目標進程造成不良影響，且能被再次掛接的操作識別從而完成清理。
4、特殊的目標。一些對繪制任務執行了比較復雜處理的軟件，比如Acrobat、Word、IE等等，如果使用基本的API Hook方法會使出錯崩潰的機會大大增加，而且由於其不公開的執行邏輯和復雜的處理方式，使得針對其進行的調試工作難於進行，不過好在它們大多數提供了另外的方法來完成我們的任務，我們可以將這些方法以插件的方式集成到取詞的模塊當中。比如Acrobat的SDK就提供了獲取正在顯示文檔某區域文本的功能，Word支持的Automation則允許在取詞插件被啟用的時候向外部進程暴露出一部分數據，IE則直接支持了獲取顯示窗口的Document；比較有趣的是Apabi，它的開發人員發現詞霸沒有為其獨立制作可用的取詞插件（實際上是沒辦法），就在每次自己進行繪制緩存輸出的時候，調用了一次空的 TextOut方法，用來配合金山詞霸的取詞方式，哈。這里還想順帶說一下觸發目標進程重繪屏幕的方法，正常情況下我們會用一個透明窗口把用戶鼠標焦點附近擋一下，這樣Windows就會自動給目標窗口發一個區域無效的消息提醒目標進程重新繪制被遮擋的部分；但僅僅是這樣的話會有不少軟件和你鬧別扭，比如大名鼎鼎的QQ，在某些版本里那個家伙被一個透明窗口擋住都會出現一片白色的未正常繪制的區域，而且根本不會自己重繪，對於這樣的問題，呵呵，只能具體問題具體分析了。
5、未來可行性。前面提到了Avalon和GDI+，這些新出來的東西是金山詞霸在最初開發時沒有考慮的。GDI+的問題已經解決了，畢竟它目前還是運行在Win32平台上的，通過分析它的Flat API和更底層的非文檔接口，我們用同樣的方法解決了取詞問題，甚至，由於GDI+提供了方便的計算字符位置的方法，獲取用戶鼠標焦點位置字符的方法也變得容易了許多。有限的一點感慨就是：沒有文檔的接口還真是不容易用啊。Avalon現在被設計為與GDI+平級的一個顯示層接口，由於集成了2D和3D顯示接口，其內部結構目前看來是相當的復雜，但是由於其仍然支持Win32平台，並且考慮到目前的3D設備在系統中的位置，個人認為Avalon的2D部分的API Hook取詞也有着相當的可行性。實際上金山游俠也是金山詞霸組的產品，所以我們當初考慮DirectX方式下的取詞和顯示也是可行的，不過由於其實現成本比較高，預期效益也並不大，就沒有做。WinFX我沒有太深的研究，更深的細節現在還沒法說，嘿嘿。還有一個麻煩的事情是Java，Java的桌面程序總讓人感覺不倫不類，分析下來在Windows平台下它有一部分文本輸出是調用了一些W非文檔的函數，而有一些則是使用自帶字庫進行繪制——對於后者，雖然不能說是一點辦法沒有，但實際的商業價值似乎不大，只是不知道在Windows Vista上的Java虛擬機會怎么做。最后一個潛在的問題是移動設備，受用戶輸入方式和系統資源的限制目前對屏幕取詞的需求還不是很強烈，但在可以預見的未來，還是有一些苗頭的。
6、后記。從現在的趨勢看來，即便Windows Vista給我們提供了更加豐富的接口功能，更高效的應用軟件開發模式，更強悍的界面表現方式，更方便的數據通信和溝通方式，B/S的大潮仍然無法阻擋的，這甚至代表了整個軟件生產和使用的趨勢，Browser功能的不斷擴充與其說是網絡應用進化的必然，不如說是埋下了系統表示層瀏覽器化的伏筆，而微軟在Windows Vista上所作的一切也使我多少嗅到了這樣的味道——如果這是真的，那么金山詞霸取詞技術現在這個樣子，則有可能隨着不可挽回的Win32落潮而成為這個時代的終篇之一。
能想起來的都說了，再想起來什么的話，再改吧，呵呵。
在金山詞霸中2005中帶了一個XdictGrb.dll，添加引用
廢話不多說了，還是把源碼放上
using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Text; using System.Windows.Forms; using XDICTGRB;//金山詞霸組件
namespace WindowsApplication1 { public partial class Form1 : Form,IXDictGrabSink { public Form1() { InitializeComponent();
} private void Form1_Load(object sender, EventArgs e) {
GrabProxy gp = new GrabProxy(); gp.GrabInterval = 1;//指抓取時間間隔
gp.GrabMode = XDictGrabModeEnum.XDictGrabMouse;//設定取詞的屬性 gp.GrabEnabled = true;//是否取詞的屬性 gp.AdviseGrab(this); } //接口的實現 int IXDictGrabSink.QueryWord(string WordString, int lCursorX, int lCursorY, string SentenceString, ref int lLoc, ref int lStart) { this.textBox1.Text = SentenceString;//鼠標所在語句 //this.textBox1.Text = SentenceString.Substring(lLoc + 1,1);//鼠標所在字符 return 1; } } }
B.Nhw32.dll法
這個是C++寫的一個組件
nhw32.dll 主要引出兩個函數：
1. DWORD WINAPI BL_SetFlag32(UINT nFlag, HWND hNotifyWnd, int MouseX,
int MouseY) 功能: 啟動或停止取詞。 參數: nFlag [輸入] 指定下列值之一：
GETWORD_ENABLE: 開始取詞。在重畫被取單詞區域前設置此標志。nhw32.dll是通過 重畫單詞區域，截取TextOutA, TextOutW, ExtTextOutA, ExtTextOutW等Windows API函數的參數來取詞的。
GETWORD_DISABLE: 停止取詞。 hNotifyWnd [輸入] 通知窗口句柄。當取到此時，向該通知窗口發送一登記消息：GWMSG_GETWORDOK。 MouseX [輸入] 指定取詞點的X坐標。
MouseY [輸入] 指定取詞點的Y坐標。 返回值： 可忽略。 2. DWORD WINAPI BL_GetText32(LPSTR lpszCurWord, int nBufferSize, LPRECT lpWordRect)
功能:
從內部緩沖區取出單詞文本串。對英語文本，該函數最長取出一行內以空格為界的三個英文單詞串，遇空格，非英文字母及除‘-’外的標點符號，則終止取詞。對漢字文本，該函數最長取出一行漢字串，遇英語字母，標點符號等非漢語字符，則終止取詞。該函數不能同時取出英語和漢語字符。
參數: lpszCurWord [輸入] 目的緩沖區指針。 nBufferSize [輸入] 目的緩沖區大小。
lpWordRect [輸出] 指向 RECT 結構的指針。該結構定義了被取單詞所在矩形區域。 返回值：
當前光標在全部詞中的位置。
此外，WinNT/2000版 nhw32.dll 還引出另兩個函數：
1. BOOL WINAPI SetNHW32() 功能: Win NT/2000 環境下的初始化函數。一般在程序開始時，調用一次。
參數: 無。 返回值： 如果成功 TRUE ，失敗 FALSE 。
2. BOOL WINAPI ResetNHW32() 功能: Win NT/2000 環境下的去初始化函數。一般在程序結束時調用。
參數: 無。 返回值： 如果成功 TRUE ，失敗 FALSE 。
"鼠標屏幕取詞"技術是在電子字典中得到廣泛地應用的，如四通利方和金山詞霸等軟件，這個技術看似簡單，其實在windows系統中實現卻是非常復雜的，總的來說有兩種實現方式：
第一種：采用截獲對部分gdi的api調用來實現,如textout,textouta等。
第二種：對每個設備上下文(dc)做一分copy,並跟蹤所有修改上下文(dc)的操作。
第二種方法更強大,但兼容性不好，而第一種方法使用的截獲windowsapi的調用，這項技術的強大可能遠遠超出了您的想象，毫不誇張的說，利用 windowsapi攔截技術，你可以改造整個操作系統，事實上很多外掛式windows中文平台就是這么實現的！而這項技術也正是這篇文章的主題。
截windowsapi的調用，具體的說來也可以分為兩種方法： 第一種方法通過直接改寫winapi 在內存中的映像，嵌入匯編代碼，使之被調用時跳轉到指定的地址運行來截獲；第二種方法則改寫iat（import address table輸入地址表），重定向winapi函數的調用來實現對winapi的截獲。
第一種方法的實現較為繁瑣，而且在win95、98下面更有難度，這是因為雖然微軟說win16的api只是為了兼容性才保留下來，程序員應該盡可能地調用 32位的api,實際上根本就不是這樣！win 9x內部的大部分32位api經過變換調用了同名的16位api，也就是說我們需要在攔截的函數中嵌入16位匯編代碼！
我們將要介紹的是第二種攔截方法，這種方法在win95、98和nt下面運行都比較穩定，兼容性較好。由於需要用到關於windows虛擬內存的管理、打破進程邊界牆、向應用程序的進程空間中注入代碼、pe（portable executable）文件格式和iat（輸入地址表）等較底層的知識，所以我們先對涉及到的這些知識大概地做一個介紹，最后會給出攔截部分的關鍵代碼。
先說windows虛擬內存的管理。windows9x給每一個進程分配了4gb的地址空間，對於nt來說，這個數字是2gb，系統保留了2gb 到 4gb之間的地址空間禁止進程訪問，而在win9x中，2gb到4gb這部分虛擬地址空間實際上是由所有的win32進程所共享的，這部分地址空間加載了共享win32 dll、內存映射文件和vxd、內存管理器和文件系統碼，win9x中這部分對於每一個進程都是可見的，這也是win9x操作系統不夠健壯的原因。 win9x中為16位操作系統保留了0到4mb的地址空間，而在4mb到2gb之間也就是win32進程私有的地址空間，由於每個進程的地址空間都是相對獨立的，也就是說，如果程序想截獲其它進程中的api調用，就必須打破進程邊界牆，向其它的進程中注入截獲api調用的代碼，這項工作我們交給鈎子函數（setwindowshookex）來完成，關於如何創建一個包含系統鈎子的動態鏈接庫，《電腦高手雜志》在第？期已經有過專題介紹了，這里就不贅述了。所有系統鈎子的函數必須要在動態庫里，這樣的話，當進程隱式或顯式調用一個動態庫里的函數時，系統會把這個動態庫映射到這個進程的虛擬地址空間里，這使得dll成為進程的一部分，以這個進程的身份執行，使用這個進程的堆棧，也就是說動態鏈接庫中的代碼被鈎子函數注入了其它gui 進程的地址空間（非gui進程，鈎子函數就無能為力了），當包含鈎子的dll注入其它進程后，就可以取得映射到這個進程虛擬內存里的各個模塊（exe和 dll）的基地址，如：hmodule hmodule=getmodulehandle("mypro.exe");在mfc程序中,我們可以用afxgetinstancehandle() 函數來得到模塊的基地址。exe和dll被映射到虛擬內存空間的什么地方是由它們的基地址決定的。它們的基地址是在鏈接時由鏈接器決定的。當你新建一個 win32工程時，vc＋＋鏈接器使用缺省的基地址0x00400000。可以通過鏈接器的base選項改變模塊的基地址。exe通常被映射到虛擬內存的 0x00400000處，dll也隨之有不同的基地址，通常被映射到不同進程的相同的虛擬地址空間處。
系統將exe和dll原封不動映射到虛擬內存空間中，它們在內存中的結構與磁盤上的靜態文件結構是一樣的。即pe (portable executable) 文件格式。我們得到了進程模塊的基地址以后，就可以根據pe文件的格式窮舉這個模塊的image_import_descriptor數組，看看進程空間中是否引入了我們需要截獲的函數所在的動態鏈接庫，比如需要截獲"textouta"，就必須檢查"gdi32.dll"是否被引入了。說到這里，我們有必要介紹一下pe文件的格式，如右圖，這是pe文件格式的大致框圖，最前面是文件頭，我們不必理會，從pe file optional header后面開始，就是文件中各個段的說明，說明后面才是真正的段數據，而實際上我們關心的只有一個段，那就是".idata"段，這個段中包含了所有的引入函數信息，還有iat（import address table）的rva（relative virtual address）地址。
說到這里，截獲windowsapi的整個原理就要真相大白了。實際上所有進程對給定的api函數的調用總是通過pe文件的一個地方來轉移的，這就是一個該模塊(可以是exe或dll)的".idata"段中的iat輸入地址表（import address table）。在那里有所有本模塊調用的其它dll的函數名及地址。對其它dll的函數調用實際上只是跳轉到輸入地址表，由輸入地址表再跳轉到dll真正的函數入口。
具體來說，我們將通過image_import_descriptor數組來訪問".idata"段中引入的dll的信息，然后通過image_thunk_data數組來針對一個被引入的dll訪問該dll中被引入的每個函數的信息，找到我們需要截獲的函數的跳轉地址，然后改成我們自己的函數的地址……具體的做法在后面的關鍵代碼中會有詳細的講解。
講了這么多原理，現在讓我們回到"鼠標屏幕取詞"的專題上來。除了api函數的截獲，要實現"鼠標屏幕取詞"，還需要做一些其它的工作，簡單的說來，可以把一個完整的取詞過程歸納成以下幾個步驟：
1． 安裝鼠標鈎子，通過鈎子函數獲得鼠標消息。 使用到的api函數：setwindowshookex 2． 得到鼠標的當前位置，向鼠標下的窗口發重畫消息，讓它調用系統函數重畫窗口。
使用到的api函數：windowfrompoint，screentoclient，invalidaterect 3． 截獲對系統函數的調用，取得參數，也就是我們要取的詞。
對於大多數的windows應用程序來說，如果要取詞，我們需要截獲的是"gdi32.dll"中的"textouta"函數。
我們先仿照textouta函數寫一個自己的mytextouta函數，如： bool winapi mytextouta(hdc hdc, int nxstart, int nystart, lpcstr lpszstring,int cbstring) { // 這里進行輸出lpszstring的處理 // 然后調用正版的textouta函數 }
把這個函數放在安裝了鈎子的動態連接庫中，然后調用我們最后給出的hookimportfunction函數來截獲進程對textouta函數的調用，跳轉到我們的mytextouta函數，完成對輸出字符串的捕捉。hookimportfunction的用法：
hookfuncdesc hd; proc porigfuns; hd.szfunc="textouta";
hd.pproc=(proc)mytextouta; hookimportfunction (afxgetinstancehandle(),"gdi32.dll",&hd,porigfuns);
下面給出了hookimportfunction的源代碼，相信詳盡的注釋一定不會讓您覺得理解截獲到底是怎么實現的很難，ok,let s go：
///////////////////////////////////////////// begin /////////////////////////////////////////////////////////////// #include <crtdbg.h> // 這里定義了一個產生指針的宏 #define makeptr(cast, ptr, addvalue) (cast)((dword)(ptr)+(dword)(addvalue)) // 定義了hookfuncdesc結構,我們用這個結構作為參數傳給hookimportfunction函數 typedef struct tag_hookfuncdesc { lpcstr szfunc; // the name of the function to hook.
proc pproc; // the procedure to blast in. } hookfuncdesc , * lphookfuncdesc; // 這個函數監測當前系統是否是windownt bool isnt(); // 這個函數得到hmodule -- 即我們需要截獲的函數所在的dll模塊的引入描述符(import descriptor)
pimage_import_descriptor getnamedimportdescriptor(hmodule hmodule, lpcstr szimportmodule); // 我們的主函數 bool hookimportfunction(hmodule hmodule, lpcstr szimportmodule, lphookfuncdesc pahookfunc, proc* paorigfuncs) {
/////////////////////// 下面的代碼檢測參數的有效性 ////////////////////////////
_assert(szimportmodule); _assert(!isbadreadptr(pahookfunc, sizeof(hookfuncdesc))); #ifdef _debug if (paorigfuncs) _assert(!isbadwriteptr(paorigfuncs, sizeof(proc)));
_assert(pahookfunc.szfunc); _assert(*pahookfunc.szfunc != \0 );
_assert(!isbadcodeptr(pahookfunc.pproc)); #endif if ((szimportmodule == null) || (isbadreadptr(pahookfunc, sizeof(hookfuncdesc)))) {
_assert(false); setlasterrorex(error_invalid_parameter, sle_error);
return false; }
//////////////////////////////////////////////////////////////////////////////
// 監測當前模塊是否是在2gb虛擬內存空間之上 // 這部分的地址內存是屬於win32進程共享的 if (!isnt() && ((dword)hmodule >= 0x80000000)) { _assert(false);
setlasterrorex(error_invalid_handle, sle_error); return false; }
// 清零 if (paorigfuncs) memset(paorigfuncs, null, sizeof(proc)); // 調用getnamedimportdescriptor()函數,來得到hmodule -- 即我們需要 // 截獲的函數所在的dll模塊的引入描述符(import descriptor) pimage_import_descriptor pimportdesc = getnamedimportdescriptor(hmodule, szimportmodule); if (pimportdesc == null) return false; // 若為空,則模塊未被當前進程所引入 // 從dll模塊中得到原始的thunk信息,因為pimportdesc->firstthunk數組中的原始信息已經 // 在應用程序引入該dll時覆蓋上了所有的引入信息,所以我們需要通過取得pimportdesc->originalfirstthunk // 指針來訪問引入函數名等信息 pimage_thunk_data porigthunk = makeptr(pimage_thunk_data, hmodule, pimportdesc->originalfirstthunk); // 從pimportdesc->firstthunk得到image_thunk_data數組的指針,由於這里在dll被引入時已經填充了 // 所有的引入信息,所以真正的截獲實際上正是在這里進行的 pimage_thunk_data prealthunk = makeptr(pimage_thunk_data, hmodule, pimportdesc->firstthunk); // 窮舉image_thunk_data數組,尋找我們需要截獲的函數,這是最關鍵的部分! while (porigthunk->u1.function) { // 只尋找那些按函數名而不是序號引入的函數 if (image_ordinal_flag != (porigthunk->u1.ordinal & image_ordinal_flag))
{ // 得到引入函數的函數名 pimage_import_by_name pbyname = makeptr(pimage_import_by_name, hmodule, porigthunk->u1.addressofdata);
// 如果函數名以null開始,跳過,繼續下一個函數 if ( \0 == pbyname->name[0]) continue;
// bdohook用來檢查是否截獲成功 bool bdohook = false; // 檢查是否當前函數是我們需要截獲的函數
if ((pahookfunc.szfunc[0] == pbyname->name[0]) &&
(strcmpi(pahookfunc.szfunc, (char*)pbyname->name) == 0)) { // 找到了! if (pahookfunc.pproc) bdohook = true; } if (bdohook) {
// 我們已經找到了所要截獲的函數,那么就開始動手吧 // 首先要做的是改變這一塊虛擬內存的內存保護狀態,讓我們可以自由存取
memory_basic_information mbi_thunk; virtualquery(prealthunk, &mbi_thunk, sizeof(memory_basic_information));
_assert(virtualprotect(mbi_thunk.baseaddress, mbi_thunk.regionsize,
page_readwrite, &mbi_thunk.protect)); // 保存我們所要截獲的函數的正確跳轉地址 if (paorigfuncs) paorigfuncs = (proc)prealthunk->u1.function; // 將image_thunk_data數組中的函數跳轉地址改寫為我們自己的函數地址! // 以后所有進程對這個系統函數的所有調用都將成為對我們自己編寫的函數的調用 prealthunk->u1.function = (pdword)pahookfunc.pproc; // 操作完畢!將這一塊虛擬內存改回原來的保護狀態 dword dwoldprotect;
_assert(virtualprotect(mbi_thunk.baseaddress, mbi_thunk.regionsize,
mbi_thunk.protect, &dwoldprotect)); setlasterror(error_success);
return true; } } // 訪問image_thunk_data數組中的下一個元素
porigthunk++; prealthunk++; } return true; } // getnamedimportdescriptor函數的實現 pimage_import_descriptor getnamedimportdescriptor(hmodule hmodule, lpcstr szimportmodule) { // 檢測參數 _assert(szimportmodule); _assert(hmodule); if ((szimportmodule == null) || (hmodule == null)) { _assert(false);
setlasterrorex(error_invalid_parameter, sle_error); return null; }
// 得到dos文件頭 pimage_dos_header pdosheader = (pimage_dos_header) hmodule;
// 檢測是否mz文件頭 if (isbadreadptr(pdosheader, sizeof(image_dos_header)) ||
(pdosheader->e_magic != image_dos_signature)) { _assert(false);
setlasterrorex(error_invalid_parameter, sle_error); return null; }
// 取得pe文件頭 pimage_nt_headers pntheader = makeptr(pimage_nt_headers, pdosheader, pdosheader->e_lfanew); // 檢測是否pe映像文件 if (isbadreadptr(pntheader, sizeof(image_nt_headers)) ||
(pntheader->signature != image_nt_signature)) { _assert(false);
setlasterrorex(error_invalid_parameter, sle_error); return null; }
// 檢查pe文件的引入段(即 .idata section) if (pntheader->optionalheader.datadirectory[image_directory_entry_import].virtualaddress == 0) return null; // 得到引入段(即 .idata section)的指針
pimage_import_descriptor pimportdesc = makeptr(pimage_import_descriptor, pdosheader,
pntheader->optionalheader.datadirectory[image_directory_entry_import].virtualaddress);
// 窮舉pimage_import_descriptor數組尋找我們需要截獲的函數所在的模塊 while (pimportdesc->name) { pstr szcurrmod = makeptr(pstr, pdosheader, pimportdesc->name); if (stricmp(szcurrmod, szimportmodule) == 0)
break; // 找到!中斷循環 // 下一個元素 pimportdesc++; } // 如果沒有找到,說明我們尋找的模塊沒有被當前的進程所引入! if (pimportdesc->name == null) return null; // 返回函數所找到的模塊描述符(import descriptor) return pimportdesc; }
// isnt()函數的實現 bool isnt() { osversioninfo stosvi;
memset(&stosvi, null, sizeof(osversioninfo));
stosvi.dwosversioninfosize = sizeof(osversioninfo); bool bret = getversionex(&stosvi); _assert(true == bret); if (false == bret) return false; return (ver_platform_win32_nt == stosvi.dwplatformid); }
/////////////////////////////////////////////// end //////////////////////////////////////////////////////////////////////
不知道在這篇文章問世之前，有多少朋友嘗試過去實現"鼠標屏幕取詞"這項充滿了挑戰的技術，也只有嘗試過的朋友才能體會到其間的不易，尤其在探索api函數的截獲時，手頭的幾篇資料沒有一篇是涉及到關鍵代碼的，重要的地方都是一筆代過，msdn更是顯得蒼白而無力，也不知道除了 image_import_descriptor和image_thunk_data，微軟還隱藏了多少秘密，好在硬着頭皮還是把它給攻克了，希望這篇文章對大家能有所幫助。