APK/SO 加壳加固与脱壳（防反编译、二次打包）

  Android安全方面的博客- http://blog.csdn.net/lpjishu
  对App进行加固，可以有效防止移动应用被破解、盗版、二次打包、注入、反编译等，保障程序的安全性、稳定性。
  目前关于Android APK的安全性是非常令人堪忧的。APK运行环境依赖的文件/文件夹 res、DEX、主配文件Lib 只是简单的加密甚至没有任何加密措施。APKtool工具可轻易将其破解，再配合其他各种工具基本可以做到：源码暴露(代码混淆也几乎起不到任何安全作用)、资源文件裸奔、主配文件可任意修改、核心SO库暴露、暴力破解恶意利用等。部分大公司会对其应用APK包进行防二次打包和防APKtool破解，但其代码都是写在JAVA层，另外APKtool的可升级导致其安全保护级别也是非常低的。

--混淆和加固：应用加固包括病毒扫描模块，防逆向，防注入，防调试，防篡改模块模块。google官方提供了proguard来进行代码混淆。
 把签名v1和签名v2都勾上,区别是v1是7.0之前就存在的签名方式,v1相比v2安全系数要低,建议打包的时候v1和v2都勾上,只勾其中一个有可能会出现兼容问题。

Android 7.0 引入一项新的应用签名方案 APK Signature Scheme v2- https://github.com/bihe0832/Android-GetAPKInfo/tree/master/CheckAndroidV2Signature
获取应用基本信息的系列工具集（包名（packageName）、版本(versionName\versionCode)、应用签名(Signature)等）- https://github.com/bihe0832/Android-GetAPKInfo

android自定义linker实现安全加固- https://github.com/liumengdeqq/CustomLinker
（1）.在android 7.0之后dlopen不返回soinfo结构体，通过读取maps 获取基地址读取系统so的结构体
（2）.在android5.1之后 出现read被pread64函数读取so的结构
（3）.在android4.1.2 5.0 7.0等page_size 也是内存大小有改变
（4）.在android4.4之后都是c++ 考虑安全问题 用c语言实现

> 常见app加固厂商
加固平台有：梆梆加固，爱加密，360加固，腾讯加固等。
常见app加固厂商脱壳方法研究- http://www.mottoin.com/89035.html

1.第一代壳， Dex加密
  Dex字符串加密;资源加密;对抗反编译;反调试;自定义DexClassLoader。
  脱壳android-unpacker- https://github.com/strazzere/android-unpacker ，升级版的android-unpacker，read和lseek64代替pread，匹配dex代替匹配odex；
  基于内存搜索的Android脱壳工具drizzleDumper- https://github.com/DrizzleRisk/drizzleDumper；
  DA Pro + dumpDEX dumpDex- https://github.com/CvvT/dumpDex；
  Dex优化生成odex,监视DexOpt输出 监视文件变化inotifywait-for-Android- https://github.com/mkttanabe/inotifywait-for-Android
  Hook法,Hook dvmDexFileOpenPartial-  http://androidxref.com/4.4_r1/xref/dalvik/vm/DvmDex.cpp ；
  只针对部分壳,基于Xposed的不那么通用的脱壳机DumpApk- https://github.com/CvvT/DumpApk

2.第二代壳， Dex抽取与So加固
对抗第一代壳常见的脱壳法;Dex Method代码抽取到外部（通常企业版）;Dex动态加载;So加密。
对付一切内存中完整的dex，包括壳与动态加载的jar,ZjDroid- http://bbs.pediy.com/showthread.php?t=190494；
针对无代码抽取且Hook dvmDexFileOpenPartial失败,Hook dexFileParse -http://androidxref.com/4.4_r1/xref/dalvik/vm/DvmDex.cpp ，https://github.com/WooyunDota/DumpDex ；
  针对无代码抽取且Hook dexFileParse失败,Hook memcmp-http://androidxref.com/4.4_r1/xref/dalvik/vm/DvmDex.cpp ；
  修改安卓源码并刷机－针对无抽取代码- https://github.com/bunnyblue/DexExtractor ；
  DexHunter-最强大的二代壳脱壳工具- https://github.com/zyq8709/DexHunter；
  绕过三进程反调试- http://bbs.pediy.com/showthread.php?p=1439627；
  gcore防Dump解决方案：http://bbs.pediy.com/showthread.php?t=198995；
  分析壳so逻辑并还原加密算法- http://www.cnblogs.com/2014asm/p/4924342.html；
  自定义linker脱so壳- https://github.com/devilogic/udog；

3.第三代壳， Dex动态解密与So混淆
 Dex Method代码动态解密;So代码膨胀混淆;对抗之前出现的所有脱壳法;HOOK Dalvik的解释器的壳
 dex2oat法,ART模式下，dex2oat生成oat时，内存中的DEX是完整的- http://bbs.pediy.com/showthread.php?t=210532；
 Hook Dalvik_dalvik_system_DexFile_defineClassNative,枚举所有DexClassDef，对所有的class，调用dvmDefineClass进行强制加载

