Diskussion:Ausführbare Datei

Jemand sollte die Erklärung verbessern, weil der Begriff mit sich selbst erklärt wird. Ich habe leider nich genug wissen dazu.

Ja es wird auch nicht erklärt was genau geschieht beim ausführen einer solchen Datei! Wäre nett zu wissen wie der Computer Hardware mit einem solchen Datei umgeht und wie er es ausführt!! danke (nicht signierter Beitrag von 193.22.73.200 (Diskussion | Beiträge) 10:43, 21. Okt. 2009 (CEST))

Definition? Belege? BSI-Verweis!

Dieser Artikel ist vollkommen beleglos.

Leider wird auch das Konzept dahinter nicht erklärt: Offenbar fallen darunter auch Dateien, die von "Shells", also bestimmten Interpretern, dazu verwendet werden, "Seiteneffekte" zu erzielen. Aber welche "Interpreter" zählen zu denen, deren Inputs "ausführbare Dateien" sind? Auch G-Code-Interpreter? Auch MIDI-Player (mit dem Seiteneffekt, Sounds zu erzeugen)? Auch MIDI-Player, die damit Feuerwerke ansteuern? Auch Key-Logger, die ihre Ergebnisse replayen können (wie AutoHotkey)? Was noch alles, und was nicht?

Und nicht wirklich glücklich bin ich damit, dass vom offiziellen BSI-Dokument BSI TR-03183 Cyber-Resilienz-Anforderungen - Teil 2 "Software Bill of Materials (SBOM)" in einer Fußnote auf diesen Wikipedia-Artikel verwiesen wird - noch dazu in einer "MUSS"-Klausel; sodass dass nun viele sich hier informieren wollen, was als "Ausführbare Datei" gilt und was nicht. --Haraldmmueller (Diskussion) 09:50, 14. Aug. 2023 (CEST)

Das mit den fehlenden Belegen sehe ich zwar ein, jedoch sind die verlinkten Artikel durchwegs bequellt. Außerdem muss man auch festhalten, dass es eben so ist: je nach System gibt es eben bestimmte Merkmale, wann eine Datei ausführbar ist. Für Unix ist das im verlinkten Artikel Unix-Dateirechte genau erklärt, der jedoch auch nicht bequellt ist.

Was sollen "Seiteneffekte" sein? Ein Interpreter führt alles aus, was er interpretieren kann, und damit, ja: solange es sich um eine Textdatei handelt, auch MIDI-Instruktionen, wenn im Shebang unter Unix ein entsprechender Interpreter angegeben ist.

Für Binärdateien gibt es ganz eigene Regeln, aber auch da lässt sich, siehe binfmt_misc, ein Interpreter festlegen.

‣Andreas•⚖ 14:23, 14. Aug. 2023 (CEST)

Danke für Antwort - mit etwas, aber nicht viel Entschuldigung, dass ich von der Security-Seite herkomme, u.a. wegen diesen Verweis im BSI-Dokument zur SBOM. Weitere Bemerkungen:

• Seiteneffekt (von mir aus auch Nebenwirkung, Wirkung ist mir nicht geläufig) ist ein Standardbegriff der Informatik; was hier relevant ist, sind die Effekte, die die Ausführung einer ausführbaren Datei außerhalb des Ausführungssystem ("der Laufzeitumgebung") hat: Denn dort können diese Effekte ja schädliche sein; und das will man über Analysen (wie eine SBOM), Tests, ... im Griff behalten.
• Deine Ausführungen zu Unix-Dateirechten (den x-Bits) oder hier im Artikel zu Dateitypen ("file name extensions") zeigen, dass man prinzipiell jede Datei "ausführbar machen kann": Ich kann z.B. in einer PNG-Datei per Steganographie irgendwelche Anweisungen einbetten und dann diese Datei einem passenden Interpreter vorwerfen, der die Anweisungen ausführt. Damit bedeutet aber der Begriff "Ausführbare Datei" nicht "eine Datei, die inhärent ausführbar ist" (weil das alle Dateien sind - dafür braucht es keinen eigenen Begriff), sondern "eine Datei, die in einer konkreten Installation als ausführbar gekennzeichnet ist (durch x-Bit, Benennung, ...) und für die ein Interpreter vorhanden ist." Aus der (engen) Securitysicht ist damit jede Datei potenziell ausführbar; und das sollte man (oder ich) dem BSI vielleicht sagen, dass sie das klarstellen: Dass es prinzipiell für jede Datei, die aus einer Software-Build-Chain rauskommt, eine SBOM geben muss, an der man sieht, was in das "Rezept" der Datei alles an "Zutaten" hineinkommt ...

