Schutz der Urheberschaft von MQL-Code in MT5. - Seite 7
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
zum Beispiel
Käufer: findet Informationen im Internet, schreibt und will kaufen
Verkäufer: Beschreibt den Zahlungsmechanismus - wenn Sie die Zahlungsdaten nicht weitergeben möchten, werden Sie aufgefordert, Ihre persönlichen Daten anzugeben.
der Käufer: bezahlt und sendet die Personalisierungsdaten, die Kontonummer oder den vollständigen Namen, die den Schlüssel darstellen
Verkäufer: versendet die den persönlichen Daten zugeordneten Waren.
Das war's im Idealfall!
Ich habe solche Fälle, und nicht wenige
Leider macht dies das Leben für einige Trittbrettfahrer (Personen, die sich in der Materie befinden) nicht einfacher. Auch die Bindung an ein Konto ist nicht die Lösung aller Probleme, denn jeder kompetente "Transaktionskopierer" überträgt alle Daten auf ein anderes Konto (insbesondere wenn die Daten von MT5 zu MT5 kopiert werden).
Meiner Meinung nach sollten nicht nur Experten, sondern auch Skripte, Indikatoren, Bibliotheken und anderer Code geschützt werden. Meiner Meinung nach ist dies ein interessanteres und wichtigeres Thema.
Warum ist sie wichtiger?
Wie wir wissen, werden alle Tools, die mit MQL implementiert werden können, unterteilt in: automatische Systeme, halbautomatische Systeme und Tools für den manuellen Handel.
Es gibt auch eine Unterteilung in Systeme: "Black Boxes", "Gray Boxes" und "weiße" Systeme (Systeme mit offenem Quellcode und klar beschriebener Logik).
Daher werden fast alle MTS, die im kommerziellen Sektor angeboten werden, schwarze oder graue Kästen sein. Ihr spezifisches Gewicht wird nicht so groß sein (ich denke, es wird 30-40 % nicht überschreiten). Gleichzeitig sind solche Lösungen ziemlich unflexibel (weil sie im Wesentlichen nur eine Strategie umsetzen).
Separate Skripte, Bibliotheken und Indikatoren sind eine andere Sache. Diese Softwarelösungen werden in allen Bereichen des manuellen und mechanischen Handels präsent sein. Gleichzeitig können sie als Basiselemente des Konstruktors verwendet werden.
PS
Hier ist es meiner Meinung nach notwendig, den Schutz zu maximieren und die Rechte der Entwickler und Nutzer nicht zu verletzen. Der einzige optimale Schutz in diesem Fall ist meines Erachtens nur einer: die Bindung an die Hardware.
Was auch immer Sie sich denken mögen, die Bindung an Hardware ist kein wirksamer Schutz mehr. Übrigens: Für eine Person, die sich kaum mit Asmus auskennt (und davon gibt es nicht wenige), ist die Entfernung eines solchen Schutzes eine Sache von Minuten. Und es spielt keine Rolle, woran Sie sich binden wollen. Lesen Sie Programmier- (bzw. Hacking-) Foren und alles wird Ihnen klar werden. :) Und was die "gute Organisation" anbelangt, versuchen Sie versuchsweise, einen Teil Ihrer Massenproduktion an die Hardware zu binden, und ich bin sicher, dass Sie nach einer Weile (etwa ein oder zwei Monate) verstehen werden, was ich Ihnen sagen wollte.
Als ob es noch andere Schutzmöglichkeiten gäbe?
Ich bin überrascht, dass du das fragst. Natürlich gibt es die. Und zwar jede Menge. Von einfachen Recodern über Lizenzgeneratoren bis hin zu Hardware-Software-Schutzmethoden wie HASP usw. Aber fast alle von ihnen, unabhängig von ihren Kosten und ihrer erklärten Zuverlässigkeit, sind längst geknackt worden, und Crack-Codes, Keygenes und andere Software laufen im Internet frei zugänglich herum. Und ich wage zu behaupten, dass diese Schutzmethoden um mehrere Größenordnungen zuverlässiger sind als die einfache Bindung an die Hardware.
Im Rahmen von MT4/MT5 MQL4/MQL5 + DLL kann die Bindung nicht an die Hardware erfolgen, sondern an die Kontonummer (n), für Real- und/oder Familienname, alternativ zweiter Vorname
Dieser Weg ist der einfachste in Bezug auf die Sicherheit (für diese spezielle Situation) - er ist mobil und erfordert keine Bindung an die Hardware.
Zu Beginn dieses Threads hatten wir ('jeder'!) unser eigenes Zertifikat von Metakwots ausgestellt bekommen. Es ist klar, dass es sich hierbei noch nicht um eine anerkannte Zertifizierungsstelle handelt. Aber dieses Thema (Ausstellung und Verwaltung von Zertifikaten) ist ins Stocken geraten, obwohl 4 angeblich über eine solche Authentifizierungsmöglichkeit verfügt.
Eine Bindung an Hardware zum Schutz der Urheberschaft ist daher meines Erachtens ein "tiefer" Rückschritt.
Die Idee (auf den ersten Seiten) war, den "normalen" Kompilierungsalgorithmus für die ex5-Datei zu implementieren.
Der Traum sieht ungefähr wie folgt aus.
Der Programmierer ist in der Lage, sein Programm so zu kompilieren, dass es nur bei Vorhandensein eines Trace-Subkeys - einer komplexen Verkettung des Schlüssels des Entwicklers und des Benutzers - vom Terminal genau wahrgenommen werden kann.
Die notwendigen Signaturen des Entwicklerschlüssels würden sowohl im Programm als auch im Benutzerschlüssel im Programm und im Schlüssel auf dem spezifischen Terminal sitzen.
Dann würde das Vorhandensein dieses "Lizenz-Unterschlüssels" seine Verwendung ermöglichen.
Die Generierung sollte durch den Meta-Editor erfolgen, d.h. durch den Entwickler selbst, der einen Teil des Schlüssels vom Kunden erhalten hat.
So wurde es sich vorgestellt...
Aber irgendetwas kommt nicht aus dem Nebel heraus.
Mir scheint, dass die Möglichkeit, den Schlüssel des Entwicklers von der Zertifizierungsstelle "МТ5" zu generieren, und das Vorhandensein von ex5-Entschlüsselungsverfahren im Terminal, die diesen Schlüssel und einen Teil des Schlüssels des Benutzers verwenden, mehr Probleme lösen würde als dieser "native Dienst", dessen Mechanismen und Angemessenheit hier überhaupt nicht diskutiert werden können.
;)
Wenn es um den Schutz von Schlüsseln geht, wird das gesamte Internet mit genau diesen Schlüsseln überflutet. Mit anderen Worten, statt eines Schutzes wird es sich um eine Scheinlösung mit einer komplexen Implementierung handeln, die den Käufer zwingt, die Schlüssel zu verwalten.
Der beste Weg ist ein Blick auf Apples AppStore/iTunes-Verkaufssystem, das funktioniert. Der Kunde klickt sich einfach ein und kauft die Software, ohne dass er Schlüssel übertragen oder verwenden muss. Ein Kunde muss nur ein MQL5.com-Konto haben, um die Kaufhistorie zu behalten und zuvor gekaufte Software zu reaktivieren.
Beim Kauf eines Programms erhält der Benutzer eine speziell rekompilierte/geschützte Kopie, die den Verkäufer viel besser schützt als Schlüssel. Der gesamte Prozess des persönlichen Schutzes wird zum Zeitpunkt des Kaufs automatisch erfolgen.
Unser Ziel ist es, den Kauf-/Verkaufsprozess so einfach wie möglich zu gestalten.
Meiner Meinung nach fehlt in diesem Thread noch ein wichtiges Merkmal - die Einschränkung der Probezeit oder der Demo. Potenzielle Käufer wollen zu Recht zuerst sehen, was sie kaufen. Zu diesem Zweck müssen irgendwo versteckte (verschlüsselte) Informationen über die Daten und/oder die Zeit, während der das gekaufte Produkt ohne Einschränkungen funktionieren wird, vorhanden sein. Es scheint mir, dass die Einbettung eines Verschlüsselungsmechanismus mit einigen Schlüsseln (a la pgp) in die Sprache selbst nicht nur dieses, sondern viele andere Probleme lösen kann.
Es macht Sinn, nur an einen Kunden zu verkaufen, der auf einem echten Konto arbeitet (so wie er die Mittel zum Kauf hat / haben muss). Diese Nummer (und eventuell weitere Informationen wie Servername, Schlüsselphrase oder etwas anderes) wird als Schlüssel für die Entschlüsselung verwendet. Der Anbieter sollte über einen eingebauten Mechanismus zur Erzeugung eines Schlüsselpaares und zur Verschlüsselung von Dateien mit diesem Schlüsselpaar verfügen.
Und was bekommen wir? Der Entwickler erstellt eine Datei mit den Ausgangsdaten: z.B. mit der Kontonummer und zwei Daten, von und bis zu denen er auf diesem Konto arbeitet. für ihn (und nur für sein Konto), erhält die Plattform einen zweiten vollständigen Schlüssel für die Kontonummer, liest und entschlüsselt die verschlüsselte Datei (Sie können die Prüfsumme überprüfen und geben nichts zurück, wenn sich der Schlüssel als falsch herausstellt) und gibt sie als String an den Expert Advisor / Script / Indikator weiter.
Der Code selbst erhält diese Daten und entscheidet, ob er im Demomodus oder im normalen Modus arbeitet. Er kann sogar Parameter der EA-Operation speichern: z.B. das Kreuzen von MAXX - der Algorithmus ist auch nach der Dekompilierung klar, aber die genauen Parameter, mit denen diese MAXX im Gewinn arbeiten, können "geheim" sein, und es hat keinen Sinn, einen EA zu dekompilieren, ohne diese Parameter zu kennen. Natürlich gibt es einige Lücken und es wird etwas zu kompromittieren geben, aber wenn man die Daten in einer verschlüsselten Datei nicht kennt (was man mit Asm nicht kann), wird alles viel komplizierter, als wenn man nur das Produkt und dessen Support vom Autor kauft.
Fazit: Sie müssen einen verschlüsselten Container bereitstellen, und dann kann jeder, der über die benötigten Daten verfügt, für den besten Schutz sorgen.
Meine Herren, vergessen Sie nicht, dass dies ein Massenmarkt ist.
Sie denken in 1:1-Arbeitskategorien, dass Käufer und Verkäufer gemeinsam verhandeln, Gebote austauschen und sich gegenseitig die Schlüssel schicken. Natürlich werden Sie auf diese Weise nicht viel verkaufen können. Wir hingegen bieten einen Schnellverkaufsshop, bei dem der Verkäufer nicht einmal einen Finger rühren muss, um zu verkaufen. Und der Käufer muss nur auf den "Kaufen"-Knopf drücken und sich nicht um Kontonummern oder Schlüsselgenerierung kümmern.
Alles ist bereits durchdacht. Wenn Sie wissen wollen, wie es funktioniert, verwenden Sie Ihr iPhone/iPad, indem Sie im AppStore Software dafür kaufen.
Meiner bescheidenen Meinung nach ist die Möglichkeit eines an die Hardware gebundenen Schutzes ideal, sowohl in Bezug auf die Umsetzung als auch auf die Benutzerfreundlichkeit. Es gibt noch einen weiteren Wunsch zu dieser Variante, den ich Ihnen aber weiter unten erläutern werde.
Die Optionen für die Verknüpfung mit Kontonummern/Eigentümernamen und anderen sind nicht bequem, auch wenn dies auf den ersten Blick nicht offensichtlich ist. Der Käufer wechselt gerne den Makler und eröffnet jede Woche ein neues Konto. Wie wäre es also, wenn er jedes Mal ein Produkt für sich selbst zusammenstellt, und wenn es Dutzende oder Hunderte von Nutzern des Produkts gibt? Die Schlüssel können im Netz verschmolzen werden - auch das ist keine Option.
Wie sieht es mit der Bindung an Hardware aus? Wenn ein Benutzer mit dem Produkt auf mehreren Computern arbeiten möchte, sollte die Möglichkeit der Bindung an verschiedene Hardwareversionen vorgesehen werden. Und wenn der Benutzer die vorhandene Hardware aufrüsten möchte, dann müssen Sie ihm in solchen Fällen vielleicht eine Stunde Zeit geben, in der das Upgrade durchgeführt wird. Also weiter. Wir müssen über diese Punkte nachdenken. Das Produkt für immer an ein/zwei/drei Geräte zu binden, ist falsch und unfair gegenüber dem Kunden.
Was die Bindung an die Hardware betrifft. Wenn der Benutzer das Produkt auf mehreren Rechnern verwenden möchte, sollte die Möglichkeit der Bindung an mehrere Hardwareoptionen vorgesehen werden. Und wenn der Benutzer die verfügbare Hardware aufrüsten möchte, dann sollte man in solchen Fällen vielleicht eine Stunde einplanen, in der der Benutzer auf die neue Hardware umschaltet. Also weiter. Wir müssen über diese Punkte nachdenken. Ein Produkt für immer an ein/zwei/drei Geräte zu binden, ist nicht richtig und dem Kunden gegenüber nicht fair.
Aber zur gleichen Zeit, werden wir erlauben, in den Tester (Tester-Agent) geschützten EAs laufen, so dass die Nutzer unabhängig die Leistung des EA in den Tester zu überprüfen und nicht die Katze im Sack kaufen könnte.
Es gibt EAs, in die die Geschichte eingenäht ist. Oder die in der Lage sind, Geschichte aus der Geschichtsdatenbank zu lesen. Solche Dummy-EAs zeigen im Tester bemerkenswerte Ergebnisse. Gibt es einen Schutz gegen diese Art von Betrug? Vor allem, wenn der Expert Advisor zusammen mit einer DLL geliefert wird.
Wie wird der Dienst seinen Ruf im Falle von MQL5-Code + bösartiger DLL (von Spyware bis zu Viren) verteidigen?