Bug Hunter Diary

So the driver uses the METHOD_BUFFERED transfer type to describethe input and output buffers of an IOCTL request. According to thebuffer descriptions in the Windows Driver Kit, the input buffer ofIOCTLs, which use the METHOD_BUFFERED transfer type, can be found atIrp->AssociatedIrp.SystemBuffer.Below is an example of a reference to the input buffer in the disassemblyof Aavmker4.sys:[..].text:00010CF1 mov eax, [ebx+0Ch] ; ebx = address of IRP.text:00010CF4 mov eax, [eax][..]In this example, EBX holds a pointer to the IRP structure. Ataddress .text:00010CF1, the IRP structure member at offset 0x0c isreferenced.kd> dt -v -r 2 _IRPnt!_IRPstruct _IRP, 21 elements, 0x70 bytes+0x000 Type : ??+0x002 Size : ??+0x004 MdlAddress : ????+0x008 Flags : ??+0x00c AssociatedIrp : union __unnamed, 3 elements, 0x4 bytes+0x000 MasterIrp : ????+0x000 IrpCount : ??+0x000 SystemBuffer : ????[..]The output of WinDbg shows that AssociatedIrp is located at thisoffset (IRP->AssociatedIrp). At address .text:00010CF4, the input bufferof the IOCTL call is referenced and stored in EAX (Irp->AssociatedIrp.SystemBuffer). Now that I had found the supported IOCTLs, as wellas the IOCTL input data, I started searching for bugs.Step 6: Reverse Engineer the IOCTL HandlerTo find a possible security defect, I audited the handler code of oneIOCTL at a time while tracing the supplied input data. When I cameacross the IOCTL code 0xB2D60030, I found a subtle bug.If the IOCTL code 0xB2D60030 is requested by a user space application,the following code is executed:[..].text:0001098C ; int __stdcall sub_1098C(int, PIRP Irp).text:0001098C sub_1098C proc near ; DATA XREF: DriverEntry+130[..].text:00010D28 cmp eax, 0B2D60030h ; IOCTL-Code == 0xB2D60030 ?.text:00010D2D jz short loc_10DAB ; if so -> loc_10DAB[..]One Kernel to Rule Them All 99