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...

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

Monitoring ALPC Messages

February 12, 2017

The Advanced (or Asynchronous if you prefer) Local Procedure Calls (ALPC) is the internal communication mechanism Windows components use as an inter-process communication (IPC) mechanism for message exchange. Conceptually, it's similar in principle to Remote Procedure Calls (RPC), with client and server ports, but does not use any networking, and is optimized for different message sizes. ALPC messages can reveal the hidden communication between various processes that are almost invisible otherwise. Conceptually, hooking ALPC messages is possible but not easy. First, the user mode and kernel mode APIs are undocumented. Second, hooking would likely involve all processes for which...
no comments

MEF Tip: Initializing Objects

December 5, 2016

I like MEF. Maybe it's because of the default way MEF binds – using custom attributes; I like the declarative nature of attributes. Anyway, MEF exports declare their dependencies through the Import attribute. Here is a simple class export that has some imports:class AppManager {         ILogger _logger;         IFileService _fileService;     public AppManager() {        _logger.LogMessage("AppManager created");    }     public void DoWork() {        var filename = _fileService.GetFileForOpen();        if (filename == null)            return;         _logger.LogMessage("Opening file...");         var lines = File.ReadAllLines(filename);        _logger.LogMessage("Reading done.");         Console.WriteLine($"Read {lines.Length} lines of text.");    }} The AppManager class has two dependencies – an ILogger implementation and...
no comments