拿到题目，果然如题目描述一样，有两个可执行程序。主程序的图标很眼熟有没有？
直接运行，起来一个控制台，控制台的窗口标题似乎出卖了自己，看路径及目录名，应该是RAR自解压格式，用winrar打开程序文件试试，果然如此。取回自解压的两个文件。

本来原主程序的图标明显就是pyinstaller打包的默认图标。自解压后的CM.exe文件没有图标了，还带了个aplib.dll动态库文件。

大概静态分析了下（感觉时间紧张，先大概看看，找重点），CM.exe实际上就是利用aplib.dll这个压缩引擎做了一个套子。

实际的pe文件在偏移0x8000处，压缩长度为0x28131，解压长度为0x42c00。

动态把此pe从内存中dump出来，果然又出现了熟悉的图标。看了下原CM.exe文件偏移0x42c00处，果然上面是00填充，后面就是数据了。把dump出来的0x42c00大小的pe文件覆盖原CM.exe的前0x42c00字节，运行，正常。
接着又大概静态看了下新的CM.exe文件，确认是pyinstaller打包的（前面的aplib压缩引擎是新版pyinstaller自带还是后加的就不知道了）。

直接拿出pyinstxtractor，准备解包。结果出错了，认不出打包数据。

始终感觉时间比较紧，没多想直接运行，内存搜索关键字，定位到主脚本的pyc所在，dump出来（前后多dump了点），掐头去尾，加上pyc头反编得到源文件CM.py，发现还需要CMpub和general模块。但是这两个的pyc在内存中没有定位到。

最终还是回到pyinstxtractor工具上，看了下源码：

在检查文件的magic时出错了，针对新旧版本打包数据，magic相对于文件尾的偏移不一样，于是检查CM.exe的文件尾数据，发现magic是存在且正确的，只不过文件尾多了4字节的数据DEADCODE（hex），所以magic有偏移就有问题了。删除多余字节，用pyinstxtractor再次解包：

主脚本在解包的根目录，文件名为CM，另外两个在PYZ-00.pyz_extracted目录下，文件名分别为CMpub.pyc和general.pyc。CM和内存dump出的一样，需要加16字节的文件头，而另两个pyc文件文件头需要增加4字节。改好后直接反编译成功，代码如下，CMpub.py只有RSA的公钥数据，就不贴了。

校验流程为：

从以上步骤可以看出，关键在第3步，第2步的编码无需关心。第3步中的计算全是rsa加密，如果求出私钥，那整个过程就可逆，可由预期用户名求出对应的序列号。
0-9的数字序列决定了rsa的密钥选取和rsa加密过程。0-9分别对应一组公钥，除此，在计算方法上，0对应的是大数按192bits分组（m,e,n都拆成192bits）进行rsa加密，1-9对应的是正常的rsa加密。

看了下n全是768bits，e也都比较大。768bits以现在的算力是可以分解的，但是时间上可能有点长何况去了第0组，还有1-9组。首先想到上factordb上试试，然而当天数据库维护。
于上是yafu，秒出1、2组（相对而言）：

然后就跑不动了。开始找各种分解攻击方法。分解列表如下：

特殊分解算法：

一般用途算法：

除此之外，还有些攻击手段，如:

等。

上面所说的大部分方法在yafu、msieve、ggnfs中都用到了，这三个中似乎也有些交叉。
一边软件跑，一边手动写脚本试，看着答案在不同方法中一点一点出现，感觉是不是作者是考察rsa攻击的各知识点，只是有些是用软件跑出来的，不知道考察的是什么。
第7、8组n存在公约数。大概代码如下：

第4组在Fermat's factorization method中出了，后来在研究各种工具过程中发现此方法在yafu中就有集成（针对第4组n真正是秒出），大概代码如下，出了第4组我就停了，计算时间太长：

第二天在factordb上查到第9组分解结果（这是作者传上去的？）。Yafu出了第6组。后面就不见动静了。
一边用软件重复跑，一边在研究其它的攻击手段。想到题目一再地说到成语接龙的自动机，抱着试一试的想法，跑了如下代码出了第5组，不能分解n，得不到d，但是能反解，想到了以前的一个题。。。：

第3组通过P+1方法跑出来了：

最后的9层结果是：

基本全出来了，序列号就好计算了，直接在原代码的基础上改了，有点乱，把有改动的部分贴出来。

似乎用户名计算出来的数字序列中5比较多，计算稍需要点时间：

虽然最后做出来了，但似乎没有完全get到作者的意图，预期的解题方法应该也不是这样，花费了大量的时间和算力，队友帮我了很多。

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