C++学习笔记

创建可执行文件

分成三步骤：

  1. 预处理器处理所有的预处理指令。例如：将所有#include头文件的完整内容复制到.cpp文件中
  2. 编译器对.cpp文件进行编译转成对象文件，即转换成相应的二进制机器码等。
  3. 链接程序，把程序的对象文件合并到包含完整可执行程序的文件中。

展开全文 >>

风控学习——黑产武器库

黑产武器库

虚假号码

来源：手机卡商
作用：对接接码平台，提供短信验证码代收，处理并提供给黑产服务。

可以提供虚拟号码的方式

  1. 猫池
    我们平时拨号的Modem是一种用于控制和管理SIM卡的设备， 当数量足够多时即为Modem Pool，即猫池。
    猫池由多个Modem模块组成，每个模块都具有SIM卡槽、基带芯片、射频芯片、手机天线，等同于一台手机。所以每个模块都具有收发短信和拨打电话的功能。
    猫池底层使用AT命令来进行操作，例如读短信AT+CMG\r\n。
    由于使用AT命令操作不太方面，市面上有一些专门用来管理猫池的软件，例如“嘻唰唰”和“酷卡”，这些软件会把短信和通话记录保存在数据库上。然后由接码平台提供卡商端程序来读取和上传猫池中的短信，原理就是读取猫池管理软件中的数据库文件。

  2. 短信验证码
    短信验证码是目前有效面对面对爬虫的一种手段，但也是黑产用来大批量注册账号的方式。
    黑产可以通过猫池管理软件收发短信，从而实现实现自动化注册账号。
    目前，为了应对黑产使用猫池收发短信注册，有一批平台已经使用语音验证，或者通过手机发送验证码的方式。
    不过这种应对方式并不是万能的，有一些猫池可以接收语音，把音频文件进行保存，通过各种手段进行识别。这种一般会采用人工识别的方式。

  3. 接码平台
    “虚假号码”的集散地，用于为黑产提供虚假号码。2017年温州爱码平台被查处之后，接码平台变成了卡商——中间人——黑产中的中间人角色。给卡商一个卡商端，卡商管理手机卡；接码平台负责接收卡商端传来的短信进行处理——内容匹配、抽取、分发、结算。
    接码平台目前被2019年净网行动打击之后转入地下。

  4. 空号注册
    虚假号码，大多可认为为已经由运营商投放到市场的号码资源。而空号注册则是黑产与运营商内部勾结，得到未投放的号码（即空号）接收短信。少见。

  5. 流量卡和物联网卡
    流量卡有使用期限，一般人不会用来注册，而黑产使用它这些周期已经足够。
    物联网卡是运营商提供给物联网企业的用于物联网设备的通信，如共享单车等，物联网设备对该卡流量的需求小，能收发短信，打电话的功能，价格便宜，前期还不需实名，现在物联网卡已经越来越严了，从黑产当中慢慢抽离开来。

  6. 手机rom后门
    由高技术团队开发自己的手机rom系统，然后与很多公司合作生产“老人机”，当老人使用之后，rom中的后门就会通过短信上报对应的手机号到黑产预埋的手机号中。黑产使用这些手机号注册各类网络平台账号，当验证码发到老人手机当中会被后门转发到黑产手里。后门有屏蔽规则，老人无法看到这些短信。只能从运营商的短信详单当中找到端倪。此类很难识别黑号。

IP代理

代理分为两类：
1. 正向代理
可以屏蔽访问者的IP，对于服务端来说，所有通过正向代理访问的用户IP都是同一个。
2. 反向代理
访问一个网站，一个网站可能存在若干个功能存储在若干个服务器，用户无需知道其真实的ip,对于用户而言，他们访问的是同一个域名。

黑产或者是爬虫都需要代理ip去冲破风控对于IP的限制。

展开全文 >>

app的加壳与脱壳

逆向分析APP的一散流程:
  1. 使用自动化检测工具检测apk是否加壳，或者借助一些反编译工具依靠经验推断是否加壳，
  2. 如果apk加壳，则需要首先对apk进行脱壳﹔(Fart、Youpk、Dex-Dump三种常用方案)
  3. 使用jeb、jadx , apktool等反编译工具对apk进行反编译;
  4. 先依据静态分析中得到的关键字符串、关键api调用等方法快速定位需要分析的关键函数和流程;
  5. 如果依据简单的字符串、关键api无法快速定位，则apk可能使用了字符串加密、反射调用等手段，此时可结合h o o k 、动态调试等
  6. 定位到关键函数后，再根据是java实现还是jni实现进一步分析，其中so中的函数逻辑分析难度较大下面通过几个实例来看下流程
  7. JNI分析到IDA当中，IDA搜索不到响应的函数则为动态注册，动态注册是在JNI_Onload当中注册的，这个时候我们可以搜一下我们想要的目标字符串，倘若进行了字符串加密（ollvm），则搜索不到。此时可以尝试hook registerNative、art相关的地址进行监控
JVM的类加载器包括3种:
  1. Bootstrap ClassLoader（引导类加载器）
    C/C++代码实现的加载器，用于加载指定的JDK的核心类库，比如java.lang.、java.uti.等这些系统类。Java虚拟机的启动就是通过Bootstrap，该Classloader在java里无法获取，负责加载/lib下的类。
  2. Extensions ClassLoader（拓展类加载器）
    Java中的实现类为ExtClassLoader，提供了除了系统类之外的额外功能，可以在java里获取，负责加载/lib/ext下的类。
  3. Application ClassLoader（应用程序类加载器）
    Java中的实现类为AppClassLoader，是与我们接触对多的类加载器，开发人员写的代码默认就是由它来加载，ClassLoader.getSystemClassLoader返回的就是它。
自定义类加载器

通过继承java.lang.ClassLoader来实现自己的ClassLoader
picture 5

双亲委派

类加载器通过双亲委派（也叫向上委托）的方式来进行类的加载。

双亲委派模式的工作原理的是;如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都不愿意干活，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己想办法去完成，这个就是双亲委派。

为什么采用双亲委派
  1. 避免重复执行类加载器， 如果类已经被加载了，则可以直接读取已经加载的Class。
  2. 更加安全，无法用自定义的类替代系统类，防止系统级API被篡改。

当年我老师给我上课时，跟我说过，以前有个黑客通过替换java.lang.String成自己的String从而引发安全危机。所以通过双亲委派就杜绝了这种问题的发生。

类加载的时机
  1. 隐式加载
    类不由开发人员进行加载的。
    触发时机：
    1. 创建类的实例
    2. 访问类的静态变量（读写）
    3. 调用类的静态方法
    4. 使用反射方式强制创建某个类或接口对应的java.lang.Class对象
    5. 初始化某个类的子类
  2. 显示加载（在反射的过程当中用的频率较高）
    1. 使用LoadClass()加载
    2. 使用forName()加载
      两者有所区别：
JVM当中加载类的流程
  1. 装载:查找和导入Class文件
  2. 链接:其中解析步骤是可以选择的
    • 检查:检查载入的class文件数据的正
      确性
    • 准备:给类的静态变量分配存储空间
    • 解析:将符号引用转成直接引用
  3. 初始化:即调用函数，对静态变
    量，静态代码块执行初始化工作(反编译过程当中，这些静态代码将变成clinit函数，该函数由编译器自动生成)

picture 6

Android系统当中的ClassLoader的继承关系

picture 7

其中InMemoryDexClassLoader为Android8.0新引入的ClassLoader.

采用InMemoryDexClassLoader写加壳代码非常方便。

ClassLoader: 抽象类
BootClassLoader: 继承自ClassLoader，与JVM中的BootStrapClassLoader作用一样，用于预加载系统级别的类，采用单例模式，确保只需加载一次核心的类即可。由Java实现。
BaseDexClassLoader:该类非常关键。对一个d
ex加载的过程当中，大部分的逻辑都在该ClassLoader当中实现,其子类InMemoryDexClassLoader、PathClassLoader、DexClassLoader只是简单的继承了BaseDexClassLoader。
PathClassLoader: 当一个App从点击到第一个Activity呈现的过程当中，APP当中的类由PathClassLoader来加载。
SecureClassLoader继承自ClassLoader,主要加入权限方面的功能，加强了安全性，其子类URLClassLoader是用URL路径从jar文件中加载类和资源。
InMemoryDexClassLoader: 在Android 8.0 引入的，在APP的加固当中使用最多的就是在InMemoryDexClassLoader当中进行。顾名思义，从内存当中直接加载dex
PathClassLoader: 是Android默认使用的类加载器,四大组件Activity、Service等等都是在PathClassLoader当中进行加载。
DexClassLoader: 可以加载任意目录下的dex、jar、apk、zip文件，甚至可以从网络、SD卡当中加载，也是目前实现插件化、热修复以及dex加壳的重点！

