Compiliert = verschlüsselt? (aus: Forenregeln - Konkretisierung in Sachen technischer Kopierschutz)

[hikaru]

Gemäß Lenovo License Agreement [1] bleibt von Lenovo bereitgestellte Software Eigentum von Lenovo. Der Nutzer erhält nur ein Nutzungsrecht, jedoch keine Eigentumsrechte.

Dort findet sich folgende Passage:

Sie dürfen a) das Softwareprodukt nicht verwenden, kopieren, modifizieren oder verteilen, sofern dies nicht in dieser Vereinbarung vorgesehen ist; b) Reverse-Assemblierung, Reverse-Compilierung oder anderweitige Übersetzung des Softwareprodukts, sofern dies nicht ausdrücklich gesetzlich erlaubt ist, ohne dass eine vertragliche Verzichtserklärung möglich ist; oder 3) Unterlizenzierung, Miete oder Leasing des Softwareprodukts.

Im Falle eines BIOS' ist es also nach dieser Lizenz untersagt, es zu modifizieren, oder es in modifizierter (oder unmodifizierter) Form weiterzugeben.

Eine "Verschlüsselung" ist laut Wikipedia [2]:

die von einem Schlüssel abhängige Umwandlung von „Klartext“ genannten Daten in einen „Geheimtext“ (auch „Chiffrat“ oder „Schlüsseltext“ genannt), so dass der Klartext aus dem Geheimtext nur unter Verwendung eines geheimen Schlüssels wiedergewonnen werden kann.

Nach dieser Definition unterliegt ein aus Quellcode compiliertes Binary einer Verschlüsselung, nämlich der Compilierung.

Ebenfalls laut Wikipedia [3] stellt jede Verschlüsselung einen "wirksamen Kopierschutz" dar:

Wann ein Schutz „wirksam“ ist, ist trotz der gesetzlichen Definition in § 95a Abs. 2 UrhG unter Juristen umstritten. Grundsätzlich jedoch werden Mechanismen, die eine Verschlüsselung beliebiger Art, sei sie noch so leicht zu entschlüsseln, verwenden, schlicht als wirksam definiert (siehe ebendiesen Absatz im UrhG).

Ein BIOS-Binary ist also laut UrhG ein verschlüsseltes Werk, das einem wirksamen Kopierschutz unterliegt. Verschlüsselte Werke dürfen ohne ausdrückliche Erlaubnis generell nicht kopiert werden.
Das wird zwar für Software sogleich wieder eingeschränkt ...

Dieses Verbot greift vor allem für Bild- und Tonträger ein und gilt gemäß § 69a Abs. 5 UrhG nicht für Computerprogramme. Nach § 69d UrhG hat dort der berechtigte Benutzer vielmehr unter bestimmten Voraussetzungen einen Anspruch auf Ermöglichung einer Kopie.

... aber hier wird vom "berechtigten Benutzer" gesprochen. Eine entsprechende Rechteeinräumung seitens Lenovo fand jedoch nie statt (s.o.: kein Eigentumsübergang, explizite Rechtsausschlüsse).

Frage:
Wäre damit nach neuer Forenregel die Diskussion über, und Zugänglichmachung von modifizierten BIOS in diesem Forum verboten?
Falls nein, warum nicht?


[1] https://support.lenovo.com/de/de/solutions/ht104242-lenovo-license-agreement
[2] https://de.wikipedia.org/wiki/Verschlüsselung
[3] https://de.wikipedia.org/wiki/Kopierschutz

 

[MartinMenke]

Eine "Verschlüsselung" ist laut Wikipedia [2]:Nach dieser Definition unterliegt ein aus Quellcode compiliertes Binary einer Verschlüsselung, nämlich der Compilierung.

Ebenfalls laut Wikipedia [3] stellt jede Verschlüsselung einen "wirksamen Kopierschutz" dar:

Ein BIOS-Binary ist also laut UrhG ein verschlüsseltes Werk, das einem wirksamen Kopierschutz unterliegt. Verschlüsselte Werke dürfen ohne ausdrückliche Erlaubnis generell nicht kopiert werden.

Da kann ich aber nicht mitgehen. Ein Compiler verschlüsselt nichts. Einen Rückweg (Entschlüsselung) gibt es nicht. Ein Compiler übersetzt eine Sprache in eine andere Sprache.

 

[hikaru]

Ein Compiler verschlüsselt nichts.

Das hängt eben von der Definition von "Verschlüsselung" ab.
Laut dem Wikipedia-Zitat kann man Compilierung als Verschlüsselung ansehen, denn der vormalige Klartext (=Quellcode) wird mit Hilfe eines Schlüssels (=Compiler-Algorithmus) in einen Geheimtext (=Binary) umgewandelt und ist danach nur nach Entschlüsselung (=Decompilierung) wieder menschenlesbar.

Einen Rückweg (Entschlüsselung) gibt es nicht.

Doch, die Decompilierung.

Ein Compiler übersetzt eine Sprache in eine andere Sprache.

Genau wie es ROT13 tut, ein anerkannter, wenn auch äußerst ineffektiver Verschlüsselungsalgorithmus, oder die Navajo-Sprache, welche die Amerikaner im 2.WK nutzen.

Ok anders forumuliert, man wird kein "Eigentümer" der Software, eh klar. Trotzdem darf man diese verändern. (Siehe diverse Reverse Engineering-Ansichten)

Ja, das kann man so sehen, müsste mMn aber geklärt werden.
Aber auch wenn Reverse-Engineering selbst zum Privatgebrauch erlaubt wäre, bliebe immer noch die Frage, ob das auch für die Verteilung oder Zugänglichmachung (=Diskussion: "Google mal nach XYZ!") von daraus erstellten Werken gilt.

 

[schoerg]

Doch, die Decompilierung.

Das erzeugt aber nicht den Originalcode.

Ja, das kann man so sehen, müsste mMn aber geklärt werden.
Aber auch wenn Reverse-Engineering selbst zum Privatgebrauch erlaubt wäre, bliebe immer noch die Frage, ob das auch für die Verteilung oder Zugänglichmachung (=Diskussion: "Google mal nach XYZ!") von daraus erstellten Werken gilt.

Probleme sehe ich vorallem wenn das mit Gewinnabsicht gemacht wird.

 

[hikaru]

Das erzeugt aber nicht den Originalcode.

Im Idealfall schon. Funktional ist jedenfalls der korrekt decompilierte Quelltext identisch zum Original.

Probleme sehe ich vorallem wenn das mit Gewinnabsicht gemacht wird.

Ja, das ist ein Unterpunkt der zusätzlich geklärt werden müsste, nachdem man grundsätzlich geklärt hat, dass Weitergabe rechtens sein kann.

 

[schoerg]

Im Idealfall schon. Funktional ist jedenfalls der korrekt decompilierte Quelltext identisch zum Original.

Wüsste nicht wo der Idealfall existiert. Mit Bytecode basierten-Sprachen (Java) eventuell, aber selbst da kommt nicht das Original raus. Kompilierung als "Verschlüsselung" zu sehen halte ich für falsch.

 

[MartinMenke]

Im Idealfall schon. Funktional ist jedenfalls der korrekt decompilierte Quelltext identisch zum Original.

Dann hättest Du einen sehr schlechten Compiler..
Complieren ist nicht verschlüsseln, auch wenn Du es behauptest.

 

[Korfox]

Dann hättest Du einen sehr schlechten Compiler..
Complieren ist nicht verschlüsseln, auch wenn Du es behauptest.

Sicher, dass du das richtig verstanden hast?
Wenn der kompilierte Code funktional vom Quellcode abweicht, dann macht entweder der Compiler etwas falsch, oder der Entwickler hat Optimierungsflags gesetzt, die er nicht versteht.
Umgekehrt ist es korrekt, dass sich aus kompiliertem Code in den seltensten Fällen der ursprüngliche Quellcode rekonstruieren lässt (sei es nun, weil Präprozessordirektiven schwer umzukehren sind oder weil Java-Compiler immer bestimmte Optimierungen am Code umsetzen).

 