Das ging jetzt über diesen WP-Artikel hinaus, war aber doch hilfreich für mich. Daher nochmal danke für deinen Kommentar. --Haraldmmueller (Diskussion) 18:39, 14. Aug. 2023 (CEST)

Ich habe mir das BSI-Dokument nicht angesehen, es ging mir nur um "die ausführbare Datei" ansich. Und da habe ich mich jetzt auch auf die Suche gemacht, aber nichts gefunden... Zumindest keine Anfänge: wann wurde das konzept von "ausführbaren Dateien" eingeführt?

Fest steht nur: früher, auf den Mainframes der "Computer-Steinzeit" (1950 und davor) wurden auf Computern nur immer jeweils ein Programm ausgeführt, ohne jegliches Betriebssystem: die Hardware wurde direkt und ohne Programmiersprachen programmiert, und ein Programm war immer spezifisch für ein einziges individuelles System. So viele Computer gab es ja auch nicht, und bei jedem wurde zusätzliche Hardware, etwa eine Speichererweiterung oder ein Drucker, individuell und angepasst "angebaut". Sowas wie Standards für die Erweiterungen und für I/O war noch in den Kinderschuhen und wurde erst entwickelt.

Nach den 1950ern gibt es die ersten Betriebssysteme, jedoch wurden Programme und Hardware-Zubehör immer noch für einzelne Systeme entwickelt. Außerdem war es immer noch so, dass man Programme meist exklusiv laufen lies, also:

1. Ein einzelnes Programm (per Lochkarten, Magnetband etc.) wurde geladen,
2. zur Ausführung gebraucht (mit der Möglichkeit, darauf Einfluss zu nehmen, in dem Kippschalter entweder ein oder aus waren).
3. und das Ergebnis wurde am Ende meist ausgedruckt: auf einem Drucker, der auch speziell für dieses System angepasst und angeschlossen worden war.

Betriebssysteme und Dateisysteme wurden irgendwann wichtig, als es mehrere Systeme gab, die miteinander kommunizieren können sollten, und als es Compiler gab, womit man dasselbe Programm auf mehreren unterschiedlichen Systemen übersetzen konnte. Ein Programm war damit plötzlich nicht mehr nur für ein einziges System geschrieben.

Damit mussten Programme und Daten unterscheidbar werden, und zwar nicht nur vom Ersteller des Programms selbst, sondern vom System ansich. Und mit Dateisystemen gab es irgendwann die Notwendigkeit, Programmdateien als solche zu kennzeichnen, um nicht irrtümlich z.B. eine Datendatei zu laden und ausführen zu wollen.

Das COM-Dateiformat ist noch sehr rudimentär: es wird immer an einer fixen Adresse in den Speicher geladen und direkt ausgeführt. Das Format stammt noch von CP/M aus den 1970er Jahren, wurde in MS-DOS aber übernommen. Dabei läuft ebenso immer nur ein Programm, zwar unter einem Betriebssystem, aber exklusiv.

Das Betriebssystem hat aber immer mehr und mehr "Management"-Aufgaben an sich gerissen, verwaltete irgendwann alle I/O-Funktionen und den Speicher. Und vor allem bei der Speicherverwaltung entstand die Notwenigkeit, ein Programm an einer vom Betriebssystem verwalteten Speicheradresse zu laden. Das COM-Format ist damit nicht kompatibel: Das EXE-Format der späten 1970er aber schon. EXE-Dateien gab es vor MS-DOS schon auf der VAX.

Was unterscheidet nun Systeme mit Betriebssystem von jenen, ohne ein Betriebssystem? Eine (mehr oder weniger) mächtige Shell, also eine Schnittstelle zwischen "der Maschine" (der Hardware in ihrer Gesamtheit, also das gesamte System) und dem Menschen.

Die Shell von Multics und Unix war eine textbasierte Shell. Auch DOS bietet mit der COMMAND.COM eine Textshell, viele Heimcomputer hatten als Betriebssystem ein ROM-BASIC. Damit kann man Kommandos eingeben, die "das Betriebssystem", also die Shell, von sich aus bietet: "interne Kommandos". In der Unix-Shell ist das sehr minimalistisch angelegt, die Masse der Systemprogramme sind "externe Kommandos", also eigenständige Programme, die geladen und ausgeführt werden (müssen). Bei BASIC muss man Programme noch zuerst laden, "LOAD", und dann ausführen "RUN". Damit man sich diese zwei Schritte spart, bietet Unix ausführbare Dateien: die werden ohne ein vorgestelltes z.B. "exec <Dateiname>" geladen und ausgeführt, was Zeit spart.

Dazu muss das Betriebssystem aber wissen, welche Dateien Programme sind, und es diese daher auch ausführen kann bzw. darf. Sonst würde es versuchen, Daten auszuführen, was gefährlich ist.

