1. 逆向工程学习笔记的定位与整体思路拆解1.1 这道题为什么值得单独写一篇笔记做逆向题做到一定数量之后你会发现一个规律真正卡住你的往往不是汇编读不懂而是对程序整体结构的判断失误。拿到一个二进制文件如果一上来就扎进某个函数逐行硬啃很容易在几百行指令里迷路最后时间花了不少关键逻辑却没抓住。这道来自某CTF赛事的逆向题标题里带了一个很有意思的词——identity。身份。这个词其实已经暗示了题目的核心程序在判断你是谁或者说在验证你输入的东西是否符合某个特定的身份特征。这类题在逆向入门到进阶的过渡阶段非常典型它不像纯算法题那样把逻辑摊开给你看也不像加壳题那样把重点放在脱壳上而是把判断逻辑藏在若干个函数调用和字符串处理之间需要你有清晰的调试思路才能快速定位。我把它整理成笔记主要是因为它集中体现了三个能力点第一静态分析时如何快速识别关键函数第二动态调试时如何高效下断点第三如何把分散的校验逻辑拼成完整的判断链。这三点是逆向工程里最通用的基本功无论你后面做Windows平台还是Linux平台、做用户态还是内核态思路都是相通的。适合读这篇笔记的人已经会用IDA或者Ghidra看反汇编能看懂基本的x86/x64指令但对怎么从一堆函数里找到真正干活的那个还不太有把握的朋友。如果你连栈帧、寄存器传参都还没搞明白建议先把基础补一补再来看不然容易变成照着抄一遍但不知道为什么要这么做。1.2 整体分析策略先摸骨架再抠细节我处理这类题的习惯流程是固定的基本分四步走文件识别先搞清楚这是什么平台、什么架构、有没有符号、有没有加壳。这一步用file命令和查壳工具几秒钟就能完成但信息量极大。静态概览用反汇编工具打开先看函数列表和字符串窗口不急着看具体指令。字符串往往是最快的突破口尤其是那些提示性的、报错性的文本。定位关键逻辑根据字符串交叉引用找到引用这些字符串的函数判断哪个是主校验逻辑。动态验证在关键判断处下断点单步跟踪观察寄存器和内存的变化把静态分析里猜的部分用动态执行坐实。这个流程的核心思想是从粗到细、从外到内。就像拆一台不熟悉的机器你不会先拧最小的那颗螺丝而是先打开外壳看看整体布局找到核心部件在哪再决定从哪下手。很多新手的问题就是跳过了摸骨架这一步直接钻进细节结果方向错了越钻越偏。提示静态分析和动态调试不是二选一的关系而是互相印证。静态看结构动态看数据。静态里看不懂的分支动态跑一遍往往就清楚了动态里观察到的现象回到静态里找对应的指令才能理解为什么。1.3 工具选型与理由这道题我主要用了两个工具反汇编器和调试器。反汇编器负责静态分析调试器负责动态验证。反汇编器方面我习惯用IDA原因是它的反编译功能F5在判断逻辑结构时非常省事能把汇编还原成接近C的伪代码大大降低阅读负担。当然Ghidra也完全可以而且免费功能上对这类题绰绰有余。选哪个看你自己的习惯关键是不要依赖反编译结果直接下结论伪代码有时候会误导你尤其是涉及指针运算和类型转换的地方最终还是要回到汇编去确认。调试器方面Linux平台下我一般用gdb配合pwndbg或者gef插件Windows平台下用x64dbg。这道题是Linux下的ELF文件所以用gdb。pwndbg的好处是它把寄存器、栈、反汇编都显示在一个界面里单步的时候不用来回敲命令效率高很多。工具只是手段真正决定效率的是你知不知道该在哪里停下来看。下断点这件事新手容易犯两个极端要么一个断点都不下全靠静态硬看要么到处下断点程序跑两步就停反而干扰思路。我的经验是断点要下在决策点上——也就是那些会改变程序走向的条件跳转之前以及关键函数调用的入口处。2. 核心细节解析与实操要点2.1 文件识别阶段的关键信息提取拿到文件的第一步我一般会跑这么几条命令file ./challenge checksec --file./challenge strings ./challenge | head -50file命令告诉你这是ELF 64位还是32位、是动态链接还是静态链接、有没有被strip。checksec看保护机制比如有没有栈保护、有没有PIE、NX开没开。strings快速扫一遍可打印字符串找找有没有明显的提示信息。这一步看起来简单但信息量真的很大。比如如果发现是静态链接那函数会非常多反汇编工具加载后函数列表可能上千个这时候就不能靠浏览函数列表来找关键逻辑了必须靠字符串或者系统调用作为锚点。如果是动态链接函数数量少很多而且能看到调用了哪些库函数比如strcmp、strlen这些直接就能推断出程序在做什么。这道题我印象里是动态链接的64位ELF没有加壳保护机制开了NX和Canary没有PIE。没有PIE意味着代码段的加载地址是固定的这对调试很友好下断点的时候可以直接用绝对地址不用先算基址。注意strings输出很长的时候不要一行行看用grep过滤关键词。比如你想找和输入相关的提示可以strings ./challenge | grep -i -E flag|input|wrong|correct|key。这一步能帮你省大量时间。2.2 字符串窗口的妙用与交叉引用追踪字符串是逆向工程里最容易被低估的突破口。程序无论多复杂只要它要和用户交互就一定有字符串。而这些字符串所在的位置往往就紧挨着核心逻辑。在IDA里按ShiftF12打开字符串窗口你会看到所有被引用的字符串及其地址。找到那些看起来像判断结果的字符串比如correct、wrong、success、failed之类的双击进去然后按X查看交叉引用cross reference就能跳到引用这个字符串的代码位置。这一步的意图很明确程序在什么地方输出正确或错误那个地方附近一定有条件判断而条件判断的条件就是我们要找的校验逻辑。我在这道题里就是这么做的。字符串窗口里有一个很显眼的提示性字符串交叉引用过去之后发现它在一个函数的末尾前面紧跟着一个条件跳转。顺着这个跳转往上看就能看到它依赖的某个返回值或者某个比较结果。再往上追就追到了真正的校验函数。这里有个经验交叉引用不一定只有一处。有时候一个字符串被多个地方引用你要判断哪个才是主逻辑。判断方法很简单看哪个引用点的上下文最完整——有输入、有处理、有判断、有输出那基本就是主流程。2.3 关键函数的识别什么样的函数值得细看从字符串追到引用点之后接下来要判断这个引用点所在的函数是不是核心校验函数还是只是个外围的包装我的判断标准有这么几条函数体大小太小的函数比如只有几行通常是工具函数或者包装真正干活的函数一般有一定体量。调用的子函数如果这个函数调用了strcmp、memcmp、strlen这类字符串处理函数说明它在做数据比较很可能就是校验逻辑。参数和返回值如果函数接收用户输入作为参数返回一个布尔值或者整数结果那基本可以确定它是校验函数。循环结构如果函数里有循环而且循环里对输入数据做了逐字节或者逐字符的处理那这就是在加工输入核心算法往往就在这里。这道题的核心校验函数我印象里是接收输入字符串然后对它做了一系列变换最后和一个内置的常量做比较。这种变换后比较的模式在CTF逆向里非常常见因为直接比较明文太容易被strings看到了加一层变换能增加一点难度。2.4 静态分析时的常见陷阱静态分析有几个坑我踩过不止一次这里列出来给大家提个醒第一个坑反编译伪代码的类型推断错误。IDA的F5功能虽然强大但它对变量类型的推断是基于启发式的有时候会把一个指针当成整数或者把一个数组当成单个变量。如果你完全信任伪代码可能会得出错误的结论。我的习惯是伪代码只看逻辑结构具体的数据操作一定回到汇编确认。第二个坑忽略了编译器优化。编译器在优化级别较高的时候会做很多反直觉的变换比如把简单的乘法变成移位和加法组合把循环展开把函数内联。这些优化会让汇编看起来和源码差别很大。遇到看不懂的指令序列先想想如果我是编译器我会怎么优化这段代码往往就能豁然开朗。第三个坑把库函数当成用户函数。动态链接的程序里很多函数是库函数比如printf、scanf、strlen。如果你不认识这些函数的特征可能会花时间去分析它们纯属浪费时间。识别方法看函数地址如果它在.plt或者.plt.sec段那基本就是外部库函数的跳转桩。提示IDA加载完程序后先按ShiftF12看字符串再按CtrlL看函数列表心里有个大概的数。不要一上来就F5先建立整体印象。3. 实操过程与核心环节实现3.1 从字符串到校验函数的完整追踪路径我把这道题的追踪过程完整走一遍你可以跟着这个思路复现。第一步strings扫一遍发现几个可疑字符串其中有一个明显是判断结果类的提示。记下它的内容。第二步IDA打开ShiftF12找到这个字符串双击定位到.rodata段。然后按X看交叉引用发现它被一个函数引用。双击跳过去。第三步跳到引用点后发现这是一个函数的尾部前面有一个条件跳转决定走哪个分支输出。往上翻找到这个条件跳转依赖的比较指令。比较的两个操作数一个是某个局部变量另一个是某个内存地址的值或者立即数。第四步继续往上追这个局部变量的来源。发现它是某个函数调用的返回值。双击进入这个被调用的函数。第五步进入这个函数后发现它接收一个参数大概率是用户输入然后对参数做了一系列操作有循环、有异或、有加减、有查表。最后返回一个结果。这个函数就是核心校验函数。第六步把核心校验函数的逻辑完整读一遍理解它对输入做了什么变换变换后的结果要和什么比较。3.2 核心变换逻辑的参数计算与还原这道题的核心变换我印象里涉及到一个逐字符的变换加上一个位置相关的偏移。具体来说程序对输入字符串的每一个字符根据它在字符串中的位置做了一个可逆的运算然后把运算结果和一个内置的字节数组比较。为什么用位置相关的变换因为这样即使两个字符相同在不同位置上变换后的结果也不同增加了直接猜解的难度。这是CTF逆向题里很常见的一种设计。还原这种逻辑关键是把变换的逆运算推出来。如果变换是output[i] input[i] XOR key[i]那逆运算就是input[i] output[i] XOR key[i]。如果变换里还有加减那逆运算就是反向的减加。只要变换是可逆的CTF题里的变换基本都是可逆的否则出题人自己也没法验证你就能从目标结果反推出正确的输入。我当时的做法是先把核心函数的汇编完整读一遍把每一步变换用伪代码写下来然后在纸上把逆运算推一遍最后写一个小脚本验证。脚本用Python写因为处理字节数组和循环最方便。# 伪代码示意具体数值以实际题目为准 target [0x12, 0x34, 0x56, ...] # 从程序里提取的目标数组 key [0x0A, 0x0B, 0x0C, ...] # 从程序里提取的密钥数组 flag [] for i in range(len(target)): # 假设正向变换是 (input[i] key[i]) ^ 0x55 # 逆运算就是 ((target[i] ^ 0x55) - key[i]) 0xFF c ((target[i] ^ 0x55) - key[i]) 0xFF flag.append(chr(c)) print(.join(flag))这段脚本的关键点在于 0xFF因为字节运算是模256的减法可能会出负数必须取模保证结果在0到255之间。这个细节新手很容易忽略导致算出来的字符是乱码。3.3 动态调试验证在关键点下断点静态分析推完之后一定要动态验证。验证的方法是在核心校验函数的入口和出口下断点观察输入和输出的实际值。在gdb里我一般这么操作gdb ./challenge # 先跑一遍随便输入一个测试字符串 run # 假设核心函数地址是0x400abc break *0x400abc # 重新跑这次会在函数入口停下来 run # 查看参数x64下第一个参数在rdi x/s $rdi # 单步执行观察变换过程 ni # 查看变换后的结果 x/20xb $rsp这里有个技巧在函数入口处打印参数在函数返回处打印返回值。这样你就能确认输入是什么、输出是什么然后拿这个输入输出对去验证你静态推出来的变换逻辑对不对。如果对不上说明你哪里读错了回到静态重新看。我在这道题里就遇到过一次对不上的情况。静态推出来的变换动态跑出来的结果差了一个字节。后来发现是循环的边界条件我读错了——循环多跑了一次导致最后一个字节被多处理了一遍。这种错误在静态分析里很常见因为汇编里的循环边界往往是用比较指令实现的jle和jl差一个等号结果就完全不同。注意动态调试的时候输入要选有特征的字符串比如AAAAAAA这样在内存里一眼就能认出来。如果输入全是随机字符观察起来很费劲。3.4 从校验逻辑到最终答案的完整还原把变换逻辑搞清楚、动态验证通过之后最后一步就是把目标数组提取出来跑逆运算脚本得到正确的输入。提取目标数组的时候要注意数组可能在.data段也可能在.rodata段还可能在栈上动态生成。如果在.data或.rodata直接在IDA里看就行如果在栈上就得动态调试的时候在内存里dump出来。这道题的目标数组我印象里是在.rodata段的因为它是常量编译的时候就确定了。在IDA里双击数组地址就能看到所有字节的值。复制出来粘到Python脚本里跑一遍答案就出来了。得到答案后再跑一遍程序输入这个答案确认输出是正确的提示。这一步是最终确认不能省。有时候脚本算出来的答案看起来对但程序就是不认那说明还有隐藏的校验逻辑没被发现。4. 常见问题与排查技巧实录4.1 静态分析卡住时的排查思路做逆向最怕的就是卡住——盯着一段汇编看了半小时还是不知道它在干什么。这时候硬看是没用的得换思路。我的排查清单是这样的问题现象可能原因排查方法函数太多找不到关键逻辑静态链接或函数未识别用字符串交叉引用定位或看main函数的调用链反编译结果看不懂编译器优化或类型推断错误回到汇编逐条指令读重点关注数据流循环边界搞不清楚比较指令的等号判断错动态调试在循环入口和出口下断点数循环次数变换逻辑推不出来漏看了某条指令或某个分支把函数完整反汇编出来逐行标注不跳步算出的答案程序不认有隐藏校验或变换不可逆动态跟踪整个校验流程看是否有多个校验点这张表里的每一条都是我实际踩过的坑。尤其是最后一条有隐藏校验特别容易被忽略。有些题会设计多层校验你过了第一层以为搞定了其实后面还有一层。排查方法就是在程序所有输出正确的地方都下断点看看到底有几个地方会输出正确提示。4.2 动态调试时的效率技巧动态调试的效率很大程度上取决于你下断点的策略。我总结了几条第一条断点下在函数入口不要下在函数中间。函数入口是逻辑的起点从这里开始单步你能看到完整的执行流程。如果下在中间你会错过前面的初始化逻辑。第二条善用条件断点。如果某个函数被调用很多次你只关心某一次可以下条件断点。比如break *0x400abc if $rdi 0x41414141这样只有参数等于特定值的时候才会停下来。第三条用finish快速跳出函数。如果你进入了一个不关心的函数不要一步步ni出来直接finish让它跑完当前函数回到调用点。第四条观察内存用x命令格式要选对。x/s看字符串x/10xb看10个字节的十六进制x/5i看5条指令。格式选错了看到的数据就是乱的。第五条把常用的gdb命令写成脚本。比如每次都要打印寄存器、栈、反汇编可以写个hook-stop每次停下来自动打印这些信息省得手动敲。4.3 变换逻辑还原时的数学陷阱还原变换逻辑的时候有几个数学上的坑特别容易踩坑一忘记取模。字节运算都是模256的加法和减法都可能溢出。0xFF 0x02 0x01不是0x101。如果你在Python里直接算得到的是0x101必须 0xFF才是正确结果。坑二异或的优先级。在C语言里^的优先级低于和-所以a b ^ c实际上是(a b) ^ c。如果你按数学直觉理解成a (b ^ c)那就错了。读汇编的时候指令的顺序就是运算的顺序不要用C的优先级去套。坑三有符号和无符号的混淆。汇编里的比较指令分有符号jg、jl和无符号ja、jb用错了会导致分支判断完全相反。判断方法看比较的数据来源如果是数组索引、长度这类通常是无符号如果是差值、偏移这类可能是有符号。坑四字节序。多字节数据在内存里是小端序低位在前。如果你从内存dump出来一个4字节整数直接按顺序读会读反。x/4xb看到的是01 00 00 00实际值是0x00000001不是0x01000000。提示写还原脚本的时候先用一个已知的输入跑一遍正向变换看看结果和程序实际输出是否一致。一致了再跑逆变换。这样能提前发现逻辑错误避免在错误的方向上越走越远。4.4 这道题带给我的通用经验做完这道题我最大的体会是逆向工程的核心不是读汇编而是理解程序在做什么。汇编只是表达方式就像你看一篇外文文章逐词翻译不如先理解段落大意。程序的结构、数据的流向、判断的条件这些才是关键。另外静态和动态一定要结合。纯静态容易想当然纯动态容易只见树木不见森林。静态建立框架动态验证细节两者交替进行效率最高。最后写脚本是必备技能。逆向题里大量的变换、比较、数组处理手工算几乎不可能必须用脚本自动化。Python是最顺手的选择pwntools库里的p32、p64、xor这些函数能省很多事。这道题我后来又用不同的工具复现了两遍一遍用IDAgdb一遍用Ghidraradare2确认思路是通的。工具会变思路不变。把思路练熟了换什么工具都能快速上手。