加固加壳脱壳分析(1)_加固加壳原理和几代壳

什么是加固加壳

对App资源代码进行保护，使其不容易被反编译工具解开。
加固的核心在于保证软件正常运行的同时又能保证源码的安全性。

为什么要加固加壳

若应用不做任何安全防护，极易被病毒植入、广告替换、支付渠道篡改、钓鱼、信息劫持等，严重侵害开发者的利益。

加固的方向有哪些

从对抗静态分析入手

资源文件保护
dex文件保护
AndroidManifest.xml文件的保护

从对抗动态分析入手

反调试
反hook

从对抗重打包入手

Apk签名校验
安装包文件完整性校验

加固具体思路

dex和elf文件是加固的重心

• 为了避免dex文件被直接还原成java文件被读出核心逻辑，一般会把dex写到so文件里面。
• 而elf文件本身是so文件，一般会通过混淆加反调试等操作

几代加固方案对比

针对dex/elf的加固发展出不同的方案，一般分为5代或者四代。但是说实话这种分代的说法也是一种个人说法，不算是一种标准。

我也是从看雪拉到了一份几代壳的总结说法:

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

阶段	名称	开发过程	核心逻辑	不足	优势	破解状况	实例
一代	动态加载	程序切分成加载(Loader)与关键逻辑(Payload)两部分,并分别打包	运行时加载部分(Loader)会先运行,释放出关键逻辑(Payload),然后用java的动态加载技术进行加载,并转交控制权	1. Payload部分必须解压及释放到文件系统(直接获取) 2. 通过自定义虚拟机,截取关键函数,在加载Payload时把解密后的内容复制	加密Payload保存	目前基本上已经被破解,部分反编译工具已经集成修复功能	早期版本爱加密
二代	内存不落地加载	加载Loader,初始化StubApplication,解密和加载Payload,初始化原始Application,用原始Application代替StubApplication,最后正常加载其他组件.	1. 拦截系统IO相关函数(read,write),在这些函数中提供透明加解密. 2. 直接调用虚拟机提供的函数进行落地加载	1. 在启动过程中需要处理大量的解密操作,容易造成黑屏或假死 2.Payload被加载后,在内存中是连续的,内存dump即可直接获取.(针对关键函数进行拦截即可把内存dump)	当前市面上最为常见,通常作为一项基础性的免费服务向用户提供.	已经出现专业人士自行研究的手工脱壳方法,但尚未出现自动脱壳工具,破解难度依然比较大	市场上流行的大多数在线加固服务,如腾讯加固,360加固,百度加固,阿里聚安全,网易易盾等等
三代	指令抽取	首先,将保护级别降到函数级别,然后将原始DEX内的函数内容(Code Item)清除.单独移除到一个文件中,运行阶段将函数内容重新恢复到对应的函数体.	1. 加载之后恢复函数内容到DEX壳所在的内存区域 2. 加载之后将函数内容恢复到虚拟机内部的结构体上,虚拟机读取DEX文件后内部对每一个函数有一个结构体,这个结构体有一个指针指向函数内容(CodeItem).可以通过修改这个指针修改对应的函数内容3. 拦截虚拟机内与查找执行代码相关的函数,返回函数内容	1. 指令抽取方案跟虚拟机的JIT性能优化冲突,达不到性能最佳的性能 2. 依然使用Java虚拟机进行函数内容执行,无法对抗自定义虚拟机. 3. 指令抽离技术使用了大量的虚拟内部结构与未文档化的特性,再加上Android复杂的厂商定制,带来大量的兼容问题.	在对自定义虚拟机记录函数执行时函数的内容,遍历触发所有的函数,从而获取全部抽离的内容,最终组装成完整的dex文件.科通过自动化完成整个过程.	部分被破解,已经出现专业人士自行研究手工破解方法,但是至今为止未出现自动脱壳工具	1. 现在免费版的 "爱加密"2 .棒棒安全免费版
四代	指令转换	A. DEX文件内的函数被标记为native,内容被抽离并转换成一个符合JNI要求的动态库,动态库通过JNI和Android系统进行调用.B. DEX文件内的函数被标记为native,内容被抽离并转换成自定义的指令格式,该格式使用自定义接收器执行,和A一样需要使用JNI和Android系统进行交互.		1. 不论使用指令转换/VMP加固的A方案或B方案,其必须通过虚拟机提供的JNI接口与虚拟机进行交互.攻击者可以直接将指令转换/VMP加固当作黑盒,通过自定义的JNI接口对象,对黑盒内部进行探测.记录和分析,进而得到完整DEX程序 2.第四代VMP加固一般配合第三代加固技术使用,所以第三代的所有兼容问题,指令转换/VMP加固也存在		部分被破解,已经出现专业人士自行研究手工破解方法,但是至今为止未出现自动脱壳工具	大部分需要定制收费的加密服务(如爱加密,邦邦安全,中国移动加固,以及手机银行自研加固等).
五代	虚拟机保护(VMP)	基于第四代方案的A方式(Java或Kotin -> C/C++),基于LLVM编译工具链(同时支持C/C++,Swift,Object-C),通过对IR执行指令转换,生成自定义指令集(IR-VM).APP内部抽离出独立的执行环境,该核心代码运行程序在此独立的执行环境里.		1. 无法摆脱对JNI的依赖,因此依然存在第四代加固技术的缺陷,存在被记录修复的可能性. 2.由Java转换成等价的C/C++,会导致体积展线性增大,性能有所下降.	1. 由Java转C/C++后的代码,由于虚拟机的保护,逆向难度会上升一个数量级. 2.对于C/C++部分逻辑,智能投入时间去破译虚拟机的指令集含义.	大多数未被破解	极为少数,需要特殊定制的加固服务,通常用于银行金融机构等关乎国家安全的重点领域.

加固选择和是否真的需要加固

原生加固还是第三方

加固可以原生加固 自己对dex/elf文件进行代码抽取
但是

我真的需要加固吗

或许你认为加固是提高安全性的不二法则，但实际上加固的负面作用包括但是不仅限于

1.兼容性出现问题，虽然有商业化的第三方平台。但是依然无法保证能在所有机型上运行正常。
2.安装运行速度变慢，相比正常的应用。加密后的apk必须经过解密才能保证运行。同时加入各种混淆流程等逻辑，使得流程漫长，速度减慢。
3.不可避免的加大安装包大小，加固要插入各种代码到apk里面。这会影响用户体验。
4.最后说一点就是要额外的费用去采用第三方加固平台方案，或许你根本不能接收这个费用。

那我到底需不需要一个加固方式来保证自己的apk安全性呢:

1.如果不是工具类应用，更多的安全性研究应该在服务端。也就是要把重心放在服务器的安全性上面。加固被破解其实也就是时间和成本二点问题。
2.稍微大一些的厂商应用其实不会使用加固这种方式来保护他们的apk安全性，包括BAT那些。他们的重点会放在so层的参数校验，也就是和服务器交互的逻辑。而不是侧重在dex层的保护。
3.如果你是小厂而且是工具类，没有实力去做一个服务器安全性的提高，加固加壳才算是个上策。