[Carlbyte]

hi guys,

I'm working on a minifilter in preopcallback with irp_mj_set_information to detect delete files operations. I wonder if anyone knows a way to detect approximately the point where the call to DeleteFile was made. By extracting the thread context, I checked that Eip is always in kernel32.dll. The Ebp I get the top of the stack, is a reference but it is not the exact location. If I have a process that calls a function in a dll and it calls DeleteFile, believe Ebp will be pointing to the process and not for the dll. So I ask, what is the best procedure to detect this?

Thanks

[Carlbyte]

The answer seems to be [EBP + 4] which is return call address. I need to test, do not know if it's the correct answer or the best way of doing this.

[Vrtule]

Hello,

in 32-bit code, many routines start with the following prolog:

Code: Select all

MOV edi, edi
PUSH ebp
MOV ebp, esp

which mean that [EBP] contains old value of the register (saved to stack by the PUSH instruction) and because the prolog is invoked directly after a CALL instruction, [EBP+4] contains the return address.

NtXxx/ZwXxx routines exported by ntdll.dll do not contain this prolog and they are not (AFAIK) modifying the EBP register in any way. That's probably why you are seeing the caller of the DeleteFile function.

I think the method won't work on x64 since these prologs might not be present at all.

What exactly are you trying to accomplish? Why it the detection of DeleteFile calls important for you?

[Carlbyte]

I am creating a minifilter that monitors some windows API and I need to identify exactly what was the file that executed the call to the function. I think the solution can be RtlCaptureStackBackTrace. If you have a better way to do this ...

[Vrtule]

Since the monitored application controls stacks of its thread, it may fill it in a way that totally confuses your minifilter. But yes, the approach may be good enough for monitoring activity of normal application. In case your tools gets famous, your method will be bypassed quite easily I think.

[Carlbyte]

"your method will be bypassed quite easily I think." I think is relative, because any software when analyzed, are discovered their weak points. Someone created a way to prevent piracy to the present day? Anyway... In fact, a dll can use SetThreadContext to make the main thread perform a call to a XXX function, but if I go that way, anything is possible! I'm trying to verify these issues, but ... Thanks for the help.

[Vrtule]

"your method will be bypassed quite easily I think." I think is relative, because any software when analyzed, are discovered their weak points. Someone created a way to prevent piracy to the present day?

That is not entirely true (but well, it seems to be in your case). The problem in your case is that an application can lie to the minifilter. It can say "hey, a DLL named A is attempting to delete a file via the DeleteFile APi call" although a different DLL mapped to application's address space may be the real caller. I do not see a way how to verify that the application is lying (which does not mean such a way exists of course).

I think the piracy problem is quite similar. The software consists of code and data. The code relies on environment its run in. It is hard to detect that the environment is not attempting to trick the software to think it is running legally. Additionally, the code and data can be modified in most cases. It is hard (if not impossible) to build higher levels of security when the "physical" one is broken.

However, if you have a minifilter that just protects certain files from being deleted, no application can bypass you because it always must specify a file to delete and it cannot lie at that point. Of course, we assume that the minifilter has no bugs. Well, the application can modify the minifilter (its file on disk at least) but the minifilter can protect against such a behaviour. And there is that Driver Signature Enforcement mechanism on 64-bit versions of Windows.

----

it is not required to use the SetThreadContext API to do such tricks. All the dark application needs is to save contents of its stack somewhere else and rewrite it (with random values for example). By doing that, the stacktrace is quite useless. Well, you still see the return address for the DeleteFile API but it may point anywhere.

[Carlbyte]

What I mean is just that there are numerous ways to circumvent security systems. Even the DSE already read something about inserting driver, disable it ...

[Vrtule]

What I mean is just that there are numerous ways to circumvent security systems. Even the DSE already read something about inserting driver, disable it ...

Yes, DSE is typically bypassed by utilizing a bug in an already signed driver.

Yes, there are numerous ways how to deal with security. My point was that we should attempt to do it the right way from the start. That's all I wanted to say.

[Carlbyte]

I have another question that is related to this. It's about ZwQueryVirtualMemory function. Whenever I try to make a query in memory of a program, returns C0000005. I've been researching and what I found is that the question comes up of Previous Mode, but did not solve the problem.

FLT_PREOP_CALLBACK
...
ObOpenObjectByPointer (Process, OBJ_INHERIT, NULL, 0, * PsProcessType, ExGetPreviousMode () & HandleProcess);
Note: If the function is called in "DriverEntry" then works normally.
I also tried to attach the stack and not solved ... anyone have any tips?