簡單談談「遊戲圈」所謂的神乎其技的行爲檢測

1   2013-03-21, 18:44:50    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（1）

---

開始寫這些東西只是想說明幾件事兒：
1.這個世界有矛，必有盾，相反有盾，也必有矛。世界上沒有不透風的牆。
2.有些東西不是傳說中的那麼神。
3.傳說是怎麼來的。


遊戲圈裏不少走上快速發財道路的人對行爲檢測這個說法不陌生，
從這個詞誕生以來，各類封號統一說法行爲檢測，
而後一直就有人想過各類對抗（什麼數值模擬，什麼技能模擬），
結果一直沒啥明顯的效果，
最後悲情的開始宣傳行爲檢測徹底是遊戲服務器對於數據分析作出來的。
其實真相不是這樣的...

所謂行爲檢測，其實能夠看做幾種檢測的組合加上一個簡單到可怕的監控策略。
首先是程序代碼暗樁,不是說這些暗樁 人看不到，只是因爲VM的緣由，不少人大腦自動忽略了暗樁——在這裏重審一下，代碼VM化，真的殺傷性強大...
曾幾什麼時候一個簡單的Flag標記和一小段比較座標移動記錄的代碼搞殘無數高人，
還曾幾什麼時候一個簡單的不可見標記的暗樁搞殘無數全屏...
因爲不知道找不到暗樁，因此開始有人大聲宣揚這是行爲檢測。

而後是神祕信息通訊動態檢測，這裏的神祕信息不少，有進程，有窗體，有各類各樣的東西（cpuid,mac,bios,硬盤，系統版本，安裝過的軟件等等一個不能少）
這些東西拿來檢測什麼呢？主要是斷定多開，多帳戶同一機器登陸等等，甚
甚至有的會上傳未知進程和運行模塊的文件等等東西...
而這一切均可以是一段隨時隨地到達機器上的shellcode模樣的東西（某公司使用的是明文lua腳本，某某公司使用抽象代碼——自帶解釋器？？），
因而因爲進行逆向分析的人員沒有長期監控研究，因此發現不了這種動態檢測，
因而被XX後又有一些不肯意繼續被坑下去的人就開始加入大叫行爲檢測的行列。

最後是一個策略，這個策略就是不進行即時處理，好比一個檢測發現問題了，能夠等3天后把檢測出問題的機器上登陸過檢測出的問題的賬號統一封號,或者乾脆次日把與檢測到的賬號發生交易行爲最多的賬號封號...因而又有人大叫行爲檢測。

說這些到底有木有真正的行爲檢測，實際上是有的，可是基本很少見，也沒幾個真的大規模應用（本身猜測服務器負擔吧~~）


第一篇就到這裏吧，後面從第二篇，我開始講講一些具體的檢測code是怎麼寫的~~

第二篇  http://bbs.pediy.com/showthread.php?t=166298
第三篇  http://bbs.pediy.com/showthread.php?t=166302
第四篇  http://bbs.pediy.com/showthread.php?t=166309
第五篇  http://bbs.pediy.com/showthread.php?t=166492
第六篇  http://bbs.pediy.com/showthread.php?t=166574
第七篇  http://bbs.pediy.com/showthread.php?t=166703

IGS 國際遊戲安全組織 站點 

 

 

1   2013-03-21, 20:19:24    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（2）

---

上一篇談了一些東西。

這裏開始想說說檢測code是怎麼寫的。這裏不討論進程，窗體這些常見信息的檢測。
假設被檢測的東西已經完美突破各類暗樁，各類ws的掃描。


本篇就先來一個日了無數純CALL模型的輔助的檢測吧。
下面每篇再多講一些~

關鍵性的代碼很簡單
服務器發個請求XX檢測的包過來
本地返回下面代碼計算的數據

代碼:

DWORD GetInputAwayTime()
{
  LASTINPUTINFO lpi;
  lpi.cbSize = sizeof(lpi);
  GetLastInputInfo(&lpi);
  return DWORD((GetTickCount()-lpi.dwTime)/1000);
}

做用就是計算鍵盤，鼠標，手柄這類設備有多少秒不操做了~~
這個代碼是有不少變形的，好比使用IdleUIGetLastInputTime這個api,
或者經過設備鉤子記錄最後輸入時間（有的遊戲甚至用驅動去記錄的...）
服務器根據你的操做離開時間長短和進行了那些不可能離開操做的事情來判斷...
 

 

 

1   2013-03-21, 20:58:56    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（3）

---

第二篇中談到了對純CALL的輔助軟件的一種檢測手段，索性接着亂談這種輔助的檢測手段。
不過這裏談談暗樁模式的檢測，堆棧遍歷逐層找返回的EIP相信不少人都會。
不過在某些Call的地方插入下面這樣的代碼，好比遊戲邏輯的發包call的加密call裏面
因而悲情又出來了~

