Protection de l'auteur du code MQL dans MT5. - page 2

Nouveau commentaire
 

En ce qui concerne EX4, il s'agit très probablement d'Editor qui a été décompilé.

Et il semble être nu des protections. Il n'y a pas de flux financiers à cet endroit.

Et si les deux composants protégés (le client et l'éditeur) fonctionnent avec des clés - plus d'espoir de réussite.

;)

 

5 centimes...


1. La plupart des produits (sinon tous) nécessitent une connexion pour être utilisés.

2. ainsi, une "clé" sous forme de "service" placée sur le réseau (sur le site de l'auteur).

Lorsque vous démarrez le terminal, le terminal avec un indicateur ou Expert Advisor, fonctionnant sur lui, "l'utilise"...

Et, par conséquent, le problème de la décompilation n'est plus un problème.


Hors catégorie. Le produit doit être vraiment intéressant.

Une revue d'un produit vendu sur la "base" d'algorithmes super secrets

a montré qu'il n'y avait rien d'intéressant et encore moins d'utile... hélas...


En principe, l'algorithme lui-même est super-duper, si l'auteur le pense, il peut être placé sur le site.

Le conseiller expert ne doit traiter et mettre en œuvre que des processus commerciaux qui ne sont pas secrets, même s'ils sont publiés ouvertement.

- l'EA envoie une demande (par abonnement)

- reçoit des valeurs

- processus

- le commerce

- peuvent être simultanément engagés dans le dessin

//

Idem pour l'indicateur, sauf pour la négociation


Organiser l'abonnement lui-même par numéro de compte...


En général, comme le disait un empereur romain : diviser pour mieux régner !

 
circlesquares :


Le fait est que la décompilation reste un problème. Si tout le code nécessaire se trouve dans l'EA, sa décompilation avec une clé de travail connue permet d'obtenir le code source de l'EA avec toutes les conséquences qui en découlent.

Toutefois, si une partie du code se trouve sur le site web, cette solution est très peu fiable. Toute défaillance du site peut entraîner des pertes ahurissantes en argent des clients.

 
api :

De plus, j'ai vu une fois une mention quelque part que le code MQL5 se compile en code natif du CPU. Je ne sais pas : est-ce vraiment le cas ou non, mais si c'est le cas, c'est un trou sérieux dans la protection contre la décompilation.

Et en quoi cela réduirait-il la sécurité ?

L'ajout de code est empêché par l'utilisation de la cryptographie asymétrique. Si la clé est suffisamment longue, il sera impossible de falsifier la signature.

Si vous voulez parler de décompilation, son automatisation est très difficile pour le code machine. Je ne parle pas de désassemblage - c'est possible parce que le processeur lui-même doit exécuter le code d'une manière ou d'une autre. Il existe des tentatives de décompilation automatique(http://www.hex-rays.com/) mais elles se réduisent principalement à l'analyse de toutes les options possibles du code généré par le compilateur (ce qui ne devient pas du tout une tâche triviale, car d'après ce que j'ai compris, la conversion en code machine sera effectuée du côté des métaquotes). Si nous lions le générateur de code à la phase de la lune (c'est-à-dire pour compiler les constructions de différentes manières), l'automatisation de la décompilation devient irréaliste !

 
lea :

Et en quoi cela réduirait-il la sécurité ?

L'ajout de code est empêché par la cryptographie asymétrique - si la clé est suffisamment longue, il serait impossible de falsifier la signature.

Si vous voulez parler de décompilation, son automatisation est très difficile pour le code machine. Je ne parle pas de désassemblage - c'est possible parce que le processeur lui-même doit exécuter le code d'une manière ou d'une autre. Il existe des tentatives de décompilation automatique(http://www.hex-rays.com/) mais elles se réduisent principalement à l'analyse de toutes les versions possibles du code généré par le compilateur (ce qui ne devient pas du tout une tâche triviale, car d'après ce que j'ai compris, la conversion en code machine sera effectuée du côté des métaquotes). Si nous lions le travail du générateur de code à la phase de la lune (c'est-à-dire pour compiler les constructions différemment), l'automatisation de la décompilation devient irréaliste !


En effet, je voulais dire démontage. Comme c'est souvent le cas pour tout le monde, j'ai jugé selon mes propres capacités. Pour moi, c'est similaire à la décompilation, puisque dans la plupart des cas, je peux facilement reconstruire l'algorithme à partir du texte en assembleur. Bien sûr, ce processus peut être grandement compliqué par l'utilisation d'algorithmes de virus polymorphes, mais au final, comme il existe des anti-virus, cette méthode ne donne pas non plus une garantie totale.

 
api :


En effet, je voulais dire démontage. Comme c'est souvent le cas avec tout le monde, je jugeais par mes propres capacités. Pour moi, c'est similaire à la décompilation, puisque je peux facilement reconstruire l'algorithme à partir du texte en assembleur dans la plupart des cas. Bien sûr, ce processus peut être grandement compliqué par l'utilisation d'algorithmes de virus polymorphes, mais au final, comme il existe des anti-virus, cette méthode ne donne pas non plus une garantie totale.

Désassembler des fichiers volumineux (même avec ida) et reconstruire manuellement l'algorithme prend beaucoup de temps et d'efforts. Il est peu probable que les gens pratiquent souvent cette approche. Mais il semble que ce soit la seule méthode possible pour les fichiers de code machine à l'avenir, si les développeurs parviennent à compliquer d'une manière ou d'une autre le code machine généré.
Les antivirus utilisent rarement des algorithmes spéciaux. Ils s'accrochent surtout aux particularités des fichiers et des séquences d'instructions - j'ai rencontré un antivirus qui se plaignait du calcul de pi par la somme de séries (je m'entraînais à utiliser le fpu). La décompilation est une tâche fondamentalement différente. Si vous effectuez des mutations de code irréversibles pendant la génération du code, la décompilation par variantes de code caractéristiques sera en principe impossible (vous devrez émuler/tracer le code et observer ce qui se passe à un "haut niveau" - d'où il a été lu, quoi et où il a été écrit, quoi et avec quels paramètres il a été appelé... les antivirus semblent utiliser une approche similaire, mais ils n'observent que la séquence d'appels de diverses fonctions système).

En ce qui concerne les mutations irréversibles, je vais peut-être ajouter quelques liens vers des articles (j'espère que l'administration et les lecteurs ne verront pas d'inconvénient à ce qu'il y ait des liens vers ces articles) :

 

Pour la littering/ obfuscation du code dans MQL5, vous pouvez spécifier un modificateur spécial pour chaque fonction :

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

Pour l'instant, il s'agit de la poubelle, mais nous allons très probablement la changer en protection.


Cela aura pour conséquence de joncher profondément le code et de ralentir la fonction spécifiée.


En outre, le compilateur MQL5 utilise de nombreuses optimisations, ce qui réduit considérablement les possibilités de décompilation inverse.

 
Renat :

Juste pour le garbage/obfuscation du code dans MQL5, vous pouvez spécifier un modificateur spécial pour chaque fonction :

C'est bien :) Sera-t-il possible d'ajuster le pourcentage de code poubelle ? Les fonctions seront-elles intégrées par leur emplacement d'appel ?

 
lea :

C'est bien :) Sera-t-il possible d'ajuster le pourcentage de code inutilisable ? L'intégration des fonctions se fera-t-elle au point d'appel ?

Les déchets seront différents à chaque fois. Vous ne pouvez pas personnaliser le pourcentage - c'est au compilateur d'en décider.


Les fonctions automatiques en ligne fonctionnent depuis longtemps - le compilateur prend lui-même les décisions en fonction de la taille et de la complexité de la fonction. C'est-à-dire que les grandes fonctions ne sont pas inlined.

 

Eh... Comme il est facile pour moi de vivre...

Je n'ai aucune envie de pirater, et je n'ai pas l'intention de vendre quoi que ce soit dans un avenir proche.

C'est le problème avec les gens...

:)))

123456789...17
Nouveau commentaire
Raison: