Schutz der Urheberschaft von MQL-Code in MT5.

 

Das Problem des Schutzes von MQL-Programmen wurde in diesem Forum bereits mehrfach angesprochen.

Warum nehmen die Entwickler nicht eine Verifizierung (Entschlüsselung oder etwas anderes) in die Sprachwerkzeuge auf, indem sie das vom Autor der Anwendung ausgestellte Benutzerzertifikat verwenden?

Erweitern Sie zum Beispiel die Liste der #EigenschaftSicherheitszertifikate <......>.


MQL-Code mit dieser Eigenschaft konnte nur durch ein vom Eigentümer des Quellcodes ausgestelltes Zertifikat in eine brauchbare Form übersetzt werden.
 

Wir haben bereits eine Reihe von Schutzmaßnahmen speziell für erfahrene Entwickler. Wir werden sie zu einem späteren Zeitpunkt bekannt geben.


Ihre Idee ist gut, und sie kann umgesetzt werden.


Bitte teilen Sie uns mit, wenn Sie mitbestimmen möchten, wie Sie geschützt werden möchten.

 
Renat :

Wir haben bereits eine Reihe von Schutzmaßnahmen speziell für erfahrene Entwickler. Wir werden sie zu einem späteren Zeitpunkt bekannt geben.


Ihre Idee ist gut und sie kann umgesetzt werden.


Bitte teilen Sie uns mit, wie Sie es umsetzen möchten.



Ich danke Ihnen!

Ich denke, wenn Sie einen Mechanismus zur Erstellung eines solchen Zertifikats auf der Grundlage einer Kreuzung zwischen einem Info-Zertifikat eines Herausgebers und einem Nutzerzertifikat schaffen würden, gäbe es weniger Fragen zum Schutz kommerzieller Produkte.

 

Das Hauptproblem ist die theoretische Möglichkeit der Dekompilierung. Wenn dieses Problem gelöst ist, müssen all die komplexen Sicherheitsmethoden nicht implementiert werden. Nur die in das MMS eingebauten Werkzeuge sind ausreichend.

Leider wurde F4 entschlüsselt und der Decompiler ist im Internet frei zugänglich. Das Gleiche kann mit dem fünften passieren, wenn die Entwickler nicht den entsprechenden Schutz implementiert haben, ich meine den Schutz des Terminals vor Debugging und Dekompilierung. Außerdem habe ich irgendwo gesehen, dass MQL5-Code in nativen CPU-Code kompiliert wird. Ich weiß nicht, ob das wirklich so ist oder nicht, aber wenn ja, dann ist das eine ernsthafte Lücke im Dekompilierungsschutz.

Generell bin ich ziemlich skeptisch, was den Schutz vor Dekompilierung durch EA/Indikatoren angeht. Ich denke, das ist wahrscheinlich ein unerreichbarer Traum.

 

Ein Debugging-Schutz ist nicht erforderlich, wenn der Skriptcode mit einem (starken) Schlüssel verschlüsselt ist, der an den jeweiligen Käufer des Skripts ausgegeben wird. Die Algorithmen von PGP zum Beispiel sind quelloffen.

Ein weiterer Punkt ist, dass ein skrupelloser Käufer seinen Schlüssel veröffentlichen könnte. Eine zentrale Online-Datenbank mit kommerziellen Skripten und ihren Käufern, die über einen speziellen Webdienst oder MT-Server zugänglich ist, könnte wahrscheinlich dazu beitragen, solche Dinge zu verhindern, aber es gibt eine Menge zu bedenken.

 
marketeer :

Sie brauchen keinen Debugging-Schutz, wenn der Skriptcode mit einem (starken) Schlüssel verschlüsselt wird, der an den jeweiligen Käufer des Skripts ausgegeben wird. Die Algorithmen desselben PGP sind zum Beispiel quelloffen.

Ein weiterer Punkt ist, dass ein skrupelloser Käufer seinen Schlüssel veröffentlichen könnte. Eine zentrale Online-Datenbank mit kommerziellen Skripten und ihren Käufern, die über einen speziellen Webdienst oder MT-Server zugänglich ist, könnte wahrscheinlich dazu beitragen, solche Dinge zu verhindern, aber es gibt eine Menge zu bedenken.



Offensichtlich haben Sie den Beitrag über "Kreuzungen" nicht gelesen. Ein skrupelloser Käufer wird gezwungen sein, seine Rechnung ebenfalls zu begleichen. und nur in einer Hand. ;)

Immerhin handelt es sich um EX5-Dateien.

 
marketeer :

Ein Debugging-Schutz ist nicht erforderlich, wenn der Skriptcode mit einem (starken) Schlüssel verschlüsselt ist, der an den jeweiligen Käufer des Skripts ausgegeben wird. Die Algorithmen von PGP zum Beispiel sind quelloffen.

Ein weiterer Grund ist, dass ein skrupelloser Käufer seinen Schlüssel veröffentlichen könnte. Eine zentralisierte Online-Datenbank mit kommerziellen Skripten und ihren Käufern, die über einen speziellen Webdienst oder MT-Server zugänglich ist, wird wahrscheinlich dazu beitragen, solche Dinge zu verhindern, aber es ist eine Überlegung wert.

Sie haben offensichtlich ohne nachzudenken geschrieben.

Der Decompiler für Quadruple wurde als Ergebnis der Analyse, Fehlersuche und Dekompilierung des MT4-Terminals geschrieben. Und wenn nur echte Programmierprofis diese Aufgabe bewältigen können, so ist die Verwendung des Decompilers für jeden Anfänger klar. Keine Verschlüsselung wird verlässliche Ergebnisse liefern, weil ein "unehrlicher Kunde" die Schlüssel, die er hat, beim Dekompilieren der EX5-Datei verwenden kann.

Wenn Sie zum Beispiel das Recht erworben haben, einen Expert Advisor einen Monat lang zu nutzen, einen Utility-Decompiler aus dem Internet heruntergeladen haben, ihn gestartet und den Schlüssel angegeben haben, den Sie haben... und den Quellcode des Expert Advisors erhalten haben. Sie haben den gesamten Schutz entfernt und können ihn ein Leben lang nutzen und über Ihre Website verkaufen.

Der Dekompilierungsschutz des Terminals wird es zumindest erschweren, ein Dienstprogramm zur Dekompilierung von EX5-Dateien zu schreiben.

 
api :

Sie haben offensichtlich ohne nachzudenken geschrieben.


Das Russellsche Paradoxon.

;)

Das ist urkomisch.)

 

Worin besteht hier das Russellsche Paradoxon?

 
api :

Worin besteht hier das Russell-Paradoxon?


Ein Schutz gegen die Dekompilierung des Terminals in einer Windows-Umgebung ist nach Ihrer Logik ebenfalls unmöglich.

 
Sorento :


Die Dekompilierung des Schutzes in einer Windows-Umgebung ist nach Ihrer Logik ebenfalls unmöglich.



Was der eine aufgebaut hat, kann der andere zerstören.

Einen absoluten Schutz gibt es streng genommen nicht und wird es auch nie geben.

Deshalb schrieb ich: "Im Allgemeinen bin ich sehr skeptisch, was den Schutz vor der Dekompilierung von EAs/Indikatoren angeht. Ich denke, das ist wahrscheinlich ein unerreichbarer Traum".

Grund der Beschwerde: