The Case of the Unknown Autostart

A few weeks ago I installed an update to a popular Internet Explorer media-player ActiveX control on one of my systems. I knew from past experience that the plugin’s updates always configure an autostart, (an executable configured to automatically launch during boot, login or with another process) that I don’t believe serves any useful purpose, so as I had in the past, I launched Sysinternals Autoruns, set both Verify Code Signatures and Hide Signed Microsoft Entries in the options menu, pressed Refresh, found the autostart and deleted it. However, as I was about to close the window another entry caught my eye and caused my heart to stop:

The entry, IECheck, has all the characteristics of malware: it has no icon, description, or company name, and it’s located in the Windows directory. Further, Autoruns’ Search Online feature, which executes a Web search, yielded no information on the suspicious executable.

I needed to investigate further to determine if the entry was a sign of a malware infection, so I turned to the Sysinternals Strings utility. Image files often contain plain-text strings that contain clues that can connect it with an application. For example, if a program reads configuration information from the registry, the registry path is embedded in the executable and usually includes the name of the vendor or application. Strings scans a file for printable strings (both Unicode and Ascii) and prints them, so my next step was to open a command prompt and dump those in IECheck.exe. Sometimes the output is so verbose that it’s easier to pipe the output to a text file and study the results with Notepad, but this time I spotted some interesting text as it scrolled past:

Sure enough, the executable had string references to other executables that are probably part of the same application, and they revealed the name of the application, IconEdit2, as well the vendor, WinAppsPlanet. I then remembered that I had just downloaded IconEdit a few days earlier to edit hi-resolution Vista-style icons and so I was able to classify the incident as a false alarm and close the case. My heart returned to its normal rhythm.

This example highlights a few practices that software vendors should follow for reliability and to prevent the confusion I faced. First is the use of environment variables and Shell special paths instead of hard-coded strings. IECheck (which I presume stands for Icon Editor Check) references the Program Files directory by name, which is only valid on English installations of Windows, so if installed on a foreign system, IECheck would fail to find the executables it looks for. Instead, it should locate the Program Files directory by using the %PROGRAMFILES% environment variable, or call ShGetFolderPath with CSIDL_PROGRAM_FILES for the folder parameter.

To avoid scaring security-conscious users, all executables should have a version resource with a company name and a description that clearly identifies the executable’s purpose. Further, vendors should obtain a code signing certificate to digitally sign their code. Windows relies more and more on signature information to help users make trust decisions, and users can leverage tools like Process Explorer, Autoruns, and Sigcheck to verify that executables are what they advertise instead of malware. I’ve contacted the author of IconEdit2 and he’ll be updating his application to follow this guidance. All vendors need to do their part to avoid this kind of needless scare.