You are browsing the archive for Reversing.

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.

So…

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.

Bonus

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

Why?

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.

Why?

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>

SQM Process Hashes

February 24, 2019 in Reversing, Undocumented Windows Internals

Today I came across Registry entries that I have not seen being documented anywhere before, so decided to throw a quick & dirty post about it.

One of the less known/understood components of Windows is SQM. SQM stands for “Software Quality Metrics” and I don’t know really more than what I have read from the linked articles, plus general opinions online that this is a part of MS spying machine, so pardon my ignorance.

Today, I was looking at artifacts created by various processes and spotted this intriguing entry:

  • HKLM\Software\Microsoft\SQMClient\Windows\DisabledProcesses\<some hash-like looking value>

Knowing that Windows programmers love hashes, I was curious what this entry is for, and obviously, how to calculate the hash it refers to.

A quick test followed for a couple of popular programs, and I got these results:

Now that I had a few test values, I looked at the code of ntdll.dll (where I eventually traced the code responsible for these callouts to), and quickly discovered the routine. The hash type used here is known as UHash (I googled the constants used by the algorithm, and this is the name of the function that I found).

It basically takes the filename of the process (anything that follows the last directory separator), then iterates through it starting from its end (from a file extension), and then each character is upper-cased (Unicode!), and then added to the UHash formula.

You can see the full algo in a script here.

When ran with example process names as in the screenshot above, we get these values:

  • 494A65DD – powershell.exe
  • 4DA42CDB – calc.exe
  • DA0C75C2 – cscript.exe

The more troubling question is the meaning of it all. This, I frankly don’t know. There are a couple other keys associated with SQM in the same Registry branch e.g. DisabledSessions (under the same node). Googlign around and digging in the ntdll.dll shows that SQM seems to be dependent on Customer Experience settings i.e. CEIPEnable entry described here:

So, I guess the DisabledProcesses / DisabledSession entries could be flags that remove _some_ processes from active SQM monitoring (in a more granular way). And all in all, something that we probably want to completely disable via a higher-level CEIPEnable value, and others in the same location e.g.: