From now on it will keep both cursors on the two windows synchronized. If you scroll one window, IDA Pro automatically scrolls on the other one as well.

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.

In addition to renaming all the indexes I like to rename the function names. You can do it by:

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
)

It is advisable to keep the same calling convention you find in the original definition. In this case it is __fastcall.

Now we can move to our IrpDeviceIoControlHandler routine:

If we inspect the first function we notice it actually returns a pointer in a global variable that points to a memory allocation obtained by calling ExAllocatePoolWithTag():

When the driver returns from the first function, it passes the returned pointer to the next function along with the whole IRP. If we give a quick look at the second function we may notice It is a big function that handles the different IOCTLs.

I suggest to rename both functions and change their function signature:

Now let’s start inspecting InnerIrpDeviceIoCtlHandler():

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.

Now we know the function accesses the IoControlCode variable, provided as input from user mode, and based on that it handles the IRP differently. Let’s inspect the following piece of decompiled code:

Notice it references IoControlCode variable and subtract 0x22e084. If the result is zero, it calls a function (passing as input Irp->AssociatedIrp.MasterIrp). This means that 0x22e084 is a valid IOCTL. If we decode it, for example with OSR Online IOCTL Decoder we notice the info METHOD_BUFFERED:

Recalling MSDN, when using METHOD_BUFFERED, the input and output buffer, passed from user mode, are represented by Irp->AssociatedIrp.SystemBuffer. At this point we are sure we can change the union Irp->AssociatedIrp.MasterIrp to be actually Irp->AssociatedIrp.SystemBuffer.

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

Inside our InnerIrpDeviceIoCtlHandler() we notice a rdmsr instruction (__readmsr() in the decompiled code).

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!

Identifying an arbitrary pointer dereference

After additional reversing of InnerIrpIoCtlHandler() and the functions called by InnerIrpIoCtlHandler() itself, we can see a call to callDriver() (a reversed function) passing as input multiple fields from systemBuffer.

Here’s the pseudocode of callDriver() after reversing:

At this point we must reverse these two functions in order to understand what we are able to do.

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.

Now let’s reverse IofCallDriver():

NTSTATUS __stdcall IofCallDriver(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
  _IO_STACK_LOCATION *v2; // rax
  __int64 MajorFunction; // r8

  if ( IopDispatchCallDriver )
  {
    if ( IopDispatchCallDriver == 3 )
      return IopPerfCallDriver((PADAPTER_OBJECT)DeviceObject);
    else
      return IovCallDriver(DeviceObject);
  }
  else
  {
    if ( --Irp->CurrentLocation <= 0 )
      KeBugCheckEx(0x35u, (ULONG_PTR)Irp, 0LL, 0LL, 0LL);
    v2 = Irp->Tail.Overlay.CurrentStackLocation - 1;
    Irp->Tail.Overlay.CurrentStackLocation = v2;
    MajorFunction = v2->MajorFunction;
    v2->DeviceObject = DeviceObject;
    if ( (_BYTE)MajorFunction == 22 && (unsigned __int8)(v2->MinorFunction - 2) <= 1u )
      return IopPoHandleIrp(Irp);
    else
      return ((__int64 (__fastcall *)(PDEVICE_OBJECT))DeviceObject->DriverObject->MajorFunction[MajorFunction])(DeviceObject);
  }
}

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!

Wrapping up