Introduction to Windows System Internals part II by Tim Shelton Black Security

Outline Windows Subsystems Windows Subsystems API Breakdown API Breakdown The API Layers The API Layers User-land and Kernel-land User-land and Kernel-land Processes, Threads, and Jobs Processes, Threads, and Jobs Virtual Memory Manager Virtual Memory Manager

Windows Subsystem Is the Windows NT structure considered a “microkernel”? No! Is the Windows NT structure considered a “microkernel”? No! A microkernel is a type of kernel in which the principal operating system components (such as memory manager, process manager, and I/O manager) run as separate processes in their own separated address space. EX: Carnegie Mellon University’s Mach (OSX) operating kernel. A microkernel is a type of kernel in which the principal operating system components (such as memory manager, process manager, and I/O manager) run as separate processes in their own separated address space. EX: Carnegie Mellon University’s Mach (OSX) operating kernel. Shares address space with rest of kernel components Shares address space with rest of kernel components

Windows Subsystem 3 Basic Types of User-Mode Processes Fixed processes ie: logon process, session manager Service Processes – runs independently of user logons. ie: Task Scheduler, Spooler service. Environment Subsystem Windows, POSIX, and OS/2

Windows NT Layer Executive Device Drivers Hardware Abstraction Layer (HAL) Kernel User Kernel Win32 User Apps Subsystem DLL System & Service Processes POSIXOS/2 Win32 User/GDI Environment Subsystems

Windows Subsystem Each Subsystem Contains Subsystem Service Process (csrss) Subsystem API library e.g. kernel32, advapi32, gdi32, ntdll Hooks in CreateProcess code Pseudo Subsystems ex: LSASS and CLR

Services & Kernel 3 Different Implimentations Application’s Container (Libraries) Separate Containers (Services) Central, Universally Shared Container (kernel)

Kernel Disadvantages of Kernel Less Flexible Single sysentry mechanism Inter-operation requires shared abstractions Access controls limited (ACLS)

Services Services have natural advantage Filtering and refinement of operations provides finer-grained access control Easy to provide alternative abstractions Seperated in their own protected private address space

Execution Layers Executive Execution Layer Executive Execution Layer Kernel Execution Layer Kernel Execution Layer

Executive Execution Layer Executive Execution Layer Executive Execution Layer Upper Layers of Operating System Upper Layers of Operating System Provides “generic operating system” functions Provides “generic operating system” functions Creating/deleting processes and threads Creating/deleting processes and threads Memory management Memory management I/O I/O Interprocess communication Interprocess communication Security Security

Windows NT Layer Executive Device Drivers Hardware Abstraction Layer (HAL) Kernel User Kernel Win32 User Apps Subsystem DLL System & Service Processes POSIXOS/2 Win32 User/GDI Environment Subsystems

Executive Execution Layer Almost completely portable C code. Almost completely portable C code. (bits of object oriented c++ and asm) (bits of object oriented c++ and asm) Private internal O/S structure Private internal O/S structure Runs in kernel ("privileged", ring 0) mode Runs in kernel ("privileged", ring 0) mode Many interfaces to executive O/S services undocumented Many interfaces to executive O/S services undocumented

Executive Execution Layer Lower Layers of O/S Lower Layers of O/S Processor dependant functions Processor dependant functions (x86 vs. alpha vs. embedded etc) (x86 vs. alpha vs. embedded etc) Processor independant functions closely associated with processor dependant functions Processor independant functions closely associated with processor dependant functions

Kernel Execution Layer Kernel Execution Layer Kernel Execution Layer Private internal O/S structure Private internal O/S structure Heart and Soul of O/S Heart and Soul of O/S Executes in kernel mode Executes in kernel mode API not documented! API not documented! Accessed indirectly via subsystem APIs Accessed indirectly via subsystem APIs

Windows NT Subsystem Executive Services API I/O System Security Monitor Win32 GDI Object Services Memory Mgmt Processes/ Threads Exec. RTL Device Drivers Hardware Abstraction Layer (HAL) Kernel Object Management File Systems I/O Devices DMA/Bus Control Cache Control Clocks/ Timers Privileged Architecture Interrupt Dispatch Registry User Kernel System Processes ServicesUser Apps Environment Subsystems Subsystem DLLInterface DLL Session Mgr WinLogon Replicator Alerter Event Log Win32 POSIX OS/2

Kernel Execution Layer Reasons for Kernel Code Execution Requests from user mode (system calls) Via system service dispatch mechanism (dispatcher) Kernel-mode code runs in context of requesting thread

Windows NT Subsystem Executive Services API I/O System Security Monitor Win32 GDI Object Services Memory Mgmt Processes/ Threads Exec. RTL Device Drivers Hardware Abstraction Layer (HAL) Kernel Object Management File Systems I/O Devices DMA/Bus Control Cache Control Clocks/ Timers Privileged Architecture Interrupt Dispatch Registry User Kernel System Processes ServicesUser Apps Environment Subsystems Subsystem DLLInterface DLL Session Mgr WinLogon Replicator Alerter Event Log Win32 POSIX OS/2

Kernel Execution Layer Reasons for Kernel Code Execution Interrupts from external devices Interrupts (like all traps) are handled in kernel mode NT-supplied interrupt dispatcher invokes interrupt service routiner ISR runs in context of interrupted thread ("arbitrary thread context") ISR requests execution of "DPC routine", which also runs in kernel mode

Kernel Execution Layer Reasons for Kernel Code Execution Dedicated kernel-mode threads Some threads in system stay in kernel mode at all times (mostly "System" process) Scheduled, preempted, etc., like any other threads

