The Case of the Unknown Autostart

re: The Case of the Unknown Autostart

Adrian — Mon, 21 May 2007 18:34:45 GMT

But why does an icon editor need an autostart? It may not be malware, but it certainly doesn't seem like goodware.

re: The Case of the Unknown Autostart

Chip — Mon, 21 May 2007 19:01:25 GMT

I must waste maybe an hour or two each week tracking down unknowns like this. I should be happy, in the end, I suppose, that the conclusion is a legitimate app or process, but usually I'm just pissed that the vendor didn't make their app's presence/purpose more readily discernible on the system

re: The Case of the Unknown Autostart

ac — Mon, 21 May 2007 19:03:18 GMT

And why put it in %windir% in the first place, whats wrong with program files (Maybe they can't handle a space in the path :)

I hate programs that "know" that their little app is the best thing in the world and therefor you will never use anything else so they help you out by stealing back file exstensions and recreate shortcuts and all that crap

re: The Case of the Unknown Autostart

Clint — Mon, 21 May 2007 19:29:35 GMT

"I hate programs that "know" that their little app is the best thing in the world and therefor you will never use anything else so they help you out by stealing back file exstensions and recreate shortcuts and all that crap" -- quote from ac

Is that confirmed what this program is doing? Is it reseting file extensions and icons? If so, then the programmer needs to consider more then just including some versioning but the proper way to request from the user if they want these changes applied and only request at the launch of their program with a way to disable the feature.

I can think of a few other commercial software that misuse the autorun for everything from checking for updates, to the dubious quick launch.

As always Mr. Russinovich a good read.

re: The Case of the Unknown Autostart

Grew-Dan Boll — Mon, 21 May 2007 23:38:32 GMT

Amazing. The year is 2007, and people still let random applications silently write to %windir% and silently add things to their autostart lists!

re: The Case of the Unknown Autostart

Grant — Tue, 22 May 2007 01:40:29 GMT

"Amazing. The year is 2007, and OPERATING SYSTEMS still let random applications silently write to %windir% and silently add things to their autostart lists!"

Windows lacks a strong application installation model.

Windows uses an aggregation rather than a synthesis model. It favors scripting instead of declaration. This is the primary source of configuration decay.

Effectively the system configuration is the sum of all modifications applied by all install programs. The alternative is a system where registered applications declare their interactions with the system and the system builds the system state. This can even be done per user where appropriate.

Imagine that Word declared that it only needs to be able to modify .docx files (an oversimplification). The system could then trap modifications to other file types (allowing for the lack of strong file typing).

Imagine that applications are presented a synthetic view of the file system with only those areas that are appropriate (its own application files, user config, user data areas). The app wouldn't even see operating system file areas it has no business interacting with.

Now, things like SoftGrid are interesting. In particular, the way they provide a bridge for many older applications by capturing the modifications and virtualizing system interactions. It would be nice if VS produced a SoftGrid package automatically. Perhaps this is the direction we need to move in.

re: The Case of the Unknown Autostart

Norman Diamond — Tue, 22 May 2007 08:18:11 GMT

> Strings scans a file for printable strings

> (both Unicode and Ascii)

Push that on the stack for a moment.

> 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

Now pop the stack. In principle, if IECheck were installed on either a Japanese system or a foreign system other than US, then Strings would fail to find the strings naming the executables (except if IECheck is compiled in Unicode).

Strings is freeware and I have no complaint about its limitations. But if you think about whether you might want to check for strings in a non-US environment, you might want yourself in the future to take the code page into consideration.

Monday, May 21, 2007 4:38 PM by Grew-Dan Boll

> people still let random applications silently

> write to %windir% and silently add things to

> their autostart lists!

That's why you have to be administrator in order to install a program. That's why Vista doesn't even ask the administrator whether or not to elevate the installer; Vista *knows*.

re: The Case of the Unknown Autostart

Daniel — Tue, 22 May 2007 10:50:37 GMT

Quicktime is another example of this type of app. it is an immensley overbloated program that dumps files everywhere, adds a key to the RUN key in the registry, sticks icons in the systray that i never asked for, takes over files associations and who knows what else.

All that to be able to view a fairly minor file type. When will Apple get it into their head that the .MOV format is not the only format in existence? They have this same mentality with iTunes, but I don't want to rant about that!

www.andrewhay.ca » Suggested Blog Reading - Tuesday May 22nd, 2007

www.andrewhay.ca » Suggested Blog Reading - Tuesday May 22nd, 2007 — Tue, 22 May 2007 13:58:53 GMT

PingBack from http://www.andrewhay.ca/archives/126

re: The Case of the Unknown Autostart

JC — Thu, 24 May 2007 00:48:47 GMT

I can understand what you were scared... the IE in IECheck definitely looks suspicious, among all the other things (no version resource, etc...)

I'm still surprised that people hardcode strings like this.

Actually, %ProgramFiles% is called "Program Files" on all the languages versions I've been given an occasion to work with (that said, I'm far to pretend I've touched all the localized versions of Windows yet).

In French, it is called "Program Files" as well, and I think it is the same on dutch systems. So goes for the "Documents and Settings" and "Application Data" folder.

I guess that Microsoft made this as a countermesure against bad practices of some people.

Some translated folders include Favorites and mysteriously %CommonFiles% (which is a bit odd as it is usually a subfolder of %ProgramFiles%...)

Contrarily, I've seen one or two software who assumed that Program Files was translated in a different language (say, french) and translated "Program Files" to "Fichiers Programmes", which didn't exist because on french systems %ProgramFiles% is "Program Files" too... as a result, things worked, but a needless folder (the localized one) was created only for this program.

So many difficulties these programmers created for themselves by not properly reading the documentation...

That said, internationalized paths or not, it would have failed on an english system as well if my system drive was D: and not C: (which happens sometimes when the Windows installer affects a different letter to a partition you thought it would give, but in this case, I restart the whole process as I know so many programs are so poorly designed in that aspect).

Glad to see you're back in more frequent blogging again, Mark, (it's a bit less advanced than before, but it can't always be call stack-level troubleshooting and is always a good read nevertheless).

Thanks,

JC.

Localization issues

JKB — Thu, 24 May 2007 17:43:00 GMT

Well, in German Windows the "Program files" is called "Programme" - which enabled some bad-developed Windows programs to work on German Windows because "Programme" has no blanks.

The most other shell directories also have different names in German.

In Windows Vista the Shell folders have English names and there are symbolic links placed to those folders in both English an localized versions - it looks a bit messed up compared to older Windows versions. In addition applications writing to their exe path under Vista get their files redirected to the users Application data, so it is difficult to find out the real storage location for newly created files (even Applications where writing to the own directory is denied can do that under Vista).

It would be a nice thing to enable the old (Windows 2000) style access mechanism for Vista, so when the Application directory is read-only, the Application fails to write there - ist not nice, but it is safe.

re: The Case of the Unknown Autostart

James — Thu, 24 May 2007 19:28:07 GMT

Please protest HR 1525 this bill supposedly to prevent spyware looks like it was written by a spyware company. Why do I say this? It prevents people from sueing companies like sony who's infamous rootkit scandal got them sued, by many of the victims. This bill would allow the Government to set a fine (less than the cost of a lawsuit) . Now think about this.. If the government fines sony lets say $10,000.00 or even $100,000.00 thats far less than the law suits that sony had to settle for, this becomes a bill that makes it a cost of doing business for sony, not a risk for spying on customers. This Bill is insidious as it takes the Constitutional rights to seek compensation by the victims of such a crime. This bill will make it afordable for Sony to violate your privacy and rights. And who benefits? only the Government as it becomes nothing more than a Spyware tax and licence to continue the behavior. This Bill is a scam in itself. It's no surprise it was written by a congresswoman in Silicon Valley, I wonder how much she was paid to write this bill. Let's see who she gets a consulting job from after she leaves Congress.

re: The Case of the Unknown Autostart

Sean Barrett — Fri, 25 May 2007 06:18:52 GMT

"Actually, %ProgramFiles% is called "Program Files" on all the languages versions I've been given an occasion to work with"

On my XP system it is "c:\programs", because spaces in paths are _still_ a headache (dunno if this is fixed in Vista). Open a command window and type "start c:\windows" (or winnt or whatever the path is), and you will open an explorer window looking at that directory. In at least XP and earlier, open a command window and type 'start "c:\program files"', and you will open up... another command window. (The problem here is the quotation mark, not the spaces, but that makes the spaces unfixable.)

As to Mark's original scenario, I run StartupMonitor to catch most cases of programs running needless startup things when it happens, rather than after the fact. Recommended, at least until there's a sysinternals equivalent.

re: The Case of the Unknown Autostart

molotov — Sat, 26 May 2007 05:17:13 GMT

'start "" "C:\program files"' gets you the Explorer window.

start /? indicates the first quoted param is the "Title to display in window title bar".

re: The Case of the Unknown Autostart

James E. Clemens II — Mon, 28 May 2007 08:43:21 GMT

The Sysinternals AutoRuns tool is all that is needed to track down this type of questionable program.

As a Network Administrator, I can run this very small application and uncheck all those programs stealing my resources in less than two minutes.

If I can suggest anything here, it is to inform users to stop installing software and updates under the "typical" setup. Simply check the "custom" setup and save yourself a lot of time. Adobe, Java and several others will add all sorts of extra programs when using the "typical" setup.

I think this should be considered hiddenware at the very least! If I wanted the toolbar or other program they are pushing, I would install it!!

Good thing I have Sysinternals AutoRuns to level the playing field. This app is awesome!!!

re: The Case of the Unknown Autostart

Tim Maletic — Wed, 30 May 2007 23:26:38 GMT

Mark's recommendations to the author of IconEdit2 can just as easily be adopted by every malware author, so I don't see the point. But I must be missing something or someone would have pointed this out already...

re: The Case of the Unknown Autostart

Alice Chang — Thu, 31 May 2007 00:33:25 GMT

I think I agree with Mr. Maletic about the proposed solution, up to a point. In my job as a network analyst, I often have to analyze concurrent HIDS events as well; seeing suspicious traits like "no icon, description, or company name, and [..] in the Windows directory" definitely raise red flags with me. But then I think about all the stuff that *don't* raise red flags -- and sometimes I wonder if there aren't malware that are being blissfully ignored because they simply appear to be an unusual, but legitimate application with all the right markings. (The markings in this case being some sort of author, some sort of company, some sort of icon...)

The solution of using certificates could effectively mitigate the risk, I suppose, except I'm not sure how easily malware-writers or suspect ware-writers could obtain one...

re: The Case of the Unknown Autostart

.jon — Tue, 12 Jun 2007 02:00:25 GMT

> Actually, %ProgramFiles% is called "Program

> Files" on all the languages versions I've been

> given an occasion to work with (that said, I'm

> far to pretend I've touched all the localized

> versions of Windows yet).

With a german system I have of problems with about 10% of all installed applications.

On a German XP it is not "Program Files" but "Programme". And not "Documents and Settings" but "Dokumente und Einstellungen" and not "ApplicationData" but "Anwendungsdaten". Just to name a few. They are (luckily) totally localized.

One thing as important as this is people (including me) who absolutley hate the MS way to throw all into a single root and install Program Files, Documents and Settings, $TEMP% and maybe even others on seperate partitions, which makes backing up the system, re-installing it etc. much more easy.

re: The Case of the Unknown Autostart

James — Mon, 18 Jun 2007 11:18:06 GMT

"IEcheck" does sound like the typical malware trick of masquerading as a part of Windows, and putting itself in %WINDIR% rather than its own application directory doesn't help; then again, at least it didn't have a valid MS signature: if seeing "iecheck.exe" made Mark's heart stop, imagine my reaction when I saw a *signed* 'services.exe' sitting there, merrily probing port 25 on remote machines! (Needless to say, that was indeed malware; I'm actually quite impressed by the lengths it went to to escape detection, hiding most of its antics within services.exe *without* compromising the MS signature!)

