现代Windows系统堆溢出利用

1. 现代Windows系统堆结构与布局

现代 Windows 系统(Windows 10Windows 11 以及最新的 Windows Server 2025/2026)中,堆管理架构经过了彻底的安全重构。为了彻底终结传统的堆溢出利用,微软对堆的底层结构进行了深度加固,其核心设计理念是:“彻底隐藏元数据、全面隔离不同类型的对象、以及完全随机化分配顺序”

现代 Windows 堆结构主要由段分配器(Segment Heap)低碎片堆(LFH, Low Fragmentation Heap)主导,传统的 NT 堆(NT Heap)已退居幕后(仅用于极少数兼容场景)。

1.1 现代堆的核心架构:段分配器 (Segment Heap)

从Windows 10版本开始,微软引入了段分配器(Segment Heap)作为现代核心态和用户态的主流堆管理机制(例如:所有 UWP 应用、Edge 浏览器、以及大部分系统核心服务默认强制启用,内核 Pool 也在向其演进);

分配器根据申请内存的大小,将分配策略分为三类:

  • 1. 小块分配(通常 ≤ 16KB):由现代 LFH(低碎片堆) 驱动管理;
  • 2. 中块分配(通常 16KB 至 508KB):VS(Variable Size)分配器 管理;
  • 3. 大块分配(通常 > 508KB):直接向系统申请内存页(Page Allocation);

1.2 现代堆的关键结构体与加固机制

在现代 Windows 中,传统的堆头(如旧版本的 HEAP_ENTRY)已被重新设计和加密,攻击者无法再通过直观的内存 dumping 来轻易获取和伪造堆结构;

1.2.1 堆头元数据加密(Heap Cookie)

现代堆头结构(如 _HEAP_VS_CHUNK_HEADER)包含了块大小(Size)、内部碎片大小等关键元数据。为了防止堆溢出篡改这些数据,微软使用了以下加固:

  • XOR 异或加密:堆头在写入内存前,会与一个进程唯一的随机密钥(Heap Key)进行 XOR 操作,并且会结合该堆块自身的内存地址进行哈希计算
  • 校验破坏立即蓝屏/闪退:当程序释放(Free)或重新分配该块时,堆管理器会解密并校验堆头。如果攻击者通过堆溢出覆盖了相邻的堆头,解密后的数据将彻底变成乱码,无法通过校验,系统会立即触发 STATUS_HEAP_CORRUPTION 并导致进程闪退或内核蓝屏(BSOD);

1.2.2 VS(Variable Size)分配器结构

中等大小的内存块由 VS 分配器管理。它不再使用传统的空闲双向链表,而是采用红黑树(Red-Black Tree)来管理空闲的内存块;

这彻底终结了经典的 DWORD SHOOT(利用双向链表拆卸进行的任意地址写)。因为红黑树的平衡旋转操作非常复杂且带有极其严格的上下游指针合法性校验(Safe Unlink 升级版),攻击者几乎不可能通过溢出伪造一个合法的红黑树节点。

1.3 现代 LFH(低碎片堆)的核心变化:彻底随机化

由于绝大多数导致漏洞的结构体都属于小块分配(< 16KB),现代 LFH 是攻防是对抗的核心战场。

1.3.1 基于桶(Bins)的分层管理

LFH 将不同大小的申请划分到不同的“桶”(Bins / Buckets)中(例如,32字节一个桶,64字节一个桶)。同一种大小的对象会被集中分配在同一个 LFH 内存段中。

1.3.2 彻底的分配随机化

这是现代 Windows 堆结构最强悍的防御手段

  • 以前:LFH 的分配是确定性的。如果连续释放块 A,再申请块 B,块B必然落在块 A 的物理位置上;
  • 现在:现代 LFH 引入了内部的随机数生成器(RNG)和位置数组(Slots)。当程序申请一个 LFH 堆块时,堆管理器会在该桶内所有的空闲位置中随机抽取一个槽位(Slot)返回给用户;
  • 影响:这使得经典的精准堆风水(Heap Grooming)变得极度困难。攻击者无法确保自己分配的“溢出源”和“目标受害者”在物理上刚好相邻;

