一 、基于产生原因

1.1 Callback机制

Win32k组件最初的内核设计和编写是完全建立的用户层上的，但是提权微软在 Windows NT 4.0 的改变中将 Win32k.sys 作为改变的一部分而引入 ，用以提升图形绘制性能并减少 Windows 应用程序的漏洞内存需求。窗口管理器（User）和图形设备接口（GDI）在极大程度上被移出客户端/服务端运行时子系统（CSRSS）并被落实在它自身的防对一个内核模块中。

wKg0C2Q1UZKAI9jFAAA8HhChBCU732.png

这样的基于设计无疑是为内核增添了一部分压力 ，服务器租用win32k.sys需要处理大量的内核用户层回调 ，在这之后国外安全研究人员Tarjei Mandt公开了他对Win32k User-Mode Callback机制的提权研究成果
，从此User-Mode Callback的漏洞攻击面得到广泛关注，UAF的防对漏洞也不断的涌现 。

下图代码为一个经典UAF漏洞，基于用户层执行的内核某个函数通过syscall传入到内核层 ，当内核代码执行到xxxSomeCallback这一句时 ，提权用户层可以在用户定义的漏洞callback函数中获得代码执行的机会 ，香港云服务器如果用户在callback函数调用了DestroyWindow函数销毁窗口p，防对内核层的相应销毁代码将会被执行 ，p的相应内存被释放，回调执行完毕 ，NtUserSysCall函数继续执行 ，当执行到xxxSetWindowStyle(p)一句时 ，由于p的内存已经被释放从而导致UAF漏洞的产生。

wKg0C2Q1UdGAG1l0AAB8AXXrrIM630.png

1.2 GDI对象

在TypeIsolation机制的引入之前 ，windows内核中以bitmap为代表的GDI对象成为内核漏洞利用时的首选，免费模板对于WWW漏洞来说，GDI对象就是它的“左膀右臂”，借助GDI对象可以很容易构造出稳定内核内存的任意地址读写原语 ，以此来绕过Windows的安全机制（KALSR、SMEP等）。

二
、利用框架

漏洞成功利用漏洞触发、漏洞利用这两大环节，而漏洞利用又有以下三个阶段 ，分别是堆喷射阶段、信息泄露阶段 、源码下载代码执行阶段。下面将结合CVE-2019-0808、CVE-2021-1732进行详细阐述。

2.1 漏洞触发

漏洞的类型虽然五花八门，但基于win32k的内核漏洞是存在者一些共性的，也就是它的用户层回调 ，近年来所爆出的win32k的漏洞，其触发点大多都在用户层回调被hook。源码库下面将通过两个案例来进行介绍。

在CVE-2021-1732中 ，攻击者正是hook xxxClientAllocWindowClassExtraBytes的用户层回调函数
，强行改变窗口对象tagWND的扩展数据的保存位置以及寻址方式 ，从而触发一个任意地址覆盖写漏洞。

wKg0C2Q1UrqAce6UAACLexflaGQ178.png

针对这种触发方式，我们可以直接对用户层的usertable进行检测，usertable存在于PEB+0x58偏移处:

CVE-2021-40449 是Win32k 的 NtGdiResetDC 函数中的一个释放后使用漏洞 ，建站模板在执行其自己的回调期间针对同一句柄第二次执行函数 ResetDC 时触发UAF漏洞。

wKg0C2Q1UuOAZdTrAACPaTgCZog116.png

针对这种触发方式 ，可以通过开启Driver Virifier进行检测，UAF的漏洞再此环境下会触发蓝屏。

2.2 漏洞利用

漏洞成功被触发仅仅是一个好的开端，更重要的是漏洞利用点的寻找过程
。笔者将此过程大致划分为信息泄露 、堆喷射 、原语构造、代码执行这四个阶段。

在win32k漏洞利用过程中 ，内核对象的泄漏是至关重要的。可以说成功利用一个漏洞的大前提就是获取win32k内核对象的地址。

wKg0C2Q1U3aAYy0iAAEH1E9EANQ917.png

上图是对Windows内核地址泄漏的总结（来自GitHub），表格中包含截止目前泄漏内核对象的各种技巧。下面也是拿两个demo来阐述内核对象泄露的细节 ：

在R3通过CreateBitmap创建位图成功后会得到一个hBitmap,如果要在R3去泄露该对象在内核中的地址可以通过GdiSharedHandleTable获取。GdiSharedHandleTable位于PEB+0x94的位置。

wKg0C2Q1U5CAaWhkAAAepg2jbsk966.png

GdiSharedHandleTable的本质是一个指向GDICELL结构体数组的指针 。

wKg0C2Q1U6KAT7J1AAA0SxX9GE617.png

同 CreateFile 类似 ，其实Windows 都用句柄（Handle）来标识用户态对内核对象的引用 。这个句柄低 16 位其实是数组索引。

wKg0C2Q1VAWAfZUXAAANNlwfltw725.png

通过上文，就可以计算出bitmap在内核中的地址。

wKg0C2Q1VBGAQck3AAAUsLBZxA641.png

HMValidateHandle是微软未公开的一个函数
，凭借此函数可以通过传入句柄获取对于内核对象的地址（win32k对象）。HMAllocObject创建了桌面堆类型句柄后 ，会把tagWND对象放入到内核模式到用户模式内存映射地址里
。 为了验证句柄的有效性，窗口管理器会调用User32!HMValidateHandle函数读取这个表。函数将句柄和句柄类型作为参数 ，并在句柄表中查找对应的项 。如果查找到对象, 会返回tagWND只读映射的对象指针，通过tagWND这个对象我们可以获取到句柄等一系列窗口信息
。

该函数地址是通过R3的user32.dll!IsMenu函数获取到的 。

wKg0C2Q1VDaAOEifAABK7i13EFg646.png

具体获取方式如下：

wKg0C2Q1VEOAQ8crAADZGjJrmGw662.png

堆（池）喷射是进行内存布局的常用手段, 通过在分配关键的内核对象之前，首先分配和释放特定长度和数量的其他对象，使内核内存首先处于一个确定的状态，来确保在分配关键的内核对象时 ，能够被系统内存管模块分配到我们所希望其分配到的某些位置，例如接近某些可控对象的位置。攻击者可利用此种方法构造完美的内存布局从而达到自己的目的。此技术没有固定的方法（“因地制宜”），但是所要达成的目的比较一致--执行shellcode以及信息泄露
。

案例1：

Bitmap对象的地址在RS1中是通过AcceleratorTable获取到的。先申请大量的AcceleratorTable对象然后释放其中一个，接着申请大小相等的bitmap对象。通过泄漏AcceleratorTable对象的地址，即可等到bitmap的内核地址 。（内存大小计算方式将在下一章节进行详细阐述）

wKg0C2Q1VFiAatRuAABZb8ZW9wQ135.png

代码框架如下

wKg0C2Q1VGGAC6cqAACw29G8S0A729.png

在win32k内核漏洞利用中 ，RW原语同样扮演着重要角色。它可以对所分配的关键内核对象后面的内存区域进行操作，以控制原本不能控制的相邻对象的成员数据，这些数据将作为后续利用操作的重要节点。

下面将对win32k漏洞常用到的读写原语进行介绍：

wKg0C2Q1VJ2AUPU9AAE36tbfPzk258.png

此系列一直到RS3微软把Bitmap header与Bitmap data分离后
，彻底失效 。

wKg0C2Q1VNWAAeetAAB4GMR5X8A958.png

wKg0C2Q1VNqAACqeAACfThupnU170.png

应用场景1：

Wnd->StrName 字段是指向窗⼝标题名的指针，通过修改此变量 ，再借助⽤户态下 的 InternalGetWindowText 和 NtUserDefSetText 函数则可实现任意内核地址读写

wKg0C2Q1VPWAP7o8AABRuCzwQr0810.png

应用场景2：

a)申请两个连续的Wnd对象（Spray） ，Wnd0与Wnd1

b)通过漏洞能力将Wnd0的pExtraBytes字段变为可越界读写的。

c)通过Wnd0.的越界写入能力 ，修改tagWND1.pExtraBytes到指定地址

d)借助SetWindowLongPtr的修改能力 ，最后使Wnd1获得任意地址写入能力。

wKg0C2Q1VSeAbZPuAAAwYN3HNgQ077.png

wKg0C2Q1VTWATycRAACFCy5ktlM232.png

一般仅需tagMenuBarInfo.rcBar.left 和 tagMenuBarInfo.rcBar.top读取指定地址的8个字节的数据。

wKg0C2Q1VUCAPhNuAACdn1vLEPQ467.png

另外，通过GetMenuBarInfo构造Read Primitive时 ，需要提前构造Fake Menu（用户层） ，再通过SetWindowLongPtr对Target Wnd的Menu（内核层）进行替换
，以达到读取地址可控的目的。

wKg0C2Q1VUuAd8KAACqSW0mBns734.png

对于win32k内核漏洞 ，其最终利用方式就是本地提权，而提升权限的主要手法就是进行Token替换，共以下两种方式
：

wKg0C2Q1VWKASYr9AAA52Kc5NjM556.png

将当前进程 EPROCESS 中存储的 Token 指针替换为 System 进程的 Token 指针 。

wKg0C2Q1VW2AA6MzAACv5Wa8u5Q094.png

wKg0C2Q1VXKALdlUAAEJvY13O8519.png

将当前进程 EPROCESS 的成员 Token 指针指向的 Token 块中的数据替换成 System 进程拥有的 Token 块的数据

wKg0C2Q1VYSAWQaSAABAUD69sOQ973.png

将Present和Enabled的值更改为SYSTEM进程令牌的所有权限。

wKg0C2Q1VY2AK7OpAAA1U2FkTU378.png

三 、内核对象

3.1 Bitmap

GDI（Windows Graphics Device Interface），是windows为应用程序提供图形
、文字显示的 API 接口 。

Bitmap是GDI中的图形对象，用于创建 、操作（缩放 、滚动、旋转和绘制）并将图像作为文件存储在磁盘上 ，其实际上为一个二元数组 ，去存储像素 、颜色、大小等信息。

SURFACE对象（Bitmap在内核中的结构）

wKg0C2Q1VcKAYJpSAAAsz7rKY4c312.png

BaseObject
，内核 GDI 对象类的基类都是一个称作 _BASEOBJECT 的结构。对内核对象进行标记 ，用于描述最基础的对象信息

wKg0C2Q1VdCASXVAAAlRzvaNM671.png

SURFOBJ（Bitmap核心结构），用于控制位图的大小 ，像素等信息。

wKg0C2Q1VdABlnSAABTSUqvvrg712.png

wKg0C2Q1VgCAbkXoAAApoINYtcc373.png

创建具有指定宽度，高度和颜色格式（颜色平面和位每像素）的位图，而前文中也提过bitmap在内核中关联的对象SURACE,由SURACE通过CreateBitamp的前4个参数去精确控制分配的内核内存块的大小。其调用链如下
：

wKg0C2Q1VhSAUxAQAAB75owvyTw709.png

在GreCreateBitmap函数中  ，首先根据传入的 cPlanes 和 cBitsPerPel参数确定位图的像素位类型，然后创建一个DEVBITMAPINFO对象  ，通过CreateBitmap前四个参数去内存块中申请一片内存并且设置位图数据扫描线的长度。接着lpBits如果不为0，则通过GreSetBitmapBits去设置像素数据。

wKg0C2Q1Vh6AEDA3AABVoGSJSBo274.png

DEVBITMAPINFO的结构：

wKg0C2Q1VieADLBBAABGYsmlzbI562.png

在 Windows 内核中处理位图像素数据时，通常是以一行作为单位进行的，像素的一行被称为扫描线，而扫描线的长度就表示的是在位图数据中向下移动一行所需的字节数
。

位图数据扫描线的长度被存储在SURFACE+0x34 字节偏移的成员（即 SURFACE->so.lDelta 成员）中 。这样一来，成员 pvScan0 将指向当前位图 SURFACE 对象的像素点数据缓冲区的起始位置。在后续对位图像素点进行读写访问时 ，系统位图解析模块将以该对象的 pvScan0 成员存储的地址作为像素点数据区域起始地址 。

wKg0C2Q1VkiADXVeAABsg3IFe0151.png

3.2 Palette

调色板是一个数组，其中包含标识当前可以在输出设备上显示或绘制的颜色的颜色值。调色板由能够生成多种颜色但在任何给定时间只能显示或绘制这些颜色的子集的设备使用 。

PALETTE对象

wKg0C2Q1VuCAO8nAAE5zXPcDuQ249.png

PALETTE结构中  ，有三个成员是值得我们关注的分别是cEntries、pFirstColor、apalColors。cEntries指定当前调色板的项数，pFirstColor指向调色板列表起始表项（apalColors）的地址，apalColors是一个结构体数组存储调色板列表数据。

PALETTEENTRY （调色板列表）

结构体 PALETTEENTRY 大小为 4 字节 ，其各个成员用于定义调色板表项对应的 24 位 RGB 颜色值等信息

wKg0C2Q1Vu6AZ8bAAApmXRjvG0967.png

wKg0C2Q1Vx2AOGL7AAAZ8CsH2YM553.png

Createpalette函数用来创建调色板对象，其只有一个参数lplgpl是指向LOFGPALETTE类型结构体对象的指针 。定义如下：

wKg0C2Q1V4SACU02AABEui0D474872.png

这里我们仅需要关注第二个和第三个参数 
，palPalEntry是可变长度的 PALETTEENTRY 结构体类型数组，而palNumEntries来决定PALETTEENTRY 的个数。也就是说palette对象的大小是由palNumEntries控制的。

wKg0C2Q1V4ABNCAAAD39Rl4gy4172.png

显然
，我们可以得出palette对象大小的计算方式：4 * cEntries + 0x90/PALETTE/

3.3Wnd

Windows是对象，它们同时具有代码和数据，但它们不是C++ 类。 相反
，程序通过使用名为句柄 的值来引用窗口 。句柄是不透明类型。实质上它只是操作系统用来标识对象的数字 。可以想象Windows创建的所有窗口都有一个大表 。它使用此表按其句柄查找窗口。 (它内部的工作方式是否完全相同都很重要。) 窗口句柄的数据类型是 HWND， 这通常发音为"aitch-wind" 。 窗口句柄由创建窗口的函数返回 ：CreateWindow 和CreateWindowEx。

这里只介绍tagWnd常用的字段,分别是tagwnd.cbwndextra和tagWND.ExtraBytes。当使用CreateWindowEx创建窗口时，可以在注册窗口类时通过WNDCLASSEXA结构体中的cbWndExtra字段直接在内存中的tagWND对象之后请求额外的内存字节。

wKg0C2Q1ViAJvcjAAC9fUTdNWI133.png

CreateWindowEx是用来创建窗口  ，在漏洞利用的世界中 ，Wnd地位是非常高的
，可被用来进行堆spray，越界写的容器等等。此次我们仅介绍Wnd的pExtraByte字段 ，分析它在内核中生成的过程。

wKg0C2Q1WEKAMR2AACNvR70g8412.png

上图时CreateWindowEx到内核真正调用xxxCreateWindowEx函数的过程 ，xxxCreateWindowEx中回到tagWND的cbWndExtra字段进行判断。

wKg0C2Q1WEyAUfiMAABVSsYn8w305.png

如果cbWndExtra不为0，则将其作为参数传入xxxClientAllocWindowClassExtraBytes ，在xxxClientAllocWindowClassExtraBytes中通过KeUserModeCallback进入到R3 ，最后调用RtlAllocateHeap为其在用户层的桌面堆上申请一块内存。

wKg0C2Q1WF6AaVL0AABDDmtkyk581.png

对于SetWindowLongPtr函数 ，最重要的就是其对Wnd的修改能力，下图xxxSetWindowLongPtr函数的部分反汇编代码 ，可以看到当dwExtraFlag被设置为800后，可以直接对位于内核桌面堆的pExtraBytes+Index处的数据进行修改
。

wKg0C2Q1WHCALoOMAABs2i1UgSE515.png

xxxSetWindowData函数可以对Wnd的spMenu进行替换，这是我们能够利用Menu构造Read Primitive的先决条件 。

wKg0C2Q1WIaAJ1E1AABtmMOgRZA040.png

相邻的窗口中相差的只是一个tagWNDk结构体的大小

3.4Menu

菜单是为应用程序指定选项或选项组（子菜单）的项目列表
。单击菜单项打开子菜单或使应用程序执行命令。菜单管理也是win32k中最复杂得组件之一，其整体依赖多种十分复杂的函数和结构体。

tagMENU，

wKg0C2Q1WTOABfwBAADqVmnN14o150.png

tagPOPUPMENU ，

wKg0C2Q1WTyAWWZAADxjkmL5X8350.png

通过spMenu泄漏EPROCESS内核地址 ，用于寻找SYSTEM进程以及Token替换。

wKg0C2Q1WVeAdGtAABRE7Pewxc086.png

四 、攻防进化史

