眼見爲虛--解析映像劫持技術

一. 詭異的中毒現象

在成品檢驗科文員辦公室的一臺電腦上折騰半個小時後,計算機維護部門的技術員只覺得眼皮不停狂跳,因爲從剛開始接手這個任務開始,他就一直在做無用功:他隨身帶的U盤裏引以爲豪的衆多維護工具包在這臺機器上全軍覆沒,無論他直接在U盤上運行還是隨便軟件後,他像一個賊似的趕緊離開了辦公室,生怕多呆一會兒就會惹來什麼麻煩似的,而他卻不知道,“麻煩”早已在他剛纔使用的U盤上安家了。回到自己的電腦前,他剛右鍵點擊U盤,就看見鼠標忙碌的狀態比平時久了點,然後托盤區裏的殺毒軟件和網絡防火牆都消失了,他心裏一慌張,趕緊運行超級巡警,系統卻報告“找不到文件”,他一下子呆在了電腦前:瘟神跟上門來了……

古語云:道高一尺,魔高一丈。這句經典哲理在網絡上得到了迅速的延伸應用。今年初,一種早已有之的系統調試功能被應用到病毒技術上,從而搖身一變成爲惡魔的代言人,普通用戶很快就面臨了一場莫名其妙的病毒災難,這就是“映像劫持”。

二. 我本將心向明月,奈何明月照……

“映像劫持”,也被稱爲“IFEO”(Image File Execution Options,其實應該稱爲“Image Hijack”,後面章節會詳細提到,至少也應該稱爲IFEO Hijack而不是隻有“IFEO”自身!),它的存在自然有它的理由,在WindowsNT架構的系統裏,IFEO的本意是爲一些在默認系統環境中運行時可能引發錯誤的程序執行體提供特殊的環境設定,系統廠商之所以會這麼做,是有一定歷史原因的,在Windows NT時代,系統使用一種早期的堆(Heap,由應用程序管理的內存區域)管理機制,使得一些程序的運行機制與現在的不同,而後隨着系統更新換代,廠商修改了系統的堆管理機制,通過引入動態內存分配方案,讓程序對內存的佔用更爲減少,在安全上也保護程序不容易被溢出,但是這些改動卻導致了一些程序從此再也無法運作,爲了兼顧這些出問題的程序,微軟以“從長計議”的態度專門設計了“IFEO”技術,它的原意根本不是“劫持”,而是“映像文件執行參數”!

IFEO設定了一些與堆分配有關的參數,當一個可執行程序位於IFEO的控制中時,它的內存分配則根據該程序的參數來設定,那麼如何使一個可執行程序位於IFEO的控制中呢?答案很簡單,Windows NT架構的系統爲用戶預留了一個交互接口,位於註冊表的“HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options”內,使用與可執行程序文件名匹配的項目作爲程序載入時的控制依據,最終得以設定一個程序的堆管理機制和一些輔助機制等,大概微軟考慮到加入路徑控制會造成判斷麻煩與操作不靈活的後果,也容易導致註冊表冗餘,於是IFEO使用忽略路徑的方式來匹配它所要控制的程序文件名,例如IFEO指定了對一個名爲“小金.EXE”的可執行程序文件進行控制,那麼無論它在哪個目錄下,只要它名字還叫“小金.EXE”,它就只能在IFEO的五指山裏打滾了。

說了半天都只是純粹的概念,那麼IFEO到底是怎麼樣發揮作用的呢?例如有一個程序文件名爲“lk007.exe”,由於使用了舊的堆管理機制,它在新系統裏無法正常運行甚至出現非法操作,爲了讓系統爲其提供舊的堆管理機制,我們需要IFEO來介入,則需執行以下步驟:

1、確保在管理員狀態下執行regedit.exe,定位到以下註冊表項:

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options

