关于烧饼游戏修改器的分析

时间：2016-07-22 18:35:41 阅读：267 评论：0 收藏：0 [点我收藏+]

标签：

一、前言

　　烧饼游戏修改器是一款元老级的游戏修改器，提供了精确搜索、模糊搜索、联合搜索、数据过滤、存储搜索与读取搜索等功能。主要实现搜索手机进程的内存数据并做相应修改。

　　本文中分析的版本为2.0.2(34)，SDK:8，TargetSDK：17，代码经过混淆，修改器基本使用方法为输入需要修改的数据进行查询，查询结果少则可直接修改，查询结果多则需要返回游戏，使想修改的数据发生变化后再次搜索，最后根据数据变化偏移找到需要修改的地址。输入想要修改成的数据即可修改。

　　本程序测试机为LG Nexus 5，版本为Android 4.4，运行程序前需先root手机。

　　系统环境：Java 1.8.0_92 ，Android Debug Bridge version 1.0.36

　　使用工具：AndroidKiller、JEB、Eclipse、IDA

二、详细分析

2.1 关于smali注入代码的说明

　　为了便于分析，本文中涉及向工程中注入smali代码并重新打包运行，对常用的注入代码做如下说明。其中使用到的寄存器vn要根据实际代码使用的寄存器个数来做相应修改。如图2-1中的run()中“.locals 5”申明使用了5个寄存器，即v0~v4，如果我们需要插入一条日志信息，为了不影响原来代码的执行，需要自己增加一个寄存器v5，先将“.locals 5”变成“.locals 6”，再用v5来保存日志信息。

图2-1 Smali代码中对寄存器的说明

2.1.1 log信息输出

const-string vn, "提示语"

invoke-static {vn}, Lcom/android/killer/Log;->LogStr(Ljava/lang/String;)V

图2-2 Log信息输出

2.1.2 打印字符型数据

const-string vn, "string数据"

invoke-static {vn, v1}, Landroid/util/Log;->v(Ljava/lang/String;Ljava/lang/String;)I

图2-3 打印字符数据

2.1.3 打印整型数据

const-string vn, "int数据"

invoke-static {v1}, Ljava/lang/Integer;->toString(I)Ljava/lang/String;

move-result-object v(n+1)

invoke-static {vn, v(n+1)},Landroid/util/Log;->v(Ljava/lang/String;Ljava/lang/String;)I

图2-4 打印整型数据

2.1.4 打印boolean型数据

const-string vx, "boolean数据"

invoke-static {p1}, Ljava/lang/Boolean;->toString(Z)Ljava/lang/String;

move-result-object v(x+1)

invoke-static {vx, v(x+1)}, Landroid/util/Log;->v(Ljava/lang/String;Ljava/lang/String;)I

图2-5 打印boolean型数据

2.1.5 栈追踪

new-instance vn, Ljava/lang/Exception;

const-string v(n+1),"这里是 trace"

invoke-direct{vn,v(n+1)},Ljava/lang/Exception;-><init>(Ljava/lang/String;)V

invoke-virtual{v(n+1)},Ljava/lang/Exception;->printStackTrace()V

图2-6 栈追踪

2.1.6 toast输出

const-string v0, "这里是Toast输出"

const/4 v1, 0x1

invoke-static {p0, v0, v1}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

move-result-object v0

invoke-virtual {v0}, Landroid/widget/Toast;->show()V

图2-7 Toast输出

2.1.7 加载so库

const-string v0, "这里是Toast输出"

const/4 v1, 0x1

invoke-static {p0, v0, v1}, Landroid/widget/Toast;->makeText(Landroid/content/Context;Ljava/lang/CharSequence;I)Landroid/widget/Toast;

move-result-object v0

invoke-virtual {v0}, Landroid/widget/Toast;->show()V

图2-8 加载so库

2.2 Java层代码分析

2.2.1 加载的so文件

　　用AndroidKiller打开该apk，得到反编译之后的工程，如图2-9。

技术分享

图2-9 反编译之后的apk工程目录

　　查看AndroidMainfest.xml，如图2-10，可以看到应用程序包名为“org.sbtools.gamehack”，程序主活动为“MainActivity”，还可以看到服务名为“org.sbtools.gamehack.sesrvice.FlowServ”。

技术分享

图2-10 AndroidMainfest.xml

