Mq4 Schutzmethoden... - Seite 4
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
Haben Sie schon einmal über Folgendes nachgedacht?
Führen Sie MetaTrader wie gewohnt aus. Laden Sie Ihre verdammt stark geschützten Indikatoren oder was auch immer. Führen Sie ein Prozessdump-Tool aus und schreiben Sie den gesamten Speicher des terminal.exe-Prozesses in eine Datei (... und vielleicht andere Speicherbereiche, die er zuweist), verwenden Sie einen Hexeditor oder normalen Texteditor und suchen Sie nach Fragmenten Ihrer so perfekt geschützten Indikatoren.
Ich habe das nicht ausprobiert, aber ich habe fast 30 Jahre Erfahrung in der Low-Level-Programmierung (680x0 Assembler, Powerpc und so weiter).
Viel Spaß bei der Suche.
:)
Ok, ich war etwas in Eile, als ich auf diesen Thread geantwortet habe und möchte daher ein paar Zeilen ergänzen. So etwas wie einen wirklichen Schutz des Codes gibt es nicht. Man kann zwar seinen Code verschlüsseln, verschieben, drehen, copylocken, aber am Ende ist er wieder nackt.
Ein Beispiel: Ich habe früher mal Programme geschrieben und die Start- und Endadresse des Codes in eine Datei geschrieben. Alle Sprünge innerhalb des Codes wurden auf einen relativen Offset gesetzt und der Code (der ja normale Daten sind) wurde um 1 Bit gedreht. Der Code ist also nicht mehr vorhanden. Du kannst einen Loader-Teil an deinen Code anhängen und ihn wieder aufdrehen lassen und die Adressen der Labels (normalerweise in Hunks zu finden) neu zuweisen lassen. Springen Sie zum Eintrag und voila, Sie führen das Programm wieder aus.
Daher werden die meisten Leute glauben, dass Ihr Programm oder Ihr Indikator gut geschützt ist, weil man keine Labels oder andere Dinge aus der Krypta (ausführbar) lesen kann. Am Ende ist es wieder sichtbar. Sichtbar, wenn Sie es ausführen und es durch Ihren Prozess (oder Ihr Programm) laufen lassen.
Sie können den Code verkrüppeln, verschieben und schützen, so viel Sie wollen. Sobald das Programm ausgeführt wird, ist der Schutz größtenteils wieder aufgehoben (mit einigen Ausnahmen wie Schlüsseldateien oder Seriennummern usw.).
Ich gehe also davon aus, dass dies auch für Indikatoren gilt. Sie werden kompiliert, ja. Ist es eine Binärdatei? Ich weiß es nicht. Ist es ein Bytecode? Ich weiß es auch nicht. Aber ich bin mir ziemlich sicher, dass Sie, wenn Sie es in terminal.exe ausführen und die Speicherbereiche, die terminal.exe für den Indikator reserviert hat, auslesen, Spuren Ihres Codes erhalten können (selbst wenn es sich nur um Textstrings oder ähnliches handelt).
Vielleicht erhalten Sie eine Art CODE zurück, wie in Ihren *.mql4-Dateien. Vielleicht aber auch nicht. Vielleicht erhalten Sie Bytecode, vielleicht auch nicht. Vielleicht erhalten Sie etwas. Vielleicht hat terminal.exe einen eigenen Code-Interpreter, der den von metaeditor.exe erzeugten Code so interpretiert, dass terminal.exe ihn versteht. Wie ich bereits sagte, habe ich es nicht ausprobiert.
Was ich erklären möchte, ist, dass man, wenn man seinen Code verschlüsseln oder schützen will, ihn nicht immer nur von einer Seite aus sehen kann (z.B. die ex4-Dateien, die der Metaeditor kompiliert und mit unbekanntem Code versehen hat. Sehen Sie ihn auch von der anderen Seite. Sobald Sie ihn ausführen, ist Ihr geschützter Code wieder nackt. Und das ist ein Teil, um die Finger darauf zu bekommen. Kann funktionieren. Muss aber nicht.
Ein negativer Effekt beim Auslesen der Start- und Endadresse eines laufenden Codes ist dieser. Alles wird initialisiert. Arrays werden mit Werten gefüllt, Platzhalter könnten Werte haben usw.
Gute Argumente, Ali. Danke, Ali.
Das Mining im Speicherauszug scheint eine teure Lösung zu sein. Bisher war die einzige billige Lösung das Wissensleck von Metaquotes. Ich gehe davon aus, dass jemand - der in der Lage ist, Speichercode zu schürfen - den MQL4 selbst von Grund auf für weniger Aufwand programmieren kann. Damit fühle ich mich derzeit sicher, bis das neue Wissensleck auftaucht, das billige Decoder ermöglicht. Dann kommt der Plan B - ihn so zu kodieren, dass die Manipulation des zerlegten Codes hohe Kosten verursacht.