代碼:

  WCHAR wzCallerName[MAX_PATH];
  PVOID dwRetArray[62];
  DWORD dwRetCount;
  BOOL bNeedLogStack = TRUE;
  dwRetCount = RtlCaptureStackBackTrace(2,50,dwRetArray,0);//用api是很差的，能夠本身實現的說~~
  if (dwRetCount)
  {
    for(DWORD xIndex=0;xIndex<dwRetCount;xIndex++)
    {
      if (CheckExcepAddr((DWORD)dwRetArray[xIndex]))//排除部分白地址
      {
        bNeedLogStack = FALSE;
        break;
      }
    }
    if (bNeedLogStack)
    {
      for(DWORD xIndex=0;xIndex<dwRetCount;xIndex++)
      {
        GetCallerModule((DWORD)dwRetArray[xIndex],wzCallerName);//獲取地址模塊名稱
        ReportToSrv((DWORD)dwRetArray[xIndex],xIndex,wzCallerName);//把信息寫入定時返回服務器的數據體裏，嘿嘿~
      }
    }
  }

第三篇內容就這些吧，還有幾個有意思的檢測和暗樁的方法等繼續講~~
 

 

 

1   2013-03-21, 21:42:58    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（4）

---

接續上篇 第三篇~
先補充點檢測技巧
不少人會注意到檢測掃描中的進程，模塊，窗口的掃描（大部分寫檢測的人都以爲這些就ok了），可是不會注意到能夠經過掃描本地TCP鏈接信息來檢測——好比某輔助會鏈接固定登陸驗證服務器（ip？端口？），因而服務器上添加一個掃描特徵，完爆之，之後只要是這個服務器的輔助直接就是不解釋封號...

接着進行本篇的部分，上次繼續講了經過call的輔助的檢測，此次就不講它了，我換個話題，講講一直以來被不少人推崇的模擬設備操做的輔助的檢測。

首先對後臺模擬按鍵的檢測
有兩種後臺模型，一種是消息的，不過估計如今已經絕種了，是個遊戲公司開發都會dinput了。
一種是dinput裏作手腳，二者檢測方式同樣，直接用GetKeyState結合GetForegroundWindow爆菊花（經過其餘方式獲取按鍵狀態和窗體位置層次信息同樣能夠哦）——檢測出來不封號，直接服務器留個記錄，等那天高興了再封。
接着就是純前臺的SendInput或者驅動（NTIO也算是驅動吧）模擬的，這種其實很很差檢測，在32位系統裏一般是經過內核hook來進行處理的，可是對於64位系統或者重載內核繞過hook的狀況則須要一些新的小技巧就是記錄按鍵點擊的相對座標，通常模擬輔助的點擊座標都是很是穩定的，而後經過一組特徵來檢測，不過這裏已經涉及超出本篇的內容了——必須抓到樣本才能夠了。

第四篇有點水，第五篇儘可能就來點不水的內容。 

 

 

1   2013-03-22, 20:23:31    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（5）

---

儘可能不水~~

開篇先來一種檢測小trap,HANDLE檢測，這個檢測主要是枚舉句柄而後檢測的東西好比隱藏的進程，特殊的被打開文件之類等東西，有時候也用來檢測是否存在多個自身（基於對某些特別句柄的檢測...）

接着進入本篇的內容，本篇說2個檢測，也是不太常見的，和比較冷門。
第一個是對脫機類型的輔助的檢測，服務器上記錄累計在線時間長度（好比累計在線3天，1周，2周等），在總時間達到某個值的時候發送一個特殊數據給客戶端，客戶端抓住特殊數據後返回特殊返回結果。看似簡單的東西，可是效果很好很強大。觸類旁通一下，還能夠是帳戶角色等級，好比角色到達70級了，發檢測...甚至是郵寄物品的次數啊，角色身上的錢數啊，好多可能的判斷標準，因此效果很好，又很難被解決。

第二個是對非脫機的一個檢測，這個檢測頗有意思，就是經過Windows自帶的pnp即插即用接口去獲取當前監視器的產品id（目前都是WMI方式的了，不多用SetupApi），而後返回給服務器。這裏觸類旁通一下，其實還能夠檢測鼠標鏈接狀態，鍵盤鏈接狀態等等,甚至有的同事想出來若是存在攝像頭則拍照取回判斷是否存在人臉等等...

補充一下：
對於非脫機的輔助還有一種比較好的特殊手段，就是發個GM聊天信息給可疑的遊戲玩家。

下一篇，準備講一些關於多開的檢測。
PS：若是須要講一些其餘的檢測，請在本帖跟帖說明就好了，可是本人不針對任何遊戲進行任何闡述，只能對某種檢測進行一些解釋和說明。

 

 

1   2013-03-23, 14:12:03    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（6）

---

接續第五篇，上回說，這篇主要講講多開檢測。

