写rxposed的时候，搞了很多模块，其中有一个远程调用脱壳的，但是当时使用的是rmi远程调用，因为一些问题无法使用，可能是对抗问题，也有可能是技术问题，所以我又换了一种远程调用方式。

android的dex加固，有整体dex加固，抽取加固，dex vmp,java2c，虽然有这么多，但是其实就脱壳主要是两个方面，第一个是整体dex脱壳，第二个就是在整体dex脱壳的基础上进行dex加密函数还原。抽取加固，dex vmp,java2c这些加固方式都以函数为粒度，进行函数代码的保护。

这个比较简单，有一些dex的文件是不进行加固的，直接解压apk就行，有些dex是加固过的，常用的dex不落地的内存加载，对于这种dex的脱壳都有个通用的方案，就是内存dump。dex在运行时总是要加载到内存中的，所以选择合适的时机是可以dump下来完整的dex的。

dexvmp,java2c，dex抽取，这些加固方案，在我看来其实都是函数方法抽取，dex抽取是代码抽取了以后，在运行时还原，dexvmp，java2c这些方案是抽取了以后将抽取的代码转变成了另一种代码，导致了无法自动还原，code_item消失。

可以，这种可执行文件加固，本质上就是一种静态加密，动态运行时解密，理论上只要在动态运行解密后dump下来就可以了。

因为直接在内存dump整体dex，然后在获取解密的code_item的修复到dex的方案，对于某些有针对性对抗的安全方案是无效的，对于比较简答的dex抽取确实没有问题

因为内存中dump下来的dex在修复code_item的时候，都是将dump下来的code_item，写到dex中code_item被抽取出来的位置，但是内存中dump出来的dex中，可能没有code_item的位置，可能是dex文件进行了重新编译的时候抽出来，也可能是定制了dex重编译，将特定的code_item抽出来，也有可能是修改了偏移位置等等

fart和frida-fart都是基于主动加载脱壳，但是fart是基于函数级别的主动加载，会在dex方法执行前夕进行dump,frida-fart是基于类加载的主动加载，颗粒度没有fart细，但是他们有同属于dex内存加密函数自动还原方式的脱壳，如果frida-fart不行，可能是有一些别的问题，如果fart，那么可能就是真的不行，这种方案就本身不行了。甚至可能不是dex抽取壳。

理论上可以，hook一些fart中dex函数主动调用需要用到的函数，确实可以，但是目前没有实践

fart和frida-fart具体怎么修复的我没有去了解，但是如果内存位置不够的话，先反编译dex，将code_item的字节码反编译然后写入到dex中（可能需要用smail写），然后在回编译，可能就可以了。当然，如果可以做到dex内存重组，也可以。

dex抽取相比于dex内存不落地加载，实现的难度高很多，但是在保护方面，强度确实好像并没有很高，有些确实有修复问题，但是实际上内存中都解密了。

可以看看这个博客
https://bbs.kanxue.com/thread-268760.htm#msg_header_h2_6

https://bbs.kanxue.com/thread-260052.htm

网上说fart是主动调用，但是我觉得不太准确，far和frida-fart其实都像是主动加载，博客里说的这些函数需要真正执行一次在dump,更像是主动调用

借鉴一段他的代码

函数本身就是壳代码，需要先执行一次，对本身进行解密。

还有一些强度更高的，被加密的函数执行以后，会先调用壳代码解密，然后调用执行原函数，然后在加密回去。甚至可以将dex指令揭秘一条，执行一条，循环解密，这些可能会需要一些技巧，但是都是fart或者说自动脱壳所无法做到的。

确实可能存在更高强度的抽取，我在研究的时候也一堆纠结，但是转换思路想写，抽取壳本身的兼容问题，写的强队越高，越复杂，兼容问题越严重，而且还有性能问题，一般越复杂的加密和解密，都意味着性能成倍的损耗。另外方案价值的问题，如果抽壳的方案写的如此复杂，就像我前面说的，解密要好几层，那么为什么不用dex vmp。

安全对抗中技术确实是一个问题，但是一个安全产品不是技术的高低问题，而是他是否能符合客户要求，在符合用户要求和最大化利益的情况下，提高技术上线。毕竟要吃饭，这也是对抗中防守方的弱势问题。

我在上一次写博客推荐我的rxposed的工具的时候，埋了个脱壳的坑，但是有些事没搞完。

讲个笑话：

当时我觉得fart这类工具确实是可以做到内存自动修复的，然后我屁颠屁颠的去找肉丝说我给你修一下，然后肉丝说你去搞搞银行app，然后我去了，我才发现这种code_item偏移位置有问题的dex,理论上确实能做，但是工程里估计很大，只能说，真是尴尬。

项目地址：

https://github.com/Thehepta/androidGRPC

rxposed项目博客地址：

https://bbs.kanxue.com/thread-280808-1.htm

上次博客里我写的使用rmi做的远程调用，然后脱dex,但是rmi在某些银行或者第三方加固公司中不知道为什么用不了，然后我就改成grpc远程调用了，native脱壳的代码完全使用的是frida-fart代码native话，然后我加了一点code_item位置修复，这部分对于我上面说的有防护方案的壳是没啥用。

工程分为两部分，一部分用idea打开，另一部分作为rxposed模块注入到用户进程，lsposed如果要使用，需要只需要加载进去执行入口代码，并且能够执行native函数。只要双方的端口能够通讯连接成功就可以。

grpc 的服务端在android平台上，会一直开启。

grpc 的客户端在pc上，可以随时断开。

部分代码

userServiceBlockingStub.dumpdex 会dumpdex到app目录下
userServiceBlockingStub.dumpClass(className) ，这个是远程主动调用类加载函数，来对函数进行解密，然后dump。

用了肉丝测试的几个商业app，都可以脱出来，但是银行类型的app不行，没法自动修复

grpc可以进行文件传输，可以直接将dex传输过来dump到pc上，目前还未实现.

如果有机会，可以将dex修复功能和grpc远程调用结合起来使用，可以一次性修复，或者动态dump想要的java函数的code_item。也可以和jadx或者gda

dex抽取壳脱壳，目前大部分使用的可能都是比较简单的抽取壳，我这种native-fart脱壳的方式就能脱下来

强度稍微高一点，code_item 修改偏移的抽取壳，这类目前确实市面上有，比如银行，这类fart也是可以脱下来的

目前dex抽取主要对抗的问题在于code_item修复问题上，脱壳工具在技术理论上是可以实现一体化修复的

更高强队的脱壳，技术上存在，并且有人举了例子，但是本人没有遇到过，不知道到底什么情况

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！