3969人阅读
Android开发主线（101）
I/PackageManager(
934): Running dexopt on: /system/app/Development/Development.apk pkg=com.android.development isa=x86 vmSafeMode=false with dexOptFlag=O2
I/dex2oat (10384): /system/bin/dex2oat --zip-fd=6 --zip-location=/system/app/Development/Development.apk --oat-fd=7 --oat-location=/data/dalvik-cache/x86/system@app@Development@Development.apk@classes.dex --instruction-set=x86 --instruction-set-features=sse4_2,aes_in,popcnt,movbe --runtime-arg -Xms64m --runtime-arg -Xmx512m --compiler-filter=interpret-only --swap-fd=21
E/dex2oat (10384): Failed to open dex from file descriptor for zip file '/system/app/Development/Development.apk': Entry not found
E/installd(
647): DexInv: --- END '/system/app/Development/Development.apk' --- status=0x0100, process failed
I/PackageManager(
934): Running dexopt on: /system/app/Development/Development.apk pkg=com.android.development isa=x86 vmSafeMode=false with dexOptFlag=O2
( 1670): Surface destroy: ANDROID_NATIVE_WINDOW_MAGIC
W/Settings( 1549): Setting airplane_mode_on has moved from android.provider.Settings.System to android.provider.Settings.Global, returning read-only value.
W/Settings( 1549): Setting airplane_mode_on has moved from android.provider.Settings.System to android.provider.Settings.Global, returning read-only value.
E/installd(
647): DexInv: --- END '/system/app/DevI/dex2oat (10386): /system/bin/dex2oat --zip-fd=6 --zip-location=/system/app/Development/Development.apk --oat-fd=7 --oat-location=/data/dalvik-cache/x86/system@app@Development@Development.apk@classes.dex --instruction-set=x86 --instruction-set-features=sse4_2,aes_in,popcnt,movbe --runtime-arg -Xms64m --runtime-arg -Xmx512m --compiler-filter=interpret-only --swap-fd=22
E/dex2oat (10386): Failed to open dex from file descriptor for zip file '/system/app/Development/Development.apk': Entry not foundelopment/Development.apk' --- status=0x0100, process failed
W/ResourcesManager(10368): Asset path '/system/framework/android.test.runner.jar' does not exist or contains no resources.
D/AndroidRuntime(10368): Shutting down VM
E/AndroidRuntime(10368): FATAL EXCEPTION: main
E/AndroidRuntime(10368): Process: com.android.development, PID: 10368
E/AndroidRuntime(10368): java.lang.RuntimeException: Unable to instantiate activity ComponentInfo{com.android.development/com.android.development.Development}: java.lang.ClassNotFoundException: Didn't find class &com.android.development.Development& on path: DexPathList[[zip file &/system/framework/android.test.runner.jar&, zip file &/system/app/Development/Development.apk&],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
E/AndroidRuntime(10368):
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2236)
E/AndroidRuntime(10368):
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2387)
E/AndroidRuntime(10368):
at android.app.ActivityThread.access$800(ActivityThread.java:151)
E/AndroidRuntime(10368):
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1303)
E/AndroidRuntime(10368):
at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(10368):
at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(10368):
at android.app.ActivityThread.main(ActivityThread.java:5258)
E/AndroidRuntime(10368):
at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(10368):
at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(10368):
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
E/AndroidRuntime(10368):
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
E/AndroidRuntime(10368): Caused by: java.lang.ClassNotFoundException: Didn't find class &com.android.development.Development& on path: DexPathList[[zip file &/system/framework/android.test.runner.jar&, zip file &/system/app/Development/Development.apk&],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
E/AndroidRuntime(10368):
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
E/AndroidRuntime(10368):
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
E/AndroidRuntime(10368):
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
E/AndroidRuntime(10368):
at android.app.Instrumentation.newActivity(Instrumentation.java:1066)
E/AndroidRuntime(10368):
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2226)
E/AndroidRuntime(10368):
... 10 more
E/AndroidRuntime(10368):
Suppressed: java.io.IOException: Zip archive '/system/app/Development/Development.apk' doesn't contain classes.dex (error msg: Entry not found)
E/AndroidRuntime(10368):
at dalvik.system.DexFile.openDexFileNative(Native Method)
E/AndroidRuntime(10368):
at dalvik.system.DexFile.openDexFile(DexFile.java:295)
E/AndroidRuntime(10368):
at dalvik.system.DexFile.&init&(DexFile.java:80)
E/AndroidRuntime(10368):
at dalvik.system.DexFile.&init&(DexFile.java:59)
E/AndroidRuntime(10368):
at dalvik.system.DexPathList.loadDexFile(DexPathList.java:262)
E/AndroidRuntime(10368):
at dalvik.system.DexPathList.makeDexElements(DexPathList.java:231)
E/AndroidRuntime(10368):
at dalvik.system.DexPathList.&init&(DexPathList.java:109)
E/AndroidRuntime(10368):
at dalvik.system.BaseDexClassLoader.&init&(BaseDexClassLoader.java:48)
E/AndroidRuntime(10368):
at dalvik.system.PathClassLoader.&init&(PathClassLoader.java:65)
E/AndroidRuntime(10368):
at android.app.ApplicationLoaders.getClassLoader(ApplicationLoaders.java:57)
E/AndroidRuntime(10368):
at android.app.LoadedApk.getClassLoader(LoadedApk.java:361)
E/AndroidRuntime(10368):
at android.app.LoadedApk.makeApplication(LoadedApk.java:553)
E/AndroidRuntime(10368):
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4530)
E/AndroidRuntime(10368):
at android.app.ActivityThread.access$1500(ActivityThread.java:151)
E/AndroidRuntime(10368):
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1364)
E/AndroidRuntime(10368):
... 7 more
E/AndroidRuntime(10368):
Caused by: java.io.IOException: Failed to open oat file from dex location '/system/app/Development/Development.apk'
E/AndroidRuntime(10368):
... 22 more
E/AndroidRuntime(10368):
Caused by: java.io.IOException: Failed to open oat file from /system/app/Development/x86/Development.odex (error Failed to open oat filename for reading: No such file or directory) (no dalvik_cache availible) and relocation failed.
E/AndroidRuntime(10368):
... 22 more
E/AndroidRuntime(10368):
Caused by: java.io.IOException:
E/AndroidRuntime(10368):
... 22 more
E/AndroidRuntime(10368):
Suppressed: java.lang.ClassNotFoundException: com.android.development.Development
E/AndroidRuntime(10368):
at java.lang.Class.classForName(Native Method)
E/AndroidRuntime(10368):
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
E/AndroidRuntime(10368):
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
E/AndroidRuntime(10368):
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
E/AndroidRuntime(10368):
... 13 more
E/AndroidRuntime(10368):
Caused by: java.lang.NoClassDefFoundError: Class not found using t no stack available
details and solution will be added the day after tomorrow. :)
do not create dex file . &Android.mk
+LOCAL_DEX_PREOPT := false
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：211763次
积分：3894
积分：3894
排名：第7874名
原创：123篇
转载：31篇
评论：52条标签：至少1个，最多5个
本文来自于，非经作者同意，请勿转载，原文地址：
Android 不仅系统版本众多，机型众多，而且各个市场都各有各的政策和审核速度，每次发布一个版本对于开发同学来讲都是一种漫长的煎熬。相比于 iOS 两三天就能达到 80% 的覆盖速度而言，Android 应用版本升级至少需要两周才能达到 80% 的升级率，严重阻碍了版本迭代速度。也导致市场上 App 版本分散，处理 bug 和投诉等也越来越麻烦。
修复的 bug 需要等待下个版本发布窗口才能发布？
已经 ready 的需求排队上线，需要等待其他 Feature Team 合入代码？
老版本升级速度慢？频繁上线版本提醒用户升级，影响用户体验？
这几个问题是每个 App 开发同学都必然要面对的。那么有没有方法能在用户无感知的情况下加速 bug 处理和版本迭代速度？
在这方面 PC 端 Chrome 浏览器的 patch 升级方案给我们了一个很好的借鉴：当 Chrome 有版本升级的时候会自动下载 patch 文件。下次启动后，Chrome 就已经是新版本。
他山之石，可以攻玉
近一两年 Android 热补丁框架非常热门。从最初 360 动态下发 lua 脚本，到后来出现的各种方案，如雨后春笋般出现。早期的补丁框架偏向于以代码修复为主，主要分为两大类：native hook 方案和 Multidex 方案。
native hook 方案如阿里巴巴的 AndFix 和 Dexposed。Multidex 方案如 Qzone。切入点都是替换掉将要执行的代码。基于 Qzone 方案的思路，出现了 nuwa 这个比较完善的库，工具链比较完善。
类似 Chrome 的 patch 升级方案足以满足加速 bug 处理和版本迭代速度的需求，给了我们很大的借鉴意义。在安卓系统上，可以通过 hotfix 的思路来达到这一目的：下发补丁文件，更新 App 版本。
站在巨人的肩膀上
在今年 3 月份开始做技术选型的时候把上面的几种方案试了一轮。其中 AndFix 甚至跟上了现网的一个发布版本，但是由于影响正向开发过程（只能修改方法、不能修改 field、不能新增类等问题）、库本身难于维护（需要依赖外部开源力量进行维护）以及发现的莫名其妙的 bug（导致我们 App 下发 patch 后白屏），所以即使跟上了发布版本也没有使用。nuwa 仅支持更新 Java 代码，不能更新资源和 so 文件，满足不了我们的需求。
没有好用的轮子，我们决定自己造一个，于是有了现在的 patch 方案。
App 只是一个加载器
既然做安卓 patch 方案，最好的结果就是能支持更新 App 所有的代码和资源。但是
Application 类是 App 启动之初就被安卓系统加载起来，所以至少 Application 类和它启动依赖的其他业务类是不能被更新的？
修复 bug 或者版本迭代过程中难免会遇到需要修改资源文件的情况。资源文件能更新吗？
native 实现的 so 文件如何更新？
针对上面三个问题， 我们的设计是把 App 仅仅当做一个加载器。系统启动 App 之后，加载器决定将要运行的代码和资源的位置。当有新功能或者 bugfix 需要推送给用户，替换加载器内容即可。
支持更新全部代码
上面提到 Application 由于启动就被加载而不能被更新的问题，我们代理了真实 Application 类的创建过程。通过代理 Application，控制 Application 从新 dex 文件中加载。假设真实的 Application 类是 MyApplication。我们在编译期间自动修改 AndroidManifest.xml 文件，把 MyApplication 替换为 MoaiApplication（是 App 的入口 Application）。App 启动后由 MoaiApplication 加载完相应的文件（dex/资源文件/so 文件）后，再将控制权交回给 MyApplication。
代理生命周期
将控制权交回给 MyApplication，我们最初是代理 MyApplication 的生命周期。具体做法是，MoaiApplication 决定加载哪里的业务代码、资源文件以及 so 文件之后依然负责接收 App 的全部生命周期，然后把生命周期代理给 MyApplication，简单例子如下：
还有比较多生命周期函数上面代码就没一一列举。
从上面代码容易想到代理方案的缺点：必须要完整代理所有生命周期接口。否则 MyApplication 会由于生命周期不完整而出现奇怪的 bug。比如我们最初版本在测试过程中就出现了没有代理 registerActivityLifecycleCallbacks 函数而导致拿不到 Activity 生命周期 onActivityCreated/onActivityDestroyed 等回调。
反射 Application
踩到生命周期回调不完整的坑之后，我们开始考虑能不能把 App 运行期间 Application 的引用全部替换成 MyApplication ？这样就无需 MoaiApplication 把生命周期代理给 MyApplication，而是由 MyApplication 直接接收系统回调。安卓系统 ContextWrapper 的实现是包装了一层真正的 mBase 上下文，App 真正使用到的就是这个 mBase。通过反射 mBase 以及其中字段对 Application 的引用，『彻底』解决了需要手写代理 Application 全部生命周期的方法。
Qzone 方案下发的 patch 文件是变更过的 Java 类组成的 patch.dex，在 dalvik 和 ART 虚拟机下分别需要解决 Class ref in pre-verified class resolved to unexpected implementation 和内存地址错乱问题。这些问题根源在于改变了类原本所属的 dex 文件。既然改变类所在的 dex 会导致各种各样的问题，那直接替换掉整个 dex 不就好了？在调研 JRebal for Android 和 Instant Run 的时候也发现了他们有类似的做法。
我们把 App 的 dex 分成两部分：
patch 库的 dex 文件 -& classes.dex
其他业务代码的 dex 文件 -& classes[N].dex
其中 classes.dex 中仅包含了 patch 库的全部代码，并不包含任何其他业务代码。
假设 apk 中包含三个文件：classes.dex、classes2.dex、classes3.dex。classes.dex 充当的角色就是加载器，负责启动 App 并且加载后面的两个 dex。这样做的目的是，App 启动需要用到的所有类都集中在 classes.dex 中，所有业务代码的类都集中在 classes[N].dex 中。如果某次下发 patch 代码把 classes2.dex 变更为 classes2-1.dex，那么由加载器加载 classes2-1.dex 和 classes3.dex 即可实现更新包含 MyApplication 类在内的所有代码。
怎么加载更新后的代码？
如果 dex 文件有更新，加载器会选择加载更新后的文件。我们最初采用了 Google 官方的 Multidex 方案，扩展 DexPathList 的 dexElements 字段。
Multidex 方案存在问题
Multidex 方案上线后发现某些机型（比如三星s6 5.0.2 ROM）并不能加载扩展进去的 dex 中的代码。debug 阶段却能顺利加载（debugger 拖慢代码执行速度）。目前的猜测是某些厂商在 5.x 以上版本改动 ROM 导致 App 启动逻辑有多线程并发执行。
最终我们弃用了 Multidex 方案，转而 Hack 系统 ClassLoader。
ClassLoader Hack 方案
所有线程使用的是同一个 ClassLoader 对象。所以一旦 Hack 了这个对象，所有线程都开始使用 Hack 过的对象，从而能够解决多线程导致加载不到扩展的 dex 文件中代码的问题。
安卓系统加载代码的 ClassLoader 是 PathClassLoader 和 BootClassLoader。我们最初设计的方案是在 PathClassLoader 和 BootClassLoader 之间插入一个 BaseDexClassLoader，让所有业务代码都在这个插入的 BaseDexClassLoader 中加载。但是这样的设计存在缺陷：业务代码的 ClassLoader 会变成 BaseDexClassLoader，如果业务代码依赖了 patch 库的代码（在 classes.dex 中），会出现 ClassNotFoundException。
在这方面 Instant Run 的设计很精巧。它让 PathClassLoader 插入的父 loader （IncrementalClassLoader）包装了 DelegateClassLoader，并且把 DelegateClassLoader 的父 loader 设置为 PathClassLoader，使得类加载的路径变成：
在 DelegateClassLoader 加载业务代码的时候（业务代码在 classesN.dex 中），流程会沿着标记的顺序最终第 5 步成功加载到业务代码。业务代码如果依赖 patch 库的代码，会在 PathClassLoader 加载。这样所有代码都可以被加载到。
怎么更新资源？
单纯更新 Java 代码的 patch 框架，实用性会受到很大的局限。开发同学需要仔细验证提交内容，确保提交中不包含资源文件的变更以及 native so 的改动，会导致本就复杂的开发流程变得更加繁琐。所以我们在支持更新 Java 代码的基础之上，也支持更新资源和 native so 文件。
App 加载资源是依赖 Context#getResources 函数返回的 Resources 对象。Resources 内部包装了 AssetManager，最终由 AssetManager 从 apk 文件中加载资源。所以我们反射了替换系统默认的 Resources，让 AssetManager 从我们更新后的 apk 中加载资源。现阶段的实现支持比如 string/anim/drawable/color/layout 等资源文件的变更。由于 Android 系统在安装 apk 时候已经把 AndroidManifest.xml 文件解析并写入到系统中，目前还不支持修改四大组件，比如增加 Activity。后续会继续研究如何做到无缝修改四大组件。
怎么更新 so 文件？
在 Android 项目中使用 native 函数前需要先调用 System.loadLibrary(libName)。
当 lib 文件需要更新或者有 bug 时候怎么办？首先想到的是在代码中把加载 so 文件的代码改成System.load(libFilePath)，让系统加载自己指定的 libFilePath 文件。然而这样的改动需要
在源代码中修改或者使用工具在编译期把 loadLibrary 接口改为 load
patch 库把 so 文件从 patch 文件中复制到特定目录
这样在运行期才有可能加载更新后的 so 文件。
通过分析系统加载 so 文件的方式后，我们使用了更简单的处理方法。查找 lib 文件是通过调用 PathClassLoader 的 findLibrary，最终调用到 DexPathList 的 findLibrary。DexPathList 会在自己维护的列表目录中查找对应的 lib 文件是否存在。所以我们在发现 patch 文件中有 so 文件变更的时候，会在 PathClassLoader 的 nativeLibraryDirectories（Android6.0以下）或者nativeLibraryPathElements （Android 6.0及以上）的最前面插入自定义的lib文件目录。这样 ClassLoader 在 findLibrary 的时候会先在自定义的 lib 目录中查找，优先加载变更过的 so 文件。
patch 包的生成与应用
回到我们最初的目标：patch 不应该影响正向开发流程。我们生成 patch 文件是针对 apk 进行的，开发同学无需关心此次发布是 patch 版本还是正常版本，只需要正常开发并且打包要发布的 apk 即可，不会对正向开发流程产生任何影响。
我们提供 python 脚本生成两个 apk 的：对比两个 apk 中的所有文件，找出有变更的文件进行 diff，把 diff 结果写入 patch 文件。线上用户下载 patch 文件到本地之后，启动一条新的进程使用 context.getApplicationInfo().sourceDir 路径的 apk 与 patch 文件合并，得到新的 apk（包含资源文件，不包含 dex 文件）以及 dex 文件、native so 文件，并在这条进程中提前做 dex 优化（dex2oat/dexopt）。针对 dex 优化过程太慢的问题（优化过程慢会导致进程可能会系统kill，降低 patch 成功率）我们并发了 dex 优化过程，使 patch 过程耗时相对减小。新 apk、dex文件、so 文件就可以在下次启动 App 的时候由加载器加载。
优势和不足
正所谓没有完美的架构，只有适合自己的架构。当前的开源方案并不能满足我们加速 bug处理和版本迭代速度的需求，于是有了站在巨人肩膀上的思考和我们现在的 patch 方案。我们目前的优势：
全面支持 patch Java 代码、资源文件 和 native so 文件。版本只需要正常滚动，开发同学无需关心是发布 patch 版本还是正常版本
使用相对简单（减少接入成本也是我们的最初思考点之一），只需要在 build.gradle 中加入三行代码即可，无需更多配置。
从我们团队发布的多个 patch 版本来看，下发的 diff 结果文件稍大。大文件下载过程可能出现的错误也会间接影响到 patch 铺开的速度，所以我们也在尝试更好的 diff 方案。Chrome 最初升级方案也是 bsdiff，而后慢慢演变出 Courgette 算法。
演进与思考
我们对于补丁框架的定义不仅仅是『修复bug』就足够，除此之外，如何快速接入，如何做到不影响现有流程，这对于很多应用来说至关重要。在此之上，搞清楚框架的定位，适当舍弃一些不重要方面的时候，快速迭代，在迭代中持续优化，事情往往比想象的更加简单。
持续交付一直都是快速迭代思想的一种践行方式，对于 App 开发而言，如果我们通过构造补丁框架这样一个渠道，可以通过自动化系统把补丁快速地把新功能推送给用户，那这个事情的意义就不仅仅是『修复 bug』这么简单。减少线上 crash 率和加速版本迭代、让新功能尽早与用户见面，从而可以在更短的时间内不断收集用户反馈信息对产品进行打磨。
目前我们已经在微信读书线上三个版本开始试行了用补丁代替版本发布或者加速老版本升级的做法，期待将来能通过这个渠道，为安卓开发同学们做到无感知的持续交付过程 。
更多精彩内容欢迎关注的微信公众账号：
是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条
根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！
0 收藏&&|&&2
你可能感兴趣的文章
6 收藏，868
3 收藏，453
本作品采用 署名-非商业性使用-禁止演绎 4.0 国际许可协议 进行许可
分享到微博？
技术专栏，帮你记录编程中的点滴，提升你对技术的理解收藏感兴趣的文章，丰富自己的知识库
明天提醒我
我要该，理由是：
扫扫下载 App当前位置：&>&&>&
dex2oat脱壳 常见app加固厂商脱壳方法研究
发布时间：
来源：服务器之家
目录 简述(脱壳前学习的知识、壳的历史、脱壳方法) 第一代壳 第二代壳 第三代壳 第N代壳简述 Apk文件结构 Dex文件结构 壳史 壳的识别Apk文件结构
Dex文件结构
壳史第一代壳 Dex加密 Dex字符串加密 资源加密 对抗反编译 反调试 自定义DexClassLoader第二代壳 Dex抽取与So加固 对抗第一代壳常见的脱壳法 Dex Method代码抽取到外部(通常企业版) Dex动态加载 So加密第三代壳 Dex动态解密与So混淆 Dex Method代码动态解密 So代码膨胀混淆 对抗之前出现的所有脱壳法第四代壳 arm vmp(未来) vmp壳的识别1.用加固厂商特征： 娜迦： libchaosvmp.so , libddog.solibfdog.so 爱加密：libexec.so, libexecmain.so 梆梆： libsecexe.so, libsecmain.so , libDexHelper.so 360：libprotectClass.so, libjiagu.so 通付盾：libegis.so 网秦：libnqshield.so 百度：libbaiduprotect.so2.基于特征的识别代码
第一代壳 内存Dump法 文件监视法 Hook法 定制系统 动态调试法内存Dump法 内存中寻找dex.035或者dex.036 /proc/xxx/maps中查找后，手动Dump
定制系统 修改安卓源码并刷机
动态调试法 IDA Pro
gdb gcore法
.gdbserver :1234 Cattachpid .gdb (gdb) targetremote :1234 (gdb) gcore
coredump文件中搜索“dex.035”
第二代壳 内存重组法 Hook法 动态调试 定制系统 静态脱壳机内存重组法Dex篇
对付一切内存中完整的dex，包括壳与动态加载的jar
elfrebuild
构造soinfo，然后对其进行重建
针对无代码抽取且Hook dvmDexFileOpenPartial失败
Hook dexFileParse
针对无代码抽取且Hook dexFileParse失败
Hook memcmp
修改安卓源码并刷机-针对无抽取代码
Hook dexfileParse
DexHunter-最强大的二代壳脱壳工具
DexHunter的工作流程：
DexHunter的工作原理：
绕过三进程反调试
修改系统源码后：
ls /proc/345/task
./gdbserver :1234 --attach346 ... (gdb) gcore
gcore防Dump解决方案：
断点mmap调试，针对Hook dexFileParse无效
原理： dexopt优化时， dvmContinueOptimization()-&mmap()
静态脱壳机
分析壳so逻辑并还原加密算法
自定义linker脱so壳
main() -& dump_file()
第三代壳 dex2oat法 定制系统dex2oat法
ART模式下，dex2oat生成oat时，内存中的DEX是完整的
Hook Dalvik_dalvik_system_DexFile_defineClassNative
枚举所有DexClassDef，对所有的class，调用dvmDefineClass进行强制加载
第N代壳 so + vmp 动态调试 + 人肉还原
Copyright © . 版权所有}