HShield遊戲保護的對抗和新的問題

2021-04-13 00:35:45 字數 1287 閱讀 6434

**bujin888

第乙個版本

hshield反外掛程式方式應該向程序插入他們的反外掛程式鉤子  攔截我們做外掛程式的必要函式

我當時突破方法是rookit技術,隱藏程序!

第二個版本

hshield利用訊息全域性鉤子插入他們的反外掛程式鉤子 ,我是攔截了loadlibary到

自己的處理函式拒絕了他家反外掛程式鉤子進入

第三個版本

他家在loadlibary上做了處理,但他們忽律了乙個東西!那就是loadlibaryex函式

第四個版本

也就是現在這個版本!只能用**來形容  一開始我用hook loadlibaryex ,

但是好多api仍然不能使用   我一開始以為loadlibaryex 也被處理過了  

於是我又攔截 rtlinitunicodestring 因為每乙個檔案在底層傳輸字元處理中

必須用到這個函式,但是發現hshield的dll是全被攔截了,但getpixel等仍然沒有作用,

通過除錯發現,ring3層**完全沒有被修改,那只能說明進了sysenter的ring0層!

沒辦法,也只好自己寫驅動對抗了,於是根據ddk資料裡的mirro.sys

重新寫了我所需要的外掛程式函式驅動win32gdi.sys!完成了這次的反外掛程式的突破!

問題:win32gdi.sys是參考ddk驅動裡的mirror驅動改寫的,屬於虛擬顯示卡的的方式!他有幾個缺點

一:不支援 directx遊戲

二:消耗的cpu比較大!

看了驅動開發網的資料 hook int 2e  hook sysenter 和 國外rootkit方式中的另類

hook   sysenter   仍然不能根本解決問題!

因為如果  我hook  sysenter  然後啟動遊戲  遊戲的驅動hook  又會把介面接管過去

我如果恢復介面,遊戲就會自動退出!   還有通過直接在原來sysenter位址裡面寫跳

轉**來實現hook sysenter我感覺也  沒什麼用!因為sysenter已經被攔截了,根本

執行不到我所寫跳轉的位置,就算執行到了又能如何呢?我總不能自己實現sysenter功

能吧,如果能自己實現sysenter功能!我還不如直接ring3層hook kisystemcall

目前我有新的想法  就是增加服務id  就是增加系統的服務id  假如getpixel最後呼叫

的系統伺服器id為x 我們增加個系統的服務id  y,讓y的id跳到x的id裡執行,從而欺騙

反外掛程式系統!不知道大家有什麼更好的辦法

語文一直不及格!所以語言組織很差!大家見諒 

棧的保護 windows和linux

上面提到的兩種方式中,安全cookie提供了更大的保護,而不可執行棧在遇到溢位 放到堆的時候就很難奏效了,先看看安全cookie是怎麼一回事。在傳統的函式呼叫時,棧自下而上是 引數 返回位址 老的棧底指標 區域性變數 如果區域性變數發生向下溢 出,覆蓋了函式的返回位址,那麼程式一點脾氣也沒有,乖乖聽...

受保護的Hyper V環境和受保護的虛擬機器

無論是企業內部還是託管在idc或雲服務商的虛擬機器,如何保障執行的環境是安全的,虛擬機器是安全的 虛擬機器檔案裡的資料以及看到的監視器畫面 成為此篇文章和大家 研究的。比如您正在執行的虛擬機器,管理員是可以通過虛擬化平台通過監視器看到您的系統並操作的,比如關機,開啟,重啟等等操作,其次如果有別有用心...

對抗樣本生成的PGD和C W方法

projected.gradient algorithm 先記錄幾個常見的單詞 convex set 凸集convergence rate 收斂速率 convex 凸函式interpretation 理解l0範數是指向量中非0的元素的個數。l0範數很難優化求解 l1範數是指向量中各個元素絕對值之和 ...