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

胖虎哥

发布于 2023-05-10 19:24:20

5290

发布于 2023-05-10 19:24:20

文章被收录于专栏：胖虎的研发之路胖虎的研发之路

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

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

前言

上文中讲到了关于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 应用的启动流程

Android系统启动的最后一步是启动一个应用（Launcher），这个应用程序用来显示系统中已经安装的应用程序，Launcher在启动过程中会请求PMS(PackageManagerService)返回系统中已经安装的应用程序的信息，并将这些信息封装成一个快捷图标列表显示在系统屏幕上~

这样用户可以通过点击这些快捷图标来启动相应的应用程序

（借助前辈已经画好的图）流程图如下：

1.点击桌面图标的时候，Launcher应用会调用startActivity方法，通过Binder通信，调用system_server进程中AMS服务的startActivity方法，方法内部会发出启动请求~ 2.system-server 进程接收到请求之后，会向Zygote发送创建进程的请求（fork）~ 3.zygote接到请求之后知道自己来活了，就开始fork 出app的进程，并且该app进程中的ActivityThread类的main方法会被调用，创建ActivityThread线程，进行初始化MainLooper、主线程Handler，同时初始化该app进程中的AplicationThread用于和AMS进行交互通信~ 4.App进程创建完成之后，会通过Binder想system_server发送attachApplication请求（实际是App进程通过Binder进程调用system_server 进程中AMS服务的attachApplication方法）AMS中的attachApplication实际的作用是将app进程中的ApplicationThread对象跟AMS绑定，方便通信之类的~ 5system_server收到attachApplication请求之后，会进行一系列的准备工作，完成后再通过Binder IPC向App进程发送handlerBindApplication请求，（目的是进行对Application的初始化和调用Application的onCreate方法）并通过Binder发送scheduleLaunchActivity请求（启动创建Activity）~ 6.app进程的binder线程（ApplicationThread）在收到请求后，再通过内部的handler向主线程发送BIND_APPLICATION和LAUNCH_ACTIVITY消息，这里注意的是AMS和主线程并不直接通信，而是AMS和主线程的内部类ApplicationThread通过Binder通信，ApplicationThread再和主线程通过Handler消息交互~ 7.主线程收到message后，开始创建application并调用oncreate方法，再通过反射机制创建目标Activity，并回调Activity.onCreate等方法~ 8.到此，App启动便正式结束，开始进行Ac的生命周期，进行UI的渲染

到这里，我们的大致弄清了APP的启动流程~

3.ActivityThread的启动流程

在加壳中，有个十分重要的角色，就是ActivityThrad，在之前的一系列的文章中，很多都讲到了ActivityThread.main()是进入App世界的大门，并由此对加壳原理绽开了讲述~

接下来跟随大佬的步伐，我们也来开始对源码进行分析，了解ActivityThread中到底做了什么操作~

我们可以看到在ActivityThread中的main方法，调用了accath（falsh,xx)进行了一系列的初始化准备工作，最后主线程进入消息循环，等待来自系统的消息~ 当接收到系统发来的BindApplication的进程间调用时，调用函数handlebindapplication来处理该请求~

ublic void handleMessage(Message msg) {
****
    case BIND_APPLICATION:
        Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "bindApplication");
        AppBindData data = (AppBindData)msg.obj;
        handleBindApplication(data);
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        break;
****
}

在处理该消息的时候，进入了 handleBindApplication(data) 函数去执行，这里借鉴前辈的图，来具体描述一下：

主要看第四步，Application进行了实例化，然后进入了data.info.makeApplication方法中~

然后进入newApplication函数查看~

至此，我们可以看到在这个流程中完成了两件事情

（1）完成了Application的实例化（2）并调用Application.attach()函数

然后继续进入attach方法

可以看得出来，attach方法第一步就是调用的attachBaseContext方法~ 最后我i们回到步骤中的，第六步，执行到了最后一步~

就执行了Application的onCreate方法~

总结一哈~

从上文可知, 加载的流程是：
    初始化————>Application的构造函数————>Application.attachBaseContext()————>Application.onCreate()函数
最后才会进入MainActivity中的attachBaseContext函数、onCreate函数
所以一般的加壳厂商要在程序正式执行前，也就是上面的流程中进行动态加载和类加载器的修正，这样才能对加密的dex进行释放，而更多的厂商往往选择在Application中的attachBaseContext或onCreate函数进行~

下图是网上大佬的一个详细执行流程图，可供参考~

二、整体加壳的原理详解

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<String, WeakReference<LoadedApk>> mPackages = new ArrayMap<>();
           Field mPackagesField = ActivityThread.getDeclaredField("mPackages");
           mPackagesField.setAccessible(true);
           //3.拿到LoadedApk
           ArrayMap mPackagesObj = (ArrayMap) mPackagesField.get(activityThreadObj);
           String packagename = context.getPackageName();
           WeakReference wr = (WeakReference) mPackagesObj.get(packagename);
           Object LoadApkObj = wr.get();
           //4.拿到mclassLoader
           Class 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父节点设置为DexClassLoader
        ClassLoader pathClassLoaderobj = context.getClassLoader();
        Class<ClassLoader> 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了