Schutz der Urheberschaft von MQL-Code in MT5. - Seite 2

 

Was EX4 betrifft, so handelt es sich höchstwahrscheinlich um Editor, der dekompiliert wurde.

Und es scheint von den Schutzmaßnahmen nackt zu sein. Dort gibt es keine Finanzströme.

Und wenn beide geschützten Komponenten (Client & Editor) mit Schlüsseln arbeiten - mehr Hoffnung auf Erfolg.

;)

 

5 Cents...


1. Die meisten (wenn auch nicht alle) Produkte erfordern eine Verbindung, um verwendet werden zu können.

2. also einen "Schlüssel" in Form eines "Dienstes", der in das Netz (auf die Website des Autors) gestellt wird.

Wenn Sie das Terminal starten, das Terminal mit einem Indikator oder Expert Advisor, der darauf läuft, "benutzen"...

Das Problem der Dekompilierung ist somit kein Problem mehr.


Aus der Kategorie. Das Produkt muss wirklich interessant sein.

Ein Bericht über ein Produkt, das auf der "Grundlage" supergeheimer Algorithmen verkauft wird

zeigte, dass es nichts Interessantes und noch weniger Nützliches gibt... Leider...


Im Prinzip ist der Algorithmus selbst super-duper, wenn der Autor denkt so, kann auf der Website platziert werden.

Der Expert Advisor sollte nur Handelsprozesse bearbeiten und umsetzen, die nicht geheim sind, auch wenn sie öffentlich veröffentlicht werden.

- der EA sendet eine Anfrage (per Abonnement)

- erhält Werte

- Prozesse

- Handel

- können gleichzeitig mit dem Zeichnen beschäftigt sein

//

Dasselbe gilt für den Indikator, außer für den Handel


Organisieren Sie das Abonnement selbst nach Kontonummer...


Im Allgemeinen gilt, wie ein römischer Kaiser zu sagen pflegte: Teile und herrsche!

 
circlesquares :


Tatsache ist, dass die Dekompilierung immer noch ein Problem darstellt. Wenn der gesamte erforderliche Code im EA enthalten ist, kann man ihn mit einem bekannten Arbeitsschlüssel dekompilieren und erhält so den Quellcode des EA mit allen seinen Konsequenzen.

Wenn sich ein Teil des Codes auf der Website befindet, ist dies jedoch eine sehr unzuverlässige Lösung. Jeder Ausfall der Website kann zu unvorstellbaren Verlusten an Kundengeldern führen.

 
api :

Außerdem habe ich einmal irgendwo gelesen, dass MQL5-Code in nativen CPU-Code kompiliert werden kann. Ich weiß nicht, ob es wirklich so ist oder nicht, aber wenn es so ist, dann ist das eine große Lücke im Dekompilierungsschutz.

Und wie würde dies die Sicherheit verringern?

Das Hinzufügen von Code wird durch die Verwendung asymmetrischer Kryptographie verhindert - wenn der Schlüssel lang genug ist, wäre es unmöglich, die Signatur zu fälschen.

