百度脱壳的一点尝试--人肉修复

前言

近期把研究dex的脱壳,顺便又是再次熟悉了一下dex的标准格式以及dex被解析后在内存中所存在的格式。自己上官网加了一个壳子,发现跑不起来。于是求助几个基友,最后样本是海总给的apk,非常全面,带有Activity、Application、BroadcastReceiver、ContentProvider、以及Service。

0x1 加壳前后对照

这里写图片描写叙述

加固后的文件列表变化:
新增一个so文件以及一个jar包:
libbaiduprotect.so
baiduprotect.jar
改动:
META-INF目录
AndroidManifest.xml
Classes.dex

0x2 IDA尝试

用IDA来远程调试,直接跑挂了。看来有反调试。
从壳入口Java层找到例如以下语句:

 static {
        if(!Debug.isDebuggerConnected()) {
            String v0 = Build.CPU_ABI;
            if(v0 != null && (v0.startsWith("x86"))) {
                StubApplication.loadX86Library();
                return;
            }

            System.loadLibrary("baiduprotect");
        }
}

把第一个if删掉之后,程序顺利的载入了baiduprotect.so。顺利的进入了壳的领空。只是不知道是程序在so里面做了完整性校验还是再次检測了debuggerconnected,每次跑都是进入了一个死循环后,然后程序就跑挂了。跑了非常多次都是难以逃出那个trap。这个时候就比較纠结了。既然反调试过不去,想起360的壳子用DD也能够脱的非常完美。那就换个方式试试。

0x3 DD大法

dd if=/proc/PID/mem of=XX skip=0 ibs=1 count=LENGTH 
skip改成偏移地址
偏移地址 
cat /proc/pid/maps

1.这里首先要感谢下wbyang博士猛男,这个DD大法也是上次挑战赛之后向他学来的。程序跑起来,把内存都dump出来,大概是100多mb的东西。找几个字符串,然后向上翻。找到dex文件的头。发现是被抹掉的。如图:
这里写图片描写叙述
前面红色框的8字节是odex的magic头。后面的0x70字节是dex的头。除了一些size和编码标志没有被抹掉。其它的已经是面目全非,修复后例如以下:
这里写图片描写叙述
这下把dex文件抠出来了。
2.把dex反编译成smali文件
出现例如以下错误:

这里写图片描写叙述

重复检查后发现了例如以下是CodeItems以下的offset错误:
这里写图片描写叙述
Dex的文件大小才0xA30DC。而offset指向了外面的东西。

当然是无法解析的。这里我是有一个问题的,第三个偏移,这个0x0220E8E8,指向的是前面的内存。这是怎样做到的?我个人觉得是百度是在载入完毕之后有益改成这个数字的。若有错误。还望前辈不吝指正。


把这三个offset 都改成0就能够达到反编译成功,当然是在缺三个DataItem的前提下编译成功的。找到被抹掉的DataItem地址:
这里写图片描写叙述

以上三处为0的区域就是加固前的dex代码所存放的位置。


因此,如果我们能从dex的结构逆推出该三处的数据而且用应该的数据填充这块。静态就能把这个壳子搞定了。


3.怎样修复

360壳子要修复的数据为DataclassDef中的offset就可以。而百度的更为麻烦一些,不仅它的偏移须要修复一下,更为麻烦的是DataItem的数据也要修复。这个难度就更大了。


总的修复原则是导出函数表,然后按顺序来修复dex中被抹掉的数据,例如以下:
这里写图片描写叙述

逆计算出函数的uleb128的索引值、常见函数的一些accessflags、以及指向函数内容的offset。
修复后例如以下:
这里写图片描写叙述

修复的过程比較繁琐。有时候还须要自己尝试几次才知道size是多少。所以叫它人肉修复好了。
修复好了反编译如图
这里写图片描写叙述

发现onCreate函数没有代码,检查了一下,又有新发现!


这里写图片描写叙述

原来是oncreate中的insns[]也被抹掉了。

这个算是最主要的单位了。功力太弱。无法逆推。

最后总结下。百度的壳子须要修复dex头中的magic、签名值、校验值以及各个offset。还须要修复Dataclassoffset,以及Dataclass和opcodes。前两者是能够静态修复的,最后的仅仅能动态调试寻找了。百度壳子新增了一个oncreate001的函数,调用的壳中的d方法以及e方法,推測是d方法填充了insns[]解密数据,然后e方法为清洁工,抹去正确的数据或者是改成一些非法数据。此时就泪奔了。。

(心里暗想:百度好猥琐啊。。

。)

因为过去几天了,再次写文章又又一次做了一遍,把各种东西找好。写完花了将近三个小时,累觉不爱了。

。。

T T

因为水平有限,难免有错误。还望各位看官不吝指正。


2015.3.24 By Ericky

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Frida-dexdump是一款用于Android应用程序的工具。它基于Frida框架,可以在运行时动态地注入代码,从而实现对应用程序的监控和修改。通过使用Frida-dexdump,用户可以获取应用程序的dex文件,进而进行反编译和分析。这对于安全研究人员和逆向工程师来说是非常有用的。 ### 回答2: Frida-Dexdump是一种工具,它使用Frida库提供的动态注入技术来实现。它可以帮助安全研究人员分析Android应用程序中的可执行文件(dex文件),以便他们能够防止应用程序的非法复制或修改。 Frida-Dexdump的主要优点是它不需要修改目标应用程序的源代码,因为它是通过在应用程序运行时动态注入实现的。这个过程非常简单,只需要在设备中安装Frida-server,然后运行Frida-Dexdump即可。过程中,它会将dex文件从目标内存中复制到本地磁盘,然后对该文件进行解密、反编译和分析。 此外,Frida-Dexdump还提供了一些其他有用的功能,例如提取应用程序进程的内存信息和文件系统信息,以及可以监视应用程序的API调用、函数调用和网络请求等操作,有助于发现应用程序中的漏洞和安全问题。 总之,Frida-Dexdump是一种非常有用的工具,它给安全研究人员提供了一个方便而有效的方式,来分析Android应用程序中的DEX文件,并发现和解决其中的安全问题。但需要注意的是,在使用该工具时,需要严格遵守法律法规,不得将其用于非法用途。 ### 回答3: Frida-Dexdump是一款非常强大的工具,它是基于Frida框架开发的,能够帮助开发者轻松地从安卓应用程序中提取dex文件,帮助开发者进行逆向分析,加深对程序的理解。 Frida-Dexdump的主要功能是从本地已安装的应用程序中提取dex文件,并将其保存到本地文件系统中,使其方便地进行后续分析。这个工具不仅能够Native方法,还可以有效地防止抓包等应用安全风险。 使用Frida-Dexdump非常容易,只需要在Frida Server启动的情况下,通过命令行来启动即可。可以利用命令行参数去指定你需要的应用程序包名,然后Frida-Dexdump就会自动使用Frida去hook这个被指定的应用程序,并提取它的dex文件。 Frida-Dexdump采用了一种非常高效的技术,它能够轻松地解析目标程序的内存结构,获取有关dex文件的相关信息,并且还能够将提取的dex文件保存在指定的本地文件系统中,方便开发者进行后续分析。值得一提的是,Frida-Dexdump支持多种不同的目标程序,包括应用程序、Framework、动态库等。 总的来说,Frida-Dexdump是一款非常强大的工具,可以帮助开发者轻松地进行逆向分析,深入探究Android应用的内部机制。它的强大功能和高效性使其受到广泛的关注和使用,目前已经成为许多安卓开发者逆向工程的首选工具之一。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值