Code: Select all
!gflag +ksl sxe ld app.exe g r $proc .process bp /p @$proc nt!NtMapViewOfSection g bp0 /p @$proc ntdll!RtlUserThreadStart g
Either way I can normally break at the start of a usermode process remotely without too much problem, including cmd.exe. However I'm not sure how to extend that to a command line process such as strings, findstr, dir, etc. In Win7 a command window by itself runs as the process cmd.exe. In Win10 there is also a child process conhost.exe involved.
As to why I'm interested in tracing Strings64, in another thread we discussed how if you pipe the output to a file it will pick up the logfile as a search file and can lead to a recursive unending search if any results have been written to the logfile. The solution I found was that the logfile MUST be named alphabetically so it is the very first file found in the search directory, that way it will be empty when Strings opens it for searching, then closed for good and not lead to recursive results.
Using Procmon I determined that Strings uses FindFirstFile / FindNextFile, a standard routine for listing files in a directory. This led to wondering what character is "first" in a sorted list of filenames. It turns out that the alphabetical sort order you see in Explorer is different from the sort order yielded by FindFirstFile. The definition for the API states that the order in which the function returns the file names is dependent on the file system type, NTFS vs FAT for example.
This is further explained in a blog post by Raymond Chen where it is revealed that NTFS captures the case mapping table at the time the drive is formatted
Why do NTFS and Explorer disagree on filename sorting?
https://devblogs.microsoft.com/oldnewth ... 0/?p=35293
I suspected that this case mapping table might be what is defined in the NTFS Master File Table ($MFT) as the $UpCase metadata. Using 7-Zip, of all things, I was able to dump the $UpCase metadata and sure enough it seems to match the exact alphabetical order of filenames returned by FindFirstFile / FindNextFile.
Here is the method of accessing $MFT using 7-Zip
Attached is a screenshot of $UpCase opened in HxD. The first usable alphabetical character for filenames is "!", the last (after regular letters) is "~". This matches all the tests I did using Procmon to monitor Strings Query Directory results of filenames.
Finally, Procmon points to FindFirstFile eventually leading to FLTMGR.SYS being involved where I was wondering if it was possible to actually see the $MFT being accessed through code, that being the bottom line of all this.
I could of course just make a gui app that uses FindFirstFile / FindNextFile and trace into it that way, but I'm still wondering how to remotely debug a command line process with my usual Windbg setup.