1.DVM JVM区别
1.1 基础架构不同
jvm是基于栈的，需要在栈中读取数据，所需要的指令会更多，这样会导致速度更慢。
DVM是基于寄存器的，他没有基于栈在虚拟机拷贝数据，而是使用大量的入栈和出栈指令，同时指令更加的紧凑简洁。
1.2执行字节码不同
jvm
1).编写java
2).通过javac编译成字节码
3).解释成机器语言
4).执行
DVM
1).编写java
2).通过javac编译成字节码
3).java字节码通过dx转换为DVM字节码
4).在DVM上执行
ART与DVM
1.添加预编译 提升效率
2.本地占用空间更大
2.apk打包流程
2.1apk的组成文件
assets：apk中静态文件
lib：存放本地依赖的native文件
META-INF：存放签名信息，
CERT.RSA 保存签名和公钥证书
CERT.SF 对每个的头三行进行SHA1 hash
MANIFEST.MF ：存放每一个文件的Base64 对每个文件进行整体校验
res：存放资源目录
AndroidManifest：清单文件
class.dex：编译后生成的虚拟机运行的主要文件
resources.arsc：记录资源文件和资源id之间的关系
2.2打包过程
image.png
编译过程
aapt ：将资源文件打包生成 R.java和resources.arsc
aidl：将.aidl文件转化为java文件
javac ：将java文件转换为.class文件
dex：将.class文件转件为.dex文件
打包过程
apkBuilder：将资源文件和.dex文件打包成为签名的apk文件
签名过程
jarSingner .jar签名工具
zipalign :利用zipAlign工具进行对齐处理
3.android 启动流程
大致流程如下
1.bootloader与Linux启动
2.init进程
3.zygote进程
4.systemServer启动
4.app启动流程
image.png
- 点击app图标 launcher进程通过Binder行system_server发送tartActivity请求
- system_server 收到请求后，向zygote进程发送创建进程请求
- zygote进程Fork出新的子进程即app进程
- app进程通过bindIpc system_server发送attachAppliction请求
- system_server进行一系列的准备收后在通过binderIpc向app发送sheduleLanuchActivity请求
- app的binder线程（applicationThread）收到请求后通过handler向主线程发送 LAUNCH_ACTIVITY消息
- 主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法
5.常见加固方式
5.1 代码混淆
代码混淆是一种常用的加密方式。本质是把工程中原来的有具体含义的类名、变量名、方法名，修改成让人看不懂的名字。常见的代码混淆工具proguard。该加密方式只是对工程提供了最小的保护，并不是说不能逆向破解；只是说难度增加，需要耐心。
1）压缩：检测并移除代码中无用的类、字段、方法和特性
2）优化：分析和优化相关方法字节码，移除无用的指令
3）混淆：使用随机的小写且无意义的名称对类、字段和方法进行重命名
4）预校验：在java平台上对处理后的代码进行预校验，验证加载 class文件的可执行性
5.2 dex 文件加密
dex是Android工程中的代码资源文件，通过dex可以反编译出java代码。dex加壳是常见的加密方式。通过对dex文件加密拼接加壳，可以有效的对工程代码进行保护。apk工程在安装成功后，app启动是会有dex解密的过程，然后重新加载解密后的dex文件
5.3 jni 层级加密
使用DexClassLoader动态加载技术完成对加密class.dex的动态加载器，dex文件可以附属在assert或者raw目录
6.加固原理
6.1dex文件结构
image.png
dex Header关键字段解释
magic： 一个有效的dex 文件
checksum：校验码字段，主要用来校验字段保证这段数据的完整性，用来快速校验
signature：签名的SHA1 字段，进行大量计算 全部校验
fileSize 记录整个dex文件
需要关注
们只需要关注 checksum ，signature 和 fileSize 这三个字段，因为将一个文件(加密之后的源Apk)写入到Dex中，那么肯定需要修改文件校验码(checksum)，因为他是检查文件是否有错误。那么signature也是一样，也是唯一识别文件的算法。还有就是需要修改dex文件的大小。
需要做的
修改Dex的三个文件头，将源Apk的大小追加到壳dex的末尾就可以
5.2Application的使用
image.png
整体加固原理如下
image.png
加密过程
1）.源程序
源程序也就是我们的要加固的对象，这里面主要修改的是原apk文件中的classes.dex文件和AndroidManifest.xml文件。
2）.壳程序
壳程序主要用于解密经过加密了的dex文件，并加载解密后的原dex文件，并正常启动原程序。
3）. 加密程序主要是对原dex文件进行加密，
加密阶段：密阶段主要是讲把原apk文件中提取出来的classes.dex文件通过加密程序进行加密。加密的时候如果使用des对称加密算法，则需要注意处理好密钥的问题。同样的，如果采用非对称加密，也同样存在公钥保存的问题
合成新的dex文件：
这一阶段主要是讲上一步生成的加密的dex文件和我们的壳dex文件合并，将加密的dex文件追加在壳dex文件后面，并在文件末尾追加加密dex文件的大小数值
修改原apk文件并重打包签名，
我们需要修改的只有2个文件，分别是classes.dex和AndroidManifest.xml文件，其他文件和文件加都不需要改动
运行壳程序加载原dex文件：Dalvik虚拟机会加载我们经过修改的新的classes.dex文件，并最先运行ProxyApplication类。在这个类里面，有2个关键的方法：attachBaseContext和onCreate方法。ProxyApplication显示运行attachBaseContext再运行onCreate方法。
网友评论