Windows: UAC-Programmverhalten abhängig vom Namen

[English]Heute noch ein Blog-Beitrag aus der Mottenkiste ‘Windows skurril’. Ist euch bekannt, dass der Name eines Programmes dessen Verhalten im Punkto Aufruf der Benutzerkontensteuerung beeinflussen kann? Ich wollte es kaum glauben – aber die Microsoft-Entwickler haben da in den Eingeweiden von Windows einige Balkone ‘gestrickt’ (neudeutsch als Heuristik bezeichnet), die manches zum Lotteriespiel macht. Ist zwar dokumentiert, aber imho wenig bekannt.


Anzeige

Eine Leseranfrage zu einem seltsamen Verhalten

Vor einigen Tagen hat mich Blog-Leser Andreas T. per Mail kontaktiert, um mir von einem seltsamen Verhalten in Windows zu berichten. Er hatte eine Programmdatei umbenannt und plötzlich startete diese mit einer Abfrage der Benutzerkontensteuerung, um administrative Berechtigungen zu erlangen. Andreas schrieb mir:

ich habe aktuell eine Frage zum Thema “Windows”, bei der ich aus dem Verhalten des Systems nicht schlau werde:

Ich habe das Spiel Quake2 installiert, zu dem die ausführbare Datei “quake2.exe” gehört.

Wenn ich die Datei im Explorer mit Rechtsklick kopiere als “quake2 – Kopie.exe”, wird die Datei ganz normal dargestellt und ist auch ausführbar, ohne daß die Benutzerkontensteuerung aktiviert wird.

Programmdateien

Benenne ich die Datei in “quake2patched.exe” um, wird die Datei mit einem Schild (siehe Screenshot) im Explorer dargestellt und ich erhalte beim Start eine Anfrage der Benutzerkontensteuerung.

Der obige Screenshot untermauert das Ganze. Andreas hat dann geprüft, ob sich beim Kopieren was geändert hat, aber ohne Erfolg. Dazu schreibt er:

Die drei Dateien sind identisch.

F:\Quake II>fc /b quake2.exe quake2patched.exe
Vergleichen der Dateien quake2.exe und QUAKE2PATCHED.EXE
FC: Keine Unterschiede gefunden

Benenne ich die “quake2patched.exe” um in z.B. “quake2test.exe” verschwindet das Schild-Symbol.

Haben Sie eine logische Erklärung? Es scheint am Dateinamen zu hängen – aber warum?

Ich hatte ad hoc keine logische Erklärung für diesen Effekt, konnte aber auch nicht reagieren, da ich unterwegs war. Ein Kurztest, den ich mit dem Windows-Editor Notepad durchführte, ergab aber ein merkwürdiges Bild. Wenn ich notepad.exe mit administrativen Berechtigungen kopiere und dann in notepadpatched.exe umbenenne, startet der Editor nicht mehr.

Erklärung: Benutzerkontensteuerung in Vista

Das Ganze hat seine Ursprünge wohl in Windows Vista, als Microsofts Programmierer die Benutzerkontensteuerung einführten. Programme, die administrative Berechtigungen erfordern, müssen diese über die Benutzerkontensteuerung anfordern. Eigentlich eine gute Sache.

Geregelt wird die Anforderung über ein Manifest, welches separat beiliegen kann, meist aber in der .exe-Datei enthalten ist. Dieses legt fest, ob das Programm administrative Berechtigungen braucht. Trifft dies zu, wird das Icon der Programmdatei mit dem stilisierte Schild versehen. Beim Aufruf erscheint dann auch die Benutzerkontensteuerungsabfrage.

Der Benutzer kann zudem eine Verknüpfung auf eine Programmdatei anlegen und dieser das Attribut Als Administrator ausführen zuweisen. Und es gibt die Möglichkeit, den Kontextmenübefehl  Als Administrator ausführen zum Programmstart zu verwenden. So weit so klar und alles in Ordnung.

Heuristik, oder Balkon-Programmierung in Windows

Aber es gab ja jede Menge Alt-Programme die von diesem Mechanismus nichts wussten. Also finden die Microsoft-Entwickler mit ‘Balkonprogrammierung’ an – sprich: Verwendung von trickreichen Ansätzen, um zu erkennen, dass ein Programm administrative Berechtigungen braucht. Und dann kommt so ein Mist wie oben erwähnt bei heraus.


Anzeige

Wird beispielsweise der Registrierungseditor Regedit.exe unter einem Standard-Benutzerkonto aufgerufen, startet er mit normalen Berechtigungen. Unter einem Administratorkonto wird dagegen die Benutzerkontensteuerung aktiv und ermöglicht es, den Registrierungseditor mit administrativen Rechten auszuführen. Der Start mit Als Administrator ausführen ist nicht mehr erforderlich.

Beim explorer.exe funktioniert das aber nicht, weil Windows intern die Ausführung mit administrativen Berechtigungen blockt – denn der Explorer ist ja auch für die Windows-Shell (Desktop etc.) zuständig. Ich hatte dies im Blog-Beitrag Explorer als Administrator ausführen mal thematisiert.

Installer Detection: Die schmutzigen Seiten des Ganzen

Geht man im Internet mit den richtigen Begriffen auf die Suche, stößt man vermutlich auf diesen stackoverflow.com-Thread. Dort erklärt jemand ein paar Winkelzüge, die bei 32-Bit-Programmdateien von Windows auftreten können. Microsoft hat dies 2006 für Windows Vista in diesem länglichen Dokument (Understanding and Configuring User Account Control in Windows Vista) beschrieben. Im Abschnitt Installer Detection legt man einige interne Tricks offen.

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.

Genau dort findet sich die Information, dass die Schlüsselwörter install, setup, update etc. im Programmnamen dieses Verhalten hervorrufen. Besonders spannend finde ich das “etc.” in der Beschreibung, denn das lässt Raum für viele Möglichkeiten.

Auch in der Registrierung lässt sich die Ausführung einer Anwendung per Benutzerkontensteuerung konfigurieren (siehe hier).

Bevor ich antworten konnte, schickte mir Andreas bereits eine zweite Mail. Dort schrieb er: kaum hat man die Frage abgeschickt, wird man beim MSDN doch noch fündig. Es ist tatsächlich der Dateiname, ich habe gerade einen entsprechenden Blog-Artikel verfasst. Er bezieht sich dabei auf den MSDN-Blog-Beitrag UAC: Five most common Install failure Scenarios and workarounds (Link gelöscht) von 2007, der das Ganze nochmals kompakter aufbereitet hat.

Meine abschließenden 2 Cents

Mit der Benutzerkontensteuerung bzw. der daran hängenden Implementierung hat Microsoft ein Monster geschaffen. Quasi ein Jahr nach dem ersten Artikel aus 2006 sah man sich schon gezwungen, einen erklärenden Artikel nachzuschieben. Das Verhalten von Programmen ist also nicht mehr deterministisch, sondern wird von einer Heuristik mit beeinflusst.

Solche Balkone sind oft der Grund, wenn irgend wann etwas mit Anwendungen gravierend in die Hose geht. Möglicherweise sind auch die Fälle, wo Anwender plötzlich damit konfrontiert sind, dass alle Programme nur noch mit Administratorrechten starten, auf solche Heuristiken (mit Registry-Einträgen) zurückzuführen.

Abschließender Gedanke: Vermutlich braucht Schadsoftware das nicht, weil sie mit Manifesten in den .exe-Dateien arbeiten kann. Aber es wären Szenarien denkbar, wo die Malware die Programmdateien nach einer bestimmten Zeit einfach umbenennt und so den Aufruf der UAC per Heuristik erzwingt, um den Anwender auszutricksen. Eigentlich könnte die Benutzerkontensteuerung (UAC) eine gute Sache sein. Aber mit so etwas macht man das Ganze schlicht kaputt. Oder wie seht ihr das so? Und war euch das bekannt?


Anzeige
Dieser Beitrag wurde unter Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

10 Antworten zu Windows: UAC-Programmverhalten abhängig vom Namen


  1. Anzeige
  2. Nö kann ich leider so nicht bestätigen, Windows 10 Pro, Version 1709 (Build 16299.192) egal wie auch immer ich eine Verknüpfung Umbenenne ändert sich weder etwas beim Öffnen noch etwas in der Ansicht einzig fehlen bei mir nach wie vor auf meinem Zweitbildschirm die Verknüpfungspfeile aber damit habe ich mich bereits abgefunden.

    • Günter Born sagt:

      Startet der Notepad denn noch, wenn er in Notepadupdate.exe umbenannt wird? Ich habe hier unter Windows 7 getestet.

      • der_Puritaner sagt:

        Ich kann das Notepad auch Günter_Born.exe oder Günter_Born_update.exe umbenennen und es startet Trotzdem.
        Aber ich muss zugeben ich arbeite mit deaktivierter Smartscreenfilten und der ganze Dreck sind deaktiviert.

        • Mike2 sagt:

          Übersetzung:
          Ich kann das Notepad auch in Günter_Born.exe oder Günter_Born_update.exe umbenennen, und es startet trotzdem.
          Aber ich muss zugeben, ich arbeite mit deaktivierten Smartscreenfiltern, und der ganze Dreck ist deaktiviert.

    • Micha sagt:

      Mit Verknüpfungen funktioniert das nicht.

      Man muss die *.exe im Programmverzeichnis umbenennen. Das Programm sollte aus der Zeit vor der Benutzerkontensteuerung stammen. Dann sollte es klappen.

      Hat bei mir mit:
      Gotic 3 1.75, Mini Golf 2003 und Fur Mark 1.19.1.0 funktioniert.

      Mit Prime 95 29.1.1.0 geht es nicht.
      Mit der Titan Quest Anniversary Edition (GOG Version) geht es nicht.

      • Micha sagt:

        Notepadupdate.exe Startet ganz normal.

        Es kommt keine UAC-Abfrage.

        Nutze Windows 7 Pro x64

        • Andreas K. sagt:

          Benenne doch die Notepad.exe mal nach quake2patched.exe um.

        • andreas sagt:

          Hallo,
          Microsoft scheint da bei eigenen Programmen (evt. durch das eingebettete Manifest?) etwas anders zu machen:

          Auf (m)einem Windows 7 64Bit führt

          C:\>copy c:\Windows\notepad.exe c:\temp\notepadpatched.exe

          zu einem Notepad ohne UAC, aber ein

          C:\>copy “c:\Program Files (x86)\PuTTY\putty.exe” c:\temp\puttypatched.exe

          zu einem PuTTY mit UAC.

    • Ralph sagt:

      Es geht nicht um die Verknüpfung, sondern um das executable file dahinter. Benenne einfach mal die .exe um und schau, was passiert.

  3. Trillian sagt:

    Moin Herr Born!

    Zur Frage “…war euch das bekannt?”: Nein und daher thx für die Infos!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.