e.g. hook a write file api so that every process write file must through my function's filter.
I only know a hook function SetWindowsHookEx but so sad it only hook for global key events.
Not from user mode but you can in kernel mode with a file system filter driver. There's a new model, the Filter Manager Model, which reduces the complexity of developing a file system filter driver. See "Filter Manager and Minifilter Driver Architecture" in the MSDN.
Related
As the title says, how is this possible? Basically I want to intercept calls from NetShareEnum function same way as one would intercept calls to ReadDirectoryChangesW via IRP_MJ_DIRECTORY_CONTROL pre/post routines. Is filesystem minifilter enough for the task? Is there a major/minor function to register pre/post callbacks?
NetShareEnum is not file system operation.
I think it's impossible with file system minifilter driver.
i would like to systemwide hook CreateProcessEx
it is redirects all windows calls into my wrapper function
where I will log names to textfile then call oruginal CreateProcessEx
Can it be easy and safely done ?
I would like hook all systemwide calls to it but not etternaly
for some period of time only.. How to do it?
If I will find the adress of this api call in ram then overvrite
it with call to my procedure, how then I will call the oryginal
function if there it is somewhat corrupted?
Hooking CreateProcess is the wrong approach for a few reasons. There is an approved mechanism for doing this sort of thing but you need a driver to be loaded. Your driver can then simply leverage the PsSetCreateProcessNotifyRoutine function.
With that said, would your needs not be served by using the auditing functionality built into Windows? Turning on process creation auditing will cause the system to write an event log entry whenever a process is created, detailing plenty of information about the process being started, including the image path.
CreateProcessEx() is a user-mode function. You have to patch it on a per-process basis. That means creating a DLL that is injected into every running process, such as by using SetWindowsHookEx() or the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs Registry key, and then have that DLL patch the PE Imports table of every process it is loaded into.
I want to hook the usersendinput and userpostmessage hooking in windows 7.It didnt export by SSDT.So I am unable to accomplish this via SSDT hooking.I want to write my own api handler for these api .How can I accomplish this?SSDT shadow hooking is possible or any other way to hook this?
First you must get address of SSDT Shadow.
Next get all handles in the system and iterate over all handles to get PID of csrss.exe.
Attach to csrss.exe process, get system calls indexes (for example from this - WIN32K.sys system call table and replace original system functions with your functions.
I may post example, but I dont have Windows 7 machine to test.
I'm developing a driver that hooks some functions in windows (hardening driver that will block some actions). The problem is, that I want to log which was the user who attempted to run those actions.
For example, I've put an hook on ZwSetValueKey in order to filter registry writing.
The hook works perfectly, But I don't know how to get the caller SID. I've found out that I can determine whether the mode of the caller(i.e. user mode or kernel mode) using ExGetPreviousMode. But I'm not really sure how to determine the SID if the caller was in user mode.
Thanks.
If this were user mode, you'd start with GetCurrentProcess or GetCurrentThread, and then call GetProcessToken or GetThreadToken. This would get you an access token, from which the SID can be extracted directly. In kernel model, there's PsGetCurrentProcess and ZwOpenProcessTokenEx, and the like for threads.
Here's the equivalent question for user space: How to get Calling-Process Windows User Access Token.
I haven't tested this, but I hope it gets you started.
VOID SeCaptureSubjectContext(Out PSECURITY_SUBJECT_CONTEXT) is probably the kernel-mode API you're looking for, at least if you have ntifs.h available.
we're shipping a shell extension dll (registered with regsvr32).
is there an easy way to get debug output from this dll from another application (so we can send these traces home when something is broken)?
any ideas? what's the easiest way to get logdata from the dll to another process?
If it's a shell extension DLL, then doesn't it run as the logged-in user, and can't it therefore write to a log file in some suitable directory on disk? If so why then would you want it to write to another process?
You can use Event Tracing for Windows (ETW) to trace your extension DLL execution. ETW has almost no overhead when no listener is active, so in normal conditions your DLL will incur no perf penalty; at the same time it allows for detailed output at various levels of details.
The way ETW works is when the APIs are called, they check if there is a listener subscribed to the traces from particular publisher and if no, nothing is generated. If there is a listener, only the traces to which the listener is subscribed are written to a memory-mapped file. Thus, only as much traces data is generated as requested.
ETW listeners can be activated at any time and the publisher does not have to be restarted. Also, ETW is not flavor bound and can be used in both debug and retail. Thus, if a customer of yours has a problem, you have to only send them the listener with instructions on how to run it and collect the info; you don't have to sent them an instrumented binary version. You can either write your own app that acts as a listener, or you can use the standard tracelog.exe and tracefmt.exe tools to get the traces written to a file.
To generate the necessary ETW code in your DLL, you can use the WPP preprocesor instead of directly using the ETW APIs.
Note: While all the links I post here are to the Windows Driver Kit documentation, ETW and WPP can be (and are heavily) used for regular user mode programs.