0%

腾讯应用加固的脱壳分析和修复

首先这篇文章是具体参考【原创】**应用加固的脱壳分析和修复,上文作者在今年2月12号发了一篇文章详细分析了整个过程,由于腾讯加固的技术也不断演进,所以我在上文的基础,分析现在7月份腾讯加固采用的新方法。与上文重复的部分就不再过多说明,所以阅读本文之前,要首先看懂上文的大致思路。

反编译apk

首先,看一下原apk和加固后的文件变化情况,主要是修改了AndroidManifest.xmlclasses.dex,以及新增了libmain.solibshell.so两个文件。
然后下载最新的Apktool的源码进行编译,得到apktool-cli.jar这个文件。然后直接进行反编译,如无意外的出错了。因为腾讯加固就是利用一些Apktool的bug来阻止反编译,但是又不影响安卓程序的加载。
第一个错误,是腾讯加固时添加了两个同名的ID,attr/fasten,导致反编译时出错。由于这些ID是腾讯加固添加进去的,对于程序没有影响,所以我在Apktool的做法是直接忽略这种同名的ID。其实这个问题是Apktool的bug导致的,我这种忽略的方法是治标不治本,如果这些ID在程序中是有用的就不能这样做了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Exception in thread "main" brut.androlib.AndrolibException: Multiple res specs: attr/fasten
at brut.androlib.res.data.ResType.addResSpec(ResType.java:70)
at brut.androlib.res.decoder.ARSCDecoder.readEntry(ARSCDecoder.java:221)
at brut.androlib.res.decoder.ARSCDecoder.readConfig(ARSCDecoder.java:191)
at brut.androlib.res.decoder.ARSCDecoder.readType(ARSCDecoder.java:159)
at brut.androlib.res.decoder.ARSCDecoder.readPackage(ARSCDecoder.java:116)
at brut.androlib.res.decoder.ARSCDecoder.readTable(ARSCDecoder.java:78)
at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:47)
at brut.androlib.res.AndrolibResources.getResPackagesFromApk(AndrolibResources.java:538)
at brut.androlib.res.AndrolibResources.loadMainPkg(AndrolibResources.java:63)
at brut.androlib.res.AndrolibResources.getResTable(AndrolibResources.java:55)
at brut.androlib.Androlib.getResTable(Androlib.java:64)
at brut.androlib.ApkDecoder.setTargetSdkVersion(ApkDecoder.java:209)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:92)
at brut.apktool.Main.cmdDecode(Main.java:165)
at brut.apktool.Main.main(Main.java:81)

第二个错误,是由于腾讯加固修改了DexCode里面的debugInfoOff,竟然把这个位置的偏移量置成0xFFFFFFFF。这在解析dex文件是肯定会显示invalid DEX,所以看下面的提示信息就是说读取offetout of range了,我的做法是忽略0xFFFFFFFF这种过大的偏移量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
org.jf.util.ExceptionWithContext: Encountered small uint that is out of range at offset 0xffb78
at org.jf.dexlib2.dexbacked.BaseDexBuffer.readSmallUint(BaseDexBuffer.java:54)
at org.jf.dexlib2.dexbacked.DexBackedMethodImplementation.getDebugInfo(DexBackedMethodImplementation.java:126)
at org.jf.dexlib2.dexbacked.DexBackedMethodImplementation.getDebugItems(DexBackedMethodImplementation.java:131)
at org.jf.baksmali.Adaptors.MethodDefinition.addDebugInfo(MethodDefinition.java:575)
at org.jf.baksmali.Adaptors.MethodDefinition.getMethodItems(MethodDefinition.java:377)
at org.jf.baksmali.Adaptors.MethodDefinition.writeTo(MethodDefinition.java:238)
at org.jf.baksmali.Adaptors.ClassDefinition.writeDirectMethods(ClassDefinition.java:283)
at org.jf.baksmali.Adaptors.ClassDefinition.writeTo(ClassDefinition.java:112)
at org.jf.baksmali.baksmali.disassembleClass(baksmali.java:226)
at org.jf.baksmali.baksmali.access$000(baksmali.java:56)
at org.jf.baksmali.baksmali$1.call(baksmali.java:150)
at org.jf.baksmali.baksmali$1.call(baksmali.java:148)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