Man findet das Ausführen von Programmen auch in der Unix-exec-Funktion gut erklärt. Diese Funktion findet sich auch in C/C++ und zahlreichen anderen Sprachen, und sie ist eine Betriebssystem-Funktion – Funktion des Kernels, der dann auch gleich die I/O- und Speicherverwaltung übernimmt (und vieles mehr, etwa Rechteverwaltung).

In MS-DOS (seit 86-DOS) hingegen hat man sich, wie bei CP/M, die "Markierung", welche Datei ausführbar ist, erspart, und stützt sich rein auf die Dateinamenserweiterung. Das kann man sogar ausprobieren: Startet man beispielsweise PC-DOS 1.00, hier bei PCjs im Browser, und benennt eine Textdatei (BASIC-Programmdatei, das ist eine Textdatei) um, beispielsweise bug.bas in bug.com, dann kann man diese Datei nun ausführen. Es kommt zu einem Fehler: Undefined Opcode. Die Datei enthält nunmal keinen Maschinencode, wird aber als solcher auszuführen versucht.

A> copy bug.bas bug.com

A> bug.com
 Undefined Opcode ERROR

Bei EXE-Dateien tut sich das Betriebssystem viel leichter, denn EXE-Dateien haben einen Header: diesen muss das Betriebssystem sogar verarbeiten, damit das Programm dann unter verschiedenen Speicheradressen laufen kann. Dabei stellt es auch gleich fest, ob das wirklich eine Programmdatei ist. Wenn nicht, wird das vermeintliche Programm vom Betriebssystem nicht ausgeführt.

Die Dateinamenserweiterungen .COM und .EXE sind in der Shell, also COMMAND.COM, hart einkodiert, ebenso wie .BAT. In OS/2 und Windows NT kommt zu .BAT noch .CMD dazu, beides sind aber Shellskripte (unter DOS "Stapelverarbeitung(sdateien)" genannt): das heißt, hier geht die Shell davon aus, dass es eine Textdatei ist, und dass alle Zeilen nacheinander "eingetippt" werden sollen. Und das macht die Shell dann auch, als Interpreter.

Auch das kann man unter PC-DOS 1.00 übrigens ausprobieren: hierzu kopiert man einfach space.bas (BASIC-Programmdatei, hier allerdings als "kompilierter" Bytecode) zu space.bat, und startet die vermeintliche "Batch-Datei".

A>copy space.bas space.bat

A>space.bat

A> ╟
Bad command or file name

DOS will den Inhalt der Datei also auf der Kommandozeile ausführen, als würde man die Zeichen wie bei einer Textdatei (unter DOS ASCII-Code einer bestimmten Codepage) eingeben, was natürlich ebenfalls nicht geht.

Unter CP/M gab es auch sowas wie Batch-Files, die waren aber .SUB-Dateien, allerdings war die Dateinamenserweiterung eigentlich egal, denn man startete solche Skripte manuell mit "SUBMIT <Skriptdatei>" -- so wie u.a. unter DOS auch BASIC-"Programme" mit "GWBASIC <Basic-Datei>" gestartet wurden. Das kann man mit allen Interpretern machen, wenn diese die Skriptdatei als Kommandozeilenparameter annehmen.

Das Problem mit dieser Art, auf der Shell "Programme" zu starten, entsteht, wenn man plötzlich eine grafische GUI verwendet, denn dabei ist es viel umständlicher, Kommandozeilenparameter zu verwenden. Stattdessen will man einfach einen Doppelklick (oder was auch immer) machen müssen. GUIs gab es mit dem Xerox Alto, dem Xerox Star und der Apple Lisa schon in den (späten) 1970ern, den frühen 1980ern.

Unter Unix (das inkludiert auch alle Unixoididen Systeme, also auch Linux) macht das "Shebang" nichts anderes, als statt der Shell einfach einen anderen, im Skript selbst festgelegten Interpreter zu verwenden. Das ist äußerst flexibel. (Und: ja, damit kann man auch Unfug machen und einfach irgend ein Binärprogramm starten: Unix überprüft nicht, ob das angegebene Programm im Shebang auch wirklich ein Interpreter ist oder nicht... Wie sollte es das auch bewerkstelligen?)

