A story about Procmon (no, not that one – its misbehaving client)

Posted on by

We all love Process Monitor, but what we love even more are its undocumented features.

Checking program’s accepted command line arguments we can quickly discover that it can be called with an option “/client”. When started like this Process Monitor creates a socket and starts listening on port 23219:

Now that we found how to make it listen on port the only thing to do is finding how to talk to it. Ater checking the Window Messaging callback procedure I noticed it includes code to handle message WM_COMMAND with wParam equal to 40072. Code like this is typically executed via Menu, or keyboard accelerators. After inspecting GUI and accelerators table in procmon resources I couldn’t find any way to trigger it. At this stage I have already suspected this is probably a legacy code that has never been removed from the program, so it’s time to play dirty.

There are many ways to trigger execution of the afrementioned code path – we could probably add a new shortcut to accelerator table and recompile the .exe using Resource Hacker. We could write a small snippet of code to find PROCMON_WINDOW_CLASS window and then send the message to it. Or, we can be lazy and use an existing tool to do just that. I chose the latter and used SendMessage64:

You must ensure the program is launched with admin privileges otherwise Procmon won’t be able to receive the window message.

Once we send the message, Procmon will use SHGetSpecialFolderLocation API with CSIDL_NETWORK parameter to allow us to select the computer from our local network:

Once we choose the computer, we will … crash Procmon 🙂

This pretty much confirms the hypothesis it’s a legacy code.

With that, I loaded procmon into xdbg, and made a breakpoint after SHGetSpecialFolderLocation, then checked where the crash happens. It was two hardcoded values <remote system root> and <remote computer name> which (due to lack of GUI) can’t be initialized with proper values. I initialized them manually in memory and while avoiding crash, managed to connect to the host (which in this case was the same box – yes, you can run two Procmon instances simultaneously in this setup).

This is where I hit the wall as this time it’s client Procmon that crashed anyway:

I suspect that a) I should not be running two Procmon instances on the system or b) the code is broken and it’s a miracle we got that far anyway or c) I have no idea 🙂

Still, in theory you should be able to connect to the client w/o crashing it. The only remaining bit is the protocol which may be a bit time-consuming to crack.

Excellent Conversions (and downloads)

Posted on by

This one was on a back burner for a while too.

C:\Program Files*\Microsoft Office\root\Office*\excelcnv.exe is a program that helps to convert various documents to XLSX format. While playing around with it I noticed it accepts URLs hence you can use it to download stuff from the internet. The caveat is that this downloaded data will be stored inside a UTF8-encoded stream embedded inside the XLSX Zip archive.

Example binary data (favicon.ico):

and data downloaded as a stream:

The command line arguments for excelcnv.exe are not documented well. Many examples online refer to “-oice” argument followed by the input and output file names. That’s it. And yeah, this actually works, so since I have already mentioned that input parameter can be an URL, the downloader invocation can be as follows:

excelcnv.exe -oice <URL> <OUPUT>

Still, there is more to discover.

For instance, what the heck is ‘oice’? After googling around I eventually discovered it stands for Office Isolated Conversion Environment.

Other interesting stuff to look at are other, undocumented command line arguments used by excelcnv.exe – these I found so far are as follows:

  • -oics – don’t know how it is being used at the moment
  • -bcs – you can use it to convert INPUT file to .ods e.g.
    • excelcnv.exe -bcs <XLSX> <ODS>
  • -repair
  • -o – orientation (for PDF)
  • -ps – paper size (for PDF)
  • -dps – default paper size (for PDF)
  • -scl – scaling option (for PDF)
  • -wtp – what to print (for PDF)
  • -preview – preview quality (for PDF)
  • -pofo – automatic print on file open (for PDF)
  • -nafap – use named action setting (for PDF)
  • -pglim – page limit (for PDF)
  • -rv – unknown (for PDF)

There are probably more, but this is what I explored so far.

The default OUTPUT file type is XLSX. The file format can be changed using a dedicated file extension accepted by the program:

  • .xltx
  • .xlam
  • .xlsm
  • .ods
  • .xls*
  • .pdf
  • .xlsx
  • .png
  • .jpg

but not sure yet how to use all of them as not all of them worked for me (good news is that all the *.xl* work well with “-oice” command).