Wenn Sie die Dekompilierung meinen - deren Automatisierung ist für Maschinencode sehr schwierig. Ich meine nicht das Disassemblieren - das ist möglich, weil der Prozessor selbst den Code irgendwie ausführen muss. Es gibt Versuche der automatischen Dekompilierung(http://www.hex-rays.com/), aber sie beschränken sich im Wesentlichen auf die Analyse aller möglichen Optionen des vom Compiler erzeugten Codes (was keineswegs eine triviale Aufgabe ist, denn wie ich verstanden habe, wird die Umwandlung in Maschinencode auf der Seite der Metaquotes durchgeführt). Wenn wir den Codegenerator an die Mondphase binden (d.h. die Konstrukte auf unterschiedliche Weise kompilieren), wird die Automatisierung der Dekompilierung unrealistisch!

 
lea :

Und wie würde dies die Sicherheit verringern?

Das Hinzufügen von Code wird durch asymmetrische Kryptographie verhindert - wenn der Schlüssel lang genug ist, wäre es unmöglich, die Signatur zu fälschen.

Wenn Sie die Dekompilierung meinen - die Automatisierung ist für Maschinencode sehr schwierig. Ich meine nicht das Disassemblieren - das ist möglich, weil der Prozessor selbst den Code irgendwie ausführen muss. Es gibt Versuche der automatischen Dekompilierung(http://www.hex-rays.com/), aber sie beschränken sich im Wesentlichen auf die Analyse aller möglichen Versionen des vom Compiler erzeugten Codes (was keineswegs eine triviale Aufgabe ist, denn wie ich verstanden habe, wird die Umwandlung in Maschinencode auf der Seite der Metaquotes durchgeführt). Wenn wir den Codegenerator an die Mondphase binden (d.h. die Konstrukte auf unterschiedliche Weise kompilieren), wird die Automatisierung der Dekompilierung unrealistisch!


In der Tat, ich meinte die Demontage. Ich habe, wie es oft der Fall ist, nach meinen eigenen Fähigkeiten geurteilt. Für mich ist es ähnlich wie beim Dekompilieren, denn in den meisten Fällen kann ich den Algorithmus aus dem Assemblertext leicht rekonstruieren. Natürlich kann dieser Prozess durch die Verwendung polymorpher Virenalgorithmen erheblich erschwert werden, aber da es Antivirenprogramme gibt, bietet auch diese Methode keine vollständige Garantie.

 
api :


In der Tat, ich meinte die Demontage. Wie so oft habe ich mich an meinen eigenen Fähigkeiten gemessen. Für mich ist es ähnlich wie bei der Dekompilierung, da ich den Algorithmus in den meisten Fällen leicht aus dem Assemblertext rekonstruieren kann. Natürlich kann dieser Prozess durch die Verwendung polymorpher Virenalgorithmen erheblich erschwert werden, aber da es Antivirenprogramme gibt, bietet auch diese Methode keine vollständige Garantie.

Die Disassemblierung großer Dateien (selbst mit Ida) und die manuelle Rekonstruktion des Algorithmus ist sehr zeit- und arbeitsaufwändig. Es ist zu bezweifeln, dass die Menschen diesen Ansatz oft praktizieren werden. Aber es scheint, dass dies die einzige Methode ist, die in Zukunft für Maschinencodedateien möglich sein wird, wenn es den Entwicklern gelingt, den generierten Maschinencode in irgendeiner Weise zu komplizieren.
Antivirenprogramme verwenden selten spezielle Algorithmen. Meistens klammern sie sich an Eigenheiten von Dateien und Befehlssequenzen - ich bin auf ein Antivirus gestoßen, das sich über die Berechnung von Pi durch die Summe von Reihen beschwert hat (ich trainierte die Verwendung von fpu). Die Dekompilierung ist eine grundlegend andere Aufgabe. Wenn Sie irreversible Code-Mutationen während der Code-Generierung durchführen, ist eine Dekompilierung nach charakteristischen Code-Varianten prinzipiell unmöglich (Sie müssen den Code emulieren/nachverfolgen und beobachten, was auf "hoher Ebene" passiert - woher er gelesen wurde, was und wohin er geschrieben wurde, was und mit welchen Parametern er aufgerufen wurde... Antivirenprogramme scheinen einen ähnlichen Ansatz zu verwenden, aber sie beobachten nur die Abfolge der Aufrufe verschiedener Systemfunktionen).

Zum Thema irreversible Mutationen werde ich vielleicht ein paar Links zu Artikeln einfügen (ich hoffe, die Verwaltung und die Leser haben nichts dagegen, wenn ich auf solche Links verweise):

 

Nur für Code-Verschüttung/Verschleierung in MQL5 können Sie für jede Funktion einen speziellen Modifikator angeben:

void MyFunc(int val) trash
  {
   Print("Val: ",val);
  }

Bislang heißt er Müll, aber wir werden ihn wahrscheinlich in Schutz umbenennen.


Dies führt zu einer starken Vermüllung des Codes und einer Verlangsamung der angegebenen Funktion.


Darüber hinaus verwendet der MQL5-Compiler eine Vielzahl von Optimierungen, die die Möglichkeit der Rückwärtsdekompilierung drastisch reduzieren.

 
Renat :

Nur für Code Garbage/Obfuscation in MQL5 können Sie einen speziellen Modifikator für jede Funktion angeben:

Das ist gut :) Wird es möglich sein, den Prozentsatz des überflüssigen Codes anzupassen? Werden Funktionen nach ihrer Aufrufstelle eingebettet?

 
lea :

Das ist gut :) Wird es möglich sein, den Prozentsatz an fehlerhaftem Code anzupassen? Wird die Einbettung der Funktion am Aufrufpunkt erfolgen?

Der Müll wird jedes Mal anders sein. Sie können den Prozentsatz nicht anpassen - die Entscheidung liegt beim Compiler.


Automatische Inline-Funktionen gibt es schon seit langem - der Compiler selbst trifft die Entscheidungen je nach Größe und Komplexität der Funktion. Das heißt, große Funktionen werden nicht inlined.

 

Äh... Wie einfach ist es für mich zu leben...

Ich habe weder den Wunsch, zu hacken, noch habe ich die Absicht, in absehbarer Zeit etwas zu verkaufen.

Das ist das Problem mit den Menschen...

:)))

Grund der Beschwerde: