Article title: Application Layer Junction Scheme: Fang Original: http://www.xfocus.net Release: Unknown Publish Type: Reprinted Release Date: 2004-11-19 Today Views: 15 Total View: 547
Why is the need to apply a layer of interception introduction to a filter, conversion protocol, intercept packet analysis, and so on. The filter type is more applicable, typically a filtered firewall. The application of the conversion protocol is limited to some specific environments. For example, third-party development network protocol software, cannot be integrated with the original operating system software, and have to take "block" (bits) embedded protocol stack. For example, IPsec's third party implementation, unable to fuse the IP software provided by the operating system vendor, there is only a layer of the IP layer and the link layer as the protocol stack. Third-party PPPoE software is also achieved in this way. The interception package is used for analysis, and the "capture" describes more appropriate, "interception" generally indicates that there is a truncated ability, "the bag" only needs to be able to get it. Implementation is generally implemented as a protocol layer. The "Application Layer Interception" said in this paper specifically refers to the case in the driver, and then sent to the working mode of the application layer. The network packet intercepting method under the intercepted mode User state is 1. Winsock Layered Service Provider; 2. Windows 2000 packet filter interface; 3. Replace the system's own Winsock dynamic connection library; use the driver to block the network packet 1. TDI filter driver 2. NDIS Intermediate Driver 3. Win2k Filter-Hook Driver4. Ndis Hook Driver User Intercept data package has some limitations, "Obviously, User states to intercept the most deadly disadvantages can only be performed at the Winsock hierarchy, and the packets of the underlying protocol in the network protocol stack cannot be processed. For some Trojans and viruses, it is easy to avoid this level of firewall. "The" Application Layer "we said is not to intercept the data package in the user state. Instead, intercepted in the driver and processed in the application layer. To get a universal way, it should be intercepted under the IP layer. Comparison, this paper uses intermediate layer mode. Why do I want to apply a message that is intercepted by the application layer, network applications such as firewalls, protocol software is working in the kernel, why should we put forward, ask for a message to handle packets? The reason can also be found (even if it is more intensified): It is well known that the driver development has a certain difficulty. For an experienced programmer, there is no technical problem during the development process, but for beginners, especially The first contact programmer is simply a painful experience. In addition, the development cycle is also a problem that has to be considered. The program works in the kernel, stability / compatibility requires a lot of tests, and the library available for use is quite small relative to the application layer. In the development of application, debugging modifications are relatively easy. The unfavorable factors also include: performance impact, work mode work, change the working mode, whenever the driver is intercepted, send it back to the application layer again, and transfer it to the IP protocol. Therefore, the performance has a very large effect, the efficiency is very low, and only 80% of the performance performance is on the 100Mbps network. In combination, the application is still more suitable at a specific occasion: the desktop is used, the desktop network load is quite small, less than 100Mbps is sufficient to meet the requirements, especially for the Internet, etc., the network connection is less than 512kbps. Do not consider performance factors at all. As a stand-alone firewall or other protocol implementation, analysis is easy to implement based on this manner.
The program model is described above with the model, the main process is as follows: Receive the message process: 1. Network interface receives the packet, intercept, pass 2 to the application layer processing; 2. Apply layer processing , Send back to the intermediate layer processing result; 3. The intermediate layer discards the message according to the processing result, or send the processed message to the IP protocol; 4. IP protocol and upper application receive packets; send packets Procedure: 1. The upper application sends data, so IP protocol sends packets; 2. The message is intercepted by the intermediate layer, and the application layer is sent to the application layer; 3. After the application layer is processed, send back the intermediate layer processing result; 4. Middle The layer discards the message according to the processing result, or sends the process to the network; implementing detail to explore the IO and communication there is an easy way to use an event between the drivers and applications. When the application cretefile, the driver IOCREATESYNCHRONIZATIONEvent is a famous event, then the application CreateEvent / Openevent is a famous event. Note: 1, do not create an event when driving initialization, most of which cannot be created successfully; Conversely, if the application is created first, the application and driver has read and write permissions; / BasenamedObjects / xxxevent "; 4, the way in the way can also be used, but is feasible at Win98, unknown. 5. Since then, the driver should return to the read request, otherwise it will return failed. Otherwise, it will not be able to read the meaning of the event notification (no longer waiting for reading, but if there is a need (notify event)); 6, the application finds an event, should be read in a loop until reading failed, Indicates that there is no data readable; otherwise, subsequent data will be missed without timely read; processing thread priority application layer processing thread should increase priority, because the thread is other upper application service, if the priority is prioritized than other threads Low words will occur similar to deadlocks. In addition, it must be noted when improving priority, threads minus runtime, do not occupy the CPU for a long time, other threads cannot obtain services. The priority does not have to be improved to the realtime_priority_class level, at which time the thread cannot do some of the operations such as disk IO, and it also affects the mouse, keyboard, etc. The driver can also dynamically improve the priority of the thread. After the driver receives the message, at least one buffer should be temporarily stored, waiting for the application layer processing. The buffer does not have to be large, as long as the buffer can not overflow before the application layer gets the time slice, it is enough to store dozens of messages in practice. The way of buffering is a queue of advanced first out. Considering that it is convenient for a static storage ring queue, that is, do not have to allocate memory every time, a large number of memory is allocated, and the ring is used.
Initial, head == tail == 0; TAIL and HEAD are unlimited growth. TAIL - Head <= size; When putting a message, tail = tail packetlen; takes out a message, head = head packetlen; tail == head indicates that the empty; tail> Head indicates that there is data; Tail Input Packet Length - head> size indicates full; taking data:
PPACKET GETPACKET () {assert (tail> = head); if (tail == head) Return null; // else ppacket = & start [Head% size]; if (Head% size ppacket-> length> size) //// Data is discontinuous (part in the tail, part in the head); ELSE // data is a continuous return PPACKET;} put into data: BOOL INPACKET (PPACKET) {if (Tail Input packet length - head> size) // full Return false; // copy packet ket to & start [tail% size] // if (tail% size packet length> size) // data is not continuous (part in the tail, part at the head); // else // data is Continuous Tail = Tail Packet Length; Return True;} The above way is an array to provide a maximum message length for each message. Because the number of buffers is limited, this approach can meet the needs. If you want to take into account the waste of space, you can store the actual length of each message, the above algorithm cannot be adapted to this way. Communication for application layers and drivers During the network card receiving / IP transmission, the driver caching packets, and the event notifies the application layer there is a message that needs to be processed. Then apply this message to get this message through the IO method or shared memory. Practical description, at 100Mbps rate, the above two ways can meet the needs, the simplest way is to use a buffered IO method. The application layer is processed, or one of the above two ways can be used to submit the results to the driver. However, the IO method can only send only one message at a time, the 100Mbps network speed drops to 70% to 80% network speed, and 10Mbps will not have an impact. That is, the maximum speed emitted by the host is only 70% of the network speed, which is the same as the speed of the UDP datagram that does not exceed the MTU. For TCP, due to bidirectional communication, a larger loss, approximately 40% to 60% speed. At this time, use shared memory mode because reduced system calls, can avoid decline in speeds. The speed control sent by the message When the IP protocol sent a message, in general, our intermediate-level driver must cocaine these packets, telling IP software to send success, and then make the application layer to make a decision after processing. Obviously, the speed of storage packets far exceeds the speed that the NIC can send, but IP software (especially UDP) will send packets at our storage speed. There is a rapid depletion of the cache. Subsequent packets have to be discarded. In this way, UDP sends will not work properly. Since the TCP can be adapted to the network condition, it can still work in this case, and the speed is about 70%. In the PASSTHRU, it can be forwarded to the low-level drive, then returned with asynchronous or synchronous mode, thereby achieving the transmission speed of the NIC. Therefore, there must be a way to avoid this situation. The intermediate layer driver caches these messages and tells the IP software to send the status without the decide. Wait until the final process is complete, tell the IP software to send it. To coordinate the transmission speed. This approach brings a problem, that is, the driver must give up ownership of these buffer messages without sending timeout.
Specifically, when the MiniPortreset is called, it is possible to be NDIS to perceive the transmission timeout, thereby abandoning all unfinished sending operations. If this is not properly handled, it will lead to serious problems. If the intermediate layer is initialized in MiniPort, the NDIS_ATTRIBUTE_IGNORE_PACKET_TIMEOUT flag will not be obtained by calling the NDISMSetAttributeSex function, then the intermediate layer driver will not get the message timeout notification, and the intermediate layer must process the cache. Work with Passthru works when the upper application no longer needs to be intercepted, the driver should be all PASSTHRU behavior. This requires all sent / received functions to properly handle the interception and non-packaged state, not to make hazards. Specifically, all receive / send functions are properly processed from the IP protocol to the IP protocol to send data packets / accept the IP protocol to the IP protocol. Other auxiliary facilities add some control functions to provide finer granular control, allowing applications to get more freedom. For example, you can control which network card is intercepted, you can control the traffic in a direction, whether the network has change (NIC uninstall / disable), and more. Implementation PassthRu source code, modified, main modifications, including: 1. Modify the receiving function 2. Modify the send function 3. Add a packet cache 4. Add IO section 5. Add control function 6. Increase the application layer Subsequent processing This implementation uses shared memory, with a buffer pool after the process of handling the buffer pool and an application. Due to receiving packets and to send messages to use the same buffer pool, this implementation is not much faster than the IO mode because of other reasons. Through careful designs and comparisons, you can do 100MBPS speed delivery speed. This article is designed to discuss this method and feasibility of this application layer intercept. Also because the source code is not suitable for commercial use, it is not suitable for commercial use. As a demonstration, it is only intercepting the Ethernet type packet. So the demonstration driver will not contain source code. The third-party developers use cap.h API header files, capdll.dll contains the following functions: BOOL CapInitialize (); VOID CapUninitialize (); BOOL CapStartCapture (PKTPROC PacketProc, ADAPTERS_CHANGE_CALLBACK AdaptChange); VOID CapStopCapture (); DWORD CapGetAdaptList (PADAPT_INFO pAdaptInfo , Dword buffersize; void capSetrule (Handle Adapter, Ulong Rule); Bool CapsendPacket (Handle Adapter, Ulong Opcode, Ulong Length); the Capdll.lib file of the DLL is also available to introduce Capdll in the VC engineering file. LIB uses a more convenient compilation connection. Note that the return value of all functions does not specify the cause of the error. The DEBUG version can print run information at the console and have the same output information in C: / Capture.txt. Bool Capinitialize (); Description: Notify the intermediate layer driver to do some necessary initialization work. Parameters: None. Return Value: Failure Returns False. Void CapunInitialize (); Description: Release the event, thread, memory, etc. created by the driver. Parameters: None. Return Value: None.
Note: Before calling this function, CapSetrule should be called to set the driver intergna rule to OPCode_PASSTHRU to restore the PassthRu behavior. Bool CapStartCapture (pktproc packetproc, adapters_change_callback adaptchange); Description: Start intercept. CAPDLL will create a thread, run on the Thread_Priority_Highest priority, and wait for the network event, when the driver receives the message, or the IP protocol sends a message, or discovers the network card boot / disable / insert / remove, will pass users The paid callback function notifies the user. Parameters: PacketProc: User provides packet processing functions; AdaptChange: Network change notification function provided by users; return value: void capStopCapture (); Description: Stop intercepted. Destroy the created thread. Parameters: None. Return Value: None. DWORD CAPGETADAPTLIST (Padapt_info Padaptinfo, DWORD BUFFERSIZE); Description: Get a list of network adapter cards. Parameters: Padaptinfo Adapt_info structure array, users provide sufficient space. Buffersize buffer size. Return Value: Number of network adapted cards. Void CapSetrule (Handle Adapter, Ulong Rule); Description: Set the intercept rule. Parameters: Adapter: Specifies the intercepted NIC handle. Rule: For opcode_passthru: passthru behavior; opcode_snd: Intercept all send messages; opcode_rcv: Intercept all received packets. OpCode_snd | opcode_rcv can be used. Return Value: None. Bool CapsendPacket (Handle Adapter, Ulong Opcode, Ulong Length); Description: Place the processed packet into the buffer. You can also construct a message yourself. Not only can I send a message, but also a message to the native IP software. Parameters: Adapter: Specifies the network card handle used. OpCode: opcode_snd, send the message to the network; OpCode_rcv, passes the packet to the unit software. Length: Packet length; DATA: message content; return value: successfully returns true, failure to return false. Sample
