MiM Project Progress Report Slides by Jonathan Leach

What we’ve done Compiled QEMU from source. Used logging capabilities of QEMU to get guest assembly instructions. Identified entry point in QEMU source to where modifications should be made to intercept commands.

What we’ve done (cont’d) Identified static memory locations for Windows system calls. Identified Windows system calls used for “dir” command (via ProcMon). Identified basic approach to “intercept” system calls:

Intercepting System Calls in Windows Anytime a system call is made, there is always a specific hard-coded address loaded. It references ntdll.dll with an offset of some amount depending on the syscall function. Example: ZwCreateFile() next few slides.

Process Monitor Stack For my capture of the “dir” command I don’t have any occurrences of ZwCreateFile() being called. So I’m using ZwOpenFile().

ProcMon Stack Summary

Example Segment of Syscall Table Windows XP SP3

ZwCreateFile() Loading value corresponding to NtCreateFile() in Win7 SP1

Explanation ZwCreateFile() is a function called on the user level stack. Inside ZwCreateFile it will load some value into the EAX register for the kernel level NT function it needs to call.

Importance When we want to intercept the “dir” command, we have to identify it based on sequence of system calls. “dir” is mostly ZwQueryAttributesFile() calls.

Windows NT Family of Windows operating systems architecture including: – Windows 3.1 – Windows 2000 – Windows XP – Windows Vista – Windows 7 – Windows 8

Windows NT Layered in two main components: – User mode – Kernel mode For cmd.exe we look at Win32 within Environment subsystems.

Windows NT Kernel Mode Kernel mode has full access to the hardware and system resources of the computer and runs code in a protected memory area. While the x86 architecture supports four different privilege levels (numbered 0 to 3), only the two extreme privilege levels are used. Usermode programs are run with CPL 3, and the kernel runs with CPL 0. These two levels are often referred to as "ring 3" and "ring 0", respectively. Windows Executive services make up the low-level kernel-mode portion, and are contained in the file ntoskrnl.exe

Windows NT User/Kernel Mode Win32 applications have to make function calls to NTDLL.dll to be able to do anything requiring kernel level permissions (syscalls).

Native API The Native API is the mostly undocumented API used internally by the Windows NT family of operating systems produced by Microsoft. It is predominately used during system boot, when other components of Windows are unavailable, and by routines such as those in kernel32.dll that implement the Windows API. The program entry point is called DriverEntry(), the same as for a Windows device driver. However, the application runs in ring 3 the same as a regular Windows application. Most of the Native API calls are implemented in ntoskrnl.exe and are exposed to user mode by ntdll.dll. Some Native API calls are implemented in user mode directly within ntdll.dll.

Native API Function Groups The Native API comprises many functions. They include C runtime functions that are needed for a very basic C runtime execution, such as strlen(), sprintf() and floor(). Other common procedures like malloc(), printf(), scanf() are missing. The vast majority of other Native API routines, by convention, have a 2 or 3 letter prefix, which is:C runtime functionsC Nt or Zw are system calls declared in ntdll.dll and ntoskrnl.exe. When called from ntdll.dll in user mode, these groups are almost exactly the same; they trap into kernel mode and call the equivalent function in ntoskrnl.exe via a branch table. When calling the functions directly in ntoskrnl.exe (only possible in kernel mode), the Zw variants ensure kernel mode, whereas the Nt variants do not. [3] The Zw prefix does not stand for anything. [4]kernel modebranch table [3] [4] Rtl is the second largest group of ntdll calls. These comprise the (extended) C Run-Time Library, which includes many utility functions that can be used by native applications, yet don't directly involve kernel support. Csr are client-server functions that are used to communicate with the Win32 subsystem process, csrss.exe (csrss stands for client/server runtime sub-system).csrss.exe Dbg are debugging aid functions such as a software break point. Ki are upcalls from kernel-mode for things like APC dispatching.APC Ldr are loader functions for PE file handling and starting of new processes.PE Nls for Native Language Support (similar to code pages).Native Language Support Pfx for prefix handling.

For information on these functions Go here:

Native API KERNEL32 functions that call the Native API directly include all of its I/O (e.g CreateFile(), ReadFile(), WriteFile()), synchronization (e.g. WaitForSingleObject(), S etEvent()), and memory management (e.g. VirtualAlloc(), VirtualPro tect()) functions. In fact, the majority of KERNEL32's exported routines use the Native API directly. The figure below shows the flow of control from a Win32 application executing a Win32 call (CreateFile()), through KERNEL32, NTDLL, and into kernel mode where control is transferred to the NtCreateFile system service.

Look at this book! bKYdcC&printsec=frontcover&source=gbs_ge_ summary_r&cad=0#v=onepage&q&f=false bKYdcC&printsec=frontcover&source=gbs_ge_ summary_r&cad=0#v=onepage&q&f=false

Unexplored Problems QEMU has a dynamic binary translator (DBT) which converts binary code from the guest CPU architecture to the host architecture. Mentioning this because it could pose a problem: – Based on our entry point, we can only see one translation block at a time. How can we identify an entire “dir” command and modify it’s output if we only see segments at a time?

Dynamic Binary Translator First, the DBT converts the guest binary code into a sequence of simple micro- operations, packaged in a translation block. MicroOPs are mapped to host code instructions and passed to host.

Translation Blocks A translation block ends when the sequence hits a return, call, jump, or interrupt. Certainly for these system calls, we will be using “call” Again, as stated earlier we must identify a “dir” command which spans over many TBs by looking at one translation block at a time.

More Unexplored Problems The 5 D’s – Degrade – Disrupt – Destroy – Delay – Deny How will we implement these?

The Five D’s Delay – Fairly obvious. Inject a bunch of NOPs in the assembly instructions. – But how exactly? We have to change the actual assembly instructions but we cannot completely overwrite what is being done. – Jump to another memory address containing a large amount of NOPs and at the end jump back?

The Five D’s Deny – We would have to observe a command and see what even goes on when a command is denied. – After analyzing this, we must then figure out a way to replicate this. I won’t bother with explanations of approaches for the others, but you can see these are not easy.

Future Research Look at Wine for Linux (WINdows Emulator) – Both Linux and Windows use x86_64. However Linux uses ELF and Windows uses PE (portable executable). Also, consider cmd vs. telnet session – I assume they will not be RDPing to the Windows machine. – In the future, set up client-server telnet session and execute the command.

Sources /systemCalls.html /systemCalls.html windows/ /firstchapter#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODA3Mz U2NjI3MjglMkZpZDMwNTU4Mzg= windows/ /firstchapter#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODA3Mz U2NjI3MjglMkZpZDMwNTU4Mzg=