【胖虎的逆向之路】02——Android整体加壳原理详解实现

创始人

2024-05-10 00:18:34

0次

【胖虎的逆向之路】(02)——Android整体加壳原理详解&实现

Android Apk的加壳原理流程及详解

文章目录

【胖虎的逆向之路】(02)——Android整体加壳原理详解&实现
前言
一、加壳前的知识储备
- 1. Android 应用的启动流程
- 2. Android 应用的安装
- 3. Android应用的启动流程（待补充）
二、整体加壳的原理详解
- 1. 整体加壳原理
- 2. 自定义类加载器
- - 1）替换类加载器
  - 2）类加载器的插入
三、整体加壳案例实现
- 1. 编写源程序
- 2. 编写壳程序
- 3. 动态加载
总结
参考资料

前言

上文中讲到了关于Android中动态加载和类加载关系的详解，也是我们本章的基础

【胖虎的逆向之路】01——动态加载和类加载机制详解

为了深入了解Android 逆向相关的内容中加壳的原理，前面已经完成了关于Android中的动态加载和动态加载类关系的详解,那么接下来是对Android的整体加壳进行实现，并对原理进行讲解，由于作者能力有限，会尽力的详细描述整体加壳的流程及原理，如本文中有任何错误，烦请指正，感谢~

一、加壳前的知识储备

1. Android 应用的启动流程

启动流程这个是老生常谈了，很多面试都会问这个，实际工作中一般应用开发其实是不用关心的（ps：面试造航母，工作拧螺丝）但是对于逆向而言，其实熟悉Android 应用的启动流程，是可以避免走入很多误区的，从而提升工作效率，走向人生巅峰，赢取白富美…算了还是醒醒吧哈哈哈

不过既然要了解App加壳原理，首先就要从App的启动流程出发，在App启动之前，Android系统是启动最早，接下来我们来详细捋一下Android系统的启动过程是怎么样的~

系统启动流程图

相信做Android的你，或多或少都对这个图有些人熟悉，~~我都要看吐了~~ 首先我们来用大白话讲一下就是：

1.首先Boot Loader 启动，也就是开机电源
2.到kernel层启动idle进程
3.到navite 层初始化init进程，再解析执行init.rc,最后到我们的app_process
4.app_process中会通过jni fork出zygote进程，然后zygote 孵化出相关服务进程
5.之后的每一个应用启动的进程，都会由zygote孵化出来一个进程
6.并且会将ClassLoader传递过来（上文的知识）

那么从以上的大白话中，我们明白 Zygote进程孵化出了第一个进程SystemServer进程，而SystemServer进程是Android的重中之重，他完成的工作主要是（我们所关注的）StartBootstrapServices（启动引导服务）在其中比较重要的是ActivityManagerServices （四大组件调度管理服务，其中国Ac调度交给了ATMS）还有一个是PackageManager(提供对包的管理，包括扫描、安装、卸载)，主要是AMS、PM ，其余没有太过关心，有需要的同学可以去自行查阅什么都可以查到

2. Android 应用的安装

刚才明确了我们的PM（PackageManager）其主要的功能是完成了Android应用中包的管理，但是PMS是一个抽象类，真正的实现类是 PMS(PackageManagerService) ，我们通常看到的安装方式是系统启动安装、手动点击安装、还是ADB命令执行，不管是那种安装类型其都会走以下三个方法：

1.com.android.server.pm.PackageInstallerSession.commit（ IntentSender,boolean）安装session的提交
2.com.android.server.pm.PackageManagerService.installStage（ActiveInstallSession）开始整合安装
3.com.android.server.pm.Installer.createAppData(xxx) 安装完成

ps：检测第一个方法的开始到第三个方法的完成，可以明确该应用的安装时长~

并且应用程序在安装时涉及到了几个重要的目录：
在这里插入图片描述

我们针对PMS的认识，在这里可以暂时了解到这里，那么其实抛开PMS，还有一个很重要的服务AMS的服务流程，具体是怎么样的，大家可以自行百度 Google（狗头）后续如果有同学相关问题，欢迎随时沟通~

3. Android应用的启动流程（待补充）

二、整体加壳的原理详解

1. 整体加壳原理

可以简单理解成 Dex整体加壳在源Apk程序外面又套上了一层外壳

在这里插入图片描述
由此图可以看得出来，源APK外面套了一层壳Dex，最终组成了新的Dex（Apk）

这里如果你大概看不懂的话，可以去参考上一篇文章【胖虎的逆向之路】01——动态加载和类加载机制详解

在这里我借用前辈已经发出来的图，作为案例讲述，如下图所示，我们打开一个整体加壳的样本

在这里插入图片描述
看代码很明显，除了一个代理类Application，其他相关的代码信息都没有找到（不要用jadx看，因为实现方式不同）

继续看图~
在这里插入图片描述
在代理类中反射调用了一些方法，很显然我们解析出的结果都没有发现，那么就说明在Application.attchBaseContext()和Application.onCreate()中必须要完成对源dex的动态加载

