KMD layers between I/O manager (Io*) and hal.dll. KMD uses API exposed by hal.dll to interact with the hardware.
KMD process IRP (I/O Request Packets) handed down from I/O manager on behalf of user applications.
Microsoft introduced device framework to ease devlopment of KMD. WDM (Windows Driver Model) was released to support Win98 and W2K. WDF (Windows Driver Framework) encapsulates WDM with another layer of abstraction.
The DriverEntry() routine is executed when KMD is first loaded into kernel space. DriverEntry() returns the status in NTSTATUS type. DriverEntry() takes 2 parameters. The first IN parameter is of type DRIVER_OBJECT which contains information of the driver, including a list of function pointers:
DriverInit - by default, I/O manager set this to the address of DriverEntry()
DriverUnload - to be set by KMD for the routine to execute when KMD is to be unload
DriverDispatch - an array of MajorFunction which define the routines to be executed in response to the major function codes (e.g.IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_DEVICE_CONTROL etc) in the IRP passed down
Dispatch routines carry the following signature:
NTSTATUS DispatchRoutine(IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp);
For device control, IRP contains a 32-bit field, IoControlCode, which provide further information on the IRP. IocontrolCode comprises four sub-fields:
(1) DeviceType - Microsoft reserves type value 0x0000 to 0x7FFF e.g.FILE_DEVICE_DISK, FILE_DEVICE_KEYBOARD. User can define its own type using 0x8000 to 0xFFFF (32K)
(2) Function - program specific integer value defines action to be performed. MS reserves 0x0000 to 0x7FFF. User defined function span 0x8000 to 0xFFFF
(3) Method - defines how data are to be passed between user and kernel mode code. e.g. METHOD_BUFFER means OS to create a non-paged system buffer
(4) Access - READ or WRITE access to be declared before opening the file object representing the device.
To use the KMD, it must firstly be registered to the OS via RegisterDriverDeviceName(). Then use RegisterDriverDeviceLink() call to create a symbolic link for user mode program to communicate with the KMD.
User mode program first use CreateFile() to open the device. It then can use Windows API DeviceIoControl() to communicate with the KMD
Friday, September 27, 2013
Kernel Patch Protection (KPP) or PatchGuard
Originally deployed in 2005 and have 2 later upgrade (v2 and v3) to counter bypass techniques. PatchGuard monitor several vital system components (SSDT, IDT, GDT, MSR, ntoskrnl.exe, hal.dll and ndis.sys) periodically (5 to 10 min) against known singatures. It issues a bug check with stop code 0x00000109 (CRITICAL_STRUCTURE_CORRUPTION) when it detects any component change.
Kernel Mode Code Signing (KMCS)
KMD are required to be digitally signed in order to be loaded. Boot drivers are loaded early by winload.exe. Any driver that fails the integrity fail will prevent Windows from starting up. ntoskrnl.exe uses routines exported from ci.dll to check the rest of the drivers.
Service Control Manager
SCM is used to load and start drivers (KMD) and services in kernel space.
sc.exe is a utility to define, starts, stop and delete services and drivers.
The corresponding programmatic calls are
sc.exe is a utility to define, starts, stop and delete services and drivers.
The corresponding programmatic calls are
- OpenSCManager - open and obtaina handle to the SCM database. The handle is required for subsequent SCM calls.
- CreateService() - defines the services using supplied information including, name, binary path, START type etc. The handle return is required for the StartService call
- StartService() - load the driver or services
- ControlService() - use to stop the service DeleteService() - remove the driver information from SCM database
Thursday, September 19, 2013
DEP (Data Execution Prevention)
Windows feature that prohibit execution in designated pages to protect data, stack or heap pages.
Hardware enforced DEP is applicable to both OS and applicaiton
Software enforced DRP is applicable to application
Enabling DEP will also enable PAE. DEP is enable using /NXCOMPAT liner option.
PAE and AWE
The amount of RAM that can be accessed by Windows depends on OS version and underlining hardware.
For IA32 hardware, Windows can access beyond 4G RAM using Intel PAE (Physical Address Extension available since Pentium Pro). PAE is an extension to the system level bookeeping that allows a machine (via paging mechanism) to increase the number of address lines from 32 to 36. PAE is enabled in Windows via the /PAE boot option.
AWE (Address Windowing Extension) is a Microsoft specific feature that allows an application to access RAM beyond the 4G linear address space limit. AWE is an API (declard in winbase.h). AWE uses a set of fixed size regions (windows) in an application linear address space and maps them to a larger set of fixed size windows in physical memory.
AWE can operate with or without PAE. Application needs "Lock Page in Memory" privilege to use AWE.
VirtualAlloc() or VirtualAllocEx () - reserve a region in linear address space
AllocateUserPhysicalPages() - allocate pages of physical memory to be mapped to linear memory
MapUserPhysicalPages() or MapUserPhysicalPagesScatter() - map allocated pages of phsyical memory to linear memory
FreeUserPhysicalPages() - release the allocated pages
For IA32 hardware, Windows can access beyond 4G RAM using Intel PAE (Physical Address Extension available since Pentium Pro). PAE is an extension to the system level bookeeping that allows a machine (via paging mechanism) to increase the number of address lines from 32 to 36. PAE is enabled in Windows via the /PAE boot option.
AWE (Address Windowing Extension) is a Microsoft specific feature that allows an application to access RAM beyond the 4G linear address space limit. AWE is an API (declard in winbase.h). AWE uses a set of fixed size regions (windows) in an application linear address space and maps them to a larger set of fixed size windows in physical memory.
AWE can operate with or without PAE. Application needs "Lock Page in Memory" privilege to use AWE.
VirtualAlloc() or VirtualAllocEx () - reserve a region in linear address space
AllocateUserPhysicalPages() - allocate pages of physical memory to be mapped to linear memory
MapUserPhysicalPages() or MapUserPhysicalPagesScatter() - map allocated pages of phsyical memory to linear memory
FreeUserPhysicalPages() - release the allocated pages
Tuesday, September 17, 2013
Debugger
A machine debugger (e.g. debug command in DOS) views program as a stream of bytes. It can examine content stored in registers and memory location. It has no concept of variables or routines.
A symbolic debugger is a source level debugger. To perform debugging on source level, it uses the target's program's debug symbol table. The table contains a collection of variable length records which generated by compiler. The records contains information about variable (name, type, address) and functions (name, start address, end address, statement start and end address range).
These information allow the debugger to step execute the source code by running the machine instructions within defined ranges.
All operating systems provide hooks for debugger. Under DOS, debugger is driven off by 2 ISR:
INT 0x3 - signal to breakpoint.
INT 0x1 - allow single stepping
When the TF (Trace Flag) is set in the FLAGS/EFLAGS, the processor will execute a single instruction and then automatically execute an INT 0x1 instruction. This caused the ISR for 0x1 to execute. Processor will clear the TF automatically whenever it invokes a ISR so that the debugger does not need to operate in single step mode.
A symbolic debugger is a source level debugger. To perform debugging on source level, it uses the target's program's debug symbol table. The table contains a collection of variable length records which generated by compiler. The records contains information about variable (name, type, address) and functions (name, start address, end address, statement start and end address range).
These information allow the debugger to step execute the source code by running the machine instructions within defined ranges.
All operating systems provide hooks for debugger. Under DOS, debugger is driven off by 2 ISR:
INT 0x3 - signal to breakpoint.
INT 0x1 - allow single stepping
When the TF (Trace Flag) is set in the FLAGS/EFLAGS, the processor will execute a single instruction and then automatically execute an INT 0x1 instruction. This caused the ISR for 0x1 to execute. Processor will clear the TF automatically whenever it invokes a ISR so that the debugger does not need to operate in single step mode.
Subscribe to:
Posts (Atom)