I/O port sniffer

This program can be used to intercept PC I/O port activities. It uses X86 hardware debug registers as its ears, and eavesdrops at the lowest level. The readers are assumed to be familiar with windows device driver development and some knowledge about operating system and Intel X86 architecture.

I once wanted to analyze a program and find out the data it sends and receives from some I/O ports. I was surprised to find little resources about an I/O port sniffer over the web. I thought it should be a common utility. So I had to write my own.

At first, I wrote a driver to hook the original HAL routines such as READ_PORT_UCHAR. Though it worked mostly, it failed on the wanted program. I guess the programmer must have used assembly opcodes like “in” and “out” directly in his code. So what can I do? Is there any method to intercept I/O port accesses from the bottom (the hardware level)? Of course there is. At least windbg can do it. Windbg can set breakpoints on I/O port accesses. It uses X86 hardware registers as the deadly weapon.

Brief introduction of X86 debug registers

Intel X86 contains eight 32-bit debug registers to facilitate setting hardware breakpoints, DR7 ~ DR0, among which DR4 and DR5 are commonly not used. DR7 acts as the control register, DR6 as the status register and DR3 ~ DR0 are used to save breakpoint addresses. Only four different hardware breakpoints can be set at the same time. We can set hardware breakpoints either on memory or I/O port access. When a hardware breakpoint is hit, CPU will set according bits in DR6, raise a debug exception (#DB) and jump to the OS installed ISR handler, just as it does with a common exception. Hardware breakpoint exception is a “trap” which means the #DB ISR handler is fired after the CPU have executed the code which triggers the exception.

Read more: Codeproject

Posted via email from .NET Info