　　找到MainActivity.smali，其中onCreate方法如图2-11，在做一些布局工作后调用了a()，a()方法如图2-12，其主要工作为启用Instrumentation，通过Instrumentation框架，可以在主程序启动之前，创建模拟的系统对象，如Context；控制应用程序的多个生命周期；发送UI事件给应用程序；在执行期间检查程序状态等。从AndroidMainfest.xml中可以知道Instrumentation对应的方法为org.sbtools.gamehack.GameInstrumention。在Instrumentation中启用了服务，如图2-13。

技术分享

图2-11 MainActivity.onCreate()

技术分享

图2-12 MainActivity.a()

图2-13 启动服务

　　在FlowServ中，发现该方法加载了Libencode.so，而在该方法中我们可以找到decode被声明为native（图2-14），想必能用到这个decode的地方一定是关键之处，于是在工程里搜索decode，发现在/d/i.smali中用到了decode，而decode上面出现了两个可疑文件（图2-15）。在工程中注入代码打印出string v1，打开eclipse，在DDMS中打印出如图2-16的信息，可知将路径“/data/data/org.sbtools.gamehack/files/hack”和“/data/data/

org.sbtools.gamehack/files/gamehack”作为参数传给了decode()，随后在该类的a方法中运行了hack文件（图2-17），运行之后将该文件删除（图2-15）。

技术分享

图2-14 Native程序加载

技术分享

图2-15 调用decode的地方

技术分享

图2-16 获取的path

图2-17 执行hack文件

　　这里的gamehack文件笔者未找到，IDA调试程序安装时显示Libdecode.so加载失败，因此按逻辑图2-7中的decode()执行失败，后面的hack文件不能执行，但以附加方式调试代码时候hack文件确实已经执行了，观察smali代码反应JEB翻译的java逻辑没有问题，猜测程序采用了一些反调试的手段，具体原因还待考究。

2.2.2 Socket消息传送

　　打开该程序，搜索界面和搜索结果界面如图2-18、图2-19，我们有多种方法来了解执行搜索时候java层的执行逻辑，比如在AndroidKiller中搜索字符串“搜索”，找到其ID，逐层分析其流程，或从搜索结果入手，搜索找到“共搜索到%ld个数值，请选择修改”出现的地方，然后利用再smali代码中添加栈回溯语句来查看栈调用顺序。

技术分享

图2-18 搜索界面

技术分享

图2-19 搜索结果页面

　　最后我们在ah类中找到程序对搜索消息的的设置（图2-20），最后发送的数据为“s [要搜索的数据] 标志位 0”，其中s表示正在进行搜索操作，当输入的搜索数据合法时，标志位为1。我们在这个方法中注入代码打印出发送的消息，发送的消息如图2-21所示。

图2-20 设置搜索消息

图2-21 发送的消息

　　那么现在问题来了，这些消息发送给了谁？又是谁来接收这些搜索指令呢？分析到这里，之前提到的hack文件的功能就可想而知了。

2.3 Hack文件分析

2.3.1 获取hack文件

　　那么这个hack文件具体做了些什么呢？为了进一步分析我们需要先提取该hack文件。打开adb shell，进入该文件所在目录，但是ls命令并未查看到，文件显然已经被删掉了。（图2-22）

技术分享

图2-22 adb shell未查找到文件

　　此时我们有两种方法来找到该hack文件：

　　方法一：找到删除文件的smali代码，注释掉删除文件的代码，重新打包运行。之后用adb pull /data/data/org.sbtools.gamehack/files/hack D://命令将文件拷贝到本地计算机。注释掉的代码如图2-23、图2-24所示。

图2-23 注释掉的代码1

技术分享

图2-24 注释掉的代码2

　　方法二：linux系统中每一个进程都有一个/proc/[pid]目录，该目录下保存着有关该进程的各类信息，其中有个文件名为exe,这个文件是一个链接指向该进程的实际可执行文件。用命令ps |grep gamehack找到该进程ID为18912（图2-25），执行cd /proc/18912 进入到该进程信息目录，用ls –al会看到我们要找的文件。linux系统删除文件是使用了unlink这个函数，这个函数只会减少某个文件的硬连接数，当某个文件被打开后，并调用unlink删除该文件时，使用ls命令是不能查看到该文件了的，但这个文件实际上还是存在在磁盘上的，当使用该文件的进程结束时或者调用close关闭该文件描述符时，这个文件才真正的从磁盘上消失。因此，只要程序还在运行，该hack文件就不会被真正删除，将该文件拷贝到sdcard，再pull到计算机上（图2-26）。

