-
-
[原创]为什么没有人发贴,难道是隐藏了
-
发表于: 2015-1-26 19:00 3188
-
第一题:
略过吧
义弓么丸广之
义弓么丸广之
53 56 49 48 50 54
5 8 1 0 2 6
就是这些个东西
第二题:
用am -D启动App,然后继续在JNI_OnLoad下断点,一直跑,发现起了另一个线程,就跟那个线程跑,
后来在759afc58
4013E95C mov r7 0x25 改成 mov r7 0x1就可以过反调试了。
然后在Native的回调函数下断点,中间看到一个符号叫wojiushidaan,然后,看到内容了,
aiyou,bucuoo
第三题:
加了一个壳,只好从内存里dump了。
先修改androidmanifest.xml,把debuggable="true"加上,
把那个用来反zjdroid的receiver去掉
运行起zjdroid,可以查看到DexOrJar的地址,然后,再拿到DvmDex的里的memMap的地址,然后,dump出来就是一个odex,但是,发现这个odex不完整,很多class的class_data数据偏移超出文件大小了,经过一段时间的纠结后,发现这个偏移居然还是正确的,我多dump一些东西就行了,最后根据maps的内容,把多个模块一起dump出来后,就是完整的odex了。
用baksmali解出smali,再smali回dex,出了一些问题,一个个类排除,发现是dn类有问题,然后自己手写一个dn类的smali,就smali成完整的dex了,可以使用dex2jar+jd-gui看反编译的源码。
主要是收到what=0的Handler后,就说明成功了,密码判断的逻辑好像是b类里的run方法里吧。
然后再用apktool+eclipse来调试。(调试前要把isdebuggerconntect去掉,还要把onStop里的killProcess去掉才能调)
一点点跟进去,有很多陷阱,和很多垃圾代码,但一共有4个sendemptymessage(0),有很多乱七八糟的分支,后来看到了一个字符串解出good这个提示,就看到了希望,果然,后面它从注解里扣出一些字符串来跟输入的密码进行比较,然后进了最后一个sendemptymessage(0),后来就显示成功了。
第四题:
我拿到比较密码的入口函数地址了,但是那里的代码是混淆过的,我没有破出它的算法。
跟第三题很像,但多了20倍的垃圾代码,密码判断逻辑在f类run方法,然后又进入到了一个native函数,ali$a;->M$f(xxxx),然后又要过一次native的反调试,而且相应的so经过了加固,什么都看不到。
使用xposed注入了一个so,在这个so里,我把thread_create hook了,然后把反调试的线程过滤掉(我屏蔽了前三次的线程创建),就成功过了反调试,原理,就是平时写反调试时都需要有一个专门的线程去检测调试器的,然后我一次次地试出了第四题里的反调试线程。
在ida调试时,我在M$f的Method结构体nativefunc的位置下断点,执行到这里后就停了下来,但发现,这个东西居然是libdvm里的用于处理java方法的native方法(忘了名字了),不是so自己的方法,而且被调用无数遍(第四题里面有很多垃圾线程在跑),以致我没法跟进去。然后我看它的insns,居然还真的有8个字节的opcode存在。一个个dalvik字节码对比,发现狗屁不通的内容,只好导出,再baksmali,发现真是乱七八糟的东西。
这里我没搞懂他们是怎么搞出这个效果的。
然后,我又用xposed注入了一个so,在这个so里,我把java层的M$f函数hook了,然后,在我自己的hook回调函数里调用原本的java层M$f函数,并在ida调试跟踪CallVoidMethod的过程,跟踪到dvmCallMethod里面时,就进入到了真正的M$f代码了,地址是xxx2a0,把这个地址对应的模块数据导出成libmobisy.so文件,M$f的native函数地址偏移是562a0。
然后就进了入体力战中,我没有搞出来。
这里用ida的p功能在这个位置创建函数,然后再f5,就方便一些,其内容大概是一个根据v8来决定流程的函数。f5反编译代码有653行。比较完后就会调用Java层的SendEmptyMessage,我在中间乱改数据变量,但总是没有进入到正确的流程。期待大牛分享一下这段代码的分析方法。
略过吧
义弓么丸广之
义弓么丸广之
53 56 49 48 50 54
5 8 1 0 2 6
就是这些个东西
第二题:
用am -D启动App,然后继续在JNI_OnLoad下断点,一直跑,发现起了另一个线程,就跟那个线程跑,
后来在759afc58
4013E95C mov r7 0x25 改成 mov r7 0x1就可以过反调试了。
然后在Native的回调函数下断点,中间看到一个符号叫wojiushidaan,然后,看到内容了,
aiyou,bucuoo
第三题:
加了一个壳,只好从内存里dump了。
先修改androidmanifest.xml,把debuggable="true"加上,
把那个用来反zjdroid的receiver去掉
运行起zjdroid,可以查看到DexOrJar的地址,然后,再拿到DvmDex的里的memMap的地址,然后,dump出来就是一个odex,但是,发现这个odex不完整,很多class的class_data数据偏移超出文件大小了,经过一段时间的纠结后,发现这个偏移居然还是正确的,我多dump一些东西就行了,最后根据maps的内容,把多个模块一起dump出来后,就是完整的odex了。
用baksmali解出smali,再smali回dex,出了一些问题,一个个类排除,发现是dn类有问题,然后自己手写一个dn类的smali,就smali成完整的dex了,可以使用dex2jar+jd-gui看反编译的源码。
主要是收到what=0的Handler后,就说明成功了,密码判断的逻辑好像是b类里的run方法里吧。
然后再用apktool+eclipse来调试。(调试前要把isdebuggerconntect去掉,还要把onStop里的killProcess去掉才能调)
一点点跟进去,有很多陷阱,和很多垃圾代码,但一共有4个sendemptymessage(0),有很多乱七八糟的分支,后来看到了一个字符串解出good这个提示,就看到了希望,果然,后面它从注解里扣出一些字符串来跟输入的密码进行比较,然后进了最后一个sendemptymessage(0),后来就显示成功了。
第四题:
我拿到比较密码的入口函数地址了,但是那里的代码是混淆过的,我没有破出它的算法。
跟第三题很像,但多了20倍的垃圾代码,密码判断逻辑在f类run方法,然后又进入到了一个native函数,ali$a;->M$f(xxxx),然后又要过一次native的反调试,而且相应的so经过了加固,什么都看不到。
使用xposed注入了一个so,在这个so里,我把thread_create hook了,然后把反调试的线程过滤掉(我屏蔽了前三次的线程创建),就成功过了反调试,原理,就是平时写反调试时都需要有一个专门的线程去检测调试器的,然后我一次次地试出了第四题里的反调试线程。
在ida调试时,我在M$f的Method结构体nativefunc的位置下断点,执行到这里后就停了下来,但发现,这个东西居然是libdvm里的用于处理java方法的native方法(忘了名字了),不是so自己的方法,而且被调用无数遍(第四题里面有很多垃圾线程在跑),以致我没法跟进去。然后我看它的insns,居然还真的有8个字节的opcode存在。一个个dalvik字节码对比,发现狗屁不通的内容,只好导出,再baksmali,发现真是乱七八糟的东西。
这里我没搞懂他们是怎么搞出这个效果的。
然后,我又用xposed注入了一个so,在这个so里,我把java层的M$f函数hook了,然后,在我自己的hook回调函数里调用原本的java层M$f函数,并在ida调试跟踪CallVoidMethod的过程,跟踪到dvmCallMethod里面时,就进入到了真正的M$f代码了,地址是xxx2a0,把这个地址对应的模块数据导出成libmobisy.so文件,M$f的native函数地址偏移是562a0。
然后就进了入体力战中,我没有搞出来。
这里用ida的p功能在这个位置创建函数,然后再f5,就方便一些,其内容大概是一个根据v8来决定流程的函数。f5反编译代码有653行。比较完后就会调用Java层的SendEmptyMessage,我在中间乱改数据变量,但总是没有进入到正确的流程。期待大牛分享一下这段代码的分析方法。
[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)
赞赏
他的文章
- deodex android o的vdex文件 21370
- [原创][转帖]分享一个最好用的root方法,大家一起来捣鼓一下 5344
- 逆向修改手机内核,绕过反调试 56975
- 没有标题的水贴 5613
看原图
赞赏
雪币:
留言: