這個驅動本來準備端午節搞的,但後來端午節去了躺北京玩了幾天,也就擱置了...最近連續花了4個晚上,大致把它搞的差不多了,有些收穫...初學window驅動,水平很菜,有些東西我也未必清明,加上3環的**還沒有吃透,期間也沒有用偵錯程式跟蹤,全是ida(f5)靜態分析的,謬誤在所難免,高手請飄過,希望對菜鳥學習有點幫助.
1.ssdt檢測
這個功能有三個iocontrolcode與之對應,他們分別是22000fh(拷貝keservicedescriptortable);220007h(拷貝keservicedescriptortable->servicetable);22000bh(恢復乙個ssdt hook),這個功能目前還不具備檢測和恢復inline hook的功能
2.shadow ssdt檢測
這個功能實現和ssdt差不多,都是從kesystemservicedescriptortableshadow入手,不過3環需要為每個平台配置一張函式名錶(ssdt可以不配置函式名錶,可以從ntdll.dll中收集),詳細文章可以參見zhuwg兄弟寫的segmentobject->sizeofsegment獲取主程式記憶體鏡象大小,對2k系統,由於手頭缺乏資料,那段**什麼意思不知道,詳細**在get_main_file_size_by_eprocess函式), 然後輸出緩衝區足夠大就進入dump_selected函式拷貝記憶體
4.核心模組和stealth code檢測
iocontrolcode是0x220023h,在檢測之前也會設定檢測方式,然後根據檢測方式進行檢測.這個功能主要由list_kernel_module函式完成,這個函式裡面整合了很多檢測方法,很多方法都比較*淫**蕩*,大致的檢測方法有:
4.1 用iodriverobjecttype指向的object_type.typelist鍊錶檢測,遍歷這個鍊錶中的每一項,並會取每個driverobject上的deviceobject,並向上掃瞄這個裝置所在的裝置棧(注意這裡沒有向下掃瞄),嘗試發現其它的driverobject 詳細**見list_module_by_iodriverobjecttype函式
4.2 用iodeviceobjecttype指向的object_type.typelist鍊錶檢測,遍歷這個鍊錶中的每乙個裝置,並也會向上掃瞄這個裝置所在的裝置棧(注意這裡沒有向下掃瞄),嘗試發現其它的driverobject 詳細**見list_module_by_iodeviceobjecttype
4.3 用目錄物件樹(zwopendirectoryobject("//"))檢測,遍歷這棵樹,對葉子節點(具體物件)看其object_header.type欄位是否指向iodriverobjecttype/iodeviceobjecttype,如果是的話,則會採用4.1/4.2相似的措施;對目錄物件子樹則遞迴處理之(核心堆疊空間太小,遞迴搞始終給人一種不安全感,看snipesword裡面處理登錄檔部分也大量遞迴,比較汗) 詳細**見list_module_by_opendirectoryobject函式
4.4 用driversection(psloadedmodulelist鍊錶)檢測,這個方法大家都比較熟悉, 詳細**見list_module_by_driversection函式
經過上面4個方法,driverobject就獲取完畢了,他們對應的都是有詳細資訊的核心模組(這項檢測初步給人的感覺是比icesword可靠些,icesword則是先嘗試恢復ntquerysysteminformation,設定kernelmode,然後呼叫ntquerysysteminformation獲取核心模組資訊),下面的檢測主要是對一些零星的能執行**的記憶體塊進行檢測(stealth code)
4.5 用上面幾種方法已經找到了一些driverobject,這裡就對這些driverobject下手,檢測這些driverobject的driverstartio/majorfunction是否被hook,如果被hook且新位址不在我們已經找到的模組裡,則說明是那種分記憶體,寫**似的hook,記錄這塊記憶體資訊 詳細**見list_module_by_driverstartio_and_majorfunction函式
4.6 暴力搜尋記憶體, 找到pe頭部,並判定optionalheader.subsystem是否是native 詳細**見list_module_by_scan_memory函式
4.7 利用控制代碼表檢測,這個的具體原理我未能理解, 詳細**在list_module_use_suspicious_thread_by_handle_table_in_not_2k/list_module_use_suspicious_thread_by_handle_table_in_2k這兩個函式,感覺跟核心模組檢測無關......知道的請說一聲
4.8 rku會inline hook三個呼叫頻度很高的函式(exallocatepool/exallocatepoolwithtag/kedelayexecutionthread),在這三個函式裡會記錄它們的返回位址,並利用這些位址來檢測一些模組,如果返回位址不在某具體模組範界則會記錄其記憶體資訊 詳細**見list_module_by_return_address函式
4.9 檢測kisystemservice/kifastcallentry是否在某具體模組範界,如果不在也記錄其記憶體資訊
到這裡檢測就完成了,上面的檢測方法太多,有些檢測獲取的資訊不足,rku會進行一些額外的修正處理,這些**都在list_kernel_module的結尾部分,詳細請參見原始碼,我都做了一些注釋
5.file檢測
由於目前一直在用ida反,並沒有使用偵錯程式,主程式目前還只反了一點,這個部分具體做什麼的,我不太清楚,不過在驅動裡看到乙個iocontrolcode(2200a7)是在做扇區級別的操作......
6.code hooks檢測
在驅動裡並沒有看到分析code hooks的**, 只看到一些拷貝記憶體到3環的功能函式,把一些系統關鍵手工load展開後,進行記憶體對照比較就可以搞定這個了,當然這個裡面還具備kisystemservice/kifastcallentry hook的檢測和恢復**,詳細可以看idb檔案
7.rku的程序保護
7.1 ssdt上的保護,在ssdt上對三個函式(ntopenprocess, ntopenthread, ntduplicateobject)進行了inline hook
ntopenprocess 防止開啟rku程序
ntopenthread 防止開啟rku的執行緒
ntduplicateobject 防止複製rku程序的控制代碼
7.2 shadow ssdt上的保護,在shadow上對四個函式(ntuserquerywindow, ntuserfindwindowex, ntuserwindowfrompoint, ntusernotifyimestatus)進行了inline hook,防止其它程式通過findwindow,windowfrompoint等函式來列舉rku的視窗,你可以看到spy++對rku已經失效
icesword&rootkit unhooker驅動簡析
zhuwg yykingking 發在debugman上的兩個**片段 還有些文章,無法一一枚舉,再次一併表示感謝 大致就是這樣了. linxer 2008-06-19 於哈爾濱 有的時候我們知道目標物體的需求運動，但不知道如何去驅動系統運動以產生該需求目標運動，同時通過數學求解需求驅動函式又較麻煩時，可以利用adams進行逆向求解。即將系統建立好後，對目標物體輸入需求運動，結束後測量驅動關節處的運動函式曲線，將曲線資料匯出後，再讀入生成spline曲線，並用特定函式擬合後就... 這個應該算是我第乙個逆向的應用程式，由於過程比較複雜，這邊沒法把當時做的過程全部記錄下來，我直接把我的idb檔案和自己仿照寫的wwwscan工程檔案上傳 我只逆向了http部分，https部分沒有完成，而且我發現我的掃瞄器比原版的要卡，不知道為什麼，以後有空除錯下，我仿寫不是根據它的設計思路重新的，... 根據iphone系統版本的情況，選擇對應的越獄方法，對iphone進行越獄操作。手機越獄完成後，在cydia中安裝如下軟體 reveal loader 1.0.0 安裝後，請重啟手機 必須保證手機和mac在同乙個wifi環境下，分析時，手機無需用usb線連線到電腦 必須上傳libreveal.pli...adams的逆向分析
wwwscan目錄掃瞄器的逆向分析
Reveal逆向工程 分析任意iOS應用的UI介面