Cheat Engine

[bahblah]

this is really tripping me up

[Dark Byte]

Accrding to wikipedia: Normally, a short integer variable will consist of 16 bits.
so 2 bytes

[bahblah]

This just doesn't make sense. In dump_wmimmc.sys

DriverEntry(...)
mov esi, [ebp + 8] //esi = pDriverObject
//some stuff, esi doesn't get changed
//...
mov dword ptr [esi+34h], offset sub_1158C

Ok sub_1158C is the DriverUnload routine. It frees non-cached memory and deletes symoblic link and device. So [esi + 0x34] should be the DriverUnload function in pDriverObject right?

typedef struct _DRIVER_OBJECT
{
CSHORT Type; [esi]
CSHORT Size; [esi + 2]
PDEVICE_OBJECT DeviceObject; [esi + 4]
ULONG Flags; [esi + 8]
PVOID DriverStart; [esi + 0xC]
ULONG DriverSize; [esi + 0x10]
PVOID DriverSection; [esi + 0x14]
PDRIVER_EXTENSION DriverExtension; [esi + 0x18]
UNICODE_STRING DriverName; [esi + 0x1C]
PUNICODE_STRING HardwareDatabase; [esi + 0x20]
PFAST_IO_DISPATCH FastIoDispatch; [esi + 0x24]
PDRIVER_INITIALIZE DriverInit; [esi + 0x28]
PDRIVER_STARTIO DriverStartIo; [esi + 0x2C]
PDRIVER_UNLOAD DriverUnload; [esi + 0x30]
PDRIVER_DISPATCH MajorFunction[IRP_MJ_MAXIMUM_FUNCTION + 1];
} DRIVER_OBJECT, *PDRIVER_OBJECT;

Why is [esi + 0x34] not DriverUnload then?!
Yes my common sense says that short is 2 bytes, but dump_wmimmc.sys says that it is 4 bytes which would make [esi + 0x34] DriverUnload.

[Dark Byte]

perhaps 32-bit variable allignment, makes accessing structures faster.

e.g code like mov ebx,[esi+eax*4] can then be used (eax:0 =Type, eax:1=Size, 2=DeviceObject, etc...

[bahblah]

Ah. That makes perfect sense.

Weird thing is in the _DEVICE_OBJECT the two beginning CSHORT's aren't 32-bit aligned. If it was then it would be storing the processevent handle in pDeviceObject->Vpb->Size instead of the pDeviceObject->DeviceExtension->ProcessEventHandle (It has 24 bytes for DeviceExtension)

[bahblah]

God...there's a UNICODE_STRING in there. Must look closer next time...