Estara的小窝 http://estara.blog/ 一个NotionNext搭建的博客 Fri, 26 Jun 2026 17:00:07 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en-US All rights reserved 2026, estara <![CDATA[机器学习入门]]> http://estara.blog/article/3713139c-9ee7-802a-9496-ce94127c78b0 http://estara.blog/article/3713139c-9ee7-802a-9496-ce94127c78b0 Wed, 03 Jun 2026 00:00:00 GMT <![CDATA[IO_FILE结构以及vtable相关知识]]> http://estara.blog/article/25c3139c-9ee7-800e-b426-e9da6df39ab5 http://estara.blog/article/25c3139c-9ee7-800e-b426-e9da6df39ab5 Fri, 15 Aug 2025 00:00:00 GMT

IO_FILE结构

1.在 C 语言中，我们使用 FILE* 指针来操作文件（如 fopen, fread, fprintf 等）。这个 FILE 实际上就是 IO_FILE 结构体（在早期版本中直接定义为FILE，现代Glibc中FILE是 struct _IO_FILE 的别名）。
简单来说，IO_FILE 结构是 Glibc 用于管理文件流（file stream）的内部数据结构。它包含了处理一个文件所需的所有信息：文件描述符、缓冲区指针、缓冲区大小、当前读写位置、错误和结束标志等。 每一个你用fopen()打开的文件，在用户空间的 Glibc 层都会有一个对应的 IO_FILE 结构体实例。我们常见的标准输入、输出、错误流（stdin, stdout, stderr）也是三个预定义好的 IO_FILE 结构体。不过需要注意的是这三个文件流位于 libc.so 的数据段。而fopen创建的文件流是分配在堆内存上的。 2.FILE结构定义在libio.h中，具体结构如下：
相关参数说明：
  1. _flags:
      • 这是一个非常重要的字段，它包含了各种状态标志。
      • 标志位定义了流的属性，例如：
        • _IO_NO_READS (0x0004): 流不可读。
        • _IO_NO_WRITES (0x0008): 流不可写。
        • _IO_EOF_SEEN (0x0010): 已到达文件末尾（EOF）。
        • _IO_ERR_SEEN (0x0020): 发生了错误。
        • _IO_USER_BUF (0x0001): 缓冲区由用户提供，而非库分配。
      • 最重要的是，它的高16位必须等于魔数 _IO_MAGIC (0xFBAD0000)，用于验证这是一个合法的IO_FILE结构。
  1. 缓冲区指针:
      • 这组指针管理着用户的 I/O 缓冲区。fread和fwrite等函数并不是每次都直接调用系统调用，而是先在这个缓冲区中进行操作，满了或空了再与内核交互，极大提高了效率。
      • _IO_read_base -> 缓冲区的起始地址。
      • _IO_read_ptr -> 当前读取的位置。
      • _IO_read_end -> 缓冲区中有效数据的结束位置。
      • _IO_write_* 系列指针同理，用于输出缓冲区。
  1. _fileno:
      2. 这个整数存储着底层操作系统提供的文件描述符（file descriptor）。例如，stdin的_fileno是0,stdout是1，stderr是2。当你用fopen打开一个文件时，open()返回的fd就存放在这里。
4._offset
记录当前文件的偏移量。

Vtable

为了支持不同类型的文件，Glibc使用了一种类似C++虚函数的机制，每个IO_FILE结构体都包含了一个指向其虚函数表vtable的指针。
vtable是包含众多函数指针的结构体，当调用 fread,fwrite,fclose等函数时，最终会通过这个vtable找到对应的函数来执行具体的操作。 实际上，一个完整的文件流结构是struct_IO_FILE_plus，它包含一个标准的IO_FILE和一个vtable指针
vtable是IO_jump_t类型的指针，IO_jump_t本身是一个结构体，所以vtable本身就是一个巨大的函数指针数组结构。
关键函数指针说明：
  • __overflow: 对应于输出缓冲区满时的操作（类似 fflush）。
  • __underflow: 对应于输入缓冲区空时的操作（类似 fillbuf）。
  • __finish: 对应于流关闭时的操作。
  • __close: 底层的关闭操作。
  • __read 和 __write: 底层的读和写系统调用包装。
