由于网络上的素材大抵都是一、二级圆柱锥齿轮变速器机构的设计，没有像你林这样的自主命题+自选教材，思来想去，为了避免更多学弟学妹遁入淘门和拼门，遂开启此项目的开发计划。
如上，仍待补充
目前仅实现电动机的选择及带轮、齿轮的设计（待完善），可视化参数调整界面和整机相关功能仍在开发中，期待有dalao能issue纠错或补充
你可以通过向开发者提出申请来参与开发，或者直接向开发者提交补充文件等，你也可以通过issue提出合理建议，或纠正程序的错误。
交流群：NEFU_AutoMachanic(901252688)，验证回答github即可
项目链接：开罐即食
打开来，是一个FlareOn的3D模型：
看似没什么东西，所以我们要从程序里头找点跟这个模型相关的东西出来，有可能是一些色调和背景融为一体的东西，也有可能是内容删减啥的，etc……
但是且慢，我们先介绍一种逃课打法——NinjaRipper。这个东西可以直接dump出程序中的模型文件，其高版本在永劫无间的模型吧里经常出现。这边建议使用1.7.1的老版本，高版本提出来的东西要看起来比较麻烦。
你还需要下载Noesis，并且使用NinjaRipper相关的演示插件才能正常显示。正常来讲你会在dump出来的东西中得到flag：
但是，逃课打法要用，正儿八经的做法也要用，这样才算得上健全。
我们先来了解一下在题目使用的 DirectX 9 架构下的模型文件，具体内容可以参考mesh文件加载相关和DirectX开发相关，这里简单说明一下，一个DirectX模型文件当中的基本图元，也就是组成一个模型的基本单元都是三角形，而在导入模型的时候，都是先导入各个三角形的顶点坐标，然后当即开始绘制，这可能也是早期游戏模型大多都十分尖锐的原因。
而相关的模型参数其实涉及了大量的数学运算，最主要的就是坐标系和邻接矩阵的概念，所以，如果我们能找到模型的位置偏移相关的坐标数值，也就能找到模型的位置。
问题来了，这东西在程序中的哪里呢？我们把目光方向DirectX的D3DXMatrixTranslation函数，这玩意可以即刻生成一个模型对坐标系的平移量。具体格式如下：
D3DXMATRIX* D3DXMatrixTranslation(
_Inout_ D3DXMATRIX *pOut, // 存储矩阵的变量
_In_ FLOAT x, // 三维坐标
_In_ FLOAT y,
_In_ FLOAT z
);
估计就是这个导致了flag模型飞出窗口。于是乎我们直接IDA，启……什么也没有？
似乎是文件头格式的问题，那我们只能x32动调看内存了。不管它加了什么壳，运行到一定程度断住，转到正确地址时，总会把符号表给加载干净，我们在其中发现了一个诡异的Direct3DX库，其中就有我们需要的函数：
下断点找到调用它的位置：
导致flag消失的罪魁祸首找到了，出题人设置了一个巨大的x轴偏移，改成0便是：
但是实际运行起来，flag的模型还有飞速转动的问题。这时候我们就要找找另一个函数：D3DXMatrixRotationY，这玩意可以控制模型旋转，而这个demo在经过几次动调之后可以确定，它是通过暴力循环加载模型来实现旋转的效果（这也解释了它性能为什么这么低），因此，我们只需要把这里下个断点，问题迎刃而解：
（虽然有点不大清晰就是了）
看上去只是个很简单的下棋而已，谁知道跑了一下就不动了——
算了，如果这玩意其实是一个联机软件，那先看一下流量包里的交互吧：
似乎也只是本机跟远程AI的交互，但是每一个操作对应的Answers似乎都来自另外的IP。我们总结起来看一下（如下是我手搓的部分结果）：
车 c3->c6 127.150.96.223
马 g1->f3 127.252.212.90
卒 c2->c4 127.215.177.38
马 c7->d5 127.118.118.207
象 f1->e2 127.89.38.84
车 a1->g1 127.109.155.97
……
看着像一个只剩半截的棋谱，并且开头怎样还不清不楚，毕竟谁家好人车一开始从C3走。这下不得不逆了。先来看一眼UI：
qword_D118 = gtk_target_entry_new("x-chessblaster/move", 1LL, 0LL);
qword_D108 = gtk_target_list_new(qword_D118, 1LL);
v3 = gtk_application_new("com.flare-on.chessblaster", 0LL);
g_signal_connect_data(v3, "activate", sub_3AB0, 0LL, 0LL, 0LL);
type = g_application_get_type();
v5 = g_type_check_instance_cast(v3, type);
v6 = g_application_run(v5, a1, a2);
g_object_unref(v3);
return v6;
我们可以得知，前端使用的是GTK toolkit架构，并且，从sub_3AB0里得知，主要行为跟so库里的getAiName、getAiGreeting、getNextMove有关系。
其中最主要的是getNextMove，我们发现这玩意似乎在远程端读取某个IP上的操作码并进行识别：
strcat(dest, ".game-of-thrones.flare-on.com");
v9 = gethostbyname(dest);
if ( !v9 )
return 2LL;
v10 = *v9->h_addr_list;
if ( *v10 != 127 || (v10[3] & 1) != 0 || a1 != (v10[2] & 0xF) ) // 确认读取的ip开头是否为127，且结尾是否为偶数
return 2LL;
sleep(1u);
// 对操作进行某种不知名的二对一异或解密
byte_4060[2 * a1] = v10[1] ^ byte_2020[2 * a1];
byte_4060[2 * a1 + 1] = v10[1] ^ byte_2020[2 * a1 + 1];
// 解密结果存入byte_4060后在a1=14时输出
*(_DWORD *)a5 = (unsigned __int8)v10[2] >> 4;
*(_DWORD *)(a5 + 4) = (unsigned __int8)v10[3] >> 1;
strcpy((char *)(a5 + 8), off_4120[a1]);
return (unsigned __int8)v10[3] >> 7;
a1的作用在这里应该类似于循环变量，或者步数计数器之类的。跟到输出会发现，似乎拿4位IP的第二位解密出来的结果会逐个输出并存入byte_4060，并在最后一起输出，而byte_4060的末尾刚好就是@flare-on.com，也就是flag格式：
虽然不知道这么一解密会发生什么，但这么一看，原包中似乎有成堆的不合规IP，我们筛选过后只剩下这么多：
1 马 g1->f3 127.252.212.90
2 卒 c2->c4 127.215.177.38
3 象 f1->e2 127.89.38.84
4 象 c1->f4 127.217.37.102
5 象 c6->a8 127.49.59.14
6 卒 e2->e4 127.182.147.24
7 卒 e5->e6 127.200.76.108
8 后 d1->h5 127.99.253.122
9 象 f3->c6 127.25.74.92
10 象 f4->g3 127.108.24.10
11 卒 e4->e5 127.34.217.88
12 后 h5->f7 127.141.14.174
13 象 e2->f3 127.230.231.104
14 马 b1->c3 127.159.162.42
15 卒 d2->d4 127.53.176.56
看着清楚多了，不过要按顺序排布清楚似乎也不简单。不过，根据正常的国象逻辑，不管对方怎么走，我们总得先动能动的子，直到字符串产生能看的结果，比方说第一步肯定是先走第二行的卒。
能行！第一步是d2的卒的话，我们按照逻辑和解码的结果，一个个排下去……且慢，如果这玩意才15个步数，那最后的全排列就是15的阶乘，甚至使用深搜还能剪枝，我们直接写一个简单的爆破脚本：
#include <bits/stdc++.h>
using namespace std;
char ID_sec_list[] = {252, 215, 89, 217, 49, 182, 200, 99, 25, 108, 34, 141, 230, 159, 53};
bool ID_usable[15];
char data[] = {121, 90, 184, 188, 236, 211, 223, 221, 153, 165,
182, 172, 21, 54, 133, 141, 9, 8, 119, 82,
77, 113, 84, 125, 167, 167, 8, 22, 253, 215};
char word[35];
int check(int add, char c)
{
char c1 = data[add*2] ^ c, c2 = data[add*2+1] ^ c;
if(c1 > 32 && c1 < 128 && c2 > 32 && c2 < 128)
return 1;
return 0;
}
void dfs(int stp)
{
if (stp == 15){
printf("%s@flare-on.com\n",word);
return;
}
for(int i=0;i<15;i++){
if(ID_usable[i] == true && check(stp, ID_sec_list[i])){
ID_usable[i] = false;
word[stp*2] = data[stp*2] ^ ID_sec_list[i];
word[stp*2+1] = data[stp*2+1] ^ ID_sec_list[i];
dfs(stp+1);
word[stp*2] = word[stp*2+1] = 0;
ID_usable[i] = true;
}
}
}
int main()
{
freopen("output.txt","w",stdout);
memset(word, 0, sizeof(word));
memset(ID_usable, true, sizeof(ID_usable));
dfs(0);
return 0;
}
然后从中找到一个跟刚才的结果对的上，又看得过去的，就是flag了：
大概是去年年底，想着到春节应该还有一段比赛真空期，至少把FlareOn3的逆全刷一遍吧，结果一看除了签到题全是活
刚进die乱翻就看到了一个形似base64换表的东西——
那我们直接把另一边看起来很像数据的东西放进赛博厨子试试——
啊？
不过这种暴力猜测还是不可取，我们正儿八经地看看算法——
位运算，三份对四份，这特征b64没跑了，问题就出在密码表上。
很符合我对签到题的想象.jpg
上来给了咱一个内容物意义不明的doc文档，怀疑是什么被加密的文件，或者是RE里面塞misc啥的。但隔壁还有个exe，既然都逆向题了那肯定先看可执行文件——
虽然它运行时似乎会产生中间文件，但是不动调单步的话程序一下子就过去了，我们干脆拿x64dbg直接一步到胃——
但是无事发生。那就考虑换个思路，既然它不是自己产文件，那就直接创一个Briefcase文件夹，然后把doc放进去，为了防止扫的是绝对路径，干脆直接在桌面上也放一个——
还是无事发生。
这时候应该就是我们的理解问题了。我们再来看一遍程序——
byd我知道火绒为什么老是把你关小黑屋了，扫我硬件是吧？我直接进函数先把你硬件码掀了（比较在取硬件码之后，汇编也很好找，动调改完进1A94地址就是成了）——
然后快进到异或之后，函数会输出一组数据，想来就是之前那一串加密数据的明文——
接着步过到生成图片的位置，如果你亲手动调步过你会发现这玩意是存在你桌面上的Briefcase，那第一次取地址应该就是取的桌面的地址。不过这些都不重要，关键是这个图片写了什么——
虽然那个莫名其妙的doc是被加密的结果是真，然而RSA-4096就是纯纯误导，正儿八经的加密逻辑还得看回程序，然而，这也是最折磨的部分，因为你还得疯狂翻阅Windows相关加密函数的文档一个个对：
首先是sub_401180对传入的lpMem进行加密，经查表得为SHA1，结果存入hProv，顺带生成一个AES256的hKey——
然后加密结果在第二次扫文件的时候经过两轮加密，第一轮是sub_401770的MD5——
第二轮就显得比较迷惑，前面生成的又是AES的key，到这里表现出来的特征又像DES的分块加密，每次最多取到0x4000，再加上还有KP_BLOCKLEN的参数，这玩意又突然谜起来了。
虽然后来又突然发现前面MD5的时候其实把它的KP_MODE定义为了CRYPT_MODE_CBC（1）：
if ( CryptGetHashParam(phHash, 2u, (BYTE *)*a3, &v10, 0) )
{
if ( CryptSetKeyParam(*a1, 1u, *a3, 0) )
{
CryptDestroyHash(phHash);
return 1;
}
但不管这个key最后是用在AES还是DES上，不明了的地方就一个，大不了挨个试一遍。于是，整个解密逻辑大致就有了，还是跟之前一样用明文sha1完MD5当后续的key，然后解密AES和DES二选一（最后实际上确实是DES），代码参考Papaya的博客，对着逆出来的代码就是一顿照猫画虎——
#include <stdio.h>
#include <windef.h>
#include <windows.h>
#include <wincrypt.h>
int main()
{
char* filename = "businesspapers.doc";
char* str = "thosefilesreallytiedthefoldertogether";
BYTE md5_data[100] = {0};
DWORD md5_len = 16;
DWORD dwDataLen = 37;
BYTE pbData[4];
*(DWORD *)pbData = 1;
HCRYPTKEY phKey = 0;
HCRYPTPROV phProv = 0;
HCRYPTHASH phHash = 0;
DWORD NumberOfBytesRead=0;
HANDLE hFile = 0;
HANDLE hObject = 0;
BYTE lpBuffer[0x5000]={0};
int v18 = 0;
if (!CryptAcquireContextW(&phProv, 0, 0, 0x18u, 0)){
printf("ERR_ON_SHA1\n");
return 0;
}
// sub_401180
CryptCreateHash(phProv, 0x8004u, 0, 0, &phHash);
CryptHashData(phHash, (BYTE*)str, dwDataLen, 0);
CryptDeriveKey(phProv, 0x6610u, phHash, 1u, &phKey);
CryptDestroyHash(phHash);
// sub_401080
CryptSetKeyParam(phKey, 4u, pbData, 0);
// sub_401770
phHash = 0;
CryptCreateHash(phProv, 0x8003u, 0, 0, &phHash);
CryptHashData(phHash, (BYTE*)filename, strlen(filename), 0);
CryptGetHashParam(phHash, 2u, md5_data, &md5_len, 0);
if(!CryptSetKeyParam(phKey, 1u, md5_data, 0)){
printf("ERR_ON_MD5\n");
return 0;
}
CryptDestroyHash(phHash);
// sub_401500
hFile = CreateFile("Briefcase\\BusinessPapers.doc", 0x80000000, 3u, 0, 3u, 0x80u, 0);
if(hFile == (HANDLE)-1){
printf("ERR_ON_SCANNING_DOC\n");
return 0;
}
hObject = CreateFile("Briefcase\\output.txt", 0x40000004u, 3u, 0, 3u, 0x80u, 0);
if(hObject == (HANDLE)-1){
printf("ERR_ON_CONDUCTING_OUTPUT\n");
return 0;
}
while (ReadFile(hFile, lpBuffer,0x4000, &NumberOfBytesRead, 0)){
if ( NumberOfBytesRead < 0x4000) { v18 = 1;}
CryptDecrypt(phKey, 0, v18, 0, (BYTE *)lpBuffer, &NumberOfBytesRead);
//CryptEncrypt(phKey, 0, v18, 0, (BYTE *)lpBuffer, &NumberOfBytesRead, 0x4010);
WriteFile(hObject, lpBuffer, NumberOfBytesRead, &NumberOfBytesRead, 0);
if ( v18 )
break;
}
return 0;
}
最后随便拿个什么十六进制查看器一看，是个图片，改个后缀——
好家伙，拿个逆向的flag怎么跟做密码一样。
这玩意咋看咋像go：
但是无所谓，IDAGolangHelper会出手……
找不到模块数据？啥情况？kali打开看了才发现是golang7，太过古老。算了直接硬看汇编吧，这里还有一个小寄巧，库函数不多的时候可以通过查看出题人到底调用了什么，来推测出题人的意图。比方说，我们发现出题人调用了crypto_sha1_New和go_string_slice，跟过去看一眼：
sub_8049CFB调用了crypto_sha1_New，并且循环了三遍，想来是要对参数进行三次sha1了（话说回来怎么这B出题人这么喜欢sha1）：
mov dword ptr [ebp-0Ch], 0
cmp dword ptr [ebp-0Ch], 2
jle loc_8049D5E
……
call _crypto_sha1_New
……
add dword ptr [ebp-0Ch], 1
而这玩意唯一的调用点就是主函数，我们可以发现string_slice刚好就在前面：
与此同时，随便乱翻字符串的时候还发现了更前面调用的sub_8049F6D有一个诡异的字符集，对应着一个strings_ContainsAny，应该是用来检查密文或者原文的的字符是否在字符集里面。
mov ebx, offset aAbcdefghijklmn ;
mov esi, 22h ; '"'
……
push esi
push ebx
call _strings_ContainsAny
……
xor eax, 1
test al, al
jz short loc_8049FFD
并且前面在___go_int_to_string调用时调用的参数有[ebp-28h]，这玩意在main里面也出现过，那就权当是输入数据的长度为30吧——
sub_8049F6D:
lea eax, [ebp-28h]
sub esp, 8
push edi
push eax
call ___go_int_to_string
main_main:
cmp dword ptr [ebp-28h], 1Eh
setz al
test al, al
jz short loc_804A10D
在调用sub_8049F6D之后，切分字符串之前，传入的ecx还对这个长度除以过一次，之后作为切分的参数输了进去。
mov ecx, 6
cmp ecx, 0FFFFFFFFh
jnz short loc_804A1EE
……
mov eax, [ebp-28h]
cdq
idiv ecx
……
push ecx
所以合理推测，这玩意实际上是把一个长30的串拿去等分，每段长度为6（golang slices一般没有数量参数来着），然后拿去连着三次sha1，最后把得到的哈希值和程序里头的数据比对。
可问题又来了，我数据呢？
一种可能的思路是，你既然都打FlareOn了，它的flag格式肯定是邮箱，尾巴肯定是@flare-on.com，最后两个slice也解决了，数据也能找了，多好。可问题就在这里，静态环境下根本没法从IDA里面找到这些数据，那这些数据八成还要过一遍解密或者生成才能拿到手。
另一种办法肯定就是动调到指定位置拿到对应数据了。但是鉴于之前几道题目都动调的我头快飞了，故拿数据的方式肯定没这么粗暴。再加上golang7，这么古老的玩意，现在linux下载源都找不到库了，我也配不上来啊QAQ
还有一种方式是生啃汇编，当然效率肯定高不到哪去，因为解密逻辑在这里显得及其的迷幻：
sub_804A53B:
push ebp
……
push ecx
push 1CDh
push 1000h
push edx
push eax
call sub_8049EE7
sub_8049EE7:
mov eax, [ebp-10h]
cmp eax, [ebp+18h]
jl short loc_8049F10
loc_8049F10:
mov edx, [ebp-0Ch]
mov eax, [ebp+14h]
add eax, edx
cmp dword ptr [ebp+10h], 0FFFFFFFFh
jnz short loc_8049F26
loc_8049F26:
cmp dword ptr [ebp+10h], 0
jnz short loc_8049F3B
loc_8049F3B:
cdq
idiv dword ptr [ebp+10h]
mov ebx, edx
mov eax, ebx
mov [ebp-0Ch], eax
mov eax, [ebp-0Ch]
cdq
push edx
push eax
push dword ptr [ebp+8]
push offset unk_804CE40
call ___go_send_small
add esp, 10h
add dword ptr [ebp-10h], 1
byd，我在做这到这里的时候刚好在听脑浆炸裂少女，结果我自己脑子真的快炸了（笑
不过我突然想到一件事情，刚才入栈的第四个元素，也就是ebp-0xC，就是刚才push进来的0x1CD。这玩意在idiv取余之后每次还要加回来，再加上其他传进去的参数也可能是数据集的地址，以及push了一个意义不明的0x1000进来，这玩意可能就是在一个大小为0x1000的数据集里面找一个下标，给他驳到某个东西上组成哈希值。
哪里可能存在一个长度刚好为0x1000的数据集呢？在乱翻了一阵常量之后，我找到了unk_804BB80，这玩意完美满足条件。
算法上如果要胡诌一通也好说，那就可能是以一定基础下标为准，每次取出一个数然后加上0x1CD，然后越界了mod一个0x1000，直到组成一个sha1的哈希值，然后接着弄下一个哈希值。
只是没有动态调试的环境，我暂时没法亲自验证它的正确性（而且按理来说如果动调顺利，那么几个未知变量的问题也解决了）。而且，这么猜想的话，初始下标也是个问题，毕竟都爆破了，6个字符，就算情况固定，也得要O(m^6)的复杂度，大概有15亿种情况，你再多爆一个1000的变量，那电脑得先跟你爆了。
不对，好像不需要动态调试，也还有办法。记得刚才提到过尾巴是”@flare-on.com”，那我们只需要用上面一样的办法算出sha1，然后再用sha1值从尾到头逐字比对，寻找所有可能值然后记下偏移，就可以找出终位置和变化规律，然后从尾到头生成哈希值。
Mindaugas佬的题解至少从代码上看是这么干的，下面是我根据他的题解改的，py3以上也能用的爆破代码（毕竟题目还是py2时代的文物）——
import binascii
import hashlib
def trip_sha1(s):
return hashlib.sha1(hashlib.sha1((hashlib.sha1(s).digest())).digest()).hexdigest()
const = 0x1cd
current = 0x450 # 这个下标估计得人工确定
blob = [你提出来的0x1000大小的数据集]
hashes = [[], [], [], [], []]
for h in reversed(range(5)): # 从最后一个hash值及其终位置反过来推前面的
for b in range(20):
byte = blob[current]
current -= 0x1cd
if current < 0:
current += 0x1000
hashes[h] = [byte] + hashes[h] # 包括新加入的数据也是从前面插入
h_str = [binascii.hexlify(b''.join([chr(b).encode() for b in h])) for h in hashes]
alphabet = 'abcdefghijklmnopqrstuvwxyz@-._1234'
for c1 in alphabet: # 剩下的就是硬爆所有可能的六位字符，去找哈希值存在的那几个
for c2 in alphabet:
for c3 in alphabet:
for c4 in alphabet:
for c5 in alphabet:
for c6 in alphabet:
six = ''.join([c1, c2, c3, c4, c5, c6])
if trip_sha1(six.encode()).encode() in h_str:
print(six, trip_sha1(six))
（佬在题解里表示用这玩意他也爆了整整20min，何其恐怖的计算量，反正我跑了好一会没跑通，各位谁有超算的可以整一整，我是不想再折磨我的电脑了）
我就纳闷了，flareon你们怎么都喜欢玩这么抽象的底力题
一上来，pe32，想着应该不会有啥花活吧，但看FlareOn那尿性还真说不准。这一看果不其然，符号表里面的信息显示这道题表面的程序名和实际运行时符号表里的程序名好像是两个东西——
从die里看内含字符串还能看到debug信息，看来这玩意真的只是个被重命名的，从原程序extraspecial的pdb里扒出来的内存映射之类的东西吧。
但是这玩意有什么用呢？我们先分析一下程序：
也就是说，这鬼玩意的本体实际上是个哈希比对。我们理论上直接把这个简单哈希搬过来用就完事了：
import numpy
flare = 'FLARE On!'
between_c = ord('_')
hexlist = []
def cal(Str):
Sum = numpy.uint32(0)
for i in Str:
Sum = numpy.uint32(ord(i) + 37 * Sum)
return Sum
flag = ''
for i in range(26):
between_c += 1
for j in range(ord(' '), 127):
Str = chr(j) + chr(between_c) + flare
Sum = cal(Str)
if Sum == hexlist[i]:
flag += chr(j)
break
print(flag)
但是用上述代码中原装的数据是解不出东西的。那真正的数据呢？
我们回到刚才的代码，发现中间那段未知代码实际上有点像把v23的处理结果跟我们的数据串掉了个。而且，v23就是代码的十六进制中RSDS最后出现位置的后缀（因为没有break中间夹断），于是我们拉进Winhex看一眼：
好消息，我们有pdb文件的原始地址了。坏消息，我数据呢？
结果外网的题解简直是一个模子里刻出来的，都说地址有了，数据就有了。可是这道题就没给出啥额外信息，直到我乱翻github时看到了：
对啊，好像可以借由GUID去找对应PDB，然后再从对应PDB里面找我们要的数据。但是很遗憾，寻找了数个解决方案之后，它们在我的电脑环境下都行不通。
直到我在数次动调之后突然发现，这玩意好像没有正确的文件名是过不去start的检测的。那么，之前拿到的文件名应该能用得上了，重命名成extraspecial.exe试试——
哟西，能跑通，但是就是卡在了某个判定。那我们直接在x64dbg上大跨步动调到0x4027a0，也就是主函数的地址上（别问为什么不用ida，问就是寄，以及，很多地方需要动调的时候手动过，因为有反patch），接着看哪里是那个意义不明的形似加密和换表的东西，一遍给它过过去——
然而悲伤的事情发生了，这玩意似乎加了亿些异常分发和反调试，导致你反调试不是一个萝卜一个坑，而是你一个萝卜拔出来，地下还埋着几个土豆。然后从网上下了SharpOD，结果SharpOD也不好使，碰到反patch进程直接炸了。甚至我现在想截个图都得担心哪里会不会突然给我整炸了，哪里出个参数判断哪里出个Dispatch，boom，你进程没了。
出题人我XX你个X
看到了22级陈师傅的文章，只能说，非常好文章，使我的脑子旋转。
刚好在最近的DubheCTF的wp上看到同款黑蚊子多（什，随开始新一期青年大学习——
这玩意的原名非常简单粗暴，Windows 32-bit on Windows 64-bit。顾名思义，这玩意是64位windows系统内嵌的子系统，目的就是为了让你能够在64位上跑32位程序。
它的大概机理就是通过新建一个64位进程，并加载一堆运行32位程序必要的库，以及一些64位的动态链接库，其中主要包括：
· Wow64.dll，通往Windows NT内核的核心接口，它转换32位与64位调用，包括指针和调用栈操作。
· Wow64win.dll，为32位应用程序提供适当的入口点。
· Wow64cpu.dll，负责解决进程从32位切换到64位模式。
· Ntdll.dll，重要的Windows NT内核级文件。描述了windows本地NTAPI的接口。当Windows启动时，ntdll.dll就驻留在内存中特定的写保护区域，使别的程序无法占用这个内存区域。
通过加载一个类似于虚拟机一样的独立空间，并为32位进程提供与CPU的接口，WoW64得以实现32位进程在64位硬件上的兼容，以及与64位系统的隔离。详细内容可以参见博客园相关文章和Windows官方文档，本文不再赘述。
Windows是一个强大的操作系统。为了方便开发者，微软将进程中的每个线程都设置了一个独立的结构数据。这个结构体内存储着当前线程大量的信息。这个结构被称为TEB（线程环境块）。通过TEB结构内的成员属性向下扩展，可以得到很多线程信息。这其中还包含大量的未公开数据。
TEB结构的其中一个成员为PEB（进程环境块），顾名思义，这个结构中存储着整个进程的信息。通过对PEB中成员的向下扩展可以找到一个存储着该进程所有模块数据的链表。
也就是说，如果我们想要在调试中遍历整个进程所调用的模块，我们就得找到相对应的结构指针。由于PEB是TEB的子集，所以PEB的指针存在于TEB中，而TEB的指针又存储在段寄存器FS中。
一种简单的辨认方法是依靠前人的经验，fs:[0x18]存储着TEB结构指针，fs:[0x30]存储着PEB结构指针。另一种办法就是，x32dbg，启动（
而整个PEB的原理实际上就是一个巨大的SEH链（程序逆向就是一个巨大的SEH？），所以大致结构跟链表类似。PEB偏移为C处存储着LDR指针，它指向一个_PEB_LDR_DATA结构，整个表的排序方式存储在其中的，以_LIST_ENTRY结构体定义的ModuleList系变量中（例如InLoadOrderModuleList），而顾名思义，它们每个变量同时又都是表头。定义表头的_LIST_ENTRY结构体存在F(ront)link和B(ehind)link，分别指向链上的上一个和下一个节点，所以其实也不算单纯的SEH链，而是双向链表。
这个链表上的每一个元素实际上都存储在_LDR_DATA_TABLE_ENTRY结构体中，而为了维持链表_LDR_DATA_TABLE_ENTRY中又以_LIST_ENTRY定义了所有排序方式的ModuleLink，特别地，第一个_LDR_DATA_TABLE_ENTRY结构中_LIST_ENTRY的Blink指向 PEB_LDR_DATA中对应成员的Blink，最后一个_LDR_DATA_TABLE_ENTRY结构中的Flink指向 PEB_LDR_DATA 中对应的成员的Flink。所以这玩意不但是个双向链表，还是个双向连通环。
我们需要检索对应模块的时候，可以根据不同的排序方式选择不同表头，然后从这条序列中选出对应的元素。
Reebuf上的相关文章中明确提到过流程——
64位Windows判别进程的位依靠段寄存器CS，当CS=0x23时是32位，而CS=0x33时是64位。而“天堂之门”就是利用模式转换，在32位进程中返回64位模式，使得某处32位无法识别的64位代码，得以在64位的架构下解释并执行。
这里还用到了一个原理，32位的ret只会弹出栈顶的指令寄存器IP，以保证下一条要读取的指令，但是64位的retf还会同时弹出栈顶的CS寄存器。这俩寄存器相关的东西在博客园相关文章里有阐述，本文不再赘述。
一种典型的特征代码如下，这里的call不但是调用，同时也是压栈：
// convert x86 to x64
6A 33 push 0x33 ； cs寄存器的新值
E8 00 00 00 00 call $+5 ；push 下一条指令的地址入栈，并继续执行下一条指令
83 04 24 05 add dword [esp], 5 ；栈顶的返回地址加5，指向retf的下一条指令
CB retf ； 通过retf，程序返回到下一条指令继续执行，但cs 寄存器已经被修改为0x33， 执行的代码是64位
// convert x64 to x86
E8 00 00 00 00 call $+5
C7 44 24 04 23 00 00 00 mov dword [rsp + 4], 0x23
83 04 24 0D add dword [rsp], 0xD
CB retf
——摘自y0hv2y的文章
虽然但是，部分天堂之门也会用到或写入上述PEB理论里涉及的某些64位库，而非直接硬写64位代码，而这都是后话了。
这种办法适用于你对整个程序的结构有一定理解，且天堂之门埋的一整个64位代码块比较完整，能够直接扒下来，而不是分散在数个地址。关于如何建构程序可以自搜教程，这里放一个CSDN上的文章以供参考。
顺带，如果你真的想硬修也不是不行，就是记得把调用链看清楚了，然后再把jmp和call啥的给改到位了，并且在手搓的主函数里添加适当的调用。
如果你的可执行文件后缀是exe，恭喜你，Windbg可以直接连接Windows内核进行调试，你只需要打开你的Windbg：
接入你的内核，再打开你的程序attach上：
恭喜你，天堂之门对你仿佛没有作用一样，你可以免除IDA的虚拟内核切换不了位数的困扰，安心逆向了！
这方面我也还在学，要么你可以结合以下要讲的题目食用TLSN的文章或Taardis的文章，要么就直接搜Unicorn使用教程，总而言之，这个贵物可以直接hook指令或地址，直达目的，达到反混淆的效果。
如果你只会使用IDA，或者对IDA有某些特别的感情（比如我），那么这种办法可能就比较适合你了。
这个办法其实还是从程序里扒代码，但是我们可以使用一些别的奇技淫巧来获得函数的位置。一种还是需要结合Windbg内核态调试的trace来寻找x64代码块的起终点，但评价是都这样了为什么不直接用Windbg调呢？
另一种就相对比较复杂，参考Sachiel的文章。直接用64位模式启动，然后在动态调试的时候，先在天堂之门入口点下断，然后在Segment段找到你的进程，或者正在运行中的debugger——
然后，Edit Segment，把所有相关的东西，包括数据段和代码段全部切换为64位模式——
确定完地址之后，把入口点代码段重新Analyze selected area一遍，你在理论上是可以看到一个正常的远跳和CS寄存器变更的。但是这种办法本人在实际上是没试通的，各位可以尝试一波。
用IDA脚本动态扒内存下来，然后放到64位模式里直接看，没有必要管破碎的代码块的链接是怎么影响程序的正常运行的。关于如何扒代码可以自搜，这里的链接仅供参考。一种可行的代码模板如下（注意下列代码必须在动调环境下运行，以正确dump内存）：
-----IDAC-----
static main()
{
auto i ,fp;
fp = fopen("[文件地址]","wb");
auto start = [代码起始地址];
auto size = [代码块大小];
for(i=start;i<start+size;i++)
fputc(Byte(i),fp);
fp.close();
}
-----IDApython-----
import idaapi
start_address = [代码起始地址]
data_length = [代码块大小]
data = idaapi.dbg_read_memory(start_address , data_length)
fp = open('[文件地址]', 'wb')
fp.write(data)
fp.close()
回显过于简单，拿不到有用信息，我们直接看程序，Flag格式类似SangFor{……}，长度0x29，如图能看到类似天堂之门的调用结束段，后面跟着的函数返回值为1为成功：
call只是个伪装成调用的jmp，跳到出口的位置，则前面的jmp必定是某处天堂之门的入口。关于jmp对IP和CS寄存器的修改，可以查阅这篇文章。总之，我们发现jmp far ptr dword_405640指令实际更改的IP偏移应该是0x5310，而将CS改为了0x33，天堂之门入口没跑了。而0x405310就是call的位置，你在windbg之类能够接入内核的软件里头能看得更清楚：
看结构，输入存储在偏移为0x701D的位置：
合理怀疑另一个push的偏移0x705C是密文或者key之类，但是经windbg动调结果，除了第一遍还没分析出代码过程之后，这玩意总是在还没调进去的时候就突然进ntdll然后terminate了。IDA动调的时候更加干脆，直接给你卡在32位虚拟CPU动弹不得，模式都没得改。
算了，一不做二不休，构造一个41位用0填充的输入，从偏移0x1010处开始trace，暴力调试后找到的和原文所在地址+flag头偏移=0x7025相关，并且有用的代码如下——
---about rsi---
---b6326d---
cmp byte ptr [rsi],30h ds:00000000`00b67025=30
jb OddCode+0x3221 (00000000`00b63221) [br=0]
call OddCode+0x3210 (00000000`00b63210)
---if number b63214---
cmp byte ptr [rsi],30h ds:00000000`00b67025=30
jb OddCode+0x3221 (00000000`00b63221) [br=0]
add rsp,8
cmp byte ptr [rsi],39h ds:00000000`00b67025=30
ja OddCode+0x3221 (00000000`00b63221) [br=0]
mov al,byte ptr [rsi] ds:00000000`00b67025=30
sub rax,30h
---if A to Z 23327d---
cmp byte ptr [rsi],41h ds:00000000`00237025=41
jb OddCode+0x361d (00000000`0023361d) [br=0]
cmp byte ptr [rsi],46h ds:00000000`00237025=41
ja OddCode+0x361d (00000000`0023361d) [br=0]
……
sub rax,41h
---about rsi+1---
cmp byte ptr [rsi+1],30h ds:00000000`00b67026=30
jb OddCode+0x2fc5 (00000000`00b62fc5) [br=0]
cmp byte ptr [rsi+1],39h ds:00000000`00b67026=30
ja OddCode+0x2fc5 (00000000`00b62fc5) [br=0]
mov bl,byte ptr [rsi+1] ds:00000000`00b67026=30
---summary for al and bl---
shl al,4
or bl,al
似乎到这里的逻辑是先检查字符是否在数字或’A’到’F’的区间，对每一个字符进行减去’0’或’A’的运算后，再对每两位做(a[i]<<4)|a[i+1]的运算。接着看密文/key的位置0x705C相关的代码：
---233a3a---
lea rcx,[rdx+rcx]
mov al,byte ptr [rcx] ds:00000000`0023705c=90
xor rcx,rcx
我们发现在这之后，少数提到读取了另一个参数的al寄存器的非模块代码段就只有这一段：
---2338e5---
xor bl,cl
cmp al,bl
看来另一个参数是密文没错了。应当是把密文与加密后的原文进行比对。参与其中的bl寄存器应该是存储原文的，和前面对上了。除此之外，前面还有个指令：
---234a30---
ror bl,cl
经过动调，cl并没有明确的将其它变量的值赋予其的指令，不出意外加密算法是没key了。动态调试，第一次在234a30的cl是3，第二次在2338e5的cl是0x64。这就意味着原文在经历一定变换后是先循环右移三位再异或0x64的。虽然但是，再结合密文的数据，其实已经可以开爆了……且慢。
在实际操作的时候，一直输出不了结果。后来动调一看寄存器才发现，整个计算过程实际上并不是单纯的暴力删减，而是将它们化为对应的十六进制数。这似乎也解释了为什么字母只取A到F而不是A到Z。
这样甚至只剩下最后的加密过程了。开搞！
#include <bits/stdc++.h>
using namespace std;
unsigned char enc[] = {0x90, 0xF0, 0x70, 0x7C, 0x52, 0x05, 0x91, 0x90, 0xAA, 0xDA, 0x8F, 0xFA, 0x7B, 0xBC, 0x79, 0x4D};
int main()
{
printf("Sangfor{");
for(int i=0;i<16;i++){
unsigned char tmp = enc[i]^0x64;
printf("%02X",((tmp&0xE0)>>5) + ((tmp&0x1F)<<3));
}
printf("}\n");
return 0;
}
女子，接下来就是交flag——
纳尼！！！
不过接下来的部分就是动态调试了，大不了Windbg再trace几遍，找到错误的位置直接改成小写，flag如下：
SangFor{A7A4A0C0B10Bafa776F55FF4F8C6E849}
如图，天堂之门标志位，实际跳转地址偏移0x1258：
Windbg用ta命令，从偏移0x1258开始trace，代码块从0x1258的call跳到偏移0x27a50之后，一直跑到偏移0x27c5f（其实用IDA切代码位数尝试一遍了，但最后都只能得到错误的指令，不知道为什么）。直接用IDA脚本把东西扒下来：
import idaapi
import idaapi
start_address = 0x427a50
data_length = 0x20f
data = idaapi.dbg_read_memory(start_address , data_length)
fp = open('D:\比赛\月饼杯2\data', 'wb')
fp.write(data)
fp.close()
然后你就能看到一个非常标致的tea：
顺带，以下有个cmp部分，密文在偏移0x27A30处：
loc_40127F:
cmp dword ptr [ebp-30h], 8
jge loc_401391
mov eax, [ebp-30h]
mov ecx, [ebp-30h]
mov edx, [ebp+eax*4-20h]
cmp edx, dword_427A30[ecx*4]
jz loc_40138C
于是我们就可以直接写exp了：
#include <bits/stdc++.h>
using namespace std;
int key[8] = {0x66, 0x6C, 0x61, 0x67, 0x69, 0x73, 0x6D, 0x65};
int a1[8] = {0xB5ABA743, 0x4C5B3EE0, 0xB70AEB14, 0x6946BC13, 0x906089C4, 0x5B9F98F0, 0x0964B652, 0x78920976};
int main()
{
int sum = 32 * 0x88481145; // 会显示其它数字是ida的锅
for(int i=0;i<32;i++){
a1[7] -= (((a1[0] << 4) ^ (a1[0] >> 5)) + a1[0]) ^ (key[sum&7] + sum);
for(int k=6;k>=0;k--)
a1[k] -= (((a1[k+1] << 4) ^ (a1[k+1] >> 5)) + a1[k+1]) ^ (key[sum&7] + sum);
sum -= 0x88481145;
}
for(int i=0;i<=7;i++)
printf("%x\n",a1[i]);
return 0;
}
Tea_12345_12345_yes_flag_is_easy
死去的题目在攻击我.jpg
当初看Nep里的佬的复现看得云里雾里，现在发觉这玩意就是送，果然还是我太菜了
因为这里缺运行库所以看不到回显，但是代码还是能勉强看看的——
看你姨母，这玩意因为某些编译错误根本没法f5，不过看了一圈调用函数之后，sub_401120倒是挺让人在意的，进去看一眼：
dword_407050 = VirtualAlloc(0, Size + 6, 0x3000u, 0x40u);
dword_407000 = (int)dword_407050;
memcpy(dword_407050, retaddr, Size);
v2 = (char *)dword_407050 + Size;
*v2 = 0xE9;
*(_DWORD *)(v2 + 1) = &retaddr[Size] - v2 - 5;
v2[5] = 0xCC;
*retaddr = 0xEA;
*(_DWORD *)(retaddr + 1) = a2;
*(_WORD *)(retaddr + 5) = 0x33;
return 0;
我涅码，这天堂之门写脸上了，而且忽略掉前面的int3中断（0xCC）看Return Address上写的东西，EA XX XX XX XX 33 00，这不就是一个标准的jmp far开天门吗？但是它在return之前写入这条指令的地址呢？
注意看前面有着几次push：
然而sub_401620压到函数栈的只有一个参数，f5完也是如此，基本可以确定这玩意就是套皮scanf：
那么接下来，push的size是7，a2是unk_4011D0地址上的东西，也就是0x48B4865，怎么想都不对。故动态调试，得到两次调用偏移分别为0x11D0和0x1290，查看调用链之后发现可能还有一次模式转换，调用了0x40700C上的地址0x401200（00 12 40 00 33 00）。
自此，我们得到了所有代码块的地址，顺序是0x11D0，0x1200和0x1290，并且输入是0x7060，中间对输入还有一次操作，应当就是加密的一大部分。并且它们刚好连在了一块。于是我们直接dump：
import idaapi
import idaapi
start_address = 0x4011d0
data_length = 0x115
data = idaapi.dbg_read_memory(start_address , data_length)
fp = open('D:\比赛\\2023西湖论剑\data', 'wb') #部分单斜杠容易被弄成转义符
fp.write(data)
fp.close()
下面的比较逻辑非常简单粗暴，我们直接提出来即可。我们先来看看64位部分，这是第一个函数——
__int64 sub_0()
{
MEMORY[0x40705C] = *(_BYTE *)(__readgsqword(0x60u) + 2);
if ( !MEMORY[0x40705C] )
MEMORY[0x407058] = 0x5DF966AE;
return MK_FP(MEMORY[0x407008], MEMORY[0x407000])();
}
存入0x407008的数是0x23，则return刚好将CS寄存器还原。看样子只是赋值了一个变量0x407058，下面还有个操作，对其减去一个值：
mov eax, dword_407058
sub eax, 21524111h
mov dword_407058, eax
mov dword ptr [ebp-0Ch], offset unk_407060
mov dword ptr [ebp-18h], 0
jmp short loc_401417
咱们接着往下看，其实中间还夹着一层循环：
完全就是把输入变量循环至第八位，加上0x407058的值，再把结果异或回0x407058，看这阵仗好像还是当long算的。看下一个函数：
__int64 __fastcall sub_30(__int64 a1, __int64 a2, __int64 a3, __int64 a4, __int64 a5)
{
void *retaddr[2]; // [rsp+8h] [rbp+8h]
if ( MEMORY[0x40705C] )
{
*(_QWORD *)retaddr[1] = __ROL8__(*(_QWORD *)retaddr[1], 32);
*((_QWORD *)retaddr[1] + 1) = __ROL8__(*((_QWORD *)retaddr[1] + 1), 32);
*((_QWORD *)retaddr[1] + 2) = __ROL8__(*((_QWORD *)retaddr[1] + 2), 32);
*((_QWORD *)retaddr[1] + 3) = __ROL8__(*((_QWORD *)retaddr[1] + 3), 32);
}
else
{
*(_QWORD *)retaddr[1] = __ROL8__(*(_QWORD *)retaddr[1], 12);
*((_QWORD *)retaddr[1] + 1) = __ROL8__(*((_QWORD *)retaddr[1] + 1), 34);
*((_QWORD *)retaddr[1] + 2) = __ROL8__(*((_QWORD *)retaddr[1] + 2), 56);
*((_QWORD *)retaddr[1] + 3) = __ROL8__(*((_QWORD *)retaddr[1] + 3), 14);
}
return MK_FP(retaddr[0], retaddr[0])(a1, a2, a3, a4, a5);
}
似乎还是同样的原理，但为什么都会有对0x40705C的特判？尽管怀疑这是不是作者的某种反调试变量，反正这个函数要做的事情就是对输入变量进行一个从string到long long的改，然后再一个循环左移，就是和上面一样忽略0x40705C!=0的情况。最后一个函数非常好理解，就是位运算：
__int64 sub_C0()
{
LODWORD(MEMORY[0x407000]) = 0x4014C5;
MEMORY[0x407014] &= MEMORY[0x407018];
MEMORY[0x407018] |= MEMORY[0x40701C];
MEMORY[0x40701C] ^= MEMORY[0x407020];
MEMORY[0x407020] = ~MEMORY[0x407020];
return MEMORY[0x407050]();
}
0x407014上是9D 44 37 B5，可能是某种key，我们权当这是对key的某种运算，但是这里的return并没有MK_FP切换回32位，所以我们需要额外进行一次dump，看看最后是什么结果：
还是一个循环，但是确认了输入为32位，div rcx和mov dl, [rbx+rdx*4]确认了这玩意是取key[i%4]，然后用这个key对输入进行循环异或。自此，整个加密逻辑就很明了了（如下部分写法参考了parafish_0的文章：
#include <bits/stdc++.h>
using namespace std;
#define rol(x,i) ((x<<i)|(x>>(64-i)))
#define ror(x,i) ((x>>i)|(x<<(64-i)))
int key[4] = {0x9D, 0x44, 0x37, 0xB5};
char flag[32] = "*******************************";
int main()
{
int key2 = 0x5DF966AE - 0x21524111;
unsigned int *DwordFlag = (unsigned int *)flag;
for(int i=0;i<8;i++){
DwordFlag[i] += key2;
key2 ^= DwordFlag[i];
}
unsigned long *QwordFlag = (unsigned long *)flag;
*QwordFlag = rol(*QwordFlag, 12);
*(QwordFlag+1) = rol(*(QwordFlag+1), 34);
*(QwordFlag+2) = rol(*(QwordFlag+2), 56);
*(QwordFlag+3) = rol(*(QwordFlag+3), 14);
key[0] &= key[1];
key[1] |= key[2];
key[2] ^= key[3];
key[3] = ~key[3];
for(int i=0;i<0x20;i++)flag[i] ^= key[i%4];
printf("%s\n",flag);
return 0;
}
于是解密如何也很明了了：
#include <bits/stdc++.h>
using namespace std;
#define rol(x,i) ((x<<i)|(x>>(64-i)))
#define ror(x,i) ((x>>i)|(x<<(64-i)))
int key[4] = {0x9D, 0x44, 0x37, 0xB5};
char flag[32] = {
0xAA, 0x4F, 0x0F, 0xE2, 0xE4, 0x41, 0x99, 0x54, 0x2C, 0x2B,
0x84, 0x7E, 0xBC, 0x8F, 0x8B, 0x78, 0xD3, 0x73, 0x88, 0x5E,
0xAE, 0x47, 0x85, 0x70, 0x31, 0xB3, 0x09, 0xCE, 0x13, 0xF5,
0x0D, 0xCA
};
int main()
{
// 第三段加密
key[0] &= key[1];
key[1] |= key[2];
key[2] ^= key[3];
key[3] = ~key[3];
for(int i=0;i<0x20;i++)flag[i] ^= key[i%4];
// 第二段long long加密
unsigned long long *QwordFlag = (unsigned long long *)flag;
*QwordFlag = ror(*QwordFlag, 12);
*(QwordFlag+1) = ror(*(QwordFlag+1), 34);
*(QwordFlag+2) = ror(*(QwordFlag+2), 56);
*(QwordFlag+3) = ror(*(QwordFlag+3), 14);
// 第一段long加密
unsigned long *DwordFlag = (unsigned long *)flag;
int key2 = 0x5DF966AE - 0x21524111;
unsigned int Key2 = (unsigned int)key2;
for(int i=0;i<8;i++)Key2 ^= DwordFlag[i];
for(int i=7;i>=0;i--){
Key2 ^= DwordFlag[i];
DwordFlag[i] -= Key2;
}
flag[32] = '\0'; // 防止输出过长，直接在字符尾掐断
printf("DASCTF{%32s}\n",flag);
return 0;
}
DASCTF{6cc1e44811647d38a15017e389b3f704}
在现场，眼看着Nep靠着Re和Cry AK 在神仙局杀进前六
但是和我并没有什么关系，因为虽然也在打，但一道题都没出，甚至干出了把VMP看成控制流混淆的蠢事。
于是乎，赛后补补脑子——
die打开发现rustc的文件目录
不过细看还有个更让人在意的东西，这个tauri又是个啥玩意？
一查发现了一个跟我们碰到的程序图标相同的Rust框架。我们注意到它还可以调用js，那说不定从这个压缩出的exe里还可以提出些别的什么。于是我们直接提提，提提提（
提取方法参考yllhwa的文章和Medium上Felix Alexander的文章，我们可以通过程序里内显的关键字，或者直接搜索文件名找到index.html、tauri.svg之类的固有文件名，拿到所有的数据表及其相关的地址，然后再brotli解压缩。
虽然但是，由于tauri 1.5.4对数据结构采用了一种新的优化方式，个人理解可能会让ida产生一些不必要的误会，导致现在查找这些数据可能得费点功夫，详情可见华章出版社的文章。但实际上，如果你能翻找到数据集的开头，还是用肉眼可以强行把数据给翻出来的（虽然很费劲就是了）——
由于IDA里并没有看出什么可能有rust库的成分，因此本体的逆向基本可以忽略。综上，不管你是直接找数据表，还是从数据溯源回数据表，我们直接把在这个数据表里两个特别显眼的文件，一个html，一个js给捞出来——
import brotli
content = open("ez_rust.exe", "rb+")
content.seek(0x37022f + 0x0B) # 注意以die之类的二进制查看器找到的实际地址为准（实在不行挨个试一遍
html = content.read(0xE7) # 至于数据和长度，程序内部都给好了，照着填就行
content.seek(0x370321 + 0x19)
js = content.read(0x5569)
decompressed = brotli.decompress(html) # brotli解压
open("index.html", "wb").write(decompressed)
decompressed = brotli.decompress(js)
open("index-tWBcqYh-.js", "wb").write(decompressed)
content.close()
html里面除了样式没东西，我们直接看js（随便找一个美化器美化一下就可），然后搜索页面里面出现的内容，再顺手调到函数里头，主要逻辑是这一块：
function s(o, i = "secret") {
for (var c = "", u = i.length, d = 0; d < o.length; d++) {
var h = o.charCodeAt(d),
x = i.charCodeAt(d % u),
w = h ^ x;
c += String.fromCharCode(w)
}
return c
}
async function r() {
if (n.value === "") {
t.value = "Please enter a name.";
return
}
btoa(s(n.value)) === "JFYvMVU5QDoNQjomJlBULSQaCihTAFY=" ? t.value = "Great, you got the flag!" : t.value = "No, that's not my name."
}
非常简单异或加密，随便写个py意思意思：
from base64 import b64decode
ans = b64decode(b'JFYvMVU5QDoNQjomJlBULSQaCihTAFY=')
key = b'secret'
flag = ''
for i in range(len(ans)):
flag += chr(ans[i] ^ key[i % len(key)])
print('L3HCTF{' + flag + '}')
L3HCTF{W3LC0M3_n0_RU57_AnyM0r3}
这贵物的回显上来就报错：
PS D:\比赛\L3HCTF2024\Reverse\Dictionary Compression> ./main.exe
Error: Os { code: 2, kind: NotFound, message: "系统找不到指定的文件。" }
die里看到这玩意是Rust，更慌了。别急，它还下发了一个output，虽然里面只有一串⭐意义不明⭐的字符，但是还是能够借助文件名定位到一个奇怪的函数：
在此之前程序加了大量的0x48用来jump +$2花指令迷惑IDA，手动去掉即可（虽然后面发现从main函数也能直通）。这里面也标明了“指定文件”就是flag.txt，以及输入位数大概是31左右（因为只有这一个比较明显的常量）。不过更让人在意的是上面那一段，为什么就特定对这三个字母switch case。这时候，看看output，再看看回显：
忽然发觉，如果靠硬蒙，那最后应该是用这三个字母组成输入，要让程序的输出，或者output产生的结果跟下发output一致了。前8位二进制还好说，经过几次运行检查，就是回显的二进制串的长度，但后面未知。那么问题来了，硬爆31位字符串，就算只有三个字母也太大了，用什么办法呢？
找规律呗：
横向对比同一字符变化：
“abcabc”对应1BE3579A04
“abcaba”对应1BE357AC02
“abcabb”对应1AE357AD02；纵向对比变化位置改变时（二进制数值仅供参考）：
“abcabc”对应1BE3579A04（11100011,01010,11110,0110,10100）
“abcaba”对应1BE357AC02（11100011,01010,1111,0101,10010）
“abcaac”对应1BE356DD07（11100011,01010,11011,0111,01111）
“abcbbc”对应1BE34D6B01（11100011,01001,10101,1010,11001）
“abaabc”对应1AE24F3500。
不难发现，同一字符变化，后输入的字符至少会使得输出的某处对应字节受到影响；变化位置前移，受到影响的起始位置也前移。结合来看，输入末尾第1个字符变化影响输出末尾两个字节，第2或3个字符影响三个字节，第4个字符影响4个字节。
但要是从二进制位来看就更明显了，根据回显数值来看，组成二进制输出以5个二进制位为一组，对应着某些输入位数，一位输入的变化明显导致对应其对应组、前一组和后一组的二进制数值发生变化。也就是说，本质上而言，这个问题其实是深度为2的动态规划，只有n和n-1对n+1有影响？（见S1uM4i的题解
但我在打OI的时候就弄不清动态规划，怎么办？Nep的师傅倒是给出一个暴力思路，既然综上所述，那么在前面所有位数已知的前提下，会对最终结果造成影响的只有后三位，也就是说，我们只要每一次爆五去三，把后三位扬了，最后高低能弄出来点东西。
以下是本人在看了好几遍Nep的暴力代码后生出的产物：
import os
import itertools
brute_list = ["".join(i) for i in itertools.product('abc', repeat=5)] # itertools，非常好暴力插件，使我的全排列旋转
origin_output = "111010110011111010100110100011001110100100010011111110110110100111100110001111001101010011011011010110111110101001001101101101010100110110111010"
def cmp(out): # 比较当前答案与标答
correct_len = 0
out_len = out[0]
out_bin = ''
for i in range(1, len(out)):
out_bin += bin(out[i])[2:].rjust(8, '0') # 传进来是以字节形式，所以要按字节大小补全
out_bin = out_bin[0:out_len]
for correct_len in range(len(out_bin)):
if origin_output[correct_len] != out_bin[correct_len]:
break
return correct_len
def brute(Input):
file_flag = open("flag.txt", "wb")
file_flag.write(Input.encode())
file_flag.close()
os.system("main.exe > rubbish.txt") # 暴力执行程序以求得当前遍历值结果
now_output = open("output", "rb")
output_data = now_output.read()
now_output.close()
same_len = cmp(output_data)
return same_len
ans = ""
current_len = 0
while current_len <= len(origin_output):
r = [0 for _ in range(len(brute_list))]
maxtag = 0
maxval = 0
for c in range(len(brute_list)): # 暴力枚举每一个可能的情况并记录最大匹配长度
r[c] = brute(ans + brute_list[c])
if r[c] > maxval:
maxtag = c
maxval = max(maxval, r[c])
current_len = maxval
ans += brute_list[maxtag] # 将匹配结果存储
ans = ans[:-3]
print(ans, current_len)
爆的位数差不多了就可以开始手动暴力最后一两位了。
L3HCTF{bbccaacbcacbacbaaabcacbaaabcccaaaabbaaab}（应该
上来只给一个bytecode，事出反常必有妖。
进去看到IMPORT_NAME，发现是python的bytecode的可视化形式，没办法直接用，遂接受Nep佬Musicat的建议，直接喂AI……好吧，我实在没有那种劲爆AI，免费版不是被干宕机就是根本吞不下去。唯一的办法就是手搓汇编，但是那样太废工了，索性拿官解的成品看看，正常来讲你会得到下面这个东西——
import random
def func1(lss, i, j):
if arr[i*len(lss)+j] != -1:
return arr[i*len(lss)+j]
s1, s2 = list(lss[i]), list(lss[j])
l1, l2 = len(s1), len(s2)
flag = True
n = 0
if l1 - l2 == 1:
for m in range(l1):
if s1[m] != s2[n]:
if flag:
flag = False
else:
arr[i * len(lss) + j] = 0
return arr[i * len(lss) + j]
else:
n += 1
if n == l2:
break
else:
arr[i*len(lss)+j] = 0
return arr[i * len(lss) + j]
arr[i * len(lss) + j] = 1
return 1
def abc(lss, i):
if abcarray[i] > 0:
return abcarray[i]
m = 1
for index, word in enumerate(lss):
# if i == index:
# print('warning!')
if func1(lss, i, index) == 1:
m = max(m, abc(lss, index) + 1)
abcarray[i] = m
return m
def solution(lss):
global abcarray
abcarray = [-1] * len(lss)
global arr
arr = [-1] * (len(lss) * len(lss))
ans = 1
for i in range(len(lss)):
ans = max(ans, abc(lss, i))
return ans
def func2(n):
a, b = 1, 1
for i in range(n - 1):
a, b = b, a + b
return a
def calc(nums):
num1, num2, num3 = nums[0], nums[1], nums[2]
num1 = 2023 + (num1 & 0xf) - (num1 & 0xf0)
num2 = func2(num2 + 7)
random.seed(num3)
flag = f"{num1}{num2}{num3}{random.gauss(num2, 0.2)}"
flag = flag.replace(".", "x")
print('flag=', flag)
return flag
def encode(s):
ret = []
ls = list(s)
for i in range(0, len(ls), 2):
num1 = ord(ls[i])
num2 = ord(ls[i+1])
numa = (num1 & 0xf8)>>3
numb = ((num1 & 0x7)<<3) | ((num2 & 0xf0)>>4)
numc = num2 & 0xf
ret = ret + [numa, numb, numc]
return ret
if __name__ == "__main__":
num1 =
num2 =
num3 =
str1 =
str2 =
str3 =
str4 =
str5 =
str6 =
str7 =
str8 =
assert encode(str1) == [12, 22, 1]
assert encode(str2) == [12, 14, 2]
assert encode(str3) == [12, 22, 3]
assert encode(str4) == [12, 30, 2]
assert encode(str5) == [12, 22, 4, 12, 30, 1]
assert encode(str6) == [12, 22, 1, 12, 30, 4]
assert encode(str7) == [12, 22, 2, 12, 22, 2]
assert encode(str8) == [12, 14, 3, 12, 38, 2]
assert num1 == solution(["a", str1, str2, str3, str4, "bda", str5, str6, str7, str8, "bcdef", "aabcc", "acbac", "bdcaa", "bbbbcc", "babccc", "abaccc"])
assert num2 == solution(["klmnowx","abcdefgiklmno","fgij","bcfghijklmno","fgjpqrst","uy","abceklmnouvw","pqrstuwy","fghijlno","mnouvwxy","klmnopqt","klmnopqrstuy","aeuvw","muvw","abcdeklmnow","fhijpqrst","mpqrst","klmnoprt","fghijklno","abcdelmo","klnuvwxy","klmnopst","abcdeklmnov","fghj","luvwxy","ghklmnopqrst","pqrstwx","abcdklmno","cdefghij","pqrs","efghijklmno","fghjklmno","adeklmno","rs","kuvwxy","ghij","befghijklmno","ln","hijklmnopqrst","ghpqrst","fgiklmnopqrst","pqrtuvwxy","pqrsty","jklmnopqrst","lnouvwxy","klmnoqsuvwxy","abcdeghklmno","fi","fghijlnpqrst","abdklmnouvw","uwx","abcdekln","klmno","abcdekn","abcdemuvw","pqs","fghijpqt","klmnopqrstuw","n","nopqrstuvwxy","abcdefghj","fghiklmnopqrst","klmnorst","abcdemnouvw","fgh","pqt","abfghij","o","nouvw","abcdklmnouvw","abeklmno","abcden","klmnopqrstwxy","q","fghijklmnoprt","klmnovx","abceuvw","klmnopsuvwxy","hj","abcdefgh","fhjklmno","klmnoquvwxy","wxy","klmnopqrstuvwy","kln","abcdegklmno","mno","gklmno","klnouvw","fghijklmnoqr","fghijpqrst","mnuvwxy","ghipqrst","klmnoqrtuvwxy","acdfghij","uwy","fghjklmnopqrst","mnpqrstuvwxy","abcdeknouvw","abcdefghijklmno","klmnorsuvwxy","abcdeh","klmnost","iklmnopqrst","abcdegijklmno","fghijklmopqrst","fghijklmnors","pqrstux","abcdefghijlm","abcdem","klmn","opqrst","ghjklmnopqrst","cdfghij","kluvwxy","ceklmno","abcdeghijklmno","lmo","bklmno","fghijs","cdeklmnouvw","abcdeknuvw","cdklmnouvw","abcdeklmnovw","klmnopr","fghijklmnopqrst","klmnopqtuvwxy","abcdefhijklmno","abcdeuv","abcdefhklmno","x","abcdeouvw","fjklmno","a","klmnopqrstuv","abdklmno","fghijlm","bcefghijklmno","quvwxy","fghi","klmnopqrstuwx","r","klmnuvw","kn","abcdeklmn","abcdeklmno","ps","klmnoqrt","pstuvwxy","klmnopqrsty","lmn","d","abcdefghijmo","fghijmnopqrst","ghiklmno","mouvwxy","abcdeghj","fghijklmnopr","kmnouvwxy","fghijklmnopqst","klmnox","nouvwxy","adefghijklmno","kmo","klmnovy","klmnopqrstuvwxy","cde","y","klmnouy","fgklmnopqrst","nuvwxy","kluvw","abcdefghijkno","abcdekl","fghijno","ceuvw","abcdelo","bcdklmno","gij","abcdeijklmno","klmnopqrt","abcdeklm","pqruvwxy","klnuvw","fijklmno","knpqrstuvwxy","fghijklmnor","ace","abcdekluvw","deklmnouvw","lpqrstuvwxy","abcdefhiklmno","fijpqrst","klmnopqrstvwy","mn","kmpqrst","ipqrst","fghijkmnpqrst","uvxy","bklmnouvw","fghijkmnopqrst","fghijklnopqrst","kopqrstuvwxy","pqrstuwxy","abdeuvw","acefghij","jklmno","k","fghijqs","abcdefghijno","fghijklmnort","adeuvw","vwx","gjklmno","hi","abcdefghijm","nuvw","fklmnopqrst","abcdehklmno","fghijklmnoqrt","klmnoruvwxy","abcdemnuvw","klmnovw","klmnopqrstvw","klmnoqtuvwxy","klmnoy","wx","ouvwxy","lmopqrst","fghjpqrst","lnuvwxy","vy","abdfghijklmno","kmnouvw","uvy","klmnoqst","klmnort","pqrstuxy","qs","lopqrstuvwxy","mnouvw","abdeklmno","abcdelnouvw","pruvwxy","qrsuvwxy","cklmno","bc","acdfghijklmno","j","fghijpqs","fghijknopqrst","fgijklmno","fghijnopqrst","mpqrstuvwxy","knopqrst","acdeuvw","lnouvw","fghijklmn","klmnouvxy","abcdefghiklmno","abcdefghij","hij","abcdekuvw","klmnopqs","aklmnouvw","acdefghijklmno","cfghij","fghijpqst","cfghijklmno","abcdefhi","kmouvwxy","pquvwxy","pqrstuy","pqrstuwx","ce","klmnopqrstv","deklmno","klmnouvw","abcdeno","fghijkmo","knouvwxy","fpqrst","hklmno","fghijkmopqrst","abcdefghjklmno","kmpqrstuvwxy","dklmnouvw","abcdefghijkmo","abcdel","giklmnopqrst","buvw","klmo","klmnoqrsuvwxy","uvwy","abcdeluvw","klmnostuvwxy","bceklmno","fghijm","defghijklmno","ijklmno","pqr","abcduvw","fghijklmnopqt","hijklmno","klmnoprsuvwxy","aeklmno","lo","klmnouxy","cdklmno","fghijpr","muvwxy","lmnouvwxy","abce","kmnopqrst","pt","klmnoptuvwxy","abde","abcdeghiklmno","klmnopqsuvwxy","klmnouvx","efghij","klmnouwy","bceklmnouvw","klmnuvwxy","ad","klmnoux","gjpqrst","abcdegij","fghijkpqrst","fghijlmnopqrst","abcdefj","fghijklmnops","fghijklmnoqs","ghi","fghijqst","abcdemo","abcdefghijkl","fghklmnopqrst","no","klmnopqrstuwxy","klmnopqrstvwx","abcdeklmnou","abdefghijklmno","klmnopqrstxy","acfghij","pqrstuvwy","kuvw","abcdehi","de","fghijpq","lmuvwxy","abcdelmouvw","abdfghij","knuvwxy","acde","cuvw","uw","kmopqrstuvwxy","abcfghij","fghij","abcdeklmo","abcdehij","abcdek","fghijklmnoqrst","pqrstvx","klmnopqrstvx","abc","klmnoqrstuvwxy","acklmnouvw","afghijklmno","abcdeklmnuvw","abcdei","fgiklmno","klmnopqrstuvw","abcklmnouvw","abcdelmnuvw","abcdehj","abcdefghijlo","fghpqrst","acfghijklmno","abcdeg","klpqrst","klmouvw","bdfghijklmno","aefghijklmno","fijklmnopqrst","fghijps","fghijklnpqrst","fghijklmnop","fklmno","klmnopqrstw","abcdfghijklmno","fj","lnopqrst","fghijkmpqrst","fghijlnopqrst","ux","fgjklmno","fghijklmnopqr","abcdeghjklmno","abcdefghijkmn","abcdegiklmno","abcdefiklmno","acdeklmno","klmnops","fghijklmnopqrt","fghijklmnoqt","abcdegj","acdklmno","abcdeghi","abcdelmuvw","abcdefg","fghijkl","gjklmnopqrst","hipqrst","klmnopqstuvwxy","lnuvw","ghijpqrst","pqrstuvwxy","klmnovwx","klmnoqstuvwxy","bcklmnouvw","abdeklmnouvw","fghijklmnopq","abcdefghijk","abcdefghijklno","fiklmnopqrst","klmnopq","npqrstuvwxy","klmnopqrstwx","abcdefi","lpqrst","ghijklmnopqrst","bd","bcuvw","hjklmnopqrst","adfghijklmno","klmnosuvwxy","louvwxy","bce","gpqrst","fghijklmnot","wy","pqrstvwxy","fghijkln","lmouvw","gi","fghijn","fhklmnopqrst","ghj","klpqrstuvwxy","abcdefgklmno","fghijlmo","fghijo","fhpqrst","klmnoprs","abcefghij","abcdeklno","abcdefghijlmno","kmnpqrst","fghijklmnoq","abcdefhij","fghijklmnopt","klmnopt","abcdefklmno","abcdelno","pqrstw","fghijlopqrst","bfghij","abuvw","abcdefghijln","ac","aefghij","prs","lmnopqrstuvwxy","abcdefghijn","klmnopqrstux","luvw","giklmno","kpqrst","jpqrst","fghijrt","fghijlo","abcdefij","fghijklmnorst","fghijqrst","tuvwxy","fghijlmopqrst","klmnouwxy","bdeuvw","fghijprt","klmnoprst","pqrstuvy","fghijpqrt","fgj","pqrstvxy","abdefghij","abcdegh","abefghij","lno","klmnopuvwxy","klmnouvwxy","fghijrst","cd","euvw","hijpqrst","pqrst","klopqrst","gijpqrst","klmnopqrs","fghijk","klopqrstuvwxy","rtuvwxy","klmnorstuvwxy","stuvwxy","abcdevw","cdefghijklmno","bdeklmno","pqstuvwxy","fghipqrst","fghijpst","kmn","mo","abcdeuw","qst","fghijklmnost","klnopqrst","abcdekm","abcdefgj","klmnopqrstuvy","kouvw","abcdelmnouvw","abefghijklmno","fgipqrst","klm","klmnopstuvwxy","abcdekmno","fghijmno","pqrstvw","kmouvw","cdeklmno","st","fij","fhiklmno","abcdefghklmno","lmnuvwxy","klmnovwy","klmnow","mnuvw","fghijklmnpqrst","klmnoxy","fghklmno","b","lopqrst","pqrstuvw","abcdekmouvw","abcdeklmnouw","acduvw","klmnoq","bde","pqrstxy","qrs","bcdeklmnouvw","abcdekmo","abcdefghijkn","kno","abcdefghijklm","abcdefgij","kmopqrst","kmnuvwxy","pqrstuvwx","fghijkmn","acdefghij","fghijmn","qr","l","kmnopqrstuvwxy","abcdefghijl","afghij","auvw","abcdew","klmnopqrstwy","adfghij","abcdeghij","lmopqrstuvwxy","abcdefghijklmn","uvx","km","abcdefijklmno","abcdeij","pq","lnpqrst","bdfghij","abcdefhj","mopqrstuvwxy","fghijklmnopqs","fghijqt","ade","abcdejklmno","fghijklmpqrst","pqrstuvxy","mouvw","mopqrst","lmnopqrst","abcdefhjklmno","acdklmnouvw","bcklmno","nopqrst","qrt","fghijlmnpqrst","pqrstuv","klmnos","pqrstwxy","fgjklmnopqrst","pqrstuw","klmnopqrstuvxy","fhijklmno","abcdekmnuvw","ghjklmno","klmnoprtuvwxy","abcdefghijlmn","klmouvwxy","abcdegjklmno","p","hiklmnopqrst","rstuvwxy","gh","cdfghijklmno","klmnou","iklmno","klmnopqrstvxy","lmpqrstuvwxy","prtuvwxy","klmnovwxy","pqst","klmnortuvwxy","lmnpqrstuvwxy","fghijmpqrst","ghiklmnopqrst","klmpqrst","klmnoprstuvwxy","ghklmno","fghijopqrst","klmnoqruvwxy","abcdeklmouvw","ae","abcfghijklmno","vw","fghijr","kmnpqrstuvwxy","fghijklpqrst","vwxy","uxy","cklmnouvw","abcdefghijkm","uvw","bcd","bcefghij","abcdeiklmno","klmnot","cduvw","fghijmo","eklmnouvw","klmnopqrstuwy","kmnuvw","lmouvwxy","abcdefghijlmo","cefghij","klmnoqs","klmnouwx","kmuvwxy","ceklmnouvw","fghijklmnoqrs","abduvw","abceklmno","ghijklmno","abcdefghijmn","bcdfghij","pqrstvwx","fghijlpqrst","gijklmnopqrst","abcdelnuvw","pqrstvwy","pr","fghijklmnos","c","fghijklmno","abcdefghijkmno","abcuvw","abcdev","abeuvw","pqrstuvx","klo","fghijln","klmnpqrstuvwxy","abcdefghijlno","fghijklmnopst","acd","gipqrst","w","abcdenuvw","deuvw","abcdeklmnouvw","fg","cdeuvw","lmnuvw","abcdenouvw","klmnoqt","hklmnopqrst","klmnouvwy","gijklmno","klmnopqrst","fghijmopqrst","kmno","f","uv","fhij","knuvw","klmnor","klnouvwxy","bcdeuvw","bdklmno","abklmnouvw","abcdehjklmno","bcde","fghijklmo","abcdefghijklmo","ko","abcdeklmuvw","bcdefghijklmno","beuvw","qstuvwxy","aeklmnouvw","h","t","kmuvw","fhi","fjklmnopqrst","hiklmno","fhipqrst","qrtuvwxy","abcdeklnuvw","fghijqrt","pqrstx","bdefghijklmno","gj","abcdelmno","abcdefjklmno","fhjpqrst","klnpqrst","fgijklmnopqrst","abcdelm","fghijrs","klmnouw","fhklmno","abcdeln","fgijpqrst","fghijklmnoqst","abeklmnouvw","klmuvw","i","lmno","fghijklo","fghijkm","g","adklmnouvw","be","abcdefgjklmno","prst","puvwxy","qrstuvwxy","klmnov","klmnopqrstuvwx","acefghijklmno","fghijpqrs","fhj","abklmno","abcd","fiklmno","ijpqrst","fghijnpqrst","lmnouvw","suvwxy","knouvw","duvw","fghijkmno","bdefghij","aceklmno","fgklmno","fghijst","adefghij","fghijklmnopqrs","bcdefghij","abcdefghijko","klmnotuvwxy","klmnopruvwxy","klmnovxy","qtuvwxy","fhjklmnopqrst","klmnoqrst","prt","fghijt","uvwx","abcdekmnouvw","dfghij","abcdehiklmno","klmnopqrstu","adeklmnouvw","abcdefghijmno","klmnopquvwxy","abcdefghijkln","mnpqrst","fghijlmn","lnopqrstuvwxy","pqrt","fghijpt","abcde","ij","bcdklmnouvw","fghijkn","pst","bdklmnouvw","abcdeko","fh","fjpqrst","fghijqr","beklmno","fghijklopqrst","lmuvw","klouvw","fghijpqr","abcdegi","psuvwxy","klnopqrstuvwxy","abcdelmn","fhiklmnopqrst","fghijprst","lnpqrstuvwxy","qruvwxy","aduvw","abcdekmuvw","adklmno","abcdeu","cefghijklmno","lm","hjklmno","abcdefghijklo","klmnoqrs","fghijko","ouvw","pqrstu","mnopqrst","louvw","prsuvwxy","abcdekno","klmnopqruvwxy","kpqrstuvwxy","abcdefgijklmno","klmnors","abcdefghijo","npqrst","knopqrstuvwxy","vx","fghijqrs","klmnopqrstuxy","u","aceuvw","klmnopqrtuvwxy","uvwxy","fipqrst","klmnowxy","befghij","gklmnopqrst","abe","mnopqrstuvwxy","fghijklmnoprs","abcdeo","eklmno","fgi","fghijlmpqrst","qt","abcdefghi","bcduvw","bduvw","klouvwxy","kouvwxy","fghiklmno","abcdemno","pqsuvwxy","ab","klmnopqrstvwxy","pqrstv","abfghijklmno","beklmnouvw","fghijklm","pqrsuvwxy","acdeklmnouvw","vwy","ghjpqrst","fghijl","klmnopqrstvy","abcdelouvw","fhijklmnopqrst","klmpqrstuvwxy","abcdef","bcfghij","fghijkno","kopqrst","rsuvwxy","abcdekmn","aklmno","dfghijklmno","abcdeklouvw","klmnpqrst","abcdeklmnouv","knpqrst","aceklmnouvw","kl","fghijprs","rt","klmnopqrsuvwxy","bfghijklmno","klmnouv","abcdefh","s","klmnouvwx","fghijp","uwxy","fghijq","klmnoqr","vxy","fgpqrst","fghijlmno","defghij","pqtuvwxy","dklmno","klno","klmnowy","abcdemn","abcdeklnouvw","ptuvwxy","abcdehijklmno","acuvw","bcdfghijklmno","abcdemouvw","abcdefgi","opqrstuvwxy","v","lmpqrst","abcdeuvw","abcdekouvw","qrst","klmopqrstuvwxy","prstuvwxy","lmnpqrst","pqrstvy","abcdfghij","klmnop","ijklmnopqrst","klnpqrstuvwxy","klmnopqr","xy","abcdeklo","abd","klmnouvy","klmuvwxy","abcefghijklmno","fghijkopqrst","fghijklmnoprst","ruvwxy","m","e","abcdej","hpqrst","bceuvw","fghijmnpqrst","pqrstwy","klmnopqrstx","qsuvwxy","fghijknpqrst","bcdeklmno","klmopqrst","bdeklmnouvw","klmnopqst","klmnopqrstuvx","acklmno","hjpqrst","abcklmno","rst"])
assert num3 == solution(["ysvydhncudvxqgub","jxomzgqmpccovmyy","hxiwwqdowwbdzrql","zqfykhyqgxpuedhx","vhszanyizlocrcta","dthywqimclejyrxf","pxvnsacefcaeqwpn","eibroystpzgkhwkt","efioczniyhzlkgxx","jbafyifjrdsevjlt","noggsbrxuzxxxpnv","usxugdobkxyvebgp","omppygjbdzvfncoh","lszhxcyfyhbezqpl","sywbjmfmigsrdhbe","kmitesfpzturedvn","fhccayoplynamcmf","xwkxxvmngwdkktcq","bkdetlrdtrvxtwnm","otbqjkibazuiuzjc","bvdlpsuozpxykhso","sfkdemywenvutigi","zlsgexavkjlbniyz","omvmljrelegkrnly","ncfqxwbgspmmxequ","nsnusovrqfyjqcmi","xmfltlmbucykoygu","znevkwdmcjkxazvx","qmmlumphgweyuqll","vvwllhnjjilkkfbr","tfczebbrmcwkijpy","dyqudxtooxmzaivg","qabmbvkkacpipzwv","ousivmwzqkzowbsf","wiajbnzcyczvdkme","jtvkqglawuiitvne","hynkguvzlahiaweu","dcdhzutcxsrwhtiu","sjkbkfbzcltyhkzc","vmtoulenvyzgmzph","hhpjlqospgyrpjnr","trxsiqvzjdsumnbx","ifmzrmfjlfbxrspp","zuybbnxweoodzrcp","dqselcmauqpdbvji","ucdmjxlnodsqbtpf","yxqxoqyqsuxbvvwh","jifmvnffunc2jlgdux","fttypgxftlzhrjhu","rzmkqtaejgzrwvht","fylzmnvoslrjeuhu","xxhmsywcfchxybtz","nivviopjjkilmfnt","vlvtonhigprfttuk","cwgnurrfabcfotdmj","erjxfseyzaygaujp","nrcqdwczglmcvinq","dqbyglmywihtexid","vqggccuiimjqqpuz","wbvvklwhouxxcbzg","jxstdmcbouqvysje","envdnanmuewgheqr","oxjeneckyoxdypwq","ityoxogkfmlasgfq","tgpkcweywtqopjnc","hepoijpjgvckkqzc","ubppuzmagmjgmjnf","snvaiqinphtkbxtc","wvdwymqejrygisbn","kmbwjynfbwyablvs","rsscpinfcegvnulj","oplzudhvjaumtavx","oionhndcrjvfexir","cxxlrudrixtmjsgw","sfngfbrksewwbwuo","wngezcjkxlftmure","xgkmmsvjjvtlwyko","dfaihamfjrwobkai","ybzlbmtejcbhkbqn","yvgttkpmodjrdjaj","wsfkdifjxsisyazp","btdahuinzvvmyuti","sppdjjphoadtnxqz","idikaxmkupaaeyvd","bxmusrwhsuglelsa","wllftkyuyjwumzfz","lsrfakcruqfghhqr","oitbsfztaayzgttw","qvdaclqbkxzxtvji","hqtnylqopcuyitvv","dovrsivynjuycgob","zbeexmgffbvgyukt","jnyrkwuketocbnlp","kesivzsfimkupknz","fvctuhkhcsxgpnlc","geyiflxobsqqgysp","vdhnckkljiwiylkc","jxixmpjvkuisogjx","ggmgthlqqfjzvsiv","nkdbbqswrytidodb","cvnxasfxcyyprwky","msptawajcgigotxx","lggqfreicrrzgqug","pywexuvmpapzhhmk","yjfzlaazckdxqhpk","gxopiqnejwahizvy","rwptjuqhjshtosim","zhszbxltmwjfbcnn","hznbmqrhucjlhtev","repwvulbjzulzqlm","juemhyiaujdhjwda","iphegtklhgyiabcof","tpqxoalgjntzhxph","ahnrxtoyzqrqrxce","ljsunmfpleczezfi","flqbbwjpvmpiagkm","enxrdnasgsrczncm","setirvmdopdbgqqi","uuyoeqtcgvygmlbd","gznmxhdzpgclmmce","wrqmvtilsmjrfruj","nzbqahmftsbygrje","nodxqfwosevxikai","ynzmckxtfampkdcb","ishsysxcjavxukfq","mbwcnmktksqoptdx","ybpgwitxuarhyuud","odkhmislpnpjltvc","imlknoihasmgbjle","autoweexfbmsnamc","pzddxvvmnmujzovy","zbklmwsqltyiqjaq","wsfezmwlwnovzfnq","ipvtflaxlabczbjwg","xmeypiupgboeikma","qmhxpnusoafktsrp","akbzwaoevusmqhjy","ptnrluxfiaoedirs","fkkujjetvujaffev","iqlaebkqlabcuugvd","tvfazupnodyxyegj","cxxbmckkoocwwmkv","eiinwggrnufbuefm","jbajzgyvabcjrpirb","anotitqeflusqkmx","kkyyjfyqfwuyphvs","mkxxxgmewnnfmtgw","rfzfkowvhlbuptnn","yihacnrktjrrbupi","ljbfbmrxivbqhvgn","kelkifhcummieqec","qwglfqmlgtufeggt","ztdsjupiobdswepc","nxxrjnqebfrtztab","zwuijitgzkamuohu","skctyqbrtdlybrad","ftvbzzqisluhwvoj","tkyzlbdwikxwxtfm","yqzbwtibgyhezefc","ugmtditxujqhzdjk","pzqfxlcsbyiayoqn","mvuvmubzxoapqlwq","wxydvrxojyifgild","gaubuvvoncoahhqs","arrqgidasqpyozqo","hlktmcpfqmqunsiw","hpshspcjtkvjtyfc","xwdjpdyqbgkvbbto","dnipqamvliabetfk","zrptncovohuprjfj","zykerhdnpwqnklnp","wehvwpjsjmlhbxme","qhabvcixedhtacnm","nzbonhjtiragsjxu","piktfsxlejzjpmxa","kpgluxplomivhups","utbqkkbmdakmajvb","pbosjdvammowabof","hwwpavjyghyogxiz","qixjbuehpllqwbir","watokwdhqrlthmyt","fiuvnmucwsfhvirt","efjbktqktzylkzym","eyagoufvrlrbukvi","dbebcdxywrceoioj","dmejkiuqtpzkvtil","irxxxrbxjvvisefx","ezacasyffovrewri","zfoernjrzvxkzqjn","krrmkfftxdxqxrjf","xexiopshwbkipjdw","cnuiizhcocljycvu","idsxihqjacgtwiuu","nwjjtbiketrqdvxb","avmxhxabcxhflzcbs","uqxjgosfyjcbxshz","gwybdcsgvjjacjoq","zokabcujdqyhfvvve","dudqkxdyvnmzxbal","duurelhvlvlwtisc","vvduznkfxsydjjsu","jvohyxbezkxdybjk","tecmjpqvbqdfgbch","wmiwtqmxlipobteb","bzhfoutsommbeahv","pzxilyvfyokfmsmr","fvptnoujoahvjljv","nntjwlzvtlwjijtq","iiahigptxppvjwwh","fiwxrfkvznhngctp","hljuecxsqwhfhooj","kpgylifngxbybkwm","ckxgbjjygzkystat","anxjpmmadenhxunx","kztzbysfhebhkxhw","qeywqntlveiebhos","jlbvhtvumiyxwqlo","ubsttmdcjigfizes","tifeodqhusljfhxl","xhtrvehthwvsxkmj","slytykltdhwruorn","ettsedvbbxttpkwg","znlstbcrbxxyauvt","zvxkminzbadeyxpn","vkeqpqwrdrzvrdkg","lmgvnrmbwermpsxx","wpcihvumyumoljws","sqqleapevuisjovs","xrtefpneewlrlvwd","mmbabccilwfyvvjak","mqebclxzlkierkjf","cuytrwygyntgajgm","fhodjnmtmzrqzszj","kmgwmlnfykcuvqnl","aopjewaqievtqdct","tjouxksorchkworv","ncirabcozpldzewjz","sucivpgmovkfqxpn","akhusibommljkvfb","cdxrtkejlxftegjn","pcykwqocqfjcpygs","ddgipyltjxtthplq","uqtqauyppkzzztxr","byziilqifrkefnmx","pihmqvosbrmfwvgj","zcrokjgwuujlsqzk","midiigvhwxuuxdoj","quzizelifvrqgiqy","qoizxtjfeiykktbh","kopvmoiueozhbxfe","rabczignulcwpsobz","esmkumjwclulmmlg","cwknucjbjropshgm","xrkvscqbnuofxbbd","lfhexistfbnypjxb","qtvceoxufqerkgcd","nvqnrbzmizbmenoj","vaxeseydjahzmeqv","kkhvyzvdlupbekot","ghkdrqrrufndvlab","puuorkmgkyjrrfzm","qdojlkfsajazdbtr","trunvamzxxtruqqk","wyfqiycmuaxnwdmj","tehftxcnimfcgulv","xideohbursltsyaw","zukuxtscehugrlwz","tqyowyifdxmlekmi","gktvxxotbobtzjhz","sbrdswxuitwshrql","vjxkqyvipqlevbhk","xupvseicxsjlvprl","zzvgmaspjzobbbai","umqxughwbhxrbgnv","necgnedkdtsxllws","kfzhgtbffdkcmemk","jygmwohqgxytdabcc","xubntcuzhakycmhb","nykkvobihcvcbsom","jmpfjbgethlvegac","rcrkrqlqszizkuwn","mkvtjvezpqntwsor","vavxnwabzsvbxrta","wxjtawscbrqldboj","ukqyxnzmmregydtj","bzdoqdhyfxjhrtca","zwwifjejxilnlncq","zbhinfwhbsewmmnj","wpatetlrcetrwygn","qijjqtjtkjldjzpv","wizlmxgtbqokdive","gjowgwgtfyoyvakj","dutziyzhjwwdwbmh","hhxlvaslalqnjfez","nftbzbqrrdhpbvel","rawgbwriyffuvwea","qelvbxvcmyipiyux","gpvbmgzpjpvmfjou","edysbthmpzewjmhq","gimdgabewrjfmouq","kabamudmytcvskgz","jnbqnbtzepeettut","ubycgxbczobyuvty","ncqlwqzzlurrfurm","mqdliidaptajnque","aqkislhbhutlmskx","kqgowgleasjmgjro","anzasevxbinscrwy","mligzlmekbqjtlkz","acjwzeaariolohth","lewbaeswgtsegzgf","bkaleiidkzgtyukg","griqeggfgygajdxr","tiqtuoakcxhsppug","djwebkqgutgcqjkq","mtdquygxxpcnmxvg","lzbitojuuxxhrcms","wkqdzfkdeoxlrrrv","qdkvpynqxmqizxfh","rsypvochupieijuw","zhjqkrovsdewbwrg","cojrovhotitqglxf","vupizqllrxepdyej","rrcescgfpodyqgqj","enyhpwibqizxzxlf","ysgpfnkxewxpunmc","qqayjdiwesfhjqdj","vvxsqmsxkwlowkaz","vhbgvteemnjcjzjn","pjvysfsrgpzeefgi","hjpqwdkuxpvojlrb","qdviqqkpfpmusqku","zekclapatdchkkuu","ushhsykosapkwfvn","qlwhigtykfafzwkf","ueeemzyxxionuzvh","uxidcslniryrlkfr","wjrqpxvnjwnzvhaw","sfufkmlseobjehmb","viqcfxqgzfgjlwyn","vfffdaynlllgflud","xgbzqwuziammugee","juwviucofrqykbph","nfhofnyrvpgnrncr","xwnrmtztbduhaxzm","qwjuwencytcviddt","zgtzokhuophlklax","yhhhyqbivjulhxzz","qjlrmtnkpezzxbip","csjtxagscqzcyxgw","gibiwnkxfwmdypdb","zwuqefypxjswiqnr","rvwoomgislxnjiku","avtzjpgdqkrswwil","tybnjxlyeppveuln","hvjlkwgdbzjuthio","uwmvnynpvcrtjaoi","tazibajxbbektuny","eydtgcsqrjeudusa","cjvzwcgypecfudux","oovnezznsbbuzage","jjeciyognokzoavb","ewwzxbjfxgyrwdnz","mqtotsnaejvwsfxv","hewhemklxufjlxds","qfgrjckxuvxppffa","xrkanxmmdhjnrpms","ugszqiazpribuhin","hhtlbstnuebaovan","wmerwupitfwffwjq","cfhlftbplljrdnmt","iwgvszqjzoutyofq","rfddyjwanuajwfms","glcpwdgghxjjlbhl","opyabchjxtqeaqluw","zqrzsgsurxcablbp","tlzsuhpazrgyftra","hfbywjxrjvfyfjor","xfuisoaqkhitaneo","jbmpkilwrfevuabc","riftearjllxbsrpg","visatalbyphvpcqn","tezwyeuynxiqceny","gmllnngsknyuqfyg","jcptptnztjtczgin","sfslwzsttdrouqmi","oprcoelsndlnehzv","cfmhxjwgozohudcf","mhxzekxwbbccbumx","qeqyvhpujfgrmiop","gtqtcpovarcorjrf","aloszdzbbywgchfd","dknbhpmmjnuehczn","ebkeuntykvvfywib","nlgiglojmpbxhafl","uswobtqjlbukbjdo","deinrxindafjewms","bgkkntzoayoycmii","ibgusyotlezfhixr","jhduofjmetuvulfv","ncomoknshtsctgif","oeqgwqzgiuxzwnbo","kfqhheuvmfwtbokw","iqsoqygphhfktibu","bobacxbmnfzanumt","knnwtzpjwzujuuxw","vfnlobdgwymhcgun","gsvqncqugmzlvkcc","fqnfjzhlmmsjzvxx","isynioqvlkzdhldw","ysyenabcioynjgrzo","mgarisubmmtmxaqu","tlkplxdwjvivozqu","uumvkpkfqckauzpy","jqzzndmsdwuznmii","cqqaephdukcklkkh","arqsbqajtlzbxspv","fpwnogjkszhusmqn","arkauhwcnzyhgzgp","mmlbhlqmmpxdsjpr","hxsyiwgylwvfxvqf","fmgsmcxhczkblvrr","jfsbaiqqmrcqziyh","yonriirnykgcqqoa","loqnbxhvnqhefnzc","vnrwfrtawnjzmzpr","nwvmixbdevbawgcb","ssoscjougdkdgwzy","tdotnfxymskkechy","gdqyqjahcohateim","nmpingpzculglnzq","oshxfncaghkzfflo","brqucwymtbtbpkmg","dlbolallmawftyne","zaygaqdomkdndypz","frynwfgjeyczjiyj","fkrmnqytsxookgtf","ztsuspdffprgefji","urmvtcqxbzqlfenp","jtqnervrgeqgltma","mxazffkgorgqvasd","ohxmmsvrbcbakvtz","gvgbadnzvabrkajj","ytxszlngumxdrxgs","uyrufyweypbkrbcg","ylelxbcmvwdqlsst","fnqgyqxovwwitolz","nmrqcgovdmaregoh","jabcyxscsxpdwhduv","agyjbfjdrxsdxcbz","rsxthmvbbfsbapza","bnulsywwhvtckkmm","oetgshifgdhknjen","fdacdxgrjnfqhbgl","ltrpuqvqvaaijmix","aalhlxvddlhxsyev","qubggjexevkjzapf","qffkqkgvbxyrncum","ouebeyqrrbwluaiu","bsmvockhhfxdvwnn","wzyrusboriskzetg","qtkohvlnoxldzkhe","sknqielwtnmdozdk","hueabhcqpsziqofs","qvdcptldvpyzwbwt","gmcsgkgfgdzvdywo","whcybgsdsunkkpqd","zouenychsloywadi","ofnixothejurjqwx","baurihhbpsuzaxdz","odnxgsawwegaqqsk","avnvjxfrofflpnfl","fpeejbcasyuuirri","lnqcckixeovoabad","ogzfwbnpmoqzdxqb","lsfpkmktczfkgase","ckfkwbmenshnuzrk","puuxkxfbbtdttkec","oxplgbgxocgwayuc","tgxfplgbhcjubdtg","cpcwhsckcdfhbwmp","huaukdwwqenjsnbr","hvofxghsjlfhswhp","vnwbsvtnpfpwatiw","mcbkpsbgywhqxsix","zksceqawvnemisil","ojpmvjelrldcqflk","ppfxcvjrjywbkaci","vkkkabrzumejtwdr","jzzvegddqgtogyel","fvwxxwbukfrbazxg","rpvgsjrcsunopqja","ngjxvxsqxcboieeo","xgrdakguxugvngjr","zlixckrlsfjnvwiw","kqqahdzvaovwrarw","zeqmlrqvcymohkfc","fkdmammoniaqeaei","ktrvrgxstgvttftq","skujpfmasgqboljm","ydenwjcdlcdtodqp","hgsuqywmnwmyfotr","waufauuijgxaqceu","gbudfydfhbvoamth","afskwqlszmvafeqm","nbsjuuyfqbhqajok","iiawyxcdikosbwsx","kgqvvxhnmswfngde","icqcdxpedlxpvgms","wpxzbdlhhvarycks","wkwdjgkzzrmuhuol","swsgbdcrbhqhfcci","kgmkgeiryynvhwah","cmpvksdyjvmbdfhj","uglxrzjgijfcvhbx","bgevfvpmocxgausz","uqojyggipoyuwkby","avlnovzpuzubuuss","eyghurrorndubcsm","zdnntbwcugnykdti","lchrlndexvovoznd","cpnizzfmpzinymlk","hskvkurwexwqasxt","xprysdqnfmvifwjy","ngzdbejzpatoixnp","zxomsbqlfuhemazl","iqvuegauwclhvqma","tzdgvyptuayjvktt","zvhbvljserqbcbir","mukwzypdxlegwipe","uslhhogibvwqzhyz","rylrlapnfsdogovl","impmhoqumkogchoq","zarlqxhzfwhqjsms","ymxpexvboiwzkomy","nhgexfzvunjnosgb","wslojqmvusvumclp","uufkkyrchehmokjr","uadbebqfwaewmzdk","wwzazyhamqhdwjzc","yrwrqxhvmzfeiqpa","gycblakmiqqoioke","gpyfmbzhhhtuysyf","agtyhlalmwzmpnes","jhbfquwnkzzmmrqg","xahekbixkfaidgkb","njiajqrymsbxsfyj","xrhkzoerfwjjjvyv","mojaewgjwmmxmmcj","mcimexhcqqptnotx","lshefqasobmbuxdd","srgglcluxgheudmy","cgxocmkqzjagwgmm","iyreabcwxbnkpsjoa","zaljaqjvfvvqdays","gskeygtjgbijvkjn","smpslnyxjvbhjyvh","raeaxhedueaayvlp","vbzqcqhzdaptsdts","enurfjqxyapakpyu","xesnqtvzlkjudkgx","kjwfyrasqtafiyri","bsbavcxzjuaksbld","hstmbonbgsleppae","exyhezlohmqkhxlr","rqmhckbvtfyqwsxh","wfnvwsffbdliqsll","eaqnrvadjaojgfsm","rhocxroqdqrervjn","mzdczcvbrhjwcdve","yxlrftymqxqtbvso","baunrbrfzrapqzit","oipmrdynelruxvry","khppolojdkojxwqv","umwgrzharatzdqjb","jbabfxajhdducgsw","ohtxxfqthypvhbca","knwjiwadhywkwlsz","qteikhwuuasdyvpn","ytdeibtvnlysssfj","bdcflvlghfonjfik","eactaiaqtgrhwkbn","evfodntmumnmpltz","zklhlzjiueabafnz","zrsbbgkjcseqeang","cbvthkbgywxvjkhh","gykehthvmdzklzmm","bhrydwsdwtqaxyhu","abchczaihcevacgzx","yonhiezjoqwosrwx","lpwsvvjbtimkqkaz","tibcufriphwxwzhj","kqxnnvmxdyubsyma","jdjdalrfdvtzjzzf","qzijzvthlydyayby","xsmhbxalbihmkgmr","ickheeqdhkhfvagy","zgancfyzdspdikye","rglysjgxdhtlirpe","xwmvbwnbknuynzms","rtggytyubuthyvdu","hjfqzmmiqdopyduc","yyeixxunfkstmdly","stccdhodaeauqskv","bsemgaskpcgvmcgd","todqxrxzpksoowqy","wqpfgvkppuehavdx","oecawvidnbencfzv","ocpbksbgdutggshn","hvfvfvhuwftqdtys","raqymywkbzpjsomo","mnsgyltrdguifeom","zrtwkfvmrxgmebpc","esnlddvhmlycfnzm","ujmrrippyxxaitjd","cjqopvqjmwdwrhtc","axterdjcgvvkvjmt","wsfjhyhiwcskrnzl","excxprrgtvsdstkq","bqpvnpcbqbjeorfs","zgrbyxqcahdirxzz","ibruhcuhiwpsndjo","dmningijzetvgssq","vsbnskosiigyjwhd","gvbexrsmzefdfjra","rnjdwommvluzgmiw","qfnpnioafynmfnch","iutdykdyrnjbijim","yybpzynyyvqsibqw","ukcumxubdajklbow","qpfhjabesozcqxnt","ogpjowmcxjvltaei","nmmgxxpblhyvjcza","rsdicjpuitrhjhoo","rougghrsdcuhaxkb","ccoubobkldovhdha","heeysansiaiqecsy","txyzgixqzbqoyddo","zgonqkaonzusldmu","ksvocdxauzvzaqej","tthfhimluvparxna","jrfaqfteargbowaq","vwgdxfzukfkbwmoi","kxaxverroublhnkg","hxcyocruwhxerkwv","waaywxwtrwpnwcxe","kbrwbedcrxacnfzn","heqhjudnrfmpgffr","zoninmtmgfzwfivy","nhdjsbedakglczfb","eyklkfsriufgdeta","cdtcihvzlfrxcqkk","nszlmuisqibdhuij","frfwwwunnpwouryl","bahmwsfifpehpvlm","xinovuwjryvjderk","stdxirugdjwsxdrf","ukzsodimorlbassb","dcqdmnpirlwetexz","lnkkravbrdzuaixf","iqhikikqgoabcupoz","tqqnskydlxxyeloy","hoqhujloveotexob","tafrmbzoiiyxkrpv","gedftcwddbvqbcbp","tmlvgfxezfqhqlro","omkqddentowyusgs","uvmoywmfgcxprcob","wxaexnkxfscqpbvn","arouwkkwzmpxcraq","oshuiowfgoxvscum","wlcbjlvtpwbizxkk","pqdqfcardhablnlm","hncftotfykwkmcwc","ilbkfisyjvqmmjox","mjziuevwvgazkmrr","qxftpuleqzgeoxkn","qwfbcoulervauwzy","hzzahmyatnakmfkm","atlkeburbqttzgdv","chctjbylvaqivhnu","kljxzdlufmjsakrn","ldqznwrdmigxmplj","jnzsugujwghliiyj","davvfzptwjezrtut","ayvxlihyfxjghbnj","damnybtgbouyhgvm","xycclwykeleqgqbz","xcexkuimhauveeep","alawhglfqmrpujdu","ucqkzhnxzfmhrscm","giqfhrubpvulkbcz","ibjyvrczdfvorhxe","qbwwxgvtphqitwrc","nznctodxeivfdauc","gcelouuuaxwxmvsw","rqelrfgexnkdnazl","fbepvxtrhujvrdfc","iczbfakdstudncnv","qwyjcjokwchroxbr","ycjrzaetiivrrdkc","hjaflkntduxbssgu","rwfrleciyxwvxygj","pfkodbjvlrgvryzh","fyvawqjluonvjjxc","nzkedkvundnsfmnm","zkvlbpsldcyafkpj","hrnjhejkhdkcmnmh","sydwdkxfjjkvvbfk","ydznqbenlyrstgmu","katzotudzcpwwvkb","xucadxwemqvixtva","nnbzlmlmesntwwhh","sidmvrqryepebkda","zqlfnaleybermqpx","kduaxanohkcebsaj","jajuaudbrkkcnyyq","rhtefiqjirzhpjwt","tgbyhnyxxivxpebp","oqqwgmpqimqnjrxz","tptopmpejaaaxokz","rglhbkxoupbeqxhn","diannxikfirreuin","ilkjfpwdabcorejuk","tzygwhlicpqhsxsm","ednqyfigrhjjsixi","ichtvcqqxhzvwyrk","ckyoxfbufktqznpj","xoskspafepfgeeit","jcbtyhklimaasdfu","cfkabckzjghzapvxx","owdyarpowhkunwhy","etnyrgssgohswpva","ccdzytrxkxrfobiv","vxmwodlmkjmnanqf","lfoyuzoffzuzknom","avpouwwwczpcsixm","befuilgwreabcsjqn","wwlkjupnpinaskti","wuaufrnozwrcwrux","ddmlqscfylvvlqet","ngtehvarjqltinad","hxilufvmpbmybqse","sxckpnkpctadurmj","tkauepahazlgunce","wdnczbubbvaeugur","blbtvambkabhgfmt","hscywaqlqpzmajlw","kqbcyrflffoyrrde","swatgwoezppbhzrz","wncpezwknhwlkyfa","fxoalqugauheullc","yfejaqfwodcbvjxo","srdidycbfudekvry","wbmqrnpsbwvajyst","eojhwvsjkhruoihy","lebgsqpfytyfljzy","nlfrksicpahzoyzs","vwfuihhrcdfzahuq","zxossokxsiilrhwn","nnogzvnyavbajgxg","xudcsovkwdigfykp","oxnernpkebnwtzgk","lpkluymjfczcabbg","xwmoythsnnalagrd","bwxqduzhwponwuxh","tvqujorvigsrzqra","ruhirwfwnudvhndi","yigakwntqrddbxel","doyelkmwfiqrcvwf","nqepgxvwmpczbqmp","euwsrbwhhaosbuxv","qybvertwzftjmsbo","ovrxezhfnplztkrf","zhsklztsgdxqqlos","hjkalxuedegqevxf","acqcmxxnvxiyiarj","irfjxvnxvcwfggyf","ivjlvhotuhyjrbqi","ybowwazfbqnlxhix","rwldwkwiuokthyvd","emeoryhhzmchkcaf","wkjtfktltlxrpodu","zozxqufosbvhvzmk","kejjywawtflpnzxq","tgjqeqqyflstgyfn","edodalhdkbpbvbbi","svvbrdqtivcocuok","jqycfyojmcojaike","uysmgvolzqhvrjcg","jepqutdjnzdxpuis","htypdjotmvugsqrn","ruanlnsslyvcmloa","rmguapshfylrqcyw","idmrozfesprjyydi","igiijxxuaewkngez","mmfbpbxhjbbtaktl","wbryhbistnsnxcre","eyypsgultocxkddt","hmgsapmnlbhkldjy","srdiuczmorzzmqmx","jydlzvjtvssbiriv","xyxlubdngtpamnie","hzxhqmvdfeelavey","dnmkfxoqikbpnncm","uvykqjhcbjrkhwws","hcouhxnefskqtsmj","tlzdfixqvzmpnxey","bqthxadcjbuoihjb","amqcryxqrquugjds","kazopbofkzigbrjf","yoazjvgcjnuynogm","cekiuyvsxvnhllot","skaakenhygficler","vyyblxbztgjdxemi","cwijfnzpasohsysb","vxshtpkflepkegsv","dqlajjejvwkljffm","pdrurythrunegiyt","wyniiprlwdxayecx","onzimmmmwsczxrud","wahjycyykcusbzkh","pmxfomqplrchaeji","cuiofjxjmfwmwjpo","mqeyxhbjjhtyiqax","vxjtwryiiaiqmgxc","rpxhygecrrxsorep","pdhcrtkvutpxkjqk","xghqzhfjrcskksay","llatzvkvpehtkmlp","evcdafiqhelayolh","wnpjllgpnngclefg","cplkciggvoivrdrk","rwzojlohceoksqei","ibblbsqbtieahuip","rxymbuhpxlybbpwj","oufytsooclpjthdt","ladsdwyczkhlprsk","lqglakcncwvhbmdq","pvffqrafetpcnonv","ltxqocyoaqwqlclh","ujleyjgijrzxpohv","hdliszkijxjfdhuz","uerwlwcboltvibyv","frnvgotjrsmsvdrv","kprkmutaqpumileg","dyfntcyriixrbzpu","pljixloqwehtiyju","guvbkiuixwtllbyh","aywoiniduriovexc","xkhsubtnkyitnjuu","orgjwbnwirxnlvkv","tbnfpmbwrdvlcids","ljptwryckhaervnt","piklsbpqrpcwtkax","btjqiwzsjhtyrabp","xaqhoeyrofnixysd","ildloryxoleksykm","tpkrvszvlfvhpgua","uomslwptxjarrgtp","qfawaceubqhtfqia","xvsatjnexaphrcsq","chlowdcammoiqswp","vryqjuplbwlaomsw","zkndhkyqnmooseqy","oehmlodyfkbgwggc","ygicydiozmvrkjov","vffghaadldklcvpa","dudkmcpnwktzabcyc","cgpwhbxlqbydfial","xkeqyrbppiqzzdtc","aywomxmmicyapqry","qxrfswxmtgqwiaiu","ogesstqnbrqzcike","quvgbtgtjtgxrqez","ilrohxbbjzdyifwb","mwbgfsetpneteejs","awvqavqersnsgvym","lslutwvxqsgrasxf","hujsniqoktvleeph","tbibnfjtibcusfqc","jkeeyrhwuudkrzmx","rckpwpavcgvgmbqn","drzbjsuvjgfxgpzx","kmdsvposrrdokxzu","lapmakjdxbobqslx","awqhcznyrcbreinx","sgtrrbfxpgcdmlfi","hjvvuazaydvuqzfl","ukvueksttoovtqnx","fjcjtxrbzsrxelui","ynxnlswchgyljfah","ueznbslrhcswvlvg","ixvfnmhdbnowsido","tnvrbemiduyabcpgf","xicjxbvnripjquxk","pnguepiandvkkjgm","fmjuyijqtflklzrz","wowbwesqdjgbnfza","bzhqulhhfrmvlikt","xwwbxkpqwzuvbfcc","tzfeejglmxpjfiob","ttvlzzgyydwznuuj","zsaqdcbxiivqeibj","jqhivhimzrbhfjye","woxtmnynlehbynso","tweacunvvzvxvkhe","wvjiwrdllmbrzyzh","kpawpohuffukizip","culggzusblbzrbvp","rfiaujemuathqnrg","txcebmnimvozhnbq","lbpnqjkgkmqepuca","rqfueobyxicwpkao","rggegjcjqzhrkjqn","xbxlktpwwsergaut","lhowgnysedqhcquk","oqldregahyfprwsi","dizcwcthvgopgnwx","bzpodvsqzlmeakvy","vclpieckqkxhblhl","lnvngowxjpgdkwfv","yvkdxviywwowawba","zxymzgtfqsshclgz","boqkrbmnsxvbiema","hoeexawhwjrohbxe","luocnssrsnrlbmyi","tduuyggdvgbfgmhw","frvhgulszabsrunb","vcsontpzpacsgobo","kaiqymcnijuixgvp","vgfugfulxkppkurw","foudqjgejntrwhke","abldoxtbpltfnsni","kqxvgbgkkoakfeaj","rdkjzlwcpygzkshq","qfjxzlkyrpmuvlrf","depydkicbtuwrbuf","vmpfhqfgcyreyqdl","oneokdfkplafayzn","fjcerifwgajithlr","gtlxawvwmlmqsuuu","wgfxdchxqlzdxcpr","ajdrspwucswacivi","wjzhtgddolhaahmo","hbyrafvgohzefptw","roxblqysntdnkfqx","rmvrjdkeppblcmvy","xzgbkvnyxljluccp","dvvwfjxmydfdzqyt","kxxjltlgbaiguihx","rahukefeaibeekpq","spsdfgpofpoanurm","pjmewktbcytjsvrs","nhtbcrwqzoxbhkyi","eanjdepcqzqdeoea","ujhvaizclocaksng","tkucqzszyktwvyjq","dnummodkocgrdhbx","bzvvgfxvgzqjshji","ddctbuygjncstchf","mrpciqjmowzdjvsm","qhdgxhopljagfbfi","ksnimciprjexohfu","sdfgsfcwgaknzrqt","keiywmjuavometzf","pxdzshicopwmofxl","xdwlukdaxhwjojeq","krnlgjtxhnuntwsa","bpnrhdwfkagaubka","beoyleogpryyjcmv","rrhlmtgpyfszchsi","ozdknlljectjisdg","wdobdazbwjecqcep","jfxjpbzonkvxltib","fwcffctkbvpkgexm","gornbkdvwuqirrlk","yyiqngwrxevbwchf","ggyqhxvbjwyzuxwf","ixhwkhgotdmkamtj","dbqqdygrhtysgxgw","mzwmkjfknwfhulgv","xtngfkkjuaonbemi","vghhkblxwbijsqwi","fkfulljgmpkmvxwn","kqdckewxfcwyjkuo","msaxmgcjerovxgqo","bswhhcxiljhjeivr","lwllrzomgnjzjqxh","gugxbiwfpjbtscyw","mmqsxwrnsiprrmyv","pdjccwbewqxbhgzn","mshemwgzytwmqljx","moezekitiafkvsqr","edthrvvafeypjypw","qspowcqalsukqhhy","wasrmlhgjgalcbrb","dglyfamnfpqkmteh","xgpvsclrqskbjnao","iawgyqoqnmxmwtrk"])
s = calc([num1, num2, num3])
（因为常量过多所以啃汇编需要去掉大量的不必要信息，特别烦人）
要让它吐出s，我们首先就是要拿到str：
def decode(s):
ret = ""
for i in range(0, len(s), 3):
num1 = (s[i] << 3) + (s[i + 1] >> 3)
num2 = ((s[i + 1] & 7) << 4) + s[i + 2]
ret += chr(num1) + chr(num2)
return ret
coded_str = [[12, 22, 1], [12, 14, 2], [12, 22, 3], [12, 30, 2], [12, 22, 4, 12, 30, 1], [12, 22, 1, 12, 30, 4],
[12, 22, 2, 12, 22, 2], [12, 22, 2, 12, 22, 2]]
for i in range(len(coded_str)):
print("str"+str(i+1)+" = \""+decode(coded_str[i])+"\"")
然后是借用str求num，这里直接照搬源码都没问题。接下来把所有的变量塞到空缺项里头就能得到flag了。
比赛前：来了来了它来了，RWCTF它来了
比赛后：看我看我，我宣布个事，我是个（）
所以为什么这场比赛一道逆向都没？什么？体验赛也没有？算了，拣点简单的题复现一下，也算是拓宽眼界了
（所以大概还是不定期更新）
可谓是这次RealWorld在做法上最简单的一道题，不得不尝。
一上来先把脚本都给你了让你去拆解sha256——
跟着到github上扒下源码直接用，它会让你连上另一个端口——
那连都连上去了，试几个常用指令呗——
啊？我cat flag都还没打呢？可这道题明摆着又是pwn标签，看来问题只能出在程序里头了，我们解包出来看看——
开头就是一个简单的字符过滤。问题出在接下来的一段——
我们输入的其它指令过不了这个宽松的判定，是它容许的指令集里面并没有相应的子串，但sh在前面可是确实有个showKey包含的。而也正因如此，在sh前面加空格反而会弄巧成拙导致判定出空指令。
而下面有一段popen可以触发sh，所以当你输入sh flag的时候，它会直接识别到sh然后把flag拱手让人。
当然，还有一种理论可行的办法，就是用卡随机数种子的办法强行把openthedoor指令过了，但是这玩意，nep那边有两位老哥扫了半天还是Fail to get shell，所以基本可以pass了。
反正RealWorld也打麻了，刚好看到了NSS R17，就想着打一手，结果进去一看只剩一个多钟头，再加上忘记了RSA长啥样，于是乎当了一个钟头笨比来不及看题。
于是乎，这里算是一个后续补票（不定期更新）的题解记录档。
（那边干脆没有RE，这边的RE又上强度，我缺的这块RE上哪补啊）
RSA模板题，但是p和q分别等价于两个RSA式子的e。
from Crypto.Util.number import long_to_bytes
import gmpy2
n = 22517647586……
c1 = 143239309626……
c2 = 1329967939289……
p = e1 = 15586169039……
q = e2 = 14447198365282……
phin = (p - 1) * (q - 1)
d1 = gmpy2.invert(e1, phin)
d2 = gmpy2.invert(e2, phin)
print(long_to_bytes(pow(c1, d1, n)))
还是RSA，但是叫你嗯猜e和p，p在文件里有给直接爆，e因为题目有提示所以很明了，65537一代，完事
from Crypto.Util.number import long_to_bytes
import gmpy2
c = 1744181471440……
q = 14572173647052……
e = 65537
f = open("ps.txt", 'r').readlines()
for p in f:
intp = int(p)
n = intp * q
phin = (intp - 1) * (q - 1)
d = gmpy2.invert(e, phin)
try:
print(long_to_bytes(pow(c, d, n)).decode())
except:
continue
虽然说一看就是非常粗糙的贪吃蛇，但是die一看，Go>=1.15，再一看IDAGolangHelper，没有对应的go标志，好吧，IDAGolangHelper莫得1.19支持，只能手搓了。
通过查找在界面上出现的字符一路跟到snake_pkg_app_Run，看到了熟悉的wasd：
顺藤摸瓜找到main，又发现了可能是判定条件的东西：
loc_4A3301:
cmp rax, 0Ah
jl short loc_4A328D
jnz loc_4A338B
cmp cs:qword_569E78, 190h
jnz short loc_4A338B
也就是：
if ( i == 10 && qword_569E78 == 400 )
结合snake_pkg_app_Run相关的操作，不难得出qword_569E78就是得分，那么i就是步数了：
for ( i = 0LL; i < 10; i = v11 + 1 )
{
v11 = i;
snake_pkg_app_Run();
……
}
十步以内得到四百分，骗鬼哦，我们直接把步数判定扬了，然后再把分数判定改成0，patch完直接运行：
./snake.exe
success!
flag{da39a3ee5e6b4b0d3255bfef95601890afd80709}
完美（才不会告诉你因为过不了判定以为是反调试搓了一个钟头呢
ps.在做这道题之前请注意如下内容：
If “notepad.exe” in #flareon4 on Win10 crashes just patch 0x01013C54 to make it “push 0x6e2bca17”
ps.2 以及，flareon上的原装题目大概率只适用于win7及以下部分版本的windows，建议部分无法正常打开的题目替换为buu上的移植版食用
打开一看，除了一开始会显示某些莫名其妙的时间之外，似乎就是一个普通的32位记事板？
虽然不知道它在干什么，但是当我们点进去的时候，我们会看到start调用了一些东西：
strcpy(v27, "%USERPROFILE%");
strcpy(v8, "\\flareon2016challenge");
strcpy(v10, "ImageHlp.dll");
strcpy(v9, "CheckSumMappedFile");
strcpy(v15, "user32.dll");
strcpy(v12, "MessageBoxA");
FlareOn4是2017年的，我们要把上一届比赛（16年）的题目给弄下来放自己的用户文件夹里头。试着再度运行，但是除了什么跟刚才一样之外都没发生……等下，什么时候多出来一个key.bin？
虽然但是，我们回头先看看程序本体，主函数里面出现了成吨类似的结构：
v16[0] = sub_1015310((int)v5, 0x63D6C065);
动态调试可以发现其实际上是对kernel32.dll库的调用，每次将一个函数的地址压栈。而我们将整个调用链拉出来会发现，start部分似乎就是将上述文件夹中符合条件（并且这个条件多半和文件的更新日期，也就是题目文件编译的日期有关系）的程序提出来，塞点什么。
Stack[00000840]:000DFEF0 aUser32Dll_0 db 'user32.dll',0
Stack[00000840]:000DFEFB db 0
Stack[00000840]:000DFEFC dd offset kernel32_FindFirstFileA
Stack[00000840]:000DFF00 dd offset kernel32_FindNextFileA
Stack[00000840]:000DFF04 dd offset kernel32_FindClose
Stack[00000840]:000DFF08 dd 0
Stack[00000840]:000DFF0C dd offset kernel32_CreateFileA
Stack[00000840]:000DFF10 dd offset kernel32_CreateFileMappingA
Stack[00000840]:000DFF14 dd offset kernel32_MapViewOfFile
Stack[00000840]:000DFF18 dd offset kernel32_CloseHandle
Stack[00000840]:000DFF1C dd offset kernel32_WriteFile
Stack[00000840]:000DFF20 dd offset kernel32_GetFileSize
Stack[00000840]:000DFF24 dd offset kernel32_FlushViewOfFile
Stack[00000840]:000DFF28 dd offset kernel32_LoadLibraryA
Stack[00000840]:000DFF2C dd offset kernel32_GetProcAddress
Stack[00000840]:000DFF30 dd 0
Stack[00000840]:000DFF34 dd offset kernel32_GetModuleHandleA
Stack[00000840]:000DFF38 dd offset kernel32_UnmapViewOfFile
Stack[00000840]:000DFF3C dd 0
Stack[00000840]:000DFF40 dd 0
Stack[00000840]:000DFF44 dd 0
Stack[00000840]:000DFF48 dd 0
Stack[00000840]:000DFF4C dd offset kernel32_ExpandEnvironmentStringsA
Stack[00000840]:000DFF50 dd offset kernel32_FileTimeToSystemTime
Stack[00000840]:000DFF54 dd offset kernel32_GetTimeFormatA
Stack[00000840]:000DFF58 dd offset kernel32_GetDateFormatA
Stack[00000840]:000DFF5C dd offset kernel32_ReadFile
问题来了，是哪几个程序呢？比较简单粗暴的办法是挨个试一遍，最后，发现challenge1、DudeLocker、khaki和unknown在题目的notepad运行之后，都会有一些莫名其妙的弹窗，而唯独unknown的弹窗是”What’s wrong with my keyfile?”。
不用猜，unknown肯定是最后一个打开的程序，而第一个肯定是notepad.exe。至于剩下几个的顺序，一种办法是挨个试一遍，三个相异元素的全排列而已（实际上你直接按首字母排序的话，顺序运行下来就是一遍过）。还有一种是按时间查找，但是因为部分题目使用的是buu的移植版，使用上一个打开的程序的弹窗里的时间可能还是对不上号。
至于最后一种，每次运行完上一个程序，key.bin里肯定会多出些什么，直接将里面每次多出的内容到还没打开的程序里挨个找一遍，绝对会找到匹配的结果，以DudeLocker为例：
反正怎么顺手怎么来。最后的flag一定是：
谁家好人会用自己出过的题目当题目内容，还放在C盘占空间的啊kora
看到代码的一瞬间，我有点害怕这玩意会不会有什么php特性：
<?php $o__o_ = base64_decode(
"QAYLHhIJbzIQC..."
);
$o_o = isset($_POST["o_o"]) ? $_POST["o_o"] : "";
$o_o = md5($o_o) . substr(MD5(strrev($o_o)), 0, strlen($o_o));
for ($o___o = 0; $o___o < 2268; $o___o++) {
$o__o_[$o___o] = chr((ord($o__o_[$o___o]) ^ ord($o_o[$o___o])) % 256);
$o_o .= $o__o_[$o___o];
}
if (MD5($o__o_) == "43a141570e0c926e0e3673216a4dd73d") {
if (isset($_POST["o_o"])) {
@setcookie("o_o", $_POST["o_o"]);
}
$o___o = create_function("", $o__o_);
unset($o_o, $o__o_);
$o___o();
} else {
echo '<form method="post" action="shell.php"><input type="text" name="o_o" value=""/><input type="submit" value=">"/></form>';
} ?>
但好在事实上并没有。不过这么长的密文看上去有点哈人，还拿字符串正反两遍的md5的合体做key，64位，看着更哈人了。不过就没啥招解决吗？
注意看这一句代码：
$o_o .= $o__o_[$o___o];
如果说这个for要正常运行不至于抛出索引越界（毕竟key只有64位，但这for的上限足足2268），那这个.=只剩下一种可能：拿加密后的字符当key的末尾继续加密。也就是说，第65位开始都可以用前文直接爆。
可问题在于：在生成后续的key之前，前文也必须得被加密啊，所以根本问题还是怎么爆出原文和key。
一种很浅显的办法就是遍历所有可能用到的php函数，因为密文解密的结果实际上就是php代码：
@setcookie("o_o", $_POST["o_o"]);
create_function("", $o__o_);
但是逆向手可能很难知道所有可能的CTF常用php函数，所以赛场上得去请教web手或者挨个试一遍。
另一种更简单的办法，MD5本身只有16个字符的字符集，我们直接循环前64位，对于每一位，根据之前的算法来看，从第一次根据key加密过后，之后每64位的加密都是以前64位为key加密，也就是说，我们爆破每一位key的时候，只需要向后以64为间隔循环异或，检测值是否为阳间字符就行了。（思路参考Thomasd的博客和mkhdznfq的博客）
from base64 import b64decode
f = open('output.txt', 'w')
crypted = b64decode("QAYLHhIJbzIQC...")
def check(offset, tmp):
for sit in range(offset, 2268, 64): # 以64为间隔开始遍历，判断是否为正常字符
tmp = (crypted[sit] ^ tmp) % 256 # 继续以当前加密字符为key向后遍历
if 32 <= tmp < 127 or tmp == 10 or tmp == 13: # 若为正常字符
continue
return -1
return 1
for i in range(64): # 剩下的事情就是遍历md5字符集了
output = 'md5set[' + str(i) + ']=['
for j in md5charset:
if check(i, ord(j)) == 1:
output += '\'' + j + '\', '
output = output[:-2] + ']'
print(output, file=f)
f.close()
但是如果是纯暴力，最后爆出来的产物还是会产生一些不定结果。但既然都暴力了那为什么不爆到底呢？递归生成树，挨个试一遍！
然而最后发现根本跑不通。究其原因还是64位的超长key带来的巨大运算量让人难以接受（足足10^28种可能性）。那剩下的只能是先手动调整key，看看能不能产生一些可能可以看见的结果：
from base64 import b64decode
from hashlib import *
crypted = b64decode(
"QAYLHhIJbzIQCl...")
key = "..."
key = [char for char in key]
output = ""
for i in range(len(crypted)):
output += chr((crypted[i] ^ ord(key[i])) % 256)
key += output[i]
print(output)
这个过程是相当漫长与折磨的。就算你脑子里有一万种php指令，调整key也得半天。所以我们需要把可能的明文也打印出来，看看到底啥玩意是可能整理出一个可用的cookie的明文，然后再找对应的key：
from base64 import b64decode
f = open('output.txt', 'w')
f2 = open('output_origin.txt', 'w')
crypted = b64decode("QAYLHhIJbzIQC...")
md5charset = "0123456789abcdef"
def check(offset, tmp):
for sit in range(offset, 2268, 64): # 以64为间隔开始遍历，判断是否为正常字符
tmp = (crypted[sit] ^ tmp) % 256 # 继续以当前加密字符为key向后遍历
if 32 <= tmp < 127 or tmp == 10 or tmp == 13: # 若为正常字符
continue
return -1
return 1
def exchange(tmp):
if 32 <= tmp < 127:
return chr(tmp)
else:
return '\\x' + str(tmp)
for i in range(64): # 剩下的事情就是遍历md5字符集了
output = 'md5set[' + str(i) + ']=['
output_origin = 'original_set[' + str(i) + ']=['
for j in md5charset:
if check(i, ord(j)) == 1:
output += '\'' + j + '\', '
output_origin += '\'' + exchange((crypted[i] ^ ord(j)) % 256) + '\', '
output = output[:-2] + ']'
output_origin = output_origin[:-2] + ']'
print(output, file=f)
print(output_origin, file=f2)
f.close()
f2.close()
然后再把生成的可能明文和可能key一个个比对，看看什么样的key组合可以凑出一个算是cookie的明文。这个过程需要比较繁琐的手工，但没办法，谁叫电脑也不一定跑得动呢？
手操得出key=db6952b84a49b934acb436418ad9d93d237df05769afc796d067bccb379f2cac，再塞回去得到cookie：
$d='';
$key = "";
if (isset($_POST['o_o']))
$key = $_POST['o_o'];
if (isset($_POST['hint']))
$d = "www.p01.org";
if (isset($_POST['t'])) {
if ($_POST['t'] == 'c') {
$d = base64_decode('SDcGHg1feV...');
$key = preg_replace('/(.)../', '$1', $key);
}
if ($_POST['t'] == 's') {
$d = base64_decode('VBArMg1H...');
$key = preg_replace('/.(.)./', '$1', $key);
}
if ($_POST['t'] == 'w') {
$d = base64_decode('DycdGg1hYj...');
$key = preg_replace('/..(.)/', '$1', $key);
}
while(strlen($key) < strlen($d))
$key = $key.$key;
$d = $d ^ $key;
}
if (strlen($d))
echo $d;
else
echo '<form action="shell.php" method="post"><input type="hidden" name="o_o" value="'.$key.'"><input type="radio" name="t" value="c"> Raytraced Checkboard<br> <input type="radio" name="t" value="s"> p01 256b Starfield<br> <input type="radio" name="t" value="w"> Wolfensteiny<br><input type="submit" value="Show"/></form>';
但是这里的preg_replace又在干什么？其实通过在线编译，我们可以知道这里的每一项preg_replace都分别在取key中每3个字符的第一/二/三个，分别组成一个新的key用于进行异或：
剩下的事情就好办了，爆！
啊？！
所以这个POST的key传进来的时候还带变的是吗？这下多爆三个密文了，这么玩是吧.jpg，更悲惨的是这回不是md5了，这下任何字符都有可能了。
而且，还有一件可怕的事情，我们到现在依旧不知道flag是藏在代码里还是就是哪一个环节的key。
不过嘛，思路还是有的。注意这里：
if (isset($_POST['hint']))
$d = "www.p01.org";
我们点进去一看，发现这是个压行老哥的博客，专注压行二十年。但我们不止要查看相关的代码，从直觉上看，上述密文拼接起来有足足998个字符，而整个网页字数相近且符合出题日期，并且含有有效代码的文章有：DWITTER SON1K、WOLFENSTEINY、TEA STORM等。而它们之中的代码都是html。顺着这条线索，我们推测原文当中应当含有“<body”之类的，html特有的字段。并且，由于第三部分的长度比第1、2段甚至多出整整42个字符，我们甚至可以直接开始暴力循环密文后42位，看看有没有什么捞的着的东西：
from base64 import b64decode
code = [[] for i in range(3)]
code[2] = b64decode('DycdGg1hY...')
origin = "</body>"
origin = [ord(char) for char in origin]
# 密文最短只有316位
for i in range(316, len(code[2]) - len(origin)):
tmp = ""
for j in range(len(origin)):
tmp += chr(code[2][i + j] ^ origin[j])
print("offset %i decode is %s" % (i, tmp))
最后结果也就三个能看的，还都是乱码。但是，秉持着不会做就瞎蒙乱猜的原则，这三个能看的结果当中，也就一个能和网页沾上边的：部分密文^'</body>'=@a-.m3Q
且慢，如果我们看一看原比赛的网址：
__@__a__-__.__m__3__Q
flare-on.com
* * * *
W……T……F……什么顶级抽象脑洞
然后我们有端联想一下，这玩意的末位如果真是“@+比赛官网”，那我们不就可以通过暴力向前遍历完整版密文找到key可能的长度，进而暴力遍历可能的字符找到flag吗？所以我们直接对着三段密文挨个试一遍：
from base64 import b64decode
code = [[] for i in range(3)]
code[0] = b64decode('SDcGHg...')
code[1] = b64decode('VBArMg1H...')
code[2] = b64decode('DycdGg1h...')
possible_key = [[] for i in range(3)] # @flare-on.com，但根据原算法，一份key拆三份用
possible_key[0] = 'froc'
possible_key[1] = 'leno'
possible_key[2] = '@a-.m'
f = open("burp_second_output.txt", 'w')
for i in range(3):
f.write("in code %i:\n" % i)
for j in range(len(code[i]) - len(possible_key[i])):
tmp = ""
possible_tag = 1
for k in range(len(possible_key[i])):
c = (code[i][j+k] ^ ord(possible_key[i][k])) % 256
tmp += chr(c)
if c < 32 or c > 126:
possible_tag = 0
if possible_tag == 1:
f.write(" offset %i decode is %s\n" % (j, tmp))
于是我们可以清晰地看到一些字段中浮现了html相关字段，以及这位p01老哥的部分代码字段。其中以这里尤为明显：
考虑到这个箭头应该不太可能凭空出现（实际上那是html的注释标志），我们姑且认为flag长度在39左右。这样的话，每部分key还有8~9位未知。于是我们开始尝试爆破，再结合wolfensteiny文章的源代码，原文的算法之类的，以及之前的暴力代码多跑几遍一顿瞎猜：
from base64 import b64decode
f = open('output2.txt', 'w')
f2 = open('output2_origin.txt', 'w')
code = [[] for i in range(3)] # 继续拆成三个解
code[0] = b64decode('SDcGHg1f...')
code[1] = b64decode('VBArMg1HY...')
code[2] = b64decode('DycdGg1hYjl8...')
keylen = [13, 13, 13]
def check(offset, enc, tmp, keyl): # 输入当前偏移量、待解密字符串、当前待判断key位，当前key长度
for sit in range(offset, len(enc), keyl):
c = (enc[sit] ^ tmp) % 256
if 32 <= c <= 126 or c == 10 or c == 13:
continue
else:
return -1
return 1
def exchange(tmp):
if 32 <= tmp <= 126:
return chr(tmp)
else:
return '\\x' + str(tmp)
for i in range(9): # key剩余位数第i位
for k in range(3): # 第k个密文串/key
output = 'possible_key[' + str(3*i+k) + ']=['
output_origin = 'original_set[' + str(3*i+k) + ']=['
for j in range(32, 127): # ascii表第j个可用字符
if check(i, code[k], j, keylen[k]) == 1:
output += '\'' + chr(j) + '\', '
output_origin += '\'' + exchange((code[k][i] ^ j) % 256) + '\', '
output = output + ']'
output_origin = output_origin + ']'
print(output, file=f)
print(output_origin, file=f2)
f.close()
f2.close()
考虑到剩下的密文也极有可能是html代码，那么开头的字符也很有可能是三个重复的html头，并且按出题人的习惯还会接两个不同ascii码的换行，我们照着这个思路一个位一个位的比对：
# th3_xOr_is_waaaay_too_w34k@
t_rsaatwk
<html>
hx__ayo3@
<html>
3Oiwa_o4
<html>
这不但验证了我们之前对key尾的猜想，还把前面完完整整的吐出来了。所以最后的结果应该是：
th3_ xOr_ is_ waaaay_ too_ w34k@flare-on.com
顺带，你把这个key放到php运行器上解密，你会发现这些明文都是p01老哥的杰作……套了些不明所谓的玩意。
ps.1 你确定这题真的不放在misc或者crypto？
ps.2 在最后的爆破环节我一开始把长度当40看爆了半天，还调了一整个晚上的算法，最后才发现其实是我一开始看的39，我人傻了（各种意义上）
ps.3 出题人你(wo)没(cxx)有(ni)心(mx)
ps.4 buu导题的时候导错了flag导致中间的’O’变成’0’才能过，忘周知
一上来发现像是迷宫题，但又不那么正统，我们的视野直接被封死了，目前唯一可以得到信息的途径就是h(elp)和l(ook)：
Game commands:
h[elp] - See this help
q[uit] - Exit the game
Area commands:
l[ook] [object] - Look at the room [or at an optional object)
n[orth] - Move north
s[outh] - Move south
e[ast] - Move east
w[est] - Move west
u[p] - Move up
d[own] - Move down
Personal commands:
say <someone> <words...> - Say <words...> to <someone>
wear <inventory-item> - Put <inventory-item> on
remove <thing> - Take <thing> off
Inventory commands:inv[entory] - Check your inventory
get <object> [location] - Get object [from within optional location])
drop <object> - Put object down
方向键并不是wasd而是东南西北，但不管怎么说，我们都应该四处转转。往南走是outside直接死路，往北走的话，里面会有一些奇怪的结构，于是我们直接画一张地图，顺带把有关键道具的地方给标注了：
但是我们对于现在要做的事情一头雾水，遂喂die和ida，找到一条鲸鱼以及它的所在函数和地址：
但打开程序跟进网页之后也只剩下一条鲸鱼：
其它什么也没有，感觉脑子要喂鲸鱼了。但是我们发现，打开时会出现一个clrhost的调试信息，搜一下是个能在汇编程序中打开一个CLR环境，并通过一个自启动的控制台跑C#代码的玩意。相关内容可以参考CLRhost本体以及lidandan2016
的文章。
我们还发现某些函数调用了一些空全局变量作为函数，可能在程序运行过程中会有一些对.NET调用库的解码也说不定？用CheatEngine一开果真看到了不对劲的whiskey_tango_flareon.dll。
虽然但是，回到解谜游戏本体，我们似乎发现从drawers里拿走钥匙之后，再前往Mandiant offices，key上不但有新内容，我们还发现有新路可以走了，新路连到的work area似乎是一个无限大且方向延伸为6个的空间：
> l key
You BANKbEPxukZfP2EikF8jN04iqGJY0RjM3p++Rci2RiUFvS9RbjWYzbbJ3BSerzwGc9EZkKTvv1JbHOD6ldmehDxyJGa60UJXsKQwr9bU3WsyNkNsVd/XtN9/6kesgmswA5Hvroc2NGYa91gCVvlaYg4U8RiyigMCKj598yfTMc1/koEDpZUhl9Dy4ZhxUUFHbiYRXFARiYNSiqJAEYNB0r93nsAQPNogNrqg23OYd3RPp4THd8G6vkJUXltRgXv7px2CWdOHuxKBVq6EduMFSKpnNB7jAKojNf1oGECrtR5pHdG1LhtTtH6lFE7IVTEKOHD+TMO1VUh0Bpa37WhIAKEwpuyp5+Tspyh0GidHtYcNWfzLNBXymmrhzvta2nJ+FtI6KWXgAAMJdUCy6YrGbWFoR2ChpeWlZLf7cQ1Awh27y6hOV19R6IKOpQzCOQLNjUplm4SOltwRU0pH6BYCeoYXbyRl3kk92uXoBsBXwxdo9QoLBOAdJmKnN95VBT03a+jS3ku3YLwXR29GIlsCfdkVKr4J1d/Xal//e+Bqq1xMEucIdnNSwr4hlOtdpLrPyfnCVkBcadlRC6hGitbptCknTCUniXCCOE1NkWSVi3v5VrXkPGAvw/iRu7F2BimC+o3tIdWPpxkcfks6zVQSiFJjVzrt28+QUb28+YRaCkPhfZALYKQLU3DR5YJw64sL40tykTI68evyRF/Fnp4VTNlWQHXPJ+Y6yCHZnrb8NdIRDPfm1wxOQJbdeaEZSa3AgqI2wW0pPBnf69vVAq4qjxyrI1LPL9hzd7cBfqnohjyDy/t78TZOh0hX++W6zkMl0Ez6I2CHxop3vzg1/9iQig0WAglmdqiAhKbDFSM7kGPf5Reyphx27uzxHAllP7LrX1vF7o9v4vcCrHE7dJpuisSWhsx3rtJsBA15mdMAbuj1ErOpWLMbXCYfhpSj6GLOHOU/PqeDoktZs9BLS+V11PcxaVVwHBGfCimMe61mSFD0hhYJXgTxbwKDvIS...
----------
> n
...
You go north
The key emanates some warmth...
the Mandiant offices
This is where the magic happens. To the west, open work areas, cubicles, offices, and adjustable desks stretch out and intersect in a dazzling maze as far as the eye can see.
Exits: North South East
但是这个key到底是用来开啥的尚且未知，我们拿着钥匙稍微走走，会发现部分操作会使得钥匙变热并且让密文部分解密，部分输出Hmm...并导致解密停止。
> n
You go north
The key emanates some warmth...
the northeast hallway
This hallway links the snack/lunch area with the IT access junction.
Exits: South East
> l key
You can start to zXykaHk29xWQzs7kNrmhu4oN0TsxM7iyJ4tmttuCijPJ2G0VA3xCFLvUnmYb/P3Ae+sO/wdNm1OpZX5AltsADOBqgr2uErcM9BeKqlOCmfH2SPfDXoZN7p5PoZe9RPv0reF1C6Rse23MtetFeffgvPztw/ZRnxIiAg9jKhL8……
思来想去，应该是要让钥匙全程红温才能把这一大串密文解密完成。问题来了，我们该怎么走才能让钥匙全程热乎呢？
一种方法当然是暴力走无数遍，直觉来看，表层肯定是顺时针或者逆时针把整个有限部分转一遍（测试是从大厅开始顺时针，然后宿舍先女后男），然后再去无限房摸路，但是那样未免也太耗时间（参考Thomas佬的题解，他的暴力代码整整走了一个钟头）。
另外一种就是直接通过IDA的东西提取dll，然后从里面找寻路的办法。我们先从CE里头看上面提到的dll的函数包含：
再从IDA里头找到对应的MZ头：
然后把所有看着挺像的东西dump出来塞进DNSpy里：
private static string Decrypt2(byte[] cipherText, string key)
{
byte[] bytes = Encoding.UTF8.GetBytes(key);
byte[] array = new byte[16];
byte[] iv = array;
string result = null;
using (RijndaelManaged rijndaelManaged = new RijndaelManaged())
{
rijndaelManaged.Key = bytes;
rijndaelManaged.IV = iv;
ICryptoTransform transform = rijndaelManaged.CreateDecryptor(rijndaelManaged.Key, rijndaelManaged.IV);
using (MemoryStream memoryStream = new MemoryStream(cipherText))
{
using (CryptoStream cryptoStream = new CryptoStream(memoryStream, transform, CryptoStreamMode.Read))
{
using (StreamReader streamReader = new StreamReader(cryptoStream))
{
result = streamReader.ReadToEnd();
}
}
}
}
return result;
public static int Smth(string arg)
{
using (PowerShell powerShell = PowerShell.Create())
{
try
{
byte[] cipherText = Convert.FromBase64String(arg);
string script = four.Decrypt2(cipherText, "soooooo_sorry_zis_is_not_ze_flag");
powerShell.AddScript(script);
Collection<PSObject> collection = powerShell.Invoke();
foreach (PSObject value in collection)
{
Console.WriteLine(value);
}
}
catch (Exception ex)
{
Console.WriteLine("Exception received");
}
}
return 0;
}
虽然知道我们的钥匙经历了AES加密，Key是soooooo_sorry_zis_is_not_ze_flag，但IV未知（八成是输入的路线转换成的东西）。这时候，从CE看运行时内存，我们又会发现一些对其它指令的解码，且基本以function打头（如下是字节码放进赛博厨子烤的结果）：
function Invoke-MoveDirection($char, $room, $direction, $trailing) {
$nextroom = $null
$movetext = "You can't go $direction."
$statechange_tristate = $null
$nextroom = Get-RoomAdjoining $room $direction
if ($nextroom -ne $null) {
$key = Get-ThingByKeyword $char 'key'
if (($key -ne $null) -and ($script:okaystopnow -eq $false)) {
$dir_short = ([String]$direction[0]).ToLower()
${N} = ${sC`Ri`Pt:MS`VcRt}::("{1}{0}" -f'nd','ra').Invoke()
这不就是我们在程序控制台里看到的东西吗？在这里，我们可以看到key的初定义，看到各种输出，甚至是——不对，上面那个不就是行动轮的代码吗？顺藤摸瓜找到全局变量direction的定义：
$directions = @('n', 'north', 's', 'south', 'e', 'east', 'w', 'west', 'u', 'up', 'd', 'down')
$directions_short = @{'n' = 'north'; 's' = 'south'; 'e' = 'east'; 'w' = 'west'; 'u' = 'up'; 'd' = 'down'}
$directions_enum = @{'n' = 0; 's' = 1; 'e' = 2; 'w' = 3; 'u' = 4; 'd' = 5}
$prepositions = @{'north' = 'north of'; 'south' = 'south of'; 'east' = 'east of'; 'west' = 'west of'; 'uu' = 'above'; 'down' = 'below'}
很好，我们现在只需要在程序的静态资源里头找到一串只有0~5的序列就行了。dword列表一翻，很快的找，然后简单转换一下变成路线：
way = '30022111023022333540540540140240123540123123123123540'
dir = 'nsewud'
oput = ""
for i in way:
oput += dir[ord(i) - 48]
print(oput)
按照路线走就会传送回大门，然后你的key变成了这样：
> l key
You can start to make out some words but you need to follow the RIGHT_PATH!@66696e646b6576696e6d616e6469610d0a // findkevinmandia
好，这就去找Kevin。不过在此之前，这里还有一个函数——
function Invoke-Say($char, $room, $trailing) {
$resp = "It doesn't talk back"
$ar = $trailing.Split()
if ($ar.Length -lt 2) {
return "Syntax: say <someone> <words...>"
}
$to_whom = $ar[0]
$words = $ar[1..99999]
$thing = Get-ThingByKeyword $room $to_whom
if ($thing.Name -eq "Kevin Mandia") {
$resp = "Kevin says a friendly 'hello' and then looks back down at his computer. He's busy turbo-hacking."
$key = Get-ThingByKeyword $room 'key'
$helmet = $null
foreach ($thing in $char.Wearing) {
if ($thing.Keywords -contains "helmet") {
$helmet = $thing
}
}
if (($key -ne $null) -and ($helmet -ne $null)) {
$md5 = New-Object System.Security.Cryptography.MD5CryptoServiceProvider
$utf8 = New-Object System.Text.UTF8Encoding
$hash = [System.BitConverter]::ToString($md5.ComputeHash($utf8.GetBytes($key.Desc)))
$Data = [System.Convert]::FromBase64String("EQ/Mv3f/1XzW4FO8N55+DIOkeWuM70Bzln7Knumospan")
$Key = [System.Text.Encoding]::ASCII.GetBytes($hash)
# Adapated from the gist by harmj0y et al
$R={$D,$K=$Args;$H=$I=$J=0;$S=0..255;0..255|%{$J=($J+$S[$_]+$K[$_%$K.Length])%256;$S[$_],$S[$J]=$S[$J],$S[$_]};$D|%{$I=($I+1)%256;$H=($H+$S[$I])%256;$S[$I],$S[$H]=$S[$H],$S[$I];$_-bxor$S[($S[$I]+$S[$H])%256]}}
$x = (& $r $data $key | ForEach-Object { "{0:X2}" -f $_ }) -join ' '
$resp = "`nKevin says, with a nod and a wink: '$x'."
$resp += "`n`nBet you didn't know he could speak hexadecimal! :-)"
}
}
return $resp
}
看样子我们得在完成一系列步骤后去老板办公室把头盔带上，再把key撇了。于是我们照做试试看：
> get helmet
You get A football helmet.
> wear helmet
You put the helmet on your head. It looks objectively awesome.
> drop key
You drop a key
> say kevin hi
Kevin says, with a nod and a wink: '6D 75 64 64 31 6E 67 5F 62 79 5F 79 30 75 72 35 33 6C 70 68 40 66 6C 61 72 65 2D 6F 6E 2E 63 6F 6D'.
Bet you didn't know he could speak hexadecimal! :-)
flag到手！
题目为XCTF2023的“我不是病毒2.0”
die查看，发现是个拟态C++，实际上是个python3.10程序，万幸它没用3.11，遂直接用pyinstxtractor和pycdc跟它爆了。
具体怎么爆可以看fortinet上的教程、一篇有关解码加密pyc的文章，以及Redamancy的博客。第一步肯定还是尝试使用pyinstxtractor拆解exe文件，但当你拆解完成之后，你会发现主函数对一个 意⭐义⭐不⭐明 的pyc进行调用：
import sign
sign.main()
这意味着源代码其实是在解压出的pyc包中的这个自定义pyc模块：
但是怎么解码呢？我们得先明白，这个python程序是如何打包的，以及为什么会出现这样的加密数据：
（资料参考王小希ww 的博客和琴声悠悠-悠悠琴声 的博客）
目前python程序的打包方式主要是通过PyInstaller或setupTools来实现的。前者是将python文件及其调用模块打包成一个可执行文件（exe/elf），后者则是将其作为python用的软件包打包，并发布到PyPI或者其它软件包管理器中，作为其它python程序的调用库被下载和使用。当然，你也可以选择直接拷贝一份你的运行环境并写一个启动程序，不过，这种方法的稳定性、高效性和安全性就取决于你的代码能力和肝度了（笑
关于pyinstaller打包命令参数如下：
-w 表示希望在生成的.exe程序运行过程中，不要出现cmd黑框，一般用于打包GUI界面
-F：表示希望将所有的程序全部打包在一起，生成的只有一个.exe文件，这样的文件集成度高，但是运行速度慢
（如果不写-F，生成的还有一堆.dll文件，这样的程序里文件很多，但是运行速度比较快）-D：生成一个文件目录包含可执行文件和相关动态链接库和资源文件等
（对于打包结果较大的项目，选用-d生成目录相比单可执行文件的打包方式，执行速度更快，但包含更加多的文件）-p：自定义需要加载的类的路径
-i：自己做的软件可以放上自己的图标，分享一个网站，可以把其他格式图片转成ico格式
需要注意的是，被打包的python文件在import某个包内的其它模块的时候，需要添加调用包的根目录名，或者将被调用模块的根目录打包成一个新包，否则会因为找不到调用模块而报错。
而我们看到的这一个程序，明显是-F指令生成的集成程序。至于为什么使用pyinstxtractor解包后看到的调用包是一堆encrypted的包，是因为pyinstaller还可以使用特定的key参数对代码进行AES加密，比方说：
pyinstaller --key 123 demo.py
但实际上，这个加密有个致命的弱点，那就是存放key的pyimod00_crypto_key，以及入口函数main.py并没有加密。这样，我们的目标库和加密key简直就是开盖即食。于是先用pycdc反编译一下key，然后用代码解pyc加密的同时加上一下文件头，最后用pycdc处理一手：
import tinyaes
import zlib
CRYPT_BLOCK_SIZE = 16
# 从pyimod00_crypto_key里把key拽出来
key = bytes('HelloHiHowAreYou', 'utf-8')
inf = open('./PYZ-00.pyz_extracted/sign.pyc.encrypted', 'rb') # encrypted file input
outf = open('sign.pyc', 'wb') # output file
# 代码块就这么长，能AES的不多，先初始化一手
iv = inf.read(CRYPT_BLOCK_SIZE)
cipher = tinyaes.AES(key, iv)
# 解码并解压
plaintext = zlib.decompress(cipher.CTR_xcrypt_buffer(inf.read()))
# 写入pyc文件头
outf.write(b'\x6f\x0d\x0d\x0a\0\0\0\0\0\0\0\0\0\0\0\0')
# 写入解码过的pyc
outf.write(plaintext)
inf.close()
outf.close()
最后爆出来这一坨：
import hashlib as 沈阳
import base64 as 杭州
import ctypes as 蚌埠
def main():
蚌埠.windll.kernel32.VirtualAlloc.restype = 蚌埠.c_void_p
福建 = input('您的输入：')
天津 = '9K98jTmDKCXlg9E2kepX4nAi8H0DB57IU57ybV37xjrw2zutw+KnxkoYur3IZzi2ep5tDC6jimCJ7fDpgQ5F3fJu4wHA0LVq9FALbjXN6nMy57KrU8DEloh+Cji3ED3eEl5YWAyb8ktBoyoOkL1c9ASWUPBniHmD7RSqWcNkykt/USjhft9+aV930Jl5VjD6qcXyZTfjnY5MH3u22O9NBEXLj3Y9N5VjEgF2cFJ+Tq7jj92iIlEkNvx8Jl+eH5/hipsonKLTnoLGXs4a0tTQX/uXQOTMBbtd70x04w1Pa0fp+vA9tCw+DXvXj0xmX8c5HMybhpPrwQYDonx7xtS+vRIj/OmU7GxkHOOqYdsGmGdTjTAUEBvZtinOxuR7mZ0r9k+c9da0W93TWm5+2LKNR6OJjmILaJn0lq4foYcfD5+JITDsOD6Vg01yLRG1B4A6OxJ7Rr/DBUabSu2fYf1c4sTFvWgfMV8il6QfJiNMGkVLey1cBPSobenMo+TQC1Ql0//9M4P01sOiwuuVKLvTyDEv6dKO//muVL9S2gq/aZUBWkjj/I5rUJ6Mlt4+jsngmuke9plAjw22fUgz+8uSzn40dhKXfBX/BOCnlwWsMGAefAfoz/XAsoVSG2ioLFmlcYe/WBgaUJEoRUSyv73yiEOTVwIK6EPnDlwRgZZHx2toLu8udpEZ0aKGkex5sn7P8Jf9AbD4/EiQU+FdoJSxGorPSZGvrc4='
北京 = 沈阳.md5('云南'.encode('utf-8')).hexdigest()
重庆 = 杭州.b64decode(天津)
河南 = b''
北京_len = len(北京)
广州 = list(range(256))
j = 0
for i in range(256):
j = (j + 广州[i] + ord(北京[i % 北京_len])) % 256
广州[i] = 广州[j]
广州[j] = 广州[i]
山东 = 陕西 = 0
for 河北 in 重庆:
山东 = (山东 + 1) % 256
陕西 = (陕西 + 广州[山东]) % 256
广州[山东] = 广州[陕西]
广州[陕西] = 广州[山东]
河南 += bytes([
河北 ^ 广州[(广州[山东] + 广州[陕西]) % 256]])
四川 = 蚌埠.create_string_buffer(福建.encode())
黑龙江 = 蚌埠.windll.kernel32.VirtualAlloc(蚌埠.c_int(0), 蚌埠.c_int(len(河南)), 蚌埠.c_int(12288), 蚌埠.c_int(64))
蚌埠.windll.kernel32.RtlMoveMemory(蚌埠.c_void_p(黑龙江), (蚌埠.c_ubyte * len(河南)).from_buffer(bytearray(河南)), 蚌埠.c_size_t(len(河南)))
辽宁 = 蚌埠.windll.kernel32.CreateThread(蚌埠.c_int(0), 蚌埠.c_int(0), 蚌埠.c_void_p(黑龙江), 蚌埠.byref(四川), 蚌埠.c_int(0), 蚌埠.pointer(蚌埠.c_int(0)))
蚌埠.windll.kernel32.WaitForSingleObject(蚌埠.c_int(辽宁), 蚌埠.c_int(-1))
if 四川.raw == b'\xdb\x1b\x00Dy\\C\xcc\x90_\xca.\xb0\xb7m\xab\x11\x9b^h\x90\x1bl\x19\x01\x0c\xeduP6\x0c0\x7f\xc5E-L\xb0\xfb\xba\xf6\x9f\x00':
print('是的！你得到了！')
return None
None('不，再尝试更多。 （笑脸符号）')
if __name__ == '__main__':
main()
return None
虽然加了一堆的中文混淆，但是，基本逻辑还是比较清晰的。不过有个坏消息，这又是一道密码题，它先以“云南”为key生成S盒，然后直接跑一个浅显的RC4（详情请见0verWatch 的博客），把一份shellcode解密完再开一个子进程运行。虽然初见看的我两眼一黑，但我有wp（
我们先直接进行一个RC4的解：
from Crypto.Cipher import ARC4
import hashlib
import base64
天津 = b'9K98jTmDKC...
北京 = hashlib.md5('云南'.encode('utf-8')).hexdigest()
北京 = bytes(北京.encode('utf-8'))
重庆 = base64.b64decode(天津)
天津 = ARC4.new(北京)
output = 天津.decrypt(bytes(重庆))
print(list(output))
然后得到的东西像原代码一样，我们之前也见过类似的东西，也就是数据层藏代码然后放到子进程运行，只不过这里是在python上调用的C库。但是接下来的事情直接用C就成，开个虚拟栈帧+子进程把shellcode弄出来（参考SU战队的题解）：
#include <stdio.h>
#include <Windows.h>
unsigned char shellcode[] = {
81, 232, 0, 0, 0, 0...
};
int main() {
PVOID p = VirtualAlloc(NULL, sizeof(shellcode), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(p, shellcode, sizeof(shellcode));
((void(__stdcall*)())(p))();
return 0;
}
然后我们从ida里可以看到它本来的样子……的一部分。虽然你第一遍可能看不明白它为什么会高位截瘫，你甚至找不到一个return，还得自己补一个。
但我们至少得让这里面的东西解出来再说。我们通过刚才强行凑函数的结果可以看到，这玩意其实在对后面那段shellcode进行解密，尤其是在动调一遍后，这一段尤其明显：
等下，这不是解密完了吗？我们直接create function然后f5进去看一眼：
_WORD *sub_1D0162()
{
_WORD *result; // rax
unsigned int v1; // [rsp-1Ch] [rbp-1Ch]
unsigned int v2; // [rsp-14h] [rbp-14h]
unsigned int v3; // [rsp-10h] [rbp-10h]
int i; // [rsp-Ch] [rbp-Ch]
__int64 v5; // [rsp-8h] [rbp-8h]
for ( i = 0; i <= 20; ++i )
{
v2 = 2029;
v3 = *(unsigned __int16 *)(2i64 * i + v5) % 0xD1EFu;
v1 = 1;
while ( v2 )
{
if ( (v2 & 1) != 0 )
v1 = v3 * v1 % 0xD1EF;
v3 = v3 * v3 % 0xD1EF;
v2 >>= 1;
}
result = (_WORD *)(2i64 * i + v5);
*result = v1;
}
return result;
}
好家伙，算法直接看完了。就是把数据两个两个提出来（因为是int16且i*2的提法）于是我们直接数据提出来，写脚本开爆：
·python part
---------------
output = []
str1 = '\xdb\x1b\x00D...
for i in str1:
output.append(ord(i))
print(output)
·C++ part
---------------
#include <iostream>
#define modnum 0xD1EFu
using namespace std;
unsigned char cipher[] = {219, 27, 0, 68...
int main()
{
for(unsigned int i=0;i<=20;++i){
int laztag = 0; // 爆出即停用标记
unsigned int cip = (cipher[i*2] + (cipher[i*2+1]<<8)) % modnum;
for(unsigned int j=0;j<127;j++){
for(unsigned int k=0;k<127;k++){ // 暴力枚举每一个可能字符
unsigned int key = 2029;
unsigned int guess = (j + (k<<8)) % modnum;
unsigned int v1 = 1;
while(key){ // 还原算法
if(key & 1 != 0)
v1 = guess * v1 % modnum;
guess = guess * guess % modnum;
key >>= 1;
}
if(v1 == cip){ // 猜对了
printf("%c%c",j,k);
laztag = 1;
break;
}
}
if(laztag == 1)break; // 爆出即停，节约算力
}
}
}
做个总结：
终于，到了大三
估计不久之后也要开始崩溃的考研时光了（悲
那么接下来，开始我的炸弹秀——
啊对对对，是咋俩的炸弹秀。
哦，对了，上一回刚刚讲到子进程和fork，其中提到了一些：
我们之前提到的SIGSTOP / SIGSTEP / SIGTTIN / SIGTTOU信号，其实只是信号的一部分。信号的定义，实际上就是内核向进程系统发送的消息，提示系统进程发生了，或者计划发生某些事件。比方说一个进程可以通过内核发送向另一个进程的SIGKILL信号，来终止目标进程；再比如内核发出SIGXCPU信号的时候，是一个进程TLE（Time Limit Exceed，运行超时，准确来讲是在CPU中执行指令的时候并没有抛出异常却卡住了）了。
至于这些信号的确切作用，你可以在《深入理解》的原书中找到，本文不再赘述。
既然提到信号，那么就不得不提信号的收发。概念很简单，发送信号就是内核将信号发送到进程，接收信号就是进程对内核发出的信号做出反应（并且因为内核的层级高于进程，实际上在通常情况下，这个接受过程是受迫的）。
是否发送取决于内核是否对检测到的系统事件进行反应，或者说系统有没有收到来自进程的kill请求。最直观的就是当你的程序卡住不动，尝试操作又导致超时的时候，windows任务管理器会发来一个提示，让你决定是否中断程序，当你选择中断，那么内核才会对这个异常信号反应，或者接受kill的调用请求，选择继续等待时则会绕过这一次的决策。
同样的，有无法发送的情况，就有无法接收的情况。有被动的情况，一个发出但没有被接收的信号叫待处理信号，一旦一个进程有一条对应的待处理信号，那么与这条信号同类的所有信号都会在传入的时候被拦截，而这也就意味着，待处理信号有对于当前进程的唯一性，即一个进程的同一类待处理信号只能有一个。
也有主动的情况，就是一个进程可以选择阻塞某类信号，这些被阻塞的信号会处于一种“如收”的状态，即收了但没执行，直到进程取消阻塞行为。实际上，对于待处理信号的处理过程就是一种隐式的阻塞，相对而言，使用**sigporcmask函数之类的手段进行调用的阻塞则是显式**阻塞，具体而言可以翻阅《深入理解》原书522到533页，本文不再赘述。
内核在每个进程中维护两个分别叫”pending“和”blocked“的位向量，一个维护当前进程的待处理信号，一个维护被阻塞的信号类别.当内核发送一个信号给进程时，它将会修改进程的pending位向量，譬如说，当内核发送一个SIGINT信号给进程，那么它会将进程的pending[SIGINT]的值设置成1。同样地，当进程屏蔽掉一个信号时，那么它会修改blocked位向量。实际上，比起将其当作向量理解，学OI学多的人更可能会将其当作bool数组来理解，不过这都是后话了。
虽然我很想先把发信方式讲了，但是，我突然意识到，我在介绍进程的时候漏了个概念：
众所周知，每个进程有唯一对应的编号，但是，打过OI或者学过数据结构的人应该明白，对于大批量且具有明确上下级关系的结构，用并查集维护（简单来讲就是对于在同一个连通块的数据，全部归为一组进行管理，方便对组数据的批处理操作）往往比直接用数组更为高效。
行行行，考虑到大家都是学CTF的，不谈OI了，谈数据结构吧。
就单纯为了方便管理，在进程之上，还有进程组的概念，即父进程以及所有与之直接或间接关联的子进程。众所周知，是个并查集都需要一个单射序列，来确定所有的集合。同样地，进程组也需要一个唯一对应的标识，也就是**进程组ID(PGID)**。当一个新的进程组产生，其进程组ID往往是其根进程，也就是第一个加入该进程组的进程的PID。
一个进程对自身所在的进程组，可以用**getpgrp进行查询，也可以用set-pgid**函数来更改自身或其它进程的进程组，set-pgid若设定pgid为0，则以目标进程为根进程，新创建一个进程组。
发信的方式有很多，**/bin/kill** 程序或者编程语言中系统库的kill函数，可以向任意进程发送SIGKILL，也就是所谓“杀程序”的信号；系统快捷键也可以向正在运行中的进程发送信号，比方说在运行时 Ctrl+C 就是发送强制终止的信号；进程也可以通过调用alarm函数给自己发送SIGALRM信号，etc。
信号的收发，论其根源实际上都是内核到进程的单线控制。当内核完成上下文切换或者从系统调用中返回进程时，控制权由内核移交给进程，此时，若我们之前提到的，内核维护的待处理信号集合/序列为非空状态，内核会根据序列中信号在系统中编号的大小，从小到大发送信号。进程在接收信号，完成行为之后就继续执行下一条指令——如果它没有被信号影响而产生一些无法逆转的后果的话。
进程在接收信号的时候可以通过 signal 函数来改变某类信号相关联的行为。简单来讲，如之前所说，每一个信号种类其实对应着序列上的一个元素，而这个元素又与一条编码序列，也就是 信号编码 形成单射，signal就是将编码对应的信号调用转移到其它函数，或者将它已经变更过的调用转移到原信号上。
举个并不很实际，但却很直观的例子，假设今天小娜想特别给自己插张全新N卡，她的SIGUSR1(允许用户自定义的信号)被设定为自己的导航程序的启动函数：
signal(10, *loc_tar_start);
这时候，她的思考进程捕获到了SIGUSR1信号，启动了导航程序，让她能够一路畅通无阻的杀向电子城。但是，她盘算了自己的钱包，显然连这个月给自己充电用的电费都快付不起了。她只好想着法子克制自己的欲望，于是她灵机一动，把代码改成了这个样子：
sighandler_t signal(10, SIG_IGN);
当第二个参数为SIG_IGN时，SIGUSR1会被忽略，这样她就找不到地，也就用一个非常简单的方式保住了自己的钱包。
好吧，下回给你多发点……
不过，如果想要达到忽略信号的效果，阻塞其实也不失为一种办法，这就要利用 sigporcmask 函数了。
当然，并不是只有内核才能处理异常，异常也不是只提供给内核的操作手段。非本地跳转通过**setjump和longjump**函数，提供了令用户层不需要通过内核，便能在进程间转移的手段。
setjump通过在栈上的env缓冲区保存当前调用环境，也就是在栈上某个可用区域存储你目前用到的运行环境相关的变量，包括程序的计数器、栈指针和通用目的寄存器。而longjump负责从env缓冲区中恢复这些状态。具体实例还是得翻阅原书，毕竟这里只是个笔记，抛砖引玉用的。
综上所述，我们终于大概弄明白了整一个进程操作和控制流传递的过程，也大致明白了你的计算机究竟是怎样在多个问题中思考，寻求解决方案的。不出意外，下一期，我们就要去干内存了。所以……
–ARE YOU READY???–
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true