文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载花指令(junk code)是 Windows 逆向中一类典型的抗反编译技术:它在保持程序运行时行为完全正确的前提下,向真实代码中混入垃圾指令,使 IDA 等反汇编器产生错误的指令流与反编译结果。本文基于 ctf-wiki 中 Windows 反调试章节的 花指令文档,完整覆盖花指令的混淆原理、MSVC 与 GCC 两种编写手法、IDA 反汇编结果的成因与修复方式,并以一道真实的 CTF 题目为例,演示如何通过栈溢出转移控制流、结合 OD 动态跟踪,从花指令中还原出被隐藏的验证逻辑。一、花指令的原理与定位花指令是企图隐藏掉不想被逆向工程的代码块(或其它功能)的一种方法:在真实代码中插入一些垃圾代码,同时保证原有程序的正确执行,使得程序无法被很好地反编译,难以理解程序内容,从而对分析者达到混淆视听的效果。花指令通常用于加大静态分析的难度——程序运行起来没有任何异常,但静态打开反汇编窗口时,关键函数可能直接无法反编译,或者反编译出大量无意义的指令与跳转。从源码结构看,这类技术在本仓库中被归入 Windows 逆向的反调试技术导航之下(见 站点导航配置 中reverse/platform/windows/anti-debug/junk-code.md一项)。更广义的代码混淆视角(利用jmp、call、ret改变执行流来欺骗反汇编器)在 代码混淆:花指令 一文中有对应展开,两者可对照阅读。花指令之所以骗得过反汇编器,根源在于:反汇编器只能从字节序列按指令边界线性或图化地解析,它无法知道运行时真实的跳转落点;而一段精心构造的字节流,完全可以在运行时被合法跳过的同时,被静态解析成一条看似合理实则错误的路径。二、编写花指令:两种经典手法2.1 MSVC 内联汇编:jz/jnz跨字节 _emit最简单的花指令使用内联汇编完成。下面以 VC(MSVC)添加花指令的方式为例,GCC 系编译器也可以采用类似方式,只是改用 ATT 语法:// 正常的函数代码 int add(int a, int b){ int c 0; c a b; return c; } // 添加花指令的函数代码 int add_with_junk(int a, int b){ int c 0; __asm{ jz label; jnz label; _emit 0xe8; // call 指令,后面加 4 bytes 的地址偏移,因此导致反汇编器不能正常识别 label: } c a b; return c; }这段代码的巧妙之处在于三行汇编的配合:jz label与jnz label是覆盖全部标志位状态的成对条件跳转(ZF 置位走jz,ZF 清零走jnz),保证无论运行时状态如何,都会跳过中间那条_emit 0xe8字节,直接落入正常代码;_emit 0xe8向机器码中裸写了一个call的操作码字节,但它后面并没有合法的 4 字节相对偏移,它只是被运行时跳过的一块垃圾。用 IDA 打开该程序,添加花指令的函数无法被正常反编译,反汇编结果如下:// 添加了花指令 .text:00401070 loc_401070: ; CODE XREF: sub_401005↑j .text:00401070 push ebp .text:00401071 mov ebp, esp .text:00401073 sub esp, 44h .text:00401076 push ebx .text:00401077 push esi .text:00401078 push edi .text:00401079 lea edi, [ebp-44h] .text:0040107C mov ecx, 11h .text:00401081 mov eax, 0CCCCCCCCh .text:00401086 rep stosd .text:00401088 mov dword ptr [ebp-4], 0 .text:0040108F jz short near ptr loc_4010931 .text:00401091 jnz short near ptr loc_4010931 .text:00401093 .text:00401093 loc_401093: ; CODE XREF: .text:0040108F↑j .text:00401093 ; .text:00401091↑j .text:00401093 call near ptr 3485623h .text:00401098 inc ebp .text:00401099 or al, 89h .text:0040109B inc ebp .text:0040109C cld .text:0040109D mov eax, [ebp-4] .text:004010A0 pop edi .text:004010A1 pop esi .text:004010A2 pop ebx .text:004010A3 add esp, 44h .text:004010A6 cmp ebp, esp .text:004010A8 call __chkesp .text:004010AD mov esp, ebp .text:004010AF pop ebp .text:004010B0 retn从这份反汇编结果可以清晰看到花指令的破坏机理:jz/jnz的目标是loc_4010931,即0xe8字节的下一字节,运行时两个跳转都精确地跨过了那个0xe8;但 IDA 沿线性扫描把0x401093处的0xe8解码成一条完整的call near ptr 3485623h——它把后续 4 个本属于真实指令的字节当作 call 的相对偏移消费掉,得出一个不存在的地址0x3485623h;偏移被吃掉4 字节后,指令解码边界整体错位,真实的add等操作被解读成inc ebp、or al, 89h、cld这类毫无关联的垃圾指令。于是函数体在静态视角下彻底错乱,F5 反编译必然失败。修复方法也很直接:把0x40108F~0x401094这段混淆视听的花指令patch 成nop(0x90),恢复正确的指令边界后即可正常分析。2.2 GCC ATT 内联汇编:用push/call/pop/ret扰动栈值得注意的是,IDA 对栈的判定比较严格,因此push、ret一类的花指令会进一步干扰反汇编器的正常运行。下面给出一个用 gcc/g 编译的具体例子,读者可以自己编译复现:#include stdio.h // 使用 gcc/g 进行编译 int main(){ __asm__(.byte 0x55;); // push rbp 保存栈 __asm__(.byte 0xe8,0,0,0,0;); // call,压入返回地址 __asm__(.byte 0x5d;); // pop rbp - 获取返回地址 __asm__(.byte 0x48,0x83,0xc5,0x08;); // add rbp, 8 __asm__(.byte 0x55;); // push rbp - 相当于将 call 的返回值(返回地址)修改到下面去 __asm__(ret;); __asm__(.byte 0xe8;); // 这是混淆指令,不执行 __asm__(.byte 0x5d;); // pop rbp 还原栈 printf(whoami \n); return 0; }按照原文注释梳理其真实执行流:push rbp先保存栈基址;call(机器码为E8 00 00 00 00)把下一个执行位置的地址压栈;紧接着的pop rbp把这个返回地址取到rbp中,再add rbp, 8将其向后偏移 8 字节;push rbp把修改后的值写回栈顶,相当于把 call 的返回地址改道到后面;执行到ret时,实际控制流落到后面那两个垃圾字节处的pop rbp,还原栈后继续向后执行printf。整条路径上:真实程序:栈被完整保存、修改、还原,程序正常打印whoami;反汇编器:沿线性解析看到的是call → 若干指令 → ret的标准形态,它认定的返回目标、栈变化与运行时实际落点并不相符,函数边界与栈帧推断随之出错。这正是push/ret类花指令比 2.1 节跳过单个字节型更强的地方:它不是简单地错开指令边界,而是直接污染对返回路径的静态推断。三、实战例题:看雪 TSRC 2017 秋季赛第二题下面以看雪.TSRC 2017 CTF 秋季赛第二题(ctf2017_Fpc.exe)为例,完整演示题目作者如何用花指令藏逻辑、分析者如何把逻辑挖出来。3.1 题目设置:虚假的验证函数 不可反编译的关键函数程序写了几个函数混淆视听,将关键的验证逻辑加花指令,防止 IDA 的静态分析。用 IDA 打开该程序,主函数会先打印提示信息,然后获取用户输入:这里使用了不安全的scanf函数,用户输入直接落入v1缓冲区。双击v1进入栈帧视图:用户输入的缓冲区只有0xC长,其后就是函数返回地址。因此我们可以通过溢出数据覆盖返回地址,将控制流转移到任意地址继续执行。题目中scanf之前的那几个验证函数其实是一些简单方程式,但实际上是设计成无解的诱饵;真正的验证逻辑被加花混淆,导致 IDA 无法很好地反编译。因此这道题的整体思路是:利用溢出漏洞,把执行流转到真正的验证代码处,再继续分析。3.2 定位被当作数据块的真实验证代码在分析时,可以在代码不远处发现一个 IDA 未能识别为代码的数据块——那正是被花指令伪装过的真实验证逻辑。因为 IDA 没能很好地识别这段数据,操作方法是:将光标移到数据块的起始位置,按下C键(把 data 改为 code),让 IDA 把这块数据反汇编成代码。值得注意的是,这段代码位于0x00413131:0x41是A的 ASCII 码,0x31是1的 ASCII 码,也就是地址本身就是 A1 字符序列。由于看雪比赛对输入的限制,用户输入只能是字母和数字,因此利用溢出漏洞跳转到这段代码是完全可行的(返回地址恰好可以由合法字符拼出)。3.3 用 OD 动态跟踪还原花指令执行流用 OllyDbg(OD)打开程序,CtrlG跳转到0x413131处设下断点,运行后输入12345612345611A回车,程序成功到达0x00413131处;随后右键选择分析 → 从模块中删除分析,让 OD 重新识别出正确代码。断在0x413131后,点击菜单栏的查看选择RUN 跟踪,再点击调试选择跟踪步入,程序会记录这段花指令的完整执行过程:这段花指令本来很长,但使用 OD 的 RUN 跟踪功能后,花指令的执行流程就变得非常清楚:整个过程中进行了大量跳转,我们只需要把其中有效指令挑出来分析即可。需要注意的是,在有效指令中依旧要满足一些条件跳转,程序才能在正确的逻辑上一直执行下去。例如0x413420处的jnz ctf2017_.00413B03:如果按当前状态执行会走错分支,就需要重新来过,并在0x413420处设下断点,通过修改标志寄存器来满足跳转条件。继续跟踪步入(之后还有0041362E jnz ctf2017_.00413B03需要满足),保证逻辑正确后,将有效指令取出继续分析即可得到真正的验证逻辑。四、方法小结与延伸把本例题的处理过程抽象出来,针对花指令的逆向路径可以归纳为四步,每一步在本文例题中都有对应落点:静态识别混淆:函数无法 F5、出现不存在的call 3485623h式目标、成对的jz/jnz指向同一位置 1、数据块中藏着可执行代码,都是花指令的典型指纹;修复指令边界:对 2.1 节型花指令,将混淆区域 patch 为nop(0x90)即可恢复正确反汇编;数据改代码:对 IDA 误判为 data 的真实代码,将光标置于块首按C键重命名,再删除已有分析让反汇编器重建;动态跟踪取证:当静态修复代价过高时,借助溢出等可控入口把执行流导入目标代码,用 OD 的RUN 跟踪 跟踪步入记录真实执行轨迹,辅以修改标志寄存器满足条件跳转,最终从轨迹中提炼有效指令。对于push/call/pop/ret 扰动栈这类更顽固的花指令(参见 2.2 节),静态 nop 修复往往不足以恢复 IDA 的栈推断,动态跟踪是更可靠的手段。延伸阅读:代码混淆:花指令(含 N1CTF2020 oflo 例题的逐字节 patch 分析)Windows 反调试技术:花指令(简体版)站点导航:Windows 逆向 → 反调试技术赞分享文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载相关推荐ctf-wiki 花指令Junk Code去除实战原理、编写手法与 N1CTF2020 oflo 完整分析流程ctf wiki 花指令Junk Code去除实战原理、编写手法与 N1CTF2020 oflo 完整分析流程 花指令junk code是静态逆向中常文档网络安全教程ctf-wiki Windows 逆向实战CheckRemoteDebuggerPresent 反调试检测原理与绕过ctf wiki Windows 逆向实战CheckRemoteDebuggerPresent 反调试检测原理与绕过 本文基于 ctf wiki 中 Wind文档网络安全教程ctf-wiki Linux 逆向实战ptrace 反调试检测原理与两种绕过方法ctf wiki Linux 逆向实战ptrace 反调试检测原理与两种绕过方法 本篇基于 ctf wiki 仓库的 detect dbg.md https:文档网络安全教程上一篇AMD Phi-4-reasoning-plus-w8a8-llmcompressor-v0.12.0震撼发布革命性8位量化技术如何让CPU推理效率提升46%下一篇Stable-Worldmodel与LeRobot集成从Hub数据集到模型训练的无缝衔接指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考