WRK Compatibility With Windows Server 2003 SP2

By Alexander Schmidt

The deployment of Windows Server 2008 R2 Hyper-V based virtual machines to facilitate our operating system course assignments has brought up the issue that virtual machines have to run at least Windows Server 2003 SP2. Since the WRK documentation says that Windows Server 2003 SP1 is needed to run the kernel, the question remains whether the application binary interface (ABI) of those two versions are compatible. As others indicated (thanks for your comments 🙂) and evaluated on our server, the WRK appears to be able to run on Windows Server 2003 SP2. Nevertheless, I wanted to examine if at least the user-kernel mode ABI is compatible, for which I will give an answer in this post.

The Application Binary Interface for the WRK is determined through the system call table and its calling conventions (system call number in EAX, parameters on the stack). Since I don't assume that the calling conventions have changed, I concentrated on the system call table. If any of the system call numbers would differ, both versions are incompatible. On the Metasploit web site, you can find a comparison of system calls from various Windows versions. Unfortunately, system calls of Server 2003 SP2 are not listed in their table. It also appears that the site is not active anymore since the comparison ends with Windows Vista.

So, I had to find out the system call table myself. Fortunately, WinDbg is your friend in such a case. The user mode portion of a Windows system call is implemented in ntdll.dll and looks like this:

mov  eax,<system_call_number>
mov  edx,offset SharedUserData!SystemCallStub (<resolved_address>)
call dword ptr [edx]
ret  8

Since system calls are exported by ntdll.dll, we can scan through all the exported symbols starting with Nt. Then we can disassemble the instructions for each function. As shown in the snippet above, the first two instructions are enough to figure out, whether the symbol we found is actually a system call. To retrieve a disassembly of all exported symbols starting with Nt, I used the following WinDbg command:

.foreach /ps 5 (syscall {x ntdll!Nt*}) {u syscall L2}

The command x ntdll!Nt* examines all symbols from ntdll.dll that start with Nt. Each line is passed to a variable named syscall, for which we disassemble (u) the first two instructions (L2). Unfortunately, the .foreach command does not iterate line wise over an input stream but rather word wise. Since the x command delivers multiple words of information per symbol, the /ps switch tells .foreach to skip 5 of those (unnecessary) parameters. Finally, I wrote a small Python script to search through the generated output to identify all the included system calls and extract the system call number.

I performed this experiment twice: once on an SP1 and once on a SP2 machine. Here are the system call tables of these two versions:

As you can see in the table above, both versions offer the same amount of system calls, which is why, from an ABI perspective, the WRK can run on both operating system versions. Unfortunately, there is one uncertainty left: the WRK links against modules such as the HAL. If there are any dependencies broken, which I think is pretty unlikely, you may encounter unexpected crashes or unpredictable behavior.

If you have any comments or hints about how to resolve the issue, please let us know.

Comments