Feb 25, 2018 - Vb6 Serial Port Sniffer Source Code. Such a program structure, when the application is running, and the serial transceivers the data transceiver.
Introduction First of all excuse my English since it is not my native language and this is my first article. In this article, I'd like to share 'what I know' about how to monitor serial ports. Please note that this is about 'what I know' and I could be wrong about what I understand about driver programming, specially in this article.
If you find out that I am wrong, please let me know and we can discuss it further. So, what is a serial port monitor? Well, I believe you know what it is. The basic idea of this serial port monitor is: create a system driver and then add the filter driver functionality to it. Okay, let's get on to the detail. System driver As you can see in the source, this is just a system driver (without real hardware) and it implements minimal dispatch functions for the system driver.
If you want to see the requirements of a system driver, please take a look at MSDN. In this driver, I simply forward an IRP sent to this driver to the lower level driver as the default handler and use 'standard PnP and Power dispatch handling' as the WDK suggest. This driver also handles open, clean up, close, read, and control request, plus handles some requests as a serial port driver IRP handler requirement in WDK (Window Driver Kits). Attach to and detach from target device When a client application sends an IO control request to attach to a target device, IOCTLDKPORTMONATTACHDEVICE with a string parameter of the serial port name, the driver does this:. Driver gets the top of the target device object identified by the string parameter in the IOCTLDKPORTMONATTACHDEVICE request with IoGetDeviceObjectPointer. This routine will fill a pointer to the device object variable we provide if successful. The driver then creates a new device object characteristic of the device object we get from IoGetDeviceObjectPointer and the 0 size of the device extension.
After that, the driver copies the flags from the device object created by IoGetDeviceObjectPointer and puts some 'additional flags' if any. Attaches to the device object we just created with the IoAttachDeviceToDeviceStack function and then sets up initialization flags. And the code for attaching device (you can see the details in the function DkCreateAndAttachDevice in the file DkIoExt.c). Extern PDEVICEOBJECT gpThisDevObj. NTSTATUS DkCreateClose(PDEVICEOBJECT pDevObj, PIRP pIrp).
If (pDevObj!= gpThisDevObj) return DkTgtCreateClose(pDevExt, pIrp). Handling an IO request that is coming to our device object Before we discuss further about handling requests, I'd like to say a little bit about the queue in this driver.
This driver uses two kinds of queues, one for handling an IRP (Cancel-Safe queue as WDK suggested) and another for collecting data (simple First In First Out data queue / FIFO data queue). We discuss how we collect data later in the next section. Our driver handles open ( IRPMJCREATE), close ( IRPMJCLOSE), clean up ( IRPMJCLEANUP), read ( IRPMJREAD), and control ( IOCTLDKPORTMONATTACHDEVICE and IOCTLDKPORTMONDEATCHDEVICE) requests. As you can see in the source, open, close, and clean up requests are handled in the same dispatch routine, that is DkCreateClose. For open request, we just initialize our FIFO data queue, complete the request with STATUSSUCCESS, and returns STATUSSUCCESS.
For clean up request, we detach the device (if any, as the detach function state), clean the data queue and Cancel-Safe queue, and then complete the request. For close request, it just 'accepts' it, completes the request, and returns STATUSSUCCESS.
When we receive a read request from the client application program, we retrieve data from FIFO data queue. If there is data, we copy it to the system buffer which 'represents' the user buffer, and then remove/destroy/delete/free it, and then complete the request with STATUSSUCCESS and with the size of data we get from the FIFO data queue. If there is no data present in the FIFO data queue, we queue the IRP to Cancel-Safe queue then return a pending status, and indicate that the IRP is queued and will be completed later by another function in this driver ( DkTgtCompletePendedIrp function). This is the code fragment in file DkIoReq.c, in function DkReadWrite. As you can see, IRPMJWRITE comes just after IRPMJCREATE. This is because this port monitor does not monitor 'IRP state'. It collects data after/before the driver forwards the request, as we discussed in the previous subsection about collecting data above.
This driver doesn't check the status of the request whether they succeed or fail. Installation and usage This driver only supports Windows XP x86. If you use this on other platform than Windows XP, you need to recompile it under the target you want.
So this procedure below is only valid for Windows XP. Installation Step by step driver installation:.
In Control Panel, double click Add Hardware and then click Next, this will show the 'Searching hardware' dialog box. After the 'Searching hardware' dialog box finishes, click the radio button 'Yes, I have already connected the hardware', and then click Next.
In the Installed Hardware list box, scroll down and choose/click 'Add a new hardware device', and then click Next. Choose/click the 'Install the hardware that I manually select from a list (Advanced)' radio button and then click Next. In the 'Common Hardware Type' list box, choose/click 'System Devices' and then click Next. Click the 'Have Disk' button and then locate the file DkPortMon2.inf and then click Next.
Click Next again to finish driver installation. If the driver has installed successfully then the Device Manager should look like this: VI. Just run the program called ' DkPortMonGui.exe' in the Bin directory. First, you need to select the port to monitor, by clicking Tool - Select Port, select it and then click Tool - Start to start monitoring the port. If you want to see some debugging messages from the driver, use DbgView from SysInternals.