Android逆向之旅--运行时修改内存中的Dalvik指令来改变代码逻辑

太过爱你忘了你带给我的痛 2022-07-20 15:08 225阅读 0赞

# **一、前言** #

最近在弄脱壳的时候发现有些加固平台的加固方式是修改了dex文件结构，然后在加载dex到内存的时候，在进行dex格式修复，从而达到了apk保护的效果，那么在dex加载到内存的时候，如何进行dex格式的修复呢？其实原理就是基于运行时修改内存中的Dalvik数据，本文就来用一个简单的例子来介绍一下如何在内存中去修改Dalvik指令代码来改变代码本生的运行逻辑。在讲解本文之前，一定要先看这篇文章：[Android中Dex文件格式详解][Android_Dex] 这篇文章主要介绍了关于Dex文件的格式介绍，这个对于后面修改内存中Dex的数据是有很大的作用的，如果没有阅读完这篇文章，或者是不了解Dex的文件格式的话，下面介绍的内容将会看的很吃力，因为本文不会在重复的介绍一下Dex的文件格式了。好了，下面就开始我们今天的介绍主题了。

首先来说一下案例场景：

本文的案例就是将一个类的方法改变他的运行逻辑，原来的逻辑是加法操作，现在改成乘法操作。

# **二、案例介绍** #

这里在TestAdd类中有一个加法的操作方法，然后我们在native层去修改Dalvik指令，修改这个方法为乘法操作

![Center][]

这里我们可以看看TestAdd类的实现：

![Center 1][]

只是一个简单的加法操作，下面来调用运行测试：

![Center 2][]

测试结果如下：

![Center 3][]

看到了测试结果，发现是乘法，而不是加法的结过，好了，到这里我们就演示完了项目结构，下面来开始说说如何修改的：

# **三、代码解析** #

这里把修改指令的逻辑代码放在了native层做的，其实放到Java层也是可以的，但是会发现在操作内存字节的时候，Java会显得很无力，因为他没有指针，指针真的很好很强大，特别是在操作文件和内存字节的时候，那写代码都很爽的。

在MainActivity中定义了一个native方法：

![Center 4][]

我们使用javah指令产生头文件：

![Center 5][]

运行命令的时候，注意目录和类全名没有后缀。

把产生的头文件拷贝到工程中：

![Center 6][]

# **四、原理解析** #

下面开始写主要逻辑了，在编写逻辑之前，这里我还是说一下Dex的文件格式，以及本文章需要用到的几个数据结构：

**第一个数据结构：Uleb128**

LEB128 （ little endian base 128 ) 格式 ，是基于 1 个 Byte 的一种不定长度的编码方式 。若第一个 Byte 的最高位为 1 ，则表示还需要下一个 Byte 来描述 ，直至最后一个 Byte 的最高位为 0 。每个 Byte 的其余 Bit 用来表示数据 。这里既然介绍了uleb128这种数据类型，就在这里解释一下，因为后面会经常用到这个数据类型，这个数据类型的出现其实就是为了解决一个问题，那就是减少内存的浪费，他就是表示int类型的数值，但是int类型四个字节有时候在使用的时候有点浪费，所以就应运而生了，他的原理也很简单：  
![Center 7][]  
图只是指示性的用两个字节表示。编码的每个字节有效部分只有低7bits，每个字节的最高bit用来指示是否是最后一个字节。  
非最高字节的bit7为0  
最高字节的bit7为1  
将leb128编码的数字转换为可读数字的规则是：除去每个字节的bit7，将每个字节剩余的7个bits拼接在一起，即为数字。

比如：  
LEB128编码的0x02b0 —> 转换后的数字0x0130  
转换过程：  
0x02b0 => 0000 0010 1011 0000 =>去除最高位=> 000 0010 011 0000 =>按4bits重排 => 00 0001 0011 0000 => 0x130

底层代码位于：**android/dalvik/libdex/leb128.h**

**这个结构非常重要，也是后面所有结构的基础，而且在后面看解析代码中都会用到这个结构，知道他的原理，解析代码就很简单了。**

**第二个数据结构：string\_ids\_item**

**struct string\_ids\_item  
\{  
uint string\_data\_off;  
\}**

这个结构主要是存储dex文件中所有的字符串的，其中的string\_data\_off字段是字符串在dex文件中的相对地址，每个字符串都是uleb128格式的，解析完每一个字符串都存放到一个字符串池中，这个池子中的字符串索引值StringIdIndex将会被下面几个数据结构使用到。