漏洞只有能够被成功利用 ，才可以体现出它的价值
。而对于win32k内核漏洞，最经典也是利用率最高的类型就是“任意地址任意写(WWW)”漏洞。本章节将围绕“ArbitraryOverwrite” ，对win32k提权利用方式的进化史以及微软相应的缓解措施进行详细阐述 。

4.1 Win7下的利用模式

个人认为Win7是Win32k内核漏洞利用最理想的环境 ，因其具有以下几点特征
：

综上，可以更加确认一个win32k内核漏洞在win7的利用率是极高的。

我们以“Bitmap”为例
，介绍内核提权漏洞在win7上的利用方式 ：

前提：Arbitrary Memory Write漏洞

wKg0C2Q1Wa6AOjwRAAAOHNIDfM234.png

wKg0C2Q1WbyAfWQ0AABWPadb8I609.png

操作第一个 hManager ，可以替换第二个 hWorker->pvScan0地址，再通过第二个 hWorker来将system进程的token写入当前进程 。

wKg0C2Q1WdWAP4PiAAEcglZL8Y656.png

4.2 RS1下的利用模式

GdiSharedHandleTable泄露bitmap的方式被缓解 ，GdiSharedHandleTable的pKernelAddress 指向一块无意义的地址 。

wKg0C2Q1WkSAW8wyAAGbgyaOwdY153.png

结合网上资料 ，Windows 中存在着 3 种类型的对象，分别为 User object
、GDI object 、Kernel object，一共有 40 多种对象。

wKg0C2Q1WmaAJkNLAACzMzaa3VU995.png

而bitmap属于GDI object其存在于换页会话池中，由于GDI object泄露地址方式在RS1版本中被缓解，因此我们需要从另外两种类型对象中去寻找替代方案。此次我们使用的是Accelerator table其属于User object并且也存在于分页会话池中。

wKg0C2Q1WnKAdfZAAAidc8gxcU837.png

Tips:非分页池的虚拟地址被物理地址分配,而分页池对应的虚拟地址和物理地址不存在一一映射
，只保证在当前执行会话有效，其余内核操作时，并不要求这些对象必须在内存中。

在user32.dll中有一个全局变量gSharedInfo，其成员aheList为一个USER_HANDLE_ENTRY的句柄表
。

wKg0C2Q1WoOACfYZAABH840fs30887.png

该句柄表的具体结构如下所示  ，其第一个成员为pKernel作用GdiSharedHandleTable 中的 pKernel 一致 ，均指向object在内核中的位置（KernelAddress）
。

wKg0C2Q1WoyAb2hWAAAOnVvZ8c916.png

因此可通过USER_HANDLE_ENTRY去泄露Accelerator table的内核对象地址。

KernelAddress= SHAREDINFO->USER_HANDLE_ENTRY->pKernel + handle&0xffff

函数 CreateAcceleratorTable 用来在内核中创建快捷键对应表 。

wKg0C2Q1Wp2ATnvAAAXHn4ybg394.png

该函数存在 LPACCEL lpaccl 和 int cAccel 两个参数。参数 lpaccl 作为指向 ACCEL 结构体类型数组的指针，cAccel 表示数组的元素个数。结构体 ACCEL (szie=6)的定义如下:

wKg0C2Q1WqeARsSAAAA5BM3aN0c314.png

通过1)、2)我们肯定可以想到通过内存分水技术去泄露bitmap内核对象的地址，经笔者分析得出可以控制CreateAcceleratorTable 的参数
 ，来控制其到内核所申请内存的大小
。

wKg0C2Q1WxKAGITMAABN5EuR2U269.png

现在，bitmap和AcceleratorTable内核对象的大小均可控，可以进行内存布局。过程如下：

wKg0C2Q1Wx2AOixGAACSUNu5bg788.png

至此，我们就可以成功泄露bitmap内核对象的地址啦！

wKg0C2Q1W0iAdWGnAACTFPUjts242.png

后续提权过程与win7一致。

4.3 RS2 下的利用模式

在RS2中pKernel指向异常地址
， AcceleratorTable + 池风水泄露pvScan0的方式失效

新的替代方案—桌面堆，更准确一点就在桌面堆上的lpszMenuName 。lpszMenuName就是我们创建窗口时wndclass的成员 ，同bitmap一样它也存于换页内存池 。

另外 ，我们还需知道桌面堆是有两份分别存于用户态和内核态
。

