首先前排感谢我的老大,也是我的好哥们@mouse@smali
这是一款很老的壳了(4.4直接用hook opt的dexdump无法dump出。),是老大给的成长任务,花了不短的时间,终于搞定了,今天记录一下流程。
先反编译,发现smali中的方法体都是Nop了。继续看Java代码,找到很可疑加载dex的地方
OK,下面进入native层找答案
先过一下反调试,反调试代码在initarray
相关资料
调试init和init_array技巧(这个壳是在init_array初始化反调试的)
反调试在gnu_..._11中,通过bsdsignal反调试的
代码中是判断常量为-1的时候,直接bsd了,我改的方法是,直接改成比较-2.然后重新覆盖so,由于我的系统刷的是没有安装签名校验的。
另一个点是检测data/local/tmp下面是否有android_server 由于我名字之前就改掉了,后面调试的时候才知道有这个。
经过漫长的调试,最终定位关键代码
interface4函数
由于接下来的so是动态加载的,所以不能实时保存日志,所以强烈建议写一个ida脚本动态保存日志,方便我们继续分析
这个是我写的,idapython脚本,有用但是很丑,凑合着用,根本就是根据起始地址和结束地址,然后把中间的日志和地址对应,保存起来。
又是漫长的调试,进入下一个关键地方
可以看到到这边已经修复classdefdata了。
附一张修复前和修复后的图
修复前
修复后
下面就是要向6520792这个偏移地址写真正的classdefdata了
这里说下 dump后的dex不是标准的dex,所以要baksmali一下,然后再smali,就是标准的dex了
整体流程:
hook了4.4的opt函数,所以无法dump出dex
更改原来apk的classdef以及classdefdate,将真正的数据存到apk中,native层从apk中取真正的classdef替换老的。
然后后面的任务,是直接自动化脱一下,顺便提升一下自己写C的能力(我C语言太菜了)
首先,先确认hook的点,第一个要得到apk地址,第二个找到修复后的点.
OK,最终确认了方案,用inject+substrate
1、通过hook字符串比较函数,确定apk地址
2、通过最后的munmap函数,拿到修复后的点
我C代码写的太烂了,还请大家包涵。。
最终mycql.dex就是dump出的dex了
最后付一个样本
[公告]安全服务和外包项目请将项目需求发到看雪企服平台:https://qifu.kanxue.com
最后于 14小时前 被GitRoy编辑 ,原因: