-
-
[原创]某渊某音游的dll保护分析，以及偷学一点Unity代码保护思路
-
发表于: 2019-4-28 02:35
-
本人虽然是个手残，却非常喜欢尝试各种音游，即使被虐到爆炸也停不下来。
最近看上一款某渊的音游，它的判定线移动打拍的玩法挺不错的，于是乎又手贱买了，然后被虐到体无完肤。
本着至少要给自己爽一下的原则，就准备对它下毒手了。
首先拆一下压缩包，发现是unity引擎，而且还是Assembly-CSharp.dll的方式，感觉也许会轻松不少（并不是
拖出来，上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文件进行分析。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 | static MonoImage *do_mono_image_load (MonoImage *image, MonoImageOpenStatus *status, gboolean care_about_cli, gboolean care_about_pecoff){ MonoCLIImageInfo *iinfo; MonoDotNetHeader *header; mono_profiler_module_event (image, MONO_PROFILE_START_LOAD); /* if MONO_SECURITY_MODE_CORE_CLR is set then determine if this image is platform code */ image->core_clr_platform_code = mono_security_core_clr_determine_platform_image (image); mono_image_init (image); iinfo = image->image_info; header = &iinfo->cli_header; if (status) *status = MONO_IMAGE_IMAGE_INVALID; if (care_about_pecoff == FALSE) goto done; if (!mono_verifier_verify_pe_data (image, NULL)) goto invalid_image; if (!mono_image_load_pe_data (image)) goto invalid_image; if (care_about_cli == FALSE) { goto done; } if (!mono_verifier_verify_cli_data (image, NULL)) goto invalid_image; if (!mono_image_load_cli_data (image)) goto invalid_image; if (!mono_verifier_verify_table_data (image, NULL)) goto invalid_image; #ifndef USE_COREE /* if the last bit is not set, then the image is mixed mode with native code */ if (!(iinfo->cli_cli_header.ch_flags & 1)) goto invalid_image;#endif mono_image_load_names (image); load_modules (image);done: mono_profiler_module_loaded (image, MONO_PROFILE_OK); if (status) *status = MONO_IMAGE_OK; return image;invalid_image: mono_profiler_module_loaded (image, MONO_PROFILE_FAILED); mono_image_close (image); return NULL;} |
首先是mono_image_load_pe_data函数对PE文件进行解析，这里有一个检验MZ头的步骤，而这个dll的头部是mz，所以这里应该有问题
不仅仅认正常的MZ，也认修改后的mz，没错了。
顺着加载过程摸下去，我们还可以找到魔改后同时认可PE和pe的部分
修改这里两处标识后之后，继续尝试读取dll文件，仍旧失败，根据失败原因继续走，发现时dll文件的段头被加密了，在mono中对应部分找到解密方法
段头的每一项都被单独处理，加密过程中密钥会随着改变的一个流加密，有伪代码的情况下还原解密方法没什么难度。
继续读取，发现PE结构解析部分没有问题，但还是出错了，继续往后跟，发现是.Net部分读取时出了问题
[招生]科锐逆向工程师培训(2025年3月11日实地，远程教学同时开班, 第52期)！
赞赏记录
参与人
雪币
留言
时间
東陽不列山
为你点赞！
2025-2-1 05:36
shinratensei
为你点赞~
2022-10-11 17:54
PLEBFE
为你点赞~
2022-7-27 01:44
心游尘世外
为你点赞~
2022-7-26 23:37
飘零丶
为你点赞~
2022-7-17 03:22
greenbie
为你点赞~
2022-5-21 13:07
pareto
为你点赞~
2021-2-15 11:45
shoker
为你点赞~
2019-9-11 23:10
luluting
为你点赞~
2019-7-27 15:56
v0id_
为你点赞~
2019-5-1 14:40
blackbin
为你点赞~
2019-4-30 21:46
caolinkai
为你点赞~
2019-4-30 09:55
黑的雪
为你点赞~
2019-4-29 16:02
goldengod
为你点赞~
2019-4-29 09:07
风间仁
为你点赞~
2019-4-28 21:00
DevilMayCry
为你点赞~
2019-4-28 16:33
Amun
为你点赞~
2019-4-28 16:00
yzlmars
为你点赞~
2019-4-28 15:00
AJISky
为你点赞~
2019-4-28 11:50
月落之汀
为你点赞~
2019-4-28 08:30
junkboy
为你点赞~
2019-4-28 07:09
|
|
|---|---|
|
|
分析的很好，
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
下面自动回复一万个赞
|
|
|
|
|
|
这样过不了Opcode那一关呀，而且这里主要就是要分析dll保护的机制 |
|
|
现在的萌新都是大佬假扮的
|
|
|
|
|
|
看不懂，但是把它看完了
|
|
|
|
|
|
|
|
|
楼主牛皮，类似网易盾的保护，开始流行起来了
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
