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

hikaru

Rather active member
Themenstarter
Registriert
1 Okt. 2013
Beiträge
2.080
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
 
Letztendlich ist doch die Antwort schon gefallen. Technisch betrachtet übersetzt ein Compiler von einer Sprache in eine andere. Dabei muss es nicht mal von einer Hochsprache in Maschinencode sein. Ich persönlich stolperte schon über Fortran nach C Compiler und die ersten C++ ging auch über C. So erschloss man für unterschiedliche Hardware ein Softwarepool sobald ein C Compiler gebaut war.

Danach soll jeder Entscheiden was Übersetzen sonst noch ist. Englischen Songtext nach Deutsch übersetzt. Was ist das? Für jeden der kein Deutsch spricht ist es wohl auch "Verschlüsselung". Bekommt man den Text im Original wieder wenn man die Deutsche Übersetzung wieder nach Englisch übersetzt? Kann man den übersetzten Text um- oder weiterschreiben?
 
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.
Gibt es in der Tat schon sehr lange und in verschiedenen Varianten. Eine andere Form ein Binary unleserlich zu machen ist es zB als zip zu packen und während der Laufzeit wieder zu entpacken, was der Definition der Verschlüsselung schon deutlich näher kommt als eine Übersetzung.
 
Wenn man mal ein bischen den Pfad der PC-Technik verläßt kommt man beispielsweise bei embedded Systemen immer noch mit dem Lesen des Maschinencodes zurecht.

Verschlüsselte Programme sind sogar gar nicht mal so unüblich. So kann man stored procedures in einer Oracle-Datenbank verschlüsseln, so daß deren Quellcode nicht mehr lesbar ist. Die Programme können aber trotzdem abgearbeitete werden und man kann sich sogar ihre Paramater anzeigen lassen, damit man weiß, wie man die aufzurufen hat.

Und dann gibts noch einen Ausleseschutz für Programm in embedded Controllern. Die kann man nur neu programmieren, aber das Programm nicht auslesen.
 
Ich habe mal etwas die Begriffe durchsortiert. An sich sind wir vom Thema durch. Der Compiler übersetzt in Maschinencode und fertig. Die Verwirrung kommt evtl. durch weiter Funktionen, die aber mit "Kompilieren" nichts zu tun haben.

Da Speicher früher sehr knapp war (CPU-storage und HD) hat man sehr schnell auch den (lesbaren) Programmcode gepackt (ähnlich den Zip Formaten). Der Loader (oder tools wie Disassembler) konnten den wieder entpacken. Im Speicherauszug war er immer lesbar, auf der HD als File direkt nur ungepackt. Dies Pack-Algorithmen sind öffentlich (nachvollziehbar ohne Schlüssel), d.h. gelten nicht als Chiffrierung. Allerdings waren die Packprogramme durchaus in der Lage, mit dem Packen gleichzeitig zu verschlüsseln. Das passiert(e) oft bei Auslieferung der Programme (auch in Packages), die dann per Installer mundgerecht mit dem Betriebssystem verbandelt wurden.

Bspl. Word hat anfangs in lesbarem Code gespeichert, irgendwann dann gepackt. Ungepackter Code/Text war natürlich leichter zu restaurieren im Crash-Fall. Gleiches gilt für verschlüsselte Daten/Programmcode - deshalb war Chiffrierung außer bei notwendigen Accountdaten nicht sehr beliebt. Zugriffsbeschränkungen (Lese-/Schreibschutz) gab es von Anfang an bei Multiprogramm-fähigen Betriebssystemen. Ganz am Anfang (-60er) lief auch auf den Mainframes zu einer Zeit nur ein Programm). Mit Multiprogramming wurden Zugriffe auf Speicher (und Daten/Programme) beschränkt. Leseschutz war von Anfang an mit dabei. Die Daten/Erlaubnis für Zugriffe wurden anfangs nur per Userid/Password geschützt, später dann verschlüsselt. Die klassischen Fehlercodes (bis heute) waren Zugriffsfehler auf geschütze Bereiche/Daten.

Zu Zip, weil es erwähnt wurde: es gab zum Zip-Programm einige Zeit Chiffrier-fähige Versionen, die das Pack-Produkt chiffrieren konnte. Funktionierte ähnlich heutigem PDF-Password-Schutz. Die durfte außerhalb USA nicht ausgeliefert/benutzt werden, wegen Exportbeschränkungen. Ich weiß den aktuellen Stand nicht, muß ich mal demnächst recherchieren. Solche IT-Exoten gab es immer wieder - H/W und S/W.

Falls ich Eulen nach Athen getragen habe, bitte überlesen/vergessen. Ist etwas Historie. Manche Begriffe werden heute ohne Hintergrundwissen bzw. Historie verwendet, und dann gibt es Mißverständnisse.
 
Danke für die technischen Hintergrundinformationen. Da wird dann auch noch klarer ersichtlich, dass eine Verschlüsselung als solche ein Schutz gegen unbefugte Einsichtnahme ist, aber noch keine Kopierschutzmaßnahme. Allerdings kann sie dann auch ein Teil einer Kopierschutzmaßnahme sein, wenn sie mit anderen Maßnahmen gekoppelt ist, die den Vorgang des Kopierens unterbinden.
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben