Protection de l'auteur du code MQL dans MT5. - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
par exemple
Acheteur : trouve des informations sur Internet, écrit veut acheter
Vendeur : Décrit le mécanisme de paiement - si vous ne souhaitez pas communiquer les détails du paiement, il vous sera demandé de fournir vos informations personnalisées.
l'acheteur : paie et envoie les données de personnalisation, le numéro de compte ou le nom complet, qui sont la clé
Vendeur : envoie les marchandises attribuées aux données personnelles.
idéalement, c'est ça !
J'ai de tels cas, et pas seulement
Malheureusement, cela ne rend pas la vie plus compliquée pour certains freeloaders (personnes qui sont dans le sujet). La liaison à un compte n'est pas non plus la solution à tous les problèmes, n'importe quel "copieur de transactions" compétent transférera toutes les données vers n'importe quel autre compte (surtout si les données sont copiées de MT5 à MT5).
À mon avis, il faut protéger non seulement les experts, mais aussi les scripts, les indicateurs, les bibliothèques et autres codes. À mon avis, c'est un thème plus intéressant et plus important.
Pourquoi est-ce plus important ?
Comme nous le savons, tous les outils qui peuvent être mis en œuvre à l'aide de MQL sont divisés en : systèmes automatisés, systèmes semi-automatisés et outils pour le trading manuel.
Il existe également une division des systèmes : les "boîtes noires", les "boîtes grises" et les systèmes "blancs" (systèmes à source ouverte et à logique explicitement décrite).
Ainsi, presque toutes les MTS présentées dans le secteur commercial seront des boîtes noires ou grises. Leur poids spécifique ne sera pas si important (je pense qu'il ne dépassera pas 30-40%). Dans le même temps, ces solutions seront plutôt rigides (car elles ne mettent en œuvre qu'une seule stratégie).
Les scripts, bibliothèques et indicateurs distincts sont une autre affaire. Ces solutions logicielles seront présentes dans tous les domaines du trading manuel et mécanique. En même temps, ils pourront être utilisés comme éléments de base du constructeur.
PS
Ici, à mon avis, il est nécessaire de maximiser la protection, et de ne pas empiéter sur les droits des développeurs et des utilisateurs. Le seul moyen optimal de protection dans ce cas ? Si je comprends bien, il n'y en a qu'un - Lier au matériel.
Quoi que vous puissiez vous dire, la fixation au matériel n'est plus une méthode de protection efficace. D'ailleurs, pour une personne connaissant à peine Asmus (et il y en a beaucoup plus que cela), la suppression de cette protection est une question de minutes. Et peu importe à quoi vous vous liez. Lisez les forums de programmation (ou de piratage) et tout deviendra clair pour vous. :) Et pour ce qui est de la "bonne organisation", essayez, à titre expérimental, de lier une partie de votre production de masse au matériel et je suis sûr qu'après un certain temps (un mois ou deux), vous comprendrez ce que je voulais vous dire.
Comme s'il existait d'autres options de protection ?
Je suis surpris que vous demandiez ça. Bien sûr qu'il y en a. Et beaucoup d'entre eux. Des simples recodeurs aux générateurs de licences, en passant par les méthodes de protection matérielle et logicielle telles que HASP, etc. Mais presque tous, indépendamment de leur coût et de leur fiabilité déclarée, ont été craqués depuis longtemps, et les codes de craquage, les keygens et autres logiciels se promènent sur Internet en accès libre. Et j'ose dire que ces méthodes de protection sont plusieurs ordres de grandeur plus fiables que la simple liaison au matériel.
Dans le contexte de MT4/MT5 MQL4/MQL5 + DLL la liaison peut être faite non pas au matériel, mais au numéro de compte (numéros), pour le nom réel et/ou le nom de famille, alternativement le deuxième prénom.
Cette méthode est la plus simple en termes de sécurité (pour cette situation spécifique) - elle est mobile et ne nécessite pas de liaison avec le matériel.
A partir de ce fil, nous avons eu ('chacun' !) notre propre certificat délivré par Metakwots. Il est clair qu'il ne s'agit pas encore d'une autorité de certification bien reconnue. Mais ce sujet (émission et maintien de certificats) est au point mort, bien que 4 soit censé disposer d'une telle capacité d'authentification.
Par conséquent, une liaison au matériel pour la protection de la paternité est, à mon avis, une régression "profonde".
L'idée (dont il est question dans les premières pages) était d'implémenter l'algorithme de compilation "normal" pour le fichier ex5.
Le rêve est approximativement le suivant.
Le programmeur est capable de compiler son programme de telle sorte qu'il ne puisse être perçu avec précision par le terminal qu'en présence d'une sous-clé de traçage - une concaténation complexe de la clé du développeur et de celle de l'utilisateur.
Les signatures nécessaires de la clé du développeur se trouveraient dans le programme ainsi que la clé de l'utilisateur dans le programme et dans la clé du terminal spécifique.
La présence de cette "sous-clé de licence" permettrait alors de l'utiliser.
La génération doit être effectuée par le méta-éditeur, c'est-à-dire le développeur lui-même - ayant reçu une partie de la clé du client.
C'est ainsi que l'on a imaginé...
Mais quelque chose ne sort pas du brouillard.
Il me semble que la possibilité de générer la clé du développeur à partir de l'autorité de certification "МТ5" et la présence dans le terminal de procédures de décryptage ex5 utilisant cette clé et une partie de la clé de l'utilisateur résoudraient plus de problèmes que ce "service natif" - dont les mécanismes et l'adéquation ne peuvent absolument pas être discutés ici.
;)
Si nous parlons de protection des clés, l'internet tout entier sera inondé de ces mêmes clés. En d'autres termes, au lieu d'une protection, ce sera une imposture avec une mise en œuvre complexe obligeant l'acheteur à gérer les clés.
Le meilleur moyen est d'examiner le système de vente AppStore/iTunes d'Apple qui fonctionne. Le client n'a qu'à cliquer et acheter le logiciel sans avoir à transférer ou à utiliser des clés. Il suffit au client de posséder un compte MQL5.com pour conserver l'historique de ses achats et réactiver les programmes achetés précédemment.
Lorsqu'il achète un programme, l'utilisateur reçoit une copie spécialement recompilée/protégée, qui protège le vendeur bien mieux que les clés. L'ensemble du processus de protection personnelle sera automatique au moment de l'achat.
Notre objectif est de rendre le processus d'achat/de vente aussi simple que possible.
Je pense qu'il manque une autre caractéristique importante dans ce fil de discussion : la période d'essai ou les restrictions relatives aux démos. Les acheteurs potentiels veulent, à juste titre, voir d'abord ce qu'ils achètent. À cette fin, il faut cacher quelque part (crypter) des informations sur les dates et/ou les heures pendant lesquelles le produit acheté fonctionnera sans restrictions. Il me semble que l'intégration d'un mécanisme de cryptage avec un couple de clés (à la pgp) dans le langage lui-même peut résoudre non seulement ce problème mais bien d'autres.
Il est logique de ne vendre qu'à un client travaillant sur un compte réel (comme s'il avait / devait avoir les moyens d'acheter). Ce numéro (éventuellement accompagné d'autres informations comme le nom du serveur, la phrase clé ou autre) est utilisé comme clé de décryptage. Le fournisseur doit disposer d'un mécanisme intégré permettant de générer une paire de clés et de crypter des fichiers avec celle-ci.
Qu'est-ce qu'on obtient ? Le développeur crée un fichier avec les données initiales : par exemple, contenant le numéro de compte et deux dates de et à laquelle il travaille sur ce compte. ce fichier est crypté. et est donné avec l'expert/script/indicateur à l'acheteur. La plateforme reçoit (et seul le client a sur le compte) la deuxième clé, lit et décrypte le fichier crypté (vous pouvez vérifier la somme de contrôle et ne rien renvoyer si la clé s'est avérée fausse) et le donne comme une chaîne de caractères au conseiller expert / script / indicateur.
Le code lui-même recevra ces données et décidera s'il fonctionne en mode démo ou normal. Il peut même stocker les paramètres de fonctionnement de l'EA : par exemple, le croisement des MAXX - l'algorithme est clair même après décompilation, mais les paramètres exacts avec lesquels ces MAXX travaillent dans le profit peuvent être "secrets", et il n'y a aucun sens à décompiler un EA sans connaître ces paramètres. Bien sûr, il y a des lacunes et il y aura quelque chose à compromettre, mais ne pas connaître les données dans un fichier crypté (ce que vous ne pouvez pas obtenir avec Asm), tout devient beaucoup plus compliqué que d'acheter simplement le produit et son support auprès de l'auteur.
En résumé, vous devez fournir un conteneur crypté, puis tous ceux qui détiennent les données dont ils ont besoin peuvent prendre des dispositions pour obtenir la protection la plus sophistiquée.
Messieurs, n'oubliez pas que c'est un marché de masse.
Vous pensez à des catégories de travail 1:1, que l'acheteur et le vendeur vont négocier ensemble, échanger des offres et s'envoyer les clés. Bien sûr, de cette façon, vous ne pourrez pas vendre grand-chose. Nous, en revanche, proposons une boutique de vente rapide où le vendeur ne doit même pas lever le petit doigt pour vendre. Et l'acheteur n'a qu'à appuyer sur le bouton "acheter", sans s'embarrasser de numéros de compte ou de génération de clés.
Tout a déjà été pensé. Si vous voulez savoir comment cela va fonctionner, essayez un iPhone/iPad, en achetant un logiciel pour celui-ci sur l'AppStore.
A mon humble avis, l'option d'une protection liée au matériel est idéale, tant en termes de mise en œuvre que de facilité d'utilisation. Il existe un autre souhait concernant cette variante, mais je vous en parlerai plus loin.
Les options de liaison aux numéros de compte/nom du propriétaire et autres ne sont pas pratiques, bien que cela ne soit pas évident au premier abord. L'acheteur aime changer de courtier et ouvrir de nouveaux comptes chaque semaine, alors que penser de compiler un produit pour lui à chaque fois, et s'il y a des dizaines ou des centaines d'utilisateurs du produit ? Les clés peuvent être fusionnées sur le net - ce qui n'est pas non plus une option.
A propos de la liaison avec le matériel. Un utilisateur peut vouloir travailler avec le produit sur plusieurs ordinateurs et il faut alors prévoir la possibilité de le lier à plusieurs versions de matériel. Et si l'utilisateur souhaite mettre à niveau le matériel disponible, il faudra peut-être, dans ce cas, lui accorder, disons, une heure pendant laquelle la mise à niveau sera effectuée. Et ainsi de suite. Nous devons réfléchir à ces points. Lier le produit à une, deux ou trois machines pour l'éternité est une erreur et une injustice pour le client.
Quant à la liaison avec le matériel. L'utilisateur peut vouloir utiliser le produit sur plusieurs machines, il faut alors prévoir la possibilité de se lier à plusieurs options matérielles. Et si l'utilisateur souhaite mettre à niveau le matériel disponible, il faudrait peut-être, dans ce cas, prévoir, disons, une heure pendant laquelle l'utilisateur passe au nouveau matériel. Et ainsi de suite. Nous devons réfléchir à ces points. Lier un produit à une, deux ou trois machines pour toujours n'est ni juste ni équitable pour le client.
Mais en même temps, nous autoriserons l'exécution dans le testeur (agent du testeur) d'EA protégées, de sorte que les utilisateurs puissent vérifier de manière indépendante les performances de l'EA dans le testeur et ne pas acheter un cochon dans un poke.
Il y a des EA qui ont une histoire cousue en eux. Ou qui sont capables de lire l'histoire à partir de la base historique. Ces EA factices donnent des résultats remarquables dans le testeur. Existe-t-il une protection contre ce type de fraude ? Surtout si le conseiller expert est livré avec une DLL.
Comment le service luttera-t-il pour sa réputation en cas de code MQL5 + DLL malveillante (des logiciels espions aux virus) ?