运行apk，ida附加调试，程序会退出。
利用命令行kill -19 <pid>使程序暂停，此时ida可以正常附加
(PS:使用的测试环境禁用了ptrace的PTRACE_TRACEME，即当TRACEME时会直接返回-1，看log发现apk调用了4次ptrace(0,0,0,0)，都是返回-1)
通过libdvm.so -> gDvm -> userDexFiles哈希表查看加载的dex文件。发现加载了lib/armeabi/libmobisecy.so文件，作为Jar文件加载。
修改libmobisecy.so后缀，可以解压缩出classes.dex，反编译发现每个函数实际内容被隐藏。
这个情况，在之前ali CTF中出现过。修改了CodeOffset。
从调试的进程中，根据userDexFiles中libmobisecy.so项的DexOrJar结构，找到JarFile结构。
然后找到DvmDex，就能找到内存中的dex文件地址。将dex文件dump出来，大小0x3004。
可以发现，dump出来的dex文件，Class的method的CodeOff值为0x10E094附近
根据/proc/<pid>/maps查看内存映射。
这个问题我之前提出过，只要把CodeOff指向的内存跟Dex文件一起dump出来即可。
之前的CTF题目，是dex文件和Code在同一段内存中，直接dump出来即可。
这道题目把dex和code放在两个不连续的段中。
不连续部分dump的时候填充垃圾数据即可。
dump出来的dex修复了一下，就是把两处的annotations_off改成了0
然后baksmali在smali，可以得到正常的dex文件
分析dex文件代码
在class b extends TimerTask里面找到关键流程
v5 = new e().a(this.c);
输入通过e.a转换成字符
查看class e，可以看到.和_组合跟字母数字的对应关系
分析代码，找到关键内容
v0_6 = v5.substring(0, 2).hashCode();
if(v0_6 == 3618) {
if(v1_6[0] + v1_6[1] != 168) {
...
byte[] v5_1 = (e.class.getAnnotation(f.class).a() + a.class.getAnnotation(f.class).a()).getBytes();
PS:中间有个"good"，没啥子用
枚举hashcode，找到相加是168的，为“s5”
查看Annotation，分别为"7e"和"1p"
组合结果就是"s47e1p"，用class e中的.-表示，用空格分割就是答案
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
