[ConcernedCitizen]

https://voidsec.com/windows-drivers-reve...up-the-lab
- It's quite a long yet friendly read if you're starting into or researching kernel debugging and driver exploitation at ring0.

With this blog post I’d like to sum up my year-long Windows Drivers research; share and detail my own methodology for reverse engineering (WDM) Windows drivers, finding some possible vulnerable code paths as well as understanding their exploitability. I’ve tried to make it as “noob-friendly” as possible, documenting all the steps I usually perform during my research and including a bonus exercise for the readers. (sic)

Outline:

Windows Driver 101:
A driver is a piece of software (module) that interacts with the kernel and/or controls hardware resources. One can think of a driver as a DLL, loaded into the kernel address space, and executed with the same privilege as the kernel.

DriverEntry:
Drivers have a well-defined entry point called DriverEntry. They do not have a main execution thread and they simply contain code that can be called by the kernel under certain circumstances. For this reason, drivers usually have to register “Dispatch Routines” within the I/O manager to service requests from user-land or other drivers.

Devices & Symlinks:
  - When analysing drivers, the first and most important task is to identify these dispatch routines and understand how they interact with the kernel.

Dispatch Routines:
  - Drivers execute different routines based on the Windows API that’s called on the device they expose. This behaviour is controlled by the driver developer through the MajorFunctions (an array of function pointers) member of the DriverObject structure. APIs like WriteFile, ReadFile and DeviceIoControl have a corresponding index inside MajorFunctions so that the relevant function pointer is invoked after the API function call.

DeviceIoControl & IOCTL Codes:
  - There is a specific index inside MajorFunctions defined as IRP_MJ_DEVICE_CONTROL. At this index, the function pointer of the dispatch routine (invoked after the DeviceIoControl API call on the driver’s device), is stored. This function is very important because one of its arguments is a 32-bit integer known as I/O Control Code (IOCTL).

Windows Driver Reverse Engineering Methodology
  - Driver Analysis:
      When performing a driver analysis is important to gather the following information:
      - Identify the DriverEntry
      - Determine the IRP dispatch handlers.
      - Determine if the driver attaches to another device to filter/intercept its I/O requests.
      - If so, what is the target device?
      - Determine the DeviceName.
      - Identify all the IOCTL codes and their corresponding functionality.
      - Determine what buffering method they use.
      - Try to understand how all the pieces fit together.

Coverage of this blog post:

• DriverEntry
  
• DeviceName
  
• Driver Buddy Reloaded
  
• Searching for vulnerable code paths
  
• Model-Specific Registers (MSRs)
  
• Loading the Driver
  
• Interacting with the Driver
  
• IOCTLpus
  
• DispatchDeviceControl
  
• UserBufferIn – Requirements and Constraints
  
• wrmsrs opcode
  

[*]
Exploitability:

We can clearly control all the “parameters” of the wrmsrs opcode but, unfortunately, we cannot overcome the restriction in place; preventing us from loading the 0xc0000082 (MSR Long System Target-Address Register – LSTAR) value into the ECX register. If anyhow, we would have been able to do so, we would have obtained arbitrary code execution in the context of the Windows Kernel (ring-0 / NT AUTHORITY\SYSTEM).

Is Admin>Kernel a security boundary? MSFT says nah. They're wrong.
https://threadreaderapp.com/convos/1479787860245028867

PM me if you don't understand a word of the blog post and I'll try to clarify if needed.