Can Windows Theme files (aero.msstyles) be sideloaded with spyware in their resources, specifically in UI scripts

Question

Short version: topic

Detailed version:

I want to use a specific 3rd party theme for Windows. I'm already using an open source solution which I've compiled myself to disable Window's restriction on Themes.

In the past, when using 3rd party theme related mods that come with DLLs (for example authui.dll for the login ui, or imageres.dll for modding system icons), I avoid using unknown DLLs by simply copying the unknown DLL's theme related resources (such as Bitmaps, Icon groups or UI scripts) unto it's virgin MS Dll counterpart. I call this resource grafting, where resource are changed but the executable elements of DLLs or exes are left alone.

Going back to the theme I want to install, I used sha256 hashing to determine that only aero.msstyles which is also modifiable by resource hacker. So I did the same thing I usually do and transferred resources from the third party theme to Window's own aero.msstyles. Problem is that I ran into a type of resource that I am unable to read or know the contents of. It's called VARIANT. From some experiments done in a VM, it seems to be some kind of binary UI script that resource hacker is unable to decompile. I usually like to be able to read any UI scripts that I transfer but I am unable to do so with this one.

Would this constitute any real security risks? Can UI scripts be side-loaded with some kind of exploit? Seems unlikely to me since the function of a theme file (msstyle) is to coordinate the appearance of the system UI but I don't know enough about the inner working of the whole theming system to be sure. I thought I'd get some other point of views before I take the theme out of the Virtual Machine.

Answer 1

I used vBinDiff to compare the hex code the altered VARIANT/NORMAL binary to that of the original theme. You can also copy the binhexes and save them to two text files which you would compare with WinMerge.

vBinDiff and WinMerge will highlight what modifications and what additions/substractions were made to the binaries, displaying them side by side. I read through the differences, 90% of them were no larger than 4 octals (4bytes), typically what you would expect to see when modding colors using a hex editor. The biggest divergence was an added 32bytes of code.

There are two possible explanations for the such an addition: (1) the author added extra image resources and added the entries necessary to reference them, (2) there is some kind of unwanted code that has been slipped in.

To address the possibility of 2, I did a search to see how small trojan code can get. How likely is it that a trojan has been stuffed into 32bytes if compiled UI scripts? I found a few mentions of an old 17byte virus from the DOS era called trivial which I disegarded right away because it would become apparent very quickly given it's known behavior. As far as full fledged trojans with backdoor and downloading abilities, the smallest I found was 20kb (trojan tinba), discovered in 2012. There is also Catchy32 which is still considered a Trojan but with simpler and very specific functionalities and that one's about 580 bytes (reference). Based on this info, I established that it is highly unlikely (if not impossible) to slip any code in 32bytes of code and established that the resource in question is clean.

Mind you, this doesn't answer the question I asked but it comes pretty close. Thought I'd share it.