技术分享

图2-25 查看进程ID

技术分享

图2-26 进入进程目录并提取文件

　　接下来就可以对该文件进行分析了。

2.3.2 hack文件分析

　　IDA加载提取出来的hack文件，查看导出表，只有一个start()，双击进入start()，F5之后如图2-27所示。

图2-27 start()启动函数

　　在我重命名为“_HackWhat”的函数中，实现了该程序中最核心的功能。首先建立起socket连接，接收来自远端的数据，并根据第一个数据来决定后续要执行的操作（图2-28）。前面我们已经得出，当执行数据搜索的时候用字母“s”来表示，直接分析case s的代码（图2-29），可以发现在_DataMemory()中对接收到的数据做了一些处理，提取出需要搜索的数值，接着在_SearchData中读取进程内存信息进行搜索。

图2-28 接收socket数据

技术分享

图2-29 搜索数据

　　静态分析搜索部分的代码，可以看到程序首先用ptrace来attatch进程(图2-30)，接着打开了进程内存映射信息所在的文件“/proc/[PID]/maps”并读取相关信息进行保存(图2-30)。

图2-30 Ptrace进程

技术分享

图2-31 读取内存映射信息

　　接下来程序读取进程内存信息“/proc/[PID]/mem”并保存。此处用于监测程序的内存映射信息是否发生变化。当在执行搜索操作时，程序实际上执行的为图所示的_SearchData函数，该函数在IDA中的偏移地址为0000A900。

图2-32 读取进程内存

技术分享

图2-33 执行搜索

　　在该函数中，同样先ptrace进程，读取内存信息并和之前保存的做一个比较，校验内存是否发生变化，接着从内存信息中搜索我们要修改的数据（图2-35、图2-36），而此处的具体逻辑还待深究，此处未作进一步描述。

图2-34 读取内存信息

技术分享

图2-35 搜索数据a

技术分享

图2-36 搜索数据b

　　搜索完数据之后，执行图2-29中的_SendFindResult将搜索结果发送到远端，交给java层代码做接下来的处理。

　　如果搜索结果太多，需要我们返回游戏，手动使想要修改的数据发生变化，然后重新搜索(图2-37)。此时发送的消息为“f = [Data]” (图2-38)。Hack程序收到socket信息后会提取变化之后的数字，再次执行图2-33中的_SearchData函数，不过此时会读取刚才搜索数字8之后的内存，检测哪一个内存保存的数值变为了12，据此来锁定想要修改的数据所在的内存。接着执行修改操作。

技术分享

图2-37 变化数据

技术分享

图2-38 第二次搜索时向socket发送的数据

　　当点击修改之后，hack进程识别标志修改的字母“m”并执行如图2-39所示的操作流程。在对收到搜索命令做一系列提取等操作之后，ptrace注入进程并对相应内存地址的数据进行修改(图2-40)，最后将修改结果发送给java层进行处理。

图2-39 修改数据a

技术分享

图2-40 修改数据b

2.3.3 用IDA进行动态分析

　　以上分析结合了静态分析和动态分析，用IDA对进程进行动态分析的步骤如下：

　　1) 把IDA\dbgsrv目录下的android_server push到android中，命令：

　　　　adb push android_server /data/data/sv

　　2) adb shell进入该目录，为android_server赋755权限并以管理员权限运行。

cd /data/data/sv

chmod 755 android_server

./android_server

　　　　成功运行之后可以看到监听端口为23946。.

　　3) 在windows控制台下转发window到模拟器或手机端口。

　　　　adb forward tcp:23946 tcp:23946

　　4) 在IDA中选择android调试，在Debuggger 中的process options 的hostname 填上localhost。

　　5) 在Debugger中的attach上选择对应的android程序即可。

　　这里由于hack文件运行之后被删除了因此需要注释掉删除文件的代码，重新编译运行之后才能attach上该进程。附加上该进程之后在IDA右侧的Modules窗格可以看到该文件基址为00008000，从刚才IDA加载的我们导出的hack文件中可以看到start偏移地址为00009010。两个地址相加即为该代码在elf文件中的实际地址，即00011010，我们在IDA中找到这个地址并下断。接着运行程序点击搜索，可以发现程序执行了如图所示的流程，在寄存器窗格中可以查看到存放接收数据的地址，Hex窗格中可以看到该地址下存放的数据。（图2-41）

技术分享