基于HOOK技術和MMF的Windows密碼滲透技術研究_第1頁
基于HOOK技術和MMF的Windows密碼滲透技術研究_第2頁
基于HOOK技術和MMF的Windows密碼滲透技術研究_第3頁
基于HOOK技術和MMF的Windows密碼滲透技術研究_第4頁
基于HOOK技術和MMF的Windows密碼滲透技術研究_第5頁
已閱讀5頁,還剩3頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、基于HOOK技術和MMF的Windows密碼浸透技術研究摘要隨著計算機與網絡的普及,信息平安越來越成為人們所普遍關心的大事。密碼的浸透與反浸透在此領域表現的愈演愈烈。本文深化分析了各個版本inds密碼的特點,尤其是針對inds2K/XP平安性進步的情況下,提出了獲取inds密碼的關鍵技術及方法。并進一步分析了inds鉤子Hk和內存映像文件F的技術細節。在基于F的核心類IP中為鉤子句柄在內存中的共享提供了方法,并且解決了線程間的同步問題。然后深化討論了_PYDATA消息的特點。接著分析了實例程序重要代碼及注解并演示了結果。最終給出一些反密碼浸透的應對策略。關鍵詞內存映像文件;inds鉤子;進程間

2、通信;多線程上世紀90年紀使用過inds3.x的人可能很少有人理解這類操作系統中存在著密碼保護的破綻,假如選擇密碼控件中的“*文本然后復制到剪貼板上,那么看到的將不是“*而是密碼的原始文本。微軟發現了inds3.x這個問題并在新的版本ind95中修改了這個破綻。但是inds95存在著新的平安破綻,可以設計出間諜程序從當前運行的程序中得到密碼控件中的密碼,這些間諜程序并非是如同sftie一樣的破解程序。然而,微軟在ind2000中又修補了這個問題,如何通過F與HK技術獲取任何版本inds密碼控件的內容,這正是本文討論的重點問題。圖inds2K/XP密碼校驗獲取inds密碼技術主要是利用了inds

3、的平安破綻。在indsNT/95/98/E等操作系統下,假如在間諜程序中發送_GETTEXT消息到密碼控件,返回的文本將不再是“*而是實際的文本內容,而在inds2K/XP系統中微軟加了平安控制,假如發送_GETTEXT到密碼控件,系統將校驗懇求的進程判斷該進程是否有答應權,如圖1所示:假如懇求進程與密碼控件所在進程是同一進程,那么_GETTEXT消息將仍舊返回密碼的真實文本。假如兩個進程不一樣,就返回一個ERRR_AESS_DENIED的錯誤。所以獲取inds2K/XP密碼的關鍵技術在于:從密碼控件所在的進程中獲取_GETTEXT消息,而不是在浸透進程中得到。而這種在其它進程中運行用戶代碼的

4、技術完全可以利用inds鉤子(hk)技術來實現。首先我們需要理解一下什么是鉤子。inds系統是建立在事件驅動的機制上的,即整個系統都是通過消息的傳遞來實現的。鉤子(hk)是一種特殊的消息處理機制,鉤子可以監視系統或進程中的各種事件消息,截獲發往目的窗口的消息并進展處理。這樣,我們就可以在系統中安裝自定義的鉤子,監視系統中特定事件的發生,完成特定的功能,比方截獲鍵盤、鼠標的輸入,屏幕取詞,日志監視等等。鉤子的種類很多,每種鉤子可以截獲并處理相應的消息,如鍵盤鉤子可以截獲鍵盤消息,外殼鉤子可以截娶啟動和關閉應用程序的消息等。如圖2是一全局鉤子示意圖。在實例程序中運用H_GETESSAGE鉤子,這個

5、鉤子監視投遞到消息隊列中的inds消息。圖2全局鉤子的原理圖安裝鉤子的函數為SetindsHkEx,利用這個函數可以為整個系統或為某一特定進程安裝鉤子,不同的鉤子監視特定鉤子事件的發生,當某一事件觸發后,與之對應的代碼就會被系統調用。運用inds鉤子的一個難點是如何妥善保存鉤子的句柄。在設置鉤子前需要解決兩件事:1)一個包括了鉤子函數的動態鏈接庫;2)要注入鉤子的進程ID。如今假設進程A為進程B注入了一個鉤子。鉤子注入后,鉤子的句柄返回給了進程A并且動態鏈接庫映射到了進程B的地址空間。當進程B中觸發了一個鉤子事件,鉤子代碼被進程B調用(需要特別指出的是,鉤子代碼被一個遠程進程所調用,被調用的鉤

6、子代碼中假如調用GeturrentPressId這個函數,得到的是被注入了鉤子進程的進程ID,而不是注入進程)。在鉤子代碼中通過發消息獲取密碼真實文本,在鉤子代碼完畢前需調用allNextHkEx函數,假如這個函數調用失敗,安裝的其它鉤子將得不到消息。如今出現的問題是allNextHkEx需要一個鉤子的句柄,但那個所需的句柄已返回給了進程A而鉤子程序目前運行在進程B的代碼段內。這樣就需要用到進程間通信IP(InterPressuniatin)來傳遞鉤子句柄。解決以上問題的一般方法是在動態鏈接庫中創立一個“共享局部,寫入如下代碼:#pragadata_seg(“Shared)HHKg_hHk=N

