Protección de la autoría del código MQL en MT5. - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
En lo que respecta a EX4, lo más probable es que se trate de un Editor que ha sido descompilado.
Y parece que está desnudo de las protecciones. Allí no hay flujos financieros.
Y si los dos componentes protegidos (Cliente y Editor) funcionan con llaves, más esperanzas de éxito.
;)
5 centavos...
1. La mayoría de los productos (si no todos) requieren una conexión para ser utilizados.
2. Así, una "llave" en forma de "servicio" colocada en la red (en el sitio web del autor).
Cuando se inicia el terminal, el terminal con un indicador o Asesor Experto, que se ejecuta en él, "utilizar"...
Y, en consecuencia, el problema de la descompilación ya no es un problema.
Fuera de la categoría. El producto debe ser realmente interesante.
Una revisión de un producto vendido sobre la "base" de algoritmos súper secretos
demostró que no hay nada interesante y menos aún útil... por desgracia...
En principio, el algoritmo en sí mismo es super-duper, si el autor lo piensa, puede ser colocado en el sitio.
El Asesor Experto sólo debe manejar y aplicar en los procesos de comercio, que no es un secreto, incluso si se publica abiertamente.
- el EA envía una solicitud (por suscripción)
- recibe valores
- procesos
- comercio
- puede dedicarse simultáneamente a dibujar
//
Lo mismo para el indicador, excepto para el comercio
Organizar la propia suscripción por número de cuenta...
En general, como decía un emperador romano: ¡divide y vencerás!
El hecho es que la descompilación sigue siendo un problema. Si todo el código necesario está dentro del EA, entonces al descompilarlo junto con una clave de trabajo conocida se obtiene el código fuente del EA con todas las consecuencias que se derivan.
Sin embargo, si parte del código se encuentra en el sitio web, esta es una solución muy poco fiable. Cualquier fallo en el sitio puede suponer pérdidas alucinantes en el dinero de los clientes.
Además, una vez vi una mención en algún lugar que el código MQL5 compila en código nativo de la CPU. No sé: es realmente o no, pero si lo es, es un grave agujero en la protección contra la descompilación.
¿Y cómo reduciría esto la seguridad?
La adición de código se evita utilizando criptografía asimétrica: si la clave es lo suficientemente larga, sería imposible falsificar la firma.
Si te refieres a la descompilación, su automatización es muy difícil para el código máquina. No me refiero a desensamblar - es posible porque el propio procesador tiene que ejecutar el código de alguna manera. Hay intentos de descompilación automática(http://www.hex-rays.com/), pero se reducen principalmente al análisis de todas las posibles opciones de código generadas por el compilador (que se convierte en una tarea nada trivial, porque según he entendido la conversión a código máquina se realizará en el lado de las metacitas). Si vinculamos el generador de código a la fase de la luna (es decir, para compilar las construcciones de diferentes maneras), ¡la automatización de la descompilación se vuelve irreal!
¿Y cómo reduciría esto la seguridad?
La criptografía asimétrica impide añadir código: si la clave es lo suficientemente larga, sería imposible falsificar la firma.
Si te refieres a la descompilación, su automatización es muy difícil para el código máquina. No me refiero a desensamblar - es posible porque el propio procesador tiene que ejecutar el código de alguna manera. Hay intentos de descompilación automática(http://www.hex-rays.com/), pero se reducen principalmente al análisis de todas las posibles versiones de código generadas por el compilador (lo que se convierte en una tarea nada trivial, porque según he entendido la conversión a código máquina se realizará en el lado de las metacitas). Si vinculamos el generador de código a la fase de la luna (es decir, para compilar las construcciones de diferentes maneras), ¡la automatización de la descompilación se vuelve irreal!
Efectivamente, me refería a desmontar. Yo, como suele ocurrir con todo el mundo, juzgué por mis propias capacidades. Para mí es similar a la descompilación, ya que en la mayoría de los casos puedo reconstruir fácilmente el algoritmo a partir del texto en ensamblador. Por supuesto, este proceso puede complicarse mucho si se utilizan algoritmos de virus polimórficos, pero al final, como hay antivirus, este método tampoco da una garantía total.
Efectivamente, me refería a desmontar. Como suele ocurrir con todo el mundo, estaba juzgando por mis propias capacidades. Para mí es como descompilar, ya que puedo reconstruir fácilmente el algoritmo a partir del código ensamblador en la mayoría de los casos. Por supuesto, este proceso puede complicarse mucho si se utilizan algoritmos de virus polimórficos, pero al final, como hay antivirus, este método tampoco da una garantía total.
Desmontar archivos grandes (incluso con ida) y reconstruir manualmente el algoritmo lleva mucho tiempo y esfuerzo. Es dudoso que la gente practique a menudo este enfoque. Pero parece que este es el único método que será posible para los archivos de código máquina en el futuro, si los desarrolladores consiguen complicar el código máquina generado de alguna manera.
Los antivirus rara vez utilizan algoritmos especiales. Sobre todo se aferran a peculiaridades de archivos y secuencias de instrucciones - me he encontrado con un antivirus que se quejaba de calcular pi a través de la suma de series (estaba entrenando para usar la fpu). Descompilar es una tarea fundamentalmente diferente. Si se realizan mutaciones de código irreversibles durante la generación del código, la descompilación por variantes de código características será imposible en principio (se necesitará emular/rastrear el código y observar lo que ocurre a "alto nivel" - de dónde se leyó, qué y dónde se escribió, qué y con qué parámetros se llamó... los antivirus parecen utilizar un enfoque similar, pero sólo observan la secuencia de llamadas de varias funciones del sistema).
En cuanto al tema de las mutaciones irreversibles, tal vez incluya algunos enlaces a artículos (espero que a la administración y a los lectores no les molesten los enlaces):
Sólo para la basura de código / ofuscación en MQL5, puede especificar un modificador especial para cada función:
Hasta ahora se llama basura, pero lo más probable es que lo cambiemos por protección.
Esto dará lugar a una profunda contaminación del código y a la ralentización de la función especificada.
Además, el compilador MQL5 utiliza muchas optimizaciones, lo que reduce drásticamente la posibilidad de descompilación inversa.
Sólo para la basura de código / ofuscación en MQL5, puede especificar un modificador especial para cada función:
Eso es bueno :) ¿Será posible ajustar el porcentaje de código basura? ¿Se incrustarán las funciones por su ubicación de llamada?
Eso es bueno :) ¿Será posible ajustar el porcentaje de código basura? ¿La incrustación de funciones se hará en el punto de llamada?
La basura será diferente cada vez. No se puede personalizar el porcentaje, es el compilador el que decide.
Las funciones inline automáticas llevan mucho tiempo funcionando: el propio compilador toma las decisiones en función del tamaño y la complejidad de la función. Es decir, las funciones grandes no se inlinean.
Eh... Qué fácil es para mí vivir...
No tengo ningún deseo de piratear, ni tengo intención de vender nada en un futuro próximo.
Ese es el problema de la gente...
:)))