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层代码，可以发现反调试函数在打开应用的那一刻便被执行完毕。后期程序既没有再次调用该函数也没有开新线程来检测。而我们偏偏就是在应用运行途中附加上去的，所以绕开了检测……
要是这个反调试能正常运行的话，这个题目其实会棘手不少。只能说出题人有心挖坑，但最终还是手下留情了（）