2、 在“Image File Execution Options”下建立一個子鍵,名爲“lk007.exe”,不區分大小寫。現在確保位於HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/lk007.exe/下,建立一個字符串類型的註冊表項,名爲“DisableHeapLookAside”,值爲“1”

3、再次運行lk007.exe查看運行情況,如果真的是由於堆管理機制引發的問題,則程序得以正常運行,否則該程序問題不屬於IFEO能夠干涉的範圍,或者需要嘗試搭配其他的參數使用。

目前已知的IFEO參數有:

ApplicationGoo

Debugger

PageHeapFlags

DisableHeapLookAside

DebugProcessHeapOnly

PageHeapSizeRangeStart

PageHeapSizeRangeEnd

PageHeapRandomProbability

PageHeapDllRangeStart

PageHeapDllRangeEnd

GlobalFlag

BreakOnDllLoad

ShutdownFlags

說白了,IFEO本質是系統廠商爲某些可能以早期設計模式運行的軟件提供一種保全措施而設計出來的產物,並對其加以擴充形成了一套可用於調試程序的簡易方案,如“BreakOnDllLoad”參數可設定在載入某個DLL時設置斷點,便於程序員調試ISAPI接口;帶有“Range”字樣的幾個參數則用於限制堆的大小等。

而裏面有一個導致了今天這種局面的參數:Debugger。或許微軟當初的用意是便於程序員能夠通過雙擊某個設置了IFEO控制列表的執行體文件來直接調用調試器對其進行調試,而不用再通過繁瑣的打開調試器再進行文件載入來實現調試,提高了工作效率。

爲了使得IFEO能夠影響到任何一個程序啓動請求,NT架構中將IFEO的優先權設置得很高,基本上,當用戶要求執行某個程序時,系統首先判斷該程序文件是否可執行體,然後就到IFEO的入口項進行文件名配對了,直到通過IFEO這一步後,進程才真正開始申請內存創建起來。

如果系統在IFEO程序列表裏匹配了當前運行的文件名,它就會讀取文件名下的參數,這些參數在未被人爲設置之前均有個默認值,而且它們也具備優先權,“Debugger”的優先權是最高的,所以它是第一個被讀取的參數,如果該參數未被設置,則默認不作處理,如果設置了這個參數,情況就變得複雜了……

三. 罪魁禍首“Debugger”

前面一章裏大家應該都瞭解IFEO的本質了,從實際現象來說,把IFEO直接稱爲“映像劫持”未免有點冤枉它了,因爲裏面大部分參數並不會導致今天這種局面的發生,惹禍的參數只有一個,那就是“Debugger”,將IFEO視爲映像劫持,大概是因爲國內一些人直接套用了“Image File Execution Options”的縮寫罷,在相對規範的來自Sysinternals的專業術語裏,利用這個技術的設計漏洞進行非法活動的行爲應該被稱爲“Image Hijack”,這纔是真正字面上的“映像劫持”!

Debugger參數,直接翻譯爲“調試器”,它是IFEO裏第一個被處理的參數,其作用是屬於比較匪夷所思的,系統如果發現某個程序文件在IFEO列表中,它就會首先來讀取Debugger參數,如果該參數不爲空,系統則會把Debugger參數裏指定的程序文件名作爲用戶試圖啓動的程序執行請求來處理,而僅僅把用戶試圖啓動的程序作爲Debugger參數裏指定的程序文件名的參數發送過去!光是這個概念大概就足夠一部分人無法理解了,所以我們放簡單點說,例如有兩個客人在一起吃自助餐,其中一個客人(用戶)委託另一個客人(系統)去拿食物時順便幫自己帶點食物回來(啓動程序的請求),可是系統在幫用戶裝了一盤子食物並打算回來時卻發現另一桌上有個客人(Debugger參數指定的程序文件)居然是自己小學裏的暗戀對象!於是系統直接端着原本要拿給用戶的食物放到那桌客人那裏共同回憶往事去了(將啓動程序請求的執行文件映像名和最初參數組合轉換成新的命令行參數……),最終吃到食物的自然就是Debugger客人(獲得命令行參數),至此係統就忙着執行Debugger客人的啓動程序請求而把發出最初始啓動程序請求的用戶和那盤食物(都送給Debugger客人做命令行參數了)給遺忘了。

在系統執行的邏輯裏,這就意味着,當一個設置了IFEO項Debugger參數指定爲“notepad.exe”的“iexplore.exe”被用戶以命令行參數“-nohome bbs.nettf.net”請求執行時,系統實際上到了IFEO那裏就跑去執行notepad.exe了,而原來收到的執行請求的文件名和參數則被轉化爲整個命令行參數“C:/Program Files/Internet Explorer/IEXPLORE.EXE - nohome bbs.nettf.net”來提交給notepad.exe執行,所以最終執行的是“notepad.exe C:/Program Files/Internet Explorer/IEXPLORE.EXE - nohome bbs.nettf.net”,即用戶原來要執行的程序文件名iexplore.exe被替換爲notepad.exe,而原來的整串命令行加上iexplore.exe自身,都被作爲新的命令行參數發送到notepad.exe去執行了,所以用戶最終看到的是記事本的界面,並可能出現兩種情況,一是記事本把整個iexplore.exe都作爲文本讀了出來,二是記事本彈出錯誤信息報告“文件名不正確”,這取決於iexplore.exe原來是作爲光桿司令狀態請求執行(無附帶運行命令行參數)的還是帶命令行參數執行的。

Debugger參數存在的本意是爲了讓程序員能夠通過雙擊程序文件直接進入調試器裏調試自己的程序,曾經調試過程序的朋友也許會有一個疑問,既然程序啓動時都要經過IFEO這一步,那麼在調試器裏點擊啓動剛被Debugger參數送進來的程序時豈不是又會因爲這個法則的存在而導致再次產生一個調試器進程?微軟並不是傻子,他們理所當然的考慮到了這一點,因此一個程序啓動時是否會調用到IFEO規則取決於它是否“從命令行調用”的,那麼“從命令行調用”該怎麼理解呢?例如我們在命令提示符裏執行taskmgr.exe,這就是一個典型的“從命令行調用”的執行請求,而我們在點擊桌面上、普通應用程序菜單裏的taskmgr.exe時,系統都會將其視爲由外殼程序Explorer.exe傳遞過來的執行請求,這樣一來,它也屬於“從命令行調用”的範圍而觸發IFEO規則了。爲了與用戶操作區分開來,系統自身加載的程序、調試器裏啓動的程序,它們就不屬於“從命令行調用”的範圍,從而繞開了IFEO,避免了這個加載過程無休止的循環下去。

從編程角度來說明“命令行調用”,那就是取決於啓動程序時CreateProcess是使用lpCommandLine(命令行)還是lpApplicationName(程序文件名)來執行,默認情況下大部分程序員編寫的調用習慣是lpCommandLine——命令行調用

BOOL CreateProcess

(

LPCTSTR lpApplicationName,

LPTSTR lpCommandLine,

LPSECURITY_ATTRIBUTES lpProcessAttributes。

LPSECURITY_ATTRIBUTES lpThreadAttributes,

BOOL bInheritHandles,

DWORD dwCreationFlags,

LPVOID lpEnvironment,

LPCTSTR lpCurrentDirectory,

LPSTARTUPINFO lpStartupInfo,

LPPROCESS_INFORMATION lpProcessInformation

);

由於Debugger參數的這種特殊作用,它又被稱爲“重定向”(Redirection),而利用它進行的攻擊,又被稱爲“重定向劫持”(Redirection Hijack),它和“映像劫持”(Image Hijack,或IFEO Hijack)只是稱呼不同,實際上都是一樣的技術手段。

