Protecção de autoria de código MQL em MT5. - página 7
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
por exemplo
Comprador: encontra informação na Internet, escreve quer comprar
Vendedor: Descreve o mecanismo de pagamento - se não quiser fornecer os detalhes de pagamento, ser-lhe-á pedido que forneça as suas informações personalizadas.
o comprador: paga e envia os dados de personalização, número de conta ou nome completo, que é a chave
Vendedor: envia os bens atribuídos aos dados pessoais.
idealmente, é isso!
Tenho tais casos, e não poucos
Infelizmente, isto não torna a vida mais complicada para alguns freeloaders (pessoas que estão no assunto). A ligação a uma conta também não é a solução de todos os problemas, qualquer "copiadora de transacções" competente transferirá todos os dados para qualquer outra conta (especialmente se os dados forem copiados de MT5 para MT5).
Na minha opinião, não só especialistas mas também guiões, indicadores, bibliotecas e outros códigos devem ser protegidos. Na minha opinião, este é um tema mais interessante e importante.
Porque é que é mais importante?
Como sabemos, todas as ferramentas que podem ser implementadas usando MQL estão divididas em: sistemas automatizados, sistemas semi-automatizados, e ferramentas para comércio manual.
Há também uma divisão em sistemas: "caixas negras", "caixas cinzentas" e sistemas "brancos" (sistemas com código aberto e lógica explicitamente descrita).
Assim, quase todos os MTS apresentados no sector comercial serão caixas pretas ou cinzentas. O seu peso específico não será tão grande (penso que não excederá 30-40%). Ao mesmo tempo, tais soluções serão bastante inflexíveis (porque, na sua essência, implementam apenas uma estratégia).
Os guiões, bibliotecas e indicadores separados são outra questão. Estas soluções de software estarão disponíveis em todas as áreas de comércio manual e mecânico. Ao mesmo tempo, poderão ser utilizados como elementos básicos do construtor.
PS
Aqui, na minha opinião, é necessário maximizar a protecção, e de modo a não infringir os direitos dos criadores e utilizadores. A única forma óptima de protecção neste caso... Pelo que sei, existe apenas uma - Ligar ao hardware.
O que quer que pense para si próprio, a ligação ao hardware já não é um método eficaz de protecção. A propósito, para uma pessoa mal familiarizada com Asmus (e há muito mais do que alguns deles) a remoção de tal protecção é uma questão de minutos. E não importa aquilo a que se vai ligar. Leia os fóruns de programação (leia hacking) e tudo se tornará claro para si. :) E que tal "boa organização", tente, por experiência, ligar alguma da sua produção em massa ao hardware e estou certo de que, passado algum tempo (cerca de um mês ou dois), compreenderá o que lhe queria dizer.
Como se houvesse quaisquer outras opções de protecção?
Surpreende-me que pergunte isso. É claro que há. E muitos deles. Desde simples recodificadores, a geradores de licenças, a métodos de protecção de software de hardware, tais como HASP, etc. Mas quase todos eles, independentemente do seu custo e da fiabilidade declarada, foram rachados durante muito tempo, e os códigos de rachadura, keygenes e outros softwares andam pela Internet em acesso aberto. E atrevo-me a dizer que estes métodos de protecção são várias ordens de magnitude mais fiáveis do que a simples ligação ao hardware.
No contexto do MT4/MT5 MQL4/MQL5 + DLL ligação pode ser feita não ao hardware, mas ao número de conta (números), para nome real e/ou nome de família, em alternativa nome do meio
Esta forma é a mais fácil em termos de segurança (para esta situação específica) - é móvel e não requer a ligação ao hardware.
Iniciando este tópico, tivemos ('cada'!) o nosso próprio certificado emitido pela Metakwots. É evidente que esta ainda não é uma autoridade de certificação bem reconhecida. Mas este tópico (emissão e manutenção de certificados) estagnou, embora 4 supostamente tenha uma tal capacidade de autenticação.
Portanto, uma ligação ao hardware para protecção da autoria é, creio eu, um retrocesso "profundo".
A ideia (sobre isto nas primeiras páginas) era implementar o algoritmo de compilação "normal" para o ficheiro do ex5.
O sonho é aproximadamente o seguinte.
O programador é capaz de compilar o seu programa para que este só possa ser percepcionado com precisão pelo terminal na presença de uma subchave de rastreio - uma concatenação complexa da chave do programador e do utilizador.
As assinaturas necessárias da chave do programador sentar-se-iam no programa, assim como a chave do utilizador no programa e na chave do terminal específico.
A presença desta "licença-subchave" tornaria então possível a sua utilização.
A geração deve ser feita pelo Meta-editor, ou seja, o próprio desenvolvedor - tendo recebido uma parte da chave do cliente.
Assim foi imaginado...
Mas algo não sai do nevoeiro.
Parece-me que a possibilidade de gerar a chave do programador a partir da autoridade certificadora "МТ5" e a presença no terminal de procedimentos de descodificação do ex5 utilizando essa chave e uma parte da chave do utilizador resolveria mais problemas do que esse "serviço nativo" - cujos mecanismos e adequação não podem de modo algum ser discutidos aqui.
;)
Se estivermos a falar de protecção de chaves, toda a Internet será inundada por estas mesmas chaves. Por outras palavras, em vez de protecção, será uma farsa com uma implementação complexa que obrigará o comprador a gerir as chaves.
A melhor maneira é olhar para o esquema de vendas AppStore/iTunes da Apple que funciona. O cliente simplesmente clica e compra o software sem o incómodo de ter de transferir ou utilizar chaves. Um cliente só precisa de ter uma conta MQL5.com para reter o seu histórico de compras e reactivar programas previamente adquiridos.
Ao comprar um programa, o utilizador recebe uma cópia especialmente recompilada/reprotegida, que protege o vendedor muito melhor do que as chaves. Todo o processo de protecção pessoal será automático no momento da compra.
O nosso objectivo é tornar o processo de compra/venda tão fácil quanto possível.
Penso que falta mais uma característica importante neste tópico - período experimental ou restrições de demonstração. Os potenciais compradores querem, justificadamente, ver primeiro o que estão a comprar. Para este fim, em algum lugar deve ser escondida (encriptada) informação sobre as datas e/ou hora durante as quais o produto adquirido funcionará sem restrições. Parece-me que a incorporação de um mecanismo de encriptação com um par de chaves (a la pgp) na própria língua pode resolver não só este mas muitos outros problemas.
Faz sentido vender apenas a um cliente que trabalha com uma conta real (como ele tem / deve ter os meios para comprar). Este número (talvez + mais alguma informação como nome de servidor, frase chave ou outra coisa) é usado como chave para decifrar. O fornecedor deve ter um mecanismo incorporado para gerar pares de chaves e encriptar ficheiros com elas.
O que é que recebemos? O criador cria um ficheiro com os dados iniciais: por exemplo, contendo o número de conta e duas datas de e para as quais trabalha nesta conta. este ficheiro é encriptado. e é dado juntamente com o perito/script/indicador ao comprador. A plataforma recebe (e só o cliente tem na conta) a segunda chave, lê e desencripta o ficheiro encriptado (pode verificar o checksum e não devolver nada se a chave se revelar errada) e dá-a como uma string ao Expert Advisor / Script / Indicator.
O próprio código que recebe estes dados determinará se funciona em modo de demonstração ou normal. Pode mesmo armazenar parâmetros do funcionamento da EA: por exemplo, cruzamento de MAXX - o algoritmo será evidente mesmo depois da descompilação, mas os parâmetros exactos com que estes MAXX funcionam em modo de lucro podem ser "secretos", e não faz sentido descompilar uma EA sem conhecer estes parâmetros. Claro que também há buracos e haverá algo a comprometer, mas não conhecendo os dados no ficheiro encriptado (que não se pode obter com assimetria), tudo se torna muito mais difícil do que simplesmente comprar o produto e o seu apoio ao autor.
Conclusão: é necessário fornecer um contentor encriptado, e depois todos podem colocar os dados de que necessitam e providenciar a protecção mais sofisticada.
Cavalheiros, não se esqueçam que este é um mercado de massas.
Pensa-se nas categorias de trabalho 1:1, que o comprador e o vendedor irão negociar em conjunto, trocar propostas e enviar as chaves um ao outro. É claro que desta forma não poderá vender muito. Nós, por outro lado, oferecemos uma loja de venda rápida onde o vendedor nem sequer tem de levantar um dedo para as vendas. E o comprador só tem de premir o botão "comprar" e não se incomodar com qualquer número de conta ou geração de chaves.
Tudo já foi pensado. Se quiser saber como vai funcionar, experimente um iPhone/iPad, comprando software para ele na AppStore.
Na minha humilde opinião, a opção de protecção ligada ao hardware é ideal, tanto em termos de implementação como de facilidade de utilização. Existe um outro desejo sobre esta variante, mas vou falar-vos a seguir sobre ele.
As opções de ligação aos números de conta/ nome do proprietário e outros não são convenientes, embora isto não seja óbvio à primeira vista. O comprador gosta de mudar de corretor e abrir novas contas todas as semanas, e se houver dezenas ou centenas de utilizadores do produto? As chaves podem ser fundidas na rede - também não é uma opção.
E quanto à ligação ao hardware? Um utilizador pode querer trabalhar com o produto em vários computadores e depois deve ser fornecida a possibilidade de ligação a várias versões de hardware. E se o utilizador quiser actualizar o hardware disponível, então talvez em tais casos, terá de lhe dar, digamos, 1 hora durante a qual a actualização será realizada. E assim por diante. Precisamos de pensar sobre estes pontos. Ligar o produto a uma/duas/três máquinas para sempre é errado e injusto para o cliente.
Quanto à ligação ao hardware. O utilizador pode querer utilizar o produto em várias máquinas, então deve ser fornecida a possibilidade de ligação a várias opções de hardware. E se o utilizador quiser actualizar o hardware disponível, então talvez em tais casos, deve permitir, digamos, 1 hora durante a qual o utilizador muda para o novo hardware. E assim por diante. Precisamos de pensar sobre estes pontos. Ligar um produto a uma/duas/três máquinas para sempre não é correcto e justo para o cliente.
Mas, ao mesmo tempo, permitiremos correr no testador (agente testador) EAs protegidos, para que os utilizadores possam verificar independentemente o desempenho da EA no testador e não comprar um porco num poço.
Há EAs que têm a história costurada neles. Ou que são capazes de ler a história a partir da base da história. Tais EAs fictícios mostram resultados notáveis no testador. Haverá alguma protecção contra este tipo de fraude? Especialmente se o Expert Advisor for entregue juntamente com uma DLL.
Como irá o serviço lutar pela sua reputação em caso de código MQL5 + DLL malicioso (de spyware a vírus)?