I/O element such as a network interface, a high-level networking protocol, a
file system, or a physical storage device.
Of course, the position in which a filter resides on the I/O stack makes a very
big difference, because it affects the type of data that the filtering component is
going to receive. For example, if a filtering component resides above a high-
level networking protocol component (such as TCP for example), it will see the
high-level packets being sent and received by applications, without the vari-
ous low-level TCP, IP, or Ethernet packet headers. On the other hand, if that fil-
ter resides at the network interface level, it will receive low-level networking
protocol headers such as TCP, IP, and so on.
The same concept applies to any kind of I/O channel, and the choice of
where to place a filter driver really depends on what information we’re look-
ing to extract. In most cases, we will not be directly making these choices for
ourselves—we’ll simply need to choose the right tool that monitors things at
the level that’s right for our needs.The Win32 Subsystem
The Win32 subsystem is the component responsible for every aspect of the
Windows user interface. This starts with the low-level graphics engine, the
graphics device interface(GDI), and ends with the USER component, which is
responsible for higher-level GUI constructs such as windows and menus, and
for processing user input.
The inner workings of the Win32 subsystem is probably the least-docu-
mented area in Windows, yet I think it’s important to have a general under-
standing of how it works because it is the gateway to all user-interface in
Windows. First of all, it’s important to realize that the components considered
the Win32 subsystem are not responsible for the entire Win32 API, only for the
USER and GDI portions of it. As described earlier, the BASEAPI exported from
KERNEL32.DLLis implemented using direct calls into the native API, and has
really nothing to do with the Win32 subsystem.
The Win32 subsystem is implemented inside the WIN32K.SYSkernel com-
ponent and is controlled by the USER32.DLLand GDI32.DLLuser compo-
nents. Communications between the user-mode DLLs and the kernel
component is performed using conventional system calls (the same mecha-
nism used throughout the system for calling into the kernel).
It can be helpful for reversers to become familiar with USER and GDI and
with the general architecture of the Win32 subsystem because practically all
user-interaction flows through them. Suppose, for example, that you’re trying
to find the code in a program that displays a certain window, or the code that
processes a certain user event. The key is to know how to track the flow of such
events inside the Win32 subsystem. From there it becomes easy to find the pro-
gram code that’s responsible for receiving or generating such events.104 Chapter 3