Android的源码目录

art: 存放Android runtime的实现，以C++代码为主
bionic: Android的C库
libcore: ClassLoader的存放处，编译到手机时以jar包的形式呈现
framework: Android四大组件的管理处

tips: android的源码可以到aospxref.com和androidxref.com当中查看，aosp为国内镜像且以更新到android 10

Android ClassLoader源码解析

ClassLoader位于其他所有ClassLoader的根节点。其中一个关键的变量parent是用于实现双亲委派的关键。该参数在每个ClassLoader当中都有存在，用于表示它的父节点是哪个ClassLoader,对于Android的BootClassLoader来说，parent是空的。再看看parent是一个final类型的变量，意味着只能赋值一次。该变量是否重要，对于如何插件化加载dex，并且让dex当中的组件生效。

picture 8

BaseDexClassLoader源码：
picture 9

DexClassLoader源码:
picture 11

PathClassLoader源码:
picture 12

InMemoryDexClassLoader源码:
picture 13

以上三个子类均继承自BaseDexClassLoader,且仅仅只有自己的构造函数。

证明：BootClassLoader为根ClassLoader

通过Android Studio写一个程序：

frida与xpose对ClassLoader的加载

xpose: 需要加载ClassLoader才能进行操作
frida: 通过反射找到app所在的ClassLoader, 自动处理ClassLoader

动态加载dex

之前我们有提到DexClassLoader 可以加载任意目录的dex、zip、jar、apk文件，所以我们需要得到一个DexClassLoader实例，先看看源码部分。
picture 11
第一个参数dexPath,即要加载的那4个类型的文件路径，第二个

  1. 我们先创建一个Android项目，然后我们再创建一个类，类中创建一个方法，用来输出已经被调用到。

  2. 编译整个项目成apk，然后解压apk，找到当前classxx.dex，把其导入到手机的/sdcard/目录

  3. 接着，我们创建一个用于Load刚才我们导入进sdcard的项目，记得添加读写sd卡的权限.(使用时还要记得在设置里面打开本app读取sdcard的权限，因为时常因为这个没读取报错)
    picture 1

  4. 编写程序

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    package com.example.loadsdcardcode;

    import androidx.appcompat.app.AppCompatActivity;

    import android.app.Application;
    import android.content.Context;
    import android.os.Bundle;

    import java.io.File;
    import java.lang.reflect.InvocationTargetException;
    import java.lang.reflect.Method;

    import dalvik.system.DexClassLoader;

    public class MainActivity extends AppCompatActivity {

        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            Context context = this.getApplicationContext();
            testDexClassLoader(context, "/sdcard/3.dex");
        }

        /**
         *
         * @param context 获取当前app的私有目录
         * @param dexPath dex、zip、apk、jar这四种中的一种文件格式的路径
         */
        public void testDexClassLoader(Context context, String dexPath){
            // 在当前的私有文件下新建一个私有目录,用于存放其dex
            File optfile = context.getDir("opt_dex", 0);
            File libFile = context.getDir("lib_dex", 0);
            DexClassLoader dexClassLoader = new DexClassLoader(dexPath,
                    optfile.getAbsolutePath(),
                    libFile.getAbsolutePath(),
                    MainActivity.class.getClassLoader());
            try {
                // 读取dex中的class
                Class clazz = dexClassLoader.loadClass("com.example.beloadedproject.TestClass");
                try {
                    // 反射出需要的method
                    Method method = clazz.getDeclaredMethod("functionBeLoaded");
                    // 反射出我们要load的class
                    Object obj = clazz.newInstance();
                    // 调用方法
                    method.invoke(obj);
                } catch (NoSuchMethodException e) {
                    e.printStackTrace();
                } catch (IllegalAccessException e) {
                    e.printStackTrace();
                } catch (InstantiationException e) {
                    e.printStackTrace();
                } catch (InvocationTargetException e) {
                    e.printStackTrace();
                }

            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        }
    }

    看看结果：
    picture 1

DexClassLoader方法参数:
dexPath:目标所在的apk或者jar文件的路径，装载器将从路径中寻找指定的目标类。
dexOutputDir:由于dex文件在APK或者jar文件中，所以在装载前面前先要从里面解压出dex文件，这个路径就是dex文件存放的路径，在android系统中，一个应用程序对应一个linux用户id ,应用程序只对自己的数据目录有写的权限，所以我们存放在这个路径中。
libPath:目标类中使用的C/C++库。
最后一个参数是该装载器的父装载器，一般为当前执行类的装载器。

APP运行的过程

picture 2
ActivityThread.main()是进入APP世界的大门，只有经过这个方法之后才会进入到加壳app的自己的代码当中。
接下来我们开始讲ActivityThread:

ActivityThread

ActivityThread是一个单例模式的类，sActivityThread用于保留这个唯一的实例。
我们要想获取到当前的ActivityThread，需要调用其静态函数currentActivityThread
picture 3

通过该函数，我们将获取这个全局、单例的实例，通过该实例我们可以获取一些比较重要的变量。

LoadedApk:
picture 6

在ActivityThread的内部这个部分有LoadedApk这个类的变量，其中这个类中有一个变量叫做mClassLoader，就是我们加载APP用的ClassLoader，即PathClassLoader.

我们通过反射获取一个ActivityThread这个仅有的实例，接下来，再通过反射获取mPackages这个ArrayMap,接下来就可以通过当前APP的包名获取到它的LoadedApk,最后就可以通过这个LoadedApk获取到其中的一个mClassLoader。
picture 7

这个实际上就是PathClassLoader,就是接下来APP用于加载四大组件这些类的ClassLoader。

而什么时候才会进入到app的代码当中？（何时进行dex解密）

在handleBindApplication当中，最先进入到app自身代码当中。
在hangbingle老师的这片文章链接就有提到，此处上他的代码截取

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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);

picture 9

接下来我们看看那个newApplication做了什么。
picture 10

跟到这里发现app.attach,我们接着跟到attach里。
picture 11

这里实际上调用了attachBaseContext这个函数。
一个正常的APP的哪一部分最先被执行？在AndroidManifest.xml当中，所声明的ApplicationBaseContext和onCreate函数是最先获取到执行权的。
在这个过程当中，涉及到两个ClassLoader,BootClassLoader用来加载系统核心库，而PathClassLoader用于加载APP自身dex，其中包含有app所声明的Application,如果APP没有加壳，自然而然拥有APP这些类信息；如果加壳了呢？此时PathClassLoader加载的，只有壳的代码！而且，当前呢，也还没有加载真正的代码也就是壳解密后释放的代码。接下来就进入到Application的attachBaseContext这个函数执行，再往下就是onCreate函数进行执行。对于壳程序来说需要找到一个比较早的时机进行加密dex交付。自然而然就会选择这两个函数做文章。
picture 12

加壳应用的运行流程

picture 13

如何解决动态加载中加壳dex的类的生命周期

要解决这个问题，我们首先来看看dex的解密源程序在哪里进行。

在自定义的Application中的attachBaseContext以及onCreate两个函数当中进行

实战讲解

  1. 首先我们创建要动态导入的dex， 并导入到sdcard当中。
    2020-10-27-22-38-18

  2. 创建一个新项目，并先在AndroidManififest.xml当中注册我们要动态加载的Activity.

2020-10-27-23-37-35

  1. 动态加载dex，并启动activity
    2020-10-27-23-32-33

报错： java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.juziss.loadactivity/com.juziss.loadeddex.TestActivity}: java.lang.ClassNotFoundException: Didn’t find class “com.juziss.loadeddex.TestActivity” on path: DexPathList[[zip file “/data/app/com.juziss.loadactivity-R-aobRMym_MNBJ9GchrmZg==/base.apk”],nativeLibraryDirectories=[/data/app/com.juziss.loadactivity-R-aobRMym_MNBJ9GchrmZg==/lib/arm64, /system/lib64, /vendor/lib64]]

报错的原因：

