BUUCTF 上那道叫「不一样的flag」的逆向题名字起得挺欠揍——它确实和别的 flag 题不太一样。我第一次打开它的时候脑子里默认这是一道算密钥、解校验的常规逆向结果 F5 出来的伪代码里一个加密函数都没有只有一串很眼熟的字符常量和一个循环读输入的骨架。折腾了二十来分钟才反应过来这题的本质是让你在一个 5×5 的网格里走迷宫走通了才拿得到 flag。它考的不是密码学、也不是算法功底而是你能不能在反编译结果里一眼认出「这是一张地图」。这篇就把我完整的分析链路摊开讲包括怎么从 25 个字符判断出网格尺寸、1/2/3/4 四个方向码分别对应什么、为什么最短路径是 12 步、以及我在输入和展平顺序上踩过的几个坑。如果你刚接触 BUUCTF 的 reverse 或者 misc 分区这类「伪输入、实迷宫」的题会反复出现套路摸清之后基本是白送分。1. 拿到题目先别急着按 F5三十秒定型比什么都重要1.1 用 file 和 strings 先把题的「性格」摸清很多人拿到二进制第一反应就是拖进 IDA 等自动分析其实更划算的做法是先花半分钟做三件事把题目分类。第一件是file看架构和链接方式第二件是strings看有没有明显的提示语、格式串和可疑长字符串第三件是有没有加壳upx -d试一下或者看节区名正不正常。这三步做完题目属于哪一类基本就有数了。这道题我这边file出来的结果是 32 位的 ELF 可执行文件没有加壳也不用脱壳。strings就比较有意思了能直接翻到几句很像人话的提示通常是一句让你「选择前进方向」之类的引导语还有那个长度 25、由*、1、0、#四种符号拼成的字符串常量。这四种符号的存在本身就是巨大的信息量——真实的加密程序里不会出现这么干净的字符集。顺序求解成本太高了先把这些线索记下来再去反编译你至少知道自己在找什么。我见过不少人字符串扫一眼就跳过然后在 IDA 里对着几千行伪代码瞎翻最后卡在同一个地方。1.2 为什么这类题静态分析比动态调试更划算逆向题有两套常用打法静态看伪代码动态挂调试器。这道题两者都能做但我更推荐先静态。原因是它的逻辑结构非常浅——读一个字符、改一次坐标、判一次边界没有任何间接跳转、没有反调试、也没有花指令。这种「一层套一层但很薄」的逻辑用 F5 出来的伪代码读一遍比在 gdb 里单步十来分钟要快得多。但静态分析有个前提你得相信编译器把结构保留了。这道题恰好保留了。伪代码里能清楚看到数组、循环、switch 或者连续的 if-else 分支。要是遇到被高度优化、结构被打散的样本那还是得动态配合在关键地址下断点看寄存器和内存。判断依据很简单伪代码里如果还认得出「数组」「循环」「比较」就先静态如果全是位运算和跳转表再考虑上调试器。还有一个实际的好处静态看完之后你已经在脑子里建好了模型再去动态验证的时候是带着明确问题去的——比如「我要看它读第 12 个字符时坐标是多少」。带着问题调试和没头没脑单步效率差着好几倍。2. 反编译结果里最值得盯的三处25 个字符、两组边界、四个方向2.1 那个 25 字节的字符串常量是怎么暴露成迷宫的反编译出来以后我最先盯住的就是那个字符串常量*11110100001010000101111#这串东西有 25 个字符字符集只有四种*、1、0、#。判断它是迷宫的推理链其实很短就三步。第一步25 是个特殊的数25 5×5而且它刚好是完全平方数很多二维网格的展平长度都会落在平方数上第二步字符集这么小说明每个符号只承担一种「地形」含义真实数据不会这么规整第三步后面的代码会对下标做边界检查而不是对自由增长的指针做检查说明长度是写死的。把这三条串起来「这是一个 5×5 的二维网格用一维数组按行优先展平存放」这个结论就站得住脚了。我建议你以后遇到类似的结构都先做一次这样的推理而不是直接猜。猜对了是运气推出来才是能力而后者可以复现。2.2 两组边界检查把网格尺寸钉死了真正让我百分百确认尺寸的是后面那几行越界判断。伪代码里会看到类似这样的比较某个变量小于 0 或者大于 4 就判定失败、直接返回。这个0和4就是关键证据——合法下标区间是 0 到 4一共五个值对应五行或五列。如果网格是 5×5那么行下标有五个合法值、列下标也有五个合法值越界检查自然就是0..4。如果换成 10×10这里出现的就会是9。所以边界常量是网格尺寸的直接指纹看到4就该想到 5看到9就该想到 10。顺带一提展平成一维之后的下标范围是 0 到 24但代码里通常不会直接写24因为它把「行」和「列」当成两个独立变量在维护最后才换算成一维下标去取值。这也是为什么认清这时候的变量语义这么重要如果不搞清楚哪两个变量是坐标、哪个是下标后面读逻辑会一直别扭。2.3 1/2/3/4 四个分支背后的坐标偏移接下来是输入处理部分这也是整道题的题眼。还原出来的核心逻辑大致是这样char maze[] *11110100001010000101111#; int row 0, col 0; char c; for (int i 0; i 11; i) { scanf(%c, c); if (c 1) row - 1; // 上 else if (c 2) row 1; // 下 else if (c 3) col - 1; // 左 else if (c 4) col 1; // 右 if (row 0 || row 4 || col 0 || col 4) return 0; // 出界 if (maze[row * 5 col] 1) return 0; // 撞墙 } if (maze[row * 5 col] #) { /* 到达终点 */ }这里是按我当时的分析整理出来的骨架具体变量名和写法各家版本会有差异但结构就是这样。四个分支做的事情非常清晰两个改行号、两个改列号加减各一。这种「上下左右各一个分支」的形态是方向控制题的典型特征。判断哪个数字对应哪个方向不能靠翻译习惯得看偏移的符号。行号减一意味着往上走行号从 0 开始越小越靠上行号加一往下走列号减一往左列号加一往右。这个对应关系一旦搞反后面算出来的路径就完全对不上。3. 把字符串还原成一张能看懂的网格3.1 行优先展平与坐标换算要把那 25 个字符还原成 5×5 的图先得确定展平顺序。绝大多数 C 语言里手写的二维数组都是行优先的也就是先把第一行存完再存第二行。对应关系是一维下标 行号 * 5 列号 行号 一维下标 / 5 列号 一维下标 % 5按这个规则把字符串切开5 个一组就得到下面这张图行\列012340*111110100020101030001041111#画出来之后整道题瞬间就变得直观了。*在左上角是起点#在右下角是终点0是能走的通道1是墙。你甚至不需要写代码拿眼睛看就能发现通路从左上角往下走到底再往右拐往上穿出去再往右走到最右列最后一路往下撞到#。3.2 四个符号的含义约定符号含义最好列成表固定下来避免后面来回摇摆符号含义遇到时的后果*起点初始位置坐标 (0, 0)#终点走到这里即通关0可通行正常移动什么都不发生1墙判定失败程序直接退出这里有个特别容易翻车的点1是墙0是路而不是反过来。直觉上很多人会觉得「1 代表有、代表通」但在这道题里恰好相反。判断依据不在符号本身而在代码伪代码里判断失败的条件是「当前位置的值等于1」说明踩到1就是撞墙。这个条件也顺带把0的含义定死了。3.3 手工推演一遍和写脚本跑一遍结果必须一致我的习惯是两边都做。先手工从 (0, 0) 开始走一遍把每一步的坐标和方向记下来再写个脚本搜一遍看最短路径是不是同一串。这道题手工走的结论是从 (0,0) 往下到 (1,0)再往下到 (2,0)再往下到 (3,0)右移到 (3,1)、再右移到 (3,2)往上到 (2,2)、再往上到 (1,2)右移到 (1,3)、再右移到 (1,4)往下到 (2,4)、(3,4)、(4,4)撞上#一共 12 步。你会发现这张图里其实没有岔路每个可通行的格子在排除回头路之后只剩一个前进方向相当于一条「独木桥」。这也是为什么手工推和脚本跑必然一致——不存在多条等长路径的情况。4. 用 BFS 把 12 步最短路径算出来4.1 为什么这题值得专门写一段搜索脚本有人会说独木桥迷宫手推就行了写脚本是脱裤子放屁。这话在本题成立但放在这个题型上不成立。原因有两点一是变体题目里网格会变复杂出现真正的岔路靠眼睛找路径会开始出错二是手工推的时候你很容易忽略「哪些格子是真通、哪些只是看着通」而脚本会严格执行规则不会自我说服。更实际的原因是脚本一旦写好它就是模板。以后遇到 10×10、15×15 的同类题你只需要改两个常量字符串和边长。这种能复用的工具写一次赚很多次。我自己的习惯是把这类网格题的解法和还原逻辑写在同一个脚本文件里随手就能改。4.2 可直接抄的 Python 求解脚本下面这段是我后来整理出来的通用版本改动点只有最上面三行from collections import deque maze *11110100001010000101111# # 从二进制里抄出来的字符串 N 5 # 网格边长 WALL, START, GOAL 1, *, # # 方向顺序必须和程序里的 1/2/3/4 严格对齐 # 上(-1,0) 下(1,0) 左(0,-1) 右(0,1) DIRS [(-1, 0), (1, 0), (0, -1), (0, 1)] CODE [1, 2, 3, 4] sr, sc divmod(maze.index(START), N) q deque([(sr, sc, )]) seen {(sr, sc)} while q: r, c, path q.popleft() if maze[r * N c] GOAL: print(path , path, | steps , len(path)) break for k, (dr, dc) in enumerate(DIRS): nr, nc r dr, c dc if not (0 nr N and 0 nc N): # 出界 continue if maze[nr * N nc] WALL: # 撞墙 continue if (nr, nc) in seen: # 走过就不回头 continue seen.add((nr, nc)) q.append((nr, nc, path CODE[k]))跑出来是path 222441144222步数 12和手工推的完全吻合。这段代码里有三个细节值得单独说divmod用来把一维起点下标拆成行列坐标DIRS的顺序必须和题里的方向码一一对应seen集合用来避免走回头路否则在通道里会来回横跳队列永远不会空。4.3 把搜索出来的路径翻译成提交用的 flag脚本输出的222441144222就是方向序列三个下、两个右、两个上、两个右、三个下。这串数字本身就是答案的内容按平台的格式包一层提交的就是flag{222441144222}这里我要强调一句这道题的 flag 内容就是路径序列不是程序运行时打印出来的什么字符串。程序只是校验你走没走到终点它并不会把答案告诉你。所以「跑一遍程序看输出」这种做法在这题上是死路必须自己把路径解出来。验证的方式很简单把222441144222一行敲进去程序不再报错退出说明路径正确。如果中途撞墙或者出界它会在对应的判断处直接返回什么都看不到——这也是为什么很多人第一次跑的时候以为程序「没反应」其实是自己第一步就走错了。5. 我在输入、符号和展平顺序上踩过的三个坑5.1 把 0 和 1 的角色搞反直接走进死胡同这是我最开始犯的错。凭直觉把1当成通路、0当成墙画出来的图看着也挺像回事但一搜就发现起点被1包住根本出不去。当时的反应是「这题是不是有别的机关」又回去翻了一遍伪代码才醒悟。教训很直白符号的含义永远由代码判断决定不由符号长什么样决定。程序判失败的那一侧就是障碍剩下那侧才是通路。以后遇到任何带符号网格的题先去代码里找「什么情况算失败」这一句话就把所有符号的语义定死了。5.2 scanf 读字符时把换行也吃进去第二个坑跟输入方式有关。这类题的读入通常是scanf(%c, c)一次读一个字符。问题在于终端输入是带缓冲的你敲的换行符也是字符也会被读走。如果反编译出来是固定次数的循环比如明确读 12 次那么你每敲一个数字就按一次回车换行符就会占掉一次读取机会实际有效方向变少坐标自然对不上最后停在半路上。处理办法有两种。第一种最省事把 12 个字符在一行里连续敲完最后再回车这样缓冲区里前 12 个字符全是有效方向。第二种是通过管道喂进去比如把路径写进文件再重定向给程序完全绕开交互输入。我一般用第二种因为可重复、不出错也方便写进笔记里。另外提醒一句如果反编译显示的是while无限循环加别的退出条件那换行符只是被忽略掉不会造成错位这种情况就不用管。判断依据还是看循环结构别一概而论。5.3 行列展平顺序搞错路径完全对不上第三个坑是展平顺序。我一开始按「列优先」切字符串画出来的图和程序里的完全不是一回事位置全乱。之所以能发现是因为画完之后起点*跑到了左下角而程序里初始化坐标是(0, 0)两者矛盾。所以有个很实用的自检手法画完图之后先检查起点和终点的位置是否和初始化坐标一致。程序从(0, 0)开始那*就必须在左上角如果画出来*在别处说明展平顺序或者边长猜错了。这一个检查能拦掉绝大多数低级错误比反复读伪代码快得多。6. 这类「伪输入、实迷宫」题目的通用识别与迁移6.1 从几个特征快速判断是不是迷宫题做多了之后识别迷宫题基本靠几个特征组合几乎不会看错。首先是字符集小网格题的地形符号通常只有三到四种而且反复出现其次是长度是完全平方数25、100、225 这类再次是出现成对的坐标边界检查0..N-1的区间判断往往成对出现最后是输入处理里有一组「各改一个坐标」的分支。只要看到其中三条基本可以往迷宫方向想。这时候正确的动作不是继续往下读代码而是先把字符串还原成图因为图一旦画出来剩下的逻辑就变得一目了然。很多时候你会发现连代码都不用全看懂光看图就知道该怎么走。6.2 脚本模板的通用化和变体应对我后来把求解脚本抽象成了一个通用版本核心就三个参数网格字符串、边长、方向码到偏移量的映射。方向码映射是最容易随题目变化的部分有的题用w/a/s/d有的用8/2/4/6有的干脆用数字 1 到 4 但方向顺序不一样。所以每拿到一道新题第一件事是去伪代码里确认方向码表而不是凭经验套。还有一个变体是多层或者非线性网格那就要把状态从(r, c)扩展到(layer, r, c)搜索框架不变只是状态多一维。真正需要换思路的是「带权重」或「需要按特定顺序踩点」的类型那已经超出普通迷宫的范畴得按具体规则改搜索策略。但只要底层是「网格 移动 合法判定」这三件套前面那套分析方法就一直有效。最后再分享一个小习惯做完这类题之后我会把原始伪代码里的关键片段和求解脚本贴在同一个笔记文件里标清楚方向码表。下次遇到长得像的题先翻笔记对一下方向码能省掉好几次白推。这个习惯看起来不起眼但在我做过的十几道同类题目里至少帮我少走了三四次回头路。