对于普通文件，这个vtable指针指向一个名为 _IO_file_jumps 的全局结构体。对于内存流，它可能指向 _IO_mem_jumps。
示意图总结：

常见的IO函数

fopen

fopen在标准IO库中用于打开文件，函数原型：
filename是打开文件路径，type指打开方式，返回一个文件指针。其具体实现逻辑如下：
实现流程为：
1.调用malloc分配FILE空间，分配了一个struct locked_FILE大小的结构体，并将返回的地址赋给了new_f变量。它包含三种变量：：_IO_FILE_plus、_IO_lock_t、IO_wide_data，其中_IO_FILE_plus为使用的IO_FILE结构体。
2.调用IO_no_init对FILE初始化
3.调用IO_file_init将结构体链接到IO_list_all链表
IO_list_all:
IO_list_all是一个指向IO_FILE_plus结构体的指针。所有的FILE并非孤立的存在，而是通过 _IO_FILE 结构体内部的chain字段连接形成一个单链表。IO_list_all就是这个链表的头指针。
 
4.调用IO_file_fopen根据用户传入的模式，进行系统调用打开文件

过程详解

 

fread

fread是标准IO库函数，作用是从文件流中读数据，函数原型：
buffer是存放读取数据的缓冲区，size是指定读取的每个记录的长度，count是指定记录的个数，stream是文件流，返回读取到缓冲区的记录个数。具体实现逻辑：
逻辑就是计算总字节数，加锁，然后调用 _IO_sgetn，最后解锁并返回结果。_IO_sgetn 是一个定义在vtable中的函数指针。
该函数又指向IO_FILE_xsgetn,这个函数是高效读取的核心：
__underflow是vtable中的另一个关键函数指针。对于普通文件，它指向_IO_new_file_underflow。
通过 _IO_SYSREAD 宏调用底层__read函数。这个宏展开后就是fp->vtable->__read(...)

fwrite

fwrite是标准IO库函数，作用是向文件流写入数据，函数原型如下:
buffer是写入数据的地址，size是写入内容的单字节数，count是数据项个数，stream是目标文件指针，返回写入的数据项的个数。实现逻辑：
总体逻辑：计算总字节数，加锁，然后调用IO_sputn,最后解锁并返回结果。
这里IO_sputn是vtable中的一个函数指针，对于一个普通文件，它指向IO_FILE_xsputn:
重点是__overflow,它是vtable中与__underflow相对应的函数指针，也是FSOP攻击的核心目标。对于普通文件，它指向 _IO_new_file_overflow。（FSOP到时候写在另一篇文章里）
_IO_do_write是一个封装函数，它最终会调用vtable中的 __write函数：
对于普通文件，__write 指向 _IO_file_write:

Vtable伪造

由前面的内容我们知道，一些常见的IO函数都需要经过FILE结构的处理，会通过IO_FILE_plus中的vtable指针对一些函数进行调用，所以我们伪造的方向可以分为两种：
  • 一种是直接改写vtable指针，让它指向一个伪造的虚表，再对特定偏移处写入我们想让程序执行的指令
  • 另一种是改写vtable中特定偏移处的函数指针，但是stdin/stdout/stderr的vtable是存放在数据段的不可改写，这种方法不适用
这里还是主要讲一下面向对象的vtable：
C++为了实现运行时多态，引入了虚函数的概念。当一个基类指针指向一个派生类对象，并调用一个虚函数时，实际调用的是派生类中重写的那个函数版本。
编译器是如何实现这一神奇功能的呢？答案就是虚函数表（VTable）。
  • 是什么：VTable是一个函数指针数组。每个包含虚函数的类（或者从包含虚函数的类派生而来）都会有一个或多个对应的VTable。
  • 内容：VTable中的每一个条目（slot）都指向该类的一个虚函数的具体实现地址。
  • vptr（虚表指针）：当一个类包含虚函数时，编译器会隐式地在每个对象实例的内存布局的最开始添加一个隐藏的成员变量——vptr。这是一个指针，指向该对象所属类的VTable。
