search

tklengyel / drakvuf

DRAKVUF Black-box Binary Analysis
https://drakvuf.com
Other
1.06k stars 254 forks source link

Non-consistent output for ProtectionValue of NtAllocateVirtualMemory #984

Open h4b4n3r0 opened 4 years ago

h4b4n3r0 commented 4 years ago

Hey guys,

When tracing syscalls I noticed for the NtAllocateVirtualMemory, that the Protect Value is not derived in a consistent format. Sometimes the value "0x4" (PAGE_READWRITE) is retuned and sometimes a longer version like "0x7FFB00000004" where the last nibbles correspond to the correct value. Is this wanted? Or can you explain this behaviour?

Thank you!

[SYSCALL] TIME:1599825007.600197 VCPU:1 CR3:0x4439D002 "\Device\HarddiskVolume2\Users\Changer.exe":NtAllocateVirtualMemory SessionID:1 PID:3756 PPID:6352 Module:"nt" vCPU:1 CR3:0x4439D002 Syscall:24 NArgs:6 ProcessHandle:0xFFFFFFFFFFFFFFFF *BaseAddress:0xCCDE30 ZeroBits:0x0 RegionSize:0xCCDE20 AllocationType:0x1000 Protect:0x4

[SYSCALL] TIME:1599825045.228981 VCPU:1 CR3:0x4439D002 "\Device\HarddiskVolume2\Changer.exe":NtAllocateVirtualMemory SessionID:1 PID:3756 PPID:6352 Module:"nt" vCPU:1 CR3:0x4439D002 Syscall:24 NArgs:6 ProcessHandle:0xFFFFFFFFFFFFFFFF *BaseAddress:0xCCDE30 ZeroBits:0x7FFEFFFF RegionSize:0xCCDE20 AllocationType:0x3000 Protect:0x7FFB00000004

icedevml commented 4 years ago

Seems like Protect in NtAllocateVirtualMemory should be ULONG which is uint32_t but here we do have some 64 bit value. I guess the upper part is a mistake.

icedevml commented 4 years ago

Looks like there is a hardcoded assumption somewhere that on 64 bit systems, the stack arguments are always 64 bit wide:

https://github.com/tklengyel/drakvuf/blob/master/src/plugins/syscalls/win.cpp#L197

and in this case it's unfortunately not correct.

(As a workaround you could just take this value and mask it with & 0xFFFFFFFF, should work OK.)

h4b4n3r0 commented 4 years ago

Thanks for your advice.