7、ULL;#pragadata_seg()#pragaent(linker,“/setin:Shared,rs)簡單地說這幾行代碼創立了一個共享的變量,假如5個進程載入這個動態鏈接庫,5個進程都有訪問的權限。但這個方法有一些問題:一是一些編譯器可能并不支持這種方法。二是假如將來的inds版本發生了改變,這種方法就行不通。三是這個方法沒有規定線程同步,假如有多線程訪問這個變量,線程同步是非常重要的,沒有線程間的同步可能會觸發諸如沖突等一些問題。解決這個問題的方法是利用內存映像文件(F)。在IN32中,通過使用映像文件在進程間實現共享文件或內存共享,假如利用一樣的映像名字或文件句柄,那么不同的進程可

8、以通過一個指針來讀寫同一個文件或者同一內存數據塊,并把他們當成該進程內存空間的一局部。內存映像文件可以映射一個文件、一個文件中的指定區域或者指定的內存塊,其中的數據就可以用內存讀取指令來直接訪問,而不用頻繁的使用操作文件的I/系統函數,從而進步文件的存取速度和效率。映像文件的另一個重要作用就是用來支持永久命名的共享內存。要在兩個應用程序之間共享內存,可以在一個應用程序中創立一個文件并映射,然后另外一個程序通過翻開和映射此文件,并把它當作自己進程的內存來使用。運用內存映像文件解決進程間通信問題,并且創立一個互斥變量來解決線程的同步問題。所有這些封裝在一個IP的類中。通過運用內存映像文件解決了不同

9、編譯器的兼容問題,因為使用的都是標準in32API。加上F支持進程間的數據共享,在將來的inds版本中微軟不會改變F的定義及方法。并且互斥變量保持了線程訪問的同步。以下給出IP的類定義。lassIPpubli:IP();virtualIP();blreatEiPF(vid);/創立一個進程間通信的FblpenIPF(vid);/翻開一個進程間通信的FvidlseIPF(vid);/關閉一個進程間通信的FblIspen(vid)nstreturn(_hFileap!=NULL);/判斷F是否翻開blReadIPF(LPBYTEpBuf,DRDdBufSize);/讀FblriteIPF(nstL

10、PBYTEpBuf,nstDRDdBufSize);/寫FblLk(vid);/進入臨界區,創立互斥信號量vidUnlk(vid);/退出臨界區,撤消互斥信號量prteted:HANDLE_hFileap;/F文件句柄HANDLE_hutex;/互斥變量句柄;在解決進程間的通信問題方面,_PYDATA消息是一個非常好的工具,可以節省程序員的許多時間。當內存映像文件被建立時,系統就發送消息來填充它。然后系統再轉回到最初調用Sendessage的進程,從共享內存映像文件中將數據復制到所指定的緩沖區中,然后從Sendessage調用返回。對于系統已經知道的消息,發送消息時都可以按相應的方式來處理。假

11、如要建立自己的(_USER+x)消息,并從一個進程向另一個進程的窗口發送,那又會怎么樣?系統并不知道用戶要用內存映像文件并在發送消息時改變指針。為此,微軟建立了一個特殊的窗口消息,_PYDATA以解決這個問題:PYDATASTRUTds;Sendessage(hndReEiver,_PYDATA,(PARA)hndSender,(LPARA)ds);PYDATASTRUT是一個構造,定義在inuser.h文件中,形式如下面的樣子:TypedefstruttagPYDATASTRUTULNG_PTRdData;DRDbData;PVIDlpData;PYDATASTRUT;當一個進程要向另一個進

12、程的窗口發送一些數據時,必須先初始化PYDATASTRUT構造。數據成員dData是一個備用的數據項,可以存放任何值。例如,用戶有可能向另外的進程發送不同類型或不同類別的數據。可以用這個數據來指出要發送數據的內容。bData數據成員規定了向另外的進程發送的字節數,lpData數據成員指向要發送的第一個字節。lpData所指向的地址,當然在發送進程的地址空間中。當Sendessage看到要發送一個_PYDATA消息時,它建立一個內存映像文件,大小是bData字節,并從發送進程的地址空間中向這個內存映像文件中復制數據。然后再向目的窗口發送消息。在接收消息的窗口過程處理這個消息時,lPara參數指向