示例：
对于每一个Derived对象，它的大致布局如下：
💡
+---------------------------+ <-- derived_obj 地址 | vptr (指向 Derived的vtable)| (8字节，在64位系统上) +---------------------------+ | Base::a | (4字节，来自基类) +---------------------------+ | Derived::b | (4字节，来自派生类) +---------------------------+
其中vtable结构如下：
💡
Derived's vtable: +-------------------------------+ | &Derived::func1 (覆盖了Base) | // 条目0 +-------------------------------+ | &Base::func2 (从Base继承) | // 条目1 +-------------------------------+ | &Derived::func3 (新增的虚函数) | // 条目2 +-------------------------------+
当调用 derived_obj->func1() 时，会发生：
  1. CPU 从 derived_obj 开头取出vptr。
  1. 通过vptr找到vtable。
  1. 在vtable的第0个条目找到func1的地址(&Derived::func1)。
  1. 跳转到该地址执行。
虚函数调用完全依赖于对象的vptr所指向的内存数据。

例题补充（未完待续）

这是2025sekaictf的一道题，题目给处了源码，直接看源码：
这个程序是一个宠物管理系统，用户可领养狗、猫、鹦鹉、马等宠物，通过菜单进行与宠物玩耍、喂食、让其休息等互动；每次选择之后，update函数会让宠物年龄+1，饱腹感-1,年龄达到最大值或者饱腹感为0时会死亡；用户在仍有宠物时无法退出。每个宠物对象初始年龄为0，饱腹感为10，喂食会让其饱腹感为20。
由于我们控制的是堆结构，具体是哪种宠物对我们来说不重要，这里可以选择年龄上限最大的马进行创建。Animal类结构：
💡
+-----------------------+ | vptr (8字节) | --> 指向 Animal 的虚函数表 +-----------------------+ | name[0x100] (256字节)| | | | | +-----------------------+ | age (4字节) | +-----------------------+ | fullness (4字节) | +-----------------------+ | status (4字节) | +-----------------------+ | 填充 (4字节) | // 为了8字节对齐 +-----------------------+
Animal vtable:
💡
+-----------------------+ | &Animal::eat | +-----------------------+ | &Animal::sleep | +-----------------------+ | &Animal::play | +-----------------------+ | &Animal::get_max_age| (纯虚函数，实际为0或占位符) +-----------------------+
HORSE vtable:
💡
+-----------------------+ | &Horse::eat | // 重写Animal::eat +-----------------------+ | &Horse::sleep | // 重写Animal::sleep +-----------------------+ | &Horse::play | // 重写Animal::play +-----------------------+ | &Horse::get_max_age| // 实现纯虚函数 +-----------------------+
观察函数，Animal类中set_name()的std::cin >> this->name没有控制字节，存在堆溢出；die()函数会输出name的内容，并且name起始位置实在堆地址+8的位置，故无法通过tachebin或者fastbin泄露fd,于是想到unsortedbin泄露bk，从而获取libc。动调很容易看出一个HORSE对象占用0x120字节，堆溢出可以修改size,想要其分配到unsortedbin至少大小为0x480,分配4个堆块b、c、d、e,这四个堆块之前分配一个堆块a用于溢出改写下一个chunk的size,最后面还要分配一个堆块f防止和top_chunk合并，一共分配6个堆块。泄露libc大致过程：
  • 分配a,b,c,d,e,f堆块，每个堆块可以溢出控制其age和fullness为合适的值让其在某一时刻被free
  • 6次操作后a刚好free掉，再次new()可复用a，溢出改写b的size为0x481
  • b被free，b、c、d、e一起进入unsortedbin
  • new()操作unsortedbin分割，b被复用，c堆块被写入fd、bk,也就是name开始8字节变成bk的值
  • c的fullness变成0，输出其name再被free,成功泄露libc
