第一题：
略过吧
义弓么丸广之
义弓么丸广之
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，我在中间乱改数据变量，但总是没有进入到正确的流程。期待大牛分享一下这段代码的分析方法。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！