Quote Originally Posted by blabberer View Post
i still dont believe shell and ole ole plays significant role in the process the object is created in R0 with ObCreateObjName & sisters and the handle is created with obpCreateObHandle and brothers does shell and ole send some undocumented DeviceIoControl to ntfs.sys
I know this is getting dated Blabs but I was thinking of opening up my investigation again, albeit temporarily, and I was reviewing the structures I know I'll encounter if I BPX on a file in explorer. Came across this concise but dated explanation of the process:

http://netez.com/2xExplorer/shellFAQ/bg_shell.html

The author explains that parsing a file path had to be extended due to the inclusion of objects that were not file objects, like printers, URLs, and virtual objects like the Desktop, Recycle Bin, etc. For that reason, different objects were given the ability to be opened by conventional means in a file manager. The means of opening them, executing them, printing them, etc., are referred to as verbs, which are defined in the registry. Also, you will find verbs as a parameter in ShellExecuteEx, the main function for processing the paths. As you trace through the code, you encounter Urlmon, which is related to processing URLs.

Of course, when you try to trace through this stuff, it is not going to process just the stuff you want, like opening an executable file. It seems to check and test for every conceivable object that can be opened by a file manager.

In the article, they stick to the convention of referring to an Item ID List, an IDL, as a PIDL, which is totally screwed. Even Microsoft does it. A PIDL is a POINTER to an IDL and a pointer is an address, not a list. To me, it is exceedingly sloppy to use the acronym PIDL in reference to an IDL, especially when you have already claimed that an item ID list is an IDL. A PIDL should be the location at which the IDL is found, not the list itself.

Although Shell and Ole may not play direct roles in the process, you have to get through their code unless you know where to go on the other side. I have tried jumping over the code to reach functions in NTFS.sys only to find the file has already been opened.

I am guessing that somewhere in an IDL, there is a reference to the MFT as an object. In fact, I seem to recall such a reference. Perhaps the MFT is being accessed early in the process as a file object, via Shell and Ole long before NTFS.sys comes into it.

Also, as I have pointed out in the past, there are intervening processes, depending on whether the file has already been moved to a cache. That includes the MFT or parts of it. During initial access to the disk volume, the MFT is moved to a filecache. Of course, it doesn't seem to move the entire MFT to a cache, so even if you end up in a cache, eventually it should go back to disk in order to refill the cache.

To complicate matters even more, Windows has different levels of caching, like WriteBehind caches. It also has search indexing. NTFS also writes to logfiles that are used by Chkdsk to rebuild the MFT should a power fail or crash happen before data from the WriteBehind cache can be written to disk. That's why I turn of that feature on a hard drive, especially when I am tracing.

I have already experienced a BSOD while tracing after which my system would not boot. However, running Chkdsk restored the system.

It's little wonder that mere mortals can make head or tail of the NTFS, especially in the deep code woods.