Driver Introspection with DriverMon

November 18, 2017

In the past few weeks I've been working in my non-existent spare time on DriverMon - a driver monitoring tool for Windows. The tool is far from complete, but it's already quite useful. In this post I'll describe how to use it and some of the challenges of building such a tool. Initially I wanted to be able to track every I/O Request Packet (IRP) targeted to monitored devices. The term "devices" here is important, as the Windows I/O system is device-centric rather than driver-centric. That is, requests are delivered to devices, not drivers. A device can be thought of...
no comments

Integrating COM IPC into Existing Executables

October 6, 2017

A few days ago at work, a requirement arouse to create some form of inter-process communication (IPC) between two cooperating processes where the source code for the executables themselves already existed, so such mechanism should integrate into the existing code as easily as possible, while providing bi-directional communication. Several options were brought up, including pipes and sockets. The processes are services and have no UI, so Window messages were not an option. Other ideas included shared memory with notifications using kernel event objects... and then I suggested COM. There was a brief silence and then people started murmuring things like "COM...
tags: , , ,
no comments

DLL Injection with SetThreadContext

September 5, 2017

There are several techniques available for injecting a DLL into a process. Each has its own strengths and drawbacks. The simplest one uses the CreateRemoteThread function to create a new thread in the target process and point the thread's start function to the the LoadLibrary function, as LoadLibray and a thread's starting function have the same prototype from a binary perspective (both accept a pointer). This method is the easiest to use but also the most visible. Creating a new thread can be "noticed" in several ways, such as with an ETW event. If a driver is present and is hooking...
no comments

Hooking COM Classes

August 7, 2017

There are some common scenarios that benefit from the ability to hook operations. The canonical example is hooking Windows API functions for debugging purposes, or for malware detection. In this scenario, some DLL is injected into a target process and then hooks relevant functions. There are several ways to do that, but that is not the focus of this post; the interested reader can search the web for more information. In the Component Object Model (COM) world, things are not so easy. Since COM is object based, it's not generally possible to get the address of a COM interface method,...
tags: , , , ,
no comments

C++ enum class Tip: Bitwise operator support

One of the nice features of C++ 11 is scoped enums ("enum class"). This solves a few issues with the classic C++ enums: Scoped enums don't "leak" into the enclosing scope as classic C++ enums do. Scoped enums don't automatically convert to integers, helping with type safety. Scoped enums can be declared with the size of the underlying integer. However, there is one feature that I believe was overlooked, or at least deemed unimportant to get into the standard: the automatic support for bitwise operations. For example, suppose I'm writing a class called Process that wraps a Windows process handle and provides convenient access...
no comments

Enumerating Job Objects

June 17, 2017

Job objects have been around since Windows 2000, providing a convenient way to set limits and otherwise manage a set of processes. Up until Windows 8 job objects were used sparingly, because a process could only be associated with a single job at most. That would mean an application wanting to set some limits on a process it does not create explicitly had no way of knowing whether that process was already part of a job. If it were, assigning it to another job would simply fail. Starting with Windows 8, jobs can be nested, effectively creating a job hierarchy...
no comments

Packaging Apps into Single Files

May 9, 2017

One of the hallmarks of easy-to-use tools is simple installation, preferably no installation at all. The classic example is the Sysinternals tools. Each tool is a single executable, self contained, and can be run from anywhere, including network shares and web locations. These tools have no dependencies (except for built-in Windows DLLs), or so it seems. One canonical example is Process Explorer that hides within it two binaries. The first is a kernel driver, used to extract information from the system that cannot be done from user mode (such as reading values of kernel variables), and the other is a 64...
tags: , , , ,
no comments

Enhanced GFlags Tool

April 3, 2017

The well-known GFlags tool, part of the Debugging tools for Windows package allows manipulating a 32-bit flags value maintained by the kernel and per-process. Strictly speaking, Gflags allows changing more than just these flags, such as adding the Debugger value to an image file entry that indicates which executable should be activated whenever the original image is executed. GFlags has a crude user interface that has not been updated for ages. The first annoyance with its UI is the lack of a minimize button. Here's a screenshot: The tool provides a way to change flags for three...
no comments

Injecting a DLL without a Remote Thread

March 14, 2017

A well-known technique for injecting a DLL into another process involves using the CreateRemoteThread(Ex) function to create a thread in another process and point the thread function to the LoadLibraryA or LoadLibraryW, since these functions have the same signature (on the binary level) as a thread function. Before calling CreateRemoteThread, the caller uses VirtualAllocEx to allocate some memory to hold the path to the DLL. This technique is simple and reliable, but has a couple of drawbacks: 1. The target process must be opened with a relatively broad access mask that includes PROCESS_CREATE_THREAD. 2. Anti-malware agents typically...
2 comments

Hiding Named Objects

March 2, 2017

A common technique in Windows for sharing kernel objects between processes is by using a name. The cooperating processes call the appropriate Create function (e.g. CreateMutex) and specify a simple string name. The first process to make the call actually creates the object, and subsequent processes get another handle to the exact same object. Whether that's a new object or not does not usually matter; however, that piece of information is returned with a GetLastError() code of ERROR_ALREADY_EXISTS. Another option is to call the corresponding Open (e.g. OpenMutex) function in cases where it's known that the intended object has...
no comments