網絡游戲的網絡協議設計之防外掛

網絡游戲的網絡協議設計之防外掛

我們不能期望提供完全安全的通訊,但我們可以讓攻擊者的麻煩大于其獲得


  • 任何對發送者的協議body(通訊的實際數據)序列進行的修改都應該被檢測到
    • 我們只處理body的發送
    • 對于報文的順序和可靠性問題交給底層協議棧去解決.
  • 對于篡改報文
    • 針對此類攻擊的第一線防御是一個簡單的checksum
    • 校驗和的計算范圍需要包括包頭在內的整個報文
    • 發送者計算報文的checksum并與報文一起發送給接收者
    • 一個完美的校驗和算法能對任意修改過的報文計算出不同的值
    • MD5算法是一個經過廣泛測試,可以公開使用的單向hash函數
    • 缺點:
      • 客戶端程序包含校驗和計算代碼 -> 攻擊者可通過逆向工程獲取校驗和算法 -> 然后對任何消息計算有效校驗和
      • 攻擊者可以捕獲有效包并在稍后重發,即packet replay
  • packet replay
    • 惡意用戶從客戶端捕獲報文,通常通過報文監聽 -> 多次發送 -> 然后以超過游戲允許的速度來執行命令
    • 服務器端可設置一個類似每秒一次的計時器來阻止這種攻擊 -> 但是因為可變的網絡延遲 ->導致合服的命令序列被拒絕
      • 不希望我們的安全機制將合法玩家當成欺騙者
    • 預防報文重放
      • 每個報文需要包含一些狀態信息->即使相同的有效body也要有不同的bit pattern
      • 一個隨著每個報文發送而累加的計數器之類的辦法就可以做到 -> 但是這種策略使攻擊者能夠很容易預期
      • 一個較好的方法是使用一個狀態機為連續的報文生成連續的序列號->算法快速并且足夠復雜
        • State = (State + a ) * b
        • a和b是仔細挑選出來的整數
        • 發送一個報文時-> 發送者生產一個隨機數并將之添加到報文中 -> 同時步進隨機數生成器
        • 接收者使用自己的生成器檢查收到報文中的隨機數->如果數字不匹配則表示報文已經被篡改->如果數字匹配,則接收者也步進隨機數生成器以準備接收下一個報文
      • 復雜之處
        • 發送者和接收者如何初始化并同步他們的狀態機
          • 可以使用固定種子啟動各自的狀態機 -> 但是初始報文流的位模式總是一樣 ->因為會成為可被分析的漏洞
          • 替代辦法:由服務器使用隨機生產的種子值初始化其狀態機
        • 如何在通信中保持狀態機的同步
          • 可信連接中 -> 包永遠不會丟失 -> 同步是有保障-
          • 當報文丟失或重新排序 -> 情況變的更加復雜
          • 如果消息被丟失 -> 發送者的狀態機比接收者的狀態機多步進一次 -> 后來的報文即使合法也都被拒絕
            • 簡單解決方案:使用一個在每個報文中發送的真實序列號 -> 通過這個序列號 -> 接收者可以決定需要步進它的狀態機多少次以適合當前報文
          • 如果應用程序允許無序發送(即可能會出現先發的數據包會后收到)->較老的狀態機狀態必須被保存以便在被打亂次序的報文抵達后使用
            • 如發送順序為A,B,C -> 但是收到的順序是B,A,C
            • 則對于如A包的校驗需要將將B的state保存 -> 等到A包到達后用該state校驗
  • 其他技術
    • 理想情況下 -> 為了阻擾對有效負載的分析->兩個具有同樣有效負載的報文在其模式上應該有盡可能少的相關性
    • 一個簡單的消除兩個集合之間相關性的方法是將其數據與一系列的隨機位進行異或操作(XOR)
      • A ^ randomSeed ^ randomSeed = A,如100 ^ 101 = 001 ^ 101 = 100
    • 上面描述的報文重發預防中 -> 發送者和接收者已經同步了隨機數生成器 -> 發送者可以為每個報文生成一個隨機數序列 -> 并將之與報文有效負載進行異或操作 -> 接收者生成相同的數字序列并以相同的方式獲取原始數據
    • 兩個具有相同長度的報文可能給攻擊者一個報文編碼相似數據的線索 -> 進一步干擾攻擊者 -> 每個報文可以包含一些可變長度的隨機垃圾數據 -> 其僅用來改變報文長度
      • 發送者檢測其狀態機決定需要生成并插入多少字節的隨機數作為垃圾數據到發送的報文中
      • 接收者只需要忽略垃圾數據
      • 增加垃圾數據總量可以進一步隱藏有效負荷 -> 但需要消耗額外的帶寬
  • 逆向工程
    • 客戶端包括完整的加密算法 -> 總是可以進行逆向工程 -> 這是最難解決的問題 -> 也是任何阻止協議篡改機制的根本弱點 -> 可以采用一些步驟增加逆向工程的難度

牢記你的目標是讓作弊的成本最大化 -> 而非完全禁止作弊

References

  • 《Game Programming Gems 1》1.11 # "A Network Protocol for Online games"
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,030評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,310評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,951評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,796評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,566評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,055評論 1 322
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,142評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,303評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,799評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,683評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,899評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,409評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,135評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,520評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,757評論 1 282
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,528評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,844評論 2 372

推薦閱讀更多精彩內容