• <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>
            

    
            

            




            







												


        


            

            
	
	



	

            

            


            
	
		
            
			
            
	

            


            
	
					


            
	
	
            

            好久沒寫博客了， 一個(gè)月一篇還是要盡量保證，今天談下Hook技術(shù)。
            


            

            在Window平臺(tái)上開發(fā)任何稍微底層一點(diǎn)的東西，基本上都是Hook滿天飛， 普通應(yīng)用程序如此，安全軟件更是如此， 這里簡單記錄一些常用的Hook技術(shù)。
            


            

            SetWindowsHookEx
            

            基本上做Windows開發(fā)都知道這個(gè)API， 它給我們提供了一個(gè)攔截系統(tǒng)事件和消息的機(jī)會(huì)， 并且它可以將我們的DLL注入到其他進(jìn)程。
            

            但是隨著64位時(shí)代的到來和Vista之后的UAC機(jī)制開啟，這個(gè)API很多時(shí)候不能正常工作了：
            


            

            首先，32位DLL沒法直接注入到64位的應(yīng)用程序里面， 因?yàn)樗麄兊牡刂房臻g完全不一樣的。當(dāng)然盡管沒法直接注入，但是在權(quán)限范圍內(nèi)，系統(tǒng)會(huì)盡量以消息的方式讓你能收到64位程序的消息事件。
            


            

            其次，UAC打開的情況下低權(quán)限程序沒法Hook高權(quán)限程序， 實(shí)際上低權(quán)限程序以高權(quán)限程序窗口為Owner創(chuàng)建窗口也會(huì)失敗， 低權(quán)限程序在高權(quán)限程序窗口上模擬鼠標(biāo)鍵盤也會(huì)失敗。
            


            

            有人說我們可以關(guān)閉UAC， Win7下你確實(shí)可以，但是Win8下微軟已經(jīng)不支持真正關(guān)閉UAC， 從這里我們也可以看到微軟技術(shù)過渡的方式， 中間會(huì)提供一個(gè)選項(xiàng)來讓你慢慢適應(yīng)，最后再把這個(gè)選項(xiàng)關(guān)掉， UAC和Aero模式都是如此。
            


            

            那么我們?nèi)绾谓鉀Q這些問題？
            


            

            對(duì)于64位問題 ， 解決方法是提供2個(gè)DLL，分別可以Hook32和64位程序。
            


            

            對(duì)于權(quán)限問題， 解決方法是提升權(quán)限， 通過注冊系統(tǒng)服務(wù)， 由服務(wù)程序創(chuàng)建我們的工作進(jìn)程。這里為什么要?jiǎng)?chuàng)建一個(gè)其他進(jìn)程而不直接在服務(wù)進(jìn)程里干活？ 因?yàn)閂ista后我們有了Session隔離機(jī)制，服務(wù)程序運(yùn)行在Session 0，我們的其他程序運(yùn)行在Session 1, Session 2等， 如果我們直接在服務(wù)程序里干活，我們就只能在Session 0里工作。通過創(chuàng)建進(jìn)程，我們可以在DuplicateTokenEx后將Token的SessionID設(shè)置成目標(biāo)Session，并且在CreateProcessAsUser時(shí)指定目標(biāo)WinStation和Desktop， 這樣我們就既獲得了System權(quán)限，并且也可以和當(dāng)前桌面進(jìn)程交互了。
            


            

            SetWinEventHook
            

            很多人可能都不知道這個(gè)API， 但是這個(gè)API其實(shí)挺重要的， 看名字就知道它是Hook事件(Event)的， 具體哪些事件可以看這里.
            


            

            為什么說這個(gè)API重要， 因?yàn)檫@個(gè)API大部分時(shí)候沒有SetWindowsHookEx的權(quán)限問題， 也就是說這個(gè)API可以讓你Hook到高權(quán)限程序的事件， 它同時(shí)支持進(jìn)程內(nèi)(WINEVENT_INCONTEXT)和進(jìn)程外(WINEVENT_OUTOFCONTEXT)2種Hook方式， 你可以以進(jìn)程外的方式Hook到64位程序的事件。
            


            

            為什么這個(gè)API沒有權(quán)限問題， 因?yàn)樗墙oAccessibility用的， 也就是它是給自動(dòng)測試和殘障工具用的， 所以它要保證有效。
            


            

            我曾經(jīng)看到這樣一個(gè)程序，當(dāng)任何程序(無論權(quán)限高低)有窗口拖動(dòng)(拖標(biāo)題欄改變位置或是拖邊框改變大小)， 程序都能捕獲到， 當(dāng)時(shí)很好奇它是怎么做到的？
            

            Spy了下窗口消息, 知道有這樣2個(gè)消息：WM_ENTERSIZEMOVE和WM_EXITSIZEMOVE表示進(jìn)入和退出這個(gè)事件， 但是那也只能獲得自己的消息，其他程序的消息它是如何捕獲到的？當(dāng)時(shí)懷疑用的是Hook， 卻發(fā)現(xiàn)沒有DLL注入。查遍了Windows API 也沒有發(fā)現(xiàn)有API可以查詢一個(gè)窗口是否在這個(gè)拖動(dòng)狀態(tài)。最后發(fā)現(xiàn)用的是SetWinEventHook的EVENT_SYSTEM_MOVESIZESTART和EVENT_SYSTEM_MOVESIZEEND。
            


            

            API Hook
            

            常見的API Hook包括2種， 一種是基于PE文件的導(dǎo)入表(IAT), 還有一種是修改前5個(gè)字節(jié)直接JMP的inline Hook.
            


            

            對(duì)于基于IAT的方式， 原理是PE文件里有個(gè)導(dǎo)入表， 代表該模塊調(diào)用了哪些外部API，模塊被加載到內(nèi)存后， PE加載器會(huì)修改該表，地址改成外部API重定位后的真實(shí)地址， 我們只要直接把里面的地址改成我們新函數(shù)的地址， 就可以完成對(duì)相應(yīng)API的Hook。《Windows核心編程》里第22章有個(gè)封裝挺好的CAPIHook類，我們可以直接拿來用。
            

            我曾經(jīng)用API Hook來實(shí)現(xiàn)自動(dòng)測試，見這里 API Hook在TA中的應(yīng)用
            


            

            對(duì)于基于Jmp方式的inline hook, 原理是修改目標(biāo)函數(shù)的前5個(gè)字節(jié)， 直接Jmp到我們的新函數(shù)。雖然原理挺簡單， 但是因?yàn)橛玫搅似脚_(tái)相關(guān)的匯編代碼， 一般人很難寫穩(wěn)定。真正在項(xiàng)目中用還是要求穩(wěn)定， 所以我們一般用微軟封裝好的Detours, 對(duì)于Detours的原理，這里有篇不錯(cuò)的文章 微軟研究院Detour開發(fā)包之API攔截技術(shù)。
            


            

            比較一下2種方式： 
            

            IAT的方式比較安全簡單， 但是只適用于Hook導(dǎo)入函數(shù)方式的API。
            

            Inline Hook相對(duì)來說復(fù)雜點(diǎn)， 但是它能Hook到任何函數(shù)(API和內(nèi)部函數(shù))，但是它要求目標(biāo)函數(shù)大于5字節(jié)， 同時(shí)把握好修改時(shí)機(jī)或是Freeze其他線程， 因?yàn)槎嗑€程中改寫可能會(huì)引起沖突。

            

            還有一種是Hook被調(diào)用模塊的導(dǎo)出表（EAT）， 但是感覺一般用得用的不多。原理是調(diào)用模塊里IAT中的函數(shù)地址是通過被調(diào)用模塊的EAT獲取的， 所以你只要修改了被調(diào)用模塊的EAT中的函數(shù)地址，對(duì)方的調(diào)用就自然被你Hook了。但是這里有個(gè)時(shí)機(jī)問題， 就是你替換EAT表要足夠早，要在IAT使用它之前才行。但是感覺這個(gè)行為是由PE加載器決定的， 一般人很難干涉， 不知道大家有什么好方法？ 
            


            

            我們一般可以將IAT Hook和EAT Hook結(jié)合起來使用， 先枚舉所有模塊Hook IAT，這樣當(dāng)前已有模塊的API都被你Hook了，然后再Hook EAT， 這樣后續(xù)的模塊也被你Hook了（因?yàn)橐ㄟ^EAT獲取函數(shù)地址）。 
            


            

            如果你只用Hook IAT而不Hook EAT, 當(dāng)有新模塊加載時(shí)，你要Hook它的IAT， 所以你就要Hook LoadLibrary(Ex)和GetProcAddress來攔截新模塊的加載。所以理論上感覺 Hook EAT不是很有必要， 因?yàn)閱斡肏ook IAT已經(jīng)可以解決我們所有的問題了， HOOK IAT還有一種優(yōu)勢是我們可以過濾某個(gè)模塊不Hook，而一旦hook EAT， 它就會(huì)影響我們所有調(diào)用該函數(shù)的模塊。
            


            

            COM Hook
            

            Window上因?yàn)橛泻芏嚅_發(fā)包是以COM方式提供的(比如DirectX)， 所以我們就有了攔截COM調(diào)用的COM Hook。
            

            因?yàn)镃OM里面很關(guān)鍵的是它的接口是C++里虛表的形式提供的， 所以COM的Hook很多是時(shí)候其實(shí)就是虛表（vtable）的Hook。
            

            關(guān)于C++ 對(duì)象模型和虛表可以看我這篇 探索C++對(duì)象模型
            


            

            對(duì)于COMHook，考慮下面2種case：
            


            

            一種是我們Hook程序先運(yùn)行，然后啟動(dòng)某個(gè)游戲程序（DirectX 9）， 我們想Hook游戲的繪畫內(nèi)容。
            


            

            這種方式下， 我們可以先Hook API Direct3DCreate9， 然后我們繼承于IDirect3D9， 自己實(shí)現(xiàn)一個(gè)COM對(duì)象返回回去， 這樣我們就可以攔截到所有對(duì)該對(duì)象的操作，為所欲為了， 當(dāng)然我們自己現(xiàn)實(shí)的COM對(duì)象內(nèi)部會(huì)調(diào)用真正的Direct3DCreate9，封裝真正的IDirect3D9。
            


            

            當(dāng)然有時(shí)我們可能不用替代整個(gè)COM組件，我們只需要修改其中一個(gè)或幾個(gè)COM函數(shù)， 這種情況下我們可以創(chuàng)建真正的IDirect3D9對(duì)象后直接修改它的虛表， 把其中某些函數(shù)改成我們自己的函數(shù)地址就可以了。
            


            

            其實(shí)ATL就是用接口替代的方式來調(diào)試和記錄COM接口引用計(jì)數(shù)的次數(shù)， 具體可以看我這篇 理解ATL中的一些匯編代碼
            


            

            還有一種case是游戲程序已經(jīng)在運(yùn)行了， 然后才啟動(dòng)我們的Hook進(jìn)程， 我們怎么樣才能Hook到里面的內(nèi)容？
            


            

            這種情況下我們首先要對(duì)程序內(nèi)存有比較詳細(xì)的認(rèn)識(shí)， 才能思考創(chuàng)建出來的D3D對(duì)象的虛表位置， 從而進(jìn)行Hook， 關(guān)于程序內(nèi)存布局，可見我這篇 理解程序內(nèi)存。
            


            

            理論上說COM對(duì)象如果是以C++接口的方式實(shí)現(xiàn)， 虛表會(huì)位于PE文件的只讀數(shù)據(jù)節(jié)(.rdata), 并且所有該類型的對(duì)象都共享該虛表， 所以我們只要?jiǎng)?chuàng)建一個(gè)該類型對(duì)象，我們就可以獲得其他人創(chuàng)建的該類型對(duì)象的虛表位置，我們就可以改寫該虛表實(shí)現(xiàn)Hook（實(shí)際操作時(shí)需要通過VirtualProtect修改頁面的只讀屬性才能寫入）。
            


            

            但是實(shí)際上COM的虛表只是一塊內(nèi)存， 它并不一定是以C++實(shí)現(xiàn)， 所以它可以存在于任何內(nèi)存的任何地方。另外對(duì)象的虛表也不一定是所有同類型的對(duì)象共享同一虛表， 我們完全可以每個(gè)對(duì)象都有自己的一份虛表。比如我發(fā)現(xiàn)IDirect3D9是大家共享同一虛表的（存在D3D9.dll）， 但是IDirect3DDevice9就是每個(gè)對(duì)象都有自己的虛表了(存在于堆heap)。所以如果你要Hook IDirect3DDevice9接口，通過修改虛表實(shí)際上沒法實(shí)現(xiàn)。
            


            

            但是盡管有時(shí)每個(gè)對(duì)象的虛表不一樣，同類型對(duì)象虛表里的函數(shù)地址卻都是一樣的， 所以這種情況下我們可以通過inline Hook直接修改函數(shù)代碼。當(dāng)然有些情況下如果是靜態(tài)鏈接庫，即使函數(shù)代碼也是每個(gè)模塊都有自己的一份， 這種情況下就只能反匯編獲取虛表和函數(shù)的地址了。
            


            

            最后，總結(jié)一下， 上面主要探討了Windows上的各種Hook技術(shù)，通過將這些Hook技術(shù)組起來， 可以實(shí)現(xiàn)很多意想不到的功能， 比如我們完全可以通過Hook D3D實(shí)現(xiàn)Win7任務(wù)欄那種Thumbnail預(yù)覽的效果(當(dāng)然該效果可以直接由DWM API實(shí)現(xiàn), 但是如果我們可以通過HOOK以動(dòng)畫的方式實(shí)現(xiàn)是不是更有趣 )。
            
	
            posted on 2013-10-30 11:03 Richard Wei 閱讀(30198) 評(píng)論(13)  編輯 收藏 引用  所屬分類: windows desktop 
            

            







            
	    
    


            