综合上面的逻辑流程，App加载应用时解析的应该是这个流程：

（1）BootClassLoader加载系统核心库
（2）PathClassLoader加载APP自身dex
（3）进入APP自身组件，解析AndroidManifest.xml，然后查找Application代理
（4）调用声明Application的attachBaseContext()对源程序进行动态加载
（5）调用声明Application的onCreate()对源程序进行动态加载
（6）进入MainActivity中的attachBaseContext()，然后进入onCreate()函数，执行源程序代码

2. 自定义类加载器

在刚才的描述中，很明确的了解了壳加载的过程，从开始到结束均是使用PathClassLoader来加载dex，而在上篇文章中讲过，进行动态的加载dex文件时，必须使用自定义的classloader~
所以这时候小明去直接使用了dexclassloader进行加载，很不幸，报错了~
我们来看下原因：

DexClassLoader加载的类是没有组件生命周期的，DexClassLoader即使通过对APK的动态加载完成了对组件类的加载，当系统启动该组件时，依然会出现加载类失败的异常（静态变量、代码块没有初始化）

所以当我们想要使用dexclassloader进行类的加载的时候，需要自定义类的加载器

一下有两种办法实现：

（1）替换系统组件类加载器为我们的DexClassLoader，同时设置DexClassLoader的parent为系统组件加载器
（2）打破原有的双亲委派关系，在系统组件类加载器PathClassLoader和BootClassLoader的中间插入我们自己的DexClassLoader

1）替换类加载器

标题都写好了，怎么去进行呢？经过我们的分析，ActivityThread中有个loadApk，经查阅发现，loadApk主要负责加载apk程序，我们可以进一步的查下源码

在这里插入图片描述
通过看源码得出，我们可以通过反射获取mclassLoader，然后使用自己的DexClassLoader进行替换，就可以成功的让Dexclassloader获得生命周期了~

源码具体实现：

总结：
（1）获取ActivityThread实例
（2）通过反射获取类加载器
（3）获取LoadedApk
（4）获取mClassLoader系统类加载器
（5）替换自定义类加载器为系统类加载器

public static void replaceClassLoader(Context context,ClassLoader dexClassLoader){ClassLoader pathClassLoader = MainActivity.class.getClassLoader();try {//1.获取ActivityThread实例Class ActivityThread = pathClassLoader.loadClass("android.app.ActivityThread");Method currentActivityThread = ActivityThread.getDeclaredMethod("currentActivityThread");Object activityThreadObj = currentActivityThread.invoke(null);//2.通过反射获得类加载器//final ArrayMap> mPackages = new ArrayMap<>();Field mPackagesField = ActivityThread.getDeclaredField("mPackages");mPackagesField.setAccessible(true);//3.拿到LoadedApkArrayMap mPackagesObj = (ArrayMap) mPackagesField.get(activityThreadObj);String packagename = context.getPackageName();WeakReference wr = (WeakReference) mPackagesObj.get(packagename);Object LoadApkObj = wr.get();//4.拿到mclassLoaderClass LoadedApkClass = pathClassLoader.loadClass("android.app.LoadedApk");Field mClassLoaderField = LoadedApkClass.getDeclaredField("mClassLoader");mClassLoaderField.setAccessible(true);Object mClassLoader =mClassLoaderField.get(LoadApkObj);Log.e("mClassLoader",mClassLoader.toString());//5.将系统组件ClassLoader给替换mClassLoaderField.set(LoadApkObj,dexClassLoader);}catch (ClassNotFoundException e) {e.printStackTrace();} catch (NoSuchMethodException e) {e.printStackTrace();} catch (IllegalAccessException e) {e.printStackTrace();} catch (InvocationTargetException e) {e.printStackTrace();} catch (NoSuchFieldException e) {e.printStackTrace();}}

2）类加载器的插入

在动态加载中我们讲述了类加载器的双亲委派机制，就是说我们的类加载器刚拿到类，并不会直接进行加载，而是先判断自己是否加载，如果没有加载则给自己的父类，父类再去判断，递归向上，所以可以尝试让DexClassLoader成为PathClassLoader的父类~

总结：
（1）将DexClassloader父节点设置为BootClassLoader
（2）将PathClassLoader父节点设置为DexClassloader

代码实现：

public static void replaceClassLoader(Context context, ClassLoader dexClassLoader){//将pathClassLoader父节点设置为DexClassLoaderClassLoader pathClassLoaderobj = context.getClassLoader();Class ClassLoaderClass = ClassLoader.class;try {Field parent = ClassLoaderClass.getDeclaredField("parent");parent.setAccessible(true);parent.set(pathClassLoaderobj,dexClassLoader);} catch (NoSuchFieldException e) {e.printStackTrace();} catch (IllegalAccessException e) {e.printStackTrace();}}

完成自定义的类加载器后，我们就可以正常的加载壳dex了