Classic WTF: The Core Launcher

As our vacation continues, we might want to maybe play some video games. What could possibly go wrong? Original —Remy

“You R haccking files on my computer~!!!” Charles Carmichael read in a newly-submitted support ticket, “this is illigle and I will sue your whoal compiny. But first I will tell every1 nevar to buy youre stupid game agin.”

The bizarre spelling and vague threats were par for the course. After all, when you market and sell a game to the general public, you can expect a certain percentage of bizarre and vague customer communications. When that game is a popular MMPORG (no, not that one), that percentage tends to hover around the majority.

It took a few days to see the pattern, but the string of emails started to make sense. “Uh, when did your game become spyware?” said one email. “Are you doing this just to force us to play more often?” another customer asked. “I know you have a lot of AI and whatnot, so I think it leaked out. Because now my whole computer wants me to play all the time… like my dog bringing me his chew toy.”

As it turned out, the problem started happening a few days after an update to the core launcher was published. The core launcher was one of those terrifically handy executables that could download all of the assets for any single game that was published, scan them for completeness, replace bad or missing files, and then launch the game itself after the user signed in. It’s a must-have for any modern multiplayer online game.

This core launcher could also patch itself. Updates to this executable were fairly rare, but had to be made whenever a new title launched, as was recently the case. Obviously, a large battery of automated and manual testing is done to ensure that there are no problems after publishing, yet something seemed to have slipped through the cracks… at least for some customers.

After a whole lot of back and forth with customers, Chris was able to compile dozens of detailed process lists, startup program launches, newly installed applications, and firewall usage rules. As he pored over the collected information, one program was always there. It was Interfersoft’s fairly popular anti-virus suite.

It took a solid two days of research, but Chris was finally able to uncover the new “feature” in Interfersoft’s Advanced Firewall Protector that was causing the problems. Like many similar anti-virus suites, when a program wanted to use network services, Interfersoft would pop-up a dialog confirming that the program’s operation was authorized. Behind the scenes, if the user allowed the program, Interfersoft would make a hash of that executable file, and would allow its communications to pass through the firewall every time thereafter.

Users who had this antivirus solution installed had, at one time, allowed the launcher through their firewall. The first time they connected to the game server after the launcher patch was released, their executable would download its patch, apply it to itself, and restart itself. But then of course, the executable hash didn’t match any more, and the program was no longer able to go through the firewall.

Rather than asking users if they wanted to allow the program to connect to the internet, in the new version of Interfersoft’s suite, the anti-virus system would rename the executable and move it. The logic being that, if it was changed after connecting to the internet, it was probably malware.

But what did they name the file? Program.exe. Unless that was already taken, then they would name it Progra~1.exe or Progra~2.exe and so forth. And where did they place this file? Well, in the root directory of C of course!

This naming convention, as it turned out, was a bad idea. Back in the very old, Windows 3 days, Windows did not support long file names. It wasn’t until Windows NT 3.5.1 (and then Windows 95 later) that long file names were supported. Prior to this, there were a lot of limitations on what characters could be part of a filename or directory, one of those being a space.

In fact, any space in a shell command execution was seen to be an argument. This made sense at the time so you could issue a command like this:

C:DOOMdoom.exe -episode 3

That, of course, would start Doom at episode 3. However, when Microsoft switched to Long File Names, it still had to support this type of invocation. So, the way the windows cmd.exe shell works is simple. You pass it a string like this:

C:Program Filesid SoftwareDoomDoom.exe -nomusic

And it will try to execute “C:Program” as a file, passing it “Filesid SoftwareDoomDoom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:Program Filesid”, passing it “SoftwareDoomDoom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:Program Filesid SoftwareDoomDoom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

And on top of all this, desktop shortcuts on Windows are mostly just invocations of the shell, with the actual location of the executable you want to start (the path) stored in text inside the shortcut. When you click it, it reads this path, and passes it to the shell to start up the program. And this is why Intersoft’s process of moving files to the root directory was the worst decision they could have made.

Most of the programs installed in Windows at this time were installed to the “Program Files” directory by default. This was a folder in the root (C:) directory. So when you wanted to launch, for instance, Microsoft Word, the shortcut on your Desktop pointed to “C:Program FilesMicrosoftOfficeWord.exe” or Firefox, which was in “C:Program FilesMozillaFirefox”. But thanks to Program.exe in the root directory, you ended up doing this:

C:Program.exe “FilesMicrosoftOfficeWord.exe”

and

C:Program.exe “FilesMozillaFirefox”

So, when users were trying to launch their application – applications which resided in the Program Files directory on their C drive – they were getting the launcher instead.

Chris explained all of this in great detail to Interfersoft, all the while explaining to customers how to fix the problem with the firewall. It helped some, but several hundred customers ended up closing their accounts a direct result of the “hacking”.

A few weeks later, Interfersoft started responding to the issues with their customers. Fortunately (for them), they decided to not use their own auto-update process to deliver a new version of the firewall.

Source: Read MoreÂ