Recently I figured out there are ETW rundown providers that basically allows for enumerating system resources for the purpose of filling the gaps for events that might lack full trace context. For example, Process Hacker uses kernel rundown logger to enumerate all open file objects that other kernel events correlate with in order to get the full file name that's involved in I/O operation. I would like to know if rundown kernel provider is also able to collect other resources (apart from process, threads, images), such as registry keys or system handles?
You could try to use the TdhEnumerateProviderFieldInformation with EventKeywordInformation to retrieve the keyword. And there is also an example on the document.
Related
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 need a two-way communication between a kernel-mode WFP driver and a user-mode application. The driver initiates the communication by passing a URL to the application which then does a categorization of that URL (Entertainment, News, Adult, etc.) and passes that category back to the driver. The driver needs to know the category in the filter function because it may block certain web pages based on that information. I had a thread in the application that was making an I/O request that the driver would complete with the URL and a GUID, and then the application would write the category into the registry under that GUID where the driver would pick it up. Unfortunately, as the driver verifier pointed out, this is unstable because the Zw registry functions have to run at PASSIVE_LEVEL. I was thinking about trying the same thing with mapped memory buffers, but I’m not sure what the interrupt requirements are for that. Also, I thought about lowering the interrupt level before the registry function calls, but I don't know what the side effects of that are.
You just need to have two different kinds of I/O request.
If you're using DeviceIoControl to retrieve the URLs (I think this would be the most suitable method) this is as simple as adding a second I/O control code.
If you're using ReadFile or equivalent, things would normally get a bit messier, but as it happens in this specific case you only have two kinds of operations, one of which is a read (driver->application) and the other of which is a write (application->driver). So you could just use WriteFile to send the reply, including of course the GUID so that the driver can match up your reply to the right query.
Another approach (more similar to your original one) would be to use a shared memory buffer. See this answer for more details. The problem with that idea is that you would either need to use a spinlock (at the cost of system performance and power consumption, and of course not being able to work on a single-core system) or to poll (which is both inefficient and not really suitable for time-sensitive operations).
There is nothing unstable about PASSIVE_LEVEL. Access to registry must be at PASSIVE_LEVEL so it's not possible directly if driver is running at higher IRQL. You can do it by offloading to work item, though. Lowering the IRQL is usually not recommended as it contradicts the OS intentions.
Your protocol indeed sounds somewhat cumbersome and doing a direct app-driver communication is probably preferable. You can find useful information about this here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff554436(v=vs.85).aspx
Since the callouts are at DISPATCH, your processing has to be done either in a worker thread or a DPC, which will allow you to use ZwXXX. You should into inverted callbacks for communication purposes, there's a good document on OSR.
I've just started poking around WFP but it looks like even in the samples that they provide, Microsoft reinject the packets. I haven't looked into it that closely but it seems that they drop the packet and re-inject whenever processed. That would be enough for your use mode engine to make the decision. You should also limit the packet capture to a specific port (80 in your case) so that you don't do extra processing that you don't need.
I'm developing a network-redirector like SMB.
I want to test various file I/O to compare NTFS or SMB implementation.
What I want to test are,
CreateFile
Read, WriteFile
DeleteFile
RenameFile
Set, GetFileInformationByHandle
etc.
And it' would be better if it can measure each I/Os duration.
Is there a program I can use?
If you are developing a file system driver or use some redirector driver (either our Callback File System or alternatives), you can use IFSTest tool to check your implementation for correctness.
XPerf will answer all of these questions, allowing you to see perf at both the file level and the block level. Check out the PDC09 video on the topic at http://www.microsoftpdc.com/2009/CL16
You can use the File Server Capacity Tool (FSCT) provided by Microsoft. It will let you simulate a typical user workload against a file server that supports SMB. The tool can simulate multiple users from a single client and aggregates the results into text files in the end.
You can get more information, including links to download and detailed presentations at http://blogs.technet.com/b/josebda/archive/2009/09/16/file-server-capacity-tool-fsct-1-0-available-for-download.aspx
Usually, when an application writes to one of it's files on disk, the file modified timestamp changes.
Sometimes, and in my case it is an application written in ProvideX (a Business Basic derivative i believe) doing the writing, the modified timestamp does not change after a write. A program like MyTrigger will not pick up on the write operation either, but Sysinternals ProcessMonitor does log the disk activity.
It seems obvious that there are different ways to ask windows to perform write operations, and the request could then be hooked or logged in various different ways as well.
I need to be able to hook the write operations coming from the ProvideX application. Any pointers on the different ways windows writes to disk, and the type of hooks available for them would be greatly appreciated.
Thanks
User-mode process can write to the file either using WriteFile API function or using MMF, memory-mapped file API (CreateFileMapping/MapViewOfFile/Write to memory block). Maybe your application goes MMF way. MMF writes to files very differently from WriteFile API, but they both lead to the same end point - IRP sent to file system driver. File system filter driver (such as the one used by Sysinternals stuff) can track write requests on that IRP level. It is technically possible to distinguish between write operations initiated by MMF and WriteFile as different IRPs are sent (cached and non-cached writing is involved). It seems that directory change monitoring function in windows tracks only one IRP type, and this causes MyTrigger to miss the change.
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.