[hikaru]

Dann hättest Du einen sehr schlechten Compiler..

So? Decompiliere doch mal ein Binary und recompiliere den erzeugten Code! Dann sollten Originalbinary und Recompilat sich exakt gleich verhalten, auch wenn der decompilierte Code sich vom Originalcode im "Wortlaut" unterscheidet.

Ich vermute, du willst auf Compileroptimierung hinaus. Nicht umsonst ist diese optional, denn sie ist fehleranfällig. Ein nicht optimiertes Compilat und ein Optimiertes sollten das gleiche Ergebnis erzeugen, sonst liegt ein Compilierungsfehler vor.

Complieren ist nicht verschlüsseln, auch wenn Du es behauptest.

Mag sein oder auch nicht. Letztendlich ist es aber unerheblich was ich darüber denke.
Entscheidend ist, was Lenovo, die Forenleitung und die Justiz darüber denken.
Ich meine ich habe schlüssig dargelegt, wie man zu der Überzeugung kommen könnte, dass Compilierung im Kontext von Vervielfältigungsrechten juristisch als Verschlüsselung angesehen werden kann.
Sollte die von @ahoellrigl zitierte Regeländerung kommen, dann muss sich die Forenleitung in die eine oder andere Richtung zum Thema BIOS-Mods positionieren. Und ich hätte gern, dass man darüber nachdenkt, bevor so eine Regel festgesetzt wird.

 

[schoerg]

So? Decompiliere doch mal ein Binary und recompiliere den erzeugten Code! Dann sollten Originalbinary und Recompilat sich exakt gleich verhalten, auch wenn der decompilierte Code sich vom Originalcode im "Wortlaut" unterscheidet.

Ich vermute, du willst auf Compileroptimierung hinaus. Nicht umsonst ist diese optional, denn sie ist fehleranfällig. Ein nicht optimiertes Compilat und ein Optimiertes sollten das gleiche Ergebnis erzeugen, sonst liegt ein Compilierungsfehler vor.

Zeig uns doch mal vor wie das geht.

Mag sein oder auch nicht. Letztendlich ist es aber unerheblich was ich darüber denke.
Entscheidend ist, was Lenovo, die Forenleitung und die Justiz darüber denken.
Ich meine ich habe schlüssig dargelegt, wie man zu der Überzeugung kommen könnte, dass Compilierung im Kontext von Vervielfältigungsrechten juristisch als Verschlüsselung angesehen werden kann.

Warum machst du dann diesen Nebenschauplatz mit "Kompilieren = Verschlüsseln" auf? Man kann auch sonstige abstruse Sachen als "Verschlüsselung" verschwurbeln, ROT13 wurde ja schon genannt.

 

[Korfox]