后面伪造vtable暂时还没写出来，后面补充。
补充来了👇：
这题既然题目给出libc和动态链接器，所以就用题目的吧，先patch一下，先把libc和动态连接器文件放到题目可执行文件所在目录下，接着输入：
 
 
 
]]> <![CDATA[SQL注入学习]]> http://estara.blog/article/2633139c-9ee7-803e-8fb7-dd793b9b0cad http://estara.blog/article/2633139c-9ee7-803e-8fb7-dd793b9b0cad Wed, 03 Sep 2025 00:00:00 GMT <![CDATA[堆练习wp（暑假）]]> http://estara.blog/article/23d3139c-9ee7-80ac-9db7-ed81c404f574 http://estara.blog/article/23d3139c-9ee7-80ac-9db7-ed81c404f574 Sun, 27 Jul 2025 00:00:00 GMT
💡
续之前在语雀的文章

2025NepCTF ASTRAY

这道题逆向难度挺大的，本人复现的时候也是花了将近半天才把程序的整个逻辑和结构搞明白
checksec保护全开

分析

main函数

init函数

首先malloc了一个超级大的堆块chunk1，以malloc过来的地址为起始，每隔256字节为一个地址，按顺序存放在位于bss段的manage_physic数组中（相当于把这个大堆块分割成等大的小堆块）；dword_4068数组下标1-9元素为2，10-19为3,0下标对应16；qword_41a8处存放了新malloc的chunk2地址并对chunk2作了初始化；chunk1往后16字节处存放onlyuser的地址，往后8字节处存放再次malloc的chunk3地址，并对chunk3作初始化，chunk1[0]变为1。

manager_operation函数

check函数

permission_confirm函数

checkvisit函数

user_operation函数

函数比较多，文字解释不如图形象生动👇：
notion image
💡
  • MANAGER 操作
    • MANAGER_visit（opcode1=8）
      • 📖 读取：opcode1=6 → user_chunk →choose_chunk
      • 📝 写入：opcode1=3 → user_chunk →choose_chunk
    • MANAGER_read（opcode1=4）：📖 从 manager_chunk中choose_chunk指向位置读取
    • MANAGER_write（opcode1=2）:📝 从 manager_chunk中choose_chunk指向位置写入
  • UER 操作
    • UER_read（opcode2=4）：📖 从 user_chunk中choose_chunk指向位置 读取
    • UER_write（opcode2=1）：📝 从 user_chunk中choose_chunk指向位置写入
其中check函数中MANAGER_write和USER_write操作会进行权限检查，MANAGER_write操作要求chunk2+8的地方为2，USER_chunk要求chunk3+8的地方为3。