1.4 现代内核堆的“杀手锏”:类型隔离 (Type Isolation)

针对Win32k或内核RPC提权,现代 Windows 内核(特别是 Win11 及更新版本)引入了类型隔离(Type Isolation)和安全池(Secure Pools)。

1.4.1 消除“大通铺”,按类型开辟独立堆空间

在过去,Win32k 的图形缓冲区和通用的网络数据包缓冲区都挤在同一个内核分页池(Paged Pool)里,攻击者可以用任何漏洞块去溢出覆盖任何目标对象:

  • 现代结构:微软对关键、敏感的内核对象进行了“物理隔离”。例如,特定的图形对象(如 Palette 或窗口对象)拥有自己专属的、独立的堆空间,与其他通用的内核分配完全隔绝;
  • 结果:即使攻击者在通用的内核 RPC 缓冲区中触发了堆溢出,由于物理隔离,该溢出绝不可能触碰到位于另一个独立堆空间中的敏感图形对象;

1.4.2 内核虚拟化保护(VBS / HVCI)

在最新的 Windows 11 环境中,堆管理器与基于虚拟化的安全性(VBS)深度结合:

  • 即使攻击者利用纯数据攻击(Data-Only)修改了某些堆对象的内部指针,如果他们试图进一步利用该指针去改写内核代码段,硬件级的 HVCI(虚拟机转换代码完整性) 将直接拒绝,因为代码页被严格配置为只读;

2. Windows系统堆的内存布局

在现代 Windows 系统(Windows 10/11 及 Server 2025/2026)中,一个进程的堆内存布局(Memory Layout)是非常宏观且层次分明的结构。它从最底层的系统虚拟内存页开始,经过堆管理器的组织,最终呈现为用户代码看到的动态内存块。

Windows 堆管理架构经历了从传统的 NT Heap 到现代 Segment Heap(段堆) 的演进。在 Windows 10(1903+)及 Windows 11 中,两种堆架构在用户态与内核态并存,但 Segment Heap 已逐步成为默认的主导架构。

现代 Windows 堆(以段分配器 Segment Heap 为主)在进程虚拟地址空间中的完整内存布局可以分为以下四个层级:

2.1 第一层:虚拟地址空间级

在进程的虚拟内存中,堆并不是一块连续的、固定的大内存,而是由许多离散的、在不同时间动态申请的“段”(Segments)组成的:

  • 基地址随机化:受到 ASLR(地址空间随机化) 的保护,堆的起始基地址在每次进程启动时都是随机的;
  • 按需扩展:当进程调用 HeapAlloc malloc 且当前堆空间不足时,堆管理器会调用 VirtualAlloc 向操作系统内核申请新的虚拟内存页(通常以 2MB 的大内存页或 64KB 的对齐粒度进行保留和提交),这些新申请的区域在物理排列上往往是不连续的;

2.2 第二层:段级布局

现代段分配器(Segment Heap)将申请到的整块大内存划分为一个或多个 Segment(段) 。每个 Segment 内部的内存布局是非常标准且严格对齐的:

+-------------------------------------------------------------+

|  Segment Header  |  Commit Bitmap  |  ... Blocks/Pages ...  |
|    (段头元数据)   |   (内存提交位图) |    (实际数据分配区)     |
+-------------------------------------------------------------+
  • Segment Header(段头):位于该内存段的最低地址处,包含了这个段的元数据(如段的大小、所属的堆句柄、基础配置等);
  • Commit Bitmap(提交位图):紧随段头之后,用于跟踪该段内哪些虚拟内存页已经实际映射到了物理内存(Committed),哪些还只是占位符(Reserved);
  • 数据分配区:占据该段绝大部分空间的物理区域,根据申请的大小,这里会被划分给 VS 分配器LFH 分配器大块分配器

2.3 第三层:分配器级布局

