网络游戏的网络协议设计之防外挂

网络游戏的网络协议设计之防外挂

我们不能期望提供完全安全的通讯,但我们可以让攻击者的麻烦大于其获得


  • 任何对发送者的协议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阅读 216,142评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,298评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,068评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,081评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,099评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,071评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,990评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,832评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,274评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,488评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,649评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,378评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,979评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,625评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,643评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,545评论 2 352

推荐阅读更多精彩内容