[接引言]

文本编辑器/文本编辑框是应用层常见的键盘处理程序。微软泄露的WinXP源码下有文本编辑器Notepad的实现：

(notepad源码结构)

实现一个文本编辑器并不复杂，微软又(被迫)提供了Sample，因此我就不重复造轮子了。本文从调试器的角度观察Notepad.exe如何消费(使用)键盘按键。

首先评估一下调试Notepad.exe的难易程度(虽然有源码，我还是装作没有)：Windows窗体程序，在我可以折腾的范围。

(查壳, 无壳且看着像是C++编译器生成)

(Spy++查看窗体，Notepad.exe属于标准的Windows窗口程序，如果遇到C#窗体，我直接放弃了)

既然(猜测)Notepad.exe是标准的窗口程序，那它一定按窗口程序的模板(如下)处理窗口消息，WM_CHAR等按键消息的处理亦包含其中:

在跟踪按键消息的消费者WM_CHAR的行为前，先要从茫茫众消息(窗体消息中有大量的鼠标移动的消息干扰分析)中筛选出WM_CHAR，思路如下:

搜索并定位GetMessage API；

分析GetMessage返回的消息，筛选出WM_CHAR消息；

下文分步实现上述思路：

先用IDA查找并定位Notepad.exe调用GetMessage API的位置，再用windbg下断点：

(根据IDA分析,Notepad.exe在WinMain中进行消息循环)

简单说明注记一下上面windbg的输出的:

L5处:GetMessage需要4个参数，参数1传入窗体消息MSG msg的地址。而我的OS是64位系统，所以Notepad.exe也是64位程序。而64位程序依次通过rcx/rdx/r8/r9传入函数的前4个参数;。lea rcx是传入窗体栈变量msg的地址;

L9处：运行到L9处时，GetMessage调用结束。在此处下断点，查看变量MSG msg就可以获得窗体消息。

为了使windbg能正确解析各个成员变量，需要明确告知windbg从GetMessage返回的窗体消息是个MSG结构体。

在GetMessage返回地址处下断点，当windbg断下后，开始解析MSG内容:

上面的片段中:

L1处 在GetMessage API的返回地址处下断点

L6处 从GetMessage API中获得的窗口句柄，这和前面Spy++获得的窗口句柄值一致

L7处 从GetMessage API中获得的消息类型，值0x0f对应WM_PAINT (我调试时，notepad.exe正好被windbg窗口挡住)。在此，我截取了WinUser.h中部分消息的定义:

窗口程序上会接收到大量消息，这些消息跟噪音一样影响分析。因此需要修改一下前面的断点，让它变为条件断点(条件断点略复杂，请移步windbg设置条件断点)，每当Notepad.exe中按键，windbg打印一串字符(WM_CHAR Enter)：

看下效果，左边的红框是我在Notepad中随意按键输入，右边是windbg相应输出 (作为演示效果挺好的，除了记事本按键半天才给个显示)：

Notepad.exe以内存映射的方式实现文件读写，它将收到的按键值暂存在所映射内存中，通过某种机制(哪种机制?)将这段内存内容显示在文本(文本编辑框)上。如果修改这段内存，是否导致最终文本内容被修改？以修改如下文本为例，自问自答吧:

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