这是安全研究和漏洞利用中最核心的层面。数据分配区内部的物理对齐和排列取决于内存块的大小:

2.3.1 VS(Variable Size)中块分配器布局

主要用于管理大约 16KB 到 508KB 之间的动态内存。其物理布局表现为连续的、大小可变的块:

低地址 ──────────────────────────────────────────────────────────> 高地址
+------------------+------------------+------------------+

| VS Chunk Header  | VS Chunk Header  | VS Chunk Header  |
| + 实际用户数据A   | + 实际用户数据B   | + 空闲/未分配块C  |
+------------------+------------------+------------------+
  • 物理相邻:块 A、块 B 和块 C 在内存中是紧密首尾相连的;
  • 堆溢出的物理轨迹:当数据 A 发生溢出时,数据会顺着高地址方向流出,首先破坏的就是“块 B 的 VS Chunk Header”

2.3.2 LFH小块分配器布局

主要用于管理小于 16KB 的动态内存。LFH 在段内部开辟了多个“桶”(Bins/Buckets),每个桶内部的布局高度碎片化和随机化:

LFH 某一个特定的桶(例如 64 字节桶):

LFH 某一个特定的桶(例如 64 字节桶):
+--------+--------+--------+--------+--------+--------+

| Slot 1 | Slot 2 | Slot 3 | Slot 4 | Slot 5 | Slot 6 |
| (空闲) | (用户A) | (空闲) | (用户B) | (空闲) | (空闲)  |
+--------+--------+--------+--------+--------+--------+
  • Slot(槽位)对齐:一个桶内的所有槽位大小完全相同且物理相邻;
  • 无确定性相邻:虽然 Slot 1 到 Slot 6 物理相邻,但由于现代 LFH 引入了槽位随机化(Slot Randomization),当程序连续申请两个 64 字节的对象时,它们可能被随机放到了 Slot 2 和 Slot 5,中间隔着空闲空间。这使得传统的堆溢出很难精准覆盖到特定目标;

2.4 第四层:微观微块级布局

当我们把视距放大到单个 malloc 返回的指针时,现代 Windows 堆块的微观结构如下:

2.4.1 VS 块(Chunk)的微观结构

+------------------------------------+-----------------------+

|          VS Chunk Header           |       User Data       |
|              (8 或 16 字节)         |     (分配给用户的内存)  |
+------------------------------------+-----------------------+
▲                                    ▲
│                                    └─ malloc / HeapAlloc 返回的指针
└── 堆管理器内部管理的起始地址

Header 加密VS Chunk Header 中包含了当前块大小(Size)和前一个块的大小。这些数据在内存中是以 XOR 异或加密 状态存在的,随时面临堆管理器的完整性校验;

2.4.2 LFH 块(Slot)的微观结构

现代 LFH 为了追求极致的性能和防溢出效果,极大地简化了 Slot 内部的结构:

  • 去 Header 化:在现代 LFH 中,处于“已分配”状态的 Slot 内部几乎没有传统的堆头元数据。它的分配状态、大小等信息全部被剥离出来,集中存放在前面提到的段头(Segment Header)或专门的 Subsegment 管理结构中;
  • 安全意义:这种“数据与元数据分离”的布局,使得攻击者即使在 LFH 块中触发了严重的堆溢出,也只能淹没相邻槽位的用户数据,而无法触及任何能引发底层崩溃或 DWORD SHOOT 的堆管理器核心指针;

3. Windows系统堆溢出原理

Windows 堆溢出(Heap Overflow)是指程序在动态内存堆区(Heap)分配一块缓冲区后,向其中写入的数据量超过了该缓冲区申请的实际容量,导致数据跨越内存边界,覆盖了相邻高地址堆块(Chunk/Slot)中的结构或数据。简单来说,堆溢出的根本原因在于缺失严格的内存写入边界检查

3.1 堆的内存布局与溢出物理图景

