遊戲剛上線卻被外掛頻繁騷擾，開發者該怎麼辦？

本文轉自知乎專欄「水風的遊戲思考」，作者水風，遊戲葡萄已獲轉載授權。

對於一個要上線的遊戲，防外掛是必須的，歷史上因為外掛而造成大量玩家流失的遊戲數不勝數。隨著遊戲研發技術的發展，對外掛的預防業內其實做的已經越來越好了。下面總結一下防外掛的基礎知識，以及我們的移動模塊為防外掛做了哪些工作。

在做外掛預防工作之前，我們要先了解外掛有哪些。根據我的了解，市面上常見的外掛主要有以下幾種：

這類外掛通過分析遊戲所使用的內存，找到內存中的變數去分析猜測變數是代表的什麼含義。由於客戶端本身保存著很多遊戲信息，比如技能cd、移動速度等。由於我們遊戲技能的管理和發起是由客戶端控制的，若外掛能去把技能cd改為了0，客戶端就可以無限放此技能。

常見外掛工具：葫蘆俠、八門神器

加速齒輪可以加速某一個進程的時間流逝速度，通過加速齒輪，可以讓遊戲客戶端進程的時間加速N倍。真實時間可能只過了1s，而客戶端進程的時間已經過了Ns。通過加速齒輪，可以讓人物移動速度加快、技能cd加速等。

常見外掛工具：加速齒輪

此類外掛可以截獲客戶端發送給伺服器的消息，然後進行篡改或者重發。比如可以截獲一個釋放技能消息，然後再無限重發給伺服器，伺服器若沒有驗證，就會無限執行技能。

常見外掛工具：WPE三件套（eg+wpe+ccp）

這類外掛對遊戲破壞相對較小，但是也最常見。這種外掛比較普遍，對遊戲的影響主要是看遊戲機制。比如我一個哥們弄了20多台手機，用按鍵精靈刷傳奇世界手游的金幣，然後賣給其他玩家。但是對於不能自由交易的遊戲，就不會出現這種問題，最多是導致玩家自己使用，從而可以24小時在線，縮短了遊戲壽命。

常見外掛工具：按鍵精靈（我感覺這東西都已經產生了一條產業鏈...）

防外掛是一個系統工程，需要不同的模塊配合實現。而且，對於不同的遊戲對外掛的預防要求也是不同的，具體遊戲需要具體分析。

常見的外掛預防手段有以下幾種：

遊戲開始時檢測手機正在執行的進程，若發現某個進程在黑名單上，則不能進入遊戲。這種方式可以預防市面上常見的外掛，對於不常見的或者新開發的外掛則束手無策。若遊戲不火沒人玩，這個手段就夠了。希望大家都能遇到針對自己遊戲專門開發的外掛，哈哈。

把玩家的行為（常常是點擊行為）記錄下來並進行分析。這種方式可以輔助檢測玩家是否使用按鍵精靈這種工具。

之前介紹了外掛可能修改內存或者篡改同步消息以達到他們的目的，若我們對客戶端的內存信息和通信信息加密，外掛拿到了信息也不能分析，從而也就無從下手了。

moba遊戲或者fps這種對抗性的遊戲中，玩家使用外掛對手能明顯感知到。對於這種遊戲，舉報機制是一個很有用的防外掛手段。

夢幻就有這個模式。

以上介紹的通用方法並不能解決所有的外掛問題，因此我們在遊戲的邏輯實現過程中要需要做對應的防外掛機制。

在遊戲邏輯實現中進行防外掛的基本方法是：

• 服務端保存驗證信息

• 收到客戶端發來的消息后，對消息的合法性進行驗算。

在具體的遊戲執行邏輯中增加防外掛機制的時候需要秉持一些原則：

這個有兩層含義，一層含義是要讓外掛使用者無法獲得收益；另一層含義是，若外掛使用者只能通過非常麻煩複雜的工作才獲得一些小小收益，那麼這種情況我們可以放過，也就是說不需要對所有的情況都需要增加防外掛邏輯。

在增加防外掛邏輯的時候，需要考慮為了防外掛增加的性能開銷。若因為防外掛增加了巨大的性能開銷，那麼往往是不值得的。這種情況可以考慮不要在邏輯裡面放外掛，而且是通過其他方式。

• 區分什麼是不可信的，什麼是可信的。

可信的不需要驗證，不可信的選擇性驗證。在我們遊戲裡面，所有客戶端發送的消息都認為是不可信的，所有服務端發起的調用都是可信的。比如在下面介紹的移動模塊防外掛機制，當服務端的其他模塊比如機關模塊通知我的移動模塊瞬移，這種情況我不考慮機關模塊是否可能是被外掛操作了，我認為都是可信的。當然這個機關可能是被客戶端操作，那麼這時候客戶端是不是用了外掛應該是由機關模塊來判斷和驗證。

下文以玩家在客戶端操作自己的單位移動為例，介紹移動模塊為了防外掛做了什麼工作。

之前寫過技能模塊的防外掛內容，大家可以點擊「閱讀原文」查看。