解题思路

  • 无论是manager操作还是user操作，都没有对数组下标进行检查，也就是说若输入堆序列为0，程序并不会报错，而manager_read是不会进行权限检查的，利用manager_read可以直接泄露出chunk1中的&manager_chunk和&onlyuser，相当于泄露了堆地址和pie基地址。
 
  • 从图中可以看出，下标为0的chunk（这里叫做key_chunk）是个关键，因为这里存放着可以控制写入的地址，一旦&manager_chunk和&onlyuser的值被篡改就会造成任意地址写，而二者定是要通过write功能修改，manager_write要求chunk1+8处为2，但是对于key_chunk，chunk1+8为最为特殊的值16，不可行；user_write同理；那么唯一的路径就是通过manager_visit中的write功能了。从manager功能入手，check函数manager_visit会有这么一个检查:!strcmp(a2, "MANAGER_visit") && !*(_QWORD *)qword_41A8 ,也就是说chunk3中的&choose_chunk必须存在，要先进入user功能进行操作，checkvisit函数要求opcode2不能为4(不能读操作），user功能也允许manager操作，所以先进入user选择user_write返回opcode2为2，再用user功能选择manager_visit返回opcode2=8,然后利用manager功能选择manager_visit_write,就可绕过检查实现往key_chunk的写入。
 
  • 修改了&onlyuser使得manager_visit_write写入操作具有局限性，故可利用两次机会修改dword_4068[0]中的16，更改后的值&2返回值非零，这样便可无限利用manager_write了。第一次往key_chunk写入，这里存在多级指针&onlyuser+8→&chunk3→&choose_chunk→写入的地方 ，于是往key_chunk写入的时候，前16字节填充，从&onlyuser开始，依次改为p64(&chunk1+0x18)+p64(&chunk1+0x28)+p64(dword_4068的地址),逻辑即为&chunk1+0x18+0x8处指向&chunk1+0x28处，&chunk1+0x28处又指向dword_4068。第二次manager_visit_write会根据&chunk1+0x18处的值，即往dword_4068写入，这里将16改为0xf。
 
  • 理解上一步之后后面就比较轻松了，利用manager_write修改&chunk1+0x18指向puts_got,利用manager_visit_read泄露libc。因为这题不能覆写got表因此想到返回地址的修改，返回地址的修改依靠栈地址的泄露，于是想到用libc找到environ的真实地址，然后再次manager_write往key_chunk写入修改&chunk1+0x18指向environ,manager_visit_read泄露出栈地址。
关于environ：
  • environ 通常指代 C 标准库中的全局变量 _environ，它指向程序的环境变量数组。
  • 通过读取 _environ 的值，可以获得环境变量的地址。由于环境变量存储在栈上，可以利用这个地址计算出栈的基址，从而进一步泄露其他敏感信息（如返回地址、函数地址等）。
 
 
 
  • 根据偏移找到存放manager_operation函数返回地址的栈地址，利用manager_write修改&chunk1+0x18指向返回地址，利用manager_visit_write改返回地址为rop链即可。
关于偏移的寻找，动调即可，如下图在main函数调用manager_operation时刻：
notion image
下一条指令地址即为返回地址，s进入operation函数，如下图看到返回地址存放的栈地址和泄露出的栈地址偏移为0xbc0-0xa78=0x148：
notion image

exp:

buuctf hitcontraining_magicheap 1

notion image
create_heap:
edit_heap:
delete_heap():
133t()是后门函数。
还是那几个功能就不多说了，漏洞依然在edit函数size没有做检查，存在堆溢出。magic位于bss段0x6020a0处，初始值为0，大于0x1305就执行后门，利用fastbin attack就行，前面都说过了，这里简单说一下思路吧：
1.分配3个0x60大小的堆块
2.释放第2个堆块使其进入fastbins
3.编辑第1个堆块，溢出修改第2个堆块的fd指向magic附近，依旧是利用错位思想构造size
4.连续两次malloc，第2次malloc的堆块是fake_chunk,写入修改magic的值大于0x1305即可
伪造的chunk位于0x60209d处，fd改为0x60208d：
notion image
exp:
]]> <![CDATA[pwn知识点复习和拓展]]> http://estara.blog/article/2693139c-9ee7-800d-8d16-c168caa96f55 http://estara.blog/article/2693139c-9ee7-800d-8d16-c168caa96f55 Tue, 09 Sep 2025 00:00:00 GMT <![CDATA[tachebins相关知识]]> http://estara.blog/article/2453139c-9ee7-8048-a236-c073ce12594c http://estara.blog/article/2453139c-9ee7-8048-a236-c073ce12594c Sun, 24 Aug 2025 00:00:00 GMT

基础知识

Tcache(Thread Local Caching)，即线程本地缓存，是 glibc（从版本2.26开始）引入的一种性能优化机制。
  • 目的： 提升堆内存分配的性能。在多线程程序中，传统的堆分配需要频繁地对主堆区（main_arena）进行加锁和解锁操作，这在多核高并发场景下会成为性能瓶颈。
  • 核心思想： 为每个线程预先分配一个专属的、无锁的缓存池。当线程需要分配小块内存时，优先从这个缓存池中获取；释放时也优先放回这个缓存池。这样就避免了与其他线程竞争全局堆锁，大大加快了分配和释放的速度。
Tcache的管理是通过一系列单向链表来实现的，这些链表被称为tcache bins。
  • 数量与大小：
    • 默认有64个tcache bins。
    • 每个 bin 负责一个特定大小的内存块。
    • bin 0 -> 负责24字节的 chunk（在 64 位系统上，考虑对齐后的实际大小）
    • bin 1 -> 负责32字节的 chunk
    • bin 2 -> 负责40字节的 chunk
    • ...
    • bin 63 -> 负责1032字节的 chunk
  • 数据结构：
