发新帖

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

[复制链接]
64529 27
0x1:
a,首先,看一下原APK和通过腾讯云应用加固后的文件相关变化
加固后的文件列表变化:
新增2个so文件:
libmain.so
libshell.so
修改:
AndroidManifest.xml
classes.dex
b, 用ApkTool反编译加固后的APK, 出现反编译不过去,错误日志如下:
1.通过下面日志能看出来是apktool解析AndroidManifest.xml时出错,注意下绿色划线的name=fasten,这里TX加固是利用android系统解析axml的一个特点来导致apktool反编译时,在解析AndroidManifest.xml时出错。
关于利用AndroidManifest.xml这块的技术点可以参考一下万抽抽大神的文章:http://www.cnblogs.com/wanyuanchun/p/4084292.html
2.下面来分析和修复AndroidManifest.xml
分析前,还是得先了解一下AndroidManifest.xml的二进制格式,可以参考下列文章:
AndroidManifest二进制文件格式分析 http://bbs.pediy.com/showthread.php?t=194206
辅助分析AndroidManifest.xml的二进制格式可以使用下面的:
AXML的010 Editor模板
利用axml模版在010Editor解析AndroidManifest.xml能看到,有一个属性结构的name成员的值是25, 该值指向是string的索引,同时也是res ID的索引。
属性结构:
String索引:
Res ID 索引:
为什么这样做,哈哈哈,我懒,所以直接截图引用万抽抽大神的解释:
嗯,属性结构的name成员的值是即是string索引,又是ResID索引,所以:
Name=25
String[25]=fasten
ResIDs[25]=0x01017FFF
再次引用抽抽大神文章里的一段话:
Android系统在解析AXML的属性的时候,是通过该属性的res id号而非属性名定位的。所谓的AXML就是AndroidManifest.xml对应的二进制文件,APK包中存储的就是AXML。比如属性:
<public type="attr" name="name" id="0x01010003" />
它的属性名为name,id号为0x01010003。
所以fasten这个字符串可以随意改,关键还是ResID的值,TX加固对AndroidManifest.xml处理,是插入一下非法的属性ID  (在Android的attr里没有一个ID为0x01017FFF),因为是非法的属性ID,Android是不会去解析,但ApkTool却会去解析,所以导致反编译出错了。
修复方法:
知道怎么回事,修复起来就很简单了,只要把非法的属性ID=0x0101FFFF改成一个合法的属性ID,比如把0x0101FFFF改成name的属性ID=0x01010003,然后再把修改后的AndroidManifest.xml再替换加固后apk里的AndroidManifest.xml,然后用apktook就可以顺利的成功的反编译出来。
附件有我用官网最新版的ApkTool 2.0.0 RC3源码编译,修改了一下,修复非法属性ID无法反编译。如果懒得手动去修改AndroidManifest.xml,可以直接用我这个修改过的apktool进行反编译。
反编译后,看加固修改后的AndroidManifest.xml和原版的AndroidManifest.xml多这三条:
1.  <service android:name="com.tencent.mm.fasten.check.log" />
2.  android:fasten="meta-data"
3.  <meta-data android:name="@anim/push_top_out2" android:value="meta-data" />
0x2:
a,ApkTool反编译可以成功,那接下来看一下TX加固是怎么对Dex进行加密的
1.  新增了2个smail文件
com\tencent\StubShell\ProxyShell.smali
com\tencent\StubShell\ ShellHelper.smali
2.  Smail代码的变化(对指定方法进行加密)
从截图能看到,加固后的dex,通过apktool反编译后的smali代码变化。
(1)
新增静态代码块:
(只要加载此类,就会先执行该代码块,作用是用来动态恢复被加固的方法)
.method static constructor <clinit>()V
    .locals 2
    .prologue
    const-string v0, "com.boco.nfc.activity"
    const/16 v1, 0x0
    invoke-static   {v0,v1},Lcom/tencent/StubShell/ShellHelper;->StartShell(Ljava/lang/String;I)Z
return-void
.end method
用JEB转成代码如下:
static {
        ShellHelper.StartShell("com.boco.nfc.activity", 0);
}
(2)
原始方法:
.method public constructor <init>(Landroid/content/Context;)V
改为native属性,并且隐藏字节码:
.method public native constructor <init>(Landroid/content/Context;)V
被加固后的Method数据:
从这里能看到关键是在StartShell函数,这个StartShell函数专门负责在执行时动态恢复被加固的方法,TX加固这种方式没办法直接通过dump来进行脱壳,它机制是需要运行到某个类,加载这个类时才会修复一下该类被加固的方法,但你又不能保证所有类你都能执行到,所以还是得找原始数据来进行修复dex。
public static boolean StartShell(String packageName, int iIndex)
从StartShell函数第二个参数iIndex来看,应该是要修复那个函数的编号。所以,可以猜测肯定会有一份原始的数据供给修复,所以从StartShell函数入手,就能找到修复的原始数据。

