VMP是当下最强的代码混淆，它的强度已无需再验证，而且目前并不存在成熟的开源的自动化的脱壳工具。

然而，很多恶意软件也采用了类似的代码混淆，这为安全研究人员分析恶意软件带来了巨大的困难，因此一个通用的自动化去混淆工具意义非凡。有一些探索性的研究项目，例如 VMProtect Devirtualization 和 SATURN - Software Deobfuscation Framework Based On LLVM 等，但是距离成熟的工具还有很大的距离。

如果不考虑副作用，那么代码逻辑本质是接受输入，对输入做计算和变换，最后输出结果，与数学上的函数并无二致。VMP保护虽然把控制流变得面目全非，但数据流作为运算逻辑的本质仍然是贯穿于程序中的（当然也有很多针对数据流的混淆(如不透明谓词、MBA等)，但与控制流还是相对独立的），因为无论代码如何混淆，原始程序的逻辑是不能被改变的。

最擅长数据流分析的工具是编译器。目前很多去混淆通用工具的研究项目，核心思想还是设法把被混淆的程序提升为 LLVM IR，然后利用编译器强大的数据流优化能力（主要是常量传播、活跃分析、死代码消除等）剥离大部分与核心逻辑无关的垃圾指令，同时引入SMT求解器处理某些数据流混淆。

不久前才刚知道SATURN这篇论文，感觉可行性是最高的，文章对设计思路的描述也相当详细，只可惜作者没有开源。
（计算机行业的技术整体上还是开放共享的，SATURN论文虽然没有开源，但是可以相信一定有人会按照论文的思路实现这个项目(例如当年Google提出了MapReduce但没有开源，于是有了后来的Hadoop)。另外如果某个技术成熟了，尽管会有一些人做闭源商业化创收，但一定也会有另一些人做开源共享(例如IDA是最强的反编译器，它是商业化的，而开源界也有Ghidra，虽然效果差了一些，但总是有的)（这是计算机行业的整体技术氛围，应该说目前互联网的很多基础设施都依赖于一些基础的开源项目，所以真正投入开源的人是最值得尊重的(开源困境：Log4j2 维护者发声：没有工资，还要挨骂！！)）

但是把代码混淆作为CTF题目考点来出的话，如果没有较为成熟的开源项目可以利用，个人感觉对攻击方是有些为难的。因为CTF的初衷是Hack for FUN，其次是技术交流。硬刚VMP的过程往往不太FUN，而从技术分享的角度看，此题的混淆强度4天时间如果从零开始写自动化工具基本也不大可能。
当然，防守方也许会考虑到攻击方有自己的私藏武器。但是如果思考一下这个问题可以发现，如果以SATURN论文的工作量作为参考，可以想象实现这样一个去混淆框架至少要全力投入数月（甚至考虑前期对VMProtect的逆向分析，时间周期会更长），经过不断的迭代才能有一些初步的效果，可能只有本职工作在此的人才能有足够的精力投入其中；而且，即使有了这样的工具，用来解题肯定也要做针对性适配，而这又是一个深坑：单凭一道题目搞清楚代码混淆方式就要花费大量时间，何况还要修改原有的工具，再重新测试，4天时间恐怕也不太现实。另外，考虑到计算机行业的技术开放程度，虽然业界最强的工具不一定开源，但基本上开源界总会有相同功能的工具，而且至少可以做到能用的程度（可以对比IDA和Ghidra）。但是现在似乎还没有发现高调售卖的商业化VMP去混淆工具，而且现有的几个开源的VMP去混淆工具效果还不是非常好。不过，随着时间发展，还有能够相信未来会出现成熟的工具的。
（其他CTF比赛也出现过以代码混淆作为考点的题目，不过题目为了考虑时限内的可解性（而不是为了单纯测试混淆的强度是否足够高到无人能解；如果真是这样的目的就应该搞付费悬赏，和SRC平台一样），强度往往被有意降低，重点在于展示思路，于是很好的兼顾了难度和技术交流）

不妨回顾下近几届KCTF所有以代码混淆为主要考点的题目，似乎没有一个人是真的靠自己写的自动化去混淆工具还原出原始逻辑进而解出题目的，基本上都是靠动态调试、trace跟踪、人为观察等方式，靠堆体力找出逻辑，而且，也没有任意一个出题人公开自己写的自动化去混淆工具，这样无论攻击方还是防守方，从技术交流的角度总感觉缺少了一点灵魂（p.s. 不过很多基于动态调试的解题方法也非常硬核而且能学到很多知识）。而且这种工具对安全行业具有颠覆性的意义，即使闭源高价售卖也是有巨大市场的）（此外，回想自己作为某比赛出题人时，负责人给的硬性要求就是必须自己以做题人的视角解一遍确保可解性和做题体验，而且对于代码混淆的使用有严格的限制，必须保证自己有合理的解法（比如，有成熟工具可利用，或者从零开始能在赛期内写出工具，或者有足够的线索提示能够完全绕开混淆）；而且到最后往往会发现，某些题目即使开源给做题者都不会降低难度）

所以，基于以上推理，只能合理假设既然用了VMP来出题，那么就默认了出题人是希望攻击方寻找捷径，而不是硬刚代码混淆，因为对于本题的混淆强度从零开始的话4天的时间基本上不可能写出自动化的工具。

回到本题，对本人来说正常做是不可能做出来了，也只能想一想其他的路。

根据公开的serial可知合法的serial长64字节，每个字符取值[0-9A-F]，实际上hexdecode后是32字节。
jadx逆向apk，发现java层什么都没有，只是把name和serial都传给so然后接受一个字符串并显示出来。

Android Studio 开一台 arm 架构的虚拟机，x64dbg 调试 qemu-system-armel.exe

输入正确的serial会提示"祝贺,闯关顺利"，输入错误的serial会提示"不对!再探再报"，而且从java层看到这两个字符串都是so返回的。

把这两个字符串utf8编码，在x64dbg里全内存搜索，只能找到一片内存。
保持name不变，改变输入的serial，观察附近内存的变换，发现以下区域：

观察到 0x2892A9CE580 处的 02 EB 会随着 serial 的变化而变化，而且错误的 serial 在此处的值都小于 0xEB02。

固定 name 为 KCTF，逐字节改变输入。每个字节有 16 种取值，找出使得 0x2892A9CE580 处的值最大的那种即为正确的输入。

剩下的就是体力活了，下面是花几个小时手动搞出来的表：

（做完才发现，其实每个字节尝试 1、2、4、8 四种情况就够了。如果某种情况使得 0x2892A9CE580 的值比输入取 0 时大，就加上这个值，否则不加）

（另外自动化也是有可能的：通过 adb shell input 控制输入，ReadProcessMemory 读取内存；但是评估了下手动的工作量，感觉几个小时能搞完，所以还是手动搞的）

（以及，第一次动手发现 Windows 上通过 ReadProcessMemory 读其他进程的内存竟然不需要权限。细思恐极，Windows上的恶意软件是不是随便读其他进程内存获取密码等敏感数据？）

题目的最终答案：

（p.s. 关于动态调试，这两天才知道内核的 eBPF uprobe 机制（从Linux 3.5就存在了）。通过这个机制可以跟踪用户态程序、在任意地址处停下、dump寄存器等(原理也是插入int 3指令，但不走ptrace(?)，应对反调试估计很有效)，值得发掘）

P.S. 发帖时竟然提示涉黄，要人工审核？好想知道是哪个词触发的问题，自己完全看不出来。

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