13、已在接收進程地址空間的一個PYDATASTRUT構造。這個構造的lpData成員指向接收進程地址空間中的共享內存映像文件的視圖。1只能發送這個消息,不能登記這個消息。不能登記一個_PYDATA消息,因為在接收消息的窗口過程處理完消息之后,系統必須釋放內存映像文件。假如登記這個消息,系統不知道這個消息何時被處理,所以也不能釋放復制的內存塊。2系統從另外的進程的地址空間中復制數據要花費一些時間。所以不應該讓發送程序中運行的其他線程修改這個內存塊,直到Sendessage調用返回。3利用_PYDATA消息,可以實現16位和32位之間的通信。它也能實現32位與64位之間的通信。這是使新程序同舊程序交流

14、的便捷方法。9.1鉤子函數vidExtratPassrd(nstHNDhnd,nstHNDhPdSpynd),該函數是獲取密碼的主要函數THARszBuffer256=_T(0);/分配一個緩沖區Sendessage(hnd,_GETTEXT,/向注入鉤子進程發消息獲得密碼文本sizef(szBuffer)/sizef(THAR),(LPARA)szBuffer);/保存在緩沖區中PYDATASTRUTds=0;/定義一個ds構造體ds.dData=(DRD)hnd;/dData保存該進程句柄ds.bData=(lstrlen(szBuffer)+1)*sizef(THAR);/bData保存

15、數據長度ds.lpData=szBuffer;/lpData指向緩沖首地址Sendessage(hPdSpynd,_PYDATA,(PARA)hnd,(LPARA)ds);/利用_PYDATA消息給獲取密碼進程發送密碼9.2鉤子過程LRESULTINAPIGetsgPr(intnde,PARAPara,LPARAlPara),該過程主要完成從內存映像文件中讀出保存的鉤子句柄。if(g_hHk=NULL)/從共享資源中讀數據,最終獲取鉤子句柄DRDdData=0,dSize=sizef(DRD);g_bIP.Lk();/g_bIP為IP對象,進入線程的同步g_bIP.penIPF();/翻開F文

16、件g_bIP.ReadIPF(LPBYTE)dData,dSize);/讀數據給dDatag_bIP.Unlk();/取消線程同步,退出臨界區g_hHk=(HHK)dData;/將讀到的數據賦值給鉤子句柄,本文的關鍵所在if(nde=0)/忽略小于0的值HNDhnd=NULL;/密碼控件所在的窗口句柄HNDhPdSpynd=NULL;/獲取密碼進程的窗口句柄SG*psg=(SG*)lPara;if(psg-essage=g_SanPassrd)/是否我們登記的消息hnd=(HND)psg-Para;hPdSpynd=(HND)psg-lPara;ExtratPassrd(hnd,hPdSpyn

17、d);/通過發送消息得到密碼returnallNextHkEx(g_hHk,nde,Para,lPara);/返回下一鉤子過程如圖3所示:實例是F下基于對話框的工程。在indXP下,拖動圖片控件放大鏡來檢索密碼控件中的密碼。下面的文本框顯示一些相關的窗口信息以及密碼文本。通過以上介紹的原理、方法及實現我們理解了如何得到inds系列密碼的方法,一個邏輯的問題是如何防止別人利用這樣的間諜程序復制我們的密碼?例如我們上網時假如被這樣的鉤子程序入侵,怎么才能保護密碼的平安。首選的解決方法是欺騙間諜程序,在用戶程序中不要顯示真實的密碼,最好是在密碼控件中顯示一條虛假的密碼。這樣假如有人用以上的程序來獲取

18、密碼,那他得到的是虛假的密碼而不是真實密碼。當然還有其它的應對策略,一種可行的方法是攔截_GETTEXT。但用虛假密碼還有其它的好處,通過利用虛假密碼代替真密碼,那么看到的密碼控件上*長度就不能判斷密碼到底有多長。假如一個程序在其密碼控件中顯示了“*的文本,我們立即知道密碼只有三個字符的長度,密碼的平安性大大降低。但假如通過一些加密算法將密碼控件的顯示變為一長串的“*,這種方法常見于微軟的密碼保護策略。那么密碼攻擊者將無從下手。圖3實例演示本文以評論inds系列的密碼特點為起點,主要針對2k/XP下的密碼浸透進展了分析。通過在進程內注入inds鉤子以及利用內存映像文件平安傳遞鉤子句柄等技術,找出一條獲取2K/XP中密碼的途徑。但不可否認這都是建立在利用inds平安破綻的根底之上的。為了彌補這些平安破綻,本文在最后也提出一些設想供讀者參考。當然只是在技術

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論