Whether writing shellcode, using some language’s FFI, or working on my EvilVM malicious compiler project, sometimes I need to know the value of a constant for calling some Win32 function. Sometimes, you can find the values in the MSDN documentation. But other times, it’s not so easy. Check this one out, from the MS documentation for opening process handles:

Missing Constants

What’s interesting on this one is that the actual value, from the header files, does not equal the value you’d get if you took all the other ones and OR’d them together. Maybe it doesn’t matter, but it’s nice to know what the right value is.

In other cases, constants are members of an enum, and MS doesn’t give you the value in the docs, or maybe they just left it out to be mean. This post is about how I find the values, since I run into it quite a bit when I’m writing hacking tools in something other than C.

The most annoying solution is to pull out the actual header files, and try to find the values. Sometimes they have conditional values based on your architecture, or they can be nested in other includes. Some are greppable, some aren’t. Doing this manually gets annoying very quickly.

Another possible solution would be to keep Visual Studio up all the time, with a C++ project. You could type in the constants, hover over them, and see the value. This works fine, though I can’t figure out how to copy and paste the values from the hovering window (maybe there’s a way to do it?). Plus, the expressions aren’t always fully evaluated. But the main reason I don’t like this one is because I write everything in a Linux environment, and keeping VS up somewhere all the time is asking a lot.

visual studio hover

But one key observation is that MinGW knows what these constants resolve to when it compiles, and I’m already using it for cross-compilation to make EXEs in EvilVM. So maybe I can get MinGW to tell me what the constant values are…

Cue wincon, my Win32 constant resolver. It works by constructing simple C programs, passing them to MinGW, and spitting out the constant values for me. There are a few special cases, and it tends to handle most of what I throw at it.

If we want to see a constant as the preprocessor expands it, we can see it’s “lexical value”, if you will, by preprocessing a “program” like this:

#include <windows.h>

When we macro expand this, we get something like the following:

$ x86_64-w64-mingw32-gcc -E -o - foo.c | tail -n 5
  WINBOOL ImmDisableTextFrameService(DWORD idThread);
# 131 "/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h" 2 3 4
# 2 "foo.c" 2
((0x000F0000l) | (0x00100000l) | 0xfff)

So we can see that the value of PROCESS_ALL_ACCESS is the result of that expression on the last line. (same as Visual Studio showed us too…) That’s handy enough, but there are some other cases. For example, this “program” might get us the value of TCP_TABLE_OWNER_PID_ALL (handy if you’re trying to do a netstat the manual way):

#include <windows.h>
#include <iphlpapi.h>

But we see that this doesn’t work, because the value is in an enum, so the preprocessor isn’t expanding it at all:

$ x86_64-w64-mingw32-gcc -E -o - foo.c | tail -n 5
  DWORD RestoreMediaSense (OVERLAPPED *pOverlapped, LPDWORD lpdwEnableCount);
# 3 "foo.c" 2

# 3 "foo.c"

So we can get this “lexical value”, but not always the actual numerical value by using the preprocessor. But we can pull out the slightly bigger guns, and pass a program through to the compiler, but stop just short of assembling it to machine code. Let’s do a program something like this:

#include <windows.h>
#include <iphlpapi.h>
#include <stdint.h>
static uint64_t value = (uint64_t)TCP_TABLE_OWNER_PID_ALL;
int main() { return (int)value; }

If we compile it to assembly without optimization and look at the resulting machine code, we can find the number stored in value pretty easily:

$ x86_64-w64-mingw32-gcc -S -o - bar.c
	.file	"bar.c"
	.align 8
	.quad	5
	.def	__main;	.scl	2;	.type	32;	.endef
	.globl	main
	.def	main;	.scl	2;	.type	32;	.endef
	.seh_proc	main
	pushq	%rbp
. . .

See where the label value: is a .quad with the value 5? That’s the value of our constant! So this is the sort of “nuclear” approach for getting a constant’s value. It’s tantamount to writing a throwaway C program that would print out the number, but we don’t have to go so far as to run it (e.g., with Wine or something). We can just extract it from the assembly output from MinGW.

So, here’s wincon in action:


Of course, it spits out the Forth ... value ... syntax for easy inclusion in EvilVM. And that’s about it – a handy command line tool that gets me definitions for Win32 constants in about a second; no muss, nor fuss. You can find wincon on github.