看雪 KCTF 2026，规则 5.1.1 Windows 方案一。

附件 cm.exe，SHA1：d1c8124c5964af1531c6e311328854a05ca40bca。

判胜条件：运行 cm.exe，输入序列号(Key) 回车，输出 verify success. 即通过。

先跑一下看看它要什么：

随便输个短的提示失败。试长一点的 88 位 hex：

也是失败。但能看出输入是 88 个十六进制字符，也就是说序列号是 44 字节的大数。这个长度有点意思——既不是常见 16/32，也不是任意长度，固定 44 字节多半是为了配合后面的固定串长度。

顺手 strings 看一眼，发现一句很关键的明文：

长度刚好 44 字符。基本可以确认：输入被某种变换成 44 字节，再映射成字符，和这句话 strcmp。这就是攻击入口——目标串已知，问题变成"怎么把这句话逆推回输入"。

把 cm.exe 拖进 IDA。x86 32-bit PE，没加壳，符号被 strip 但函数边界清晰。主校验函数大概这么几段（变量名我按位置重命名了）：

整个校验链有四道独立检查：XOR 和、checksum、RSA、strcmp。重点是它们之间不是线性依赖那么简单——RSA 只动后 16 字节，前 28 字节从输入到 lookup 一直没变。这个分工很关键，后面会用到。

到这里有几个点不能靠猜，必须动态确认：

这些都用 Frida 在校验点 dump 实际内存来定，不静态推导。

hook 主校验函数入口（只用 Interceptor.attach(module.base.add(offset)) hook 函数 entry，不 inline hook 任意地址——x86 上 inline hook 极易破坏相邻指令，这点吃过亏），在 onEnter 里读 ebp-0x470 处的 ArgList 缓冲，与 Python 端按大端拼出来的 int 对比。

结果：大端，正向。ArgList[0] 是输入 hex 的第 0 个字节。早先猜过反向，浪费了半小时。

给两组不同输入（比如 c1=0x11...11, c2=0x22...22），hook RSA 函数入口/出口，捕获 (c, m) 对。然后 Python 算两个方向：

实测：程序执行 m = c^e mod N。也就是说它把输入当密文，用公钥指数 e 去"解密"。这有点反直觉，但逆向题里很常见——出题人让你填的"序列号"其实是合法的密文。

所以逆运算是 c = m_required ^ d mod N，需要私钥 d。好在 N 是 128-bit，p/q 在反编译里能直接看到分解（出题人没藏，就放在常量区），d 一行 Python 算出来。

hook lookup 函数入口，for 循环跑 256 次，让程序自己把 in_byte = 0..255 全走一遍，onEnter 记 in，onLeave 记 out。得到完整的 256 → ASCII 映射表。

对目标串 "Welcome to KCTF2026! Come and give it a try." 每个字符反查 preimage，得到 required[0..43] 共 44 字节。这一步是整个题的锚点——有了 required 这 44 字节，剩下就是逆推输入怎么填才能让校验链各关都过。

hook RSA 函数，onEnter 记 ArgList[28..43] 的原值，onLeave 再读一次，看哪 16 字节变了。结果：覆盖 ArgList[28..43]，前 28 字节不动。

至此整个数据流彻底清楚：

由于 RSA 只动后 16 字节，前 28 字节在 XOR/checksum 之后直接进 lookup，所以：

back 就是输入的后 32 个 hex 应填的值。

这是最容易翻车的一步。XOR 和 checksum 是对整 44 字节算的，而我们刚刚通过 RSA 逆运算改了后 16 字节。万一新算出来的 back 让 XOR 和 ≠ 0x8F 或者 checksum ≠ 0xBEFF，就还要在 16 字节自由度里调整。

先把候选 key 整 44 字节拼出来，算一遍：

都自动满足。这其实是出题人的设计——RSA 那段 16 字节的自由度足够大，p/q 又是出题人选定的，让正确解恰好能凑齐 XOR 和 checksum。所以无需额外搜索，key 唯一确定。

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