forked from Trietptm-on-Security/WooYun-2
-
Notifications
You must be signed in to change notification settings - Fork 7
/
Android应用方法隐藏及反调试技术浅析.html
214 lines (113 loc) · 122 KB
/
Android应用方法隐藏及反调试技术浅析.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
<html>
<head>
<title>Android应用方法隐藏及反调试技术浅析 - 猎豹科学院</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<h1>原文地址:<a href="http://drops.wooyun.org/tips/9471">http://drops.wooyun.org/tips/9471</a></h1>
<p>
<h1>0x00 前言</h1>
<hr />
<p>Android应用的加固和对抗不断升级，单纯的静态加固效果已无法满足需求，所以出现了隐藏方法加固，运行时动态恢复和反调试等方法来对抗，本文通过实例来分析有哪些对抗和反调试手段。</p>
<h1>0x01 对抗反编译</h1>
<hr />
<p>首先使用apktool进行反编译，发现该应用使用的加固方式会让apktool卡死，通过调试apktool源码（如何调试apktool可参见前文《Android应用资源文件格式解析与保护对抗研究》），发现解析时抛出异常，如下图：</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010040959651301.jpg" alt="" /></p>
<!--more-->
<p>根据异常信息可知是readSmallUint出错，调用者是getDebugInfo，查看源码如下：</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041001425412.jpg" alt="" /></p>
<p>可见其在计算该偏移处的uleb值时得到的结果小于0，从而抛出异常。 在前文《Android程序的反编译对抗研究》中介绍了DEX的文件格式，其中提到与DebugInfo相关的字段为DexCode结构的debugInfoOff字段。猜测应该是在此处做了手脚，在010editor中打开dex文件，运行模板DEXTemplate.bt，找到debugInfoOff字段。果然，该值被设置为了0xFEEEEEEE。</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041003353793.jpg" alt="" /></p>
<p>接下来修复就比较简单了，由于debugInfoOff一般情况下是无关紧要的字段，所以只要关闭异常就行了。</p>
<p>为了保险起见，在readSmallUint方法后面添加一个新方法readSmallUint_DebugInfo，复制readSmallUint的代码,if语句内result赋值为0并注释掉抛异常代码。</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041005543274.jpg" alt="" /></p>
<p>然后在getDebugInfo中调用readSmallUint_DebugInfo即可。</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041007141085.jpg" alt="" /></p>
<p>重新编译apktool，对apk进行反编译，一切正常。</p>
<p>然而以上只是开胃菜，虽然apktool可以正常反编译了，但查看反编译后的smali代码，发现所有的虚方法都是native方法，而且类的初始化方法<clinit>中开头多了2行代码，如下图：</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041009564806.jpg" alt="" /></p>
<p>其基本原理是在dex文件中隐藏虚方法，运行后在第一次加载类时通过在<clinit>方法（如果没有<clinit>方法，则会自动添加该方法）中调用ProxyApplication的init方法来恢复被隐藏的虚方法，其中字符串"aHcuaGVsbG93b3JsZC5NYWluQWN0aXZpdHk="是当前类名的base64编码。</p>
<p>ProxyApplication类只有2个方法，clinit和init，clinit主要是判断系统版本和架构，加载指定版本的so保护模块（X86或ARM）；而init方法也是native方法，调用时直接进入了so模块。</p>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041011376027.jpg" alt="" /></p>
<p>那么它是如何恢复被隐藏的方法的呢？这就要深入SO模块内部一探究竟了。</p>
<h1>0x02 动态调试so模块</h1>
<p>如何使用IDA调试android的SO模块，网上有很多教程，这里简单说明一下。</p>
<h2>1. 准备工作</h2>
<h3>1.1准备好模拟器并安装目标APP。</h3>
<h3>1.2 将IDA\dbgsrv\目录下的android_server复制到模拟器里，并赋予可执行权限。</h3>
<pre><code>adb push d:\IDA\dbgsrv\android_server /data/data/sv
adb shell chmod 755 /data/data/sv
</code></pre>
<h3>1.3 运行android_server，默认监听23946端口。</h3>
<pre><code>adb shell /data/data/sv
</code></pre>
<h3>1.4 端口转发。</h3>
<pre><code>adb forward tcp:23946 tcp:23946
</code></pre>
<h2>2 以调试模式启动APP，模拟器将出现等待调试器的对话框。</h2>
<pre><code>adb shell am start -D -n hw.helloworld/hw.helloworld.MainActivity
</code></pre>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041012229438.jpg" alt="" /></p>
<h2>3 启动IDA，打开debugger->attach->remote Armlinux/andoid debugger，设置hostname为localhost，port为23946，点击OK；然后选择要调试的APP并点击OK。</h2>
<p><img src="http://static.wooyun.org//drops/20151010/20151010041015332179.jpg" alt="" /></p>
<p>这时，正常状态下会断下来：</p>
<p><img src="http://static.wooyun.org//drops/20151010/201510100410172157810.jpg" alt="" /></p>
<p>然后设置在模块加载时中断：</p>
<p><img src="http://static.wooyun.org//drops/20151010/201510100410195709411.jpg" alt="" /></p>
<p>点击OK，按F9运行。</p>
<p>然后打开DDMS并执行以下命令，模拟器就会自动断下来：</p>
<p><code>jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700</code></p>
<p>（如果出现如下无法附加到目标VM的错误，可尝试端口8600）</p>
<p><img src="http://static.wooyun.org//drops/20151010/201510100410234563012.jpg" alt="" /></p>
<p>此时，可在IDA中正常下断点调试，这里我们断JNI_OnLoad和init函数。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004102522391132.png" alt="" /></p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004102621931142.png" alt="" /></p>
<p>由于IDA调试器还不够完善，单步调试的时候经常报错，最好先做一个内存快照，然后分析关键点的函数调用，在关键点下断而不是单步调试。</p>
<h1>0x03 反调试初探</h1>
<hr />
<p>一般反调试在JNI_OnLoad中执行，也有的是在INIT_ARRAY段和INIT段中早于JNI_OnLoad执行。可通过readelf工具查看INIT_ARRAY段和INIT段的信息，定位到对应代码进行分析。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004102858986152.png" alt="" /></p>
<p>INIT_ARRAY如下：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103098854162.png" alt="" /></p>
<p>其中函数sub_80407A88的代码如下，通过检测时间差来检测是否中间有被单步调试执行：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103188236172.png" alt="" /></p>
<p>sub_8040903C函数里就是脱壳了，首先读取/proc/self/maps找到自身模块基址，然后解析ELF文件格式，从程序头部表中找到类型为PT_LOAD，p_offset!=0的程序头部表项，并从该程序段末尾读取自定义的数组，该数组保存了被加密的代码的偏移和大小，然后逐项解密。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103290802181.png" alt="" /></p>
<p>函数check_com_android_reverse里检测是否加载了com.android.reverse，检测到则直接退出。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103484689192.png" alt="" /></p>
<p>JNI_OnLoad函数中有几个关键的函数调用：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103583220202.png" alt="" /></p>
<p>call_system_property_get检测手机上的一些硬件信息，判断是否在调试器中。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103717950212.png" alt="" /></p>
<p>checkProcStatus函数检测进程的状态，打开/proc/$PID/status，读取第6行得到TracerPid，发现被跟踪调试则直接退出。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004103869974223.png" alt="" /></p>
<p>通过命令行查询进程信息，一共有3个同名进程，创建顺序为33->415->430->431。其中415和431处于调试状态：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104051820231.png" alt="" /></p>
<p>进程415被进程405（即IDA的android_server）调试：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104164270241.png" alt="" /></p>
<p>进程431被其父进程430调试：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104350080251.png" alt="" /></p>
<p>要过这种反调试可在调用点直接修改跳转指令，让代码在检测到被调试后继续正常的执行路径，或者干脆nop掉整个函数即可。 检测调试之后，就是调用ptrace附加自身，防止其他进程再一次附加，起到反调试作用。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104484102262.png" alt="" /></p>
<p>修改跳转指令BNE（0xD1）为B(0xE0)，直接返回即可。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104554751272.png" alt="" /></p>
<p>当然，更加彻底的方法是修改android源码中bionic中的libc中的ptrace系统调用。检测到一个进程试图附加自身时直接返回0即可。</p>
<p>上面几处反调试点在检测到调试器后都直接调用exit()退出进程了，所以直接nop掉后按F9执行。然后就断在了init函数入口，顺利过掉反调试:</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104786789282.png" alt="" /></p>
<p>init函数在每个类加载的时候被调用，用于恢复当前类的被隐藏方法.首次调用时解密dex文件末尾的附加数据，得到事先保存的所有类的方法属性，然后根据传入的类名查找该类的被隐藏方法，并恢复对应属性字段。 执行完init函数，当前类的方法已经恢复了。然后转到dex文件的内存地址</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004104888122292.png" alt="" /></p>
<p>dump出dex文件，保存为dump.dex。</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004105031479301.png" alt="" /></p>
<h1>0x04 恢复隐藏方法</h1>
<hr />
<p>对比一下原始dex文件，发现dex文件末尾的附加数据被解密出来了：</p>
<p><img src="http://static.wooyun.org//drops/20151010/201510100410595472431.jpg" alt="" /></p>
<p>仔细分析一下附加数据的数据结构可以发现，它是一个数组，保存了所有类的所有方法的method_idx、access_flags、code_off、debug_info_off属性，解密后的这些属性都是uint类型的,如下图：</p>
<p><img src="http://static.wooyun.org//drops/20151010/201510100411015491232.jpg" alt="" /></p>
<p>其中黄色框里的就是MainActivity的各方法的属性，知道这些就可以修复dex文件，恢复出被隐藏的方法了。下图就是恢复后的MainActivity类：</p>
<p><img src="http://static.wooyun.org//drops/20151010/2015101004110333140331.png" alt="" /></p>
<h1>0x05 总结</h1>
<hr />
<p>以上就是通过实例分析展示出来的对抗和反调试手段。so模块中的反调试手段比较初级，可以非常简单的手工patch内存指令过掉，而隐藏方法的这种手段对art模式不兼容，不推荐使用这种方法加固应用。总的来说还是过于简单。预计未来通过虚拟机来加固应用将是一大发展方向。</p> </p>
</body>
</html>