2015年0CTF一道安卓逆向,考察dump内存手法;

安装应用

安装应用看其逻辑,发现只有一个输入点和一个check按钮,随意输入点check,会弹窗错误;

反编译

使用jadx进行反编译应用,看其基本逻辑;

2098409763

java层的逻辑简单,将输入与从flag.txt文件中读取到的内容进行对比,一致则弹窗成功;

即flag.txt就是真正的flag?

提取flag.txt内容为:0ctf{Too_Simple_Sometimes_Naive!!!}

在onCreate()函数前加载了antidebug.so库文件,怀疑作者是在此动了手脚;

IDA打开so,发现了获取ptrace、hook、检查签名等敏感内容的函数;

一团乱看不懂,参考了师傅的WriteUp,发现是利用的DDMS来dump内存搜索flag;

dump HPROF file

由于应用已经开启android:debuggable=”true”,直接打开DDMS;

点击 dump HPROF file的按钮;

3027937854

会弹出保存文件;

2178333767

然后搜索关键字符串”0ctf“;

972582

发现还是flag.txt中的假flag,这时随便输入字符check后重新dump进行搜索;

1365421328

得到真实flag:0ctf{It’s_More_Than_Meets_The_Eye!}

猜想

在so文件中hook了read函数,将读取flag.txt的内容替换为真正flag;

IDA打开so文件,在函数中并没有发现JNI_Onload函数,打开Segmentation视图,找到.init_array段,双击进入发现调用了my_init函数;

3612529782

反编译函数,发现调用了j_hook()函数,参数为read;

3033484250

通过查看函数调用,发现;

1615844861

回到反编译apk的java代码中,发现正是利用了read函数读取flag.txt文件内容,猜想证实;

gdb

使用gdb也可以dump内存,参考

WP:http://www.purpleroc.com/MD/[email protected]_WriteUp.html

sakura师傅:http://eternalsakura13.com/2018/02/10/easyre