windows消息机制详解

字数统计: 2.3k字   |   阅读时长≈ 8分

windows是一个消息驱动的系统，windows的消息提供了应用程序之间、应用程序与windows 系统之间进行通信的手段。要想深入理解windows，消息机制的知识是必不可少的。

0x00 前言

windows是一个消息驱动的系统，windows的消息提供了应用程序之间、应用程序与windows 系统之间进行通信的手段。要想深入理解windows，消息机制的知识是必不可少的。

0x01 基础

进程接收来自于鼠标、键盘等其他消息都是通过消息队列进行传输的

image-20220330142934499.png

常规模式下，有一个专用的进程来接收这些消息，然后再插入某个进程的消息队列，但是这样的话会涉及到频繁的进程间的通信，效率很差

image-20220330143018662.png

windows为了解决这一问题，因为高2G的内核空间每个进程都是共用的，所以微软想到把消息的接收放到了0环，使用GUI线程

<1> 当线程刚创建的时候，都是普通线程，指向的是SSDT表

Thread.ServiceTable-> KeServiceDescriptorTable

<2> 当线程第一次调用Win32k.sys时，会调用一个函数：PsConvertToGuiThread，我们知道在3环进0环的过程中会取得一个调用号，当调用号在100以下的时候，在ntosknl.exe里面，当调用号大于100则是图形处理函数，调用Win32k.sys

如果是一个GUI线程，win32Thread指向的就是THREADINFO结构，如果是普通线程，这里就是一个空指针

主要做几件事：

a. 扩充内核栈，必须换成64KB的大内核栈，因为普通内核栈只有12KB大小。

b.创建一个包含消息队列的结构体，并挂到KTHREAD上。对应的就是MessageQueue属性

c.Thread.ServiceTable-> KeServiceDescriptorTableShadow，把Thread.ServiceTable指向SSDTShadow表，这个表既包含了SSDT表里面的函数，又包含了win32k.sys里面的图形函数

d.把需要的内存数据映射到本进程空间

总结：

<1> 消息队列存储在0环,通过KTHREAD.Win32Thread可以找到

<2> 并不是所有线程都要消息队列，只有GUI线程才有消息队列

<3> 一个GUI线程对应1个消息队列

0x02 窗口与线程

image-20220330151435668.png

我们知道创建windows窗口使用的是CreateWindow，而这个函数底层调用的是CreateWindowExA和CreateWindowExW，我们逆向分析一下CreateWindowExW

image-20220330152859474.png

首先调用CreateWindowEx

image-20220330152911168.png

然后调用VerNtUserCreateWindowEx

image-20220330152922981.png

再调用NtUserCreateWindowEx

image-20220330152935780.png

通过NtUserCreateWindowEx进入0环

image-20220330152945944.png

windows窗口都在0环有一个结构体，就是WINDOW_OBJECT，pti即窗口对象指向的线程。一个线程可以对应多个窗口，但是在同一个程序里面多个窗口只能对应一个线程

总结

1、窗口是在0环创建的

2、窗口句柄是全局的

3、一个线程可以用多个窗口，但每个窗口只能属于一个线程

一个GUI线程只有一个消息队列，一个线程可以有很多个窗口，一个线程中所有的窗口共享同一个消息队列

消息的接收

image-20220330181051283.png

首先在3环创建窗口和窗口类的对象，对应0环的_WINDOW_OBJECT结构

image-20220330182843878.png

消息队列的结构

<1> SentMessagesListHead//接到SendMessage发来的消息
<2> PostedMessagesListHead  //接到PostMessage发来的消息
<3> HardwareMessagesListHead//接到鼠标、键盘的消息

如果要取所有队列的消息，则第二个参数设置为NULL，后两个参数全部设置为0

GetMessage的主要功能：循环判断是否有该窗口的消息，如果有，将消息存储到MSG指定的结构，并将消息从列表中删除。

GetMessage( LPMSG lpMsg,//返回从队列中摘下来的消息
HWND hWnd,  //过滤条件一：发个这个窗口的消息
UNIT wMsgFilterMin, //过滤条件
UNIT wMsgFilterMax  //过滤条件
);

使用GetMessage()获取信息，另外一个程序利用SendMessage发送给窗口，这里GetMessage会接收到消息并直接处理

image-20220330204403037.png

image-20220330204429829.png

NtUserGetMessage

User32!GetMessage 调用 w32k!NtUserGetMessage

do
{
//先判断SentMessagesListHead是否有消息 如果有处理掉
do
{
....
KeUserModeCallback(USER32_CALLBACK_WINDOWPROC,
   Arguments,
   ArgumentLength,
   &ResultPointer,
   &ResultLength);
....
}while(SentMessagesListHead != NULL)
//以此判断其他的6个队列，里面如果有消息 返回  没有继续
}while(其他队列!=NULL)

SendMessage/PostMessage

SendMessage为同步，PostMessage为异步，GetMessage只处理第一个链表即SentMessagesListHead里面的消息

当一个程序利用SendMessage向另外一个程序发送消息时，另外一个程序会用GetMessage接收，这个过程GetMessage会在0环的SentMessagesListHead链表里面搜索是否存在SendMessage，如果存在SendMessage，GetMessage就会在两个程序的共享内存里面向发送消息的程序发送一个结果，在这个过程中，发送消息的程序是一直处于等待状态的，只有接收到返回的消息才会结束，这称为同步

image-20220330204458740.png

image-20220330204508959.png

如果利用PostMessage发送消息，处于第二个链表里面，GetMessage不会处理，而程序发完消息之后也会立即结束，不会有等待的过程，这成为异步，如果要处理，使用DispatchMessage()处理

MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

image-20220330204559571.png

image-20220330204605162.png

0x03 消息的分发

这里如果只有GetMessage的话，关闭窗口是关闭不了的

image-20220330204948712.png

DispatchMessage

User32!DispatchMessage 调用 w32k!NtUserDispatchMessage

<1> 根据窗口句柄找到窗口对象

<2> 根据窗口对象得到窗口过程函数，由0环发起调用

如果使用DispatchMessage分发消息，根据窗口句柄调用相关的窗口过程，即可关闭

因为很多个消息共用一个消息队列，所以通过GetMessage取出消息之后，需要用DispatchMessage进行消息的分发

DispatchMessage通过GetMessage取出的句柄，进入0环找到Window_Object对象，再找到对应的窗口过程调用

image-20220330205024274.png

TranslateMessage是用来处理键盘输出的函数，定义一个函数

case WM_CHAR:
{
sprintf(szBuffer, "Down : %c", wParam);
MessageBox(hwnd, szBuffer, "", 0);
return 0;
}

image-20220330210532824.png

这里如果不使用TranslateMessage，则没有WM_CHAR这个消息，需要自己定义WM_KEYDOWN

case WM_KEYDOWN:
{
sprintf(szBuffer, "Down : %d", wParam);
MessageBox(hwnd, szBuffer, "", 0);
return 0;
}

image-20220330211319530.png

image-20220330211224396.png

消息有很多，但是不是每个消息都需要我们自己去处理，所以与我们无关的消息就使用windows提供的DefWindowProc让微软替我们处理即可

image-20220330211726951.png

0x04 内核回调机制

窗口过程函数除了GetMessage和DispatchMessage能够调用，一些在0环的函数也能够直接进行调用。例如CreateWindow不向消息队列里面发送消息，而是直接调用3环提供的函数

这些消息类型可以被直接调用

image-20220330212919027.png

这里对WM_CREATE进行修改，当创建成功的时候弹窗

image-20220330213223172.png

这里并没有执行到GetMessage和TranslateMessage就弹窗，说明被CreateWindow调用0环函数，0环函数通过回调机制(KeUserModeCallBack)，再调用窗口过程函数

image-20220330213206308.png

所以调用窗口过程只能是以下三种情况

<1> GetMessage()在处理SentMessagesListHead中消息时
<2> DispatchMessage()在处理其他队列中的消息时
<3> 内核代码

1、从0环调用3环函数的几种方式：

APC、异常、内核回调

2、凡是有窗口的程序就有可能0环直接调用3环的程序。回调机制中0环调用3环的的代码是函数：KeUserModeCallback

3、回到3环的落脚点：

APC：ntdll!KiUserApcDispatcher

异常：ntdll!KiUserExceptionDispatcher

KeUserModeCallback

KeUserModeCallback在0环对应NtUserDispatchMessage，调用IntDispatchMessage。通过UserGetWindowObject获得一个Window_Object类型，通过对象得到当前窗口的对应的窗口函数，然后调用co_IntCallWindowProc

NTSTATUS KeUserModeCallback(
INULONGApiNumber,
INPVOIDInputBuffer,
INULONGInputLength,
OUTPVOID*OutputBuffer,
INPULONGOutputLength`
);

调用KeUserModeCallback，第一个值为索引，第二个值为窗口回调过程中所有有用的信息。第一个索引值， KeUserModeCallback函数的第一个参数就是索引，其实它是一个宏，有很多个对应的值

内核回调在3环的落脚点，有很多个地方，我们拿着索引去3环里面找回调函数地址表，如果索引为0，则取表里面的第一个函数，如果索引为1，则取表里面的第二个函数

PEB+0x2C 回调函数地址表，由user32.dll提供

KeUserModeCallback的调用过程如下

nt!KeUserModeCallback->nt!KiCallUserMode->nt!KiServiceExit->ntdll!KiUserCallbackDispatcher->回调函数->int2B->nt!KiCallbackReturn->nt!KeUserModeCallback(调用后)

在堆栈准备完毕后，调用KiServiceExit回到3环，它的着陆点是KiUserCallbackDispatcher，然后KiUserCallbackDispatcher从PEB中取出KernelCallbackTable的基址，再以ApiIndex作为索引在这个表中查找对应的回调函数并调用，调用完之后再int2B触发nt!KiCallbackReturn再次进入内核，修正堆栈后跳回KeUserModeCallback，完成调用。

这里打开一个exe，通过fs:[0]找到TEB

image-20220330215539012.png

TEB的0x30偏移为PEB

image-20220330215551359.png

PEB的0x2C偏移即为回调地址函数表

image-20220330215604629.png

这里通过KeUserModeCallback的第一个值，即索引找到函数之后，这个函数再去调用窗口过程函数，窗口过程函数已经通过Arguments放在了堆栈里面

image-20220330215640190.png


赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

俗话说“好记性不如烂笔头”，各个安全社区各自为战，当我们想要搜索某一方面的文章的时候总是得在各个平台之间来回横跳，于是乎，一个平台文章聚合搜索的想法诞生了。
然后正好我想有一个自己的博客，于是乎两者融合在了一起。
下面简单介绍各个导航的区别：
个人文章：本人的笔记、复现、总结等或者本人参与的共同创作。
收集文章：手工从公众号收集保存的文章，更新频率看本人喜好所以比较慢。
聚合文章：从各大平台收集整理，由工具实现，每天更新。
很惭愧，只做了一点微小的工作。