UWP游戏防内存修改器的方法
小编导读:
二. 对需要保护的数值进行混淆
最近我一直在编写适用于Windows 10商店的游戏.这款游戏比较怕玩家用修改器改金钱,因为这种修改会导致某些内购失效并且损害公平性。于是我把自己见过的三种反修改器的方法给网友们介绍一下。
3.免疫修改,简单的修改后不影响游戏逻辑的正常工作或者干脆用一般的搜索手段找不到该改哪里。
用.NET Native编译(或者干脆用c++而不是.net语言),可有效防止反编译看你的加密和解密算法然后搜内存。
这种方案可行性比较高,具体的实现方法我在后面列出来。
四.混合使用保护方法
VB
一个需要保护的数值被赋值时计算新值的Hash值,在读取的时候就可以验证Hash值是否正确,如果发现读取的时候存储的数值与Hash值不对应,游戏就不应该继续进行下去。
End If End SyncLock End Get Set(value As T) SyncLock lock traps.Enqueue(value) If traps.Count > TrapSize Then traps.Dequeue() hashCode = ComputeHash(value) _Value = Encrypt(ConfuseTransform(value)) End SyncLock End Set End Property你可以给需要保护的值算一个Hash值保存起来,然后对原有值混淆后加密,并且向某个远离秘文和Hash值的地方写入一个假的数值误导修改器。
2.拦截修改,修改前就拦截掉
三. 加密需要保护的数值
比如说,你让你的UWP在PC不可用,那么修改内存这个操作本身就变得十分艰难了。
1.预防修改,防患于未然,让可用的修改手段减少。
这通常需要特权,目前很多游戏的反外挂保护程序就是这样做的。缺点很明显,就是兼容性差,甚至可能导致整个操作系统崩溃。
验证的时机可以调整,比如在游戏空闲的时候,存档之前,交易之前,交易之后 等关键时刻进行。
这是本文最后的代码示例,描述了一种混合多种保护方式的值的读写方法。
VB
总结一下,防止作弊与我们看病是一样的,对抗疾病,我们应该做好预防,早发现,早治疗,还要防止后遗症。
这种方法非常经典,与上面的方法接近,但是不会骗修改器。代码很简单,没必要给大家写了。
比如你的程序使用了一种代价低但是精确度不高的作弊检查手段(比如每1分钟扫描一次需要保护的数值,检查是否作弊了),那么发现作弊后可以启动更严格的作弊检查(例如,改成每秒检查是否作弊,或者是启用其它保护方式)。
VB
这样,使用简单的内存修改器的玩家会先找到陷阱,发现那里的值改了不起作用,使用exe分析程序找到了加密用的key和iv,尝试多种解密算法,可是解出来的值还是不能用常规的hash算法找到与内存中匹配的内容。这样几乎所有不会汇编的玩家会对内存修改这条路望而却步(除非某个会汇编的人写了修改器出来,不过要看懂.NET Native编译的程序还是挺难的)。
End If End SyncLock End Get Set(value As T) SyncLock lock _Value = value Hash = GetHashCode() End SyncLock End Set End Property首先说明一下我总结的防止游戏作弊的理念:
下面的示例代码描述了对读写过程的互斥,并且要计算Hash值。读取的时候要验证Hash值。
还要注意,在UWP或者其它Windows Runtime环境下,提升特权不仅难而且违法商店规定。
Public Property Value As T
Get
SyncLock lock
Dim val = TransformBack(Decrypt(_Value))
If ComputeHash(val) = hashCode Then
Return val
Else
Throw New CheatedException
图中是我的UWP游戏强行改内存后崩溃的图,我把游戏名称抹掉了。
混合前面的方法时同样要注意线程安全问题,考虑哪里需要互斥。
下面开始介绍在UWP上比较可行的防内存修改作弊的方法。
混淆的同时,还可以更新一个假的字段诱骗内存修改器上当(不过这样可能会让真的值暴露,所以混淆算法要好好设计,假的值在哪里放也要考虑清楚)
4.检测修改,能够在修改后发现被修改了,加强这种防范。
还有个问题是关于线程安全的。如果你修改了存储的值,但是还没来得及计算Hash值,另一个线程下一步修改了存储的值,那么这个验证就会发生错误。所以整个赋值的过程应该是互斥的。
至于发现作弊后做什么,我的选择是终止游戏,而且异常提示也是具有迷惑性的。
一. 用Hash验证数值是否被修改过
Public Property Value As T Get Return TransformBack(_Value) End Get Set(value As T) baitValue = value _Value = ConfuseTransform(value) End Set End Property
转载必须注明这是Nukepayload2原创的博文
让被保护的数值混淆,比较理想的情况是:实际值变大时存储的值不一定变大,实际值变小时存储值不一定变小,即使实际值变化后与原来的实际值等价存储的值也可能变得不一样。这样的保护既可以防止精准查找,也可以防止变大或变小的模糊查找。
Public Property Value As T
Get
SyncLock lock
If GetHashCode() = Hash Then
Return _Value
Else
Throw New CheatedException
热门资讯
05-29
·OK娱 乐【超 级 奖 上 奖】娱 乐05-29
·游戏开发商和运营商也正面临着其05-29
·成为一名动荡年代的武林侠士05-29
·游戏?电影?《将军与公主》楚河05-29
·不仅仅是游戏名称的改变05-29
·游乐场能让孩子放心“乐”吗?05-29
·2015-2016年网页游戏市场分析报05-29
·乐逗游戏是中国市场领先的手游发
传奇特荐
05-04
·《期间》评最具影响力50款科技产05-05
·虐心游戏《Choppa》评测:虐的就05-06
·慈文传媒第一季度矫正通告:上半05-19
·女主播直播斗鸡游戏 衣着暴露动05-19
·眼下就是花式告白的最佳时机05-19
·《白发魔女传》删档测试今日开启05-19
·整体音乐让游戏带入感非常不错05-20
·《诛仙手游》中还有凄凉肃杀的空05-21
·pass:深圳市巨彩科技05-21
·pass:棋牌游戏银商