wKg0C2Q1W4SAfnL5AABHHHDvfzk145.png

上图 ，在网上流传的比较火，应该是国外某位大神逆出来，再此稍稍瞻仰一下。有了这个我们就可以通过桌面堆来泄露bitmap的内核地址啦 。

首先，我们要得到内核态桌面堆到用户态桌面堆的偏移值ulClientDelta 。

wKg0C2Q1W52ATszxAAB0SOVOLXg150.png

通过HMValidateHandle泄露Wnd的内核地址 ，然后通过用户态的tagCLS获取lpszMenuName（0x98）的地址 。

wKg0C2Q1W8OAL3mkAACdFHYmuE332.png

泄露结果如下所示：

wKg0C2Q1W86AKpsnAABZVdDesEE087.png

到这，相信大家都知道可以通过桌面堆对象进行占坑，并控制lpszMenuName的大小与bitmap大小一致 。即可成功泄露bitmap的内核地址 。lpszMenuName申请内存过程堆栈如下，其大小为实际申请大小 。

wKg0C2Q1WCAI0bvAAB69JVUyuc773.png

另外，BitMap的SurFace结构 在RS2上比RS1增大了10。

内存布局如下，申请等大小的lpszMenuName和bitmap
。利用UAF技术确保泄露lpszMenuName的地址稳定之后使用bitmap占坑 。

wKg0C2Q1WCALEPyAACLaCzLK00651.png

下图来自fuzzySecurity的blog,精确的展现出通过lpszMenuName进行UAF后泄露bitmap的过程。

wKg0C2Q1WAWHyrAADIeqoA8bM878.png

4.4 RS3 下的利用模式

微软引入了 TypeIsolation 功能将Bitmap header与Bitmap data分离 ，无法通过Bitmap header取得pvscan0指针的内核地址。

在第三章节介绍过另一个用于WWW漏洞利用的内核对象—Palette ，它和bitmap有着异曲同工之妙 ，palette对象的0x90处是一个4字节的数组apalColors，相当于BitMap里的pixel data，pFirstColor是一个指针
，指向apalColors，相当于BitMap里的pvScan0。

wKg0C2Q1XCaAB5nYAAATtJzGCek419.png

因此 ，我们完全可以按照在RS2中的利用思路 ，完成在RS3中的提权
。

wKg0C2Q1XLaAOI9AAAx7y9av8004.png

泄露的方法还是采用池分水技术，利用lpszMenuName为palette占坑。

Palette大小的计算方式：LOGPALETTE->palNumEntries进行控制的，具体如下
：

wKg0C2Q1XO6AR2yHAACUl66GW9A717.png

wKg0C2Q1XPyAWPaJAACkIwPXv2o616.png

wKg0C2Q1XReAP7maAADQpi2kHrQ470.png

4.5 攻防现状

RS4:

HMValidateHandle泄露内核方法失效

Palette同样被TypeIsolation进行header和body分离

RS5:

微软修改大量API，桌面堆泄露的方法被缓解 。

到这，已有的所有泄露GDI对象的方法均以被缓解 。但车到山前必有路 ，这也正体现了攻防对抗的魅力 ，直到2021年CVE-2021-1732的漏洞被爆出，不同于传统的内核漏洞，需借助“溢出”来完成漏洞利用
，该漏洞是由于窗口类型混淆而导致的 ，通过spMenu的信息泄漏能力和借助GetMenuBarInfo/SetWindowLong函数构造读写原语（RW Primitive），最后通过纯数据攻击（DataOnlyAttack，特点不需要执行原语，只操纵操作系统使用的数据结构以实现提权）实现内核提权
。

wKg0C2Q1XTAMRovAABXU0wGazI800.png

五、附录

5.1参考链接

https://www.anquanke.com/post/id/235716#h3-4

https://mp.weixi2n.qq.com/s/6mT0O9eur5-VEs0rbV0-mg

https://github.com/gdabah/win32k-bugs/

http://fuzzysecurity.com/tutorials/expDev/21.html

https://www.wangan.com/p/7fygf309c52e2678

5.2环境介绍

HEVD的一个Windows Kernel Exploition训练项目--HackSysExtremeVulnerableDriver

https://github.com/hacksysteam/HackSysExtremeVulnerableDriver

wKg0C2Q1XXiAPjCQAACoYoHRIJY361.png