在 Windows 中,无论是用户态堆(NT Heap / Segment Heap)还是内核态池(Pool),内存都是以“块”(Chunk / Slot)为单位连续或分页管理的。

典型的堆块内存结构通常包含两部分:

  • 元数据(Metadata/Header):记录堆块的大小、分配状态(Free/Allocated)、校验码、链表指针等管理信息;
  • 用户数据(User Data/Payload):返回给应用程序使用的实际缓冲区;
内存低地址                                                               内存高地址
+------------------------------------+------------------------------------+
|              堆块 A (Chunk A)             |             堆块 B (Chunk B) |
+------------------+-----------------+------------------+-----------------+
| 堆头 (Header)  |  用户数据 (Data)  |  堆头 (Header) | 用户数据 (Data) |
+------------------+-----------------+------------------+-----------------+
                       |<- 预期写入范围 ->|
                       |=====================> [ 发生溢出 ! ]
                       |             |覆盖 Chunk B 堆头 |覆盖 Chunk B 数据|

当向 Chunk A 的 Payload 写入超长数据时,溢出数据会按地址递增方向依次压写:

  • Chunk A 的末尾;
  • Chunk B 的 Header(包含堆管理信息);
  • Chunk B 的 User Data(包含邻近应用程序的对象指针、状态变量等);

3.2 堆溢出的原理演化:从元数据到应用数据

根据破坏目标的不同,Windows 堆溢出的破坏与利用原理分为两个发展阶段:

3.2.1 阶段一:传统堆溢出 —— 破坏堆元数据

在早期的 NT Heap(Windows XP / 2003 时代)中,堆管理者直接在 Chunk 头部存储链表指针,攻击者通过覆盖 Chunk Header 来攻击堆管理器本身。

当一个空闲堆块被重新分配或合并时,堆管理器需要将其从空闲链表(FreeList)中摘除,执行解链操作:

// 传统的 Unlink 解链逻辑
Node->Flink->Blink = Node->Blink;
Node->Blink->Flink = Node->Flink;

如果攻击者通过堆溢出伪造了 Node Flink(前驱指针)和 Blink(后继指针):

  • Flink 覆盖为 目标地址 – Offset
  • Blink 覆盖为 恶意数据 / Shellcode 地址

当系统执行 Unlink 时,就会强制将“恶意数据”写入到“目标地址”,构造出 任意地址写(Arbitrary Write / DWORD SHOOT) 任意写原语,进而覆写函数指针(如 PEB->ProcessHeap 或 SEH 链)劫持控制流。

为什么该原理失效?

微软后续引入了多项防护,导致元数据破坏直接引发系统崩溃(0xC0000374):

  • Safe Unlinking:解链前校验 Node->Flink->Blink == Node
  • Heap Cookie / XOR Encoding:堆头关键信息经过随机 Key 加密,覆写后解密失败直接崩溃;
  • LFH (Low Fragmentation Heap):去除了内联 Chunk Header,采用外部 Bitmap 管理空闲槽位;

3.2.2 阶段二:现代堆溢出 —— 破坏应用数据

在 Windows 10/11 及 Segment Heap 时代,攻击者放弃篡改堆头,转而通过堆布局(Heap Grooming)让目标受害对象紧随溢出对象之后,仅覆盖受害对象的 Payload核心机制为对象属性与指针覆写:

+------------------------------------+------------------------------------+
|      漏洞对象 (Vulnerable Obj)     |       受害对象 (Victim Obj)        |
+-------------------+----------------+------------------+-----------------+
| Header (不破坏)   | Buffer (溢出) | Header (不破坏)   | [关键字段]      |
+-------------------+----------------+------------------+-----------------+
                                     |                  |
                                     v                  v
                             [覆盖长度/容量]     [覆盖数据/函数指针]
  • 改写长度/容量字段(OOB Read/Write)
    • 覆盖 std::vector capacityArrayBuffer byteLength PIPE_ATTRIBUTE AttributeValueSize
    • 结果:原本合法长度为 0x20 的对象被扩充为 0xFFFF,获得越界读写(Out-Of-Bounds)能力,用来读取内核/内存敏感数据突破 ASLR/KASLR;
  • 改写指针字段(Pointer Overwrite)
    • 覆盖对象中的数据指针(如 AttributeValue),使其指向任意内核/用户态内存,再调用读取或写入接口,转化为稳定任意地址读写
    • 覆盖 C++ 对象的虚表指针(vftable)或函数回调指针,在对象方法被调用时结合 CFG 绕过劫持 EIP/RIP;

