在 上一篇博客 【Android 逆向】启动 DEX 字节码中的 Activity 组件 ( 替换 LoadedApk 中的类加载器 | 加载 DEX 文件中的 Activity 类并启动成功 ) 中 , 通过 替换 LoadedApk 中的类加载器可以成功加载 DEX 字节码文件中的 Activity 类 , 并成功启动 Activity ;
Java程序中,JVM虚拟机是通过类加载器ClassLoader加载.jar文件里面的类的。Android也类似,不过Android用的是Dalvik/ART虚拟机,不是JVM,也不能直接加载.jar文件,而是加载dex文件。
ART 虚拟机下的 DexClassLoader 的构造函数 , 与 Dalvik 虚拟机下的 DexClassLoader 构造函数基本相同 , 都是只实现了一个构造函数 , 调用了 BaseDexClassLoader 父类 ;
一代壳 即 DEX 整体加固 , 所有类型的加固 , 都会在最外围加上一层 整体加固的 壳 , 即使进行了 VMP / Dex2C 高级防护 , 最后也会在高级加壳的外层基础上 , 进行 DEX 进行整体加固 ;
在 【Android 热修复】热修复原理 ( 加载 Dex 文件到内存中 | DexClassLoader | PathClassLoader | 反射 Element[] dexElements ) 博客中已经将 系统加载的 Dex 文件对应的 Element[] dexElements 通过 PathClassLoader 类加载器获取到了 , 同时修复包对应 Dex 文件 Element[] dexElements 通过 DexClassLoader 类加载器获取到了 ;
DexClassLoader 是加载 dex 文件的核心类 , 但是该类除了定义了一个构造函数之外 , 并没有实现其它业务逻辑操作 ;
ClassLoader 是抽象类 , 是所有 类加载器 ClassLoader 的父类 ;
个类加载器 , BootClassLoader , PathClassLoader , DexClassLoader ;
在 上一篇博客 【Android 逆向】启动 DEX 字节码中的 Activity 组件 ( DEX 文件准备 | 拷贝资源目录下的文件到内置存储区 | 配置清单文件 | 启动 DEX 文件中的组件 | 执行结果 ) 的代码基础上 , 使用类加载器加载 com.example.dex_demo.MainActivity2 组件前 , 先替换 LoadedApk 的类加载器 , 就可以成功加载 DEX 文件了 , 该操作类似于热修复 ;
我们都知道要获Res下的文件,需要用Resource对象,但是apk是未安装的,宿主并没有对应的resId,因此获取资源需要进行反编译,反编译需要对应的插件的包名,就是反编译R资源。 贴代码,举个例子: 插件管理器类
【Android 热修复】热修复原理 ( 修复包 Dex 文件准备 | Dex 优化为 Odex | Dex 文件拷贝 | 源码资源 ) 【Android 热修复】热修复原理 ( Dex 文件拷贝后续操作 | 外部存储空间权限申请 | 执行效果验证 | 源码资源 )
源码路径 : /libcore/dalvik/src/main/java/dalvik/system/DexClassLoader.java
【Android 插件化】插件化简介 ( 组件化与插件化 ) 【Android 插件化】插件化原理 ( JVM 内存数据 | 类加载流程 ) 【Android 插件化】插件化原理 ( 类加载器 )
当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时出错,提示: Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536 出现这种问题的原因是: 1. Android2.3及以前版本用来执行dexopt(用于优化de
脱壳就是要在加固厂商使用类加载器加载 DEX 文件时 , 从加载过程中 , 从内存中获取 DEX 文件 ;
【Android 插件化】插件化简介 ( 组件化与插件化 ) 【Android 插件化】插件化原理 ( JVM 内存数据 | 类加载流程 ) 【Android 插件化】插件化原理 ( 类加载器 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 原理与实现思路 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 类加载器创建 | 资源加载 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 注入上下文的使用 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 获取插件入口 Activity 组件 | 加载插件 Resources 资源 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 运行应用 | 代码整理 )
为了深入了解Android 逆向相关的内容中加壳的原理,前面已经完成了关于Android中的动态加载和动态加载类关系的详解,那么接下来是对Android的整体加壳进行实现,并对原理进行讲解,由于作者能力有限,会尽力的详细描述整体加壳的流程及原理,如本文中有任何错误,烦请指正,感谢~
在 dex_demo 应用 Module 中 , 创建 com.example.dex_demo.MainActivity2 类 ;
讲起 Android 的热修复,相信大家对其都略知一二。热修复可以说是继插件化之后,又一项新的技术。目前的 Android 热修复框架主要分为了两类:
ClassLoader 抽象类中的 private final ClassLoader parent 成员 , 用于实现双亲委派机制 , 所有的 ClassLoader 子类 , 如 PathClassLoader , DexClassLoader 等类加载器 , 都会存在一个 ClassLoader parent 成员 , 用于表示该 类加载器 的父节点 是哪个 类加载器 ;
我们知道不管是插件化还是组件化,都是基于系统的ClassLoader来设计的。只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码
在上一篇博客 【Android 逆向】启动 DEX 字节码中的 Activity 组件 ( DEX 文件准备 | 拷贝资源目录下的文件到内置存储区 | 配置清单文件 | 启动 DEX 文件中的组件 | 执行结果 ) 中 , 尝试启动 DEX 字节码文件中的 Activity 组件 , 出现如下报错信息 :
在 【Android 逆向】类加载器 ClassLoader ( 使用 DexClassLoader 动态加载字节码文件 | 准备 DEX 字节码文件 ) 博客中 , 准备了 classes.dex 字节码文件 , 将字节码文件拷贝到了 将 app\src\main\assets\classes.dex 目录中 ;
上篇文章讲到了apk的分包,通过multidex构建出包含多个dex文件的apk,从而解决65536的方法数限制问题《Android Dex分包》。
在上一篇博客 Android热修复学习之旅开篇——热修复概述中,简单介绍了各个热修复框架的原理,本篇博客我将详细分析QQ空间热修复方案。
前言 好几个月之前关于Android App热补丁修复火了一把,源于QQ空间团队的一篇文章安卓App热补丁动态修复技术介绍,然后各大厂的开源项目都出来了,本文的实践基于HotFix,也就是QQ空间技术
市场上热修复有两种一种是基于multidex的更新修复(比如tinker),另外一种是native hook(比如dexposed),tinker这种是反射获取dexelements数组,修改dex加载顺序。今天我们主要介绍dex这种。 热修复包括两个部分
NotDoVerifyClasses和AntiLazyLoad在dex中居然找不到,这勾起我的兴趣。先来debug看看,到底是从哪里加载的这两个类:
众所周知,Java程序运行过程是这样的。首先,Java源码编译器将java文件编译成二进制的字节码class文件。然后,Java虚拟机再运行class文件。class文件是怎么加载到JVM里面的呢?答案是通过 ClassLoader 的加载机制。安卓虚拟机也有类似这样的机制,为了能编写出更高效的代码,我们有必要了解下ClassLoader 的加载机制。本文先会分别详解安卓的 ClassLoader。
支持插件化的app可以在运行时加载和运行插件,这样便可以将app中一些不常用的功能模块做成插件,一方面减小了安装包的大小,另一方面可以实现app功能的动态扩展。
通过上面几个类的关系,和类的查找过程,我们可以发现最终是通过遍历 DexPathList的 dexElements数组进行类的查找加载,当找到类就返回;
例如记住了当前类的引用this、父类super等等。class文件记录的信息往往比java文件多。
插件化技术可以说是Android高级工程师所必须具备的技能之一,从2012年插件化概念的提出(Android版本),到2016年插件化的百花争艳,可以说,插件化技术引领着Android技术的进步。本篇
之前一直了解到加壳脱壳,直接使用Fart等脱壳工具进行的,停留在知其然不知其所以然的层次,所以以此准备进行Android 基础理论的学习中,首先要深入理解类加载器和动态加载二者之间的关系,本文记录了类加载器和动态加载之间的关系和原理,由于作者能力有限,会尽力的详细讲解两者之间的关系,如本文中有任何错误,烦请指正,感谢~
我们知道,Java源文件(.java)经过编译器编译之后,会转换成Java字节码(.class),然而程序是如何加载这些字节码文件到内存中呢?这就用到了ClassLoader,即类加载器。ClassLoader类加载器负责读取 Java 字节代码,并转换成 java.lang.Class类的一个实例。从而只有class文件被载入到了内存之后,才能被其程序所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。
前言 在上一篇文章我们学习了Java的ClassLoader,很多同学会把Java和Android的ClassLoader搞混,甚至会认为Android中的ClassLoader和Java中的ClassLoader是一样的,这显然是不对的。这一篇文章我们就来学习Android中的ClassLoader,来看看它和Java中的ClassLoader有何不同。 1.ClassLoader的类型 我们知道Java中的ClassLoader可以加载jar文件和Class文件(本质是加载Class文件),这一点在A
任何结论在没有经过实际检验之前都不能够确定一定没问题。三年前写的文章回过头来发现有些部分内容是有问题的(PS:这的确比较尴尬),再次对结果进行验证之后重新修改了之前的结论。幸亏文章阅读量不是很多,希望被误导的同学能够在其他地方得到正确结论。
项目组件化的重要环节在于,将项目按照模块来进行拆分,拆分成一个个业务module和其他支撑module(lib),各个业务module之间互不依赖,互相解耦!每个业务module都可以安排不同的开发人员团队来进行开发,不强制使用一种开发模式,MVP可以,MVC也可以!然后各个业务module之间通过路由机制进行跳转和传递!
基本原理:加载类的时候是找element,每个element对于一个dex。我要把我修复的那个类单独放到dex插入dexlist前面,在你做类加载从前往后找优先从你的dex加载加载的就是你修复后的class.这就是
大致的意思是: ClassLoader 是一个负责加载classes的对象,ClassLoader类是一个抽象类,需要给出类的二进制名称,ClassLoader尝试定位或者产生一个class数据,一个典型的策略是把二进制名字转换成文件名然后到文件系统中找到该文件 以下是ClassLoader常用到的几个方法及其重载方法:
https://github.com/5A59/android-training/tree/master/common-tec/CommonTec
C/C++代码实现的加载器,用于加载指定的JDK的核心类库,比如java.lang.、java.uti.等这些系统类。Java虚拟机的启动就是通过Bootstrap ClassLoader创建一个初始类来完成的。
动态加载 : 调用 Java 类时 , 使用到的时候 , 才从 DEX 字节码文件中加载对应的字节码类 ;
2.最简单的插件化方案就是在宿主的androidmanifest.xml中申明插件中的四大组件
| 导语 插件化技术最早从2012年诞生至今,已经走过了5个年头。从最初只支持Activity的动态加载发展到可以完全模拟app运行时的沙箱系统,各种开源项目层出不穷,在此挑选了几个代表性的框架,总结其中的技术原理。由于本人水平有限,插件化框架又相当复杂,文中若有错误或者不准确的地方望高手指点。 内容概要 一、发展历史 插件化技术最初源于免安装运行apk的想法,这个免安装的apk可以理解为插件。支持插件化的app可以在运行时加载和运行插件,这样便可以将app中一些不常用的功能模块做成插件,一方面减小了安
领取专属 10元无门槛券
手把手带您无忧上云