dex

本文博客地址： http://blog.csdn.net/qq1084283172/article/details/78494671 在前面的博客《 DexHunter的原理分析和使用说明（一） 》、《 DexHunter的原理分析和使用说明（二） 》中已经将DexHunter工具的原理和使用需要注意的地方已经学习了一下，前面的博客中只讨论了DexHunter脱壳工具在Dalvik虚拟机模式下的脱壳原理和使用，一直想分析和研究一下DexHunter脱壳工具在ART虚拟机模式下的脱壳原理，终于有时间进行知识的消化了，特此整理一下基于Android运行时的脱壳工具DexHunter的脱壳原理，又将DexHunter工具的代码再看了几遍，对DexHunter脱壳工具的脱壳原理又有啦更进一步的理解和认识，并且也将DexHunter脱壳工具在ART虚拟机模式下的脱壳原理理解清楚啦。在DexHunter脱壳工具公布之后，类似变型的脱壳工具 Xdex 也出来了-详细的信息可以参考看雪文章《 Xdex（百度版）脱壳工具基本原理 》，基于类方法抽取的Android加固同样可以通过修改DexHunter脱壳工具进行脱壳，只是需要自己选择Android Dex文件的类方法加载点和类方法实现数据的dump点，最后进行dex文件的重组和还原。 1. Dalvik虚拟机模式下

本文博客地址： http://blog.csdn.net/qq1084283172/article/details/77966109 这段时间好好的学习了一下Android加固相关的知识和流程也大致把Android加固的一些思路理清楚了，不巧在博客上看到了这篇文章《 某加固使用xposed脱壳 》感觉还不错，正好有时间可以学习一下这款基于Xposed Hook框架开发的某加固脱壳工具，原作者的博客已经找不到但是作者已经给出了主要的实现代码，我在作者给出的原代码基础上稍微做了一下修改和优化并且在Android Nexus 5手机上测试某加固的脱壳，成功得到了某加固解密后的dex文件。在进行源码 分析 之前，你需要了解Xposed Hook框架模块编写相关的知识，还不了解的可以先看下我前面的博客《 Xposed框架之函数Hook学习 》。Android加固的实现是基于DexClassLoader的加载流程来实现的，具体详细的流程后面有时间再整理一下，因此这里使用Xposed Hook框架来脱某加固壳的工具也是基于 DexClassLoader的加载流程来实现的。 下图是 DexClassLoader在整个java层的实现流程： 从 DexClassLoader到openDexFileNative函数的整个流程下来， DexClassLoader的java层实现全部完成，

Android dex解密与解密原理及其代码实现 为什么要进行apk加密？答案是避免apk被有心人反编译，窃取公司重要技术和算法等。但是要给Apk加密要如何实现呢？系统在加载类的时候都是从我们apk的dex文件中加载的。ClassLoader会去维护一个这样的dex文件数组。而我们要做的就是将原apk中的dex都加密，然后将解密部分的代码单独编程成dex文件（我们称这样的dex为壳dex）连带着加密的dex一起加到新apk中。这样新apk安装后系统就能够找到我们应用启动的入口Application了，不至于由于加密导致系统找不到应用程序入口。而在这个程序入口中我们要做的就是解密被加密的dex文件，然后重新插入到ClassLoader维护的dex文件数组中（这里就涉及到大量的反射知识）。 dex解密与解密分为以下几个步骤： 1）把源 apk（要加固的apk）中的 dex 文件加密。加密之后就不再是正常的 dex 文件，那么市面上的反编译工具就不能按照正常的dex去解析了。 2）将加密后的dex文件与壳程序Apk的dex文件合并成新的dex文件，然后替换壳程序中的源dex文件，生成新的apk文件。 3）在壳程序apk的application中进行解密源apk的dex文件。 知道了原理，下面就是代码实现了。这里有三个工程： 1）原程序项目 app module（需要加密的APK）。 2

一、什么是热修复： 相信很多人第一次听说热修复的时候也是一脸茫然，那么我就用自己的话来跟大家讲解一下。 当一个已经上线的APP突然发现一个严重的bug的时候，除了重新发版，让用户重新下载覆盖安装以外，还有没有别的方法来解决呢？如果可以有一个动态修复的方法就好了，那就是热补丁动态修复技术，也就是我们说的热修复。向用户下发Patch，在用户无感知的情况下，修复bug问题。这里用到的是android dex分包方案 ，后面会具体解释如何实现的。 这里我们先说一下Android的插件化，Android插件化分为三大块： 热部署 ， 动态加载资源 ， 四大组件动态加载 。 分别举例： 热部署 ------------------------------热修复 动态加载资源-------------------动态换肤 四大组件动态加载----------模块化开发 二、基于的原理——心急吃不了热豆腐 首先，就要从Android的 ClassLoader 体系来说起： ClassLoader顾名思义，就是在Java中加载一个类需要用到的。 在Android中有三大ClassLoader，分别为URLClassLoader，PathClassLoader，DexClassLoader.其中：URLClassLoader：只能用于加载jar文件，但是由于 dalvik 不能直接识别jar，所以在