4. 现代Windows堆溢出主流利用技术

目前,高水平安全研究员和红队在进行 Windows 堆溢出利用时,核心思想是“不破坏堆管理结构,只破坏应用层业务数据(Data-Only Attack)”,并结合内核或特定用户态对象的特性来构建任意内存读写原语(Arbitrary Read/Write Primitive)

4.1 堆风水与内存布局重组

为了绕过 LFH 的分配随机化并保证溢出块后方紧跟目标对象,利用过程极度依赖精准的堆布局控制:

  • 碎片清理(De-fragmentation):大量申请特定大小的内存块,将堆中的空闲碎片填充完毕;
  • 占位与打洞(Holes & Slot Filling):连续申请一批同等大小的对象,释放其中的间隔对象(制造 Hole),然后分配漏洞对象与目标受害对象,使其落入预期的邻近槽位中;

4.2 构建任意读写原语

现代防御机制(如 DEP、ASLR、CFG、CET等)使得直接跳转到 Shellcode 变得极其困难。攻击者不再试图修改堆头部,而是精确覆写紧邻对象的关键数据字段:

  • 长度/界限字段覆盖(Length/Size Overwrite):在堆上精心布局(通过堆风水),让易受攻击的堆块 A 紧邻目标堆块 B:
    • 触发 A 的堆溢出,覆盖紧邻的字符串对象(如 BSTRstd::wstring)的长度前缀,使其超长;
    • 触发 A 的堆溢出,覆盖动态数组(如 std::vectorJSArrayArrayBuffer)的 capacityelement countLength字段;
  • 泄露与基址获取:当程序随后读取或写入块 B 时,由于长度字段被篡改,程序会认为这个块很大,通过超长读取相邻对象的指针,允许攻击者读取或修改块 B 之后的大片内存,从而泄露模块基址(突破 ASLR)和堆对象真实地址,甚至修改其他关键结构;
  • 全内存读写:利用已控制的超长数组或指针修改,构造出可以在全内存空间进行读取和写入的稳定原语;

4.3 控制流劫持或纯数据攻击

在获取读写原语后,终极目标的实现方式取决于目标环境:

  • 控制流劫持:
    • 虚表指针(vftable)篡改:改写 C++ 对象的 vftable 指针指向伪造的虚表;
    • 绕过 CFG/XFG
      • 非 CFG 保护点利用:寻找代码库中未启用 CFG 校验的函数指针或回调函数;
      • Stack Pivot(栈劫持):利用泄露的线程栈地址,借助 ROP 链篡改栈上的返回地址(Intel CET 未开启时);
      • JOP (Jump-Oriented Programming):寻找符合 CFG 导出白名单条件的 gadgets 拼接执行;
  • 纯数据攻击:在防护极严(如 CET + Safe Dispatch)的环境下,攻击者倾向于完全不修改控制流:
    • 权限凭证篡改:在内核态利用下,直接通过任意读写找到当前进程的 EPROCESS 结构,替换 Token 指针为 SYSTEM Token 实现提权;
    • 安全开关修改:篡改进程中的关键控制标志位(如沙箱状态位、安全检查开关、策略结构体);

4.4 用户态与内核态利用差异

