Process Monitor and Explorer are supplied an EXE file.
But they include a driver. -Where is it.
By Windows Internals,
Process Monitor works by extracting a file system filter device driver from its executable
image (Procmon.exe) the first time you run it after a boot, installing the driver in memory, and then deleting the driver image from disk.
I would like to know the detail mechanism.
Are there some codes about that? Where can I find them.
Or could you explain me this.
Thanks.
Last time I looked it was just embedded into the executable as a resource. You can use something like Resource Hacker to see it. I guess when the process starts it extracts the driver from the resource section and installs it.
Executable file in Windows may contain among other things "resource" section. It may contain any binary data, which executable may access at run-time.
The trick is to put the whole other executable (the SYS file of the driver for instance) inside an EXE during the link time. Then at runtime the EXE extract this into a SYS file.
Then this driver may be loaded on-the-fly (using SC-manager)
Related
I have a library that has a file based interface (it only accept file names/paths).
Since the operations are time critical i would like to load the file to memory.
Is there a way to create create in-memory files that have a file path that is resolvable with the normal file access routines?
For example many programs still work if they get some win32 device path or an UNC path instead of a 'classic' windows path.
or maybe if that is not the case maybe a softlink can be used to map it into 'normal' filesystem.
One obvious way would be to use some ramdisk software but this would require further manual steps and also requires to tell the program the ramdisks letter.
Suppose I have some files removed (or probably moved or renamed) in a Windows machine. Now I would like to find out what process removes/moves them. How can I do it?
Assuming that you need this in code, the only option is to have a filesystem filter driver intercept the requests and capture the information you need. Our CallbackFilter product lets one do this in user-mode (the driver is included).
Other options (not in code) are enable audit on the files in question and use ProcMon tool (Process Monitor by Sysinternals) to monitor the files.
I have two questions, both are them may be related so I am asking at once.
Linux has /proc directory which is runtime data structure and gives information about running process. Does windows have any such directory where I can get runtime info about process, like its layout and open handles. Please do no suggest tools like Process Explorer, its good but they are not part of core windows os.
Secondly, it is said for Windows that not everything is file, like socket is not a file. Does it mean that it is not a sort of file you can see in your hard disk but a runtime it creates file and in proc like data structure it has some entry.
Thanks.
While Windows has the ability to create virtual files (device drivers use this), there are no such files for process information.
Information about processes is available either through the process functions, the undocumented functions used by Process Explorer, or not at all.
Not every file is stored on some disk.
Virtual files are essentially just some value in memory, or some callback function that generates the file contents dynamically when you're trying to read it.
I want to put some sort of "hook" into windows (only has to work on Windows Server 2008 R2 and above) which when I ask for a file on disk and it's not there it then requests it from a web server and caches it locally.
The files are immutable and have unique file names.
The application which is trying to open these files is written in C and just opens a file using the operating system in the normal way. Say it calls OpenFile asking for c:\scripts\1234.12.script, and that is there then it will just open it normally. If then it asks for c:\scripts\1234.13.script and it isn't then my hook in the operating system will then go and ask my web service for the file, download it and then return that file as it it were there all the time.
I'd prefer to write this as a usermode process (I've never written a windows driver), it should only fire when files are not found in a specific folder, and I'd prefer if possible to write it in a managed language (C# would be perfect). The files are small (< 50kB) and the web service is fast and the internet connection blinding so I'm not expecting it to take more than a second to download the file.
My question is - where do I start looking for information about this kind of thing? And if anyone has done anything similar - do you know what options I have (eg can it be done in C#?)?
You would need to create a kernel-mode filesystem filter driver which would intercept requests for opening such files and would "fake" those files. I should say that this is a very complicated task even for driver development. Our CallbackFilter product would be able to solve your problem however mechanism for "faking" files is not yet ready (we plan this feature for CallbackFilter 3). Until then I don't know any user-mode solutions (frankly speaking, no kernel-mode solutions as well) that would solve your problem.
If you can change the folder the application is accessing, then you can create a virtual file system and map it to the drive letter or a folder on NTFS drive. From the virtual file system you can direct most requests to/from real disk and if the file doesn't exist, you can download the file and cache it. Our other product, Callback File System, lets you do what I described in user-mode. If you have a one-time task you need to accomplish, and don't have a budget for it, please contact us anyway and maybe we can find some solution. There also exists an open-source solution with similar (but not so comprehensive) functionality named Dokan, yet I will refrain from commenting on its quality.
You can also try Dokan , it open source and you can check its discussion group for question and guides.
So a .exe file is a file that can be executed by windows, but what exactly does it contain? Assembly language that's processor specific? Or some sort of intermediate statement that's recognized by windows which turns it into assembly for a specific processor? What exactly does windows do with the file when it "executes" it?
MSDN has an article "An In-Depth Look into the Win32 Portable Executable File Format" that describes the structure of an executable file.
Basically, a .exe contains several blobs of data and instructions on how they should be loaded into memory. Some of these sections happen to contain machine code that can be executed (other sections contain program data, resources, relocation information, import information, etc.)
I suggest you get a copy of Windows Internals for a full description of what happens when you run an exe.
For a native executable, the machine code is platform specific. The .exe's header indicates what platform the .exe is for.
When running a native .exe the following happens (grossly simplified):
A process object is created.
The exe file is read into that process's memory. Different sections of the .exe (code, data, etc.) are mapped in separately and given different permissions (code is execute, data is read/write, constants are read-only).
Relocations occur in the .exe (addresses get patched if the .exe was not loaded at its preferred address.)
The import table is walked and dependent DLL's are loaded.
DLL's are mapped in a similar method to .exe's, with relocations occuring and their dependent DLL's being loaded. Imported functions from DLL's are resolved.
The process starts execution at an initial stub in NTDLL.
The initial loader stub runs the entry points for each DLL, and then jumps to the entry point of the .exe.
Managed executables contain MSIL (Microsoft Intermediate Language) and may be compiled so they can target any CPU that the CLR supports. I am not that familiar with the inner workings of the CLR loader (what native code initially runs to boot strap the CLR and start interpreting the MSIL) - perhaps someone else can elaborate on that.
I can tell you what the first two bytes in .exe files contain - 'MZ'. i mean the characters 'MZ'.
It actually represents: Mark Zbikowski. The guy who designed the exe file format.
http://en.wikipedia.org/wiki/Mark_Zbikowski
1's and 0's!
This wikipedia link will give you all the info you need on the Portable Executable format used for Windows applications.
An EXE file is really a type of file known as a Portable Executable. It contains binary data, which can be read by the processor and executed (essentially x86 instructions.) There's also a lot of header data and other miscellaneous content. The actual executable code is located in a section called .text, and is stored as machine instructions (processor specific). This code (as well as other parts of the .EXE) are put into memory, and the CPU is sent to it, where it starts executing. (Note that there's much more interfaces actually happening; this is a simplified explanation).