在每个线程的堆管理结构中，有一个名为tcache_perthread_struct的关键结构：
  1. counts[i]： 记录第i个bin中当前有多少个chunk,每个bin的容量上限是7个chunk。
  1. entries[i]：指向一个单向链表，链表中的每个节点都是一个空闲的堆块。
  • 链表结构 (tcache_entry)：
Tcache bins是单向链表。每个被释放并放入tcache的chunk，其用户数据区域的开头
会被当作一个tcache_entry结构体：
这与fastbin中的fd类似。

攻击手法

  • tache poisoning
基本原理是通过覆盖next为控制的地址并利用malloc得到写入权限，并且目标地址无需伪造合适的size
  • tache dup
利用tache_put()函数不严谨：
该函数没有做任何检查，于是可以修改counts数组中的值，也可以对同一个chunk进行多次free，进而泄露堆地址。
  • tache house of spirit
（这个笔者暂时还没学到，以后补充）
这里补充一点，在glibc2.29及其之后，链表结构就变了：
新引入的key字段正是针对攻击者对同一块chunk多次释放的轻量级缓解措施：
  • 当一个chunk被放入tachebins时，除了设置next指针，还会添加key字段设置为指向这个 tcache所属的主管理结构（tcache_perthread_struct）的地址,作为已经释放的标记。
  • 在再次释放时：当free函数尝试再次释放同一个chunk时，它会检查该chunk的key字段,如果key字段的值等于当前线程的tcache_perthread_struct的地址，这就意味着这个chunk 已经在这个tcache的空闲链表里了,glibc 会立即检测到这是一个 Double Free 行为，并终止程序。
除此之外，还有另外一种保护措施Safe-Linking(指针加密）。
Safe-Linking 对每个放入Tcache链表的next指针进行了一个轻量级的加密处理，在从链表中取出时再进行解密。
  • 加密（当chunk被free并放入链表时）：
      • 存储的next指针不再是真正的下一个chunk的地址，而是：
      加密后的_next = (真正的_next >> 12) ^ 当前 chunk 的地址
  • 解密（当chunk被malloc并从链表中取出时）：
      • 程序会从链表头取出chunk，然后根据存储的加密值，计算出真正的next指针：
      真正的_next = (加密后的_next ^ 当前 chunk 的地址) << 12
这就给tache poisoning攻击手法造成了极大困难。

例题

题目给出了源码，直接分析源码：
这段代码实现了一个简单的字符画布交互程序，主要功能如下：
  1. 初始化一个默认 20x20 的字符画布，画布上的元素默认用 '.' 表示。
  1. 提供交互式命令操作，支持以下功能：
      • 绘制（p命令）：在指定坐标 (arg1, arg2) 处绘制十六进制字符arg3。
      • 调整大小（r命令）：将画布重新设置为 arg1 x arg2的尺寸，同时清空画布内容。
      • 帮助（h命令）：显示操作说明。
      • 退出（e命令）：结束程序。
3. 实时显示当前画布状态，并等待用户输入下一个操作命令。
这个程序存在一个很明显的漏洞就是没有对数组下标做检查，可以实现越界读写，于是我们可以想到利用越界读写修改tache结构体，使其分配到指定位置。
主要利用思路：
  • 绘制画布，利用数组越界改写tache结构体中0x20位置的count为1，对应的指针改成got表附近的地址，避免画布清空覆盖got表
  • 调整画布大小为0x20,越界覆写free地址为printf
  • 绘制当前画布，从开头写入格式化字符串
  • 调整画布为20x20，此时调用free，触发printf格式化字符串漏洞泄露栈上的libc_start_main地址，进而泄露libc;目前堆块的位置仍在最开始的20x20的堆处
  • 再次绘制画布，将tache结构体0x20的count仍改为1，对应指针改成got附近的地址
  • 调整画布大小为0x20,越界覆写free地址为system
  • 绘制当前画布，从开头写入/bin/sh
  • 输入命令h，调用free,执行system(”/bin/sh”)
exp:
 
]]>