Ich finde die Frage durchaus interessant, ob ein Kompilat als verschlüsselt angesehen werden sollte, oder nicht.
Die Aussage, dass die meisten Menschen daraus nichts mehr lesen können ist korrekt.
Wenn das nicht als verschlüsselt gilt, gilt dann das Kompilat eines Codes über den ein Obfuscator gelaufen ist als verschlüsselt (auch, wenn beim Obfuscator oft der Nebeneffekt der Codeverkleinerung der Hauptgrund ist, dass er angewandt wird)?
Ist er verschlüsselt, wenn er mit einer anerkannten Cipher verschlüsselt wurde, der Schlüssel aber in einer INI (o.ä.) mitgeliefert wird, damit der unverschlüsselte Teil der Executable damit den Code entschlüsseln kann?
Ist er verschlüsselt, wenn der mitgelieferte Schlüssel verschleiert oder verschlüsselt wurde (wobei wir immernoch an der Stelle sind, dass in einem un"verschlüsselten" Programmcode-Bestandteil einsehbar ist, wie man den Code entschlüsseln kann.
Oder gilt als verschlüsselt erst, wenn der Code unter Zuhilfenahme des TPM verschlüsselt wurde, oder unter Zuhilfenahme einer assymetrischen Cypher und der benötigte Key dann per Internet in die Register geladen wird (hallo DRM), von wo er quasi nicht auslesbar ist, weil das dann kein normalsterblicher mehr per Hand dechiffrieren kann?

Aber tatsächlich tut das nichts zur Fragestellung und ist vielleicht eher einen eigenen Thread wert.

 

[albert66]

Ich habe in den 70ern Compiler-Internals für den Service unterichtet (PL/1, Algol, Cobol, FORTRAN), einige weitere kenne ich intern. Eine reine Compilierung hat mit Verschlüsselung nichts am Hut. Nach einigen sog. Phasen oder Stufen steht am Ende (Compiler-Output) ein Maschinen-lesbarer Code (Datei), d.h. unter der Ägide des Betriebssystems ausführbarer Code. Eine andere Baustelle sind Interpreter, die die Ausführung direkt übernehmen (Script-Sprachen,....). Der vom Compiler erzeugte Code kann verschlüsselt werden, wenn anschließend der Programm-Loader (des BS oder auch ein Firmware-Loader) für die CPU lesbar decodiert. Das ist normalerweise nicht üblich, sondern das compilierte Ergebnis wird unverschlüsselt in den Speicher geladen und ausgeführt. Das ist bei µ-Code nicht anders als bei CPU-lesbarem Code. (Linker habe ich übersprungen, der ist i.d.R. auch noch beteiligt und könnte ebenfalls verschlüsseln. I.d.R. verknüpft der nur weitere Programme/Code.)

Wiki ist nicht der Nabel der Welt und Compilierung ist nicht automatisch eine Verschlüsselung, nur weil ein Jurist den erzeugten Code nicht lesen kann. Den Umwandlungs-Algorythmus bestimmt kein Schlüssel, sondern die CPU (Befehlssprache), die das Ergebnis ausführen muß.

Reverse-Engineering in jeder Form mögen S/W-Hersteller nicht so gerne, hat auch mit Dekodierung einer Verschlüsselung nichts zu tun.

Zum ersten Post, Vorschlag (Korrektur):
Nicht zulässig sind hierbei auch Anleitungen zur Umgehung von Kopierschutzmaßnahmen.

 

[Korfox]

Ich habe in den 70ern Compiler-Internals für den Service unterichtet (PL/1, Algol, Cobol, FORTRAN), einige weitere kenne ich intern.
[...]
Wiki ist nicht der Nabel der Welt und Compilierung ist nicht automatisch eine Verschlüsselung, nur weil ein Jurist den erzeugten Code nicht lesen kann.

Recht wird nicht von Dozenten für Compiler-Interna der 70er gesprochen, sondern von Richtern, die im Glücksfall einen Experten als unabhängigen Gutachter hinzuziehen, der sich mit dem Thema auskennt. Und Richter interpretieren folglich, was Recht und Unrecht ist, insofern dies nicht bereits eindeutig durch Gesetzestexte geregelt ist.
Genau deswegen habe ich den obigen Beitrag so ausführlich geschrieben, ab wann etwas als verschlüsselt gilt.
Für den Juristen sieht das Kompilat eben nicht anders aus, als das verschleiert Kompilat, als das verschlüsselte Kompilat.
Also bezeichnet er wahrscheinlich alle drei Varianten als wirkungsvoll verschlüsselt, oder aber er würde auch das verschlüsselte Kompilat nicht als wirkungsvoll verschlüsselt ansehen, insofern die Entschlüsselung wieder nachvollzogen werden kann.

Inwiefern jetzt Compiler, Interpreter und Bytecode unterschiedliche Baustellen sind, wenn schon Compiler-Output nicht als verschlüsselt betrachtet werden kann interessiert mich auch. Interpreter-Input kann dann wohl erst recht nicht als verschlüsselt betrachtet werden. Unabhängig, ob er in Klartext oder Bytecode vorliegt.

Ansonsten ist Wiki zwar kein Nabel der Welt und auch nicht zitierfähig, aber oft eine gute Anlaufstelle um an Primärquellen zu gelangen.

 

[hikaru]

Zeig uns doch mal vor wie das geht.

Um das sauber zu machen, fehlen mir leider die Kenntnisse. Daher nur als "unsauberer Proof of Concept":

Angenommen, wir haben Hello World in Assembler-Code als Original:

        SECTION .data
msg:    db "Hello World"

        SECTION .text
        global _start

_start:

        mov     edx,11
        mov     ecx,msg
        mov     ebx,1
        mov     eax,4
        int     0x80

        mov     ebx,0
        mov     eax,1
        int     0x80

Wenn wir das assemblieren und linken, dann können wir es ausführen:

$ nasm -f elf64 hello.asm 
$ ld -o hello hello.o
$ ./hello 
Hello World

Wir können das auch wieder disassemblieren:

$ objdump -M intel -d hello > disassembly.asm

Und erhalten dann diesen "Code":

$ cat disassembly.asm

hello:     file format elf64-x86-64


Disassembly of section .text:

0000000000401000 <_start>:
  401000:	ba 0b 00 00 00       	mov    edx,0xb
  401005:	b9 00 20 40 00       	mov    ecx,0x402000
  40100a:	bb 01 00 00 00       	mov    ebx,0x1
  40100f:	b8 04 00 00 00       	mov    eax,0x4
  401014:	cd 80                	int    0x80
  401016:	bb 00 00 00 00       	mov    ebx,0x0
  40101b:	b8 01 00 00 00       	mov    eax,0x1
  401020:	cd 80                	int    0x80

Zugegeben, das lässt sich nicht direkt wieder assemblieren, was an meiner Stümperei liegen mag, aber der Code macht funktionell das Gleiche wie das Original. Es fehlt allerdings der Inhalt, das "Hello World".

Den Inhalt kriegen wir von einem Hexeditor aus dem Originalcompilat:

File: hello                       ASCII Offset: 0x00002000 / 0x000022B7 (%92)  
00002000  48 65 6C 6C  6F 20 57 6F   72 6C 64 00  00 00 00 00   Hello World.....
00002010  00 00 00 00  00 00 00 00   00 00 00 00  00 00 00 00   ................

Daraus lässt sich händisch der ursprüngliche Assemblercode rekonstruieren, assemblieren, linken und ausführen.

Zugegeben, ich habe etwas geschummelt, denn ich wusste beim Blick in den Hexeditor, das ich nach "Hello World" suche. Lieber wäre es mir zu Demonstrationszwecken gewesen, die Speicheradresse (0x2000) direkt im decompilierten Code zu finden (0x402000 ist "knapp" daneben), aber der springende Punkt bleibt:
Aus den Originalbinary lässt sich prinzipiell Quellcode gewinnen, der compilierbar ist und dessen Compilat das Gleiche macht wie das Original-Binary. Der Prozess erfüllt also das "Entschlüsselungs"-Kriterium aus der Wikipedia-Defiition zur Verschlüsselung.

Warum machst du dann diesen Nebenschauplatz mit "Kompilieren = Verschlüsseln" auf?

Weil "wirksame Verschlüsselung" nach UrhG bei geeigneter Definition ein Vehikel sein kann um Decompilierung, oder zumindest die Verbreitung von Werken die so entstanden sind, gesetzlich zu verbieten. Und wenn man als Forenbetreiber juristische Fachbegriffe in seine Forenregeln schreibt, dann sollte man vorher überlegt haben, wohin einen diese Begriffe führen können, wenn ein Jurist mit Agenda darüber stolpert.

Ich habe in den 70ern Compiler-Internals für den Service unterichtet (PL/1, Algol, Cobol, FORTRAN), einige weitere kenne ich intern. Eine reine Compilierung hat mit Verschlüsselung nichts am Hut.

Das siehst du als Techniker so, aber ein Jurist könnte das anders sehen. Und ich habe versucht darzulegen, warum.
Seit deinem Unterricht in den 70ern hat ein gewisser Richard Matthew Stallman (und seitdem viele Andere) juristische Winkelzüge zu Software so in sich selbst verbogen, dass sie am Ende das Gegenteil von dem taten, wozu sie gedacht waren:
Die Möglichkeiten dessen was der Nutzer mit "seiner Software" tun kann zu erweitern oder zumindest zu sichern, anstatt sie einzuschränken.

 

[albert66]

Ich habe nicht in den 70ern meinen Beruf aufgegeben. Die Dozentenstelle war ein mehrjähriger Rotationsjob und ich war danach noch lange genug im Service. Ich habe auch genügend disassembled, reengineered und im Maschinencode sowie µcode herum gestochert, auf dem Level Fixe gebaut etc. (bis vom Labor ein endgültiger Fix kam). Ganz legal zur Fehlerbehebung vor Ort. Z.T. mache ich es heute noch auf den eigenen PCs im Fehlerfall. Zu Lizenzproblemen & Co hatte ich genügend selber beraten müssen und auch mit Juristen (hauseigenen und der Kunden) zu tun.

Man kann mit reengineering den Funktionablauf in einem Ersatzprogramm wieder herstellen, aber es gibt keine Garantie von einem compilierten Programm den Original-Quellencode 1:1 wieder her zu stellen. Der Algorithmus des Compilers zur Umwandlung des Quellcodes ist nicht eineindeutig definiert und damit kein Chiffrier-Schlüssel. Er ist nicht einmal ein fest definiertes Verfahren wie bei der Berechnung von Bank-Pin-Nummern.

Ich habe mir den Thread und die Referenzen angesehen und finde keine Definition, Urteil, oä., daß Compilierung = Verschlüsselung gilt. Sorry, kann ich natürlich übersehen haben. Herrn Stallmann kenne ich auch nicht. Wir sind ziemlich OT geworden und zum Thread-Problem habe ich bereits einen minimal geänderten Vorschlag gemacht.

 

[moronoxyd]

Ausgelagert aus https://thinkpad-forum.de/threads/f...ng-in-sachen-technischer-kopierschutz.232941/

 

[ahoellrigl]

Sollte die von @ahoellrigl zitierte Regeländerung kommen, dann muss sich die Forenleitung in die eine oder andere Richtung zum Thema BIOS-Mods positionieren. Und ich hätte gern, dass man darüber nachdenkt, bevor so eine Regel festgesetzt wird.

Nach meinem Verständnis sollte die Kompilierung eines Quellcodes keine wirksame technische Maßnahmen zum Schutz eines nach diesem Gesetz geschützten Werkes oder eines anderen nach diesem Gesetz geschützten Schutzgegenstandes gemäß § 95a UrhG darstellen, da das Kompilieren zu dem Zweck erfolgt, das Programm auf einer Maschine ablaufen lassen zu können. Nicht, um ein Kopieren des Quelltextes zu verhindern. Ergo ist es keine Kopierschutzmaßnahme.

Die von mir formulierte Ergänzung der Regeln ist nicht als Änderung gemeint, sondern beschreibt das, was die Mods ohnehin bereits durchsetzen, was aber im bisherigen Regeltext nicht sauber beschrieben ist. Siehe dazu auch meinen ergänzenden Beitrag im Thread bei den Anregungen.

Beitrag automatisch zusammengeführt: 13 Mai 2022

Zur Ergänzung noch (war in der Nacht zu faul zum Suchen): Im Urheberrechtsgesetz gibt es einen eigenen Abschnitt 8 mit besonderen Bestimmungen für Computerprogramme. Und darin sowohl den § 69e mit speziellen Regelungen für eine Dekompilierung wie auch den § 69f, in dem auf technische Programmschutzmechanismen Bezug genommen wird. Es wird jedoch nirgends ein Zusammenhang zwischen technischen Kopierschutzmaßnahmen und dem Vorgang des Kompilierens/Dekompilierens hergestellt. Also sind das auch nach eingehenderer Betrachtung zwei im Sinne des Urheberrechtsgesetzes unterschiedliche Sachverhalte.

Soll heißen: Durch die vorgeschlagene Regelerweiterung ergibt sich keine Änderung der Forenpolitik in Bezug auf Diskussionen über dekompilierten/modifizierten BIOS-Code.

 

[ggrohmann]

Das hängt eben von der Definition von "Verschlüsselung" ab.
Laut dem Wikipedia-Zitat kann man Compilierung als Verschlüsselung ansehen, denn der vormalige Klartext (=Quellcode) wird mit Hilfe eines Schlüssels (=Compiler-Algorithmus) in einen Geheimtext (=Binary) umgewandelt und ist danach nur nach Entschlüsselung (=Decompilierung) wieder menschenlesbar.

Du hast da ein wichtiges Wort übersehen: geheimer Schlüssel. Was der Compiler macht, ist nicht zwingend auch geheim. Auf den gcc beispielsweise sollte das nicht zutreffen. Und ein Compiler veschlüsselt auch nichts, er übersetzt. Bei Kenntnis der "Maschninensprache" ist das Ergebnis auch menschenlesbar.

 

[andi.short]

Ganz genau. Es gibt Menschen, die lesen und ändern ein Binary ganz ohne Decompiler und (geheimen) Schlüssel. Das passt dann nicht mehr zu dieser durchaus eigenartigen Definition.

 

[albert66]

Ich habe mir (begrenzt) die Mühe gemacht, was Wiki zu "Compiler" schreibt (https://de.wikipedia.org/wiki/Compiler).

Ein Compiler (auch Kompilierer; von englisch compile ‚zusammentragen‘ bzw. lateinisch compilare ‚aufhäufen‘) ist ein Computerprogramm, das Quellcodes einer bestimmten Programmiersprache in eine Form übersetzt, die von einem Computer (direkter) ausgeführt werden kann. Daraus entsteht ein mehr oder weniger direkt ausführbares Programm. Davon zu unterscheiden sind Interpreter, etwa für frühe Versionen von BASIC, die keinen Maschinencode erzeugen.

Das ist eigentlich alles, was es dazu als Definition braucht. Es wird von dem Quellcode eine Maschinencode erzeugt, der ohne separate Verschlüsselung öffentlich lesbar ist.

Jetzt hat mich @andi.short etwas aus dem Konzept gebracht. Ja, diese Menschen gibt es (noch), die haben früher damit die Familie ernährt. Das war in den 60er und 70er Jahren üblich, als es zur Fehlersuche sehr wenig Hilfsmittel gab. Wir (Service, ich war bei IBM mitten drin) hatten die Maschinensprache "eingebrannt" und die Fehler per Speicherauszug auf Papier gedruckt vor uns, typischer Dump so 30-50cm hoch, etwa A3 Querformat, links der Hexcode und rechts ein schmaler Streifen Textformat der Zeile. Wurde relativ schnell durch Analysetools und Arbeit am Bildschirm ersetzt.

Ist etwas OT, aber jedenfalls ist das zur Ausführung erforderliche Programm für die CPU lesbar und damit auch für jeden, der die CPU-Sprache versteht. Es ist denkbar, aber m.W. bisher (noch) nicht üblich, daß Programme verschlüsselt werden und von der CPU wieder zur Ausführung entschlüsselt werden. Das ist natürlich genau so gut möglich wie eine Datenverschlüsselung. D.h. Ich habe mich noch nicht damit beschäftigt, was mit Programmen auf einer verschlüsselten HD passiert. Zur Ausführung müßten die jedenfalls wieder für die CPU lesbar an das Rechenwerk gelangen (entschlüsselt). Kommt vielleicht alles noch ...........