FeedBack:

            
	

		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2013-10-30 20:58 | zgpxgame
            
				
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2013-10-30 21:04 | StarsunYzL
            
				
            總結(jié)的不錯(cuò)，API Hook還可以加一個(gè)EAT Hook。但是要是程序加了殼，IAT/EAT Hook通常就會(huì)失效，因?yàn)閷?dǎo)入/導(dǎo)出表已被加密，所以最通用的還是Inline Hook，同時(shí)也是最復(fù)雜的，主要是要修正包含相對(duì)地址的指令。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)[未登錄]
            
			
            
				2013-10-31 10:16 | 春秋十二月
            
				
            搞windows技術(shù)，就是要讓你不斷跟著微軟跑，兼容性是個(gè)很大的問題  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2013-10-31 10:34 | Richard Wei
            
				
            @StarsunYzL

            已經(jīng)加上, 如有不正確的地方,歡迎指正.  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2013-10-31 16:38 | Richard Wei
            
				
            @春秋十二月
            同意,相對(duì)Unix/Linux的穩(wěn)定， Windows開發(fā)要累得多  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2013-11-09 16:30 | 紅色代碼
            
				
            好文.再可以加上SSDT HOOK等驅(qū)動(dòng)級(jí)的文章,就更全面了  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2014-02-07 15:42 | allen
            
				
            “ 但是IDirect3DDevice9就是每個(gè)對(duì)象都有自己的虛表了(存在于堆heap)。所以如果你要Hook IDirect3DDevice9接口，通過修改虛表實(shí)際上沒法實(shí)現(xiàn)。”

            這個(gè)說法是錯(cuò)誤的，只要是C++對(duì)象，虛表都只會(huì)存在一份。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2014-02-07 16:13 | Richard Wei
            
				
            @allen
            嗯, 單看這句話確實(shí)是錯(cuò)的， 但是你要結(jié)合我的上下文來看。
            我的意思是你這里修改IDirect3DDevice9的虛表內(nèi)容， 修改的也僅是你當(dāng)前對(duì)象的， 而不會(huì)影響其他IDirect3DDevice9對(duì)象， 因?yàn)樗麄儾皇撬袑?duì)象共享同一虛表的， 但是同一標(biāo)準(zhǔn)C++類的所有對(duì)象會(huì)共享同一虛表。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2014-05-27 19:06 | allen
            
				
            @Richard Wei
            這也錯(cuò)了，我hook過IDirect3DDevice9的虛表函數(shù)，按你的說法我去hook這個(gè)借口完全無作用無意義，因?yàn)樾薷牡亩际亲约旱谋恚粫?huì)影響其它的IDirect3DDevice9。但實(shí)際上，IDirect3DDevice9只有一個(gè)虛函數(shù)表，對(duì)某個(gè)對(duì)象的虛函數(shù)表進(jìn)行修改則影響所有的對(duì)象。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2014-05-27 19:57 | Richard Wei
            
				
            @allen
            剛才有簡單測試了下， 測試代碼如下：
            		D3DPRESENT_PARAMETERS ps = {0};
            		ps.Windowed = TRUE;
            		ps.SwapEffect = D3DSWAPEFFECT_DISCARD;
            		ps.BackBufferFormat = D3DFMT_UNKNOWN;

            		pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL
            			, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &ps, &g_pD3dDevice);
            		if(g_pD3dDevice == NULL) break;


            		LPDIRECT3DDEVICE9 pNewD3dDevice = NULL;
            		pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL
            			, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &ps, &pNewD3dDevice);

            創(chuàng)建了2個(gè)IDirect3DDevice9對(duì)象， 然后分別打印它們的虛表指針和內(nèi)容：

            0:000> ?? g_pD3dDevice
            struct IDirect3DDevice9 * 0x02815c00
               +0x000 __VFN_table : 0x0281899c 
            0:000> ?? pNewD3dDevice
            struct IDirect3DDevice9 * 0x0241bfe0
               +0x000 __VFN_table : 0x0241ed7c 
            0:000> dps 0x0281899c 
            0281899c  6fe56f19 d3d9!CBaseDevice::QueryInterface
            028189a0  6fe56992 d3d9!CBaseDevice::AddRef
            028189a4  6fe56969 d3d9!CBaseDevice::Release
            028189a8  6fe72587 d3d9!CBaseDevice::TestCooperativeLevel
            028189ac  6ff0c6ad d3d9!CBaseDevice::GetAvailableTextureMem
            028189b0  6ff49c8f d3d9!CD3DBase::EvictManagedResources
            028189b4  6fe6b1c5 d3d9!CBaseDevice::GetDirect3D
            028189b8  6fe56ff8 d3d9!CBaseDevice::GetDeviceCaps
            028189bc  6fe8d144 d3d9!CBaseDevice::GetDisplayMode
            028189c0  6fe7084e d3d9!CBaseDevice::GetCreationParameters
            028189c4  6ff0bb74 d3d9!CBaseDevice::SetCursorProperties
            028189c8  6ff0c04d d3d9!CBaseDevice::SetCursorPosition
            028189cc  6fe8def0 d3d9!CBaseDevice::ShowCursor
            028189d0  6fe6e9a0 d3d9!CBaseDevice::CreateAdditionalSwapChain
            028189d4  6fe69ac7 d3d9!CBaseDevice::GetSwapChain
            028189d8  6fe993ca d3d9!CBaseDevice::GetNumberOfSwapChains
            028189dc  6feaf251 d3d9!CBaseDevice::Reset
            028189e0  6fe9a064 d3d9!CBaseDevice::Present
            028189e4  6feb1418 d3d9!CBaseDevice::GetBackBuffer
            028189e8  6fe6bfe9 d3d9!CBaseDevice::GetRasterStatus
            028189ec  6ff0c139 d3d9!CBaseDevice::SetDialogBoxMode
            028189f0  6ff0c3bf d3d9!CBaseDevice::SetGammaRamp
            028189f4  6ff0c4fd d3d9!CBaseDevice::GetGammaRamp
            028189f8  6fe85ddb d3d9!CBaseDevice::CreateTexture
            028189fc  6ff0ca68 d3d9!CBaseDevice::CreateVolumeTexture
            02818a00  6feacb2d d3d9!CBaseDevice::CreateCubeTexture
            02818a04  6fe72d69 d3d9!CBaseDevice::CreateVertexBuffer
            02818a08  6fe732e6 d3d9!CBaseDevice::CreateIndexBuffer
            02818a0c  6fea0127 d3d9!CBaseDevice::CreateRenderTarget
            02818a10  6ff0cd88 d3d9!CBaseDevice::CreateDepthStencilSurface
            02818a14  6ff0e0e0 d3d9!CBaseDevice::UpdateSurface
            02818a18  6fe846ab d3d9!CBaseDevice::UpdateTexture
            0:000> dps 0x0241ed7c 
            0241ed7c  6fe56f19 d3d9!CBaseDevice::QueryInterface
            0241ed80  6fe56992 d3d9!CBaseDevice::AddRef
            0241ed84  6fe56969 d3d9!CBaseDevice::Release
            0241ed88  6fe72587 d3d9!CBaseDevice::TestCooperativeLevel
            0241ed8c  6ff0c6ad d3d9!CBaseDevice::GetAvailableTextureMem
            0241ed90  6ff49c8f d3d9!CD3DBase::EvictManagedResources
            0241ed94  6fe6b1c5 d3d9!CBaseDevice::GetDirect3D
            0241ed98  6fe56ff8 d3d9!CBaseDevice::GetDeviceCaps
            0241ed9c  6fe8d144 d3d9!CBaseDevice::GetDisplayMode
            0241eda0  6fe7084e d3d9!CBaseDevice::GetCreationParameters
            0241eda4  6ff0bb74 d3d9!CBaseDevice::SetCursorProperties
            0241eda8  6ff0c04d d3d9!CBaseDevice::SetCursorPosition
            0241edac  6fe8def0 d3d9!CBaseDevice::ShowCursor
            0241edb0  6fe6e9a0 d3d9!CBaseDevice::CreateAdditionalSwapChain
            0241edb4  6fe69ac7 d3d9!CBaseDevice::GetSwapChain
            0241edb8  6fe993ca d3d9!CBaseDevice::GetNumberOfSwapChains
            0241edbc  6feaf251 d3d9!CBaseDevice::Reset
            0241edc0  6fe9a064 d3d9!CBaseDevice::Present
            0241edc4  6feb1418 d3d9!CBaseDevice::GetBackBuffer
            0241edc8  6fe6bfe9 d3d9!CBaseDevice::GetRasterStatus
            0241edcc  6ff0c139 d3d9!CBaseDevice::SetDialogBoxMode
            0241edd0  6ff0c3bf d3d9!CBaseDevice::SetGammaRamp
            0241edd4  6ff0c4fd d3d9!CBaseDevice::GetGammaRamp
            0241edd8  6fe85ddb d3d9!CBaseDevice::CreateTexture
            0241eddc  6ff0ca68 d3d9!CBaseDevice::CreateVolumeTexture
            0241ede0  6feacb2d d3d9!CBaseDevice::CreateCubeTexture
            0241ede4  6fe72d69 d3d9!CBaseDevice::CreateVertexBuffer
            0241ede8  6fe732e6 d3d9!CBaseDevice::CreateIndexBuffer
            0241edec  6fea0127 d3d9!CBaseDevice::CreateRenderTarget
            0241edf0  6ff0cd88 d3d9!CBaseDevice::CreateDepthStencilSurface
            0241edf4  6ff0e0e0 d3d9!CBaseDevice::UpdateSurface
            0241edf8  6fe846ab d3d9!CBaseDevice::UpdateTexture

            可以看到g_pD3dDevice的虛表地址是0x0281899c, pNewD3dDevice的虛表地址是0x0241ed7c，他們各自擁有自己虛表，盡管虛表里的內(nèi)容是一樣。如果你改變第一個(gè)對(duì)象的虛表內(nèi)容，理論上不會(huì)影響第二個(gè)對(duì)象。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2014-06-23 14:36 | allen
            
				
            @Richard Wei

            哦，之前理解錯(cuò)了。
            應(yīng)該說，我hook的不是虛表，而是hook的虛表里面函數(shù)指針指向的函數(shù)。  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2016-08-18 20:09 | 陳利敏
            
				
            博主，我現(xiàn)在遇到一個(gè)問題，對(duì)于不同游戲，有的能Hook到createdevice函數(shù)，進(jìn)入自定義的createdevice函數(shù)，但是有的游戲不行，不知道博主有沒有遇到過，能否給予幫助，我的代碼來源http://bbs.pediy.com/showthread.php?t=85368  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	
		
            
			
            # re: HOOK技術(shù)的一些簡單總結(jié)
            
			
            
				2016-08-19 12:23 | Richard Wei
            
				
            @陳利敏
            可以用先用API Monitor 或者WinDbg的API斷點(diǎn)看看對(duì)方程序是如何工作的  回復(fù)  更多評(píng)論
              
            
			
            
			
			
		
            
	








            






            

				

            


    
    







            
	   
	