1. 前言 文章开始需要提下的就是，在如今看雪论坛的用户一发关于安卓加固的文章动辄就是有关脱壳机、vmp、函数级指令抽取或者各大厂商的加固等技术的情况下，为何我要发一个代码抽取壳的分析，并且还是早期的那种整体抽取、整体还原回去、没有混淆、代码风格十分民风淳朴的那种壳... 原因是我开始尝试复现论坛中一些很优秀的关于 so 层的分析帖子时候，尽管很多帖子都力所能及进行了十分详细的说明，可是有些步骤我复现起来还是觉得不太理解或者有点力不从心，很多时候也是因为一些知识点和操作对大佬来说是比较简单的事情，说起来比较琐碎大佬就给一笔带过略了。 然后自己也尝试着去找一些 App 的 so 文件或者厂商加固的 App 进行分析，但是移动安全毕竟发展了这么多年，很多保护对抗技术都很成熟了，结果就是很多时候分析计划首先卡在了混淆上了... 混淆是件很头疼的事，变量函数名混淆、汇编指令的混淆、ollvm 混淆等这些都很好地阻碍了入门分析者的脚步，很多时候我们只是刚入门的新手，so 层的分析还不太熟练，壳和加固原理也没有那么的清晰，去混淆也没有那么手到擒来，很多文章能浅显的读懂但是没有碰到过一个很好的分析案例来帮我们巩固等等...一言以蔽之，段位太低了。 然后问题就出现了，刚入门想提高，然后去找 App 练手分析，结果一看首先就是各种胡里花哨的混淆甚至连 JNI_Onload 函数都找不到

一、Frida技术原理 Android脱壳的目的是从内存中dump下解密的应用dex文件，为了实现这个目的我们需要知道dex文件在内存中dex地址与dex文件大小。Android系统的libart.so库文件中提供了一个导出的OpenMemory函数用来加载dex文件。 这个函数的第一个参数指向了内存中的dex文件，如果我们可以Hook 这个函数，就可以得到dex文件加载进内存时的起始地址，再根据dex文件格式计算得到文件头保存的dex文件的长度fileSize。 二、获取函数签名 在编写Frida脚本之前我们需要在libart.so文件中找到OpenMemory的函数签名，这个签名根据android版本或者架构的不同会有些许差异，下面介绍如何从运行待脱壳应用的设备中提取libart.so文件： $ adb pull /system/lib/libart.so /本地目录 $ adb pull /system/lib64/libart.so /本地目录 获取libart.so文件后有两个方法可以获得函数签名，第一种是利用IDA pro 分析so文件，搜索OpenMemory函数： 第二种方法实在linux系统下使用nm命令直接查看libart.so文件的函数签名： $ nm libart.so | grep OpenMemory 三、编写脚本

众所周知，Android 最开始面世时，使用的开发语言是 Java,而 Java 是运行在 Java 虚拟机上的，即 JVM。那么为什么 Google 要单独设计一套新的 Dalvik 虚拟机来执行 Android 程序呢？可能是为了解决移动端设备上软件运行效率问题，可能是 JVM 虚拟机无法满足当时移动端的使用场景，也可能是为了规避与 Oracle 公司的版权纠纷问题，最终 Google 专门为 Android 平台设计了一套虚拟机来运行 Android 程序，它就是 Dalvik Virtual Machine(Dalvik 虚拟机)。 随着 Android 发展至今，虽然目前开发 Android 程序的语言已经越来越多样性，如 Java,Kotlin,Dart,Flutter 等等，但无论使用哪种语言开发 Android，最终都需要运行在虚拟机上,本篇文章将站在 Android 虚拟机的视角来分析 Android 程序的运行原理。 1、Dalvik 虚拟机概述及特点 Google 于 2007 年底正式发布了 Android SDK, Dalvik 虚拟机也正式进入我们的视野，而 Dalvik 命名的由来是取至其作者**丹·伯恩斯坦（Dan Bornstein）**曾居住过一个名叫 Dalvik 的小渔村。Dalvik 虚拟机作为 Android 平台的核心组件

记录下踩过的坑提醒下自己 我用到的工具： jadx DexExtractor 做好的 镜像 adt-bundle（eclipse） apktool baksmali.jar 和 smali.jar 1. 观察特征 先拿 jadx 看了下，没有activity类，这里可以注意到 AndroidManifest.xml 无写权限（第3步会说明） 度娘了一下SecShell，再结合题目，应该是梆梆安全加固-.- 参考了 最新各大apk加固特征库 git上现搜的工具 DexExtractor 根据md提示，下载了做好的 镜像 2. 模拟器就位 下载镜像版本是 android-19 ，需要版本一致~ 我的坑一：一开始用的 Android Studio 3.6 建的AVD，结果 android-19 的版本的模拟器怎么装都起不来，高版本的没问题。然后就弃了以后再研究。 用了老的 adt-bundle（eclipse） ，AVD新建启动，没有问题。 后来由于本机SDK过于杂乱，挨个system.img重命名才 找到adt-bundle（eclipse）所用的system.img，备份下用新下载的替换之。 （ AndroidManifest.xml 无写权限，可以直接跳第3步 ） 虚拟机装上了apk，启动apk，logcat筛选一下： （找sdk路径吧adb环境变量加上了，方面以后写命令） adb

告警信息： 13% building modules 28/40 modules 12 active ...dex=0!\src\App.vue{ parser: "babylon" } is deprecated; we now treat it as { parser: "babel" }. 95% emitting 是prettier版本导致的，直接在项目中：npm install prettier@~1.12.0 -d 然后重新npm run dev 来源： oschina 链接： https://my.oschina.net/u/4405407/blog/4278989

BoardConfig.mk WITH_DEXPREOPT := false 来源： oschina 链接： https://my.oschina.net/wfy94/blog/4347995