Total Commander Plugins & Their Automated Installation
May 12, 2019 in Clustering, File Formats ZOO, Forensic Analysis, Malware Analysis
Total Commander (TC) and its Plug-ins are floating on the internet for a veeeery long time. As such, most of what I describe below is most likely known to many people. However, as it is with everything, it’s always good to just describe stuff from a DF/IR angle, especially to ppl who never used or came across this program itself or a very specific subset of its features.
And since this post is about TC, I must say for the millionth time that if you use Windows Explorer as your goto File Manager you are hurting yourself a lot. Once you try TC, FAR, or any type of the Orthodox File Managers, there is no way back. It’s worth every single eurocent you have to pay for it. Btw. I am not paid to endorse this software, I just love it and recommend it to anyone who wants to be more efficient.
Like many other popular programs TC supports plug-ins. There are many of these, they are often pretty cool and they add a lot of extra features to this awesome program e.g. handling of additional file types, direct access to Registry, additional archiving options, etc. Some examples can be found here. The page I linked to also includes a number of .chm files (search for a ‘guide’ keyword) that describe how to build your own plug-ins.
The topic of this post is not TC or its plug-ins coding though. At least not directly.
What I want to mention is this: the plug-ins support a mechanism that author of TC calls a ‘Plugins Automated Installation’. The idea is pretty straightforward – any common archive that TC opens/sees that has the ‘pluginst.inf’ file present inside the archive will make TC recognize the file as a possible TC Plug-in. This is actually a very handy auto-install method and I personally used it a number of times in the past.
When one opens such archive in TC, the following windows may appear:
Or
These messages come from the pluginst.inf file itself. The structure of the file is like any other standard .ini file, plus it needs these section bits to be defined:
[plugininstall]
description = description in English
description<lngcode> = description in the language identified by <lngcode>
type=<type>
file=<filename>
defaultdir=<path>
defaultextension=<extension>
The type determines what plug-in it is. The available types are: wcx, wfx, wlx or wdx or lng. Additionally the plug-ins may include files with a .mnu or .bar file extension + various misc. files that support its work.
Here’s a quick break down of what these file extensions are associated with:
- WCX – New Archive formats.
- WDX – New columns (properties) for items.
- WLX – Lister plug-ins
- WFX – New file systems (e.g. extX)
- LNG – Language files
- MNU + BAR + INI – Menu files
That’s it really.
While interaction is required to install these, it’s always better to be safe than sorry. For this reason, it is perhaps worth blocking these file extensions on the email gateway. I actually added them to my old post about file extensions of interest for exactly this reason.
It is also a handy way to use the presence of pluginst.inf inside the compressed files (note: doesn’t need to be .zip; 7z works too!) to properly identify archive file subtype.