淺談遊戲安全 (一)

前言

準備來說這個是遊戲安全了，安全和測試雖然有部分重合，但因為關注方向和技術棧差異還是蠻大的。
今天參加了看雪 20 週年後，祝看雪越辦越好，有點感觸，在鄭重得吃完一盆東西后，寫下這個關於遊戲安全的帖子。
當然遊戲在安全方向上方方面面，只接觸了其他一部分，這裡淺談下這些年的一些小儲備，但只講種類，現在翻新的很快，也不確定是否還實用了。
下面很多都建立在對遊戲功能業務十分了解。

客戶端反編譯

遊戲反編譯意義有很多，比如是對提取資源，程式碼以及重新打包。一般公司沒有安全防護的找第三方公司，或者公司本身會有安全防護的都會基礎的防護手段加殼和資源混淆，用非官方的手段進行編譯，並且殼的種類很多，版本也在更新。
如果不加殼，被破解難度會大幅度降低，現在部分殼對遊戲影響很小，還有外掛白名單的監測功能。
這裡主要防護了程式碼和資源被破解以及二次打包風險，要獲得更多資訊得和了解遊戲打包的方式，從下文來看，會發現這條作用又多大。

反調式模式

主要是防止進行逆向分析，目前用附加到對應遊戲程序上，根據瞭解去花追蹤的輔助工具和 IDA 十分強大，只要有足夠的耐心沒有什麼是不可以調式的。
如果說有的話，可以在斷點成功時讓遊戲直接掛起後退出，so 是否可以選擇只被特定程序載入不確定。
為啥要反調式，因為有這個的存在可以完成遊戲離線破解和嗅探出遊戲內部的一些關聯。

遊戲離線破解

先得確保遊戲不被脫殼，得知道協議型別，遊戲資料包包頭結構和訊息體組成，一般進行抓包分析，現在把抓包一段段猜和拼出來的。

邏輯問題

使用遊戲設計或者不是實時和資料庫和伺服器進行同步的功能。
前者比如一些活動設計不合理，被小號擼了羊毛轉給大號上，靠封小號不是一回事啊，一開始就得想清楚。
後者比如不要被結合協議一起給做了或者脫離網路完成漏洞的重要環節。

協議安全

也是封包測試的一種，這個也是測試會做的，可以抓包去改，也可以寫框架來測試，主要提高協議穩定性和檢查服務端校驗疏忽，首先也是得防止脫殼。
這裡做起來有二個層面和一個和其他使用者互動項，判斷畸形邊界和根據遊戲資料型別設計特殊溢位的數字檢查回包一個層面。
第二個層面是多次傳送後，確定服務端是否有不影響當機的錯誤日誌，如果錯誤日誌足夠多也是可以影響伺服器穩定性。
修改資料結構有幾種組合（這裡面說起來簡單，做起來收集資料要沉澱）
fuzz 畸形資料 + 歷史問題資料 ；有符號無符號數字的邊界和浮點數精度問題；下個協議欄位不變，引數和上個協議交換資料（需要動態才行）
最後互動是最難的一種（這個模式手動搞過，但想了下開發到框架內部也不是不行）
互動性完成的協議封包，1 對 n，進行傳送不合法廣播和傳送合法但不該出現的訊息，對其他 n 個使用者的影響。

記憶體修改

現在字面值型別在記憶體中分段已經沒啥用了，主要是驗證客戶端表現和客戶端表現問題後是否會影響伺服器。
因為有些時候的確修改記憶體會讓金錢數量顯示上變成很多或者揹包道具疊加異常，伺服器不會完全信任客戶端。
之前 moba 遊戲就有遊戲出現修改某個附加裝備後，會導致 1 級可以打死 3 級野怪的情況。

硬體變速

加速和變慢速，只要對其他人不公平的都是有影響的，這部分通常是策劃層面進行防護，開加速跑路，只能靠檢查使用者距離最近幾次座標變換速度大於正常全 buff 速度的一定倍數就踢號。

未來需要關注的

1.第一個好像這個和遊戲業務確沒啥關係，但不得不做啊，隨著等保標準的出現有 7 大類，50+ 的檢查，對於 app 包做一系列掃描檢查工具基本是箭在弦上不得不發。
可以延伸開發出 7-10 個左右的小工具，在定序用持續整合串聯起來，下個文章會介紹這些小工具的簡要需求和幾個點的思路。

2.壓測混合會讓伺服器正常條件下出現錯誤資訊（前提是大部分情況下會 return null 拒絕的）

3.利用正常網路回包的時候修改發包頻率的工具，介面或者工具項

4.拿一款修改工具好好二次開發，跟著別人的版本走。

5.關注輿情，檢查自家遊戲是否被盯上了。