re: The Case of the Unknown Autostart

Ruben — Tue, 19 Jun 2007 14:48:51 GMT

In Spanish %ProgramFiles" is "Archivos de programa" and so on. Most system folders are localized, but surprisingly, "Documents and settings is not.

That aside, I fully second Mark's suggestions.

"Mark's recommendations to the author of IconEdit2 can just as easily be adopted by every malware author"

That's where digital signatures come in.

"The solution of using certificates could effectively mitigate the risk, I suppose, except I'm not sure how easily malware-writers or suspect ware-writers could obtain one."

Not easily. The problem with that is not that malware writers can obtain or forge a Microsoft certificate. The problem is they don't need to. All they need is a certificate that "looks" like the real thing and most end users will accept it as real without bothering to check.

re: The Case of the Unknown Autostart

Calum Grant — Wed, 20 Jun 2007 13:55:54 GMT

It's definitely good for applications to have proper resource information - since I would expect good quality software to follow those guidelines. Anything that fails to follow simple guidelines is suspect.

Another crime is services with no apparent purpose, and no description of what suite they are part of. Even respectable software in the install/remove programs sometimes has cryptic names from 3rd party publishers. Sony installed a lot of such rubbish on my Vaio laptop. I have no idea what I can disable without suddenly breaking functionality.

