[GKCTF 2021]App-debug

WP

最近忙活很多事，很长时间没有认真刷题了，于是今天特训了一波。
正好遇到一道有点意思的题目，于是记录下来。谈不上WP，更多是记录一点做题的心路历程吧（）

安装，查看概况

用一个输入框判断是否符合flag，挺清楚的。

反编译

jeb打开

​ 可以看到，程序对flag检测的关键是check()方法，但是class文件里面并不存在算法内容。结合上面的loadlibrary，可以推测程序调用了native层即so文件中的方法。

​ 又因为check仅仅返回了一个bool值，所以我们没办法在java层通过hook得到flag。必须深入一层了。

拆包，静态分析

lib下面只有个v8a版本的so……但凡我的逆向机再老一点，这程序就铁定跑不起来了

函数窗口里面搜索check，很容易找到check方法的代码了

这里有不少陌生的函数，按顺序一个个深入分析太浪费时间，所以反过来找，从return v5开始分析改变返回值的函数，直接就能找到关键代码了。

是典型的tea加密。

delta、key、密文都齐全了，直接开始解密捏

这值好像不太对啊……
刚开始我以为是前面的函数对其进行了预处理，所以花了很长时间向前分析，结果发现根本没有任何效果。

没办法，上动态调试喽。

动调

ida上传server，adb端口转发，附加程序调试，一切顺利

并且在关键变量处全部加上监视，以免看漏。

果然有变化！可以对比一下静态分析下的数值

交叉引用，发现篡改数据的函数

这其实是一个反调试手法，程序通过检测treacerpid来判断自己是否在被调试。如果检测到没有被调试的话，会将key值换成真的key。

TreacerPid,可以直接理解为“跟踪本进程的进程的pid”，可通过"cat/{进程pid}/status"来查看。所以绕过方法也很简单，将其改为0即可。

将正确的值换上去之后，就可以正常解密了：

这里需要自行调整一下顺序

md5加密后即可

后话

于是又出现了一个新问题——我明明确实用了ida来附加调试，可为什么没有被检测到呢？

继续交叉引用，在这里可以看到，反调试函数的位置是在so文件加载的入口或者说初始化位置。

结合java层代码，可以发现反调试函数在打开应用的那一刻便被执行完毕。后期程序既没有再次调用该函数也没有开新线程来检测。而我们偏偏就是在应用运行途中附加上去的，所以绕开了检测……

要是这个反调试能正常运行的话，这个题目其实会棘手不少。只能说出题人有心挖坑，但最终还是手下留情了（）