Protección de la autoría del código MQL en MT5. - página 7
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
por ejemplo
Comprador: encuentra información en Internet, escribe quiere comprar
Vendedor: Describe el mecanismo de pago - si no quiere dar los datos de pago, se le pedirá que proporcione su información personalizada.
el comprador: paga y envía los datos de personalización, número de cuenta o nombre completo, que es la clave
Vendedor: envía la mercancía asignada a los datos personales.
¡idealmente eso es todo!
Tengo esos casos, y no pocos
Desgraciadamente, esto no complica la vida de algunos gorrones (personas que están en el tema). La vinculación a una cuenta tampoco es la solución de todos los problemas, cualquier "copiador de transacciones" competente transferirá todos los datos a cualquier otra cuenta (especialmente si los datos se copian de MT5 a MT5).
En mi opinión, no sólo los expertos, sino también los scripts, los indicadores, las librerías y otros códigos deberían estar protegidos. En mi opinión, este es un tema más interesante e importante.
¿Por qué es más importante?
Como sabemos, todas las herramientas que se pueden implementar utilizando MQL se dividen en: sistemas automatizados, sistemas semiautomatizados y herramientas para el comercio manual.
También hay una división en los sistemas: "cajas negras", "cajas grises" y sistemas "blancos" (sistemas con código abierto y lógica explícita).
Así, casi todos los STM presentados en el sector comercial serán cajas negras o grises. Su peso específico no será tan grande (creo que no superará el 30-40%). Al mismo tiempo, estas soluciones serán bastante inflexibles (porque aplican en esencia una sola estrategia).
Otra cosa son los scripts, las bibliotecas y los indicadores por separado. Estas soluciones informáticas estarán presentes en todos los ámbitos del comercio manual y mecánico. Al mismo tiempo, podrán utilizarse como elementos básicos del constructor.
PS
Aquí, en mi opinión, es necesario maximizar la protección, y para no infringir los derechos de los desarrolladores y usuarios. ¿La única forma óptima de protección en este caso? Según tengo entendido, sólo hay una: la vinculación con el hardware.
Aunque usted piense lo contrario, la vinculación al hardware ya no es un método eficaz de protección. Por cierto, para una persona que apenas conozca Asmus (y no son pocos) la eliminación de dicha protección es cuestión de minutos. Y no importa a qué te vayas a atar. Lee foros de programación (léase hacking) y todo te quedará claro. :) Y lo de la "buena organización", prueba por experimentar a ligar parte de tu producción en serie al hardware y seguro que al cabo de un tiempo (como un mes o dos) entenderás lo que te quería decir.
¿Como si hubiera otras opciones de protección?
Me sorprende que preguntes eso. Por supuesto que sí. Y muchos de ellos. Desde simples recodificadores, pasando por generadores de licencias, hasta métodos de protección hardware-software como HASP, etc. Pero casi todos ellos, independientemente de su coste y fiabilidad declarada, han sido crackeados desde hace tiempo, y los códigos de crackeo, keygenes y otros softwares se pasean por Internet en abierto. Y me atrevo a decir que estos métodos de protección son varios órdenes de magnitud más fiables que la simple vinculación al hardware.
En el contexto de MT4/MT5 MQL4/MQL5 + DLL la vinculación puede hacerse no con el hardware, sino con el número de cuenta (números), para los reales y/o el nombre, o alternativamente el segundo nombre
Esta forma es la más fácil en términos de seguridad (para esta situación específica) - es móvil y no requiere vinculación con el hardware.
A partir de este hilo tuvimos ('cada') nuestro propio certificado emitido por Metakwots. Está claro que todavía no es una autoridad de certificación bien reconocida. Pero este tema (emisión y mantenimiento de certificados) se ha estancado, aunque 4 supuestamente tiene esa capacidad de autenticación.
Por lo tanto, una vinculación al hardware para la protección de la autoría es, en mi opinión, un retroceso "profundo".
La idea (en las primeras páginas) era implementar el algoritmo de compilación "normal" para el archivo ex5.
El sueño es aproximadamente el siguiente.
El programador es capaz de compilar su programa de manera que pueda ser percibido con precisión por el terminal sólo en presencia de una subclave de rastreo, una compleja concatenación de la clave del desarrollador y del usuario.
Las firmas necesarias de la clave del desarrollador se encontrarían en el programa, así como la clave del usuario en el programa y en la clave del terminal específico.
Entonces, la presencia de esta "licencia-subclave" permitiría utilizarla.
La generación debe ser realizada por el Meta-editor, es decir, el propio desarrollador - habiendo recibido una parte de la clave del cliente.
Así que se imaginó...
Pero algo no sale de la niebla.
Me parece que la posibilidad de generar la clave del desarrollador a partir de la autoridad certificadora "МТ5" y la presencia en el terminal de procedimientos de descifrado ex5 utilizando esa clave y una parte de la clave del usuario resolvería más problemas que ese "servicio nativo", cuyos mecanismos y adecuación no se pueden discutir aquí en absoluto.
;)
Si hablamos de protección de claves, todo Internet estará inundado de estas mismas claves. En otras palabras, en lugar de protección, será una farsa con una implementación compleja que obligará al comprador a gestionar las claves.
La mejor manera es fijarse en el esquema de ventas de la AppStore/iTunes de Apple que funciona. El cliente simplemente hace clic y compra el software sin la molestia de tener que transferir o utilizar claves. Un cliente sólo necesita tener una cuenta en MQL5.com para mantener el historial de compras y reactivar el software previamente adquirido.
Al comprar un programa, el usuario recibe una copia especialmente recompilada/reprotegida, que protege al vendedor mucho mejor que las claves. Todo el proceso de protección personal será automático en el momento de la compra.
Nuestro objetivo es facilitar al máximo el proceso de compraventa.
Creo que hay una característica más importante que falta en este hilo - período de prueba o restricciones de demostración. Los compradores potenciales quieren, con razón, ver primero lo que van a comprar. Para ello, se debe ocultar en algún lugar (encriptado) la información sobre las fechas y/o el tiempo durante el cual el producto adquirido funcionará sin restricciones. Me parece que incrustar un mecanismo de encriptación con un par de claves (a la pgp) en el propio lenguaje puede resolver no sólo esto sino muchos otros problemas.
Tiene sentido vender sólo a un cliente que trabaja en una cuenta real (como si tuviera / debiera tener los medios para comprar). Este número (tal vez + alguna información más como el nombre del servidor, la frase clave o algo más) se utiliza como clave para el descifrado. El proveedor debe tener un mecanismo incorporado para generar un par de claves y cifrar los archivos con él.
¿Qué obtenemos? El promotor crea un archivo con los datos iniciales: por ejemplo, que contiene el número de cuenta y dos fechas desde y hasta las que trabaja en esta cuenta. este archivo está codificado. y se entrega junto con el experto/script/indicador al comprador. para él (y sólo para su cuenta), la plataforma recibe una segunda clave completa para el número de cuenta, lee y descifra el archivo encriptado (puede comprobar la suma de comprobación y no devuelve nada si la clave resultó ser incorrecta) y lo da como una cadena al Asesor Experto / Script / Indicador.
El propio código recibirá estos datos y decidirá si trabaja en modo demo o normal. Incluso puede almacenar parámetros del funcionamiento del EA: por ejemplo, el cruce de MAXX - el algoritmo está claro incluso después de descompilar, pero los parámetros exactos con los que estos MAXX trabajan en beneficio pueden ser "secretos", y no tiene sentido descompilar un EA sin conocer estos parámetros. Por supuesto, hay algunas lagunas y habrá algo que comprometer, pero al no conocer los datos de un archivo encriptado (lo que no se puede conseguir con Asm), todo se vuelve mucho más complicado que simplemente comprar el producto y su soporte al autor.
En resumen: hay que proporcionar un contenedor encriptado, y luego cada uno con los datos que necesita puede disponer de la protección más sofisticada.
Señores, no olviden que esto es un mercado de masas.
Usted cree que en las categorías de trabajo 1:1, el comprador y el vendedor negociarán juntos, intercambiarán ofertas y se enviarán las llaves. Por supuesto, de esta manera no podrás vender mucho. Nosotros, en cambio, ofrecemos una tienda de venta rápida en la que el vendedor no tiene que mover un dedo para vender. Y el comprador sólo tiene que pulsar el botón "comprar" y no molestarse con ningún número de cuenta o generación de claves.
Todo está ya pensado. Si quieres saber cómo va a funcionar, prueba con un iPhone/iPad, comprando software para él en la AppStore.
En mi humilde opinión, la opción de protección ligada al hardware es ideal, tanto en términos de implementación como de facilidad de uso. Hay otro deseo sobre esta variante, pero te lo cuento a continuación.
Las opciones de vinculación con los números de cuenta/nombre del propietario y otras no son convenientes, aunque esto no es obvio a primera vista. Al comprador le gusta cambiar de corredor y abrir nuevas cuentas cada semana, así que ¿qué pasa con la compilación de un producto para él cada vez, y si hay docenas o cientos de usuarios del producto? Las llaves se pueden fundir en la red - tampoco es una opción.
¿Qué pasa con la vinculación al hardware? Es posible que un usuario quiera trabajar con el producto en varios ordenadores, por lo que debe ofrecerse la posibilidad de vincularlo a varias versiones de hardware. Y si el usuario quiere actualizar el hardware disponible, entonces tal vez en estos casos, tendrá que darle, digamos, 1 hora durante la cual se realizará la actualización. Y así sucesivamente. Debemos reflexionar sobre estos puntos. Vincular el producto a una/dos/tres máquinas para siempre es erróneo e injusto para el cliente.
En cuanto a la unión con el hardware. El usuario puede querer utilizar el producto en varias máquinas, por lo que debe ofrecerse la posibilidad de vincularlo a varias opciones de hardware. Y si el usuario quiere actualizar el hardware disponible, entonces tal vez en esos casos, debería permitir, digamos, 1 hora durante la cual el usuario cambia al nuevo hardware. Y así sucesivamente. Debemos reflexionar sobre estos puntos. Vincular un producto a una/dos/tres máquinas para siempre no es correcto ni justo para el cliente.
Pero al mismo tiempo, permitiremos ejecutar en el probador (agente probador) EAs protegidos, para que los usuarios puedan verificar independientemente el rendimiento del EA en el probador y no comprar un cerdo en un poke.
Hay EAs que tienen la historia cosida. O que son capaces de leer la historia desde la base de la historia. Estos EAs ficticios muestran resultados notables en el probador. ¿Habrá alguna protección contra este tipo de fraude? Especialmente si el Asesor Experto se entrega junto con una DLL.
¿Cómo luchará el servicio por su reputación en caso de código MQL5 + DLL malicioso (desde spyware hasta virus)?