最近学了点ollvm相关的分析方法,正好之前朋友发我一个小demo拿来练练手.
看上去很简单 就是找flag用jadx打开发现加壳了
然后想试试直接用fridadexdump脱壳的时候发现frida上就崩了
上葫芦娃的strongfrida 直接重启了!....
这只能去过反调试了,打开so找了下.init和.initarray(反调试常见位置,so比较早的加载时机)
ctrl+s 打开 initarray里面有两个奇怪的函数 decode,这就是ollvm默认的字符串加密
导出函数中搜索init 找到里面也有函数定义,创建了一个线程执行反调试函数,进入这个函数看到字符串都被加密了
看了下代码 有个kill函数,一开始就行hook kill函数不让他自杀,发现没用...
然后我继续找了下发现有个strstr函数 这有点可疑,拿来比较字符串的,直接hook一波
从代码中得知str2是我们要关心的对象,是个char*类型直接readCstring打印
然后发现出现很多frida 然后进程就崩了
所以接下来就有两种方法 直接hook create_pthread不让这个线程程起来 和 hook strstr,我这就直接hook str了.
然后就不崩了,可以愉快的frida了~
先拖个壳,Fridadexdump一波(可以直接fart脱的全,但是懒的刷机,直接用这个了..),hook events定位
oncreate直接是native化了 应该是360的vmp, 这里肯定不是让你逆360的vmp,盲猜一波就是check方法,先hook一下.
直接返回false,应该是true就会拿到flag,为了不每次都手动输入 直接写个主动调用.
接下来去看so了,导出函数就这几个..肯定是动态注册,先直接hook
hook到了偏移,去so看一下
改了些名字后 操作流程就是将输入的jstring转为char* 然后判断长度是否为20看到很多都是unk_开头的,这些就是被ollvm加密后的字符串,要怎么看他解密后的内容呢?因为他加载到内存的时候肯定是解密状态,直接读这个地址打印cstring就可以得到解密后的字符串了.
然后继续改名,改完名字就是这样
发现他重新对check的方法进行了动态注册,然后sub_1234 里面也进行了动态注册里面嵌套了好几次动态注册,然后用strcmp比较 输入的值和 &unk_5100(解密后为kanxue) 如果相等那就返回true. 但是输入要20个字符 kanxue 只有6个字符,我们hook一下这个比较的地方看看,
直接hook strcmp蹦的比较厉害,我选择inlinehook,按tab切换到汇编,打开opcode,s1的值给到了R0 我选择在0x1564进行hook,因为是 2个opcode 所以为thumb指令,需要地址+1
我们输入了kanxue00000000000000,hexdump打印s1,发现s1就是kanxue,但是程序没提示通过,然后hook registernative hook到他又进行了2次动态注册,根据这个地址 我们往前找
发现第二次动态注册的和最开始的代码很像,第三次就短了很多,然后仔细一看第二次动态注册中又注册了sub_1148, 原来就是嵌套了3次动态注册,注册了3个函数,根据一开始的分析 对strcmp这里的字符串解密
然后inlinehook剩下几个分别strcmp验证下
发现第二次比较是输入的8个0 这样区分不了是第几个输入,我们用abcd来实验,输入kanxueabcdefghieklfn 20个字符
是abcdefgh 这8个,所以是加到kanxue后面的,然后真正的字符串之前我们已经解密了,是unk_50F7(即为training),然后后面猜也猜得到剩下6个字符是之前解密的unk_5096(即为course) 为了保证严谨性,我就在inlinehook一次
果然就是我们最后六位进行比较 所以答案前面的解密的字符合起来,就是 kanxuetrainingcourse
这里有个bug 每次输错都要重启一次,不然到最后答案就变成course或者trainingcourse了~
上传的附件：
2、找出flag.apk
(2.36MB，44次下载)