类似于这样：

![Center 8][]

**第三个数据结构：type\_ids\_item**

**struct type\_ids\_item  
\{  
uint descriptor\_idx;  
\}**

这个数据结构，主要存储的是dex中所有类，方法等类型的id值，这里的descriptor\_ids字段就是上面的字符串常量池中的索引值id，这里解析完之后也会存放在一个常量池中，给后续的数据结构使用，类似于这样：

![Center 9][]

**第四个数据结构：class\_def\_item**

**struct class\_def\_item  
\{  
uint class\_idx;  
uint access\_flags;  
uint superclass\_idx;  
uint interfaces\_off;  
uint source\_file\_idx;  
uint annotations\_off;  
uint class\_data\_off;  
uint static\_value\_off;  
\}**

这个数据结构主要存储的是dex中所有类的元信息，其中class\_idx字段是一个TypeId类型的，就是上面的TypeId池子中的索引值，其他的字段不解释了，还有一个重要的字段就是class\_data\_off这个字段就是类数据在dex文件中的相对地址。

解析结构类似于：

![Center 10][]

**第五个数据结构：method\_id\_item**

**struct method\_id\_item  
\{  
ushort class\_idx;  
ushort proto\_idx;  
uint name\_idx;  
\}**

这个数据结构主要存储的是dex中所有的方法元信息，其中class\_idx字段是上面类数据结构中的class\_idx，name\_idx字段是在字符串池中的索引值id，这里解析完之后，也是需要用一个池子来存放这些MethodId索引值，下面的一些结构需要用到。

解析结构类似于：

![Center 11][]

**第六个数据结构：class\_data\_item**

**struct class\_data\_item  
\{  
uleb128 static\_fields\_size;  
uleb128 instance\_fields\_size;  
uleb128 direct\_methods\_size;  
uleb128 virtual\_methods\_size;  
encoded\_field static\_fields \[ static\_fields\_size \];  
encoded\_field instance\_fields \[ instance\_fields\_size \];  
encoded\_method direct\_methods \[ direct\_method\_size \];  
encoded\_method virtual\_methods \[ virtual\_methods\_size \];  
\}**

这个数据结构主要存储的是类中的具体信息，这里包括static字段，类字段，static方法，类方法等信息，这个数据结构数据在dex中的位置，就是上面的class\_def\_item数据结构中的class\_data\_off字段的地址。

解析结构如下：

![Center 12][]

**第七个数据结构：encoded\_method**

**struct encoded\_method  
\{  
uleb128 method\_idx\_diff;  
uleb128 access\_flags;  
uleb128 code\_off;  
\}**

这个数据结构主要存放的是一个方法指令的元信息，method\_idx\_diff字段是上面的方法类型池中的索引值id，code\_off字段就是这个方法存储的指令代码相对地址。

解析结构如下：

![Center 13][]

**第八个数据结构：code\_item**

**struct code\_item  
\{  
ushort registers\_size;  
ushort ins\_size;  
ushort outs\_size;  
ushort tries\_size;  
uint debug\_info\_off;  
uint insns\_size;  
ushort insns \[ insns\_size \];  
ushort paddding; // optional  
try\_item tries \[ tyies\_size \]; // optional  
encoded\_catch\_handler\_list handlers; // optional  
\}**

这个数据结构主要存储的就是方法的指令的具体信息，其中ins\_size字段表示的是这个方法的参数个数，insns\_size字段表示的是这个方法的指令条数，insns字段存储的就是指令内容，解析结构如下：

![Center 14][]

到这里我们就介绍了完了上面的几种数据结构，下面来总结一下：

首先用一张图来看看：

![Center 15][]

1》首先介绍了Uleb128数据结构，这个数据结构是贯穿所有数据结构的，所以这个数据结构是最基本的。

2》然后介绍了string\_ids\_item数据结构，这里需要把dex中所有的字符串解析出来存放在一个常量池中，后续的数据结构会通过索引值来获取。比如type\_ids\_item数据结构中的idx字段指向的就是这个索引值。

3》然后介绍了type\_ids\_item数据结构，这里的字段主要就是指向字符串常量池的索引值，解析完这个数据结构之后也是需要用一个常量池存储索引值，后续的数据结构会通过索引值来获取，比如class\_idx信息。

4》然后介绍了class\_def\_item数据结构，这里的字段主要是类的具体数据的偏移地址，类的索引值class\_idx(这个是通过TypeId池获取)。

5》然后介绍了method\_id\_item数据结构，这里主要是开始解析方法id内容，其中name\_idx字段是字符串常量池中的值(通过StringId池获取)，以及这个方法所在类的class\_idx值。

6》然后介绍了class\_data\_item数据结构，这个结构主要存储的是这个类对应代码的元信息，其中direct\_methods thod字段和virtual\_methods字段就是存储的是类对应的指令元信息。他们的结构是encoded\_method。

7》然后介绍了encoded\_method数据结构，这个结构中主要存储的是这个方法对应的元信息，其中method\_idx\_diff字段是上面得到的Method类型的id常量池索引值，code\_off字段是这个方法指令对应的相对地址。

8》最后介绍了code\_item数据结构，其中insns字段就是存储的是方法的指令数据。

来看看各个数据结构之间的关系：

![Center 16][]

这里就算全部解析完了本文需要用到的数据结构，以及这些结构相互引用关系，这里还需要注意的是：这里的一些结构的解析地址是存放在dex的头部信息中的：

![Center 17][]

下面我们在看看代码怎么去实现它，首先我们通过上面的例子看到，有一个字符串索引常量池，而我们现在如果想改一个方法的指令代码的话，肯定得找到他对应的code\_off地址即可，现在我们有的入口条件就是：方法名+类名，所以思路是这样的：

**类名=》字符串索引常量池=》类型TypeId=》类的定义元信息ClassDefItem=》类的代码元信息ClassDataItem**

**方法名=》字符串索引常量池+类的TypeId=》方法Id**

**方法Id+类代码元信息ClassDataItem=》方法的元信息EncodeMethod=》方法的指令代码结构Code**

有了这个思路，下面来看具体代码吧：

**第一步：获取应用的内存数据地址，读取/proc/pid/maps文件**

![Center 18][]

**第二步：解析出dex文件的内存地址**

因为我们知道一个进程的maps内存中是有很多数据的，所以这里需要先找到dex数据对应的起始地址：

![Center 19][]

下面看代码如何进行解析这个起始地址和结束地址：

![Center 20][]

这里我们打印一下起始地址和结束地址：

![Center 21][]

通过打印的信息，可以看到，我们上面在使用命令行去查看maps文件的时候是多个dex文件的，但是用代码去去的时候就是只有一个dex内容，但是不管怎么样，最终的起始地址和结束地址是一样。

**第三步：校验dex文件**

这里为什么说校验文件呢？因为在内存中存在的是odex文件了，这个文件其实是dex文件进行优化之后的产物，看一下odex文件的格式：

![Center 22][]

这个文件格式定义在DexFile.h头文件中，**源码位于：Android源码目录\\dalvik\\libdex\\DexFile.h**

![Center 23][]

这里的u1类型就是一个字节，u4就是4个字节，那么头部大小就是：8+4\*9=40.

所以，我们得到上面的起始地址，是odex文件的地址，我们需要获取到dex文件的偏移地址，然后在进行dex文件的头部信息校验，这里主要是校验dex文件的魔数：dex\\n35，注意中间有一个换行符哦：

![Center 24][]

下面来看具体代码：

![Center 25][]

这里首先需要获取系统的对其页面大小，一般都是0x1000，然后我们采用的是用内存的结束地址开始往前找，记得每次在校验dex的时候，需要考虑DexOptHeader的大小是40，每次叠加的大小是页面大小。调用findmagic方法来校验dex文件：

![Center 26][]

注意魔数中间有一个换行符即可。

第四步：获取方法和类的StringId索引值

![Center 27][]

关于这里的getStrIdx方法这里不再说了，代码后面会给出地址的，通过类的名称和方法的名称获取他们的StringId值

**第五步：获取方法和类的TypeId索引值**

![Center 28][]

这里关于getMethodIdx方法这里不再说了，代码后面会给出地址的，通过类的StringId获取ClassTypeId，再通过ClassTypeId和方法的StringId获取方法的MethodTypeId值。

**第六步：获取ClassDefItem地址**

![Center 29][]

**第七步：获取方法的指令代码**

![Center 30][]

这里主要获取指令的大小，然后在获取指令代码，打印出来，我们可以分析指令的含义，看一下打印的结果：

![Center 31][]

这里打印了指令大小是3，那么指令字节长度就是3\*2=6个字节，下面打印了指令的字节是：90 00 02 03 0F 00

