I need to get some information that is contained in the MFT on a Windows machine, and I'm hoping that there is some super-secret API for getting this information. I need to be able to get to this information programmatically, and because of legal concerns I might not be able to use the tools provided by the company formally known as sysinternals.
My other option (which I really don't want to have to do) is to get the start sector of the MFT with DeviceIoControl, and manually parse through the information.
Anyway, in particular, what I really need to get out of the Master File Table is the logical sectors used to hold the data that is associated with a file.
There is a documented API for getting info on file positions on disk since Windows 2000. Look for DeviceIoControl function with FSCTL_GET_RETRIEVAL_POINTERS control code on MSDN:
http://msdn.microsoft.com/en-us/library/aa364572(VS.85).aspx
The API has been provided for writing custom disk defragmenters and consists of several other control codes.
Related
Per Wikipedia and other resources such as Windows Internals book, the SCM gets the data it presents in Services.exe by reading HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\List and HKLM\SYSTEM\CurrentControlSet\Services.
When you try to create your own process using sc command, the data in the registry seems to match the data you entered. When you cross the data seen in SCM's Services.exe tool, there is a lot of data I couldn't find elsewhere in the system.
For example, Eaphost.
Its display name in Services.exe says "Extensible Authentication Protocol" and it has a really long and descriptive description:
When you look in registry, you get the following, which shows a Description and DisplayName values that look more as a command rather than something else.
It's of course not only in the mentioned service, but in others also.
So, where does the SCM gets the rest of its data?
Is there any source to find details of each field in _EPROCESS structure? I'm working on a VM introspection project where I try to get detailed information of each running process. I can read the data for each fields but I don't really know what those fields represent. I couldn't find any link explaining those fields, probably because Windows being a closed source OS.
I understand that I might not be able to find details of each and every fields but it would really help me if I can get at least some of them.
EPROCESS is a structure very internal to the operating system kernel and changes quite a lot accross individual Windows versions. That's another reason why it is not documented. It would be probably better if you write down the fields you are interested in. Maybe, somebody would know their meaning. In some cases, the meaning can be guessed from their names.
Keep also in mind that access to certain fields may be synchronized via a lock so you may receive inconsistend data when reading them without acquiring the lock.
If you are interested in information that is available via certain kernel API (e.g. PSXxx routines), you can reverse the API and decode their references into EPROCESS and other structures.
I'm looking for a feature similar to CreateNamedPipe on Windows, which would allow programmatically generating file contents on demand. However, it would need to support seek operation as well, so plain named piped will not work, I think. Or does it?
Some details: The file will be read by other existing program, and changing that is not possible in this case. The two specific uses are: 1. the actual data is in a compressed binary blob. 2. the actual data is behind a network connection, accessed with a custom protocol. In both cases, the "virtual" file would give access to date as if it were a local regular file.
I'm sure this would be possible at least by creating a custom file system device driver, or using existing network file system and creating custom server program. But this sounds like very complex (is it?) and not worth the effort.
So, any practical efficient solution, other than just storing the data to regular temp file?
You need to write a kernel device driver, or take advantage of one of the existing user mode device driver frameworks, such as UMDF. You can start reading up on that on Wikipedia.
Windows Resource Monitor displays (among other things) which files on disk are currently accessed by which processes. And it does that in realtime. How?
I know that it probably uses ETW and that I can generate traces with tools like xperf. But how to get realtime information without having to start, stop and parse a trace file?
I need to programmatically access the data, i.e. from C# or C++.
wOpenTrace/ProcessTrace/StopTrace can get the data in real-time as long as you know the provider GUID. They can run on Win2000 but you need to parse the raw data in your callback functions. To convert raw data into human-readable text, we need the TMF/MOF. Not sure if they are public though.
For Vista/Win7, there is a new set of TDH (Trace Data Helper) APIs (eg: TdhFormatProperty).
Scroll down a little of above links and you can see them. The good thing about TDH is they can parse the data for you (still need to provide TDH the TMF/MOF though).
I tried to write my own .etl to readable .txt program using Open/Process/StopTrace API (because I need to support XP). I found out it's quite difficult. The TMF file is not hard to interpret since it pure text. The hard thing is to decipher more than 50 different undocumented prinf-alike format-specifications' internal structures. So I gave up in the end and stick to the powerful tracefmt.exe provided in Microsoft WDK.
I want to store some information in the EPROCESS structure of the process in windows NT kernel. My aim is that when winlogon is called I want to assign a unique value to the next process based on which user logs in. But I do not know where to store this unique ID. I have tried and succeeded in modifying some information (like the tokens) in the EPROCESS block of a process by the method of Direct kernel object modification and I wonder if there is any structure in this EPROCESS block where some other information can be stored.
p.s. For modifying the EPROCESS block I used a device driver.
The EPROCESS structure is opaque and undocumented, meaning you shouldn't be messing with its internals. Doing so requires you, among other things, to test on every OS version and service pack you plan on supporting.
Do not modify EPROCESS. It will bring you great sorrow.
Furthermore, if you do, do not install it on anyone elses machine. It is absolutely wrong to impose such a profoundly damaging, system destabilizing change on another persons computer. How would like it if I gave you tuberculosis?