内核提权最终都是通过读写来做一些事情所有内核提权都是获取一个system值 从而获得最高权限。

替换当前进程EPROCESS结构的token为system的token

替换当前进程EPROCESS结构体token所指向的数据

3环直接写shellcode是不行的因为当前 进程eprocess位于内核空间，要进行读写代码必须在0环中，如果在3环进行读写会出现保护异常。用户层可以通过调用系统服务来访问内核层代码。

win32k.sys组件中创建窗口站对象(CreateWindowStationW)时候，SetImeInfoEx函数没有对指针进行安全验证; 对应指针指向零页内存，然后在它下一次使用之前有代码对该区域进行修改触发蓝屏.

需要提权申请一块堆大小并且构造这块内存中的数据释放后指向shellcode位置，当提权完成后再恢复这块数据。

以2018-8120为例子进行傻瓜式分析开始啦，
前提需要进入当前进程所对应的内核空间

窗口站是和当前进程和会话(session)相关联的一个内核对象，它包含剪贴板(clipboard)、原子表、一个或多个桌面(desktop)对象。
用户调用CreateWindowStation创建新的窗口站时，最终会调用内核函数xxxCreateWindowStation执行窗口站的创建，但是在该函数执行期间，被创建的新窗口站实例的spklList指针并没有被初始化，指向的是空地址

1、HWINSTA hSta = CreateWindowStationW(0, 0, READ_CONTROL, 0);
hSta 句柄=58，对应在内核中窗口站地址是87a85d48

2、CreateBitmap getpvscsn0 下断点得到下边四个值
CreateBitmap创建的句柄是 gManger=1205067e

同理所得：gWorker=180504e7 mpv=fe667038,wpv=fdab8368

3、自己申请一块空间的地址
构造tagkl(目标键盘布局)对象的结构体指针piiex指向的输入法信息对象的缓冲区。

自己申请内存地址初始化002cf2b0 =0xccc

当触发漏洞时候：002cf2b0变成自己构造的数值了具体汇编这里不做过多的介绍了

下图书触发漏洞以及在申请的内存里面构造了自己需要的数据


验证自己找的gManger gWork等值是否正确

思路：SetBitmapBits --> NtGdiSetBitmapBits --> GreSetBitmapBits --> bDoGetSetBitmapBits--> memcpy
(1)setbitmap代码分析
SetBitmapBits((HBITMAP)gManger, sizeof(PVOID), &oaddr);

NtGdiSetBitmapBits(int a1, SIZE_T Size, PVOID Address)
2、bp win32k!NtGdiSetBitmapBits下断点进行分析
v6 = GreSetBitmapBits(a1, Size, Address, &v4);进行分析

3、bp win32k!bDoGetSetBitmapBits下断点进行分析
v9是算出来的计算公式如下

代码如下

v9计算过程gManager句柄的后3位，wpv+20位置


(1)由于漏洞中的memcpy大小不可控，所以回覆盖一部分的SURFOBJ成员，所以我们需要修复某些在Set/GetBitMapBits时所必须的成员
利用Bitmap内核对象中的pvScan0字段+10的位置系统API的GetBitmapBits和SetBitmapBits可以读写pvScan0所指向内存地址的内容
(2)因此这个v9计算公式俩种
4、拷贝

剩下的GetBitmapBits以及需要逆向的其他函数都是类似操作只要知道调用哪个函数就可以动态跟踪里面数据

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课