NDIS. Introduction
Actually, as promised, I begin a series of articles about the NDIS subsystem and about what is connected with it. I decided to link it with the process of my own learning at my first job. If the cycle does not work out, it means that I was fully loaded, or even quit.
For what, in general, this NDIS? Why did they come up with it, if everything is already so good?
')
NDIS is one of the Windows kernel subsystems that is directly related to the spectrum, from network card drivers to interfaces for network layer protocols. NDIS consists of the so-called. driver stack (although, as for me, it’s not a stack, but a queue), but for a common understanding it’s better to imagine it this way:
If you dig deeper, then NDIS consists of a mandatory part - itself (the NDIS.SYS file), and a theoretically unlimited number of user drivers, which this NDIS.SYS wraps up. At the same time, the driver must perform some actions so that the NDIS subsystem considers it to be local at all and can integrate into its “stack” which is the queue. The minimum conditions are:
All these drivers are divided into several types, namely:
Frequently, in practice, driver-filters and intermediate drivers are written, since in the rest, a small circle of companies have their own network solutions. At the time of XP, developers often used intermediate drivers (because there were no filters), starting with Windows Vista it is better to use filters, since they are simpler in their device and the main function (and for us in almost all cases - traffic modification) is performed with a bang. So, as we remember, “on top” of NDIS we have protocols (IP, IPX, ARP, RARP, etc.), and network cards on the bottom. In this gap, we will perform our magic spells on traffic.
We will understand the difference between filter drivers and intermediate drivers. So, when traffic moves to the network, i.e. from protocol to network card, it goes through a queue of user drivers that NDIS has formed. In the middle of this queue (honestly, I don’t know how to find the middle if there are 3 drivers in the queue, but you can’t argue with MSDN) NDIS has intermediate drivers. These drivers are built in turn by an unknown algorithm, but NDIS ensures that traffic passes through each driver in the “stack”. The intermediate driver is a snag, "top", i.e. for drivers that are located above it, it looks like a miniport (although these miniports are still far below), and “below” looks like a protocol (protocols are far above). So The intermediate driver is transparent, and often it is used not to filter or modify traffic, but to “send” traffic from one protocol to several miniports (they are also interfaces of network cards). Well, or vice versa: sending network card traffic over several protocols.
Ok, this is understandable, now about filter drivers. A driver filter is a driver that is also located along the path of traffic from the network card to the protocols, but the specific location in the queue is determined by the settings, and more about them later. Now let's take a look at the fact that driver filters are of two types (do not confuse the type that defines the location of the driver and the main type):
From the name it is clear what is the difference between them, but it is worth noting that during installation both drivers are installed and “work” normally. Those. if you have written tracking functions, then you will see traffic. However, the driver modifier in some cases will require a reboot. If there is no reboot, then you can monitor the traffic, but, let's say, drop the packets - no. Functional feature.
Now let's deal with the place of filter drivers in the queue. The position in the queue is determined by the purpose of the driver. The purpose of the driver (the usual purpose, that is, what this driver is used for) is installed at the installation stage in its .INF file. I will not give a complete list of appointments, but I will outline a picture. Suppose the driver is designed to compress traffic, for this we specify “compression” in the .INF file, there is also the purpose of “encryption”, or “Custom”.
Here you can see the entire list. I will also say that custom - the most underlying drivers, and, for example, the scheduler - the most "top".
Perhaps enough for today, read more information here:
msdn.microsoft.com/en-us/library/ff557563 (v = VS.85) .aspx
Next time let's talk about the minimum implementation of the driver filter.
Introduction
For what, in general, this NDIS? Why did they come up with it, if everything is already so good?
')
NDIS is one of the Windows kernel subsystems that is directly related to the spectrum, from network card drivers to interfaces for network layer protocols. NDIS consists of the so-called. driver stack (although, as for me, it’s not a stack, but a queue), but for a common understanding it’s better to imagine it this way:
Well, but this is not enough for me!
If you dig deeper, then NDIS consists of a mandatory part - itself (the NDIS.SYS file), and a theoretically unlimited number of user drivers, which this NDIS.SYS wraps up. At the same time, the driver must perform some actions so that the NDIS subsystem considers it to be local at all and can integrate into its “stack” which is the queue. The minimum conditions are:
- The driver must register itself. This means that the driver, when booted, indicates to the kernel what it really is and what type it is;
- The driver must provide the minimum set of interface functions that it provides to NDIS. Actually, for these functions, NDIS will be this very driver;
- Also, the driver should, depending on its type, implement the functions of self-control, which also thrust during the execution. The difference from the previous paragraph is that these functions are unique for each type of driver.
All these drivers are divided into several types, namely:
- Miniport drivers;
- Protocol drivers;
- Intermediate drivers;
- Drivers filters.
Frequently, in practice, driver-filters and intermediate drivers are written, since in the rest, a small circle of companies have their own network solutions. At the time of XP, developers often used intermediate drivers (because there were no filters), starting with Windows Vista it is better to use filters, since they are simpler in their device and the main function (and for us in almost all cases - traffic modification) is performed with a bang. So, as we remember, “on top” of NDIS we have protocols (IP, IPX, ARP, RARP, etc.), and network cards on the bottom. In this gap, we will perform our magic spells on traffic.
We will understand the difference between filter drivers and intermediate drivers. So, when traffic moves to the network, i.e. from protocol to network card, it goes through a queue of user drivers that NDIS has formed. In the middle of this queue (honestly, I don’t know how to find the middle if there are 3 drivers in the queue, but you can’t argue with MSDN) NDIS has intermediate drivers. These drivers are built in turn by an unknown algorithm, but NDIS ensures that traffic passes through each driver in the “stack”. The intermediate driver is a snag, "top", i.e. for drivers that are located above it, it looks like a miniport (although these miniports are still far below), and “below” looks like a protocol (protocols are far above). So The intermediate driver is transparent, and often it is used not to filter or modify traffic, but to “send” traffic from one protocol to several miniports (they are also interfaces of network cards). Well, or vice versa: sending network card traffic over several protocols.
Ok, this is understandable, now about filter drivers. A driver filter is a driver that is also located along the path of traffic from the network card to the protocols, but the specific location in the queue is determined by the settings, and more about them later. Now let's take a look at the fact that driver filters are of two types (do not confuse the type that defines the location of the driver and the main type):
- The monitor driver does not subject traffic to changes, but can “steal” it;
- Driver-modifier, full control over traffic, change, delete, add your own - whatever.
From the name it is clear what is the difference between them, but it is worth noting that during installation both drivers are installed and “work” normally. Those. if you have written tracking functions, then you will see traffic. However, the driver modifier in some cases will require a reboot. If there is no reboot, then you can monitor the traffic, but, let's say, drop the packets - no. Functional feature.
Now let's deal with the place of filter drivers in the queue. The position in the queue is determined by the purpose of the driver. The purpose of the driver (the usual purpose, that is, what this driver is used for) is installed at the installation stage in its .INF file. I will not give a complete list of appointments, but I will outline a picture. Suppose the driver is designed to compress traffic, for this we specify “compression” in the .INF file, there is also the purpose of “encryption”, or “Custom”.
Here you can see the entire list. I will also say that custom - the most underlying drivers, and, for example, the scheduler - the most "top".
Perhaps enough for today, read more information here:
msdn.microsoft.com/en-us/library/ff557563 (v = VS.85) .aspx
Next time let's talk about the minimum implementation of the driver filter.
Source: https://habr.com/ru/post/113233/
All Articles