PROTEGENDO SOFTWARE PIRATARIA - CODIGO ASSEMBLY
Citação::
Uma das soluções que implemento é colocar pedidos de senhas diferentes programadas para determinado perÃodo... tipo de 3 em 3 meses...
Assim, um energumino que soltar uma versão [Ô]de grátis[Ô] para toda a net, uma hora vai dar pau... aÃ, o usuário terá que procurar alguém... tipo assim: o desenvolvedor... :)
Queria implementar umas proteções e fazer testes...Alguém sabe como acho um desses programas que visualizam em Assembler?... Com este programa posso fazer testes se minha aplicação tá fácil ou dificil de quebrar
Ola LEAO10
Eu tambem pensava que nem voce... mas no caso se teu programa verifica a validade de 3 em 3 meses, o cracker vai desbloquear ele apenas 01 vez e ficara desbloqueado pra sempre.
O que o cracker faz é modificar o codigo (o IF do seu codigo, que valida o sistema), e nao apenas validar o sistema.
Citação:Ola LEAO10
Eu tambem pensava que nem voce... mas no caso se teu programa verifica a validade de 3 em 3 meses, o cracker vai desbloquear ele apenas 01 vez e ficara desbloqueado pra sempre.
O que o cracker faz é modificar o codigo (o IF do seu codigo, que valida o sistema), e nao apenas validar o sistema.
Olá MAICONJG
Acho que não expliquei direito o que faço: Meu sistema possui inúmeros formulários, e coloco as proteções em vários formulários aleatoriamente, e para complicar um pouco, o sistema possui IF's de validação de campo, para saber se o usuário colocou algum item errado num campo, e no meio de um desses eu coloco um IF para um campo text, só que este campo na verdade está validando o serial...
Lógico que, a intenção é dificultar, porque pelo que estou vendo, é impossÃvel evitar...
Bem se o pessoal tá preocupado com VB6 (pra mim muito seguro por ter um Runtime e tudo separado em OCX e DLL), então quando chegarem no Dot.Net vão ter um ataque cardÃaco (risos para não chorar).
Estou lendo e vou colocar algumas experiências, não vou citar nomes, pois não quero reler tudo então só citarei os tópicos.
- é a pura verdade, não existe 100% de segurança em nada na informática. Porém se pode dificultar o máximo para que sobrem poucos hackers competentes que possam burlar sua segurança, e sendo seu sistema não tão importante ou conhecido, terá menos chances de ver seu código burlado.
- Há um grande conjunto de ferramentas que podem ser usadas para proteger um programa, cada uma com suas vantagens e problemas. Cabe avaliar o quanto de benefÃcio terá com cada recurso incluÃdo, olhando sempre para os problemas que possam ser gerados aos suas clientes (usuários), pois algo problemática, espantará mais os clientes do que os piratas de plantão.
- Talento e Conhecimento - concordo perfeitamente com o Kerplunk. Isso é um diferencial que ninguém poderá substituir, e você conhce bem seu negócio, os outros não. Eu mesmo já desisti de olhar códigos de programas de terceiros fornecidos gratuitamente para uso e estudo, pois é tanta complicação para seguir que é melhor fazer o nosso mesmo. Cada um tem sua metodologia de codificação, só ficando mais uniforma com OOP.
- O VB6 não é tão simples de reverter como dizem. Ele tem componentes externos e com isso dificulta muito. O uso de ferramentas licenciadas de terceiros, complica ainda mais, pois não se pode usar uma OCX ou DLL sem estar registrada. Assim, fica um monte de bloqueios pelo código, quanto mais componentes de terceiros tiver, mais complicado é usá-los num programa pirateado.
- Cada programa compressor tem sua própria assinatura. é através dela que se sabe qual programa PE foi usado, como se faz mais facilmente com as extensões dos arquivos e assim identificar o Editor dele. Para evitar que um programa saiba que o gerou, basta remover a assinatura interna vis editor Hex, assim nem o próprio programa poderá reverter sua compressão, mas continuará funcionando normalmente na RAM.
- Strong Names é uma ótima solução nesses casos, pois se o programa for recompilado não funcionará. Porém nada impede que se copie o código visÃvel e cria um novo programa com ele, isso dá muito mais trabalho e pode gerar problemas futuros.
- Usar texto e dados de acesso no fonte é realmente suicÃdio, mas há casos que não há outra opção. Se não tiver um Webservice, não tem como resolver o acesso de banco na web ou STMP por email. Se alguém souver explica. Agora no VB6, se pode criptografar o código com alguma rotina em uma DLL por exemplo, assim fica mais complicado. Isso no Dot.Net já não resolve, pois se pode ler direto na RAM facilmente, então criptografia só do fonte, mas dos dados não adianta.
Algumas dicas, depois que perdi meses estudando o assunto.
- Há formas de proteger mais os fontes, mas como disse alguém aqui, não são compartilhadas e guardadas para quem sabe, mesmo não sendo 100% e melhor que nada.
- Seu sistema deve estar em permanente manutenção (atualizações, tanto de correções como de implementações), se isso ocorrer o cidadão que comprou seu programa irá encher a paciência do indivÃduo que vendeu, obridando-o a ter um trabalho constante de refazer toda a decryptografia, craquear seu programa para atualizá-lo a seus clientes.
- Uma versão DEMO é fundamental para tornar um sistema vendável, pois sem ver é difÃcil alguém comprar, ou você terá um custo enorme com visitas para demonstrar, onde nem 5% se concretiza. Digo por experiência, a maioria das empresas que fui, só estava procurando algo para ter idéia de como desenvolver, ou fazer comparação com o que já tinha ou com outros fornecedores. Depois que coloquei um DEMO, é que comecei a ganhar dinheiro, hoje não visito mais ninguém.
- Seu demo não deve conter as rotinas importantes, só as básicas. Não grava, Só inclui e edita. Não faz validações, só a versão final comprada, então não fica na Web.
- Pode incluir bugs propositais na versão demo, assim o program irá apresentar problema sempre. Ou encher de mensagens de versão demo a cada ação, isso já é um grande transtorno.
- Todas as rotinas e variáveis devem ser nomeada com o nome da empresa ou aplicativo, assim o código ficaria documentado.
- a cada nova versão (mensal é uma boa), muda a forma de licenciamento. Assim o cara teria um grande trabalho para mudar isso a cada versão sua.
- Só disponibilize atualizações aos clientes em área segura do site, não para qualquer um. Assim seu código de atualização estará mais seguro e só disponÃvel aos clientes e se fazer, algum cliente é o responsável. Nesse caso poderia usar uma rotina especÃfica para cada cliente, e se vazar, teria como descobri de que cliente partiu. Isso auxiliaria a ter alguma ação com esse cliente.
Veja que cada medida obriga em mais trabalho para você, em algumas consequencia aos seus clientes, e assim por diante. Os prós e contras devem ser analisados sempre.
Infelizmente é esse o mundo que vivemos. Salve o VB6, problema é com o Dot.Net.
Um último comentário final, e não direcionado a ninguém em especial, só para análise de cada um: Antes de reclamar de piratear nossos softwares que geraram tanto trabalho e suor, pense se você não usa nenhum pirata de outro também, a começar do Windows, Officer, Antivirus, etc........
Canso de ver gente reclamando, mas usa tudo pirata e quer que o seu não seja. Só existe software pirata porque tem gente que usa, o mesmo para mercadoria contrabandeadas e de baixa qualidade, o mesmo para Drogas. Se ninguém usar não terá traficante, tudo é assim.
Então não comprem produtos de camelôs (roubados, contrabandeados ou de péssima qualidade que não pagam tributos e podem ser fruto até de trabalho escravo, como muito carvão para churrasco vendido no Brasil sem nota ou imposto e com derrubada de florestas).
Não compre CDs piratas por R$ 5,00
Não compre ou baixe softwares piratas em Torrentes, etc...
Não compre joguinhos para PC, PS3, Xbox, etc... por R$ 10,00
etc...
etc...
etc...
Se todos fizermos nossa parte e criticarmos quem faz isso ilegalmente, inclusive parentes e amigos, começaremos a mudar a nossa volta. Ninguém gosta de passar vergonha. Eu já mudei minha postura a algum tempo, agora só uso coisas legais. Nunca mais parei em banca de camelô, desde que me tornei programador.
Lembren-se o exemplo é o melhor caminho e forma de educação, começando por nos mesmos e nossos filhos.
Abraços e boa sorte.
Estou lendo e vou colocar algumas experiências, não vou citar nomes, pois não quero reler tudo então só citarei os tópicos.
- é a pura verdade, não existe 100% de segurança em nada na informática. Porém se pode dificultar o máximo para que sobrem poucos hackers competentes que possam burlar sua segurança, e sendo seu sistema não tão importante ou conhecido, terá menos chances de ver seu código burlado.
- Há um grande conjunto de ferramentas que podem ser usadas para proteger um programa, cada uma com suas vantagens e problemas. Cabe avaliar o quanto de benefÃcio terá com cada recurso incluÃdo, olhando sempre para os problemas que possam ser gerados aos suas clientes (usuários), pois algo problemática, espantará mais os clientes do que os piratas de plantão.
- Talento e Conhecimento - concordo perfeitamente com o Kerplunk. Isso é um diferencial que ninguém poderá substituir, e você conhce bem seu negócio, os outros não. Eu mesmo já desisti de olhar códigos de programas de terceiros fornecidos gratuitamente para uso e estudo, pois é tanta complicação para seguir que é melhor fazer o nosso mesmo. Cada um tem sua metodologia de codificação, só ficando mais uniforma com OOP.
- O VB6 não é tão simples de reverter como dizem. Ele tem componentes externos e com isso dificulta muito. O uso de ferramentas licenciadas de terceiros, complica ainda mais, pois não se pode usar uma OCX ou DLL sem estar registrada. Assim, fica um monte de bloqueios pelo código, quanto mais componentes de terceiros tiver, mais complicado é usá-los num programa pirateado.
- Cada programa compressor tem sua própria assinatura. é através dela que se sabe qual programa PE foi usado, como se faz mais facilmente com as extensões dos arquivos e assim identificar o Editor dele. Para evitar que um programa saiba que o gerou, basta remover a assinatura interna vis editor Hex, assim nem o próprio programa poderá reverter sua compressão, mas continuará funcionando normalmente na RAM.
- Strong Names é uma ótima solução nesses casos, pois se o programa for recompilado não funcionará. Porém nada impede que se copie o código visÃvel e cria um novo programa com ele, isso dá muito mais trabalho e pode gerar problemas futuros.
- Usar texto e dados de acesso no fonte é realmente suicÃdio, mas há casos que não há outra opção. Se não tiver um Webservice, não tem como resolver o acesso de banco na web ou STMP por email. Se alguém souver explica. Agora no VB6, se pode criptografar o código com alguma rotina em uma DLL por exemplo, assim fica mais complicado. Isso no Dot.Net já não resolve, pois se pode ler direto na RAM facilmente, então criptografia só do fonte, mas dos dados não adianta.
Algumas dicas, depois que perdi meses estudando o assunto.
- Há formas de proteger mais os fontes, mas como disse alguém aqui, não são compartilhadas e guardadas para quem sabe, mesmo não sendo 100% e melhor que nada.
- Seu sistema deve estar em permanente manutenção (atualizações, tanto de correções como de implementações), se isso ocorrer o cidadão que comprou seu programa irá encher a paciência do indivÃduo que vendeu, obridando-o a ter um trabalho constante de refazer toda a decryptografia, craquear seu programa para atualizá-lo a seus clientes.
- Uma versão DEMO é fundamental para tornar um sistema vendável, pois sem ver é difÃcil alguém comprar, ou você terá um custo enorme com visitas para demonstrar, onde nem 5% se concretiza. Digo por experiência, a maioria das empresas que fui, só estava procurando algo para ter idéia de como desenvolver, ou fazer comparação com o que já tinha ou com outros fornecedores. Depois que coloquei um DEMO, é que comecei a ganhar dinheiro, hoje não visito mais ninguém.
- Seu demo não deve conter as rotinas importantes, só as básicas. Não grava, Só inclui e edita. Não faz validações, só a versão final comprada, então não fica na Web.
- Pode incluir bugs propositais na versão demo, assim o program irá apresentar problema sempre. Ou encher de mensagens de versão demo a cada ação, isso já é um grande transtorno.
- Todas as rotinas e variáveis devem ser nomeada com o nome da empresa ou aplicativo, assim o código ficaria documentado.
- a cada nova versão (mensal é uma boa), muda a forma de licenciamento. Assim o cara teria um grande trabalho para mudar isso a cada versão sua.
- Só disponibilize atualizações aos clientes em área segura do site, não para qualquer um. Assim seu código de atualização estará mais seguro e só disponÃvel aos clientes e se fazer, algum cliente é o responsável. Nesse caso poderia usar uma rotina especÃfica para cada cliente, e se vazar, teria como descobri de que cliente partiu. Isso auxiliaria a ter alguma ação com esse cliente.
Veja que cada medida obriga em mais trabalho para você, em algumas consequencia aos seus clientes, e assim por diante. Os prós e contras devem ser analisados sempre.
Infelizmente é esse o mundo que vivemos. Salve o VB6, problema é com o Dot.Net.
Um último comentário final, e não direcionado a ninguém em especial, só para análise de cada um: Antes de reclamar de piratear nossos softwares que geraram tanto trabalho e suor, pense se você não usa nenhum pirata de outro também, a começar do Windows, Officer, Antivirus, etc........
Canso de ver gente reclamando, mas usa tudo pirata e quer que o seu não seja. Só existe software pirata porque tem gente que usa, o mesmo para mercadoria contrabandeadas e de baixa qualidade, o mesmo para Drogas. Se ninguém usar não terá traficante, tudo é assim.
Então não comprem produtos de camelôs (roubados, contrabandeados ou de péssima qualidade que não pagam tributos e podem ser fruto até de trabalho escravo, como muito carvão para churrasco vendido no Brasil sem nota ou imposto e com derrubada de florestas).
Não compre CDs piratas por R$ 5,00
Não compre ou baixe softwares piratas em Torrentes, etc...
Não compre joguinhos para PC, PS3, Xbox, etc... por R$ 10,00
etc...
etc...
etc...
Se todos fizermos nossa parte e criticarmos quem faz isso ilegalmente, inclusive parentes e amigos, começaremos a mudar a nossa volta. Ninguém gosta de passar vergonha. Eu já mudei minha postura a algum tempo, agora só uso coisas legais. Nunca mais parei em banca de camelô, desde que me tornei programador.
Lembren-se o exemplo é o melhor caminho e forma de educação, começando por nos mesmos e nossos filhos.
Abraços e boa sorte.
A tempo Kurtgu
Simples o VB6 gera código binário já o Dot.Net gera linguagem intermediária (meta tags) que serão compiladas na hora da execução para a plataforma correta (windows, framework, 32 ou 64 bits, etc...) chamada MSIL (um EXE falso digamos assim) e não EXE real (binário)
Citação:o foda e isso cara e que as empresas a maioria so cria ofuscador pra .net nao sei o por que nunca achei pra vb6...
Simples o VB6 gera código binário já o Dot.Net gera linguagem intermediária (meta tags) que serão compiladas na hora da execução para a plataforma correta (windows, framework, 32 ou 64 bits, etc...) chamada MSIL (um EXE falso digamos assim) e não EXE real (binário)
Tópico encerrado , respostas não são mais permitidas