由于组件相关的Activity实际上是由上面提到的mClassLoader（实际上就是PathClassLoader）进行加载的，虽然我们通过反射拿到了我们想要动态加载的Activity,但是却造成ActivityManager在管理上无法找到我们要加载的Activity,因为别忘了是先加载AndroidManifest才到onCreate的！

两种解决动态加载组件相关的Activity的生命周期问题

  1. 替换系统组件类加载器为我们的DexClassLoader,同时设置DexClassLoader的parent为系统当前的组件类加载器即PathClassLoader。
    2020-10-28-00-32-16
    通过反射区替换当前的ClassLoader为我们定义的DexClassLoader,当进入到App的Activity相关的生命周期切换的过程时，就会使用DexClassLoader进行加载。自然而然就找到了我们需要的类。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    // 先传入我们的DexClassLoader
    public void replaceClassLoader(ClassLoader classLoader){
        try {
            // 通过反射获取ActivityThread
            Class<?> ActivityThreadClass = classLoader.loadClass("android.app.ActivityThread");
            // public static ActivityThread currentActivityThread() {
            //        return sCurrentActivityThread;
            //  }
            // 由以上可以得知，需要通过currentActivityThread来获得当前的ActivityThread,因为ActivityThread是单例的
            Method currentActivityThreadMethod = ActivityThreadClass.getDeclaredMethod("currentActivityThread");
            // 执行这个Method对象即可得到ActivityThread
            Object activityThread = currentActivityThreadMethod.invoke(null);
            // 寻找LoadedApk类（因为这个类里面存在当前的mClassLoader），关键要找到    final ArrayMap<String, WeakReference<LoadedApk>> mPackages = new ArrayMap<>();
            // 即要找到mPackages
            Field mPackages = ActivityThreadClass.getDeclaredField("mPackages");
            // 关闭类型检查
            mPackages.setAccessible(true);
            // 通过包名来获取WeakReference<LoadedApk>
            ArrayMap mPackagesObj = (ArrayMap) mPackages.get(activityThread);
            // 参数为一个String类型，实际上为当前的包名，得到的是一个弱引用对象，该对象对应着LoadedApk，可以理解为python的弱引用，能引用到，但是垃圾收集器不计数
            WeakReference weakReference = (WeakReference) mPackagesObj.get(this.getPackageName());
            Object loadedApk = weakReference.get();

            // 通过反射先获取LoadedApk类
            Class<?> loadedApkClass = classLoader.loadClass("android.app.LoadedApk");
            Field mClassLoader = loadedApkClass.getDeclaredField("mClassLoader");
            mClassLoader.setAccessible(true);

            // 替换ClassLoader为我们的DexClassLoader
            mClassLoader.set(loadedApk, classLoader);

            } 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();
        }

    }

    把该函数加到我们写的那个实战当中

    2020-10-28-22-52-17

    寒冰老师牛逼！！！

  2. 打破原有的双亲关系，在系统组件类加载器和BootClassLoader的中间插入我们自己的DexClassLoader。
    2020-10-28-22-55-57

    这种解决方案和双亲委派密切相关，我们依然保留当前组件的ClassLoader,但是我们把它的parent设置成DexClassLoader,通过双亲委派的特性，PathClassLoader会把加载Activity的时机交由我们创建的DexClassLoader进行处理。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    private void startTestActivity2(Context context, String dexFilePath) {
        Class clazz = null;
        File optFile = context.getDir("opt_dex", 0);
        File libFile = context.getDir("lib_dex", 0);

        ClassLoader pathClassLoader = MainActivity.class.getClassLoader();
        ClassLoader bootClassLoader = MainActivity.class.getClassLoader().getParent();
        // 将我们的DexClassLoader的parent设置成BootClassLoader
        DexClassLoader dexClassLoader = new DexClassLoader(dexFilePath, optFile.getAbsolutePath(), libFile.getPath(), bootClassLoader);

        try {
            //通过反射获取PathClassLoader的parent
            Field parentField = ClassLoader.class.getDeclaredField("parent");
            parentField.setAccessible(true);
            parentField.set(pathClassLoader, dexClassLoader);
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        try {
            clazz = dexClassLoader.loadClass("com.juziss.loadeddex.TestActivity");
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        startActivity(new Intent(context, clazz));
    }

    2020-10-28-23-16-35

    寒冰老师牛逼！！！

Dalvik下一代壳通用解决方案

Dalvik下的DexClassLoader的加载流程。
Dalvik在Android4.4以下的源代码位于libcore里，我们找到DexClassLoader.
2020-11-07-21-34-04
第一个参数为要加载的dex的路径，第二个是dex在优化过程当中产生的odex的路径，第三个是当前要加载的so的路径，第四个则为为了双亲委派而设置的父节点的ClassLoader。

然后我们跟到BaseDexClassLoader当中，这里才是真正的逻辑处理的地方。其跟前面所提到的BaseClassLoader一样，继承于ClassLoader这个抽象类。
2020-11-07-21-40-40
先看其构造函数。这里先调用父类的构造函数，我们看看在父类的实现。

2020-11-07-21-43-33
此时网站上可以看到有两个ClassLoader，其实不奇怪，我们看的Android4.4版本的源码，在那个版本当中Android开始引入来ART，与Dalvik共存，我们只需看看Dalvik下的实现。
2020-11-07-21-46-45
这里ClassLoader这个构造函数只是把传入的父节点设置为parent,让我们回到BaseDexClassLoader当中。

2020-11-07-21-50-02

设置完成父节点之后，又new了一个DexPathList,我们跟进去。
2020-11-07-21-57-59

在这个构造函数当中，第一个参数为传入的ClassLoader,第二个则是要加载的Dex文件,其他三与四个则为DexClassLoader所设置的opt和lib,这个构造函数真正做了事情的是：
2020-11-07-21-54-54

跟进去，
2020-11-07-21-58-31
这个makeElements返回的是一个Element[]数组，其定义在DexPathList.java这个文件里，
2020-11-07-22-02-39
this.file是dexFile对象。

跳回来makeElements这个函数里，当我们动态加载dex时一般只加载一个dex,此时传递的就是一个文件，此时的后缀就是dex，所以走的是第一个逻辑。
2020-11-07-22-09-11
调用loadDexFile,之后把这个dex添加到要返回的Element[]数组当中，我们跟进loadDexFile这个函数
2020-11-07-22-11-20
其仍旧在DexPathList这个文件当中， 第一个参数就是Dex文件，其调用来DexFile类当中的loadDex,我们跟着跳过去。
第一个参数是我们的Dex文件路径，第三个文件参数是0，第二个是DexClassLoader当中的opt这个File,不用去管这个先。
看到其new了一个DexFile，我们跟到相应位置。
2020-11-07-22-18-46

我们看到这里调用了一个openDexFile，然后返回来mCookie,我们接着跟进openDexFile
2020-11-07-22-24-16

发现剩下的处理都在native层当中进行了。既使用C/C++来实现。第一个参数就是要加载的Dex的文件路径

接着往下跟进到JNI函数当中。这个函数所在的路径其实对应了Java的包的路径
2020-11-07-22-28-12
其对应的JNI函数所在路径就是dalvik_system_DexFile
2020-11-07-22-31-03

来到native函数
2020-11-08-21-29-11

第一个参数是Dex文件的路径。

往下拉来到这里，由于我们传进来的是dex结尾的，所以会走这条流程
2020-11-08-21-31-57

可以看到这里还走了一个函数dvmRawDexFileOpen,跟过去看看。
2020-11-08-21-46-34
需要注意的是加载的Dex路径。

然后可以看到他用了open这个函数打开这个dex文件。然后尝试访问这个dex.
2020-11-08-21-51-03
首先对这个dex的魔术进行了校验。
接着往下拉。
2020-11-08-21-52-10
这里呢，将生成要优化的文件（在动态加载的dex有一个优化的过程，最终会生成odex文件），这里是产生odex的路径。

2020-11-08-21-55-25

这里是优化的流程，我们跟进dvmOptimizeDexFile
2020-11-08-21-56-30
第一个fd是我们打开的dex的id,第三个则是当前dex文件的大小。

接着往下看，这里还用到了fork(),新建了一个子进程用于调用/bin/dexopt文件对当前的dex文件进行一个优化，最后产生odex文件，直到产生odex文件之后才开始一步步返回。
2020-11-08-22-02-48

这里我们看看dexopt这个文件对dex怎么优化的。
找到这个cpp文件之后直接搜main即可。
2020-11-08-22-07-09
当我们传入的是dex文件时将调用fromDex，我们找到这个fromDex
2020-11-08-22-08-15

往下拉
2020-11-08-22-09-45
然后这里调用了dvmContinueOptimization对当前这个fd进行优化（真正的优化逻辑也就在这里），跟进去。
2020-11-08-22-12-22
先是进行了dex文件进行判断，判断文件的长度是不是比dexHeader的长度还小，倘若还小则不合法，则直接返回。
2020-11-08-22-13-53
这里先对内存进行映射。往下走
2020-11-08-22-14-49
跟进这个函数，第一个参数是映射到内存当中这个dex的起始地址，第二个则为dex文件的长度。
2020-11-08-22-16-47
紧接着，我们来到了第一个脱壳点函数
dvmDexFileOpenPartial跟踪进去
2020-11-08-22-20-41
可以看到这个函数又调用了dexFileParse其中也包含了dex的起始地址。

这样就是整个动态加载dex时，dalvik帮助我们进行的一些逻辑处理。在这个处理的流程当中，出现了加载的dex的起始地址，这些就是非常好的脱壳时机。

通用脱壳点：编译源码，对dexFileParse、dvmDexFileOpenPartial脱壳点的验证。
一般来说对这两函数进行hook，或者说取出这两个函数参数，第一个参数就是要dump的dex的起始地址，第二个就是我们要dump的内存区域的长度。

当然，除了这两个脱壳点之外还有海量的脱壳点。可以通过有传入或者函数内部有调用dex的起始地址和长度的函数进行脱壳。通过对起始地址和长度进行dump即可脱下完整的dex.当然这个思想适用于脱整体壳（所有壳都有整体壳，所以这个思想是通用的）

手动实现关键时机的hook

  1. 下载Android 4.4的源码

  2. 在linux的虚拟机下找到相应的源码部分（通过androidxref站找到源码所在的位置）
    2020-11-08-23-02-03

  3. 编写脱壳代码
    2020-11-08-23-45-03

  4. 编译源码

    1. 2020-11-08-23-52-15这个是谷歌提供的标准编译
    2. 2020-11-08-23-53-06选择设备
    3. 编译
      2020-11-09-00-16-12

    -jn是用来选择线程数的，这里给出了8个线程，编译的时候最好给虚拟机分配高点的内存，使其编译的时候快一些。

    1. 找到编译好的镜像
      2020-11-09-00-24-27
      其所在位置位于/out/target/product/由于这里只编译了hammerhead即nexus5所以就只有这个镜像的文件
    2. 把这些文件拷出来然后到平时刷机用的虚拟机里刷到手机即可。
      2020-11-09-00-27-46
    • ps:写刷机文件
      2020-11-09-22-15-47
      把这一串写上，然后chmod啥的都呼一遍，然后就可以刷了，看起来镜像刷都挺有规律的，就是顺序不知道有没有要求，盲猜没有。

ART下的脱壳原理

InMemoryDexClassLoader加载一个内存中的解密的字节流的过程当中ART是怎么的流程

2020-11-09-23-36-58

这里存在着两个构造函数，一个用于加载多个dex,一个用于加载单个dex.我们主要关注单个的即可。

跟到BaseDexClassLoader,跟我们讲Dalvik一样，这里的super是用来给ClassLoader的parent属性赋值用的，这里就不跟进去了。
2020-11-10-00-07-57

这里初始化了pathList这个属性
接着，我们又看到了熟悉的DexPathList,看到这个我又想到了熟悉的dex优化流程dex2oat,不知道这里是不是也有这个流程。

我们先看这里传入的对象，ByteBuffer[],当我们传入一个dex时这个长度就是1。

2020-11-10-00-17-21

我们进入到这个方法，因为这个传入了dex
picture 1

遍历了dexFile这个数组，然后新建一个DexFile,我们在跟去看看。
![](2020-11-10-21-13-34.png) 1

openInMemeryDexFile被调用，跟进去
2020-11-10-21-37-39

这里调用了两个地方，分别查看一下走了哪里。
picture 3

都是两native函数
picture 4

那我们就跟到native!!
DexFile_createCookieWithDirectBuffe
picture 5

因为其是一个静态函数，所以第二个参数是一个jClass, 第三个是我们传入的字节流。这个函数里面进行了一次**memcpy(dex_mem_map->Begin(), base_address, length);**进行了一次拷贝，而传入的这个Begin()和length其实就是我们的dex文件的其实地址（意味着这个函数是一个脱壳点！）

DexFile_createCookieWithArray
picture 6

这两个函数共同调用了CreateSingleDexFileCookie,跟进去看看。

picture 7

这里传入了MemMap,即我们的Dex相关信息以后，通过它创建了一个DexFile，即一个Dex实例，*最后返回了这个DexFile.**这意味着什么？这意味这这就是整个InMemeryDexClassLoader*的加载流程!!

我们跟进去看看DexFile的初始化。在这之前，我们先看看我们传入的CreateDexFile.

picture 8

这里的第二个参数就是包含我们dex文件在内存当中的映射的一个地址，而CreateDexFile最终又调用了DexFile的Open这个函数，我们传入了location,即一个字符串string（要加载的Dex的路径）,即是这个函数。
picture 10

第二个参数是dex在内存当中的映射。这个Open函数，又调用了OpenCommon这个函数,跟进去看看。
picture 9

这个函数也包含着我们加载的Dex文件的起始地址。这个OpenCommon最后又new DexFile对象，在这个DexFile又包含了Dex的起始地址和大小。

picture 11

也就是说InMemoryDexClassLoader在对内存中的Dex信息进行加载的流程当中，实际上涉及的函数都有Dex的起始信息和大小。回想一下Dalvik下的方案，也就是说，这些函数就是一个脱壳点！

还有一个重要的点：**InMemoryDexClassLoader并没有内存中的Dex信息进行一个编译生成相应的oat文件!**这一点是和DexClassLoader加载dex的不同之处！

此时

InMemoryDexClassLoader暴露出来的dex脱壳点有：

  1. CreateSingleDexFileCookie
  2. CreateDexFile
  3. DexFile::Open(location….)
  4. OpenCommon
  5. DexFile::DexFile(const uint8 t* base, …)
Art下的DexClassLoader

picture 1

该ClassLoader的分析流程会比InMemoryDexClassLoader要复杂，因为多了一步我们用到过的脱壳流程，即dex2oat的编译过程。

老套路，跟到BaseDexClassLoader当中
picture 2

其构造函数跟Dalvik下的BaseDexClassLoader是一样的，我们接着跟到DexPathList.

picture 3
可以看到，到目前为止跟Dalvik下是一样的。我们接着跟到makeDexElements当中。
picture 4
然后又跟到loadDexFile,其最后调了DexFile.loadDex,跟过去。
picture 5
再跟进。
picture 6
跟到这里，我们就来到了Native层。该层体现了与Dalvik下的区别。
picture 7
因为其是静态函数，所以第二个参数是jclass, 第三个参数是java要加载的Dex文件。
在这里我们也看到了第一次出现oat的字符，我们看到了这里有调用一个OpenDexFilesFromOat,跟进去。当我们第一次DexClassLoader去解密一个动态的Dex,此时必然还没有生成oat。
picture 8

先是生成了OatFileAssistant这个类，初始化这个对象。接着这个实例调用了isUpToDate()
picture 1
当我们第一次调用的时候，是必然还没有生成oat的。

然后我们接着跟到MakeUpToDate当中。
接着这个函数最后调用了GenerateOatFileNoChecks
picture 2
最终进入到，调用Dex2Oat编译生成oat文件的流程。

接下来我们来看看是怎么进行dex2oat这个流程。
picture 3

先判断一下Dex2Oat是否是可用的状态。若不可用直接返回。

picture 4
接着，是生成oat路径的一些函数。

接着往下走，直到Dex2Oat这个函数。
picture 5
跟进去。

我们先看到了一些二进制的程序的参数的相关信息。
picture 6
最终调用了Exec来完成Dex2Oat的编译的过程。
picture 7

picture 8

然后跟进到ExecAndReturnCode
picture 9
在这函数当中首次进行了进程的fork，在子进程当中，使用execve这个函数来执行Dex2Oat编译的过程。

也就是说，在整个流程当中，我们把其中的某个函数的逻辑进行修改，或者对某个函数（比如execve）进行hook都会导致dex2oat编译流程的结束，实际上，强制结束dex2oat的编译流程是可以让我们的DexClassLoader在第一次加载Dex的流程当中变成非常的快速，减少dex2oat的编译流程。

实际上，要实现Art下的函数抽取技术，我们也是要阻断dex2oat的编译流程的。这也是art下实现函数抽取的方案与Dalvik下的区别所在，因为Dalvik下不存在dex2oat的编译流程，所以Dalvik下实现函数抽取流程稍微简单些。

接着回到源码，当阻断了dex2oat的编译流程之后，最终会返回到OpenDexFilesFromOat,并最后来到了这个控制流上。
picture 10

会先在HasOriginalDexFiles里尝试加载我们的Dex，也就是说，倘若我们的壳阻断了dex2oat的编译流程（当前好多厂商的函数抽取流程都是这么做的），然后又调用了DexFile的Open函数。
picture 11
来到了这个Open函数，这里有调用了OpenAndReadMagic这个函数（这个函数的第一个参数是Dex文件路径）！这个是 2017DefCon上提出的通过修改DexFile的构造函数DexFile::DexFile()，以及OpenAndReadMagic()函数来实现对加壳应用的内存中的dex的dump来脱壳的原理。

接着往下走：
picture 12
由于我们加载的是一个dex文件，所以必然是走OpenFile这个函数的，跟进去！
picture 13
第一个参数fd是文件的描述符，接着我们往下走，进入到OpenCommon这个函数当中。在这之前，我们可以看到，MemMap::MapFile将这个文件进行了内存映射。
picture 14

进入到OpenCommon当中。
这个函数的参数也有文件的映射区域，
picture 15
第一个参数是文件的起始地址，
接着往下走又进入到了new DexFile函数当中,那我们就跟进去。
picture 16
这里又有文件的起始地址，把这个函数记录下来，因为有起始地址的地方都有机会成为我们的脱壳点！

以上就是Dex文件的加载流程。涉及到了三个重要的脱壳点这里。

DexClassLoader的三个重要脱壳点

  1. OpenAndReadMagic(filename, &magic, error_msg);
  2. DexFile::OpenCommon(const uint8_t* base,
  3. DexFile::DexFile(const uint8_t* base,
刷入aosp 8.0碰到的坑

我按往常那样刷了aosp,但是却一直在recovery无法进入系统，后来我对着官方的flash-all.sh看了看，发现官方包其实也是刷了编译出来的那几个.img文件，但是它还多刷了两个东西。
picture 1

这两个.img是在刷编译出来的文件的时候先刷入的，而这两个.img你单纯编译源码是没有的，需要在官方的刷机包里拿，先刷入这两个.img之后再刷入我们编译出来的.img。

上面我们提到的DexClassLoader走的是没有走dex2oat的路线，但是如果有些壳没有禁用dex2oat的编译流程，而且又是走DexClassLoader时改怎么办？

实际上dex2oat的流程也是可以进行脱壳的。

picture 1
刚才我们有说过这一步execve函数是用来调用dex2oat的二进制程序实现对dex文件的加载，我们这时候找到dex2oat.cc这个文件，找到main函数。
picture 2
我们可以看到这里调用了dex2oat这个程序，跟进去。
picture 4
picture 5
SetUp这个函数里最后出现了我们要编译的dex文件的处理。
在这里
picture 6
这个地方也可以完成对dex文件的脱壳。
实际上dex2oat存在的脱壳点还是非常多的，比如
picture 7
在这个dex2oat编译流程里，它对函数粒度的编译流程当中，都出现了dexFile这个对象，实际上都可以进行脱壳。

ART下抽取壳实现

函数抽取是宣告一代壳即整体保护的结束，由此进入二代壳的时代。

函数抽取壳的实现

二代壳的出现标志着一代壳的时代结束。

Dalvik下抽取壳实现

四哥的博客有写:
这篇是下面一篇的基础
Android免Root权限通过Hook系统函数修改程序运行时内存指令逻辑

Android中实现「类方法指令抽取方式」加固方案原理解析

实现函数抽取壳的时机要早于函数被调用的的时机，倘若晚于被调用的时机，APP的逻辑就被破坏掉了，APP自然就崩溃了。

函数被调用之前经历的阶段
  1. Dex被加载，例如Dex被动态加载
  2. 类的准备
    • 装载
    • 链接
    • 初始化
类的加载流程（loadClass）

通过DexClassLoader进行，遂跟到相应源码（本次选取4.4，流程是一致的，变化几乎很小）。
picture 1

再往上找BaseDexClassLoader,在这个类当中没有找到loadClass,那再往上找，ClassLoader在这个类中就找到了。
picture 3

这里可以体现出双亲委派，如果Class之前已经被加载，则直接返回这个Class,否则尝试使用当前ClassLoader的父类ClassLoader（父类的ClassLoader被存放于parent属性当中）进行加载，如果加载成功直接就返回，由于我们第一次执行是由DexClassLoader进行加载，其父节点ClassLoader为PathClassLoader（或者被我们自定义为BootClassLoader）,此时我们的类没有找到，因为我们的类只由当前的ClassLoader进行加载，所以会走到下一个分支，findClass(),即来到了DexClassLoader的findClass当中，而DexClassLoader的逻辑都被封装于BaseDexClassLoader当中，我们找到它。
picture 4
可以看到内部逻辑实际上由pathList的findClass来执行，而pathList被实例化于DexClassLoader加载Dex的时候已经被实例化，跟进去找到DexPathList内部的findClass()。

picture 5
可以看到findClass当中存在dexElements,并对其进行遍历，这个dexElements当中存放着的都是DexFile对象，然后又调用该对象中的loadClassBinaryName,接着往上跟。
picture 6
可以看到其内部实际上调用的是defineClass（第三个参数mCookie实际上存放的是Native层的指针，这个mCookie在往后的版本当中演变成了Object）,而defineClass内部又调用了defineClassNative方法进行Class的加载，我们要跟到Native层当中了。

跟到这个cpp文件。
picture 7
实际上这个注释也说了，从DEX文件当中加载一个类。
picture 8
也可以看到，这个cookie被转换成了DexOrJar指针，由于我们当前是加载Dex文件，所以会走dvmGetRawDexFileDex函数
picture 9

跟进来，发现只是取到这个指针中的pDvmDex
picture 10

也就意味着这里实际上没做啥实际的工作，接着刚才的逻辑往下走。
picture 11
走进这个函数。
picture 12
在深入到findClassNoInit函数，又跳过去。
picture 13
这里的第一个参数是一个类名，即一个字符串，第二个为当前的ClassLoader。
picture 14
首先对类名进行HASH计算，然后通过已经加载的类进行查询，倘若查询不到则返回null。由于当前，我们是第一次加载一个类，所以返回null。
所以接上刚才的逻辑往下走。
picture 16
这里的dexFindClass是姜维在Android中实现「类方法指令抽取方式」加固方案原理解析这篇文章当中提到的，hook这个类来实现抽取函数的恢复的解决方案（其原理就是通过hook类被加载的时机来实现类的还原，这个时机肯定要早于函数被执行的时机的，因此可以保证APP正常的运行）。

picture 1

实际上，下面的一些函数也是可以进行Hook的，但是由于可能没有导出符号，所以hook的难度不如dexFindClass容易，这也是姜维选择这个函数进行hook的原因之一。

ART下抽取壳实现
ART下的抽取壳首要解决的是禁用dex2oat

dex加载流程当中，dex2oat是可以实现脱壳的。当dex完成对dex编译以后——即生成了oat文件之后，后续的函数调用的过程当中，就会直接从oat取出编译生成的二进制代码去执行。因此，如果我们对dex进行函数抽取和填充的时机不对的话，我们填充的代码就无法生效，因为我们后面在运行时，调用的真正代码就会从dex2oat编译生成的oat文件当中获取，则此时跟以前的dex没有关系了。所以要想使得我们填充回去的指令生效，要么，禁用dex2oat；要么，还原的时机早于dex2oat。

  • ps : 第一种解决方案是加固厂商最常使用的，因为不禁用dex2oat时，我们的还原时机就要在dex2oat之前，而此时，可以利用dex2oat的编译过程就可以使得壳被脱下来。dex2oat实际上是用来提上app的运行效率的，但是加壳则是需要禁用掉它。

让我们来到之前分析的ART下dex2oat的脱壳点时的这个函数GenerateOatFileNoChecks,该函数用于开始调用dex2oat进行编译。

picture 2

该函数当中有一个Dex2Oat函数，我们跟进去。

picture 3

再跟进Exec实际上就是跟进ExecAndReturnCode函数
picture 4
我们可以看到这个函数里fork了一个进程，在这个进程当中，倘若发生任一报错，则执行_exit(1)来退出dex2oat流程。所以，我们只需要在这个函数的fork之后的这个过程当中使其报错即可终止所有的dex2oat。

我们这里通过hook execve来干掉整个dex2oat。

该项目也实现了干掉dex2oat: TurboDex,达到让我们的dex在第一次加载的过程当中快速的加载完成。倘若不干掉dex2oat,我们的ART虚拟机将会调用dex2oat进行编译，而该编译过程非常耗时，所以通过干掉它达到提升DexClassLoader的加载效率。该项目是通过Hook execv来解决。具体hook execv还是execve是由安卓的版本来决定的。有的版本不适用execv。该项目通过适用inline hook库来进行hook,也可以使用爱奇艺的xhook，该库通过JOT可以实现干掉dex2oat.

这里我们通过hook libc的execve来实现Hook
picture 5

寻找时机点——还原被抽空函数

FART正餐前甜点：ART下几个通用简单高效的dump内存中dex方法
可以参考寒冰老师的这篇文章。

抽空函数：
首先先抽空codeItem,即在32位的codeitme的 后16位全部置0，然后重新计算校验位使其合法。

FART学习

picture 1

FART由三个组件组成

  1. 脱壳组件
    与前面介绍的脱整体DEX保护的方案差不多，但是脱壳点不一样，这个只是为了获取DEX的结构体，而对于其中每一个函数的子类部分，即code_item部分只作为参考，真正使用的code_item不在脱壳组件拖出来的code_item中产生。

  2. 主动调用组件
    主要用于解决函数抽取的代码解决方案，该组件用于构造一条让壳以为自己的APP在调用其函数的路径，从而使得壳把APP源代码还原出来。

    此时前两部使得我们拥有了两种信息：

    1. DEX的结构性信息（来自脱壳组件）
    2. DEX当中每一个函数的指令信息（来自主动调用组件Dump）

  3. 修复组件
    用于整合DEX的结构体信息和每一个函数的函数体信息，从而修复DEX被抽取掉的内容。

脱壳组件

第一个脱壳点

与dex2oat的原理有很大的关系，但是又不在dex2oat的流程当中脱下来的。

apk安装时进行的dex2oat编译流程
picture 1

流程的最后会来到CompileMethod,
picture 2
在源码当中可以看到，每一个函数（除了初始化函数），都会进行基本检查

  • dex2oat编译流程：函数粒度进行编译

并不是所有函数都会被编译。比如类初始化函数。因此，对于当一个类被初始化时，该类的初始化函数始终运行在interpreter模式。

ART下函数执行模式
- interpreter模式：由ART下的解释器执行
- quick模式：直接允许dex2oat编译生成的arm指令
类的初始化函数始终运行在解释模式下的两种情况

一个壳用DexClassLoader进行加载一个dex文件时，如果没有禁用dex2oat,类的初始化函数运行在interpreter模式（解释模式）下，如果禁用掉了dex2oat则所有的函数都运行在解释模式下。

  1. 如果运行在解释模式下，必然会运行在ART下的解释器去完成一个取址操作——取出每个函数对应的code_item中的每一条smali去解释执行。
    ART下解释器不同版本存在不同的实现
    8-10版本：
     存在两种实现：
     1. Switch-interpreter 
     2. Assembly interpreter (汇编),默认是走汇编解释器。这里汇编实现的调用及效率高于Switch-interpreter的实现。
    7及以下版本存在三种实现：
         1. Switch-interpreter 
     2. Assembly 
     3. Computed-goto-based interpreter
的ArtMethod对象

即使流程走到了dex2oat下，所有除函数外都走的是Art下的interpreter解释器，但是函数也是有存在对应的ArtMethod对象的。

我们可以通过ArtMethod对象的GetDexFile函数获取其所属的DexFile对象
picture 1

DexFile存在Size()和Begin()两个函数。
Begin() -> 用于获取当前的DexFile这个对象对应的Dex文件在内存中的起始地址。

Size() -> 获取当前Dex文件的大小。

因此，可以通过ArtMethod下的GetDexFile()获取所属的DexFile对象，进而通过Begin()函数和Size()函数获取Dex起始文件的大小和地址。

FART选择的第一个脱壳点是建立在interpreter模式流程中。

一个函数在进入到解释器之前，会先进入到interpreter (其实现类是InterpreterImplKind,写出来方便后续搜索)的Execute
picture 2
在这个函数当中会调用给具体的解释器进行解释执行。在这里，我们对当前的初始化函数所属于的Dex文件进行dump,则可实现脱壳。

修改AOSP源码的小技巧

当我们修改一个AOSP里的一个很通用的函数时，可能会导致一个函数被脱出多次的情况，此时可以通过判断当前的函数名来进行过滤即可，如何判断函数名呢，ArtMethod类里有一个函数可以返回当前ArtMethod函数的函数名PrettyMethod

现有脱壳方法的根本原理

对于每一个加载Dex的文件来说，要么是加载一个DexFile对象要么就是DexFile结构体。

常用的方法就是在源码当中搜索DexFile，可以看到海量的点都可以用来脱壳，然后添加相应的脱壳代码，优先找到：参数中出现DexFile对象，其次找到返回值出现DexFile对象，最后在函数执行过程中出现DexFile对象。这些都是潜在的脱壳点。还可以通过ArtMethod对象来获取其对应的DexFile对象。

举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include <sys/types.h>    
#include <sys/stat.h>    
#include <fcntl.h>

  // inline const DexFile* ArtMethod::GetDexFile()
  ArtMethod* artmethod = shadow_frame.GetMethod();
  // jiang di tuo ke pin lve
  if(strstr(artmethod->PrettyMethod().c_str(), "<clinit>")){
	    const DexFile* dexfile = artmethod->GetDexFile();
  
  //size_t Size() const {
    //return size_;  
    //}
    

//const uint8_t* Begin() const {
  //  return begin_;
//  }
	const uint8_t* begin = dexfile -> Begin();
	size_t size = dexfile -> Size();
	
	char dexfilepath[100] = {0};
	sprintf(dexfilepath, "/sdcard/%d_%d_Excute.dex", (int)size, getpid());
	int fd = open(dexfilepath,O_CREAT|O_RDWR, 0666);
	if(fd > 0){
		int number = write(fd, begin, size);
		if (number > 0){
		
		}
		close(fd);
	}
  }
如何判断一个脱壳点的好坏
Execute为什么是一个很好的脱壳点

不管加固厂商有没有禁用dex2oat的流程，对于一个Dex文件来说，它其中的类是很多的，而对于其中的类的初始化函数来说，都会进入到解释执行的流程当中。对于Execute这个函数来说，它还是一个inline函数，即内联函数，加固厂商无法通过Hook的方法修改函数的逻辑的。

与FART中主动调用相关的概念

  1. 被动调用
    指app正常运行过程中所发生的调用，该过程只对dex中部分类完成加载，同时也只是对dex中的部分函数完成了加载调用。
  • 被动调用脱壳的缺点：存在修复函数不全的问题。
  1. 主动调用
    通过构造虚拟调用，从而达到欺骗壳，让壳误认为app在执行正常的函数调用流程从而达成对dex中所有类函数的虚拟调用。
  • 主动调用的优点：能够覆盖dex中所有函数，从而完成更彻底的函数粒度的修复。同时，函数的修复准确度同主动调用链的构造深度有关。

FART是模拟调用所有类，而并非真实的调用，免去了复杂的参数构造。

如何获取每一个函数的CodeItem

picture 1
一个Java函数最终在内存当中对应的codeitem

每一个CodeItem在内存当中的前16个字节是固定的，
picture 3
我画圈的部分是固定的部分。
uint_debugInfoOff: 这一部分对于一个发布的或者说是加壳后的应用来说是无用的，一般会进行抹除。
16个字节之后的部分才是指令的部分，具体的指令数为：
指令数 = insnsSize * 2。
指令相关的长度并非为CodeItem的长度，还与其是否有异常处理有关。

CodeItem的长度的计算

没有异常处理的函数：
picture 1
其长度为32个字节，前16个字节包含需要的寄存器的个数（ushort registers_size的数值，这里为3），还有参数的个数（ushort ins_size的数值，这里为1），调用时候的寄存器的个数(ushort outs_size的数值，这里为2)，以及刚才提到的一般会被抹去的uint debug_info_off。

*由于这里没有异常处理，所以可以直接用uint insns_size * 2 得到除前16个字节外该codeitem的长度为16 + insns_size * 2 = 16 + 8 * 2 = 32*,由上图也可以看到010 Editor也已经帮我们把该codeitem的范围长度也给标亮出来了。

接下来要判断有异常处理的函数的codeitem长度了。

在这之前，我们要清楚的知道怎样识别我们要判断的codeitem是不是包含异常处理。起始codeitem的结构是有相应的标识的ushort tries_size为1时，则为包含异常处理的codeitem。

有异常处理的函数
picture 2
除了前16个字节以外，我们先看看insns_size，这里总共有23个字节，除异常处理外的字节长度就为23 * 2 + 16 = 62。我们可以通过图片的高亮处，可以得出这个codeitem总长为77个字节，也就是说现在还有15个字节没有算出来。

实际上看这个结构也可以得出
picture 3

有异常处理的codeitem_size = ins_size * 2 + 16 + try_item_tries的长度 + encoded_catch_handler_list handle的长度

主动调用组件

picture 1

FART的使用及应用场景

FART生成的bin文件即CodeItem的格式

5元组填充
{name:函数名，method_idx:函数索引，offset:偏移，code_item_len:长度,ins:函数体codeltem的base64字符串};

method_idx:
picture 4
为图中的这些下标

offset:
偏移，当前函数体CodeItem在当前Dex文件的偏移在哪个位置，这个字段方便我们定位Dex文件的偏移，方便我们填充函数

code_item_len:
当前CodeItem的长度

ins:
CodeItem的Base64编码。意让CodeItem成为可视的编码，存放进txt文件里可直接打开，修复时直接对其进行Base64解码。

红色的字段为必需的，其他的不必需，但是可以作为参考。即只需要method_idx进行区分函数以及该函数的Codeltem内容即可

手动回填抽空的函数

picture 5
该函数需要修复，则在相应的bin文件搜索MemoryCache.checkSize
picture 6

然后把相应的dex拖入010 Editor
picture 7
找到相应的method_idx,这里为10554，即可找到要修复的函数，然后找到0E这里
picture 1
解码五元组里面的BASE64，解码的内容写进一个.bin文件里
picture 2

这里总共是16行 + 6个字节，然后通过偏移找到需要替换的函数
picture 3
先替换16行，再替换最后6个字节，即可还原！

FART的适用场景
  1. 整体加固壳
  2. FART对dex的修复粒度为函数粒度
frida FART脱壳问题

使用frida FART进行脱壳碰到一个问题，so不管怎么赋权限始终报没有权限。经高人指点，发现似乎只要push so到手机都有类似问题。

原因在于：
selinux(安全增强的Linux)

SELinux被描述为在内核中执行的强制访问控制(MAC)安全结构。SELinux提供了一种强制执行某些安全策略的方法，否则系统管理员将无法有效地实现这些策略。

就是这个机制导致的so跑不起来！

网上搜了如何禁用selinux，但是永久的方法:
“””
要永久禁用SELinux，请使用您最喜欢的文本编辑器打开/etc/sysconfig/selinux文件，如下所示：

vi /etc/sysconfig/selinux
然后将配置SELinux=enforcing改为SELinux=disabled，如下图所示。

SELINUX=disabled
然后，保存并退出文件，为了使配置生效，需要重新启动系统，然后使用sestatus命令检查SELinux的状态，如下所示：

sestatus

“””
用不了！！！，会提示说没有这个文件。。。。。

只好临时禁用selinux来解决问题~

解决方法：
adb shell -> setenforce 0临时禁用selinux

展开全文 >>

python碰到的好用模块（持续更新）

jsonpath

该模块是用于取层次深的字典里的值用的。
具体用法实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
import jsonpath

d = {
    "error_code": 0,
    "stu_info": [
        {
            "id": 314,
            "name": "矿泉水",
            "sex": "男",
            "age": 18,
            "addr": "北京市昌平区",
            "grade": "摩羯座",
            "phone": "18317155663",
            "gold": 100,
            "cars": [
                {"car1": "bmw"},
                {"car2": "ben-z"},
            ]
        }
    ]

}
result=jsonpath.jsonpath(d,'$..car2') #模糊匹配
result=jsonpath.jsonpath(d,'$.stu_info') #取到stu_info这里的所有内容
result = jsonpath.jsonpath(d, '$.stu_info[0]') #取到stu_info里的第1个元素
result = jsonpath.jsonpath(d, '$.stu_info[0].id')  # 取到stu_info里的第1个元素中的id
print(result)

展开全文 >>

Andoir Gradle出现Error:Cause: unable to find valid certification path to requested target的解决方法，亲测有效系列

前言（废话）

由于公司出现题述问题，导致严重影响本人学习Android，所以费劲心思终于找到了国内的镜像。

解决方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
buildscript {
  repositories {
    maven { url 'http://maven.aliyun.com/nexus/content/repositories/google' }
    maven { url 'http://maven.aliyun.com/nexus/content/repositories/jcenter'}
  }
  dependencies {
    classpath 'com.android.tools.build:gradle:3.6.1'
    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
  }
}
allprojects {
  repositories {
//    google()
//    jcenter()
    maven { url 'http://maven.aliyun.com/nexus/content/repositories/google' }
    maven { url 'http://maven.aliyun.com/nexus/content/repositories/jcenter'}
  }
}

修改build.gradle为以上代码部分，即可同步阿里的源，一般家里第一次同步不要走代理，后续可以走，尽量等到同步完成。当然如果你要像这样同步阿里源还是飞快的。

展开全文 >>

dex文件格式学习

什么是dex

dex是Android系统特有的可执行文件，具有应用的全部指令及运行时数据。
.class通过dx工具整合到一个dex,使得各个类都能互相通信，且减小占用的空间，使得结构更加紧凑。

class文件和dex的结构存在本质上的不同。
picture 1

为什么不使用class格式而采用dex格式
  1. dex整合所有的class文件压缩在classes.dex当中，所有的字符串常量可能会包含重复的，而整合在一起则可以最大化减少重复的字符串等信息。
  2. 如果一个class文件依赖另一个class文件则需要加载另一个class文件，这就会造成I/O操作，因为一次性把所有class文件加载，可以使得I/O操作减少。
字节序

计算机硬件有两种储存数据的方式：大端字节序（big endian）和小端字节序（little endian）。

dex格式存储采用的是小端字节序,比如一个16进制数0x2211,大端字节序跟该数字一致，采用高位字节在前低位字节在后。

而小端字节序则与大端字节序相反，采用高位字节在后低位字节在前，则该数位0x1122

同理0x987654其小端字节序写做:0x456789,即人一般读数是按大端字节序读取，而dex的读数是按小端字节序来读取的，其实这一块会由外部设备进行自动转换方便人的阅读，理解即可。

信息描述规则
数据类型描述（Type Descriptor）

数据类型描述说的是用字符串表示不同的数据类型。在这方面，Dex和Class文件格式没有区别。

  1. 原始数据类型对应的字符串描述为”B”,”C”,”D”,”F”,”I”,”J”,”S”,”Z”，它们分别对应的
    Java类型为byte,char,double,float,int,long,short,boolean。
  2. “V”：表示void，不过只能用于表示函数的返回值类型。
  3. 引用数据类型的格式为”LClassName;”。此处的ClassName为对应类的全路径名。
  4. 数组用”[其他类型的描述名”来表示。Dex文件最多支持255维数组。
简短描述（Shorty Descriptor）

用来描述函数的参数和返回值信息，类似Class文件格式的MethodDescriptor。不过，Shorty Descriptor比MethodDescriptor要抠，省略了好些个字符。

定义ShortyDescriptor的描述规则，箭头后面是规则的组成：

  1. ShortyDescriptor → ShortyReturnType (ShortyFieldType)*
  2. ()在规则中表示一个Group，*号表示这个Group可以有0或多个

定义ShortyReturnType的描述规则：
ShortyReturnType → ‘V’ | ShortyFieldType
ShortyFieldType → ‘Z’ | ‘B’ | ‘S’ |’C’ | ‘I’ | ‘J’ | ‘F’ | ‘D’ |’L’
定义ShortyFieldType的描述规则，注意，引用类型统一用”L”表示即可

ShortyDescriptor是”返回值类型”+”参数类型”，如果有参数就会带参数类型，没有参数就只有返回值类型。

在ShortyDescriptor的ShortyFieldType中，引用类型只需要用”L”表示，显然，ShortyDescriptor对于那些参数或返回值类型为引用类型的函数将无法区分。不过没关系，Dex中还会提供其他数据来指明参数或返回值的具体类型。这种做法的原因其实还是为了减少字符串的使用。

DexHeader
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/*
 * Direct-mapped "header_item" struct.
 */
struct DexHeader {
    u1  magic[8];           /* includes version number */
    u4  checksum;           /* adler32 checksum */
    u1  signature[kSHA1DigestLen]; /* SHA-1 hash */
    u4  fileSize;           /* length of entire file */
    u4  headerSize;         /* offset to start of next section */
    u4  endianTag;
    u4  linkSize; // link_data，理论上是预留区域，没有特别的作用。
    u4  linkOff;
    u4  mapOff;
    u4  stringIdsSize; // string_ids数组，元素类型为string_id_item，它存储和字符串相关的信息。
    u4  stringIdsOff;
    u4  typeIdsSize; // type_ids数组，元素类型为type_id_item。存储类型相关的信息（由TypeDescriptor描述）。
    u4  typeIdsOff; 
    u4  protoIdsSize; // proto_ids数组,主要功能就是用于描述成员函数的参数、返回值类型，同时包含ShortyDescriptor信息
    u4  protoIdsOff;
    u4  fieldIdsSize; // field_ids数组，元素类型为field_id_item，存储成员变量信息，包括变量名、类型等。
    u4  fieldIdsOff;
    u4  methodIdsSize; // method_ids数组，元素类型为method_id_item，存储成员函数信息包括函数名、参数和返回值类型等。
    u4  methodIdsOff;
    u4  classDefsSize; // class_defs数组，元素类型为class_def_item，存储类的信息。
    u4  classDefsOff;
    u4  dataSize; // data区域，Dex文件重要的数据内容都存在data区域里。一些数据结构会通过如xx_off这样的成员变量指向文件的某个位置，从该位置开始，存储了对应数据结构的内容，而xx_off的位置一般落在data区域里。
    u4  dataOff;
};

注：邓凡平先生主要把dex_header分成
picture 2
上面的注释也主要围绕这个分发加注

header_item

header_item是一个二进制数据集合，邓凡平先生通过编程语言还原了其结构
picture 3

magic: 取值必须是字符串“dex\n035\0”，或者byte数组{0x640x650x780x0a 0x300x330x350x00}

checksum: 文件内容的校验和。不包括magic和checksum自己。该字段的内容用于检查文件是否损坏。

signature: 签名信息，不包括magic、checksum和signature。该字段的内容用于检查文件是否被篡改。

file_size: 整个文件的长度，单位为字节，包括所有内容。

header_size: 默认是0x70个字节。

endian_tag: 表示文件内容应该按什么字节序来处理。默认取值为0x12345678，Little Endian格式。如果为Big Endian时，该字段取值为0x78563412。

xxx_id_item: 包括string_id_item、type_id_item、proto_id_item、field_id_item和method_id_item这五种数据结构，它们对应为string_ids、type_ids、proto_ids、field_ids和method_ids数组元素的数据类型。

picture 4

string_data_item: utf16_size是字符串中字符的个数。Dex文件的字符串采用了变种的UTF8格式，对于英文字符和数字字符而言，都只占一个字节。data是字符串对应的内容。

string_id_item: 类似Class文件的CONSTANT_String类型，它只有一个成员。

string_data_off: 用于指明string_data_item位于文件的位置，也就是索引。

type_id_item: descriptor_idx是指向string_ids的索引。

field_id_item: class_idx和type_idx是指向type_ids的索引，而name_idx是指向string_ids的索引。

method_id_item: class_idx是指向type_ids的索引，proto_idx是指向proto_ids的索引，name_idx是指向string_ids的索引。

proto_id_item: shorty_idx是指向string_ids的索引，return_type_idx是指向type_ids的索引，如果parameters_off不为0，则文件对应的地方存储类型为type_list的结构，用于描述函数参数的类型。

type_item: type_idx是指向type_ids的索引。

type_list: size表示list数组的个数，而list数组元素类型为type_item。函数的每一个参数都对应一个type_item元素。

于proto_id_item: 首先，它的成员域shorty_idx（也就是ShortyDescriptor字符串）已经描述了参数和返回值的类型，但这只是简单描述，比如所有引用类型都用”L”统一表示，所以ShortyDescriptor肯定无法完整描述那种参数或者返回值类型为引用类型的函数。为解决此问题，proto_id_item中的return_type_idx用来描述返回值的数据类型，而参数的类型则通过parameters_off域（如果取值不为0，则表示该函数有参数）指向一个type_list。这个type_list为每个参数都存储了对应的数据类型（通过type_item中的type_idx来索引type_ids中的元素）。

class_def:
picture 5
class_idx：指向type_ids，代表本类的类型。

superclass_idx：指向type_ids，代表基类类型，如果没有基类则取值为NO_INDEX（值为-1）。

interfaces_off：如果本类实现了某些接口，则interfaces_off指向文件对应位置，那里存储了一个type_list。该type_list的list数组存储了每一个接口类的type_idx索引（参考图3-5和对应的解释）。

source_file_idx：指向string_ids，该类对应的源文件名。

annotations_off：存储和注解有关的信息。

class_data_off：指向文件对应位置，那里将存储更细节的信息，由class_data_item类型来描述。

static_values_off：存储用来初始化类的静态变量的值，静态变量如果没有显示设置初值的话，默认是0或者null。如果有初值的话，初值信息就存储在文件static_values_off的地方，对应的数据结构名为encoded_array_item

picture 6
一个类的成员变量、成员函数等信息则是通过class_data_off域指向一个名为class_data_item结构体来描述的。

static_fields：类的静态成员信息，元素类型为encoded_field。
instance_fields：类的非静态成员信息，元素类型为encoded_field。
direct_methods：非虚函数信息，元素类型为encoded_method。
virtual_methods：虚函数信息，元素类型为encoded_method。

encoded_field和encoded_method用于描述类的成员变量和成员函数的信息。

encoded_field：field_idx_diff指向field_ids。注意这里是field_idx_diff，它表示除数组里第一个元素的field_idx_diff取值为索引值，该数组后续元素field_idx_diff取值为和前一个索引值的差。access_flags表示成员域的访问标志

encoded_method：method_idx_diff指向method_ids。diff的含义与field_idx_diff一样。access_flags表示该函数的访问标志，code_off指向文件对应位置处，那里有一个类型为code_item的结构体，code_item类似于Class文件的Code属性。

access_flags取值范围

picture 7
picture 8

code_item

dex格式当中，我们需要了解的重中之重，因为函数抽取实际上就是把code_item进行抽空（置0）的方式实现的。
picture 9

registers_size：此函数需要用到的寄存器个数。

ins_size：输入参数所占空间，以双字节为单位。

outs_size：该函数表示内部调用其他函数时，所需参数占用的空间。同样以双字节为单位。

insns_size和insns数组：指令码数组的长度和指令码的内容。Dex文件格式中JVM指令码长度为2个字节，而Class文件中JVM指令码长度为1个字节。

tries_size和tries数组：如果该函数内部有try语句块，则tries_size和tries数组用于描述try语句块相关的信息。注意，tries数组是可选项，如果tries_size为0，则此code_item不包含tries数组。

padding：用于将tries数组（如果有，并且insns_size是奇数长度的话）进行4字节对齐。

handlers：catch语句对应的内容，也是可选项。如果tries_size不为零才有handlers域。

padding则是需要对齐的时候才存在

展开全文 >>

爬虫遇到的问题

nodejs 的 express框架post总是接收不到参数

一般我都会把data转成json再传给nodejs服务，结果总是获取不到参数，脑壳痛，这里记录一下。
picture 1

首先发送请求的时候，要给定Content-Type为application/jsongi

注意app.use那里，指定了从header的content-type为application/json的请求获取参数，这里的limit是为了扩大接收的参数大小，这里我随意写了一个足够大的大小。
picture 2

如果不写limit会发生什么情况呢？
picture 3

会出现请求体过大导致报错的情况。

究其原因是因为nodejs 做为服务器，在传输内容或者上传文件时，系统默认大小为100kb。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

一只从Java到爬虫未来将会到安全的软件工程师。