However, malware/spyware should fake something plausable, and a casual user would have no chance of distinguishing malware from legitimate software.

re: The Case of the Unknown Autostart

Igor — Fri, 29 Jun 2007 17:27:36 GMT

IMO, you should have asked the author for the justification of autostart component for an Icon Editor. I don't see any possible reason why that crap could be needed to slow down each computer startup.

There is an increasing number of applications which use autostart or even worse system notification area for purposes which are dubious to say the least.

Those practices should be loudly discouraged by Microsoft in MSDN and in Designed for Windows logo program. I would even vote for hampering their ability to do it because 90% of software vendors just abuse it.

/rant on

I just hate it when they work against the system. Prime example would be well known disk defragmenter utility which in its latest version has no less than 4 processes running all the time. One of them is scheduler which could have been replaced by system's own Task Scheduler use. There is also some "agent" and then the engine. Why they need to be running all the time when defragmentation is something you perform once in a few weeks is really unexplainable.

Even worse the same utility has the self-repair system -- if you terminate any of those processes they come to life again in no time. If you delete the executable, it will invoke setup to repair the installation without asking you a single thing. If you remove installation cache then it will make your system unusable in an suicidal attempt to find it. That is the same mechanism malware uses to stay on your computer against your will.

In other words, every program should do what I tell him to, without asking me "do you want fries with that?" or even worse stuffing my face with fries without asking.

/rant off

re: The Case of the Unknown Autostart

Mihai — Sun, 01 Jul 2007 22:02:55 GMT

Let's say the company does not care about foreign markets, so localized folders don't matter (ok, I don't say is right, but bear with me :-)

But an application designed "to edit hi-resolution Vista-style icons" will not work on Vista! (because "Program Files" is "Programs" in Vista)

A better icon editing program

Alex Railean — Mon, 15 Oct 2007 11:59:55 GMT

Hi, I have been facing the same [original] problem - find a good icon editor which can make nice icons for Vista. I found a free program that matches the flexibility of various shareware tools I tried; look for "IcoFX".

I also have some things to say about the other problem discussed here - folder paths. Mark, you mentioned two methods of accessing the Program Files directory, one is "%programfiles%" and the other is to use ShGetFolderPath.

Is there any set of circumstances in which the two methods will return a different result? I know that it sounds stupid, but I have been facing a problem on a person's computer: using %programfiles% to access a third party program in Program Files, but I always get a file not found error. The guy swears the file is there.