我們遊戲的移動同步邏輯的基本原理是：單位在主控端（玩家自己的客戶端）根據玩家輸入執行移動邏輯，然後將位置點以及時間信息以一定的頻率發送給從端，服務端以及其他客戶端根據主控端發來的移動同步信息模擬、預測、糾正單位的位置。

基於以上同步機制，移動模塊需要考慮三種外掛情況：

1.主控客戶端偽造或篡改瞬移消息。

2.主控客戶端修改本地內存中的移動速度。

3.主控客戶端使用加速器

2.1 防止客戶端發送非法瞬移消息

由於我們遊戲所有的移動都是在主控客戶端發起和執行，然後服務端跟隨，所以瞬移也是客戶端先執行，然後通知服務端。

為了保證客戶端不能發送非法瞬移消息，我們將瞬移流程定義為：由服務端發起、客戶端執行、服務端再驗證。

瞬移邏輯如下圖所示：

1. 服務端發起瞬移，但是並不將單位移動到對應位置，而是將瞬移信息發送給客戶端。

2. 客戶端收到位移信息后，將單位移動到對應位置。

3. 客戶端發送一個瞬移消息給服務端，服務端收到后，將單位移動到對應位置。

基於以上瞬移流程，可以比較簡單的實現瞬移防外掛功能。

1. 服務端發送瞬移信息給客戶端時，記錄下來瞬移目標的位置。

2. 服務端收到客戶端的瞬移消息，進行以下驗證：

2.1 若服務端沒有發送瞬移消息給客戶端，則瞬移非法。

2.2 若收到的瞬移位置與記錄的瞬移位置不同，則瞬移非法。

基於以上流程，可以保證瞬移雖然是客戶端執行的，但是仍然由服務端發起和驗證。

2.2 檢測不合理的移動速度

對於移動邏輯，還需要防止一種外掛：改內存中的移動速度。

對於這種外掛的預防，一般有兩種：1.在客戶端通過一定的加密手段使玩家無法找到移動速度，從而無法改變。2.服務端驗證。我們使用的是服務端驗證的方式。

服務端驗證的基本原理：

當客戶端發來一個移動消息時，服務端根據此條消息和上一條消息可以計算出來兩消息之間的移動速度，然後根據服務端信息可獲得對應時間的伺服器認為可以達到的最高速度，比較后即可以驗證。

其中服務端如何獲得對應時間的允許最高速度是其中的難點。剛開始，我們使用的方式是記錄每次移動速度改變的時間和速度值，當收到客戶端消息時，根據客戶端發送消息的時間去查該時間對應的速度值。

但這裡有一個問題：當一個擊飛事件移動速度改為300，擊飛事件結束前又來了一個普通移動事件速度改為40，其實這時的移動速度其實是300，但根據我們的演算法計算出來的是40.

因此，我們實現了一套基於改變移動速度事件的移動速度驗證機制。我們並不記錄速度改變得值，而是記錄速度改變事件的開始&結束時間和速度值，因此每次需要計算某時間對應的速度時，根據速度改變事件的信息可以計算出準確的值。

2.3 檢測加速器

遊戲外掛最常見的就是加速器，在我們的遊戲移動機制中，加速器可以讓客戶端的單位移動速度變快，而我們是將客戶端單位位置同步給服務端，若服務端沒有任何驗證，則服務端就會跟隨客戶端位置，加速器外掛就會生效。

加速器外掛的原理是加快的客戶端的時間流逝，因此，最簡單的方式是當服務端收到同步消息時，從同步消息中拿出來客戶端發送消息的時間，若客戶端發送時間大於服務端當前時間（會加一個閾值），則認為是使用外掛。

遊戲中有時間校準機制，當玩家短線重連時，客戶端和服務端會重現校準時間，而校準后的時間由於網路延遲和網路波動問題，可能出現各種情況，包括客戶端時間快於伺服器時間。對於這種情況，會造成誤判。

為了解決這個問題，我分析了加速器的特點。加速器會導致客戶端時間持續不斷的加快，並和伺服器的差距越來越大。因此，我們使用以下驗證機制，基本可以避免誤判：

1.若客戶端時間>服務端時間+[閾值]，則[閾值] += (客戶端時間-服務端時間)

2.第1步重複n次，n是我們給客戶端出現異常的機會次數，我們遊戲n=2。

3.若客戶端時間>服務端時間+[閾值]，則認為客戶端是外掛。

通過這種方式，我們給客戶端一次或者多次機會，對於加速外掛，它會導致客戶端時間持續加速，最終使用掉所有的機會。而由於網路波動導致的客戶端校準后的時間快於服務端時間的情況，不太會使用掉所有的機會。

當然，這種監測方案理論上仍然存在誤判。但因為每次切換場景都會重置，當n=2時，經測試分析出現的誤判情況極少。

若把n改成更大，會導致玩家進入一個新場景后，若加速倍率比較小，比如加速0.1倍，可以使用較長一段時間的加速外掛。

附：運維log可以檢測加速器外掛的使用，但log更多的是檢查，而不是預防。我們這裡實現的是預防，保證玩家無法使用加速器獲得任何收益。