Serial Filter Kernel Driver

NTDEV
1

Dear all,

It’s a great opportunity to join this excellent forum. This is my first attempt at writing a Kernel Driver. What I’m aiming to achieve is the creation of a small filter driver that captures all traffic from a serial port, such as IOCTL_SERIAL_GET_CHARS, to fully monitor the serial port’s activities in stealth mode when another application is using it.

I came across this driver (https://www.codeproject.com/Articles/311159/SIMPLE-SERIAL-PORT-MONITOR) written in 2012, which I was able to compile, install, and run. Unfortunately, it’s not very stable, but it serves as a good starting point.

It frequently crashes with a THREAD exception, and getting Windows back to normal operation after such crashes is quite challenging.

Once again, I must emphasize that this is my first experience with Kernel Drivers, and I’m struggling to set up a stable debugging configuration for testing.

Can anyone provide guidance on whether there’s a clean way to create a simple driver for passive monitoring of serial port activity?

2

are you taking on this project to learn drivers or is there a different problem you are trying to solve? this already exists, the Sysinternals portmon tool does everything you want, https://learn.microsoft.com/en-us/sysinternals/downloads/portmon

3

Hello Doron, I need to make my own working driver and be able to filter com port opening, send, receive, baudrate change and such. I do not need an out of the box solution.

4

What bigger problem are you trying to solve? This is not a simple driver or a great first time project.

1 Like
5

Right. The problem is that the serial interface literally goes back to the very first version of Windows 1.0, and even though things have evolved over the years, you still find applications and higher level drivers that do things in an unusual way.

6

n short, I’m putting in a lot of effort to get the filter working, but occasionally, I encounter the dreaded Blue Screen error message that reads “Service Handle Exception,” which is certainly not a good sign. One major problem is that I’m not receiving the IRP_MJ_READ and IRP_MJ_WRITE packets, indicating that the Driver dispatch isn’t capturing all events. Is there anyone willing to collaborate with me to troubleshoot and get this driver up and running?

7

What’s the client here? Is it coming from an app or from another driver?

8

I am installing my kernel driver and accessing it as a device from a GUI application.

I’ve made some progress in resolving the missing packets issue. The “monitored” application keeps sending IOCTL_SERIAL_GET_COMMSTATUS, which is causing a significant slowdown in my kernel driver’s signal dispatching.

To clarify the situation:

Teraterm or a similar  <-- third-party monitored (target) application is in use.
SpyCOMdriver.sys <-- my serial port sniffing driver.
SpyCOM_GUI.exe <-- my GUI software that utilizes SpyCOMdriver to capture all IRP and MJ events.

I initialize my driver from SpyCOM_GUI as follows (pseudo code):

_**m_hPort = ::CreateFile(L"\\.\SpyDriver", GENERIC_ALL, 0,
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, NULL);
if (m_hPort == INVALID_HANDLE_VALUE)
return false;

m_RdOvr.hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL);
m_RdOvr.OffsetHigh = 0;
m_RdOvr.Offset = 0;
if (!m_RdOvr.hEvent)
{
m_bReqStop = true;
::CloseHandle(m_RdOvr.hEvent);
::CloseHandle(m_hPort);
return bRes;
}

… Here I launch the reading Thread in a while 1 where I ReadFile the driver outputs

**_