![]() ![]() I initially just used XVI32 to determine at what point the “123456” string appeared in the file data and placed that offset into a variable but I found as I tweaked the filter that I had to keep using XVI32 to see what the offset was which became laborious. To base64 encode a file and place it in the clipboard so that it can be pasted into a script, run the following: ::ToBase64String( ]::ReadAllBytes( 'c:\temp\demo.pmc' ) | Clip.exeĪnd we then paste it into the value of a variable assignment in our script, remembering to place the terminating quote character at the end of what will be a very long line:Īt run time, we can convert this base64 encoded text back to binary data simply by running the following: ]$filter = ::FromBase64String( $procmonFilter ) This fortunately is easy to achieve since we can base64 encode the binary file, which converts it to text that we then just assign to a variable within the script. pmc configuration file embedded within the script itself. pmc file, I had the added complication that this script, because it is run as a Script Based Action ( SBA) by ControlUp’s Real-Time console, needed to be self-contained so had to have the. Whilst it is easy with the procmon GUI to set the filters how you want them and also include or exclude display columns and then save this as a. Dynamically Creating a Configuration File Fortunately I found that procmon was quite happy accepting a PID with leading zeroes such as “000123” so that meant as long as I padded my PID to six digits, procmon would still work. ![]() One potential issue was that PIDs can be between 1 and 6 digits long and I didn’t want to risk changing the size/layout of the file since that may have broken procmon. So my thinking was that I could produce a template configuration file with a placeholder PID of 123456 and then replace that with the actual PID I wanted procmon to trace. Also, the (crudely) highlighted portion shows that there is a Unicode null terminator character (00 00) after the “6” of “123456” followed by the PID in little endian format. This is for information only, it doesn’t cause an issue as we’ll see presently. However, notice that after each ASCII character there is a null (00) – this means that the characters are technically Unicode (16 bit) rather than ASCII (8 bit). Where the selected character is the start of the “123456” PID string. If we look at the area around these differences in a hex editor (I use XVI32 which has served me well for many years), then we get some context and more information: But what about the last 3 bytes which are different? Well, 123456 in hex is 01E290 is 08AA52 which we can see stored in those last 3 different bytes, albeit in little endian format. Which instantly gave me hope that what I was trying to accomplish was achievable since there were only nine differences and being the sad geek that I am from my 6502 hand assembly days on Commodore computers, I already knew that hex 31 is the ASCII code for the number 1, hex 32 is 2 and so on so that the first six rows of the first column were representing the PID 123456 and the second column 567890. exe to the end of the command since “fc” is a built-in alias for the Format-Custom cmdlet which is not what we want to call. Note that when calling this from PowerShell, you must append the. To perform a binary comparison, I used the built-in Windows File Compare utility fc.exe. In terms of the filter parameters they contained, they were identical except one was for a PID of 123456 and the other for a PID 567890, e.g: In order to see if it was feasible to take an existing procmon configuration file containing a PID filter and change it, I performed a binary comparison between two configuration files I had manually saved from the procmon user interface. Isolating the Relevant Section of the Configuration File ![]() I therefore set about trying to figure out how I could add a process id (PID) filter for a specific process via a script and I present the research and relevant script parts here for the benefit of others. Of course, one could run it without a filter but that will make for potentially much larger trace files, which could impact free disk space and performance and would take longer to process in PowerShell. Indeed, web searches showed others looking for ways to dynamically create these configuration files, which contain the filters as well as included columns, but apparently without success. Searching around, I found that the format of a procmon configuration (.pmc) file didn’t appear to be documented anywhere and, being a binary format, could prove tricky, and time-consuming, to fully reverse engineer. I recently had the need to automate the use of SysInternals’ Process Monitor such that no manual intervention is required to initiate the capture, with a filter, and then to process the results, in PowerShell of course. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |