Java层Hook简单的代码框架： 1234567891011function main(){ //使用Java平台，Java层hook在Java.perform中执行 Java.perform( //代码逻辑 function(){ ... } )}//调用main方法setImm

只讲ART下的脱壳，DVM太过时了 一、脱壳点分析编写过Android第一二代加固壳的可以知道，无论是通过系统的类加载器加载的，还是通过自定义类加载器加载的，无一例外，最终都逃不过创建DexFile对象： 123456789101112131415161718192021222324252627282930313233343536373839404142434445class DexFile

一、对第一代壳的改良在第一代加固壳中，会将源程序APK存储到文件系统中，然后再通过DexClassLoader动态加载。这种落地加载方式存在很大问题，一是容易在文件系统中获取到源程序APK，二是两次加载源程序APK到内存中，效率低。 第二代壳就是为了解决上述问题，做到不落地加载，即不使用文件系统作为中转站，而是直接将内存中的源APK字节码进行加载。 那么问题就来了，怎样解决加载内存dex的难题呢？

一、前言在 Android 逆向过程中，常常可以见到 java 层使用 native 函数，但 native 函数并没有在 java 层实现，而是在 native 层实现，java 层通过加载库文件来正常使用该函数。java 层之所以可以使用 native 层实现的函数，是因为 JNI 的存在。 如果我们进一步探究 so 文件，可以发现有的 so 文件中含有 JNI_OnLoad 函数，而有的没有

一、前言在之前分析dex文件加载流程中（dex文件加载流程(一)(二)(三)），我们分析过了DexClassLoader和PathClassLoader这两个类加载器加载dex的流程。它们两个都是用来记载文件dex的，但是在Android 8新增了InMemoryDexClassLoader，专门用于加载内存dex，接下来我们就根据源码来剖析内存dex的加载流程。 二、InMemoryDexCla

在这之前，我们需要分析一下封装Java反射方法是为了干什么。 显然在Android第一代加固壳的原理及实现一文中，我们重复地使用到了Java反射来获取类、字段、方法，无一例外，获取它们的最终目的是获取字段值、修改字段值、调用方法。为了实现这些目的，我们写了很臃肿的代码，因为太多重复的反射获取，所以我们可以将这些代码封装起来，形成一个自定义类，这样一来，加固的代码就可以变得轻巧了，且这个封装类以后还

想解释一下一代壳的脱壳代码为什么这么写，以及一些代码中的细节，解释全在代码注释中！！！ 思维有点乱，可能有错误的地方，烦请告知，谢谢！ 话不多说，直接看handleBindApplication()，想要详细跟踪Application的创建请阅读Android中Application的创建流程。 12345678910111213141516171819202122232425262728293

一、前言学习加壳之前，建议先把前置知识学习再说。我们需要先学习dex文件结构、java反射、Android中的ClassLoader、Application以及它的加载流程、App启动流程。 不然我真不建议直接莽它，不懂原理只能学到皮毛！ 二、第一代加固壳原理第一代加固壳原理如下图所示： 在图中涉及到三个程序： 待加壳程序的APK（源程序APK） （脱）壳程序APK（负责解密源程序APK并加载

一、Application是什么Application同Activity、Service一样，都是Android系统的组件。当应用程序启动过程中，最先创建的是Application实例（有且仅有一个），它的创建早于应用程序启动以及任何Activity、Service或接收者对象（不包括ContentProvider）的创建。Application的生命周期是整个应用程序中最长的，它的生命周期就等于

一、前言System进程和App进程都运行着一个或多个App，每个App都会有一个对应的Application对象(该对象跟LoadedApk一一对应)。下面分别解析以下两种进程创建Application的过程： System Server进程 App进程 二、System Server进程在Android系统启动流程一文中，讲到过Zygote通过回调函数进入到System Server阶段，