一、程序初分析
1、先ida反编译，结果如下
可见有明显的混淆，无法看清程序逻辑。
查看String，如动图所示，只发现程序中有用到socket、gettimeofday导入函数（怀疑是网络验证），其中还发现123456789等简单明文，怀疑是解密其他字符串用的秘钥。
。
2、尝试分析



这几个函数跟入，感觉混淆强度很大未发现有靠谱的线索。
二、unidbg调试解难局
1、模拟执行获得新思路。
由于这是一个未知程序，不敢贸然使用真机+fridahook+ida调试（其实我感觉Ida跑混淆或者有壳的很容易跑丢了，万一程序执行了问题代码，可能会被刷机掉），故拿出了unidbg进行调试：
①选定要调试的程序路径并建立arm64模拟器

②对socket导出表进行hook与wireshark抓包联合获得程序执行逻辑，证实进行网络校验，后由于校验不通过退出程序。
1、ida静态再分析。
找到connect导入表，按x进行交叉引用查看。
发现有两条分支：
①第一条分支sub_3E108

我们只需要关注第二个参数，得知与a1有关，向上追溯，按x交叉引用得到sub_3e01c.

继续追溯

继续追溯得到该函数
虽然这里是伪C，但是有过C开发可以立刻看出这里的突破点，这个就是sockaddr_in的sin_addr进行赋值。关注a1[2]。得知a1[2] = v2;
观察v2 = operator new(0x200078uLL);
sub_3AAD0(v2, a1);有理由猜想sub_3AAD0执行后对v2进行赋值，毕竟这个是伪c呀，而且还混淆了。跟进sub_3AAD0 。
sub_3aad0关键代码如图所示：
不过被加密了。

这里我突然想到了init_array这里是可以进行加入decode函数的，在程序一开始对bss段解密，也就是说静态看是密文，运行时是明文。
于是拿出unidbg，在main开头加断点

System.err.printf(String.valueOf(emulator.getMemory().pointer(module.base+0).dump(0xfc470,100)));
```

很不幸这个就是个127.0.0.1的，于是断定网络验证在分支2.
②第二条分支sub_424E4
ida刚一点击，就报错了
原因未知。（希望大佬留言解决我用的是ida7.5）
于是到直接不看伪C直接X交叉引用追溯。

F5查看

这里直接解数据得了sub_424E4这块绝对网络验证的返回值，返回值校验应该就在该函数不远处了。
直接追溯该函数，

到这里终于看到了曙光
ida给我做了个标识：nptr


这里我们有理由相信标注处就是校验代码
。

分析到了这里，程序全pj也就很是简单了，可以crack内存截取（mmap、process_vm_writev这类函数）修改或者网包修改或者其他一堆方法，我就不举例说明了。

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界