[Vrtule]

Do you have a problem with ZwQueryVirtualMemory or with ObOpenObjectByPointer (as your code might suggest)?

If you specify UserMode as access mode, the system performs security checks whether you are allowed to do the operation. Additionally, some buffers must point to userspace memory (this is true especially for ZwXxx functions).

[Carlbyte]

This opening process normally, but the ZwQueryVirtualMemory does not work. I configured kthread-> previousmode to kernelmode and does not work. MBI.baseaddress receives the address value to be checked but MBI.allocationbase receives a kernel-level value (error).

[Carlbyte]

"Additionally, some buffers must point to userspace memory"

means PagedPool ?

[Vrtule]

Show the ZwQueryVirtualMemory call in your code.

No, the buffers must lay on virtual addresses accessible to the user application. On 32-bit systems, these addresses are below 2 GB usually.

[Carlbyte]

MEMORY_BASIC_INFORMATION BasicInformation;
pFnZwQueryVirtualMemory ZwQueryVirtualMemory = NULL;

ZwQueryVirtualMemory = (pFnZwQueryVirtualMemory)
KeServiceDescriptorTable.ServiceTableBase[ServiceId_NtQueryVirtualMemory];

ntStatus = ObOpenObjectByPointer(Process, OBJ_INHERIT,
NULL, 0, *PsProcessType,
kernelmode, &HandleProcess);

ntStatus = ZwQueryVirtualMemory(HandleProcess,
(PVOID)Address,
MemoryBasicInformation,
&BasicInformation,
sizeof(MEMORY_BASIC_INFORMATION),
&ReturnLength);

It is a test function, made several modifications in an attempt to make it work. the thread starts previousmode as "usermode" and when I try to use it in "DriverEntry" works. probably because previousmode comes as kernelmode.

check the parameters ...

[wacked2]

While I agree that perfect security isn't attainable your method can be fooled laughable easily:

Code: Select all

delete_file_mockup:
	; Common prolouge
	mov edi, edi
	push ebp
	mov ebp, esp
	
	; This here simulates your minifilter callback
	call detect_caller
	
	; Commom epilouge
	pop ebp
	ret
	
detect_caller:
	push dword [ebp + 4]
	push formatString ; formatString db 'next instruction of caller: %X', 10, 0
	call [printf]
	add esp, 8
	ret
	
unsuspecting_legitimate_function:
	ret
	
start:
	; call the normal way
	call delete_file_mockup
	
	; call with faked return
	push CODE_RESUMES_HERE
	push unsuspecting_legitimate_function
	jmp delete_file_mockup
CODE_RESUMES_HERE:

So you probably shouldn't do that. Maybe a whitelist with processes that are allowed to delete files would be better?

[EP_X0FF]

@Carlbyte
Do you know that your driver is creating security hole in Windows?
I hope you didn't sell your BSOD-generator.

For your "ultimate wtf task" the correct solution is helper service running in usermode and used in driver<->service communication for such kind of requests. The less your driver contain shits the better it work.

[Vrtule]

ZwQueryVirtualMemory = (pFnZwQueryVirtualMemory)
KeServiceDescriptorTable.ServiceTableBase[ServiceId_NtQueryVirtualMemory]

System service table entries point to NtXxx routines. The difference between them and their ZwXxx variants is that any ZwXxx routine sets access mode to KernelMode and calls corresponding Nt routine. Then, the access mode is returned to the original value (UserMode in your case).

In fact, you are calling NtQueryVirtualMemory and because the access mode (previous mode) is UserMode, the routine expects the output buffer (address of the MEMORY_BASIC_INFORMATION structure) to point to user mode memory. But your MBI structure is in kernel memory, so the routine fails.

[EP_X0FF]

He did this hack few posts above. Well from his quality code I assume it was did wrong too.

[Carlbyte]

In my tests, I tried to create a thread with pscreatesystemthread in driver_entry and fltpreopcallback. see the results

DRIVER_ENTRY(THREADPREVIOUSMODE:KERNELMODE)->PSCREATESYSTEMTHREAD->MYTHREADFUNCTION->ZWQUERYVIRTUALMEMORY
CURRENT PROCESS ID: 4
CTX EBP: A7B39DB8 STACKBASE: A7B3A000
HND: 80000A70 BUFF: A7B39D1C ADDR: 01000000 PREVIOUSMODE: 0
MBI.BaseAddress: 01000000 MBI.AllocationBase: 01000000
MODULO: \Device\HarddiskVolume1\WINDOWS\explorer.exe


FLTPREOPCALLBACK(THREADPREVIOUSMODE:USERMODE)->PSCREATESYSTEMTHREAD->MYTHREADFUNCTION->ZWQUERYVIRTUALMEMORY
CURRENT PROCESS ID: 4
CTX EBP: A7E81DB8 STACKBASE: A7E82000
HND: 80000A58 BUFF: A7E81D90 ADDR: 01000000 PREVIOUSMODE: 0
Exception: c0000005
MBI.BaseAddress: 01000000 MBI.AllocationBase: 00000000
MODULO: (null)

When creating this system thread in the thread "fltpreop", it should work ???