到这里，其实我们已经完成了从内存中读取一个方法指定的指令字节了，下面就来看看如何修改这个指令吧，其实在修改之前，我们肯定得先去看懂这指令的含义。

一条指令其实组成部分就是：指令码+指令操作数，一般指令的头几个字节就是指令码，而且指令码是可以查阅的，这里需要参考：[Bytecode for Dalvik VM][] 比如这里的90指令码：

![Center 32][]

看到了，这里的90指令码就是对应的int类型的加法操作，而且看到指令的格式是：binop vAA，vBB，vCC，再看看这个指令的解释：

![Center 33][]

意思是，vBB+vCC=vAA。那么看到方法的定义是，传入两个参数，还需要一个参数用来存放结算值，我们可以反编译apk得到方法的smali语法看看：

![Center 34][]

看到了，smali语法就是和我们分析的一样，那么这里的指令分析结果：

90 00 02 03 0F 00

![Center 35][]

分析完了指令，下面我们可以修改了，这里把加法变成乘法，其实就是改变操作码：

![Center 36][]

通过查阅，92代表乘法指令码，那么这里把90改成92即可，下面就来进行修改：

但是在修改之前还需要做一件事，改变内存属性，因为一般数据被加载到内存中是不允许修改了，但是可以借助**mprotect**函数来进行修改即可，因为我们只要修改add方法指令，那么只需要修改这个方法所在内存的那一页进行修改即可，其他的地方不需要改成可写模式的，改完之后，在使用memcpy函数进行内存数据的覆盖即可：

![Center 37][]

看到了，通过上面这么已修改之后，add方法就变成了乘法了，这就是我们在文章开始的时候演示的传入的是4,5得到的全是20不是9的原因了，到这里我们也成功的修改了内存中的方法指令，下面来总结一下：

# **六、修改流程步骤总结** #

1》首先是需要确定method的名字，也就是method字符串，再确定method所在class的名字，也就是class字符串。这确定了要修改的方法。  
2》把2个字符串到DexStringId结构的位置进行搜索，进而得到2个字符串在DexStringId中的索引序号。  
3》对于class字符串，再通过DexStrngId索引序号，到DexTypeId中搜索，得到class字符串在DexTypeId中的索引序号。  
4》还是class字符串，得到DexTypeId中的索引序号后，再到DexClassDef中搜索，就可以得到class的DexClassDef的位置。其中classDataOff字段记录了DexClassData偏移，这个结构里可以找到DexMethod结构。  
5》而对于method字符串，找到DexStringId索引后，再结合上面class的DexTypeId，可以确定DexMethodId的索引序号。  
6》 现在我们知道了DexMethodId的索引序号，也知道了存放DexMethod的位置，直接搜索就可以得到我们要找的DexMethod。这个结构里的codeoff指向了存放指令的位置。

得到指令之后，我们在对照指令表，来阅读指令的含义，然后将指令码进行替换，修改内存为可读可写模式，最后再把修改之后的指令写到内存中。

