根据国家互联网金融风险分析技术平台监测数据显示：截至 2020 年 5 月底，共发现 2801 个互联网金融仿冒 App ，仿冒 App 下载量高达 3343.7 万次。
互联网环境下，盗用和剽窃能有多简单？
先看一波新闻标题感受下：
根据国家互联网金融风险分析技术平台监测数据显示：截至 2020 年 5 月底，共发现 2801 个互联网金融仿冒 App ，仿冒 App 下载量高达 3343.7 万次。
伴随着移动应用数量的井喷式增长，对于一个 App 来说，被山寨和盗版无疑成为了每一个应用开发者最头疼与烦恼的问题之一。
移动端黑产日益壮大，伴随而来的逆向攻击手段也越来越高明，基于 java 开发的 Android 应用因其语言的特性和系统的开源属性，大量 Android 应用程序面临着应用程序遭逆袭破解、知识产权被侵犯、被二次打包签名等安全问题。
为解决上述问题，在 APK 上传至应用市场之前，需要先对 APK 进行加固并对加固后的 APK 进行兼容性测试，可最大限度保障应用不被破解。
第一代加固技术采用的是Dex加密存储，解密时落地；落地之后通过自定义的DexClassLoader将解密出的Dex加载到内存中，然后程序运行该文件（Dex是APK的Java代码经过编译后生成的文件，可以简单理解为Java的逻辑）。
其脱壳方式很简单：因为Dex加密是整体进行的，解密时还会落地。可以通过HOOK文件操作（Read、Write、Delete）将Dex文件脱壳出来，通过反编译工具分析，从而得到APP的核心逻辑。
之后对第一代版本进行了升级，与未升级版相比：Dex加密存储方式相同，但解密时不落地；解密之后在内存中通过自定义DexClassLoader进行加载。升级版本的脱壳方法也比较简单，主要采用内存Dump方法，将文件写到磁盘中，通过HOOK dvmDexFilePartial的方式达到脱壳目的。
第二代加固方式采用的是Dex Method方法抽离，Dex在内存中加载时不连续。其原理是：Method方法通过一些加固方法抽离，APK在运行时，整个Dex会一并修复，然后在内存中运行，也就说在内存中有着完整的Dex代码。第三代方式与第二代相比同样是采用Dex Method方法抽离，但Dex执行中动态解密。两者的差异在于：后者在APK运行时，Dex文件是不进行修复的，而是等到Class被执行时才进行解密。
对第二代和第三代进行脱壳前，需要先了解Dex结构。Dex结构从dex_header开始，在头部存在Dex的标志位；然后逐步按结构指向Method结构体，Method结构中的code_off字段最终指向可执行代码。因此在第二代和第三代的脱壳过程中，需要HOOK DVM虚拟机中很底层的函数，从而拿到需要执行的APK的类，进而得知Class object全部方法；然后在内存中对DEX进行重建，重建之后再将其Dump到本地，得到脱壳之后的Dex文件，便于后续采用工具分析。
除了上述的脱壳方式之外，通用的脱壳机（开源的Zjdroid、DexHunter）也可以轻松脱掉大部分壳；并且，由于传统的加固方式容易被脱壳，导致目前脱壳类教程非常之多。因此，传统的加固方式面临着很大的挑战。
针对层出不穷的脱壳方式。阿里内部经过多次讨论后，认为传统的加固方式已过时，需要转变思路：混淆。
ProGuard混淆
在APP发布前，通常会对应用进行ProGuard混淆，类似上图的配置。图中的proguard-android.txt/proguard-rules.pro是ProGuard的混淆规则。在Java中，某些特性如反射调用以及可序列化类等是需要保留的，因此需要人工配置一些复杂的规则。当规则全部配置成功后，对APK进行反编译，从上图可以看到某些逻辑被混淆成了a、b、c等，进而大大增加了黑客逆向分析的难度。
通过混淆可以增加逆向分析的难度，但并不代表着不能分析。上图是对金山隐私保险箱逆向分析的案例，通过反编译工具分析，得知金山隐私保险箱对其核心代码进行了混淆，例如它的类名是a、b、c等形式。由于ProGuard混淆时需要配置很多规则，很多开发人员为了保障兼容性会保持很多类，导致APK内的逻辑并不全部混淆，进而导致安全性的降低，通常ProGuard混淆率在10%-30%。
为了解决ProGuard混淆需要配置很多规则导致混淆效率低下的问题，阿里内部研发了全量混淆技术。上图左侧是手淘在未混淆之前的反编译情况，其中的类、函数名都是一目了然的；经过全量混淆之后的效果图如右侧所示：类名全部变成了a、b、c的类型，并且全量混淆几乎是不用任何配置的，大大降低了使用成本。目前，全量混淆已在线上对外发布。
随着APK功能的增加，其体积也在不断地增大，例如手淘、支付宝等应用达到五十几兆、游戏类的APK达到几百甚至上千兆，进而引发了手机资源存储、用户下载流量浪费等问题。因此APK优化瘦身势在必行。
APK优化瘦身的实现逻辑主要包括：首先，清除Dex文件Debug信息，减少编译器自动产生函数，优化性能，减少体积；其次，通过Java层拦截技术，对SO进行重新打包压缩，减少体积；同时，修改Android应用资源名称，通常资源名称是带有实际意义的，通过将带有实际意义的长文件名修改成上文所示的a、b、c等形式既减少应用体积，又提高了资源保护强度；此外，通过自行开发的7z工具，对签名后的APK包重新压缩，达到进一步减少体积的目的。
上图是阿里内部应用优化瘦身之后对比效果图，从图中可以看到手淘、支付宝、钉钉瘦身前后的对比，瘦身效果可以达到10%左右。
上图是市场上常见应用瘦身前后的对照表，微博、百度地图等应用优化后的减少百分比可达到百分之十几；华为账号等应用优化瘦身减少率甚至达到40+%。通常应用优化瘦身减少率在15%-20%，具体数值和APK的开发质量有关。
针对市面上移动应用普遍存在的破解、篡改、盗版、钓?欺诈、内存调试、数据窃取等各类安全风险，mPaaS 「移动安全加固」依赖于阿里云集团的移动安全加固技术，经历了淘系等亿级应用的安全性考验。
能够有效为移动应用提供稳定、简单、有效的安全保护，提高 App 的整体安全水平，力保应用不被逆向破解，在安全性上具有非常可靠的保障。
「移动安全加固」通过对 Android 应用重新编译、加壳保护、修改其指令调用顺序等手段来增强应用的反破解能力。在加固过程中，注重加固强度与兼容性并重，避免一般加固功能由于盲目追求加固强度而导致加固后应用完全不可用的问题。
① App 自身安全保护
② 深度安全检测
如有更多接入相关问题，欢迎使用钉钉扫码或搜索33417739入群交流
关注公众号「mPaaS」，回复“安全加固”，获取《APP加固新方向——混淆和瘦身》完整讲义
原文：https://www.cnblogs.com/mpaas/p/13815008.html