先來看看通常咱們知道的多開檢測有哪些
1.窗口和進程
2.各類各樣的互斥體系（Event啊，Mutext啊，信號量啊，衝突域啊，Atom鎖啊，pipe啊，本地端口啊，MapView啊，LPC啊，還有用RPC COM的，甚至有用特殊Cookie的~）
3.遊戲保護的通訊（ ）

這三種就是常見的通常全宇宙都知道的~
那麼這裏也再也不多說了，接着我來說講少數的
1.硬件id記錄
2.服務器ip記錄
這兩種如今也逐漸被重視了，因此也不是我想說的。

我這裏提一個不多有人注意到的東西::GUID
關鍵API:CoCreateGuid
流程：首先讀取本地保存記錄（能夠是臨時註冊表或者臨時文件或者遊戲保護公共內存或者交互式Set的Cookie——Cookie這種模型有時間再細說）裏的GUID，若是沒有就生成一個，而後保存一下；若是有則提取GUID投遞給服務器...
服務器上判斷不一樣帳戶登陸的GUID出現重複次數，根據CoCreateGUID重複可能性的說法同一個GUID最多同時存在2個...（系統重啓前遊戲保存的GUID通常是不消失的...）

下面是解答 某位同窗提出的 內存檢測的時間了
內存檢測有多種：
常見的是檢測HOOK,這個很常見，基本都知道。
接着是檢測模塊或者代碼，這個也是很常見的。
接着是檢測遊戲信息完備的，這個其實不少都作，可是作的好很差都很差說。
我來談的也是這種檢測 信息完備的，作法有不少種，
最多見的就是用複製多個角色對象，而後對比對象，這種比較麻煩的是服務器刷新數據，你要刷新多個對象數據。比較簡單的方法，就是把對象的屬性表（這種檢測通常都是開發商提供代碼的前提下才能進行的）在每次關鍵操做後計算一個HashStamp發給服務器（服務器上也有角色屬性並且也支持Buffer疊加的狀況下才ok..）而後就不用說什麼了。
還有一種比較取巧的辦法就是角色按照等級各類屬性有個最大屬性值（裝備按照id屬性也存在最大值,舉例，1級的角色最大HP是300，裝備加成最大是200，因而最多隻有500的HP超過500就悲劇吧~），某一項數值超過最大屬性極限時就向服務器發個包，服務器返回一個當前服務器上的角色信息，而後本地再次對比，而後再通知服務器是...

就講到這裏，最後說一下關於VM的問題，歸根揭底不少檢測都是要調用API的，因此只要頂住API的調用，必然能夠發現檢測的祕密，因此爲了保住檢測的祕密，API如今不少都是reload和抽取的~~

下一篇，講講 網頁遊戲怎麼作檢測的。

從頭看起 第一篇位置： http://bbs.pediy.com/showthread.php?t=166288
PS：若是須要講一些其餘的檢測，請在本帖跟帖說明就好了，可是本人不針對任何遊戲進行任何闡述，只能對某種檢測進行一些解釋和說明。

 

 

1   2013-03-24, 20:18:34    【原創】簡單談談「遊戲圈」所謂的神乎其技的行爲檢測（7）

---

接續上篇，本篇講講 網頁遊戲怎麼檢測輔助。
網頁遊戲因爲沒有客戶端能力，因此檢測作起來很麻煩，不少操做沒法像普通遊戲那樣隨心所遇的去作。並且因爲網頁遊戲自己設計上可能考慮的不周全，從而致使輔助很容易出現（有的網頁遊戲甚至是能夠用CE修改充值的錢數...）。

先講一下關於網頁遊戲內存修改的檢測，通常是把即時數據發送給服務器作驗證，或者乾脆服務器負責重要計算，目前沒啥好的檢測方法。
接着講一下頁遊對於封包的檢測，FLASH頁遊基本都有封包的，因此封包修改的輔助也是存在的，大部分頁遊對於封包修改都無解，不過有一種比較靠譜的封包檢測是封包數據自簽名...算法MD5+RSA...
最後來講一下頁遊對於各種輔助的檢測能力
1.輸入模擬類，目前無解。
2.Hook封包並修改,目前有sighash方案。
3.本地內存修改,目前靠客戶端和服務器的數據對比，也是發包的...
4.Flash解析hook修改，目前無解，由於頁遊自己環境侷限...

頁遊的麻煩主要是被瀏覽器侷限住了，自己代碼運行全面受限，不能作不少事情。
相比之下微端要好不少。

本篇完成，也是這個系列的最後一篇了，其餘更系統更細節的內容就再也不作談論了。
其餘東西，如手遊啊，設備網遊啊（Wii，PSN，xbox上的網遊...），這些遊戲的檢測基本都很相似的說~


從頭看起 第一篇位置： http://bbs.pediy.com/showthread.php?t=166288