2016-05-11 13,826 ℃
前言
原本这篇文章是打算在五一期间写的,结果五一被人拉去逛漫展,在外溜达了一个多星期才回到宿舍,然后就完全忘了这事,昨天被群里提了一句才想起来Σ( ° △ °|||)︴
DLL被动的手脚太多了,又是MetaData修改,又是opcode修改的。所以这次只说一下不解密的投机取巧的修改方法(我才不会说是因为没搞定呢)。
MetaData简单修复
首先简单的修复一下MetaData使Tables能够正常查看,以方便修改,步骤如下:
用CFF Explorer打开DLL,选择.NET Directory,修改MetaData RVA为001AEDD4(原因写在下面)
保存后重新打开,选择MetaData Header,修改Signature为424A5342(字符串“BSJB”),再点击MetaData Streams,把5个地址全部加4,如下图
保存,这时候就可以用.NET Reflector查看类,以及成员和函数的名称了
看不懂?没事,对照下github上mono源码就显而易见了,这个函数实际上就是load_metadata_ptrs
没错,它就是把MetaData的RVA地址与0xE9B03A28做了个异或,所以真正的RVA地址应该是0xE9AAD7F0 ^ 0xE9B03A28 = 0x1AEDD8
然而并没有这么简单,经过研究发现MetaData Header也被做了手脚,其中Signature的4个字节是直接被删掉了,为了能让.NET Reflector可以反编译,得把Signature补上,这里我选择把RVA地址减4来存放Signature,也就是0x001AEDD4,而且刚好前面4位都是0(实际上这4位是Resources的位置)
开始修改
先说下怎么查看一个函数的地址,下面的修改都用到了这个方法,就不再重复说了
以修改攻击力的BattleServantData下的getBaseATK函数为例
用.NET Reflector打开上面修复好的DLL,搜索“getBaseATK”这个函数,跳到函数后,使用reflexil插件切换到attributes选项卡
RVA地址就是了,不过我们得换算成物理地址,在CFF里选择Section Headers,查看.text段的Visual Address和Raw Address,如图
计算公式:物理地址=RVA-Visual Address+Raw Address
所以getBaseATK这个函数的物理地址就是0x16D24 – 0x2000 + 0x200 = 0x14F24
接下来正式开始修改
1.攻击力
2.一回合结束战斗
关于DLL的加密
最后再扯下DLL的加密部分,前言就已经说了,这次DLL动手脚非常多,除去上面说的MetaData部分,目前有发现的就是Method Body里的opcode。opcode做的手脚就是把部分opcode所对应的16进制做了一个交换,比如把 ldstr(0x72) 改成 ldind.u1(0x47) ,在
libmono的mono_mb_emit_ldstr这个函数里可以清楚的看到
这个要修复起来还是很容易的,把对应关系全找出来写个程序处理下就好了
大神,能够留下您的联系方式,想要请教一下您关于fgo 动态调试的一下问题
請問,是一定要免檢才能改修嗎,最近看到大家都在嚎說P大沒出免檢
Can you plz create root APK for latest ver? i BEG you! I known there is some other way, but it dont work for me, and it need TONS of RAM.謝謝
Hello where is the 1.14.1 cracked apk for root?…. 你好在哪里1.14.1破解的apk根的手机?
大神求教一下做免检的思路,有偿也可。。
大神,给几小时网上指导么,有偿。。。。望qq联系
求dalao续命
删除1.14验证检查,请
P神留个支付宝啊
新版的乖离国服也使用修改metadata的方式来干扰反编译了…
我用您提供的思路去反编译了libmono的load_metadata_pstr…发现并没有异或一个数值…
然后在想是不是只有Header动了手脚…想用CFF改, 发现Signature值是N/A无法修改
只能找您寻求意见了!
是我自己犯傻…太久没解开过dll
把解dll和csv解密方法弄混淆了…目前国服乖离还是用旧方法即可
抱歉打扰了
大佬,求更新免检哟,表示已经彻未眠QAQ
这次更新又不能进游戏了QAQ
菊苣还有免检测端吗
求问InAppPurchaseActivity里的运算是怎么解读出来的?
lib__6090__.so解密后的a函数啊
你还可以直接对照上一个版本的代码,因为只是常量加密罢了
你的意思是,SO檔本身也被加密過嗎?我目前還沒搞清楚他的做法,但是有在其他記憶體空間(非SO檔的)看到SO檔的代碼,覺得很奇怪
边解密边执行的,代码解密后再载入执行,所以出现你说的情况
……完全没想起对照旧代码这事,惭愧。
6090则是偷懒了,打开以后就看了眼结构没去跟
这么说来dll加密的载入也在6090里吧?libmono对照github看F5貌似没啥改动
6090解密后会重写mono_image_open_from_data_with_name,重写的函数也要解密后才能看到
好像新的1.11.1失效了 没有用到 getBaseATK?
只想这方法还适用于1.10.1版的吗?
适用,opcode你需要自己对照下
想請問
如果只單純修改敵方攻擊為零該如何修改HEX
想请问这款能用Ida动态调试dump出解密过的dll么?
这不是单纯的加密
有具体的修复方向么
只是修复到能看的程度我已经写在上面了
哈哈,太牛了。这个方法蛮简单的。希望能有更好的方法