Tags

, , , , , , , ,

In one or two of my earlier posts, I covered some techniques for viewing the contents of executable files using a handful of standard UNIX tools. But what happens when executables become live running processes on a Microsoft Windows system?

First, the concept of objects and handles: Whereas everything in a UNIX operating system is treated as a file, that is, OS components pipe I/O to each other, everything in a Windows operating system above the kernel and Hardware Abstraction Layer is instead an object. Something called a ‘handle’ is assigned to whatever objects are used by an executable or DLL, which is basically a pointer to another object – kind of like ‘handles’ are used in IRC when addressing a message to a particular chatroom user. If a function, process or DLL needs to interact with an object in the Windows operating system, it will generally (with some exceptions) refer to that object using its handle. This scales all the way up to Active Directory stuff, which is also object-oriented.

The other concept is that of ‘processes’ in the Windows OS. Something like Task Manager gives us a list of running processes, like a list of program names, their resource usage, etc. Each entry actually refers to areas of system memory that are assigned to running each program. Essentially a process is a container in system memory, a ‘virtual address space’ that exists for as long as the program’s running.
What’s inside a Windows process? We’d find a copy of the executable itself, runtime data, resources used by the executable, handles to other objects in the Windows OS, and of course the processor and CPU register states (the ‘thread’). It’s the thread/context thingy that enables the system to switch between tasks and keep several applications running concurrently.
For the purpose of this post, it’s the handles we’re interested in, as they’re pointers to other objects in the operating system, such as network sockets, DLLs, other executables, kernel components, etc. – again, everything in Windows is an object.

Object Dump and Data Structure
It follows that a process must have a definite structure of some kind. After all, the OS and Instruction Pointer need to know where everything is when running a program. Well, it does, and it’s possible to view a static version of it with the objdump command in UNIX. For example, running the following in UNIX on AccessEnum.exe:
$objdump -p AccessEnum.exe

And this gives us a list of DLLs and associated handles used by the executable during runtime:

EXE-Handle-Addresses

The hexadecimal values in the ‘vma’ column are relative memory addresses and offsets, not absolute memory hardware addresses. Taking the following two entries as an example:
a968 GetModuleHandleA
a97c GetStartupInfoA

Here the hex numbers refer to the Virtual Memory Addresses, the relative addresses of GetModuleHandleA (A968) and GetStartupInfoA (A97C). What this means, if my maths is correct and each address location marks 1 byte, is that GetStartupInfoA will always be 20 bytes from GetModuleHandleA, regardless of where the executable is actually loaded during runtime. This 20 bytes difference is referred to as the ‘offset’, and it’s important when calculating addresses for exploiting buffer overflow vulnerabilities.

Okay, that’s all well and good when examining static executables and DLLs. A number of similar options are available for investigating actual running processes (at least the known ones) on a Windows system, the most obvious being Process Explorer. For proper analysis, we’d want to dump the process from system memory into a static file using a tool like pmdump.exe (with the -list option to list all running processes).
With the process dumped to file, that file could then be opened in a hex editor or binary analysis program of choice.

It’s good to know in itself, but what can we use it for? By looking at the list of DLLs and their associated handles, we can get a rough idea of what an executable does, and whether its true functionality extends beyond its supposed functionality, as Trojan malware would. For example, a program called notepad.exe shouldn’t be calling network socket handles.

Advertisements