加壳原理

一、APP启动流程(结合源码分析)

当我们点击APP图标，到APP运行启动，中间经历了怎样的过程？可以用一张图来概括：

首先启动Activity/Service，(Activity、Service是什么？四大组件：Activity、Service、BroadCast Recevicer、Content provider)，通知system_server进程，然后以Binder的方式通知Zygote进程，最终进入ActivityThread.main()，开始进入APP世界的大门。

我们打开http://androidxref.com/8.0.0_r4/xref/frameworks/base/core/java/android/app/ActivityThread.java，对ActivityThread进行源码分析，了解启动流程。

ActivityThread是单例创建，sCurrentActivityThread是全局创建的ActivityThread实例。其中currentActivityThread()是静态方法，可以返回我们当前创建的ActivityThread。

ActivityThread.main()函数是java中的入口main函数，这里会启动主消息循环，创建ActivityThread实例，之后调用thread.attach(false)完成一系列初始化准备工作。之后主线程进入消息循环(bindleMessage函数)，等待接收来自系统的消息。

当收到系统发送来的bindapplication的进程间调用时，调用handlebindapplication来处理该请求。

还有ArrayMap类型的mPackages变量需要注意下，这是加载APP存放的内容，LoadApk函数如下：

我们获取mPackages，和包名就可以获取动态加载的APP包内容，这后面会用到。

接下来，我们看下handleBindApplication函数，内容比较多。

学习寒冰大佬的说法，这个函数主要完成以下的任务。

private void handleBindApplication(AppBindData data) {
    //step 1: 创建LoadedApk对象
    data.info = getPackageInfoNoCheck(data.appInfo, data.compatInfo);
    ...
    //step 2: 创建ContextImpl对象;
    final ContextImpl appContext = ContextImpl.createAppContext(this, data.info);
 
    //step 3: 创建Instrumentation
    mInstrumentation = new Instrumentation();
 
    //step 4: 创建Application对象;在makeApplication函数中调用了newApplication，在该函数中又调用了app.attach(context)，在attach函数中调用了Application.attachBaseContext函数
    Application app = data.info.makeApplication(data.restrictedBackupMode, null);
    mInitialApplication = app;
 
    //step 5: 安装providers
    List<ProviderInfo> providers = data.providers;
    installContentProviders(app, providers);
 
    //step 6: 执行Application.Create回调
    mInstrumentation.callApplicationOnCreate(app);

在handleBindApplication函数中，第一次进入了app代码世界，该函数启动了一个application，并把apk组件等相关信息绑定到application里，在创建完application对象后，接着调用了application的attachBaseContext方法，之后调用了application的onCreate函数。

正常APP启动过程：

由此可见，attachBaseContext和onCreate是最先获取代码执行权的，这也是为什么各家的加固工具主要逻辑都是替换app入口Application，并自实现这两个函数。这也是为什么在这两个地方进行脱壳的原因。

加壳APP运行流程

加壳APP运行过程：

壳要做的工作有：

1、要对原先APP的dex进行解密

2、初始化自定义类加载器

3、替换LoadApk中的加载器为自定义加载器。

上一篇文章讲述了，如何调用加载其他dex内的方法，那么如果我想调用dex内的其他Activity能不能，用同样的方法能不能行得通呢？

上代码截图：

然后build提取APK的classes.dex，adb push到手机上

adb push classes.dex /sdcard/4.dex

然后新建工程，赋予读写存储卡权限，写入 调用读取4.dex的TestActivity方法，那么很快啊，就会显示报错，无法调用。

究其原因是什么呢？因为Activity不像是上篇文章中的函数方法，Activity具有生命周期和相关组件信息，只有当classloader被修正后，才能正确加载被解密后的dex类和方法。顺便提一点，壳在函数attachBaseContext和onCreate中完成对加密的dex文件的解密。

修复classloader

如何修正呢？

有两种方法：

• 方法一：通过层层反射，拿到mPackage内容，然后根据报名通过LoadApk获取APP内的类加载器，最终使用自定义类加载器进行替换。
• 方法二：利用双亲委派机制，在BootClassloader和PathClassloader中插入我们自定义的类加载器，完成修复。

方法一

根据java的反射，和开源的java代码，进行一步步反射。(可对照androidxref，逐步理解以下代码)

然后在原先的基础上调用replaceClassloader即可。

方法二

    public void startTestActivitySecondMethod(Context context,String dexfilepath){

        File optfile=context.getDir("opt_dex",0);
        File libfile=context.getDir("lib_path",0);
        ClassLoader pathClassloader=MainActivity.class.getClassLoader();
        ClassLoader bootClassloader=MainActivity.class.getClassLoader().getParent();

        //这里的改变，MainActivity.class.getClassLoader()变成bootClassloader，意思是，这里的DexClassLoader，直接向BootClassLoader汇报的
        DexClassLoader dexClassLoader=new DexClassLoader(dexfilepath,optfile.getAbsolutePath(),libfile.getAbsolutePath(),bootClassloader);
        try {
            Field parentField=ClassLoader.class.getDeclaredField("parent");
            parentField.setAccessible(true);
            //把pathclassloader插入我们的dexClassLoader
            parentField.set(pathClassloader,dexClassLoader);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
/*
* this:dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.kanxue.loaddex-8_fCxispeBuExjw1ryrRZg==/base.apk"],nativeLibraryDirectories=[/data/app/com.kanxue.loaddex-8_fCxispeBuExjw1ryrRZg==/lib/arm64, /system/lib64, /vendor/lib64]]]--parent:dalvik.system.DexClassLoader[DexPathList[[dex file "/sdcard/6.dex"],nativeLibraryDirectories=[/data/user/0/com.kanxue.loaddex/app_lib_path, /system/lib64, /vendor/lib64]]]
this:dalvik.system.DexClassLoader[DexPathList[[dex file "/sdcard/6.dex"],nativeLibraryDirectories=[/data/user/0/com.kanxue.loaddex/app_lib_path, /system/lib64, /vendor/lib64]]]--parent:[e-mail]
root:[e-mail]*/
        /*
        * PathClassLoader => DexClassLoader => BootClassLoader
        * */
        ClassLoader tmpClassloader=pathClassloader;
        ClassLoader parentClassloader=pathClassloader.getParent();
        while(parentClassloader!=null){
            Log.i("kanxue","this:"+tmpClassloader+"--parent:"+parentClassloader);
            tmpClassloader=parentClassloader;
            parentClassloader=parentClassloader.getParent();
        }
        Log.i("kanxue","root:"+tmpClassloader);
        Class<?> clazz=null;
        try {
            clazz = dexClassLoader.loadClass("com.kanxue.test02.TestActivity");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        context.startActivity(new Intent(context,clazz));
    }

壳工作方式

而第一种方式，是加壳厂商经常会用的方式，也就是通过自定义dexclassloader对原先的类加载器进行替换修复。

这里还分为两种情况，一种是原始的APP没有自定义Application子类，那么这种情况比较简单，直接替换壳的Application即可。

另一种情况，是原始APP定义了Application子类，那么壳Application的工作就不仅仅是进行解密、类加载器修复等工作了，还有对解密后的DEX原始的Application的方法和类重新进行处理，保证整个过程运行顺畅。

我们可以看AndroidManifest.xml内的主Application是否被替换为壳Application入口，就可以了解到，同时观察壳Application的汇编代码，会发现进行了大量的修复。

Reference

https://bbs.pediy.com/thread-252630.htm