Category Archives: Living off the land

Squirrel packages’ manager as a lolbin (a.k.a. many Electron apps are lolbins by default)

Posted on by

A week ago, or so I posted this Twit that refers to Slack’s executables as lolbins… I have already posted about it last year – the Slack’s update.exe is a nice lolbin, because it’s actually a Squirrel packages’ manager in disguise. A side effect of using Electron.

I was wondering if this is a common pattern, and if Slack is the only software producer that relies on this software paradigm. Right… yeah, I know, the paradigm sounds very academic and serious, but it’s just about software development frameworks, file naming, their final placement on the user’s system, their behavior, and in the end… what you get from a command line when you run update.exe /?. Or something along these lines if the software authors relied on the same Electron framework as the one Slack did , and as my Twit shown – it was deemed to be ‘Lolbinish’.

So, before we go any further, here’s is a TL; DR; for you – run this on your (test/targeted) system:

C:\Users>dir /a/b/s update.exe

This will give you a list of potential candidates of programs that may in fact be wrappers of Squirrel packages’ manager.

Once you run the cherry-picked update.exe you will typically get this banner:

Usage: Squirrel.exe command [OPTS]
   Manages Squirrel packages
[...]

– and… yup… you can use it as a Lolbin as described in my Twit and last year’s post:

  • %USERPROFILE%\AppData\Local\<app>\update.exe –processStart “test.exe” (where test.exe must be placed in a app-* subfolder)

You can not only run programs via proxy, but also e.g. create shortcuts:

  • %USERPROFILE%\AppData\Local\<app> \update.exe –createShortcut -l <parameters> e.g.:
    • %USERPROFILE%\AppData\Local\slack\update.exe –createShortcut c:\WINDOWS\system32\mspaint.exe -l Desktop,StartMenu

After googling around, I can confirm that there are more apps placing update.exe on user’s systems, including, but not limited to:

I bet there is more. I bet there will be more in the future, because Electron is a popular framework for the current app ecosystem that wants to deliver to Windows, Linux, OSX at the same time.

When you browse the https://electronjs.org/ web site, you can find references to many applications built using this framework:

  • 1Clipboard
  • Atom
  • Beaker Browser
  • Caret
  • Collectie
  • Discord
  • Figma
  • Flow
  • Ghost
  • GitHub Desktop
  • GitKraken
  • Hyper
  • Insomnia
  • JIBO
  • Kap
  • Kitematic
  • Now Desktop
  • Simplenote
  • Skype
  • Slack
  • Svgsus
  • WebTorrent
  • WordPress.com

Also, in some cases the update.exe doesn’t produce any output if ran w/o any command line (e.g. when you run Discord). In such case you can just blindly try Update.exe –processStart <file_inside_the_app_folder>. I can confirm it still works and launches the program of our choice. Your mileage for other Electron apps may vary.

All in all, not a big deal, but good to know about. Both on a blue and red team side of the puzzle.

Dictionary files (.dctx)

Posted on by

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>