講解完Debugger參數的作用,現在我們來看看“映像劫持”到底是怎麼一回事,遭遇流行“映像劫持”病毒的系統表現爲常見的殺毒軟件、防火牆、安全檢測工具等均提示“找不到文件”或執行了沒有反應,於是大部分用戶只能去重裝系統了,但是有經驗或者歪打正着的用戶將這個程序改了個名字,就發現它又能正常運行了,這是爲什麼?答案就是IFEO被人爲設置了針對這些流行工具的可執行文件名的列表了,而且Debugger參數指向不存在的文件甚至病毒本身!

以超級巡警的主要執行文件AST.exe爲例,首先,有個文件名爲kkk.exe的惡意程序向IFEO列表裏寫入AST.exe項,並設置其Debugger指向kkk.exe,於是系統就會認爲kkk.exe是AST.exe的調試器,這樣每次用戶點擊執行AST.exe時,系統執行的實際上是作爲調試器身份的kkk.exe,至於本該被執行的AST.exe,此刻只能被當作kkk.exe的執行參數來傳遞而已,而由於kkk.exe不是調試器性質的程序,甚至惡意程序作者都沒有編寫執行參數的處理代碼,所以被啓動的永遠只有kkk.exe自己一個,用戶每次點擊那些“打不開”的安全工具,實際上就等於又執行了一次惡意程序本體!這個招數被廣大使用“映像劫持”技術的惡意軟件所青睞,隨着OSO這款超級U盤病毒與AV終結者(隨機數病毒、8位字母病毒)這兩個滅殺了大部分流行安全工具和殺毒軟件的惡意程序肆虐網絡以後,一時之間全國上下人心惶惶,其實它們最大改進的技術核心就是利用IFEO把自己設置爲各種流行安全工具的調試器罷了,破解之道尤其簡單,只需要將安全工具的執行文件隨便改個名字,而這個安全工具又不在乎互斥量的存在,那麼它就能正常運行了,除非你運氣太好又改到另一個也處於黑名單內的文件名去了,例如把AST.exe改爲IceSword.exe。

小知識:互斥量

爲了預防用戶簡單的更改一個文件名就使得大部分安全工具破籠而出,一些木馬還同時採用了一種被稱爲“互斥量”的技術來徹底阻止安全工具運行。在系統裏,有一類特殊的系統對象被稱爲“互斥量”(Mutex),它們的存在是爲了減少系統開銷而設,例如一些工具在運行時會檢測是否已經有另一個自己的副本在運行,要做這種檢測最有效率的方法就是在第一次運行時創建一個互斥量,以後再運行時檢測即可,這實際上是很簡單的方法,因爲系統會爲我們保存已經創建的互斥量,直到程序請求銷燬互斥量,否則它將一直存在。這樣一來,問題又出現了,如果惡意程序掌握了一些安全工具的互斥量並僞造呢?這些安全工具就會因爲檢測到“自身已經運行”而放棄繼續執行的權利,惡意程序就沒有剋星了。

而那些雙擊時明明程序文件就在眼前,系統卻報錯說“找不到文件”,又是什麼回事呢?這也是IFEO的另一種應用罷了,其祕訣是將Debugger參數指向一個不存在的文件位置,這樣系統就會因爲找不到這個調試器而無法順利執行下去,如果系統老老實實報出“找不到調試器”的錯誤提示那倒還好了,但就不知道微軟是出於對IFEO這個東西存在的事實掩蓋還是什麼苦衷,卻死活不肯承認是Debugger指向的調試器不存在導致的錯誤,而是把已經被“變異”成爲命令行參數無法進入系統創建進程機制的原執行請求作爲“找不到的文件”給報了回去,於是未曾瞭解過IFEO的用戶只能莫名其妙的看着眼前就存在而系統“不承認”的安全工具發愣了。

四. 防範“映像劫持”

好了,前面說了這麼多,大概又嚇得一批人開始冒冷汗了吧,我們現在就來學習如何防範和破解“映像劫持”。

