Dex加固与反编译_dex反编译

作者：我家小花儿 | 2024-07-05 09:02:15

踩

dex反编译

编译与反编译

将java代码转换为Dalvik字节码
将res资源文件、AndroidManifest.xml等配置文件编译为二进制文件

将DEX文件转换为jar包或者Smali文件
将二进制资源文件还原为资源源码文件

编译与反编译是相对的过程，转换过程分别由编译器和反编译器实现。

ApkTool命令使用：
执行java -jar apktool.jar d demo.apk 命令，会生成以下文件和目录。
在这里插入图片描述

dex2jar命令使用:
执行d2j-dex2jar.bat demo.apk 命令,生成jar包。
在这里插入图片描述

jd-gui配合dex2jar使用，用来查看dex2jar生成的jar包
在这里插入图片描述

逆向分析：漏洞挖掘、协议分析
二次打包：盗版、破解。

代码混淆：Java代码、C/C++代码、JS/HTML代码
应用加固：Dex文件、SO文件、资源文件。

Dex加固方案演进
动态加载–>dex内存加载–>dex指令抽取–>虚拟机加固–>java2c>

动态加载:从服务器动态加载业务的DEX
DEX内存加载:模拟App启动的时候，将我们的壳、将业务DEX文件加载到内存中，然后通过一些处理方式，让DEX文件把Application启动起来，让应用认为和普通的启动方式是一样的 (缺点:DEX会暴露在内存中)
DEX指令抽取:把DEX文件中的一些方法的指令抽取出来，然后在内存中开辟一段区域，然后将我们内存加载的DEX解析到相应的方法指令偏移的地方，方法指令的偏移指向我们开辟的一段内存里面。(缺点:不彻底)
虚拟机加固:我们通过自己实现一套虚拟机，将DEX方法的指令抽取出来，在运行的时候，我们的虚拟机里面就运行被抽取的一段指令。这样攻击者想要破解，首先必须要找到我们虚拟机的入口，将虚拟机整个逻辑还原出来，这样攻击成本相对比较高 (缺点:本身Android应用就运行在虚拟机里面，不论是Dalvik还是ART，增加个虚拟机，就会增加一层对应用运行时代码的解释执行操作，那么解释执行的效率会大大下降)
JAVA2C:提升应用运行时的效率，我们的方法会转换为一层在Native(JNI)上实现的逻辑，最终通过JNI编译成so，这样的话在本地执行，而不是在虚拟机执行，执行效率会大大提升。

整个演进方向是从Java到C/C++,本地方法的安全性大于Java。粒度也由方法缩小到指令。
壳和被加固的dex耦合性增加，增大脱壳难度。

Android加壳框架原理为Proxy/Delegate Application，即使用自定义的代理Application类作为程序入口（修改AndroidMani.xml），在代理Application中完成壳的解密操作，最后启动原来的Application。

ProxyApplication：框架会提供一个ProxyApplication的抽象基类（abstract class），使用者需要继承这个类，并重载其initProxyApplication（）方法，在其中改编surrounding，入替换ClassLoader等。

DelegateApplication：即应用原有的Application，应用从getApplication（）等方法中取的的都是DelegateApplication。

在这里插入图片描述

在这里插入图片描述
在ProxyApplication中实现如下内容

在这里插入图片描述

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家小花儿/article/detail/789727