浅谈android代码保护技术_ 加固

2022-10-06 21:13:42

浅谈android代码保护技术_加固

导语

我们知道Android中的反编译工作越来越让人操作熟练，我们辛苦的开发出一个apk,结果被人反编译了，那心情真心不舒服。虽然我们混淆，做到native层，但是这都是治标不治本。反编译的技术在更新，那么保护Apk的技术就不能停止。现在网上有很多Apk加固的第三方平台，最有名的应当属于：爱加密和梆梆加固了。其实加固有些人认为很高深的技术，其实不然，说的简单点就是对源Apk进行加密，然后在套上一层壳即可，当然这里还有一些细节需要处理，这就是本文需要介绍的内容了。

类装载器ClassLoader

Java中.class 文件类似于我们的windows 的DLL或者Linux下的.SO 文件，在Winodows 下我们使用DLL的服务，我们必须使用使用LoadLibaray函数加载它。同理在java中我们要使用.class

中的的类，我们必须使用类加载器加载后，才能使用。在android中我们如果提供一个DexClassLoader(继承 ClassLoader), 这个DexClassLoader 可以用来加载.jar, .apk, .class 文件。可

以在android源码中找到这个类的实现：

关于的DexClassLoader使用，DexClassLoader 只有一个构造函数，如下。这里我们特别关注的是ClassLoader parent. 关于ClassLoader 有一个特性：子ClassLoader加载过的类

可以访问/使用父ClassLoader加载过的类，而父ClassLoader加载过的类不可以访问父 ClassLoader。对于这个值我们一般获取当前的加载器器，当前的加载器。

类装载器的替换

如何替换原来的ClassLoader，关于为什么要替换原始ClassLoader，笔者在一个简单加固案例会阐述的。

1.在Android源码搜索关于ClassLoader 的引用, 由于Android源码中ClassLoade应用特别多，搜索应用仅限Java 源码

2.在众多引用有一个类LoadedApk，于是查看觉得这就是我们想要的类

从类作用描述可知这个类，是用来维护已加载的APK的信息，并且里面有两个类加载器，mBaseClassLoader, 和mClassLoader. 显然我们我想要的是mClassLoader , 要想获得mClassLoader, 我们必须先获取LoadedApk 对象

3.在Android源码搜索关于LoadedApk的引用, 由于Android源码中LoadedApk应用特别多，搜索应用仅限Java 源码; 在众多引用有一个类ActivityThread, 从类作用描述看，是我们要找的类

从类的描述可知，这个类是用于来调度Activity.Bradcast，Severices 等组件的，并且在这个类中找到一个静态函数。获取当前activity的ActivityThread 对象

总结：

* 1. 反射调用这个函数 ActivityThread.currentActivityThread 拿到一个当前ActivityThread对象

* 2. 反射获取 ActivityThread对象的 final HashMap<String, WeakReference<LoadedApk>> mPackages 成员

* 3. 从mPackages获取已在加载的 LoadedApk 对象

* 4. 反射获取LoadedApk 对象的 LoadedApk.mClassLoader成员

* 5. 用新的ClassLoaded 替换原来的mClassLoader

代码如下：

Android加固简史

版本一：

加固方案

1.源APK文件存放壳APK的资源目录asset下

2.使用DexClassLoader 动态加载APK，并运行

1.重写Application, 默认情况一个android 应用程序启动一个默认的Application 对象，由于我们加固工具需要替换加固的的程序，我们必须在加固程序的Activity前动态加载我们APK。

我们可以选择重写Application 的虚函数 attachBaseContext 或者onCreate. 笔者选择在attachBaseContext 加载我们的原APK，并启动它

2.释放资源中源APK 到目标目录下（init函数）

3. 我们启动一个动态一个android应用程序程序，通常我们需要在某个组件使用意图Intent 启动，我们学习开发的时候，我们知道Intent 是两个组件通信的的关键，如果我们要启动android程序，我们必须有一个组件，所以启动代码在加固的工具的Activity。代码如下：

分析以上代码 Class clsDestActivity = dexClsLoader.loadClass("cr.dest.DestActivity"); 这句代码返回值为null的，为什么会这样，这是因为我们的当前ClassLoader 并不能加载源APK中类。

所以我们必须替换ClassLoader.

4. 新建一个DexClassLoader , 并且替换员ClassLoader. 关于替换ClassLoader 请参考上.

5. 资源如何替换

方案一：直接替换（手工替换）

方案二：代码替换

