.NET - MAIS UMA FERRAMENTA CONTRA PROTECAO DO CODI
Continuando sempre com a colaboração.....segue mais uma descoberta, ou seria melhor chamar de [Ô]Tragédia[Ô].
Se já tinha os 2 pés atrás com o .Net, agora acho melhor vira as costas. Qual o caminho agora?
Descobri hoje que o [Ô]MAldito[Ô] cidadão que criou o Reflector, depois de passá-lo para a Red Gate’s .NET Reflector tool, decidiu criar um outro [Ô]brinquedinho[Ô] o Crack.Net.
Se não bastasse ter um decompilador dos EXE para .net, como criaram os ofuscadores (duvidosos também concordo), este cidadão agora deu um passo a frente, Vai direto na memória RAM do micro e vasculha ou altera qualquer coisa em execução, e ainda integrou ao Reflector. Imagino com isso que fica fácil pegar números de licenças, chaves de acesso, e qualquer coisa importante facilmente, inclusive encontrando os pontos por onde o programe roda em cada parte da execução.
Se alguém estava [Ô]muito preocupado[Ô] com segurança de seus aplicativos, agora é para ficar em PÂNICO mesmo.
<b>Dessa forma será o fim dos programas comerciais?
Como proteger algo 100% desprotegido?</b>
Sinceramente eu não consigo ver como viver comercialmente na programação depois que o VB6 não tiver mais suportes com o Windows 8, em se confirmando tal [Ô]murmúrio[Ô] da web. Ou vai tudo para Web e em servidores próprios e dedicados ou ficará tudo vulnerável. Acho ser essa a intenção mesmo da Microsoft, deixar tudo na Web e ganhar com a tal Nuvem, aumentando os custos das empresas, investimento em treinamento e pior, tudo e todos ficarem presos (reféns) de terceiras, pois não haverá mais controle de nada, sempre alguém estará interferindo com serviços intermediários.
Boa semana, se é que tal notÃcia permitirá isso. Abaixo o texto:
******************
Crack.NET é uma depuração runtime e ferramenta de scripting que eu fiz que lhe dá acesso aos componentes internos de qualquer aplicação de desktop. NET em execução no computador. Se você ama e Snoop Mole para o Visual Studio, você vai adorar Crack.NET também. Crack.NET permite [Ô]caminhar[Ô] no heap gerenciado de outro aplicativo. NET, inspecionar todos os tipos de valores em objetos, e até mesmo manipular os objetos através de scripts IronPython. Há tanta coisa a dizer sobre Crack.NET que eu escrevi um artigo sobre isso. Eu sugiro que você leia o artigo se você estiver interessado em usar Crack.NET. Você pode baixar esse documento aqui:
Leia o artigo Crack.NET (documento do Microsoft Word)
Versão 1.2 News
Em 02 de novembro de 2008, eu liberei Crack.NET v1.2 no site CodePlex. Além de várias correções de bugs pequenos, eu adicionei um item big-ticket. Crack.NET agora está totalmente integrado com a ferramenta Red Gate Reflector. NET. Na memória Explorer espaço de trabalho, botão direito do mouse em qualquer Digite o TreeView ou qualquer Nome do membro no ListView. Um menu de contexto será exibido, permitindo que você abra Reflector diretamente a esse tipo / membro. Clique nas imagens abaixo para visualizar-las em tamanho completo.
http://joshsmithonwpf.wordpress.com/cracknet/
Se já tinha os 2 pés atrás com o .Net, agora acho melhor vira as costas. Qual o caminho agora?
Descobri hoje que o [Ô]MAldito[Ô] cidadão que criou o Reflector, depois de passá-lo para a Red Gate’s .NET Reflector tool, decidiu criar um outro [Ô]brinquedinho[Ô] o Crack.Net.
Se não bastasse ter um decompilador dos EXE para .net, como criaram os ofuscadores (duvidosos também concordo), este cidadão agora deu um passo a frente, Vai direto na memória RAM do micro e vasculha ou altera qualquer coisa em execução, e ainda integrou ao Reflector. Imagino com isso que fica fácil pegar números de licenças, chaves de acesso, e qualquer coisa importante facilmente, inclusive encontrando os pontos por onde o programe roda em cada parte da execução.
Se alguém estava [Ô]muito preocupado[Ô] com segurança de seus aplicativos, agora é para ficar em PÂNICO mesmo.
<b>Dessa forma será o fim dos programas comerciais?
Como proteger algo 100% desprotegido?</b>
Sinceramente eu não consigo ver como viver comercialmente na programação depois que o VB6 não tiver mais suportes com o Windows 8, em se confirmando tal [Ô]murmúrio[Ô] da web. Ou vai tudo para Web e em servidores próprios e dedicados ou ficará tudo vulnerável. Acho ser essa a intenção mesmo da Microsoft, deixar tudo na Web e ganhar com a tal Nuvem, aumentando os custos das empresas, investimento em treinamento e pior, tudo e todos ficarem presos (reféns) de terceiras, pois não haverá mais controle de nada, sempre alguém estará interferindo com serviços intermediários.
Boa semana, se é que tal notÃcia permitirá isso. Abaixo o texto:
******************
Crack.NET é uma depuração runtime e ferramenta de scripting que eu fiz que lhe dá acesso aos componentes internos de qualquer aplicação de desktop. NET em execução no computador. Se você ama e Snoop Mole para o Visual Studio, você vai adorar Crack.NET também. Crack.NET permite [Ô]caminhar[Ô] no heap gerenciado de outro aplicativo. NET, inspecionar todos os tipos de valores em objetos, e até mesmo manipular os objetos através de scripts IronPython. Há tanta coisa a dizer sobre Crack.NET que eu escrevi um artigo sobre isso. Eu sugiro que você leia o artigo se você estiver interessado em usar Crack.NET. Você pode baixar esse documento aqui:
Leia o artigo Crack.NET (documento do Microsoft Word)
Versão 1.2 News
Em 02 de novembro de 2008, eu liberei Crack.NET v1.2 no site CodePlex. Além de várias correções de bugs pequenos, eu adicionei um item big-ticket. Crack.NET agora está totalmente integrado com a ferramenta Red Gate Reflector. NET. Na memória Explorer espaço de trabalho, botão direito do mouse em qualquer Digite o TreeView ou qualquer Nome do membro no ListView. Um menu de contexto será exibido, permitindo que você abra Reflector diretamente a esse tipo / membro. Clique nas imagens abaixo para visualizar-las em tamanho completo.
http://joshsmithonwpf.wordpress.com/cracknet/
eh foda, eu até comecei a mecher com XNA Game Studio pra desextressar asuhaushasu
Agora que o circo vai pegar fogo para Microsoft. Se eles não inventarem algo para proteger os programas deles, o jeito é migrar para o Java (arc)
Só que o Java é digamos [Ô]igual[Ô], poist também tem linguagem IL como o .Net.
Na realidade até agora só encontrei duas alternativas, ir para Web (se bem que o código fica disponÃvel num servidor de terceiros e muitos clientes não aceitam ficar sem o controle de seus conteúdos = dados), além de ser uma responsabilidade absurda proteger dados dos clientes contra ataques, ou usar o C que digamos é muito mais difÃcil, porém dispensa esses IL.
Existem muitas linguagens novas circulando nos fóruns, mas fica difÃcil identificar qual seria recomendável, principalmetne porque cada uma tem pontos fortes e fracos diferentes, além de uma distância muito grande do que conhecemos por VB hoje. Fora contar que na maioria seria preciso mudar tudo, desde a IDE, aprender a nova linguagem, instaladores, comunicação com banco de dados e até mesmo o próprio banco de dados.
Na realidade até agora só encontrei duas alternativas, ir para Web (se bem que o código fica disponÃvel num servidor de terceiros e muitos clientes não aceitam ficar sem o controle de seus conteúdos = dados), além de ser uma responsabilidade absurda proteger dados dos clientes contra ataques, ou usar o C que digamos é muito mais difÃcil, porém dispensa esses IL.
Existem muitas linguagens novas circulando nos fóruns, mas fica difÃcil identificar qual seria recomendável, principalmetne porque cada uma tem pontos fortes e fracos diferentes, além de uma distância muito grande do que conhecemos por VB hoje. Fora contar que na maioria seria preciso mudar tudo, desde a IDE, aprender a nova linguagem, instaladores, comunicação com banco de dados e até mesmo o próprio banco de dados.
Continuando a saga....
Estes dias andei lendo alguns posts de foruns americanos principalmente, onde há um grande movimento de preocupação também com o .Net.
Pelo que và a maioria das pessoas que participam são funcionários de empresas que usam a linguagem para uso próprio e não para desenvolvimento comercial, assim não há grande preocupação e um ofuscador resolve o problema.
As poucas pessoas que và realmente preocupadas são desenvolvedores autônomos ou pequenas empresas com aplicativos especÃficos, onde o software representa a [Ô]Vida[Ô] dessas empresas. Nesse caso o problema é sério mesmo como sempre pensei.
Pelo que pude perceber, as GRANDES empresas não estão preocupadas, ao menos não demonstram, uma ves que possuem recursos e pessoal qualificado para utilização de outras linguagens para suas aplicações importantes. Geralmente o pessoal está usando C++ para o desenvolvimento. o .Net está relegado a pequenos recursos de auxilio ao usuário e que se vazarem não comprometem seu negócio, ex: Utilitário de algumas impressoras HP, etc...
O que o pessoal está fazendo para se proteger basicamente é:
- Programar em C++ e não usar .Net
- Desenvolver a parte mais importante do código (centro vital) em C++ e o restante em .Net ofuscado.
- Utilizar webservices, porém isso não é viável na maioria dos casos, pois não há como pensar em deixar uma aplicação [Ô]presa[Ô] a um webservice que pode sair do ar a qualquer momento e deixar o cliente sem acesso e você não poder fazer nada a respeito. Ou então o cliente perder o acesso a Web, coisa comum com os provedores atuais,e não conseguir usar seus sistemas.
- Migrar toda aplicação para web, o que cai mais ou menos no mesmo acima.
Estes dias andei lendo alguns posts de foruns americanos principalmente, onde há um grande movimento de preocupação também com o .Net.
Pelo que và a maioria das pessoas que participam são funcionários de empresas que usam a linguagem para uso próprio e não para desenvolvimento comercial, assim não há grande preocupação e um ofuscador resolve o problema.
As poucas pessoas que và realmente preocupadas são desenvolvedores autônomos ou pequenas empresas com aplicativos especÃficos, onde o software representa a [Ô]Vida[Ô] dessas empresas. Nesse caso o problema é sério mesmo como sempre pensei.
Pelo que pude perceber, as GRANDES empresas não estão preocupadas, ao menos não demonstram, uma ves que possuem recursos e pessoal qualificado para utilização de outras linguagens para suas aplicações importantes. Geralmente o pessoal está usando C++ para o desenvolvimento. o .Net está relegado a pequenos recursos de auxilio ao usuário e que se vazarem não comprometem seu negócio, ex: Utilitário de algumas impressoras HP, etc...
O que o pessoal está fazendo para se proteger basicamente é:
- Programar em C++ e não usar .Net
- Desenvolver a parte mais importante do código (centro vital) em C++ e o restante em .Net ofuscado.
- Utilizar webservices, porém isso não é viável na maioria dos casos, pois não há como pensar em deixar uma aplicação [Ô]presa[Ô] a um webservice que pode sair do ar a qualquer momento e deixar o cliente sem acesso e você não poder fazer nada a respeito. Ou então o cliente perder o acesso a Web, coisa comum com os provedores atuais,e não conseguir usar seus sistemas.
- Migrar toda aplicação para web, o que cai mais ou menos no mesmo acima.
OCELOT boa tarde!
Concordo com quase tudo que disse, mas....
Primeiro não sou eu que digo, como citou. O que escrevi é que pelos foruns que naveguei, encontrei as informações que transmiti aqui. Assim não estou afirmando, só constatando com base nos resultados obtidos OK? Claro que isso não é uma pesquisa cientÃfica, só uma breve constatação do que pude encontrar.
Sempre soube que em informática nada é 100% seguro, principalmente porque toda a estrutura do desenvolvimento de softwares, segundo o dono da Norton e divulgado em meados de1990, foi baseada numa plataforma equivocada. Para se conseguir criar aplicações 100% seguras e impossÃveis de decompilação, seria preciso reinventar a informática do ZERO, o que segundo ele será impossÃvel a médio prazo e talvez nunca seja feito, pelo alto investimento, falta de interesse e principalmente pelo transtorno de migração.
Agora há um ponto de vista importante em sua colocação e que precisa ficar muito claro, até mesmo para uma avaliação correta do assunto.
Minha preocupação e de muitos programadores não é com a pirataria (citada por você e até detalhada) onde um hacker ou alguma pessoa pega o serial de um software e usa em outros micros (empresas como citou) para não pagar licença, ou quebra a proteção dele para uso sem registro. Isso eu realmente nunca fiquei preocupado e sei que não há como impedir, pois como bem citou, todos os grandes softwares do mercado são quebrados rapidamente, até Playstation 3 e Xbox 360 (hardwares) foram, então software é brincadeira de criança para esses desocupados cibernéticos.
<b>O que me preocupa realmente</b> no .Net ou Java é que qualquer um, de posse dessas ferramentas, pode facilmente recuperar 100% do código de um projeto inteiro. Não é questão de identificar o serial de registro ou tirar a proteção de validação, mas abrir seu projeto, mudar tudo. Telas, campos, regras, e até quem desenvolveu. Assim dando uma nova cara ao projeto inicial e até comercializando como sendo do cidadão [Ô]LADRÃO[Ô]. Isso sim é preocupante.
Além disso tem o lado dos concorrentes que podem abrir seu código e ter acesso a partes importantes que eles não tinham conseguido desenvolver, no mÃnimo conseguir uma boa idéia de como você conseguiu fazer. Isso sim é preocupante.
Com o projeto aberto, independente se chamou a função abreArquivo de y ou variável Cliente de uhb, ok dá um baita trabalho, mas o cara pode fazer misérias e montar um projeto semelhante ao seu de [Ô]Mão-beijada[Ô].
Para os que dependem de um software para se manter no mercado, isso é um risco ao fechamento de qualquer pequena empresa ou comprometer o trabalho de qualquer autônomo, pois estas empresas atuam em nichos de mercado e que poderiam perder sua <b>exclusividade</b> ou <b>diferencial</b> de um momento para outro.
<b>Agora uma parte que me interessou no seu comentário foi:</b>
==============================================
Poderia explicar melhor a parte em negrito?
Se o código está completamente aberto a decompilação no .Net , como poderia proteger parte do código para não ser alterado? Não entendi.
Bom feriado a todos.
Concordo com quase tudo que disse, mas....
Primeiro não sou eu que digo, como citou. O que escrevi é que pelos foruns que naveguei, encontrei as informações que transmiti aqui. Assim não estou afirmando, só constatando com base nos resultados obtidos OK? Claro que isso não é uma pesquisa cientÃfica, só uma breve constatação do que pude encontrar.
Sempre soube que em informática nada é 100% seguro, principalmente porque toda a estrutura do desenvolvimento de softwares, segundo o dono da Norton e divulgado em meados de1990, foi baseada numa plataforma equivocada. Para se conseguir criar aplicações 100% seguras e impossÃveis de decompilação, seria preciso reinventar a informática do ZERO, o que segundo ele será impossÃvel a médio prazo e talvez nunca seja feito, pelo alto investimento, falta de interesse e principalmente pelo transtorno de migração.
Agora há um ponto de vista importante em sua colocação e que precisa ficar muito claro, até mesmo para uma avaliação correta do assunto.
Minha preocupação e de muitos programadores não é com a pirataria (citada por você e até detalhada) onde um hacker ou alguma pessoa pega o serial de um software e usa em outros micros (empresas como citou) para não pagar licença, ou quebra a proteção dele para uso sem registro. Isso eu realmente nunca fiquei preocupado e sei que não há como impedir, pois como bem citou, todos os grandes softwares do mercado são quebrados rapidamente, até Playstation 3 e Xbox 360 (hardwares) foram, então software é brincadeira de criança para esses desocupados cibernéticos.
<b>O que me preocupa realmente</b> no .Net ou Java é que qualquer um, de posse dessas ferramentas, pode facilmente recuperar 100% do código de um projeto inteiro. Não é questão de identificar o serial de registro ou tirar a proteção de validação, mas abrir seu projeto, mudar tudo. Telas, campos, regras, e até quem desenvolveu. Assim dando uma nova cara ao projeto inicial e até comercializando como sendo do cidadão [Ô]LADRÃO[Ô]. Isso sim é preocupante.
Além disso tem o lado dos concorrentes que podem abrir seu código e ter acesso a partes importantes que eles não tinham conseguido desenvolver, no mÃnimo conseguir uma boa idéia de como você conseguiu fazer. Isso sim é preocupante.
Com o projeto aberto, independente se chamou a função abreArquivo de y ou variável Cliente de uhb, ok dá um baita trabalho, mas o cara pode fazer misérias e montar um projeto semelhante ao seu de [Ô]Mão-beijada[Ô].
Para os que dependem de um software para se manter no mercado, isso é um risco ao fechamento de qualquer pequena empresa ou comprometer o trabalho de qualquer autônomo, pois estas empresas atuam em nichos de mercado e que poderiam perder sua <b>exclusividade</b> ou <b>diferencial</b> de um momento para outro.
<b>Agora uma parte que me interessou no seu comentário foi:</b>
==============================================
Citação:...[Ô] <b>verificações no próprio código</b> seriam outra, uma que eu acho bem interessante também é criptografar e <b>não permitir que o cliente modifique certos dados da empresa</b> no programa, como CNPJ, Razão Social e Nome Fantasia, e fazendo que qualquer e-mail e relatório saia com estes dados, o que dificulta de usarem o programa em outra empresa, além de mostrar de onde saiu o programa que foi pirateado.[Ô]
Poderia explicar melhor a parte em negrito?
Se o código está completamente aberto a decompilação no .Net , como poderia proteger parte do código para não ser alterado? Não entendi.
Bom feriado a todos.
Grandes empresas são as que mais usam .Net em Java, pois a maioria dos sistemas deles trabalham apenas internamente, e a produtividade dessas ferramentas não pode ser desprezada num cenário corporativo. Se usam C/C++ hoje me alguns projetos, só se for por uma necessidade bem especÃfica em que o software produzido nessa ferramenta oferece, ou software legado mesmo.
Aplicações web (bem feitas claro) trabalhando na Intranet da empresa como as desktop fazem hoje, com o servidor bem configurado e com permissões bem definidas de diretório para o sistema onde ficam os scripts apenas para a empresa de desenvolvimento, e que não permita que qualquer zé graça fique executando dumpers de memória, acredito que seja uma boa alternativa.
Aplicações web (bem feitas claro) trabalhando na Intranet da empresa como as desktop fazem hoje, com o servidor bem configurado e com permissões bem definidas de diretório para o sistema onde ficam os scripts apenas para a empresa de desenvolvimento, e que não permita que qualquer zé graça fique executando dumpers de memória, acredito que seja uma boa alternativa.
Existem grandes sistemas desenvolvidos em .Net e não é tão fácil quebrar suas proteções. é mais trabalhoso pois são apenas desenvolvidos em conceitos novos por exemplo o numero de camadas.
mas posso garantir que abrir o código fonte é difÃcil e quase impossÃvel. pois as grandes empresas trabalham com o .Net (C#, VB.Net). Hoje é possivel até compilar até os codigo *.sql para SGBD que antes não tinhamos;
Utilizo minhas aplicações para Desktop, WebServer e Mobile. e não tive 05% de quebra de Código. Eu mesmo testei utilizando o Reflector ou o JustDecompiler e não obtive sucesso mesmo sabendo como o código fonte funcionava.
é o mesmo principio do Editor de HEX vc troca informações de Label objetos fixos mas não reverte retira criptografia de código que tenha polimorfismo, classes serializadas dados criptografados entre outros.
é uma matéria um pouco complexa mas vale apenas entender o conceito de Segurança para Framework 3.5 4.0
Este é o começo para estudar e entender caso alguem se interesse.....
http://msdn.microsoft.com/pt-br/library/w0x726c2.aspx
Existem empresas como IBM, ITAU, etc.. utilizam aplicações em Framework 2.0, 3.5 e 4.0 que são muito complexas e tão seguras quanto;
Elas ainda utilizar CRC, MD5, MD4, HASH são criptografias conhecidas mas depende da forma que são utilizadas
Um bom exemplo é criar Tabelas com usuário e senha no Oracle e utilizar ainda o velho MD5 para encriptar o campo de senhas.
Criar um Projeto com um Label.Text = HELLO WORD.
Depois trocar o conteudo do Label.Text para qq coisa, não podemos classificar como quebra de segurança.
Isso acontece com qq outra linguagem J2EE, COBOL, C/C++, ASM etc...
Hoje o mercado exige que cada aplicativo ERP, Admin, Cadastro, etc.. faça cada vez mais coisas e com informações externas.
Desenvolver suas aplicações em 2, 3 ou 4 Camadas é o mais seguro para seus códigos.
boa Sorte a todos
mas posso garantir que abrir o código fonte é difÃcil e quase impossÃvel. pois as grandes empresas trabalham com o .Net (C#, VB.Net). Hoje é possivel até compilar até os codigo *.sql para SGBD que antes não tinhamos;
Utilizo minhas aplicações para Desktop, WebServer e Mobile. e não tive 05% de quebra de Código. Eu mesmo testei utilizando o Reflector ou o JustDecompiler e não obtive sucesso mesmo sabendo como o código fonte funcionava.
é o mesmo principio do Editor de HEX vc troca informações de Label objetos fixos mas não reverte retira criptografia de código que tenha polimorfismo, classes serializadas dados criptografados entre outros.
é uma matéria um pouco complexa mas vale apenas entender o conceito de Segurança para Framework 3.5 4.0
Este é o começo para estudar e entender caso alguem se interesse.....
http://msdn.microsoft.com/pt-br/library/w0x726c2.aspx
Existem empresas como IBM, ITAU, etc.. utilizam aplicações em Framework 2.0, 3.5 e 4.0 que são muito complexas e tão seguras quanto;
Elas ainda utilizar CRC, MD5, MD4, HASH são criptografias conhecidas mas depende da forma que são utilizadas
Um bom exemplo é criar Tabelas com usuário e senha no Oracle e utilizar ainda o velho MD5 para encriptar o campo de senhas.
Criar um Projeto com um Label.Text = HELLO WORD.
Depois trocar o conteudo do Label.Text para qq coisa, não podemos classificar como quebra de segurança.
Isso acontece com qq outra linguagem J2EE, COBOL, C/C++, ASM etc...
Hoje o mercado exige que cada aplicativo ERP, Admin, Cadastro, etc.. faça cada vez mais coisas e com informações externas.
Desenvolver suas aplicações em 2, 3 ou 4 Camadas é o mais seguro para seus códigos.
boa Sorte a todos
Excelentes posts AJSO e OCELOT. Vcs poderiam produzir um artigo e subir aqui pro VBM. Esse assunto é recorrente aqui e importante.
Tópico encerrado , respostas não são mais permitidas