熬了一个通宵解出题，手都还是抖的。趁热把解题思路理一下。
看到出题战队的队名是ArmVMP就有不妙的预感，因为平时安卓系统和arm架构接触的就少，arm下的VMP更是一无所知。但我也不是个轻言放弃的人，起码要试一下再放弃吧。
因为第四题也是安卓题，当时刚好新搭建了unidbg环境，这次便利用上了。但是这次运行很不理想，在调用GoodLuck函数时，unidbg反馈存在无法模拟的文件读写导致异常退出（此处忘记截图了，感兴趣的可以自己下载代码运行一下）。结合ida反汇编的情况来看，程序有可能加了壳。unidbg自带了一个elfUnpacker可以实现脱壳功能，奈何java和unidbg均不熟悉，一直调用不起来。最后干脆直接把elfUnpacker里dump内存的代码拷贝出来，在调用GoodLuck之后再直接dump整个模块内存（具体代码见附件）。经过比对分析，dump下来的模块和原模块基本没有区别，也就是说原模块并没有加壳。整个下午基本没有进展，算是白干了。。。
重头分析吧。在IDA里运行Findcrypt，可以发现DES的sbox，说明里面可能使用了des，但是没有找对对这个sbox的任何引用。

然后在文件开头处发现了几个函数，但同样构不成完整的流程链。 函数sub_344处有对unk_31B0的引用，该地址与sbox较为接近。函数sub_E60里F5后看到出现了明文字符串，疑似类似base64编解码的功能。跟随该函数的引用可以来到sub_1048和sub_12A0。如果对unidbg的输出还有印象的话，应该能想起来sub_1048是对java/lang/String等安卓函数的调用。而sub_12A0则比较有意思了，第一句代码居然是获取memset的位置然后向上搜索。将1179403647转成字符串后发现居然是'FLE\x7F'标记，也就是说这是一个搜索模块头的操作。

因为手头没有可以调试的真机，因此在分析的时候顺手搜索了一下arm安卓模拟器的搭建，按照上面的教程开始搭建调试环境。还好网速给力，虽然中间失败了好几次，但是总共将近30个G文件还是下载下来了（中间可能下载了很多不需要的文件，实际应该不用这么大）。
把Android Emulator运行起来后需要设置ida进行调试，同样网上有很多安卓逆向adb+IDA端口调试 教程（吐槽一下，有些居然还是VIP文章，点开看不了）。设置好之后便用作者提供的公开用户名及序列号（再吐槽一下，这个序列号是真长啊）测试一下吧。在调试状态下，点击“输入测试”显示错误，但是Detach之后却显示正确，显然内部进行了调试检测。但值得欣慰的是作者在检测后并没有使软件崩溃或者在取消调试后仍然使序列号失效，减少了不少重输序列号的麻烦。
通过对比较关注的sub_1048和sub_12A0的动态跟踪发现sub_E60果然是用于解密字符串的，而且解密操作也很简单，于是可以直接编写程序从so的相应位置中解密明文，如图。

这里比较关注几个cat开头的字符串，通过网上搜索安卓反调试可以知道这几天命令就是被检测出调试状态的关键。反写加密程序，用“Seccomp:”替换“TracerPid:”，用“cat /proc/1/maps”替换“cat /proc/%d/maps”，将修改后的so导入模拟器并重启apk，经测试程序并没有检测数据区的完整性，可以成功通过验证。
之后便是痛苦的跟踪分析，由于程序对代码段存在大量的校验，导致基本不能在未知区域下任何断点，而且ida还一直不能下硬件断点，所以所有的分析基本都是靠单步跟踪完成的。经过一个通宵和一个上午头晕脑胀的分析，终于把几个重要函数趟出来了。
sub_C2C函数应该是个hash函数，将用户名进行运算之后保存起来。sub_6A8一共会执行18次，但每次都是将固定数组（确认为密钥）进行扩展，最后确认该函数为DES中的UncheckedSetKey函数，该函数调用的sub_344即为RawSetKey。sub_788会使用二进制形式的serial和sub_6A8的扩展结果进行运算，得到的结果放入堆中，这个函数确认为RawProcessBlock。因此整个DES解密的过程就比较清晰了。
遗憾的是并没有找到最终序列号比较的地方，也没有研究出发现调试后是如何让最后结果显示错误的。就在我一步步理顺des解密的流程时，我发现解密还没开始，目标堆中的上方不远处就已经出现了解密应该出现的结果，显然这就是name在hash之后的最终形式。
取出KCTF的hash值456897A3292A7FD4F59073574602AED5，编写相应加密程序（貌似有DES加解密工具的话可以直接使用工具）加密，经过两轮printf操作后得到相应serial。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)