6. 如果员APK中lib有SO文件，需要释放到指定目录下，代码如下：

加固版本一原理：

1.由第一个版本，我们知道DexClassLoader可以实现，于是笔者根据去看DexClassLoader的实现，

再进基类BaseDexClassLoader的构造函数

在进DexPathList 的构造函数

在进makeDexElements函数

代码行为分析

a) 具体加载DexFile 还是使用loadDex 文件进行的，并且loadDex是个静态函数，猜想DexFile 可能除

在进loadDex函数

在进DexFile构造函数

发现我们使用了openDexFile , 这是我们最

进入Native层看openDexFile 的实现代码

发现调用核心函数addToDexFileTable, 再进

行为分析结果：

2.我们在从使用代码, ClassLoader的loadClass分析函数

再进

再进：

再进Native 的实现层：

原理总结：

1. DexClassLoader 构造函数就通过遍历.APK, .JAR包所有的dex,class 文件，依次通过DexFile的openDexFile，把DexFile的dex文件中添加到一张表中（Hash表）

2. 然后通过 DexClassLoader的loadClass 函数去加载类

版本一评价：

致命缺陷：直接暴露文件路径，在新建DexClassLoader类的时候，我们发现需要指定解压好的APK地址。

版本二：

我们知道加固版本一的缺陷在于需要指APK文件路径。为了更隐蔽写我们有两种改进方法：

1.重写一个ClassLoader, 这个ClassLoader 不须指定APK的路径，这样我们就不需要释放APK文件了。(代码量比较大)

2.不是ClassLoader替换的方法，而是在原来的ClassLoader 上直接添加一个类。定义一个类不需要指定.dex 文件路径

版本2的方法就是是使用第二种改进方案. 这个版本仅限在android4.0 - android5.0之间

原理：我们在分析版本一的原理，发现版本利用DexFile.openDexFile() 实现的，如果能在这个类找到一个相似的函数。于是代开在 android源码的\libcore\dalvik\src\main\java\dalvik\system 下的DexFile.java 文件, 类描述：的DexFile类就是负责把一个把文件中类加载到ClassLoader

于是笔者发现函数 native private static int openDexFile(byte[] fileContents); 加固版本二的核心在openDexFile 的参数，这个参数不需要指定具体文件，

而是直接文件的字节数组。这就我们隐藏文件的操作。顺藤摸瓜，笔者还发发现这几个函数。

里面有4个重要的静态方法：

native private static int openDexFile(byte[] fileContents);

native private static String[] getClassNameList(int cookie);

native private static Class defineClass(String name, ClassLoader loader, int cookie);

native private static void closeDexFile(int cookie);

于是笔者就可以利用四个函数可以实现加固版的原理：

a) 将源android应用程序的 lasses.dex 存放在加固工具工程asset 目录下, 并把源android应用程序的的资源替换加固工具的资源

b) 将classes.dex 的信息读取到ByeArrayOutputStream 字节数组流中。

d) 调用native private static int openDexFile(byte[] fileContents);得到DexFile 的cookie

e) 调用 native private static String[] getClassNameList(int cookie); 获取DexFile文件中所有的类名

f) 遍历e步骤的获取的类名信息，调用native private static Class defineClass(String name, ClassLoader loader, int cookie); 想当前的加载器注册类

g) 调用native private static void closeDexFile(int cookie); 关闭DexFile文件

实现代码案例：

然后就可以通过Class.forname 或者ClassLoader.loadClss 得到DexFile 的主Activity类，最后通过意图Inetent启动，调用startActivity

原理探索：

关于DexFile 是具体怎么实现，这就需要分析native 函数的实现，笔者在此就不再探索，笔者会另辟一篇文章来探究的

native private static int openDexFile(byte[] fileContents);

native private static String[] getClassNameList(int cookie);

native private static Class defineClass(String name, ClassLoader loader, int cookie);

native private static void closeDexFile(int cookie);

版本二评价：

运行版本要求高（android4.0 -android5.0之间版本，不包含android5.0）由于版本而依赖DexFile类中3个私有静态函数，由于这个四个私有函数并没有公开，

所以并不是所有版本都兼容。具体是否支持请查看对应android源码，笔者发现在android是支持的，但是在android5.0 就不支持了。如果不支持，笔者建议深入

native private static int openDexFile(byte[] fileContents);

native private static String[] getClassNameList(int cookie);

native private static Class defineClass(String name, ClassLoader loader, int cookie);

