这题做出来的有点慢，主要是程序跑飞了都没有发现，一直在调试后面的DES函数去了。导致现在没有什么时间补WP。
比较喜欢这种用户名
/
序列号的题（那种特殊构造导致用户名KCTF走不同流程的除外），有标准的跟踪流程可以看到程序是如何从前到后跑通的。这道题在一开始就可以看到，程序在读取用户名和序列号之间存在一大片代码，可以判断程序使用用户名做了很多初始化工作。
sub_611E44是将用户名转换为数字，会出现多对一的映射，这倒不重要，多个用户名使用相同的序列号也是允许的。这个函数使用了
2
次，第一次生成的数字感觉是作为随机数的种子来用的，这个对于我们要求的固定用户名KCTF来说就是已知且固定的。第二次生成的数字就是需要用序列号解出来的目标，这里就感觉怪怪的，输入是
32
个字节字符串，就算必须能转成
16
字节数组，也远大于目标空间，完全存在多解的可能性。
还发现个加解密函数sub_40F9AF，当第三个参数为
0
或者
1
时，就会使用第一个个参数把第二个参数加密或者解密。既然这个函数功能是对称的，因此也没有分析的必要。
程序调用了
20
多次sub_5FE61E函数初始化了大量空间，然后使用sub_5F52E3分别把获得的数据加密保存起来，但是在输入序列号后，又使用sub_5F50E0将通过sub_403ACA转化后序列号依次解密还原，因此这个就是对称的加密和还原过程，也没有分析的必要。
根据输入的数据流分析，唯一可疑的就是sub_403ACA这个转化函数，它的目的就是需要把输入变成用户名加密后得到的一个固定值，只要我们得到它的逆函数，这道题就可以解了。
中间的调试过程很痛苦，特别是跑飞到了sub_5F52E3函数还不知道，浪费了很多时间。手头aes代码也没有，做前面ctf_app题用的cryptopp880库里的aes调试了之后发现居然没有用到sbox，只要重新搜索合适的aes库，经过比对后通过替换sbox、修改轮密钥、轮密钥加函数和InvShiftRows函数得到了变形的aes解密函数，然后编写逆函数ShiftRows获得变形的aes加密函数。
将目标要求的
914760739524BCD5
利用密钥
"40041A36A4B0C478"
加密得到flag：
8BCBB6979E174CB7ECAEACDA104522CA
。由于DES运算没有区分大小写，因此如果加密
914760739524BCd5
，可以得到另一个解
86211F038093FCF4EB34EDB51F43BF2C
。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
