powertool 使用学习总结
生活随笔
收集整理的這篇文章主要介紹了
powertool 使用学习总结
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
簡介?
PowerTool是一款免費的系統分析，手動殺毒工具。這款內核級的手動殺毒輔助工具，能幫助你找出病毒
木馬在你的電腦中動過的手腳，并去除病毒設下的機關。目前具備以下功能：系統修復、進程管理、內
核模塊、內核相關、鉤子、應用層、文件、注冊表、離線分析、啟動項、系統服務、網絡鏈接、漏洞修
復等。 ??
PowerTool 的特色在于它能夠獲取較高權限，從而執行一些底層的系統維護操作，如常用的強制結束進
程、強制刪除文件、強制編輯注冊表、強制刪除系統服務等等。作為內核級手動殺毒輔助工具，
PowerTool 與 PCHunter不相上下，PowerTool 在某些方面提供的功能還要多些，處理速度蠻快。
適用系統環境：Windows PE / 安全模式 / Windows XP / Windows 2003 Server / Vista / Windows?
2008 Server / Windows 7 / Windows 8 / Windows 8.1 / Windows 10 RTM / Windows 10 build 10586
========
如何使用PowerTool 20秒手動清除鬼影3病毒
“鬼影”系列病毒的共同特點是感染電腦硬盤的主引導記錄（MBR），無論重裝系統或是格式化硬盤都無
法清除病毒。
“鬼影”系列病毒的共同特點是感染電腦硬盤的主引導記錄（MBR），無論重裝系統或是格式化硬盤都無
法清除病毒。在查殺前兩代“鬼影”時，不同廠商推出的專殺工具都會首先修復MBR，然后再全面掃描清
除病毒殘骸，然而這個方法在查殺“鬼影3”時卻遇到了難題。據分析，“鬼影3”病毒之所以非常頑固
，原因在于它釋放了一個惡意驅動作為“保鏢”，用來禁止任何修復MBR的操作。對殺毒軟件來說，不清
除“保鏢”驅動就無法修復MBR，不修復MBR又無法清除“保鏢”驅動，從而陷入“鬼影3”怎么都殺不干
凈的死循環中。
年初的時候我寫過一篇20秒手殺鬼影的教程，斗轉星移，病毒的作者精益求精，前段時間，已更新到鬼
影3代了。
不過正所謂魔高一尺，道高一丈，邪還是不能勝正的，現在也有一些鬼影3的專殺工具了，不過為了知其
所以然，我寫一下如何用PowerTool的3.8版來手刃鬼影3病毒~~~
PowerTool 頑固文件清除文件下載地址為：www.jb51.net/softs/25378.html
第一步
看一下鬼影3都干了那些壞事，我們才能夠做到有的放矢
1. 鬼影3的進程
2. 鬼影3的文件
3. 鬼影3的流氓快捷方式
?
4. 鬼影3的網絡連接
5. 鬼影3在內核里面的鉤子
6. 鬼影3在的其他勾當
7. 最后也是最重要的也就是鬼影3的MBR
差不多就這些了，知道了它干得勾當，自然就可以清除它了。
清除步驟：
1.結束鬼影3的進程
2.恢復隱藏的擴展名
3.刪除鬼影3的文件
4.刪除鬼影3的流氓快捷方式
5.恢復它在內核的鉤子(這一步很重要，否則無法恢復MBR)
6.恢復成正確的MBR
========
PowerTool手動清除IE自動捆綁hao123一例
http://bbs.kafan.cn/thread-1772662-1-1.html?
話說本人很少使用IE瀏覽器，但最近由于工作中某個ZF網站只支持IE才能正常顯示(奇葩的設計），不得
不又使用了一下久違的IE軟件。
打開IE后，發現自動打開了hao123頁面，確切的說是指向了：http://www.hao123.com/?
tn=91055648_hao_pg頁面。
第一反應，進入IE設置，首頁清空，重啟瀏覽器，還是這樣，繼續搜索注冊表，果然找到幾個“hao123"
的鍵值，刪除之，哈哈，簡單，重啟~
回來~嗯？怎么還是沒用？再次搜索注冊表，并未發現流氓的蹤跡，MUMM~~，
第二反應，右鍵IE快捷方式，啊哈，果然，快捷方式直接添加了流氓軟件的地址。刪除之~，重運行，還
是不行，刪除它，嗯？顯示不具備管理員權限？啥意思？這有些木馬的感覺啊~~~，重啟，F8，安全模式
刪除，哈哈，成功，小樣~~~~~
再回來~~~，嗯？？？還在？看來有模塊監視，自動創建，咋辦？上網，度了一圈，也沒辦法，卡飯一頓
，都是求助，要不就是重裝系統！這么煩？！！
咱是干啥的？折騰唄~~~
殺毒~~~~，沒用
查看啟動項~~~~，沒啥
查看進程~~~~，正常
Mummm~~~~~
突然想起了好久沒用的PowerTool,Win7下還沒用過呢，試試，先吹吹灰先~~~
打開，流氓快捷方式——無，（識別不出？），進程管理，有紅色的一個個看........，在
Explorer.exe中，發現了線程:路徑:/bangdun/product.dll,這是啥？摘除之，explorer重啟，還在！還
有鉤子？
繼續找，鉤子，內核入口，啊~又發現了這個玩意，摘除鉤子~
再次刪除一下快捷方式看看，成功啦，看來就是這東西:Bangdun!啥玩意？找到該文件目錄刪除，系統注
冊表里尋找bangdun并清理。
重啟~~~~~~哈！快捷方式不再生成了，小樣，就是一流氓軟件。
（該過程有幾天時間了，所以本文中的細節可能記得不是很完整了，今天上網看看，很多人都在問怎么
清理hao123，我這也算是一個思路吧，大家看看，殺毒記得舉一反三。 ）
========
使用PowerTool快速清除鬼影病毒
http://www.cr173.com/html/11038_1.html鬼影病毒讓人很惱火，重做系統都沒有用，當然現在已經有很多鬼影專殺工具了，不過MBR病毒不只限于
鬼影，以后遇到了類似的也可以用PowerTool清除
第一步，先查看MBR是否有異常，如果有紅色的項目，就說明MBR已經被病毒篡改了
（PT會自動確認是否有惡意代碼和MBR代碼是否被隱藏，然后顯示紅色）
第二步就是點擊自動修復來修復了：
?到此為止，確認加上恢復大概是10秒鐘吧
接下來清除鬼影留下的流氓廣告和快捷方式
（普通的刪除方法很煩瑣，PT只需一步就可刪除）
點擊修復即可，大概耗時5秒
最后，刪除鬼影遺留下來的驅動文件
也差不多5秒，
最后系統重啟即可，就可以恢復成干凈的系統了
鬼影其實還只是一個入門級別的Bootkit，以后變種可能會強一些吧
PowerTool還可以對抗隱藏MBR代碼的MBR Rootkit，
如果還無法對抗，
在dos底下修復MBR最徹底了
重置：
fdisk /mbr
fixmbr(windows恢復控制臺)
gdisk disk /mbr。
========
使用PowerTool輕松檢測魔影病毒（TDSS.TDL-4）
http://www.cr173.com/html/12812_1.html?就不過多重復了，為了保護自己的篡改的MBR，可謂是用盡可手段，
PowerTool可以在不恢復和修改TDL-4任何鉤子的情況下，
直接穿透它的防護，檢測到TDL-4 rootkit
首先，有兩個地方，大家可能以前就知道了，
一個是工作列線程
一個是StartIO的鉤子
這個以前版本的PowerTool就可以檢測到
這次加強了內核模塊的檢測，可以看到TDL-4的隱藏驅動
TDL-4還劫持了ATAPI的設備
如果以上，大家還不能確認是否是真的中了TDL-4病毒的話
最后一個，可以徹底讓它露出真面目，
在MBR里面點擊強力檢測按鈕(目前不支持AHCI/RAID/SCSI模式)
可以完全穿透TDL-4的防護，檢測到MBR
清除的話，建議大家可以用卡巴或者BitDefender的專殺工具
也可以到PE系統里面，修復MBR來清除
以后PT會進一步加強清楚的工作，呵呵
========
找下PowerTool 0.40最新版的茬 (1)
http://bbs.kafan.cn/thread-1052303-1-1.html剛看到PowerTool 0.40出正式版了，隨便找了一個測試環境看了下它的一些功能。
下面是0.40新增或改進項目的一點問題。
1、PT新版新增了調試寄存器的檢測，但是由于對調試寄存器了解不夠深入，有一些錯誤。
本來準備拿一些比較特殊的改寫調試寄存器來測試，但是一看顯示界面，大囧。
??
最新版誤將幾個DRX調試寄存器的名字寫作CRX（正確的名字應該是DR0---DR7），作者對調試寄存器的了
解還得加深。
PT遇到某個調試寄存器的值非零就提示該處可能被hook，實際上某些還原軟件也可能對它做手腳，但并
不是hook。
另外，只檢測幾個DRX的值，而沒有檢測相應的一些重要標志位，更不說一些組合方式利用調試寄存器了
。
2、PT新版加入了內核入口點的檢測，但是由于對syscall（系統調用）機制的不熟悉，會導致正常系統
出現一些誤報或者漏報。
PT不支持2000系統，就似乎默認了syscall只是某一種，只顯示KiFastCallEntry的地址。
而事實上，即使在Win 7環境下，三種syscall入口都是可能的。
這里由于PT直接將KiFastCallEntry固定為內核入口點，導致檢測不了hook。
另外，由此也導致PT的內核入口點檢測讀取錯誤的、不起作用的“入口”地址，通過交叉分析，可能得
出存在hook的結論。
3、PT新版修正了之前版本將MBR啟動代碼的16位匯編解析為32位匯編的問題。
不考慮重定位，顯示時，PT將啟動地址標為00000002，而不是00000000，總感覺怪怪的。
4、PT新版加入了woodmann論壇Kayaker的代碼，實現在Win7快速遍歷指定內核區域。
http://www.woodmann.com/forum/en ... s-space-in-Windows7
不過Kayaker的代碼只是demo性質的，存在一些問題，比如最基本的校驗，可能導致崩潰。
5、PT新版改進了網絡連接的顯示，本想測試解析IP庫是否存在問題，結果測試中出現了藍屏，所以順便
看了下網絡連接的枚舉。
Win7下的枚舉，PT使用了debugman的《WIN7下向NSI取TCP UDP信息》提供的代碼。
http://www.debugman.com/discussi ... 4%BF%A1%E6%81%AF/p1
可惜原帖給出的代碼本身存在一些問題，比如分配釋放pool的邏輯存在問題，可能導致藍屏。
一個典型的下PT在Win7枚舉網絡連接導致藍屏時的棧回溯如下：
945a7464 81c57b92 00000003 1a501172 00000000 nt!RtlpBreakWithStatusInstruction
945a74b4 81c58673 00000003 945a7940 000001ff nt!KiBugCheckDebugBreak+0x1c
945a7878 81dc91d9 000000c2 00000006 0000108e nt!KeBugCheck2+0x6a1
945a78ec 88c1bc15 945a7948 00000000 8cb300b8 nt!ExFreePoolWithTag+0x129
WARNING: Stack unwind information not available. Following frames may be wrong.
945a79a8 88c2d635 945a7a5c 945a7a50 878b3030 kEvP+0x3c15
945a7a6c 88c37dbd 878b3030 8cb300b8 0000f428 kEvP+0x15635
945a7bec 81c4311a 878b3030 8cb300b8 00000000 kEvP+0x1fdbd
945a7c0c 82118a40 8cb300b8 8cb30128 923aff38 nt!IofCallDriver+0x7e
945a7c2c 82119bd6 878b3030 923aff38 00000000 nt!IopSynchronousServiceTail+0x258
945a7cc8 82120332 00000178 8cb300b8 00000000 nt!IopXxxControlFile+0x740
945a7d04 81da8173 00000178 00000000 00000000 nt!NtDeviceIoControlFile+0x4c
945a7d04 7702a364 00000178 00000000 00000000 nt!KiFastCallEntry+0x163
001f8878 77000844 74f8e074 00000178 00000000 ntdll!KiFastSystemCallRet
001f887c 74f8e074 00000178 00000000 00000000 ntdll!NtDeviceIoControlFile+0xc
001f88dc 75c01830 00000178 002221c4 00000000 KERNELBASE!DeviceIoControl+0xee
001f8908 013e6762 00000178 002221c4 00000000 kernel32!DeviceIoControlImplementation+0x80
001ff260 00000000 00000000 00000000 00000000 PowerTool+0xa6762
404 Not Found
今天寫到這里，明天開放。
Anti-rootkit如某些大牛說的，現在越來越多人在寫了，門檻也越來越低了。但是要寫出一個優秀的ark
，不僅僅靠得是模仿和不仔細分析就增加功能，需要對系統機制的深入理解，需要作者的思考。
有感于一直以來很多人對ark的誤解（當然，不是后面PT作者所想的）和前段時間PowerTool交流群某些
人對XueTr作者的人身攻擊，主要給出了PT這次5處更新對應項目的一些問題，作為一點回應。
一點說明：
1、調試寄存器，顧名思義，這里指P3 x86下用于擴展CPU調試機制的Drx寄存器。
調試器可直接利用它實現硬件斷點（這里是內核調試器），rootkit等可以通過設置調試寄存器，可以對
指定地址的讀取、寫入、執行進行控制，達到隱藏目的。
這里PT檢測的是全局的Drx寄存器，并不是用戶態的per thread context下的drx。
舉幾個實例：
1、一些反外{過}{濾}掛驅動會修改調試寄存器，達到阻止hook被恢復等目的。
2、360還原保護器會對IO端口下硬件斷點，攔截直接IO方式的穿還原。
3、一些反外{過}{濾}掛驅動及微點主防驅動恢復hook前會清零調試寄存器，減少受干擾可能。
2、內核入口點。
這里內核入口點不夠明確，就PT檢測項目而言指的是系統調用的內核入口點。
wiki:系統調用指程序向操作系統內核請求需要更高權限運行的服務，它提供了用戶程序與操作系統之間
的接口。
Windows NT下系統調用對應的服務函數一般指的是SSDT和Shadow SSDT兩張表內的函數，很多驅動會通過
替換這些表內的函數或者改寫函數內部代碼等方法實現hook，做一些攔截、隱藏等動作。
而由用戶態發起請求到分發服務函數有一個過程，由于SSDT和Shadow SSDT相對明顯，可以通過對從用戶
態發起請求到分發服務函數中間過程的代碼進行改寫，來實現相對隱蔽的hook。
PT準備檢測的是便是這部分hook。
簡單來說，PT作者對系統機制的理解不全面，很多地方沒有考慮周全，導致漏檢測(比如內核入口點只檢
測了一個）
不過將調試寄存器名稱寫錯有點囧了
Anti-rootkit如某些大牛說的，現在越來越多人在寫了，門檻也越來越低了。但是要 ...
CRX的名字確實寫錯了。。。不過沒什么大礙
重要標志位可以自己分析DR7，
不過打算在下個版本，詳細列出來
入口點監測，可能沒檢測全，以后的版本繼續加強了。。。
后面幾個問題，我也再檢查一下，
PT確實還算不上優秀，只能繼續改進，
如果只是進程線程文件，確實很多人都可以做，
不過dl牛好像把PT歸于這一類了。。。
而且ARK也不可能全部都考慮到，
即使是XT也有考慮不到的地方，枚舉不到的模塊吧？
PT已經加了很多自己的東西，也不能單純的說是模仿了吧
群里面有人攻擊XT嗎？會不會是dl牛過于敏感了
有人習慣用PT，有人習慣用XT，不可能讓大家都統一的標準啊。。。
更多的人應該是兩個都在用吧。。。
不管怎么說XT在linxer牛和dl牛的努力下，
的確是第一流和最優秀的ARK，但是對用戶的要求也很高
而我則努力結合用戶的反饋加上自己的想法。
做一個簡單易懂的工具，即使不把PT算作ARK，
能在大多數情況下解決病毒就可以了，呵呵
========
找下PowerTool的茬 (2)——使用PT 20秒檢測并清除ZeroAccess的不可行性
http://bbs.kafan.cn/thread-1061080-1-1.html? ? ZeroAccess rootkit是最近討論得比較多的一種惡意軟件。它又名max++，ZAccess，得名于rootkit
文件內調試信息中的作者命名。它最早于大半年前在國外一些反病毒論壇和技術博客被討論，近半年前
在劍盟的一個關于清理InstallAntiVirus2010的討論帖里，ZeroAccess首次在國內被關注，那時它已加
入了針對檢測工具的反制措施。幾個月后，卡巴、Prex、安博士、SurfRight等廠商對該rootkit進行了
公開報道。
? ? ZeroAccess rootkit使用了許多技術實現隱藏和反檢測，包括驅動reload and run、虛擬盤、NTFS
文件壓縮、存儲棧設備擴展劫持、文件緩存欺騙、直接操作FCB、引誘檢測、高級自我保護等。
? ? 看到PowerTool作者在博客發布了名為《20秒檢測并清除ZeroAccess/ADS流病毒By PowerTool》的博
文，提出了清理該rootkit的簡便方便。不過由于作者并未仔細分析該rootkit，導致該教程和PowerTool
清理過程中出現很多問題，甚至是安全隱患。結合自己對清理ZeroAccess的體會，對其中的不少細節提
出一些質疑。
? ? 這里對清理教程發現的問題做一些探討。
? ? ? 1、對ZeroAccess自我保護規避的不徹底。
? ? ? PowerTool最新版驅動會在每次分發時恢復ZeroAccess新版對IoIsOperationSynchronous函數的
hook，以此來防止訪問ZeroAccess的ADS流文件時由于未通過rootkit驗證被結束進程并清除文件權限。
? ? ? 可惜的是，PowerTool這樣做并不能完全規避ZeroAccess的自我保護，最新版在很多情況下仍然會
出現觸發ZeroAccess導致無法正常使用。
? ? ? 試舉一例：
? ? ? PowerTool在啟動時會檢測硬盤，可能會發送SMART_RCV_DRIVE_DATA的I/O控制碼獲取硬盤信息。
這一動作會被ZeroAccess在Ata/Scsi/Storport等設備棧最底層微端口設備驅動的hook截獲，然后
PowerTool會被無情的結束進程并且文件被清除權限。
? ? ? 如下所示，PowerTool的訪問被ZeroAccess的hook截獲，PowerTool.exe文件被清除了權限。
1:kd> p
8154fa2e ff156c945581 ? ?call ? ?dword ptr ds:[8155946Ch] ds:0023:8155946c={nt!
ZwSetSecurityObject (80501fb0)}
1: kd> !handle @ecx
? ? Image: PowerTool.exe
Object: 8137ba48 ?Type: (819edad0) File
? ? ? ? Directory Object: 00000000 ?Name: \Documents and Settings\Administrator\桌面
\PowerToolV4.0.2\PowerTool.exe {HarddiskVolume1}
1: kd> lmvm PowerTool ? ? ? ?
? ? Image path: C:\Documents and Settings\Administrator\桌面\PowerToolV4.0.2\PowerTool.exe
? ? Image name: PowerTool.exe
? ? Timestamp: ? ? ? ?Thu Sep 01 23:22:51 2011 (4E5FA34B)
? ? ImageSize: ? ? ? ?0065F000
? ? ? 2、教程針對ZeroAccess版本的局限導致清除無效的可能性
? ? ? 教程提出20秒修復ZeroAccess，最后提出的3步，即恢復hook、清除關機回調和修復感染文件在很
多情況下是無法清除ZeroAccess感染文件的。
? ? ? 教程對應的ZeroAccess版本，是一個多星期前的，并沒有考慮再這之前以及最新的版本。最近的
版本，ZeroAccess自建的微型文件系統的存儲文件也已轉移。
? ? ? ? ?
? ? ? 更重要的是，教程中并沒有提到刪除ADS流文件以及該文件對應的服務（實際上0.40版刪除ADS流
文件存在問題），也沒有去嘗試清除ZeroAccess自建的微型文件系統的存儲文件。特別是前者的文件和
服務配置信息，不刪除可能導致重啟重新感染，這點之前的一些教程帖中已有討論。
? ? ? ? 3、教程給出的清理步驟的多余性
? ? ? 教程提出的三步清理ZeroAccess,除了修復感染文件，其它步驟，單就ZeroAccess系列而言是沒有
意義的。即使不處理，也不會導致本身清理局限性外的修復的問題。由于該教程本身針對的是
ZeroAccess的某一版，且有著前面所述的局限性，把刪除回調、恢復hook這樣常見的殺毒手段放在這是
沒有必要的。
另外，由于PowerTool對ZeroAccess的hook檢測并不全面，包括前面所述的存儲棧設備擴展劫持（如下
XueTr提示）默認都沒有檢測，不能作為PowerTool通用清理方法。
? ? ? ? ?
? ? ? ? ?4、對進程的枚舉和顯示。 ? ? ?
? ? ? ?由截圖看，PowerTool將進程2571670320:3480008550.exe本身模塊顯示為隱藏。實際上該模塊并
不存在隱藏，使用其它Ring3工具都能正常枚舉出模塊，除了讀取文件本身可能存在困難。
? ? ? ? ?5、對進程文件的刪除。
? ? ? ?教程中并沒有提到3480008550.exe對應進程的結束以及該文件的刪除。
? ? ? ?實際使用PowerTool刪除3480008550.exe這一文件后，再次刷新進程管理，會將該進程路徑名顯
示為C:。
? ? ? ? ?
? ? ? ?此時使用結束進程并刪除文件功能，PowerTool會將該路徑傳入，刪除整個C盤時自然導致系統死
鎖或者藍屏崩潰，影響系統安全性。
? ? ? ?一個典型的崩潰dump如下，這里PowerTool附加到explorer.exe關閉了不該關的句柄：
*******************************************************************************
* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *
* ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? *
* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*
*******************************************************************************
INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver, etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 00000208, The handle that NtClose was called with.
Arg2: 00000001, means an invalid handle was closed.
Arg3: 00000000
Arg4: 00000000
PROCESS_NAME: ?explorer.exe
STACK_TEXT: ?
f088900c 804f9df9 00000003 f0889368 00000000 nt!RtlpBreakWithStatusInstruction
f0889058 804fa9e4 00000003 e186e008 81529af0 nt!KiBugCheckDebugBreak+0x19
f0889438 804faf33 00000093 00000208 00000001 nt!KeBugCheck2+0x574
f0889458 805bd4bd 00000093 00000208 00000001 nt!KeBugCheckEx+0x1b
f088949c 805bd509 00000208 00000000 00000000 nt!ObpCloseHandle+0x173
f08894b0 8054261c 00000208 f088957c 80500f31 nt!NtClose+0x1d
f08894b0 80500f31 00000208 f088957c 80500f31 nt!KiFastCallEntry+0xfc
f088952c f069f208 00000208 0100001e 813978f0 nt!ZwClose+0x11
WARNING: Stack unwind information not available. Following frames may be wrong.
f088957c f06b0a09 8158a378 f0889a80 00e37b61 kEvP+0x5208
f0889abc f06ba16f 8148e778 81677378 00e37d9d kEvP+0x16a09
f0889c40 804f018f 8148e778 81677378 806e7410 kEvP+0x2016f
f0889c50 80580982 816773e8 8162c7a0 81677378 nt!IopfCallDriver+0x31
f0889c64 805817f7 8148e778 81677378 8162c7a0 nt!IopSynchronousServiceTail+0x70
f0889d00 8057a274 000000d4 00000000 00000000 nt!IopXxxControlFile+0x5c5
f0889d34 8054261c 000000d4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f0889d34 7c92e4f4 000000d4 00000000 00000000 nt!KiFastCallEntry+0xfc
00129360 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet
FOLLOWUP_IP:?
kEvP+5208
f069f208 8b4508 ? ? ? ? ?mov ? ? eax,dword ptr [ebp+8]
? ? ? ?6、“跟蹤硬盤讀寫過程”的不全面
? ? ? ? ZeroAccess會對DR0設備的設備擴展進行修改，這種方式繞過了常規的hook檢測。PowerTool最
新版的檢測MBR功能會受此影響，導致顯示“無法讀取MBR信息（內核）”。
? ? ? ? ? ?
? ? ? ?教程分析中提到了通過“跟蹤硬盤讀寫過程”檢測可能更改。“跟蹤硬盤讀寫過程”類似avast
出品aswMBR工具的Disk IO Trace功能。PowerTool另可以通過這一功能恢復上面的劫持。不過這一功能
仍然存在問題，無法突出高亮顯示ZeroAccess的另一處hook，正是該處hook導致了之前PowerTool最新仍
然可能觸發ZeroAccess自保。
? ? ? ? ? ?
? ? ? ?7、總結
? ? ? ? 《20秒檢測并清除ZeroAccess/ADS流病毒By PowerTool》一文，其中的分析、給出的方法和實
際配合PowerTool清理ZeroAccess的效果都存在不少問題，甚至是安全隱患。這里提出其中一些問題，供
大家參考，希望對手工清除ZeroAccess有所幫助。
========
總結
以上是生活随笔為你收集整理的powertool 使用学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： N个数据库外键实例
- 下一篇： IOS树视图学习总结