**项目下载地址：[http://download.csdn.net/detail/jiangwei0910410003/9565563][http_download.csdn.net_detail_jiangwei0910410003_9565563]**

# **七、存在的问题** #

上面看到修改内存指令其实还是比较简单的，因为本文主要介绍如何修改内存指令原理，所以用一个简单的例子来进行说明，但是在实际的过程中有这么一个问题就是我们在修改一个比较复杂的方法指令的时候，如果出现增加或者减少指令的情况，那么我们的指令代码的偏移地址就会发生改变，这样就会很麻烦，需要进行dex结构修复了，而这部分工作将会变得很难。

# **八、技术用途** #

本文介绍了运行时修改内存的指令代码，其实有两个用途：

**第一个用途：**就是在本文开始的时候说到了，现在很多加固平台会操作apk中的dex文件，修改他们的数据结构，比如ClassDefItem，然后在内存运行dex的时候在进行结构修复，这样就可以避免一些破解者破解apk的风险了。

**第二个用途：**在设备root之后，可以注入到其他进程，然后修改其他进程的核心方法指令，从而达到一些自己想要的想过，但是上面也说道了，这种方式最大的问题是在修改指令之后，需要进行一定的修复，不然dex结构也是被改乱了，程序就会崩了。

# **九、技术概要** #

1、了解了Dex文件的几种数据格式

2、DexOpt格式了解以及dex和odex之间的关系

2、分析了如何通过类名和方法名找到其对应内存的指令代码，并且获取相对应的指令

3、使用mprotect函数进行内存模式的修改

4、Dalvik指令字节码的了解

# **十、总结** #

运行时修改内存中的指令代码思路其实很重要，而且对dex中各个数据结构的了解，所以本文的流程是：先了解dex中一些数据结构，然后在设想修改思路，找到内存中对应方法的地址，得到指令，然后进行修改覆盖即可。

[Android_Dex]: http://www.wjdiankong.cn/android%E9%80%86%E5%90%91%E4%B9%8B%E6%97%85-%E8%A7%A3%E6%9E%90%E7%BC%96%E8%AF%91%E4%B9%8B%E5%90%8E%E7%9A%84dex%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F/
[Center]: /images/20220720/712dbba4f22d4916a1622909dc7f091a.png
[Center 1]: /images/20220720/f9604deb90744d809fc791c4bd58577b.png
[Center 2]: /images/20220720/4c465c18a7774e3090175c0f728c0bc4.png
[Center 3]: /images/20220720/fc9c3ab4591d4f51a8b2806d196a8275.png
[Center 4]: /images/20220720/e4e3010216c640968c3d6aada09fdafb.png
[Center 5]: /images/20220720/a0930748a42645158774d54e15d0d626.png
[Center 6]: /images/20220720/e0d8d4244ba249ed942a2cd85d185d24.png
[Center 7]: /images/20220720/a4c7d468a3174c88a57341417cd87b6a.png
[Center 8]: /images/20220720/9efa9981ae5b4db8aa0ad06b1fc7356a.png
[Center 9]: /images/20220720/12a1b609b9514f23a7c0d73456d9a4bc.png
[Center 10]: /images/20220720/7f4f72f08f2647b9a823fc7064dd5c81.png
[Center 11]: /images/20220720/014a8e965ed24156a016e62c721b1de3.png
[Center 12]: /images/20220720/db7a9262adc74de096d82b324c72baae.png
[Center 13]: /images/20220720/49390c761ac1474e8dd86936e14ab4fe.png
[Center 14]: /images/20220720/7349a7f7852f4f1182022a76afdb2a1c.png
[Center 15]: /images/20220720/efaec7b85c6640d3ade7758cdf2ab86e.png
[Center 16]: /images/20220720/38f2bef563334a85801a550ecde7f17f.png
[Center 17]: /images/20220720/93873fcc17a9421bbc96898566eb5913.png
[Center 18]: /images/20220720/a69fd87046314a6e833d02979717ce69.png
[Center 19]: /images/20220720/5e5ade6359f64f0dbb105284ccb1907e.png
[Center 20]: /images/20220720/f00bd59d7b4746859a0cba2654c8950b.png
[Center 21]: /images/20220720/6d639b63b3e64dcf8eaa7a98e2abe199.png
[Center 22]: /images/20220720/71a772a9f5e8417daf86ce8a5c6ba88c.png
[Center 23]: /images/20220720/4c1623ac8a064abbb67aad139bf71d7e.png
[Center 24]: /images/20220720/ca6776ec1fec452bb9edb86e65380c17.png
[Center 25]: /images/20220720/4ea5ee4e5c744835922535944f2bff88.png
[Center 26]: /images/20220720/72cd7e30381241d7afe7a92140617f5a.png
[Center 27]: /images/20220720/9fe807f42dbc43c5adc9d72ba8ffe28a.png
[Center 28]: /images/20220720/bd96d7518a924632b240216cba744f6f.png
[Center 29]: /images/20220720/022966ff63f14455b01c84647f9e2cba.png
[Center 30]: /images/20220720/a293ad4212bd4a299b077525238d3ed6.png
[Center 31]: /images/20220720/2a05b84a72674c428ffda74142588e47.png
[Bytecode for Dalvik VM]: http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html
[Center 32]: /images/20220720/d400445a8ea844cab080dd997df04254.png
[Center 33]: /images/20220720/2cb482f3ba78444cad55911d92f20cdf.png
[Center 34]: /images/20220720/54ec2dd51a2a4588b20827a70514ece3.png
[Center 35]: /images/20220720/32498b1254cf4ba0aa7edf7770b11a5e.png
[Center 36]: /images/20220720/ec0bb37bcaf4463694b7996a4d8d10b3.png
[Center 37]: /images/20220720/4e1ceb2d39cc415ba37a2296d167e7d4.png
[http_download.csdn.net_detail_jiangwei0910410003_9565563]: http://download.csdn.net/detail/jiangwei0910410003/9565563