为了实现上述原语,攻击者通常会寻找系统中现成的、结构稳定且易于控制的结构体来进行溢出覆盖:

  • 用户态堆利用:
    • 特定的 RPC 接口 / ALPC 缓冲区:Windows 内部大量的本地进程间通信(ALPC)会频繁在堆上分配结构体,这些结构体往往包含长度和数据指针,是本地提权(LPE)的热门目标;
    • 浏览器 / 脚本引擎(如 Edge/V8):在浏览器沙箱逃逸或远程代码执行(RCE)中,攻击者利用堆溢出覆盖 JavaScript 的 ArrayBuffer TypedArray 对象的内部指针和长度,从而在沙箱内实现极其稳定的任意内存读写;
  • 内核态利用:
    • WNF (Windows Notification Facility):WNF 是一个现代内核通信机制。攻击者通过堆溢出覆盖临近的 WNF 状态数据块(State Data),修改其大小和指针,可以将其转化为一个完美的内核任意读写原语
    • Palette 对象 / tagWND(经典但仍演进):通过溢出内核 GDI 对象(如 Palette 的 cEntries 字段),可以导致越界读写内核空间。尽管微软引入了类型隔离(Type Isolation)等机制进行限制,但针对特定内核结构体的布局技术仍在不断翻新;
    • 现代(Win10 2004 / Win11):引入 ExAllocatePool2 和内核段堆(Kernel Segment Heap)。利用重点转移为针对内核对象(如 Pipe AttributeWNF 状态块、ALPC 消息)的占位与数据覆写;

4.4 现代Windows(Win10/Win11)的高阶利用思路

当前的 Windows 10/11 拥有极高的防御维度,任何一个堆溢出利用链都必须解决以下防御:

[堆溢出漏洞] ──> 克服 [LFH 随机化] ──> 绕过 [ASLR/泄露基址] ──> 绕过 [CFG/控制流防护] ──> 达成利用

一个现代 Windows 堆溢出漏洞的完整攻击闭环通常如下:

[堆布局 / 堆喷射] ──> 调整内存,使漏洞块与受害块物理相邻
       │
[触发堆溢出]     ──> 精确压写受害对象的 length / pointer 字段
       │
[构造 R/W 原语]  ──> 利用受害对象实现全内存空间的任意读与任意写
       │
[绕过安全防护]   ──> 读取模块地址绕过 ASLR/KASLR,绕过 DEP/CFG/CET
       │
[最终劫持]       ──> 篡改 Token (内核态) / 构造 ROP/JOP 链 (用户态)

5. 常见引发堆溢出的代码模式(脆弱性根源)

堆溢出漏洞通常源于 C/C++ 语言内存管理中的典型逻辑错误:

5.1 无边界检查的内存拷贝

使用 strcpystrcatmemcpy 时,拷贝长度由源数据决定而非目标缓冲区大小:

char *heap_buf = (char *)HeapAlloc(GetProcessHeap(), 0, 0x20);
// 如果 user_input 长度大于0x20,触发堆溢出
strcpy(heap_buf, user_input);

5.2 整数溢出导致堆申请过小

计算分配内存大小时发生整数溢出,导致实际分配的堆空间极小,但随后拷贝了大量数据:

DWORD total_size = count * sizeof(ELEMENT); // 若 count 极大,算术溢出变为很小的数
char *heap_buf = (char *)HeapAlloc(GetProcessHeap(), 0, total_size); // 申请了小内存
for (int i = 0; i < count; i++) {
    heap_buf[i] = ...; // 写入大量数据,造成严重堆溢出
}

5.3 经典Off-By-One

由于边界判断条件错误(如将<误写为 <=),导致多写入了一个字节(如 \0 字节)。即使只多写一个字节,也足以覆写相邻堆块 Header 的标识位或相邻对象的长度低位。

免责声明:

1. 一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。

3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
觉得有帮助可以赞赏本文哦~万分感谢!
文章:现代Windows系统堆溢出利用
作者:沛旗
链接:https://www.peiqiblog.com/article/13587/
版权声明::本博客站点所有文章除特别声明外,均采用 CC BY-NC-SA 4.0协议
转载请注明文章地址及作者哦~
暂无评论

发送评论(禁止发表一切违反法律法规的敏感言论) 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