4.第四代壳 arm vmp（未来）
  vmp. so + vmp, 动态调试 ＋ 人肉还原。

> APK安全加壳加固，脱壳
Android沙盘——MalDroidAnalyzer; APK加壳加固。研究各家的安全加固方案，大多dex加密、反调试等技术。
脱壳模块工具ZjDroid的原理- https://github.com/halfkiss/ZjDroid
Dex文件结构-- http://blog.csdn.net/androidsecurity/article/details/8664778
更好的分析Dex的格式的例子- https://download.csdn.net/download/jiangwei0910410003/9102599
Android中的Apk的加固(加壳)原理解析和实现-- http://blog.csdn.net/jiangwei0910410003/article/details/48415225
Apk脱壳圣战之---如何脱掉“梆梆加固”的保护壳- http://blog.csdn.net/jiangwei0910410003/article/details/54409957
Android安全专项-Apk加固-- http://blog.csdn.net/itfootball/article/details/50962459/
Android APK加壳技术方案【1】-- http://blog.csdn.net/androidsecurity/article/details/8678399
Android APK加壳技术方案【2】-- http://blog.csdn.net/androidsecurity/article/details/8809542

基于Xposed的一款脱壳神器ZjDroid工具原理解析- http://blog.csdn.net/jiangwei0910410003/article/details/52840602
Android常见App加固厂商脱壳方法的整理- http://blog.csdn.net/qq1084283172/article/details/53572446 
Android常见App加固厂商脱壳方法的整理- http://www.zhimengzhe.com/Androidkaifa/172675.html
如何脱掉360加固的壳-http://www.wjdiankong.cn/apk%E8%84%B1%E5%A3%B3%E5%9C%A3%E6%88%98%E4%B9%8B-%E8%84%B1%E6%8E%89360%E5%8A%A0%E5%9B%BA%E7%9A%84%E5%A3%B3/

Android中的Apk的加固(加壳)原理解析和实现：http://blog.csdn.net/jiangwei0910410003/article/details/48415225/
加固(加壳)原理-http://www.tuicool.com/articles/v6FfUv?plg_nld=1&plg_uin=1&plg_auth=1&plg_nld=1&plg_usr=1&plg_vkey=1&plg_dev=1
  App加密保护是全方位的，目前提供的服务有：DEX加壳保护、DEX指令动态加载保护、高级混淆保护，SO库保护，主配置文件保护，资源文件保护，二次打包防护。

-- 对源Apk进行加密，然后在套上一层壳即可，当然这里还有一些细节需要处理.
 具体Dex文件格式的详细介绍可以查看这个文件：http://download.csdn.net/detail/jiangwei0910410003/9102599
  主要来看一下Dex文件的头部信息，其实Dex文件和Class文件的格式分析原理都是一样的.
  其实为了增加破解难度，我们应该使用更高效的加密算法，同时最好将加密操作放到native层去做.
逆向和加固是一个永不停息的战争。
 
-- 安卓应用在开发过程中有很多安全保护的方案,简单说几种：
 1.使用混淆保护,对APK代码进行基础的防护。
 2.使用伪加密保护方式，通过java代码对APK(压缩文件)进行伪加密，其修改原理是修改连续4位字节标记为”PK0102”的后第5位字节，奇数表示不加密偶数表示加密。伪加密后的APK不但可以防止PC端对它的解压和查看也同样能防止反编译工具编译。
 3.通过标志尾添加其他数据从而防止PC工具解压反编译，这样处理后把APK看做压缩文件的PC端来说这个文件被破坏了，所以你要对其进行解压或者查看都会提示文件已损坏，用反编译工具也会提示文件已损坏，但是它却不会影响在Android系统里面的正常运行和安装而且也能兼容到所有系统 
 4.验证签名信息,通过本地或网络对签名的信息进行验证。

> SO文件安全加壳加固，脱壳
  -- Android里面关于so的加载的两种方式：
 方式一：System.loadLibrary， 这种方式传入的是so的名字，会直接从系统的目录去加载so文件，系统的路径包括/data/data/${package_name}/lib、/system/lib、/vender/lib等这类路径。
 方式二：System.load， 这种方式传入的是so的绝对路径，直接从这个路径加载so文件。

so加固例子--加密函数- https://download.csdn.net/download/jiangwei0910410003/9289009
Android SO文件保护加固（一）-- http://blog.csdn.net/feibabeibei_beibei/article/details/51498285
Android逆向之旅---基于对so中的函数加密技术实现so加固- https://blog.csdn.net/jiangwei0910410003/article/details/49966719
Android逆向之旅---SO(ELF)文件格式详解- https://blog.csdn.net/jiangwei0910410003/article/details/49336613
Android逆向之旅---基于对so中的section加密技术实现so加固- https://blog.csdn.net/jiangwei0910410003/article/details/49962173