伊人久久成人成综合网222|
婷婷久久精品国产|
久久99热这里只频精品6|
亚洲欧美精品伊人久久|
欧美亚洲色综久久精品国产|
久久精品国产99久久香蕉|
中文字幕亚洲综合久久|
996久久国产精品线观看|
久久久久久无码Av成人影院|
亚洲v国产v天堂a无码久久|
久久久久久亚洲精品不卡|
精品国产乱码久久久久久浪潮|
国产激情久久久久影院老熟女免费|
潮喷大喷水系列无码久久精品|
久久久久人妻一区二区三区vr|
亚洲狠狠婷婷综合久久蜜芽
|
久久精品女人天堂AV麻|
精品久久久久久无码中文野结衣|
国内精品久久久久久野外|
国产亚洲欧美成人久久片|
精品久久一区二区|
99久久国产亚洲高清观看2024
|
精品久久久久久久国产潘金莲|
欧美日韩精品久久久久|
欧美精品丝袜久久久中文字幕
|
亚洲国产成人久久综合一|
色综合久久久久网|
国产伊人久久|
久久久久国产亚洲AV麻豆|
一本久久综合亚洲鲁鲁五月天|
免费一级欧美大片久久网|
久久伊人精品一区二区三区|
久久精品国产亚洲AV无码娇色
|
午夜精品久久久久|
无遮挡粉嫩小泬久久久久久久|
久久香综合精品久久伊人|
青青草国产精品久久|
欧美激情精品久久久久久久九九九
|
国产精品99久久久精品无码|
久久一日本道色综合久久|
91精品国产综合久久香蕉|