[German]Today a blog post about a weird thing in Windows, that was unknown to me. The name of a program (.exe) can influence its behavior when it comes to accessing user account control. Windows has a build in heuristics to detect setup programs, that hasn't been written for Windows Vista and beyond.
Advertising
A reader request for a strange behavior
A few days ago, blog reader Andreas T. contacted me by mail to tell me about a strange behavior in Windows. He had renamed a program file and suddenly started it with a user account control query to gain administrative privileges. Andreas wrote:
I currently have a question about "Windows", where I can't figure out how the system behaves: I have installed the game Quake2, which includes the executable file "quake2. exe".
If I copy the file in Windows Explorer with a right click as "quake2 – Copy.exe", the file will be displayed normally and is executable without activating the user account control (UAC).
If I rename the file to "quake2patched. exe", the file is displayed with a UAC tag (see screenshot) in Explorer and I get a request from the user account control at startup..
The above screenshot underlines the whole. Andreas then checked whether something changed during copying, but without success. He wrote:
The three files are identical.
F: \Quake II>fc /b quake2. exe quake2patched. exe
Compare the files quake2. exe and QUAKE2PATCHED. EXE
FC: No differences found
If I rename the "quake2patched. exe" to e. g."quake2test. exe" the shield symbol disappears.
Do you have a logical explanation? It seems to be attached to the filename – but why?
At this time I didn't have a logical explanation for this effect. But as short test I renamed the Windows editor Notepad.exe to notepadpatched.exe. This .exe program didn't start anymore.
User Account Control since Windows Vista
The origins of this behavior lies probably in Windows Vista, when Microsoft's programmers introduced the user account control (UAC). Programs that require administrative privileges must request them from User Account Control. It's actually a good thing.
A program that requires UAC can declare this within a manifest, which is usually contained in the .exe file. Reading the manifest, Windows determines whether the program needs administrative authorizations. If this is the case, sometimes the icon of the program file will be provided with the UAC tag. Also a user account control dialog appears when the program will be launched.
Advertising
A user can also create a shortcut to a program file and assign the Run as administrator attribute to it. You can also use the context menu command Run as administrator to start the program. This works also for older programs, that didn't know something about UAC.
Heuristics, or balcony programming in Windows
But in 2007, as Windows Vista has been released, there were a lot of old programs that didn't know about this mechanism. So the Microsoft developers decided to construct a 'balcony' – in other words: using tricky approaches to recognize that a program needs administrative permissions. And then some crap like the one mentioned above comes out.
For example, if the Registry Editor regedit.exe is launched under a standard user account, it starts with normal permissions. Under an administrator account, however, User Account Control becomes active and allows you to run the Registry Editor with administrative privileges. Starting registry editor with Run as administrator is no longer required.
But using Run as administrator with explorer.exe, however, does not work, because Windows internally blocks execution with administrative permissions – because Explorer is also responsible for the Windows shell (desktop, etc.).
Installer Detection: The Dirty Sides of the Game
If you search the Internet with the right terms, you probably come across this stackoverflow.com thread. Somebody explains the heuristics Microsoft is using in Windows for 32 bit program. Microsoft has documented this in 2006 for Windows Vista within this dokument (Understanding and Configuring User Account Control in Windows Vista). Within the section Installer Detection you can find the details.
Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:
- Filename includes keywords like "install," "setup," "update," etc.
- Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
- Keywords in the side-by-side manifest embedded in the executable.
- Keywords in specific StringTable entries linked in the executable.
- Key attributes in the RC data linked in the executable.
- Targeted sequences of bytes within the executable.
There is the information that the keywords install, setup, update etc. in the program name cause this behavior. But the "etc." in the description leaves room for many possibilities.
You can also configure the execution of an application in the registry using user account control (see here).
Before I could answer my readers query, Andreas already sent me a second mail. There he pointed me to another Microsoft blog post UAC: Five most common Install failure Scenarios and workarounds (link broken) from 2007. So, just a year after they created that monster, they recognized that there was a need for another blog post explaining the shady tricks used within the Windows installer detection heuristic. Unbelievable.
Advertising
Hello, thanks for article.
But:
"But using Run as administrator with explorer.exe, however, does not work…"
You can run explorer.exe as Administrator. First you need to close all explorer processes and then run explorer.exe as administrator from taskmgr. I tested it in Windows 7. Process is then elevated
Not really ;-) I haven't linked my old German blog post. Of course, you can do the 'Run as administrator' trick – but explorer.exe will be executed with integrity level Medium. This behavior has been explained in the already deleted KB article 2273047 (web archive)
Microsoft explained it in the following way:
Magic André has documented this behavior within his (already deleted German WinVistaSide article (cache version). Hope this helps.
You're kind of both right and both wrong;
Any explorer.exe process started from an unelevated process will run in the standard user context. Also, explorer.exe is launched in standard user context at logon.
However, if you kill all explorer processes (including the root one providing the windows UI), then start it from an elevated task manager (or through the Win+R run prompt, but I don't remember if this one is available when no explorer process at all is running), then it will be elevated.