在上一篇博客 【Android 逆向】ART 脱壳 ( dex2oat 脱壳 | aosp 中搜索 dex2oat 源码 | dex2oat.cc#main 主函数源码 ) 中 , 分析到 dex2oat 工具源码中的主函数为 /art/dex2oat/dex2oat.cc#main , 在该函数中调用了 /art/dex2oat/dex2oat.cc#Dex2oat 函数 ;
在上一篇博客 【Android 逆向】ART 函数抽取加壳 ( ART 下的函数抽取恢复时机 | 禁用 dex2oat 机制源码分析 )
在上文中,我们讲解了关于Android脱壳的基本办法和实际操作,现在我们来针对脱壳(一代壳)的原理和脱壳相关的基础知识介绍,由于作者能力有限,会尽力的详细描述 一代壳脱壳 的流程及原理,如本文中有任何错误,烦请指正,感谢~
在 【Android 逆向】ART 脱壳 ( DexClassLoader 脱壳 | exec_utils.cc 中执行 Dex 编译为 Oat 文件的 Exec 和 ExecAndReturnC函数 ) 博客中 , 将 dex 文件编译为 oat 文件 , 编译过程是由 dex2oat 可执行程序完成的 , 这是一个有 main 函数的可执行程序 ;
两篇博客中 , 简单介绍了 禁用 dex2oat 机制 的原理 , 下面开始 实现 dex2oat 禁用功能 ;
从Android 2.1版本到现在的Android 11 , 中间虚拟机变化过三次 :
如果选择第一种方案 , 在 dex2oat 之前进行恢复 , 这没有任何意义 , dex2oat 编译后 , 生成的 oat 文件是完整的 , 此时 可以 完整的将 oat 文件 dump 到 SD 卡中 , 基本等于没有加固 , 还是一个一代壳 ;
在上一篇博客 【Android 逆向】ART 脱壳 ( DexClassLoader 脱壳 | DexClassLoader 构造函数 | 参考 Dalvik 的 DexClassLoader 类加载流程 ) 中 , 分析了 ART 虚拟机下 DexClassLoader 类加载器加载 dex 文件的 Java 层流程 , 与 Dalvik 虚拟机下基本一致 , 从 native 层开始不一致 , 本篇博客开始分析 native 层的类加载流程 ;
本文简要介绍 Android Runtime 虚拟机里的一些细节点,主要包括 dex file, oat file, mirror::Class, ArtField, ArtMethod, DexCache, ClassTable 等。
常规的手段优化后,我们能解决基本的问题,但是我们得继续追求极致,本章将分享一些意想不到的手段。
我们知道在Android N 中对其 ART做了比较大的变化。主要是同一程序的代码可能同时运行在本地机器码(编译)、解释和JIT(Just In Time)的混合运行模式,并且不同的用户,同一应用程序的代码,可能运行不同的编译代码。因为有了Profile-guided JIT/AOT Compilation,那么不同的用户行为对同一app可能会有不同的编译结果。N 上做此变化的其目的是为了在安装时间、内存占用、电池消耗和性能之间获得最好的折衷。
最近参加了华为方舟的Workshop,从编译到Runtime都有了一些体会,并且对于虚拟机的运行也有了一些了解。
OAT文件是一种Android私有ELF文件格式,它不仅包含有从DEX文件翻译而来的本地机器指令,还包含有原来的DEX文件内容。
首先非常抱歉Tinker没有按期内测,这主要因为开源的代码需要通过公司内部审核与评测,这项工作大约还需要一个月左右。当前Tinker已经在公司内部开源,我们会努力让它以更完善的姿态与大家见面。 大约在六月底,Tinker在微信全量上线了一个补丁版本,随即华为反馈在Android N上微信无法启动。冷汗冒一地,Android N又搞了什么东东?为什么与instant run保持一致的补丁方式也跪了?talk is cheap,show me the code。趁着台风妮妲肆虐广东,终于有时间总结一把。在此非常
2016年3月10日,Tinker项目正式启动,并在同年9月23日举行的MDCC会议上开源。一年过去了,两个人,50%的工作时间。总的来说,填了一些坑,获得少许成绩,也遭受不少批评。 究竟Tinker是否将已经很糟糕的Android的生态变得更差,会不会对用户的安全造成更大的挑战? 回想Tinker的初心,我们希望开发者可以用很小代价进行快速升级,它是国内追求快速迭代诉求。立项至今,Tinker踩了很多坑也填了很多坑。今天,我希望跟大家分享这一年来我们遇到的一些问题,以及解决它们的思路与过程。 Tinke
作者|shwen 来自|WeMobileDev 2016年3月10日,Tinker项目正式启动,并在同年9月23日举行的MDCC会议上开源。一年过去了,两个人,50%的工作时间。总的来说,填了一些坑,获得少许成绩,也遭受不少批评。究竟Tinker是否将已经很糟糕的Android的生态变得更差,会不会对用户的安全造成更大的挑战? 回想Tinker的初心,我们希望开发者可以用很小代价进行快速升级,它是国内追求快速迭代诉求。立项至今,Tinker踩了很多坑也填了很多坑。今天,我希望跟大家分享这一年来我们遇到的一
21世纪,安卓虚拟机正在一步步的走入我们的生活,小到个人部分朋友在电脑上使用安卓虚拟机玩手游,大到安卓从业人员在虚拟机上面跑程序。不得不承认,对于每一位Androider 而言,安卓虚拟机是我们日常开发中不可或缺的一环,但是关于安卓虚拟机的一些知识点和小细节你真的完全掌握了么?本文将就主要包括 dex file, oat file, mirror::Class, ArtField, ArtMethod, DexCache, ClassTable,这一块内容进行一个简单的概述和讨论,希望新手们多多学习,老手们温故而知新。
在进行apk热修复、插件化、动态加载的时候,会经常多个jar/dex包含相同的class,如果class结构因为需要升级出现了变化,会隐藏一些很难解释的坑在里面,务必谨慎。
大约在六月底,Tinker在微信全量上线了一个补丁版本,随即华为反馈在Android N上微信无法启动。冷汗冒一地,Android N又搞了什么东东?为什么与instant run保持一致的补丁方式也
最近在使用一款Art Hook框架对应用进行Hook的时候发现,函数Hook之后却总是没有被触发,于是怀疑是被dex2oat做了Inline处理。
现在市面上的 Android 手机大部分都是运行的是ART虚拟机了。还记得自己一部 Android手机(HuaweiG520),Android4.1 系统。那时候还是没有 ART虚拟机 的。作为Android开发者,我们应该对 Android 的发展历史有些了解为什么 Android 会经历这么多的变化。Android 是先有 JVM 然后是 Dalvik ,接着是现在的 ART虚拟机 。那么他们之间有什么关系呢?
目录简述(脱壳前学习的知识、壳的历史、脱壳方法) 第一代壳 第二代壳 第三代壳 第N代壳 简述Apk文件结构Dex文件结构壳史壳的识别Apk文件结构
为什么说经过oat之后的代码比jit的代码执行速率高:这其实类似于学习一门外语的过程~
由于国内 Android 开发环境的特殊性,兼容性一直是很多开发者极为关注的问题。为此,我们特意请来了负责 Android 在中国兼容性问题的 Google 工程师为大家对一些常见问题做出解答,来看看我的工程师提到了哪些要点吧! "大家好,我是谷歌的开发技术推广工程师,主要负责 Android 在中国的兼容性问题。我们发现,每次有 Android 新版本发布时,国内有很多应用由于没有遵循最佳开发实践,或使用了依赖于底层非公开 API 的 “黑科技”,而无法直接在新版本上运行,必须做出相当的代码修改来进行兼容
在Android 8.0中 , 一共有5中编译时机 (或者说原因) , 而dexopt会根据这几个场景进行不同的编译过程 , 而对应的过程所使用的编译方法则是通过在SystemProperty中提前预置 , 在使用时从SystemProperty中读取来定义. :
从 2018 年 3 月初我们发布 Android P 开发者预览版以来,很多开发者都对当前常见应用在 Android P 上做了一些兼容性测试,我们在这里总结了一些常见的问题,以及它们发生的原因和建议的修改措施。 问题 1: 假设 android.os.Build.VERSION.RELEASE 为数值类型 原因: 对于即将推出的 Android 新版本的预览版,这些值可能是字母数字 (如 “PPR” 或 “P”),因此在尝试将 “P” 解析为整数时会导致崩溃。 建议: 应用把 RELEASE 的值作为
使用了系统的 ClassLoader 加载 org.apache.http.* 的库
Android模拟器6.0版本进入系统时,桌面应用com.android.launcher3会发生随机Crash。 W/System.err( 1611): java.lang.IllegalArgumentException: Wrong state class, expecting View State but received class android.appwidget.AppWidgetHostView$ParcelableSparseArray instead. This usually h
Android应用程序主要是通过Java语言开发的(当然,也可以结合NDK通过C/C++开发。另外,从Android N开始,Kotlin已经成为Android官方开发语言,但实际上Kotlin的编译产物仍然是在虚拟机上运行的)。Java语言的编译产物是不能直接在设备上运行的,而必须借助于虚拟机来执行。
基本原理:加载类的时候是找element,每个element对于一个dex。我要把我修复的那个类单独放到dex插入dexlist前面,在你做类加载从前往后找优先从你的dex加载加载的就是你修复后的class.这就是
常规问题 Q1: 什么是非 SDK 接口? A:非 SDK 接口指不在官方 Android SDK 涵盖范围内的 Java 字段和方法。此类接口是 SDK 的内部实现细节,可能随时会被修改,且不对开发者另行通知。 常规问题 Q2 : Android P 在非 SDK 接口使用限制方面采取了哪些举措? A:谷歌正在逐步限制非 SDK 接口的使用:针对不同接口采取不同形式的限制 (详情请参照条目 “应用运行时,我应该如何检测非 SDK 接口的使用?” )。若您正在使用非 SDK 接口进行开发,请特别注意限制对应
DEX 整体加壳 就是将 完整的 DEX 文件 , 进行加密 , 只保留一个壳应用 , 应用执行时 , 壳应用解密 DEX 文件 , 然后执行解密后的 DEX 文件 ;
1、通过aapt打包资源文件res,对应生成R.java、resources.arsc和res文件(二进制&非二进制保持原来的代码)
卡顿、不流畅是应用性能问题最为直观的表现之一。针对应用卡顿现象,软件绿色联盟联合华为终端开放实验室进行了大量分析、总结,希望能够为应用开发者提供针对性的优化建议,共同打造更好的使用体验。
如果你有这样的问题: 1.Dalvik和ART的区别 2.DEX在Dalvik转化为ODEX和ART中转化为ODEX的过程有上面区别 3.multidex在dalvik上起作用,ART上使用的也是multidex么(如果不是的话在application中写入multidex.install会对apk启动造成影响么)
最近半年以来,Android热补丁技术热潮继续爆发,各大公司相继推出自己的开源框架。Tinker在最近也顺利完成了公司的审核,并非常荣幸的成为github.com/Tencent上第一个正式公开的项目。 回顾这半年多的历程,这是一条跪着走完,坑坑不息之路。或许只有自己真正经历过,深入研究过, 才会真正的明白 热补丁不是请客吃饭 对热补丁技术本身,还是对使用者来说都是如此。它并不简单,也有着自己的局限性,在使用之前我们需要对它有所了解。我希望通过分享微信在这历程中的思考与经验,能帮助大家更容易的决定是否在自
Dev Club 是一个交流移动开发技术,结交朋友,扩展人脉的社群,成员都是经过审核的移动开发工程师。每周都会举行嘉宾分享,话题讨论等活动。 本期,我们邀请了腾讯WXG Android开发工程师——张绍文,为大家分享《微信热补丁 Tinker 的实践演进之路》。 分享内容简介: Tinker 是微信官方的 Android 热补丁解决方案,它支持动态下发代码、So库以及资源,让应用能够在不需要重新安装的情况下实现更新。这里大致介绍 Tinker 的实现原理,当时遇到的各种坑以及对它各个方面性能的优化工作。 内
将打包好的 APK 文件安装到 Android 手机中 , 就是可运行的应用程序 ;
在日常的 Android 应用安全分析中,经常会遇到一些对抗,比如目标应用加壳、混淆、加固,需要进行脱壳还原;又或者会有针对常用注入工具的检测,比如 frida、Xposed 等,这时候也会想知道这些工具的核心原理以及是否自己可以实现。
当程序越来越大之后,出现了一个 dex 包装不下的情况,通过 MultiDex 的方法解决了这个问题,但是在低端机器上又出现了 INSTALL_FAILED_DEXOPT 的情况,那再解决这个问题吧。等解决完这个问题之后,发现需要填的坑越来越多了,文章讲的是我在分包处理中填的坑,比如 65536、LinearAlloc、NoClassDefFoundError等等。
我们知道不管是插件化还是组件化,都是基于系统的ClassLoader来设计的。只不过Android平台上虚拟机运行的是Dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码
介绍一种有点不同于目前 Android 平台上常用的 native backtrace 技术,在支持 Android ART unwind 的情况下,通过损失少数可回溯场景换取性能提升。方案有一些优势和局限性,适用于部分场景。 通常如何在 Android native 中进行栈回溯 其实 Android 上实现 native 栈回溯的方式并没有很多,罗列一下大概就两种:一种是基于函数栈帧基地址(fp=frame pointer)寄存器的栈回溯,另一种是基于异常处理(EH=Exception Handli
一款命令行工具,用于从Vdex文件反编译和提取Android Dex字节码的工具。
我一直在尝试将 AndroidX collection library 移植到 Kotlin multiplatform,来测试二进制兼容性,性能,易用性和不同的内存模型。类库中的一些数据结构使用基于数组实现的二叉树来存储元素。在 Java 代码中有许多地方使用 移位操作 来代替二次幂的乘除法。当移植到 Kotlin 时,这些代码会被转化为略显变扭的中缀操作符,这有点混淆了代码意图。
领取专属 10元无门槛券
手把手带您无忧上云