You are browsing the archive for Reversing.

cmd.exe running any file no matter what extension

April 21, 2019 in Archaeology, Reversing

I remember seeing a Tweet (long time ago) where someone was demo-ing that you you can execute any program, no matter what file extension, by simply providing a path to it from a cmd.exe shell and hitting enter.

It works.

All you have to do is type a file name in a current directory, or a full path reference and hit enter – the file, as long as it is a PE exe, will simply execute.

Pause for a moment to reflect on some funny side effects that come with this feature.

Your .exe can have any file extension. You can rename your .exe to ‘Red squirrel population dynamics – data set 2019.xlsx’, or ‘My novel that will be better than Stephen King.docx’, and launch it from cmd.exe without launching Excel or Word in the end, as one might expect. You can also pass these file names to other instance of cmd.exe via ‘/C’ argument and I bet anyone seeing it will think you are into squirrel data crunching, or writing the new Netflix TV Series.

You could even create a file:

  • c:\Program Files\Microsoft Office 15\root\office15\WINWORD.EXE foo.doc

– it could mislead some EDRs or analysts.

Back to that original Tweet – at that time I got curious and had a quick look at cmd.exe code. I quickly discovered that it always take a stab at CreateProcess API first. That is, it just tries to execute the existing file, if possible. This is unlike Windows Explorer that primarily relies on ShellExecute* APIs – and these do rely on file extensions.

Okay, so I did that quick research long time ago and thought this is the end of the story.

Until I saw this post from Mitja wondering about the very same issue in a context of a very interesting (and kinda first in its own genre /due to HIPAA legal implications/) research from Cylera by D00RT_RM.

Of course, once I saw Mitja’s post I reacted with a knee-jerk reply that stated what I discovered in the past.


Mitja came back with an observation that there must be more to this, because you can still launch a text file in a Notepad if you just type the name of a text file inside the cmd.exe shell and hit Enter.

This got me curious again, and after a few more IDA screens and some dynamic testing I discovered that Mitja was right, and the way cmd.exe executes stuff is indeed a bit twisted.

The behavior of cmd.exe depends on the value of this Registry entry:

  • HKCU\Software\Microsoft\Command Processor\EnableExtensions

If this value is zero (extensions disabled), the cmd.exe will run the file path via CreateProcess only; if it fails, we will see a message ‘<filename> is not a valid Win32 application.’:

If the value is 1 though (default since Windows XP), the cmd.exe will first attempt to execute the file via CreateProcess, and if it fails (only ERROR_BAD_EXE_FORMAT or ERROR_ELEVATION_REQUIRED errors are handled), it will pass the path to ShellExecuteWorker API that in turn will execute ShellExecuteEx — in the end mimicking the way Windows Explorer ‘opens’ files.

I think it’s a good option and probably an expected User Interface behavior, but it does make for a curiosity that is worth knowing about.

And I really liked that this second take at the research happened, because:

  • Mitja provided a feedback to my earlier research
  • This in turn triggered my further research
  • This in turn made this post possible

So, the lesson learned is: always work under assumption that your knowledge is incomplete and can be always improved. The feedback and back and forth on Twitter has proven many times to me how useful the feedback and technical convos are, and let’s hope there will be more of it in the future. Thanks Mitja!

Dictionary files (.dctx)

March 9, 2019 in Archaeology, IME, Living off the land, Random ideas, Research fails, Reversing

This is not a very important research really. Just a ‘blurb’ of what I observed during my quick tests.


First of all, I noticed that .dctx files are being handled by this program:

  • C:\Windows\System32\IME\shared\IMEWDBLD.EXE

These are dictionary files (source) and are compiled to some other binary format (.dctc AFAICT). These dictionaries seem to be heavily used (and needed?) for Asian languages, so most of info on them can be found online on forums discussing Japanese and Chinese language keyboard input.

Examples: here, and here.

When you open a .dctx file on Windows 10 you will be presented with this dialog box:

When we click OK, we will see another dialog box:

I have not figured out what that means, but it seems to be a highly prevalent error and many users report it. I couldn’t bypass it despite toying around with various parameters embedded inside my test .dctx file. I tried to use variations of English language (US vs. UK), different encoding, etc., but it always comes back with the same error.

Also, after looking at IMEWDBLD.EXE, I noticed that it takes a -v <logfile> command line argument (where -v stands for -verbose, I guess). Using it during testing is a better alternative to that non-descriptive dialog box shown above. After trying to open the very same .dctx with IMEWDBLD.EXE and -v flag enabled I observed this in the ouput of the log file:

Error: Encountered fatal error(0x80070057:The parameter is incorrect.).
Error: There is a problem with the dictionary file. Please try to download again.

Unfortunately, this error is very prevalent inside the binary (IMEWDBLD.EXE), so I didn’t spend too much time trying to figure it out. Okay, if you must know, 0x80070057 stands for an invalid argument. Would be really handy to know which argument triggered it… hmm…..

So, that’s it really.

If you want to play around, this is a minimalistic sample .dctx file you can try to import on your Windows 10 system. Download, and double click. That’s it.


I think the IME components are not very well researched and can potentially offer mechanisms that will allow for less-known attacks focused on:

  • persistence
  • bypassing security controls
  • RCE


They seem to be developed for a niche (but not negligible due to number!) group of users in Asia (Japanese, Chinese), and most likely have been poorly tested. The last IME-related research I could find is here.


If you look at IMEWDBLD.EXE binary you will notice a bunch of flags that are not documented anywhere on the internet. Hence, they could be limited to a test environment at MS, or only taken into account on OS versions that require IME. The lower the scope, the lower the testing priority. A.K.A. if it is not documented on the Internet, then it’s likely internal.

Some food for a thought:

  • HKLM\SOFTWARE\Microsoft\IME\PlugInDict
  • EncryptAllPlugInDict
  • DisableAllPlugInDict

Command line arguments for IMEWDBLD.EXE:

  • -encrypt <unknown>
  • -pluginguid <guid>
  • -w <unknown>
  • -pm <unknown>
  • -v <logfile> – saves the verbose info to logfile
  • -nofilter <unknown>
  • -testing <unknown>