Hardware Abstraction Layer Subroutine library for kernel and device drivers Seperates Kernel and Executive from platform- specific details Presents uniform model of I/O hardware interface to drivers

Windows NT Layer Executive Device Drivers Hardware Abstraction Layer (HAL) Kernel User Kernel Win32 User Apps Subsystem DLL System & Service Processes POSIXOS/2 Win32 User/GDI Environment Subsystems

Hardware Abstraction Layer HAL abstracts System timers, cache coherency & flushing SMP support, Hardware interrupt priorities HAL implements functions in both Executive and Kernel Layers

Processes, Threads & Jobs Process Layout Each Process Has Its Own: Virtual address space Program Global Storage Heap Storage Threads' stacks

Processes Process Layout - Continued Processes cannot corrupt each others address space by mistake (sort of!) CreateRemoteThread Injection Working set physical memory "owned" by process

Processes Process Layout - Continued Access token includes security identifiers (objects) Handle Table for Win32 kernel objects Resources available to all threads in process Resources separate and protected between processes

Threads Each Thread has: Stack local variable storage, call frames, etc. Instance of top-level function Scheduling state Wait, Ready, and Running states Kernel Thread Priority Execution

Threads Each Thread has: Current access mode user-land kernel-land Saved CPU state of not Running Access token optional - overrides process token if present

Processes Processes Continued Container for address space and threads Associated User-mode Process Environment Block (PEB) Primary Access Token (objects) Quota, Debug port, Handle Table (objects)

Processes Processes Continued Unique process ID Process Object Queued Job List Global Process List Session list MM structures like WorkingSet, VAD tree, AWE etc

Threads Threads Continued Fundamental schedulable entity on system Represented by ETHREAD (includes KTHREAD) Queued to Process (both E & K thread) IRP List Impersonation Access Token Unique Thread ID

Threads Threads Continued Associated User-mode Thread Environment Block (TEB) User-mode stack Kernel-mode stack Process Control Block (in KTHREAD) for cpu state when not running Holds Ready, or Waiting status

Jobs Each Job contains: Container for multiple processes Queued Global Job List Processes and Jobs in Job Set Security token filters and job token Completion ports Counters, limits etc

Virtual Memory Manager How Do We Allocate Memory? Virtual Memory Manager User Land Memory Manager Kernel Land Memory Manager

Virtual Memory Manager Allocating User Memory Space Virtual Memory Manager Handles 4gb flat of VA space (IA32) Manages process address space Handles pagefaults Manages process working sets

Virtual Memory Manager Allocating User Memory Space Virtual Memory Manager continued… Manages physical memory Provides memory-mapped files Allows pages shared between processes Structure for I/O subsystem and device drivers Supports file system cache manager

Virtual Memory Manager Allocating User Memory Space Virtual Memory Manager Internal API NtCreatePagingFile() NtAllocateVirtualMemory() NtFreeVirtualMemory() NtQueryVirtualMemory() NtProtectVirtualMemory()

Virtual Memory Manager Allocating User Memory Space Virtual Memory Manager Pagefault NtLockVirtualMemory NtUnlockVirtualMemory NtReadVirtualMemory NtWriteVirtualMemory (OMG!! Thread Injection Tangent) NtFlushVirtualMemory

Remote Thread Injection Tangent One way to copy some code to another process's address space and then execute it in the context of this process involves the use of remote threads and the WriteProcessMemory API. Basically you copy the code to the remote process directly now - via WriteProcessMemory - and start its execution with CreateRemoteThread.

Remote Thread Injection Tangent The CreateRemoteThread & WriteProcessMemory technique of code injection is, when compared to the other methods, more flexible in that you don't need an additional DLL. Unfortunately, it is also more complicated and riskier than the other methods.

Remote Thread Injection Tangent You can (and most probably will) easily crash the remote process, as soon as something is wrong with your Injected Thread. Because debugging a remote Thread can also be a nightmare, you should use this technique only when injecting at most a few instructions.

Virtual Memory Manager Allocating Kernel Memory Pool Tightest x86 system resource is KVA Kernel Virtual Address Space Pool allocates in small chunks = 4kb: page granularity Paged & Non-panged pool Paged pool backed by pagefile Special pool used to find corruptors Lots of support for debugging/diagnosis

Virtual Memory Manager Memory Paging (writing unused memory to disk and paging (pulling it back into active memory) Working Sets - list of valid pages each process and kernel Pages 'trimmed' from working set on lists Standby list: pages backed by disk Modified List: dirty pages to push to disk Free list: pages not associated with disk Zero List: supply of demand-zero pages

Virtual Memory Manager Memory Paging – Continued… Modify/standby pages can be faulted back into a working set w/ disk activity (soft fault) Background system threads trim working sets, write modified pages and produce zero pages based on memory stat and config parameters

Virtual Memory Manager Managing Working Sets Aging pages - Increment age counts for pages which haven't been accessed Estimate unused pages: count in working set and keep a global count of estimate When memory starts to become scarce replace rather than add pages when fault occurs in working set with significant unused pages When memory IS scarce reduce (trim) working sets which are above maximum

Virtual Memory Manager Memory Paging – Continued… Managing Working Sets Balance Set Manager periodically runs Working Set Trimmer, also swaps out kernel stacks of long-waiting threads

Review Windows is segmented into many different layers in order to control the flow of execution. Windows does many things unique to any other publicly available operating system (obviously)

Questions? \o/|/\