第三个问题,也是由于debugInfoOff引起的,在创建debug结构体时,如果偏移量为0xFFFFFFFF,就看做偏移量为0x0。

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
java.lang.ArrayIndexOutOfBoundsException: -1
at org.jf.dexlib2.dexbacked.BaseDexReader.readBigUleb128(BaseDexReader.java:158)
at org.jf.dexlib2.dexbacked.util.DebugInfo$DebugInfoImpl.iterator(DebugInfo.java:104)
at org.jf.baksmali.Adaptors.MethodDefinition.addDebugInfo(MethodDefinition.java:575)
at org.jf.baksmali.Adaptors.MethodDefinition.getMethodItems(MethodDefinition.java:377)
at org.jf.baksmali.Adaptors.MethodDefinition.writeTo(MethodDefinition.java:238)
at org.jf.baksmali.Adaptors.ClassDefinition.writeDirectMethods(ClassDefinition.java:283)
at org.jf.baksmali.Adaptors.ClassDefinition.writeTo(ClassDefinition.java:112)
at org.jf.baksmali.baksmali.disassembleClass(baksmali.java:226)
at org.jf.baksmali.baksmali.access$000(baksmali.java:56)
at org.jf.baksmali.baksmali$1.call(baksmali.java:150)
at org.jf.baksmali.baksmali$1.call(baksmali.java:148)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

org.jf.util.ExceptionWithContext: -1
at org.jf.util.ExceptionWithContext.withContext(ExceptionWithContext.java:54)
at org.jf.baksmali.Adaptors.MethodDefinition.(MethodDefinition.java:161)
at org.jf.baksmali.Adaptors.ClassDefinition.writeDirectMethods(ClassDefinition.java:282)
at org.jf.baksmali.Adaptors.ClassDefinition.writeTo(ClassDefinition.java:112)
at org.jf.baksmali.baksmali.disassembleClass(baksmali.java:226)
at org.jf.baksmali.baksmali.access$000(baksmali.java:56)
at org.jf.baksmali.baksmali$1.call(baksmali.java:150)
at org.jf.baksmali.baksmali$1.call(baksmali.java:148)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at org.jf.dexlib2.dexbacked.BaseDexReader.skipUleb128(BaseDexReader.java:191)
at org.jf.dexlib2.dexbacked.util.DebugInfo$DebugInfoImpl.getParameterNames(DebugInfo.java:251)
at org.jf.dexlib2.dexbacked.util.DebugInfo$DebugInfoImpl.getParameterNames(DebugInfo.java:81)
at org.jf.dexlib2.dexbacked.DexBackedMethodImplementation.getParameterNames(DexBackedMethodImplementation.java:136)
at org.jf.dexlib2.dexbacked.DexBackedMethod.getParameterNames(DexBackedMethod.java:153)
at org.jf.dexlib2.dexbacked.DexBackedMethod$1.iterator(DexBackedMethod.java:131)
at java.util.AbstractCollection.toArray(AbstractCollection.java:137)
at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:258)
at org.jf.baksmali.Adaptors.MethodDefinition.(MethodDefinition.java:93)
... 10 more

如果大家懒得去修改Apktool源码,可以直接用我的apktool-cli.jar来进行反编译。

理解加固原理

反编译后发现,AndroidManifest.xml里面有些变动,多了一行,但是好像对这版本Apktool的反编译和编译没啥影响,所以就没有理会AndroidManifest.xml文件。

<serviceandroid:name="com.tencent.mm.fasten.check.log" />

然后明显看到新增了两个so,估计跟2月份的加固方法相差不大,这一点可以通过查看反编译后StubShell的smali代码证明。
但是有一点区别的是StubShell里面有三个smail文件ProxyShell.smaliShellHelper.smaliTxAppEntry.smali。之前只有两个,现在多了一个TxAppEntry.smali,脱壳时要把腾讯相应的smail删除干净。
而dex文件的隐藏方法并没有变动,可以用2月份原作者写的FixTXShellDex工具来恢复隐藏数据。我这里就不详细说明了。

具体的脱壳步骤

a.把加固的apk解压,对classes.dex文件用FixTXShellDex工具进行修复,然后把修复好的classes.dex放回去apk包中。
b.使用Apktool加载apktool-cli.jar进行反编译,得到把反编译的代码中如下语句的全部替换为空:

1
2
invoke-static {v0, v1},Lcom/tencent/StubShell/ShellHelper;->StartShell(Ljava/lang/String;I)Z
invoke-static {p0},Lcom/tencent/StubShell/TxAppEntry;->LoadResSo(Landroid/content/Context;)V

而且把该com/tencent/StubShell目录下的三个smali文件删除。把lib目录下的libmain.solibshell.so删除。
c.重新用Apktool打包APK,脱壳成功。收工。
Apktool的修改后的源码在我的github中。

后续更新


2015/07/30更新:竟然过了几天,腾讯又修改了一下Manifest.xml,把安卓application入口改成com.tencent.StubShell.TxAppEntry
然后下面增加一个meta-dataTxAppEntry,保存原来的程序入口。所以把原来的入口放回application中就好了。如下:

1
2
3
<application android:debuggable="true" android:icon="@drawable/ic\_launcher" android:label="@string/app\_name" android:name="com.tencent.StubShell.TxAppEntry" android:theme="@style/AppTheme">
<service android:name="com.tencent.mm.fasten.check.log"/>
<meta-data android:name="TxAppEntry" android:value="android.app.Application"/>