StartShell函数会先判断如果没有初始化过则执行InitProxyShell函数,InitProxyShell函数作用其实就是加载libshell.so, 最后,调用libshell.so的load(ShellHelper.strPackageName, iIndex);来进行修复,这里调用具体过程就不说了,哈哈,TX加固还有log可以看,方便大家理思路,大家想了解自己可以去看看,。
从这里能看到,关键是libshell.so的load函数在负责动态修复功能,下面就用IDA把libshell.so分析一下load函数。
(1) 看一下libshell.so的JNI_OnLoad函数
主要就是做一些初始化的时,看来没什么,我们直接主题,找load函数。
(2) Load函数在0xC630的偏移
ART模式下的修复就先不看了,有兴趣的朋友自己去看吧, libshell的代码流程再加上有log信息辅助,流程可以很清晰…
这里我大概说一下func_ShellFixDexMethod这个函数处理,详细的可以自己看下附件的libshell.idb吧。
1.  通过/proc/(getpid)/maps 打开自身进程的内存映射,查找classes.dex的内存地址。
2.  TX加固会把所有被加固过的Method的原始数据存一份在文件尾部。
定位Method的原始数据存放地址的方法:
原始数据偏移 = DexDataOff + DexDataSize
有多少个Method需要修复 = (DexFileSize – (DexDataOff + DexDataSize))/0x12
每一个Method方法的原始数据是用一个0x12大小的结构来保存的,结构如下:
typedef struct TXFixDexData
{
    DWORD dwClassDefItem; //Class_defs的索引id
    DWORD dwMethodIdx;    //DexMethod结构里的methodIdx值
    DWORD dwaccessFlags;  //DexMethod结构里的dwaccessFlags值
    DWORD dwDexCodeOff;   //DexMethod结构里的codeOff
    WORD  wProtoIdItem;  //proto_ids的索引id
}TXFixDexData;
3.  已经可以知道Method的原始数据,接下来就看怎么修复。关键就是要怎么定位到哪个Method是需要修复的。如果熟悉Dex结构的,应该就比较容易如何修复。
我的修复方法:先通过Class_defs的索引id(TXFixDexData->dwClassDefItem)定位到需要修复的Method所在的类,再取该类的所有Method,把每个Method的DexMethod->methoIdx值等于TXFixDexData->dwMethodIdx,就确定是需要修复的Method, 然后把该Method的DexMethod结构的accessFlags和codeOff修复就OK。
下面修复TX加固的classes.dex的工具, 附件有Bin和Src,代码比较挫,大伙将就看下思路就行了:
最后,把修复完的classes.dex放到apk,再反编译下,能看到被隐藏Method的代码回来了,但是还需要做一些扫尾的事,才能算完全脱壳成功。
1.搜索一下所有smali文件的下面这一句代码,然后全部替换为空:
invoke-static {v0, v1}, Lcom/tencent/StubShell/ShellHelper;->StartShell(Ljava/lang/String;I)Z
2.删除掉AndroidManifest.xml这三个地方:
a. <service android:name="com.tencent.mm.fasten.check.log" />
b. android:fasten="meta-data"
c.  <meta-data android:name="@anim/push_top_out2" android:value="meta-data" />
最后再重新打包APK,至此,脱壳完毕!
PS:写文档真累人,比分析脱壳还累,写到后面都不知道自己在写什么,文章比较乱成浆糊,可能也有一些东西没说到,见谅,因为我已晕死…
最后,提前预祝一下大家春节快乐!!!

相关附件下载地址: http://pan.baidu.com/s/1eQs3fZc

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
已有7人评分 NB 贡献 荣获致谢 理由
kesuki + 1 + 1 很给力!
图灵 + 1 + 1 很给力!
peterdocter + 2 + 2 + 1 期待下篇猛料...
单翅的天使ylj + 1 + 1 很给力!
sndncel + 1 + 1 赞一个!
世事繁华皆成空 + 1 + 1 很给力!
蝌蚪它大爷 + 1 + 1 很给力!

查看全部评分 总评分: NB +8  贡献 +2  荣获致谢 +7 

举报 使用道具

回复

精彩评论27

蝌蚪它大爷    发表于 2015-2-12 17:14:46 | 显示全部楼层
大神啊,太牛了,谢谢分享~

举报 使用道具

回复 支持 反对
testwg301    发表于 2015-2-12 17:16:10 | 显示全部楼层
绝对支持

举报 使用道具

回复
vVv一    发表于 2015-2-12 18:58:15 | 显示全部楼层
支持,给力啊!!

举报 使用道具

回复 支持 反对
sndncel    发表于 2015-2-12 20:43:58 | 显示全部楼层
谢谢分享。。。支持一下呀。哈哈。

举报 使用道具

回复 支持 反对
xin    发表于 2015-2-12 21:06:45 来自手机  | 显示全部楼层
先留个脚印,感谢分享!

举报 使用道具

回复 支持 反对
zpdiy08    发表于 2015-2-12 21:08:00 | 显示全部楼层
看得头昏眼花的,继续领会大神的精髓

举报 使用道具

回复 支持 反对
花墨    发表于 2015-2-12 21:18:10 | 显示全部楼层
紧跟大哥学习步伐

举报 使用道具

回复 支持 反对
5Up4Shit    发表于 2015-2-12 22:58:34 | 显示全部楼层
大神啊,膜拜,!!!

举报 使用道具

回复 支持 反对
单翅的天使ylj    发表于 2015-2-13 00:05:04 | 显示全部楼层
果断收藏

举报 使用道具

回复
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表