You are browsing the archive for Research fails.

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>

I fought the Autoruns, and Autoruns won…

December 16, 2018 in Research fails

One of the less visible aspects of security research are constant failures. Anyone who ‘pokes around’ fails a lot. I covered some of my research fails in the past, so in a humble attempt to continue this tradition I am writing another quick post about… well… yet another fail.

The test I came up with was based on the following:
– Anytime you disable an autorun entry, it is being removed from the startup location, and migrated to the ‘AutorunsDisabled’ bucket – either created as a Registry key or a Folder

– I thought, what if I create an entry, mark it as disabled in Autoruns (forcing it to be moved to the ‘AutorunsDisabled’ bucket), and then re-add it in the same place. Without reverse-engineering the Autoruns I was hypothesizing there is a possibility that a presence of ‘AutorunsDisabled’ Registry key, or respective Folder will prevent Autoruns from displaying the entry in Autoruns, or will somehow affect the logic of this display.

I was wrong. A quick test confirmed that when both entries are present, Autoruns simply displays them all:

I fought the Autoruns, and Autoruns won…