Wenn ich unter Unix im Shellskript in der ersten Zeile "#!/Pfad/zu/einem/Interpreter <Parameter>" angebe, dann führt die Shell das so aus, dass es den Dateinamen des Shellskript hinten anhängt (ausgeführt wird also: /Pfad/zu/einem/Interpreter <Parameter> "Shellskript-Datei" -- im Grunde wie bei "SUBMIT <Paramter> <Skriptdatei>" unter CP/M) -- allerdings nur, wenn die Datei eben als ausführbar markiert ist. Ich kann also prinzipiell auch einen Shebang wie diesen Verwenden: "#!/Pfad/zu/meinem/Programm <Parameter>". Die Unix-Shell (der Kernel) schaut nur vorher nach, welcher Art eine ausführbare Datei ist: Ist es nicht z.B. ELF (früher auch CROFF und a.out), oder hat ein Shebang, (oder ist per binfmt_misc eingerichtet,) wird es nicht ausgeführt sondern gibt einen Fehlercode aus.

Skripte kann man unter Unix auch weiterhin -- wie früher, und wie auch unter DOS und sogut wie jeder anderen Shell auf anderen Systemen -- mit dem Interpreter vorangestellt ausführen. Ist ein Shellskript beispielsweise nicht in einer ausführbaren Datei, ich will das Skript aber dennoch ausführen, mach ich das einfach per "sh ./mein-skript.sh", und schon führt ihn die Shell ("sh") aus. Ist es ein Python-Skript, dann eben mit "python ./mein-skript.py", usw. (Die Dateinamensweiterung dient hier aber nur der "Markierung" für den Anwender, für die Ausführung ist es hübsch egal. Damit macht es das Shebang möglich, die Skriptsprache zu verstecken: ./meinskript -- ohne ".sh", ".py" usw... könnte jede Art von Programm sein, von Binärprogramm bis Skript, der von einem Interpreter ausgeführt wird; nur ausführbar muss die Datei dafür sein, und natürlich muss der im Shebang angegebene Interpreter auch auf dem System vorhanden sein.)

Dass man Dateiformaten (unter Windows: Dateinamenserweiterungen=Dateiendungen) Programme zuordnen kann, hat unter einer GUI gewaltige Vorteile. Mache ich hier einen Doppelklick auf eine .BAT-Datei, weiß das Betriebssystem, dass es diese mit dem Interpreter "CMD.EXE" ausführen muss. Und eine .docx-Datei öffnet es dann mit z.B. Word.

Das sind aber Verbindungen bzw. Verknüpfungen, "Assoziationen", der GUI, nicht der Textshell. Aber auch da gibt es teils Möglichkeiten, irgendwelche Dateien direkt mit dem zugehörigen Programm auszuführen (siehe Linux binfmt_misc).

Es gab bzw. gibt also die zwei gegensätzlichen Ansätze, sowie Mischungen daraus:

1. Dateiname, genauer gesagt dessen Erweiterung, ist mit einem Programm verknüpft ("assoziiert").

2. Eine Datei ist im Dateisystem selbst als "Ausführbar" markiert (Metadaten), und das Betriebssystem muss herausfinden, wie.

3. Eine Datei ist im Dateisystem per Metadaten mit einem Programm verknüpft (Apple: Resource Fork).

4. Das Betriebssystem analysiert eine Datei aufgrund ihres Inhalts (siehe file), und weiß aufgrund dessen, mit welchem Programm die Datei zu öffnen ist (oder ob sie direkt ausführbar ist).

TL;DR Was ein Betriebssystem ausführt, muss nicht immer ein Programm sein. Aber, weil das Fehler erzeugen würde, gibt es genügend "precautions", die ein "falsches Ausführen" verhindern sollen. In modernen Betriebssystemen gibt die Shell dem Nutzer jedoch den Eindruck, unterschiedliche Dateien "ausführen" (öffnen) zu können, als wären sie selbst Programme. Direkt im Betriebssystem laufen jedoch stets nur Binärprogramme, entweder direkt, oder um die Daten von Dateien oder von Programmcode, der zu interpretieren ist (Shellskript, Java-Bytecode), per Interpreter "auszuführen".

So gesehen ist "Ausführbare Dateien" lediglich ein Mechanismus, der dies teilweise ermöglicht. Ohne diesen Mechanismus braucht es einen anderen, komplizierteren, der z.B. so aussehen kann: "exec <PROGRAMM>", also man müsste immer die Anweisung geben: "führ das <PROGRAMM> aus". Aber auch da könnte der Nutzer ja "Daten ausführen lassen", die im besten Fall einfach nur einen Fehler erzeugen, sodass das System einen ungültigen OpCode (also einen Befehl an den Prozessor) meldet, im schlimmsten Fall aber z.B. die Hardware (und die darauf gespeicherten Daten=auf einem angeschlossenen Datenspeicher z.B. auf einer Festplatte) beschädigt.

‣Andreas•⚖ 19:37, 14. Aug. 2023 (CEST)

Überarbeitung: ‣Andreas•⚖ 23:11, 16. Aug. 2023 (CEST)