判斷你的機器是否被劫持

最簡單的方法是逐個運行你常用的安全工具,檢查是否出現“無法找到文件”或者乾脆直接沒了反應的,當然,執行結果和預期差別太大的也要被懷疑爲劫持,例如你執行IceSword.exe反而是你的QQ運行了,那就不必我多說了。

其實只要註冊表編輯器regedit.exe、regedt32.exe沒有被劫持,那我們直接用它進入“HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options”這個註冊表項並展開裏面的子項列表一個個看下來確認是否出現Debugger參數或其他可能影響程序運行的堆管理參數,便可得知機器是否被劫持。

如果註冊表編輯器被劫持了怎麼辦?直接改個名就能用了啊……

更簡單的方法,是使用Sysinternals的Autoruns,點擊它的“Image Hijacks”選項卡,即可看到被劫持的程序項了。

追查劫持來源

如果不幸你的機器上已經成爲“映像劫持”的受害者,請記錄好Debugger指向的程序位置,也不要試圖再執行那些安全工具,首先應該嘗試刪除受影響的IFEO項,然後刷新註冊表看看數據是否馬上恢復了,如果馬上恢復,則說明後臺裏有程序正在實時判斷和寫入IFEO,這時候必須拿出Sysinternals出品的註冊表監控工具Regmon或類似工具,設置Filter爲你正在嘗試刪除的安全工具的IFEO項,很快就能發現具體是什麼進程在操作註冊表了,然後將IceSword改名(如果已經被劫持),在它的進程列表裏將相應進程終止掉。如果這個進程立即又重生了呢?再終止一次,然後迅速點擊IceSword的“監視進線程創建”,你就能發現上一次搗亂的程序是什麼名字了,將它記錄下來,再開啓一個Sysinternals的工具“Process Explorer”,在對應進程上點擊右鍵選擇“Suspend”,這個進程就會被掛起,用IceSword和它配合把相關惡意進程都掛起後,再使用IceSword的文件功能裏的“強制刪除”,在這個程序還沒來得及反應時就把它們的本體給殲滅,這時候再返回Process Explorer裏按照大小排列從最大的一個守護進程開始Kill Process即可,由於沒有了映像文件存在,它們意欲重新建立木馬帝國的賊心也就無法實現了。

如果查殺過程更爲複雜的話,請自行參閱相關文章,這裏就不再贅述了。

如此實現“免疫”?不被推薦的做法

由於AV終結者搞得人心惶惶,一時間網絡上開始流傳“免疫映像劫持”甚至“利用映像劫持免疫大部分常見病毒”的做法,對於這些方法的最初提供者,我相信他們的出發點是好的,只是,從嚴格的角度來看,這卻是不可取的。

首先是“免疫映像劫持”,具體的方法是,例如免疫威金病毒“logo_1.exe”,則在IFEO列表裏建立一個“logo_1.exe”項,然後設定它的Debugger參數爲它自身即“logo_1.exe”,根據原作者解釋,其原理是遞歸死循環:“當Debugger的值等於本身時,就是調用自身來調試自己,結果自己不是調試器,又來一次,遞歸了,就進入了死循環,也就不能啓動了。”

這種方法雖然有效(最後的現象是“找不到文件”),但是它會導致系統在短時間內陷入一個CreateProcess循環和命令參數的字符串累加狀態,會消耗一定的資源,最終沒能執行程序是因爲系統使用CreateProcess啓動的實例會被它自身代替執行,從而造成死循環,而且命令行的長度是有系統限制的,到一定範圍就會出錯了,尤其在可以接受命令行參數的程序裏,你甚至會發現硬盤狂轉了好一會兒才彈出錯誤提示,這段時間裏就是在死循環傳遞狀態了,最終由於超過系統限制的命令行長度而導致系統傳遞執行請求時出錯,才得以跳出這個死循環,換一個角度來看,如果系統沒有限制命令行長度,那麼這個操作很可能直接導致系統所有資源都消耗在這個自己反覆執行自己的“調試器”上了。