native private static void closeDexFile(int cookie);

的实现，自己重写一个。所以android源码的重要性不言而喻。

版本三：

版本一，版本二，都有个致命缺点，那就是在内存中有Dex 文件，利用这点，我们可以在内存中找到Dex 文件头，然后把文件dump下来，这样这两种加固都失效了。为了防止这一点我们，我们希望能在我们的Dex本身具有代码加密功能，并且在运行前，解密后运行, 这种技术叫做：运行时自修改字节码技术（RSMC，Run Self Modify Code) ,利用这种技术就可以把我们核心的代码使用DEX的运行。

问题：运行时自修改字节码技术（RSMC，Run Self Modify Code),一个重要的技术难点就是如何在DEX 字节码运行的时候，找到函数的实现地址。

现在笔者通过分析java.lang.reflect.Method类的invoke 函数字节码存储地址。这是invoke必定会找到函数的自己吗，并且解释执行这个字节码。

1.android源码找到java.lang.reflect.Method类的invoke的代码

再进invokeNative 函数查看

再进invokeNative的native 实现层查看代码

再进dvmInvokeMethod 查看：代码:(dalvik\vm\interp\Stack.cpp)

//nativeFunc 指的函数地址为字节码解释后的结构代码(JTI)

再进函数 void dvmInterpret(Thread* self, const Method* method, JValue* pResult)

发现当前线程的pc = method->insns 可知insns 是自己地址，结果存储在方法的字节码存储Method 结构的insns中

2.找到JNI编程jmethodID 和结构Method的关系，在Java层我们是无法拿到Method 结构体的，所以我们必须使用JNI编程。在JNI编程我们只能拿到一个函数jmethodID, 所以我们要找到这两个关系。

通过分析函数是如何GetMethodID是如何获取jmethod的。

所以加固版本三的原理：

a) 通过GetMethodID 获取获取jmethodid, 并强转Method*

b) 修改a步返回Method 的insns 所在页开启可写权限

d) 解密insns内容为源DEX 的功能

e) 解密后，又将代码加密回去，防止被Dump下

版本三案例：代码如下：

Java 层代码：

函数Sub：解密前是两数加法，经过decode 运行时解密为两数加法， encode 后字节码在此称为减法，修改字节码代码使用JNI本地代码实现。

本地解密代码的实现

代码行为分析：

a)调用GetMethodID获取结构体Method

b)调用mprotected 修改Method 结构中insns所在页属性

c)解密操作-》加法：0x90 减法：0x91

同理解密代码：不贴图了

版本三加固评价：

1.在android5.0 以上版本不再适用了，因为android5.0 强制是ART（Andorid Runtime）模式。 ART模式下，APK安装时，就会把字节码编译成汇编码，这个方法就不能使用了，由于没有字节码

运行时就找不到对象的字节码，这样加固后的android APP 是运行不了了。所以加固版本三模式不适合单独使用

2.特征代码，调用mprotected修改页属性，利用这点做对抗，

版本四：

版本四就是解决版本三在android5.0 不能使用问。我们可以使用版本3 和版本1或版本2 结合使用

原理：

1.版本3的运行时解密，静态反编译找不到代码/或者代码是错误的。

2.版本3的的DEX文件/JAR 文件使用版本1 或者版本2的方式动态运行。

关于ART 和Dalivk 的简介
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

ART： Android操作系统已经成熟，Google的Android团队开始将注意力转向一些底层组件，其中之一是负责应用程序运行的Dalvik运行时。Google开发者已经花了两年时间开发更快执行效率更高更省电的替代ART运行时。 ART代表Android Runtime，其处理应用程序执行的方式完全不同于Dalvik，Dalvik是依靠一个Just-In-Time (JIT)编译器去解释字节码。开发者编译后的应用代码需要通过一个解释器在用户的设备上运行，这一机制并不高效，但让应用能更容易在不同硬件和架构上运行。ART则完全改变了这套做法，在应用安装时就预编译字节码到机器语言，这一机制叫Ahead-Of-Time (AOT）编译。在移除解释代码这一过程后，应用程序执行将更有效率，启动更快。

ART优点：
1、系统性能的显著提升。
2、应用启动更快、运行更快、体验更流畅、触感反馈更及时。
3、更长的电池续航能力。

4、支持更低的硬件。

ART缺点：
1、更大的存储空间占用，可能会增加10%-20%。
2、更长的应用安装时间。

总的来说ART的功效就是“空间换时间”。

码农公寓