Fate/Grand Order相关

2016-05-11 13,826 ℃

版本:1.9.0

前言

原本这篇文章是打算在五一期间写的,结果五一被人拉去逛漫展,在外溜达了一个多星期才回到宿舍,然后就完全忘了这事,昨天被群里提了一句才想起来Σ( ° △ °|||)︴
DLL被动的手脚太多了,又是MetaData修改,又是opcode修改的。所以这次只说一下不解密的投机取巧的修改方法(我才不会说是因为没搞定呢)。

MetaData简单修复

首先简单的修复一下MetaData使Tables能够正常查看,以方便修改,步骤如下:
用CFF Explorer打开DLL,选择.NET Directory,修改MetaData RVA为001AEDD4(原因写在下面)
保存后重新打开,选择MetaData Header,修改Signature为424A5342(字符串“BSJB”),再点击MetaData Streams,把5个地址全部加4,如下图
QQ图片20160510164324
保存,这时候就可以用.NET Reflector查看类,以及成员和函数的名称了

libmono.so中0x001D5974这个位置的函数,有这么一句
QQ截图20160510161401
看不懂?没事,对照下github上mono源码就显而易见了,这个函数实际上就是load_metadata_ptrs
QQ截图20160510161533
没错,它就是把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选项卡
QQ截图20160510224918
RVA地址就是了,不过我们得换算成物理地址,在CFF里选择Section Headers,查看.text段的Visual Address和Raw Address,如图
QQ截图20160510210345
计算公式:物理地址=RVA-Visual Address+Raw Address
所以getBaseATK这个函数的物理地址就是0x16D24 – 0x2000 + 0x200 = 0x14F24
接下来正式开始修改

1.攻击力

修改位置在BattleServantData下的getBaseATK函数,这里直接返回一个大数据即可,比如100W,也就是
ldc.i4 10000 对应hex 20 40 42 0F 00
ret 对应hex 2A
用16进制编辑器打开1.9的DLL,跳到getBaseATK函数位置0x14F24
QQ截图20160510212332
1E到2A就是整个Method了,其中1E是Method Header从20开始才是Method Body,把Hex修改上去,会发现少了一位,用00(nop)填充即可
QQ截图20160510212905
注:敌我都有效

2.一回合结束战斗

修改位置在BattleData下的checkEndBattle函数,让这个函数直接返回false即可,即
ldc.i4.0 对应hex 16
ret 对应hex 2A
跳到1.9下checkEndBattle函数的位置0x13B9A,第一个4A是Method Header,函数长度是12,从第二个开始填上数据,剩下的部分依旧用00填充即可
QQ截图20160511020032

关于DLL的加密

最后再扯下DLL的加密部分,前言就已经说了,这次DLL动手脚非常多,除去上面说的MetaData部分,目前有发现的就是Method Body里的opcode。opcode做的手脚就是把部分opcode所对应的16进制做了一个交换,比如把 ldstr(0x72) 改成 ldind.u1(0x47) ,在
libmono的mono_mb_emit_ldstr这个函数里可以清楚的看到
QQ截图20160511002229
这个要修复起来还是很容易的,把对应关系全找出来写个程序处理下就好了

Fate/Grand Order的那些事

日服v1.15 在一个月的时间里经历了太多事情,现在终于可以慢慢的写下这篇马后炮了。 调试 Fate/Grand Order在v1.11换了个保护并禁止了root过的手机,其实当时...

阅读全文

28 条评论

  1. 大神,能够留下您的联系方式,想要请教一下您关于fgo 动态调试的一下问题

  2. 請問,是一定要免檢才能改修嗎,最近看到大家都在嚎說P大沒出免檢

  3. 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.謝謝

  4. Hello where is the 1.14.1 cracked apk for root?…. 你好在哪里1.14.1破解的apk根的手机? :sad:

  5. 新版的乖离国服也使用修改metadata的方式来干扰反编译了…
    我用您提供的思路去反编译了libmono的load_metadata_pstr…发现并没有异或一个数值…
    然后在想是不是只有Header动了手脚…想用CFF改, 发现Signature值是N/A无法修改
    只能找您寻求意见了!

    1. :???: 是我自己犯傻…太久没解开过dll
      把解dll和csv解密方法弄混淆了…目前国服乖离还是用旧方法即可
      抱歉打扰了

    1. lib__6090__.so解密后的a函数啊 :!:
      你还可以直接对照上一个版本的代码,因为只是常量加密罢了

    2. 你的意思是,SO檔本身也被加密過嗎?我目前還沒搞清楚他的做法,但是有在其他記憶體空間(非SO檔的)看到SO檔的代碼,覺得很奇怪

    3. ……完全没想起对照旧代码这事,惭愧。
      6090则是偷懒了,打开以后就看了眼结构没去跟 :oops:
      这么说来dll加密的载入也在6090里吧?libmono对照github看F5貌似没啥改动

    4. 6090解密后会重写mono_image_open_from_data_with_name,重写的函数也要解密后才能看到

欢迎留言

8 + 4 =