If you want you can also further synchronize the Hex View with IDA View and Pseudocode windows using the same procedure. Right-click on the Hex View window and then select Synchronize With -> IDA VIEW A - Pseudocode - A.

The next steps here are:

1. Identifying the symbolic link to the driver (so that we know how to get a handle to the driver from user-mode).
2. Identifying driver dispatch routines handling IRPs.

In this case we will focus only on the IRP_MJ_DEVICE_CONTROL major function code but typically he IRP_MJ_READ IRP_MJ_WRITE and IRP_MJ_CREATE major function codes are also of interest.

At this point I suggest to rename the indexes in the array with the corresponding IRP_MJ_XXX code. To do this you can:

1. Click on the number and press m.
2. Select Yes in the popup.
3. Then Ctrl-F and type IRP_MJ in the search bar.
4. Select the appropriate entry and press ok.

1. Clicking on the sub_XXXX you want to rename.
2. Press n.
3. Change the name and press Enter.

After that I suggest to change the function signature to the appropriate one. Based on MSDN,  the signature is the following:

NTSTATUS DriverDispatch(
  [in, out] _DEVICE_OBJECT *DeviceObject,
  [in, out] _IRP *Irp
)

To change the function signature:

1. Click on the target function name.
2. Press y.
3. Insert the appropriate function signature.

We can see it references multiple fields inside the IRP. If we give a look at the definition of the IRP and _IO_STACK_LOCATION  we can see the fields CurrentStackLocation->Parameters and Irp->AssociatedIrp are actually unions.

Taking the CurrentStackLocation->Parameters we can see that it’s a union that changes based on the IRP Major Function Code handled. As the current function handles a IRP_MJ_DEVICE_CONTROL function code, we should use CurrentStackLocation->Parameters.DeviceIoControl in IDA Pro.

To instruct IDA Pro to do so, you must:

1. Click on the union field (CurrentStackLication->Parameters) press Alt + y.
2. Ctrl + f for searching for DeviceIoControl and then select the proper one (Parameters.DeviceIoControl.IoControlCode in this case).

At this point we are interested in reversing and analyzing the code that handles our systemBuffer variable and see if there are any vulnerabilities.

As we can see from the snippet of code above, the routine takes the input for the __readmsr instruction from the systemBuffer (that we control) and returns the output again in systemBuffer. This grants us the ability to read arbitrary MSRs!

We can see it performs:

1. A call to IoGetAttachedDeviceReference() passing as input the first parameter (that we fully control).
2. A call to IofCallDriver() passing as input the output of IoGetAttachedDeviceReference().

Open another IDA Pro window and load the ntoskrnl.exe of the Windows 11 VM. After some reversing we get the shape of IoGetAttachedDeviceReference():

PDEVICE_OBJECT __stdcall IoGetAttachedDeviceReference(PDEVICE_OBJECT DeviceObject)
{
  unsigned __int8 CurrentIrql; // di
  char *v3; // rcx
  _DEVICE_OBJECT *i; // rax
  _DWORD *SchedulerAssist; // r8
  __int64 v7; // r9
  unsigned __int8 v8; // cl
  struct _KPRCB *CurrentPrcb; // r9
  _DWORD *v10; // r8
  int v11; // eax
  bool v12; // zf


 [...]
  for ( i = DeviceObject->AttachedDevice; i; i = i->AttachedDevice )
    DeviceObject = i;
  if ( ObpTraceFlags )
    ObpPushStackInfo((__int64)&DeviceObject[-1].DeviceLock.Header.WaitListHead, 1, 1u, 'tlfD');
  ObpIncrPointerCount((volatile signed __int64 *)&DeviceObject[-1].DeviceLock.Header.WaitListHead);
  KxReleaseQueuedSpinLock((char *)KeGetPcr()->NtTib.ArbitraryUserPointer + 160);
  if ( KiIrqlFlags )
  {
    v8 = KeGetCurrentIrql();
    if ( (KiIrqlFlags & 1) != 0 && v8 <= 0xFu && CurrentIrql <= 0xFu && v8 >= 2u )
    {
      CurrentPrcb = KeGetCurrentPrcb();
      v10 = CurrentPrcb->SchedulerAssist;
      v11 = ~(unsigned __int16)(-1LL << (CurrentIrql + 1));
      v12 = (v11 & v10[5]) == 0;
      v10[5] &= v11;
      if ( v12 )
        KiRemoveSystemWorkPriorityKick(CurrentPrcb);
    }
  }
  __writecr8(CurrentIrql);
  return DeviceObject;
}

We can see that basically it walks the DeviceObject->AttachedDevice linked list and then returns the last element in the list. In addition, before returning we can see a call to ObpIncrPointerCount() passing as input DeviceObject-0x30. It is easier to see it in the disassembly listing (rbxcorresponds to DeviceObject):

Here’s the reversed ObpIncrPointerCount() function:

signed __int64 __fastcall __spoils<rax> ObpIncrPointerCount(volatile signed __int64 *a1)
{
  signed __int64 result; // rax
  result = _InterlockedIncrement64(a1);
  if ( result <= 1 )
    KeBugCheckEx(0x18u, 0LL, (ULONG_PTR)(a1 + 6), 0x10uLL, result);
  return result;
}

Notice the call to _InterlockedIncrement64(). This seems to grant us an arbitrary increment primitive. However, we have to consider that callDriver(), later on, calls ObfDereferenceObject() on the same AttachedDeviceReference variable.

If we reverse ObfDereferenceObject() we can see that the function decrements the same field that was previously incremented. This compensating action is going to null out our arbitrary increment making it very likely unexploitable.

The most interesting part of the function is the last line. It calls a function pointer inside the MajorFunction array part of DriverObject part of DeviceObject. Since we can control DeviceObject then we can control the function pointer inside the MajorFunction array. This grants us the ability redirect the execution flow to an arbitrary location!