至於“利用映像劫持免疫大部分常見病毒”的做法,發起號召者模仿“映像劫持”後門屏蔽大部分常用安全工具的原理,蒐集了許多流行危害程序的可執行文件名加以前面提到的遞歸死循環方法達到目的,如果不計較前面提到的遞歸死循環缺點,似乎這個方法是可行的。

然而這真的可行嗎?世界上存在許多與某些系統文件同名同姓的社交型後門,如位置不同而名字相同的命令提示符輸入法控制程序“conime.exe”(被OSO超級U盤病毒借用名字)、重要程序Rundll32.exe被某些木馬替換爲自身、甚至IE瀏覽器主體iexplore.exe也存在被木馬僞造文件名的案例,如此一來不知道多少正常的系統程序可能會被這份“免疫列表”給誤殺了,我僅僅粗略瀏覽了一下就發現msiexec.exe居然存在“免疫列表”中,要知道這可是微軟安裝程序的主執行體啊……

爭議話題:是否禁止IFEO列表權限?

同時,網上還流傳着一個讓初級用戶看不懂的做法,那就是關閉IFEO列表的寫入權限,具體操作如下:

• 執行32位註冊表編輯器regedt32.exe

• 定位到HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options

• 確保焦點在Image File Execution Options上,選擇“安全”—“權限”

• 將出現的用戶列表內所有帶有“寫入”的權限去掉,確定退出

這樣一來,任何對IFEO的寫入操作都失效了,也就起了免疫效果。這個方法對一般用戶而言還是不錯的,除非遭遇到一些特殊的需要往裏面寫入堆管理參數的程序,否則我建議一般用戶還是禁止此項,從而杜絕一切IFEO類病毒來襲。

而爭議正在於此,因爲從長計議來看,用戶很可能會遇到需要往IFEO列表裏寫入數據的正常程序,徹底禁止了IFEO的寫入可能會導致不可預見的後果,既然如此,我們就採取折中的方法好了,使用HIPS(主機入侵防禦系統)的註冊表防禦體系RD(Registry Defend),爲我們提供一種兩者都能兼顧的IFEO管理方法!

以SSM爲例,首先確保RD體系模塊已經開啓,然後添加新監視規則,“鍵路徑”指向HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options,“操作”爲“當更改時報警”,記得“包含值”選上,最後把“子鍵深度最大值”設爲“3”,點擊確定生成新的監視規則,然後在“規則”主界面裏確保“存取”、“刪除”、“寫入”的操作均爲疑問狀態,這是表示在相關鍵值被進行寫入操作時彈出消息詢問用戶,最後點擊“應用設定”讓規則生效,從此只需開着SSM,映像劫持就離你遠去了。

五. 千篇一律的結語

道高一尺,魔高一丈,當幾乎所有可能利用的啓動項都被安全工具翻了個遍以後,與安全對立的技術也就不得不往上提高一個檔次,於是無論什麼歪門邪道的招數,只要能夠被利用,哪怕它原意是好的,也會被改寫定義,從這次的映像劫持事件可以看出,這個系統遠遠不如我們想像中那麼容易被掌握,尤其對普通用戶而言,這次技術的誤用簡直是他們的滅頂之災!在安全技術與反安全技術鬥爭激烈的今天,我們用戶越來越有在夾縫中生存的感覺了,當年輕鬆就可以得到的隨便開多少個網頁都不會帶來一個病毒的日子早已遠去,要想在這個瘋狂的世界裏得以保全,我們只能藉助於各種工具的守護,和學習更多本來可以不用接觸的安全知識,難道這真的要變成互聯網的生存法則嗎?

=================================

後記:

發現一個有趣的現象,在百度上搜索映像劫持,會得到一堆結果返回的網頁裏都有這麼一句話:

