Como nós bem sabemos o AutoCAD é uma ferramenta tão importante para engenharia como o Windows é para o restante do mundo. Podemos dizer que quando alguém associa desenho e engenharia a primeira coisa que vem a mente é o AutoCAD.
Com o tempo nós vamos desenvolvendo nossas soluções para o AutoCAD, primeiro em AutoLISP, depois em VBA, ObjectARX e .NET.
Quem nunca fez uma LISP para si, mostrou para um amigo e agora uma pessoa do outro lado do mundo usa um código parecido com que você desenvolveu. é e ainda está com aquele comentário que você deixou!
A manter a sua propriedade intelectual em suas mãos é sempre um desafio para qualquer programador.
Como um desenvolvedor profissional (ou amador) enviar um código para frente sempre há um risco de que esse código seja enviado a outras pessoas e utilizado de forma não licenciada.
Isso é um problema se os seus códigos são pré-compilados ou protegidos por algum tipo de senha que pode ser aberto pelo usuário final.
Vamos fazer uma breve análise da solução menos segura para mais segura:
A propriedade intelectual sempre foi um problema em rotinas AutoLISP. Logo no início quando ainda era chamado de Visual LISP o código era diretamente e puramente interpretado pelo AutoCAD.
Esse tipo de abordagem permite que um código em LISP seja interpretado linha a linha e não necessite de uma compilação. A vantagem é óbvia, pessoas com baixo conhecimento de programação ou até mesmo sem um editor de sintaxe conseguem montar pequenas rotinas em LISP e modifica-las sem dificuldade.
Ao longo do tempo a Autodesk viu a necessidade de criar recursos para dificultar a copia e disseminação dos códigos AutoLISP. Basicamente há duas formas de fazer isso:
Nem sei se ainda existe alguém que utiliza ou desenvolve alguma coisa em VB6.
No geral as ferramentas de cracking disponíveis parecem funcionar com um princípio de força bruta - elas percorrerão possíveis senhas até que uma funcione -, se você realmente deseja proteger seu código, recomendo o uso de uma senha longa torna-o mais seguro. Uma senha de 16 caracteres precisa de no máximo 20922789888000 interações para ser quebrada!
O código gerenciado é compilado em assemblies (dll) que contêm o Microsoft Intermediate Language (MSIL) (Instruções diretas para cpu) além de metadados que descrevem tipos, membros e referências ao código em outros assemblies. Em tempo de execução, o MSIL é convertido em instruções específicas da CPU por um compilador just-in-time (JIT).
Esses assemblies são muito fáceis de desmontar em algo semelhante ao código fonte original (embora sem comentários ou nomes de variáveis significativos, mas os nomes e tipos de funções internas são mantidos).
Assim como o Kelvinator existem ferramentas de ofuscação disponíveis para idiomas .NET. O Visual Studio fornece o Dotfuscator Community Edition que nada mais é do que uma dessas ferramentas funcionam em assemblies .NET, reduzindo a facilidade com que alguém pode fazer engenharia reversa.
Acho que podemos ponderar por dois lados, todos esses métodos de desmontar assemblies .NET são os mais complexos de todos. O copista além de manjar de AutoCAD precisará saber muito bem como funciona os recursos de desmonte de código e depois como tudo é feito por isso acho muito pouco prático realizar esse tipo de investida especialmente por aquilo que eu digo da relação esforço/retorno muito baixa.
Com o tempo nós vamos desenvolvendo nossas soluções para o AutoCAD, primeiro em AutoLISP, depois em VBA, ObjectARX e .NET.
Quem nunca fez uma LISP para si, mostrou para um amigo e agora uma pessoa do outro lado do mundo usa um código parecido com que você desenvolveu. é e ainda está com aquele comentário que você deixou!
A manter a sua propriedade intelectual em suas mãos é sempre um desafio para qualquer programador.
Como um desenvolvedor profissional (ou amador) enviar um código para frente sempre há um risco de que esse código seja enviado a outras pessoas e utilizado de forma não licenciada.
Isso é um problema se os seus códigos são pré-compilados ou protegidos por algum tipo de senha que pode ser aberto pelo usuário final.
Vamos fazer uma breve análise da solução menos segura para mais segura:
LISP
A propriedade intelectual sempre foi um problema em rotinas AutoLISP. Logo no início quando ainda era chamado de Visual LISP o código era diretamente e puramente interpretado pelo AutoCAD. 
Esse tipo de abordagem permite que um código em LISP seja interpretado linha a linha e não necessite de uma compilação. A vantagem é óbvia, pessoas com baixo conhecimento de programação ou até mesmo sem um editor de sintaxe conseguem montar pequenas rotinas em LISP e modifica-las sem dificuldade.
Ao longo do tempo a Autodesk viu a necessidade de criar recursos para dificultar a copia e disseminação dos códigos AutoLISP. Basicamente há duas formas de fazer isso:
“The Kelvinator”
Seira o que eu eu chamo de terra da confusão, basicamente é você tirar qualquer espaço tabulação ou comentários que permite ou facilite a reprodução do código. Por isso que as LISP’s são sempre bem limpas de comentários.
A ideia é simples: se não posso impedir a reprodução então vou dificultar.
Eu li isso a muito tempo em um Livro que esse termo “Kelvinator” surgiu com Kelvin R. Throop que trabalhou na Autodesk fazendo diversas ferramentas em AutoLISP nos anos 80 e 90. A fama era tão grande que o termo ficou para a história.
O funcionamento é até efetivo, mas com um bom editor de LISP você poderia retornar com os espaços e remontar a lisp e com um bom esforço saber como as variáveis são manipuladas e como tudo é executado no script.
Antigamente os desenvolvedores utilizavam a técnica combinada do Kelvinator e depois protegiam seus códigos LISP antes de distribuí-los. Outras opções eram usar a compilação LISP. Exista uma versão do R13 (ultima versão antes do mouse, veja só!) um compilador de LISP era o Vital LISP (que mais tarde se tornou o Visual LISP) forneceu durante um tempo recursos de compilação.
O Visual LISP foi a quebra de um paradigma para desenvolvedores de LISP permitindo que eles compilassem corretamente o LISP em um formato de fato protegido. O Visual LISP suporta dois modos de compilação: (i) cada arquivo LISP pode ser compilado para um formato chamado FAS, que pode ser carregado diretamente no AutoCAD e, por sua vez, pode ser empacotado em módulos VLX. Originalmente, o Visual LISP permitia a compilação no ARX, mas essas eram essencialmente cópias VL com o código compilado armazenado como um recurso interno do projeto, além de complicado poderia acarretar aqueles tradicionais problemas de compatibilidade.
Poucas vezes distribui LISP’s, na verdade eu não gosto muito de usar LISP para soluções que podem ser distribuídas, mas também poucas vezes utilizei lisp’s compiladas em DAS ou VLX.
Não sei se alguém conseguiu quebrar essa compilação, mas com certeza seria uma relação esforço/retorno é bem baixa considerando os recursos máximos permitidos em LISP.
A ideia é simples: se não posso impedir a reprodução então vou dificultar.
Eu li isso a muito tempo em um Livro que esse termo “Kelvinator” surgiu com Kelvin R. Throop que trabalhou na Autodesk fazendo diversas ferramentas em AutoLISP nos anos 80 e 90. A fama era tão grande que o termo ficou para a história.
O funcionamento é até efetivo, mas com um bom editor de LISP você poderia retornar com os espaços e remontar a lisp e com um bom esforço saber como as variáveis são manipuladas e como tudo é executado no script.
Usando o Protect.exe
Esse é um recurso que não permite que os arquivos LISP sejam facilmente interpretados por editores de texto tipo ASCII.Antigamente os desenvolvedores utilizavam a técnica combinada do Kelvinator e depois protegiam seus códigos LISP antes de distribuí-los. Outras opções eram usar a compilação LISP. Exista uma versão do R13 (ultima versão antes do mouse, veja só!) um compilador de LISP era o Vital LISP (que mais tarde se tornou o Visual LISP) forneceu durante um tempo recursos de compilação.
O Visual LISP foi a quebra de um paradigma para desenvolvedores de LISP permitindo que eles compilassem corretamente o LISP em um formato de fato protegido. O Visual LISP suporta dois modos de compilação: (i) cada arquivo LISP pode ser compilado para um formato chamado FAS, que pode ser carregado diretamente no AutoCAD e, por sua vez, pode ser empacotado em módulos VLX. Originalmente, o Visual LISP permitia a compilação no ARX, mas essas eram essencialmente cópias VL com o código compilado armazenado como um recurso interno do projeto, além de complicado poderia acarretar aqueles tradicionais problemas de compatibilidade.
Poucas vezes distribui LISP’s, na verdade eu não gosto muito de usar LISP para soluções que podem ser distribuídas, mas também poucas vezes utilizei lisp’s compiladas em DAS ou VLX.
Não sei se alguém conseguiu quebrar essa compilação, mas com certeza seria uma relação esforço/retorno é bem baixa considerando os recursos máximos permitidos em LISP.
VB6
O IDE do VB6 permite a compilação de código executável - embora código que exija um runtime component por isso também acredito que código seja suficientemente seguro pela questão do esforço/retorno...Nem sei se ainda existe alguém que utiliza ou desenvolve alguma coisa em VB6.
VBA
O componente VBA incorporado no AutoCAD permite a proteção por senha dos arquivos DVB (fica em Propriedades do projeto no IDE do VBA). Essa proteção por senha usa criptografia padrão para bloquear o código fonte. Entendo é conhecimento bem difundido na internet ferramentas de cracking estão disponíveis para módulos VBA protegidos.No geral as ferramentas de cracking disponíveis parecem funcionar com um princípio de força bruta - elas percorrerão possíveis senhas até que uma funcione -, se você realmente deseja proteger seu código, recomendo o uso de uma senha longa torna-o mais seguro. Uma senha de 16 caracteres precisa de no máximo 20922789888000 interações para ser quebrada!
ObjectARX
Esse problema não existe em linguagens compiladas como o caso do ObjectARX onde as saída do compilador C++ não incluir nenhum código fonte ( a não ser que você envie os arquivos PDB’s). Podemos dizer que esse é um recurso bem seguro..NET
O que dizer a respeito do .NET? Bom, basicamente é o que torna a melhor solução é exatamente a segurança na distribuição do código, praticamente um consenso entre os desenvolvedores de código em .NET para todas as aplicações em ambiente Windows e Linux (porque não? Veja o Monodevelop).O código gerenciado é compilado em assemblies (dll) que contêm o Microsoft Intermediate Language (MSIL) (Instruções diretas para cpu) além de metadados que descrevem tipos, membros e referências ao código em outros assemblies. Em tempo de execução, o MSIL é convertido em instruções específicas da CPU por um compilador just-in-time (JIT).
Esses assemblies são muito fáceis de desmontar em algo semelhante ao código fonte original (embora sem comentários ou nomes de variáveis significativos, mas os nomes e tipos de funções internas são mantidos).
Assim como o Kelvinator existem ferramentas de ofuscação disponíveis para idiomas .NET. O Visual Studio fornece o Dotfuscator Community Edition que nada mais é do que uma dessas ferramentas funcionam em assemblies .NET, reduzindo a facilidade com que alguém pode fazer engenharia reversa.
Acho que podemos ponderar por dois lados, todos esses métodos de desmontar assemblies .NET são os mais complexos de todos. O copista além de manjar de AutoCAD precisará saber muito bem como funciona os recursos de desmonte de código e depois como tudo é feito por isso acho muito pouco prático realizar esse tipo de investida especialmente por aquilo que eu digo da relação esforço/retorno muito baixa.
Comentários
Postar um comentário