x8沙箱怎么用GG修改器,x8沙箱怎么修改游戏

如果替代是以字节为单位的长度相同。把下方单引号里的汉字换成你想替换的就行了

UTF-8编码

UTF-16编码

昨天偶然得知了GG修改器。实在难耐好奇心。又拿了好几个小游戏实验。尝试了好几款之后发现都能改，但是就游戏体验而言还是勇士拯救计划打击感最好。就拿TA做例子。

65ss 时光套 + 洪荒之刃

60级金刚石巨剑；2 520 800

60级金刚石巨剑；2 520 800

接下来就可以放飞自我了，在4级图里面刷65SS，10分钟就可以凑齐一套了。

修改千万条，公平第一条。
检测不通过，封号两行泪。

GG修改器修改游戏数值教程：

1、打开修改器，给修改器悬浮窗权限，再打开游戏即可进行搜索数据修改。

拖出来，上dnSpy，理所当然地出错。

拖进UltraEditor，发现可以明显地看出PE文件结构，就是有点怪而已。所以这应该不是那种简单地把整个dll文件套个加密算法，然后加载的时候解密那种方法。

大概是加密了关键部分，然后在解析的时候再解密吧。

试一下能不能Dump，ida附加，结果游戏直接闪退，估计是有反调试之类的，咱一个逆向萌新，对安卓方面的反调和反反调完全不懂，瞬间懵逼。

于是咱打算换一个歪门邪道，用GG修改器的Dump功能，这个游戏似乎没有针对GG修改器做什么。

Dump下整个游戏进程，然后在里面搜索DLL，把文件提取出来，但是发现，其他什么UnityEngine什么的都有，唯独缺了Assembly-CSharp.dll。

抱着不祥的预感在内存中搜索6D 7A 90 00 03 00 00 00 04，发现dll文件本身在内存中没有半点变化……

估计是魔改mono文件，然后用自己的一套来解析的吧……

拖libmono.so到ida里面，结果发现libmono.so也被搞了……

看一下Hex，被大量无意义字节填充了，估计是在载入so的时候再将原函数填回去……

还真是到处搞事情啊，不过so方面不比dll，到了内存里面你总得把这些函数给我还回来吧。

还是上GG(真好用)，把libmono.so给Dump出来，记得选范围时要完整，宁可范围搞大一点，也别少选

修复一下Dump出来的文件，可以参考这里：内存dump 获得基于Unity3d的游戏相关代码

再拖进IDA，现在就没问题了

通过之前的试探，我们大概可以猜测一下dll被加载的过程，首先是原文件读入内存，再通过魔改后的mono使用自己的一套方法来解析文件。

看其他dll都没有事，所以在这个魔改后的mono中应该分开了两种不同的加载方式。

mono加载dll的时候，首先是进 mono_image_open_from_data_with_name这个函数(这个应该就不用细说了)，然后走到 do_mono_image_load对PE文件进行分析。

顺着加载过程摸下去，我们还可以找到魔改后同时认可PE和pe的部分

修改这里两处标识后之后，继续尝试读取dll文件，仍旧失败，根据失败原因继续走，发现时dll文件的段头被加密了，在mono中对应部分找到解密方法

段头的每一项都被单独处理，加密过程中密钥会随着改变的一个流加密，有伪代码的情况下还原解密方法没什么难度。

继续读取，发现PE结构解析部分没有问题，但还是出错了，继续往后跟，发现

都被或2了，同时，在这个函数中，还发现了对函数体解密的部分，正好一起搞了

然后，采用这种方法解密函数体后，反编译仍旧出错，排查了好久，发现在使用完解密完header和函数体后，它还在mono_method_get_header对函数体每一个字节异或0x30，真是麻烦，到处下坑。

解密完全部函数体，将它拖到dnSpy中，依旧爆炸……

虽然绝大部分函数炸了，但是却还有一些极小的函数可以被正常反编译

看到这里，我大概猜到它做了什么……

它应该是打乱了Opcode表，重构了读取Opcode的方法……

我自己也干过这事……在加密dll的时候打乱Opcode……

没辙，Opcode被打乱，我就只能对照着正常dll加载的函数和魔改版来分析修改后的Opcode表

分析Opcode的函数快两万行，我的电脑配置不够，要是用伪代码的方式一下就直接卡死，只能扣掉F5，一点点看汇编……

花了两个多星期，我才把新的Opcode分析完。它不仅仅打乱顺序，一些相邻的Opcode码，比如ldarg0，ldarg1这些，原版是采用n-ldarg0的方式来一次性分析这一个系列的Opcode，但是魔改版直接将n-ldarg0这个值固定死，然后把这些必须相邻的Opcode也拆开来分析了，给我造成了巨大的麻烦……

还原Opcode之后，再用dnSpy打开

代码被还原成功，可以被直接查看和修改了

②改变PE文件结构。在这个游戏中，它加密了段头部分，除此之外，还可以修改各个值的偏移量，数值等等，如果有那个精力和实力的话，你甚至可以重构mono对PE文件结构的解析部分，自创一个结构

④针对函数的加密。这其实不是什么新鲜玩意了，很久以前就有用hook掉mscorre的方法来加密函数体，在mono中只是实现起来更加方便一点。对函数体加密的话，可以保证使用Dump的方法几乎没啥用，毕竟内存中至始至终都没有出现过被解密的dll文件，攻击者一次最多Dump一个函数……

⑤最后，是最恶心的Opcode替换了。攻击者必须忍受恶心来对一个巨大的函数进行分析，这已经不是技术手段了，这是赤果果的精神攻击！由于在mono中对Opcode分析并没有封装，所以保护者必须对Opcode有一定的了解，否则一不下心就会出错。没有时间精力来了解这个的话，也有一个办法，之前举办过一个比赛，上面就有一个替换Opcode的例子。它对解析Opcode的函数没有更改，只改了Opcode.def文件中的值而已，算是利用了一个小巧合吧。比赛题目链接：Gslab 2017游戏安全技术竞赛

这一次对游戏dll的加密分析到这里就结束了，我也就将Note判定稍微改松了一点，来慰藉我这个手残受伤的心灵……

这个游戏有内购功能，所以为了厂商着想，就不放任何成品以及解密代码了，感兴趣的人可以根据什么的过程自行走一便，知道答案的解题过程不会很难……除了还原Opcode部分(不能让我一个人恶心！！！)

在网上查dll加密，铺天盖地的是XXTEA加密文件再在读取时解密，毫无新意，保护力度为5,。代码保护这种东西，怎么能用别人的成品？那不就相当于所有门用同一把锁，那把锁的钥匙都还满大街人手一份。

所以，保护厂商在做代码保护时，可以借鉴思路，但是绝对不能套用！否则就是对自己产品的不负责！

希望这里写的一点浅薄的东西能够给没有技术大牛支持的厂商们带来一点点思路。

– End –

戳 立即购买！

热门文章阅读

1、GandCrab V2.0 详细分析

2、SSDT-HOOK

4、看雪众测平台第15期，新项目已上线！

官方微博：看雪安全