映像劫持原理:

Windows NT系統在執行一個從命令行調用的可執行文件運行請求時,首先會檢查這是否是一個可執行文件,如果是,又是什麼格式的,然後就會檢查是否存在。

這段話看着是不是莫名其妙?沒頭沒尾的,經過我耐心查找,終於在一個角落找到了原始出處,感謝tombkeeper的撰文(節選):

Windows NT系統在執行一個從命令行調用的可執行文件運行請求時,首先會檢查這是否是一個可執行文件,如果是,又是什麼格式的,然後就會檢查是否存在:

[HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/ImageName]

如果存在,首先會試圖讀取這個鍵值:

[HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/ImageName]

"Debugger"="debug_prog"

如果存在,就執行“debug_prog ImageName”

很明顯,被流傳的“原理”來自tombkeeper的某篇文章中的前一段,或許抄襲者不明白後面接着的註冊表鍵值是什麼意思,有什麼重要作用,就想當然的截斷了,於是,這篇抄襲不完整的斷章取義文章經過一傳十,十傳百的散播途徑後,終於成爲了鋪天蓋地的“真理”,也難怪那麼多人對IFEO感覺很好奇,因爲光看那些大部分文章都是隻有這麼一段的,不信大家可以找找“IFEO”關鍵字,看看裏面對“原理”的描述,真無語了,哎……

===========================================================================

冷漠 PS:附一款映像劫持的工具,網上找的;

映像劫持器

在windowsXP下的,功能嘛,就是映像劫持

使用方法;

假設在原文件裏填:regedit.exe

在劫持爲裏填:C:/WINDOWS/NOTEPAD.EXE

再點劫持就可以了,

效果是打開註冊表時,打開的不是註冊表而是記事本.

映像劫持的定義

所謂的映像劫持(IFEO)就是Image File Execution Options,位於註冊表的HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options由於這個項主要是用來調試程序用的,對一般用戶意義不大。默認是隻有管理員和local system有權讀寫修改。通俗一點來說,就是比如我想運行QQ.exe,結果運行的卻是FlashGet.exe,也就是說在這種情況下,QQ程序被FLASHGET給劫持了,即你想運行的程序被另外一個程序代替了。

const CString CFunction::debugger1 = "SOFTWARE//Microsoft//Windows NT//CurrentVersion//Image File Execution Options//";

void CDebuggerDlg::OnRob()

{

     // TODO: Add your control notification handler code here

     UpdateData(TRUE);

     HKEY hKey ;

     //     MessageBox(CFunction::debugger1+m_exename);

     RegCreateKey(

         HKEY_LOCAL_MACHINE,         // handle to open key

         CFunction::debugger1+m_exename, // name of subkey to open

         &hKey   // handle to open key

         );

     RegSetValueEx(

         hKey,           // handle to key

         "debugger", // value name

         0,       // reserved

         REG_SZ,         // value type

         //(const BYTE *) &m_value,   // value data

         (const BYTE *) m_exepath.GetBuffer(m_exepath.GetLength()),

         m_exepath.GetLength()         // size of value data

         );

     UpdateData(FALSE);

}

void CDebuggerDlg::OnUnrob()

{

     // TODO: Add your control notification handler code here

     UpdateData(TRUE);

     //MessageBox(temp);

     RegDeleteKey(HKEY_LOCAL_MACHINE, CFunction::debugger1+m_exename);

     UpdateData(FALSE);

}

void CDebuggerDlg::OnChoice()

{

     // TODO: Add your control notification handler code here

     UpdateData (TRUE);

     CFileDialog dlg(TRUE);

     if(dlg.DoModal () == IDOK)

     {

         m_exepath=dlg.GetPathName ();

     }

     UpdateData (FALSE);

}

發佈了31 篇原創文章 · 獲贊 0 · 訪問量 3萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章