[OFF] VALE A PENA PROGRAMAR EM NET ?
Deixa ver se eu entendi bem.
O VB.Net nao é seguro ?
Quer dizer que se voce gastar horas, dias, meses codificando vem um curioso e descobre tudo que voce fez em poucos minutos?
Com o velho e bom VB6 não acontece isto de decodificar o seu executavel?
Viva o VB6 !!!!
[txt-size=1]MAS SERà QUE A MICROSOFT IRIA LANÇAR UMA TECNOLOGIA PRA AFUNDAR DEPOIS, DEVIDO A FALHA DE SEGURANÇA????[/txt-size]
Citação::
Deixa ver se eu entendi bem.
O VB.Net nao é seguro ?
Quer dizer que se voce gastar horas, dias, meses codificando vem um curioso e descobre tudo que voce fez em poucos minutos?
Com o velho e bom VB6 não acontece isto de decodificar o seu executavel?
Viva o VB6 !!!!
bom. quamto aos [Ô]curiosos[Ô] existem ofuscadores (embaralham) o código para deixar a escrita menos legÃvel.
me parece que existe uma maneira de deixar a dll criada em .net [Ô]descompilavel[Ô] para ISL
vou ver isso
WOLFFIRE
desde 2003
CLEVERTON,
Pesquise no MSDN sobre o NGEN.EXE (Nativo Gerador de Imagem).
O único incoveniente é que o uma vez convertido o MSIL em código nativo, o EXE só rodará na máquina gerada.
Ou seja, não há como gerar o EXE em sua máquina e enviar para o cliente.
Pesquise no MSDN sobre o NGEN.EXE (Nativo Gerador de Imagem).
O único incoveniente é que o uma vez convertido o MSIL em código nativo, o EXE só rodará na máquina gerada.
Ou seja, não há como gerar o EXE em sua máquina e enviar para o cliente.
Bom, acho que estamos vendo que .Net não é tão seguro... e agora?
Continuar com o VB6 e esquecer que o .Net existe e continuarmos tecnologicamente defasados?
Esperar até que o VB6 seja incompatÃvel com o windows?
Programar em C++?
Ou mudar de profissão?
Continuar com o VB6 e esquecer que o .Net existe e continuarmos tecnologicamente defasados?
Esperar até que o VB6 seja incompatÃvel com o windows?
Programar em C++?
Ou mudar de profissão?
Marcos a questão não é VB, C++ ou C# ou até Delphi, mas sim a plataforma .Net. Qualquer dessas linguagens possuem versões atuais para .Net, e dessa forma podem ser decompiladas, já que o princÃpio do .Net é gerar o tal MISL, mas sim o que fazer para evitar a decompilação.
Então o que precisamos saber e decidir é:
1- Adotar o .Net com ofuscadores?
2- Adotar o .Net como front and, e a parte de segurança da aplicação (criptografia, registro do software, regras de negócio, etc...) ficar em outra tecnologia integrada ao .Net?
3- Mudar de plataforma de desenvolvimento, ou seja, não .Net?
Análises:
1- Adotando essa posição, como já comentei, há vários programas no mercado chamados ofuscadores, uns gratuitos e outros pagos. Sendo assim o que precisamos saber é qual ferramentas dessa é a melhor. O melhor é uma análise criteriosa sobre o resultado obtido por ela, seja no real ofuscamento e dificuldade de reversão/compreensão do código no sua reversão. Se a Ferramenta escolhida não possui ela mesmo uma reversão da própria ofuscação, já li que existem algumas com tal recurso o que as tornaria igualmente inviáveis.
2- Se uma tecnologia auxiliar não .Net poderia resolver isso, seria um caminho, apesar de muito mais complexo e trabalhoso. Como exemplo poderÃamos ter dlls desenvolvidas em VB6 com todos os nossos [Ô]Segredos tecnológicos[Ô] do aplicativo guardados nela. Também poderia ser outra linguagem qualquer, mas aqui terÃamos de saber o que seria mais viável para o desenvolvimento com nossos conhecimentos/ compatibilidade com o .Net (integração) e possibilidade de perpetuação em futuras versões do Windows, pois se não puderem ser usadas quando o VB6 não tiver continuidade, de nada adiantaria. Aqui cabe uma pergunta que não sei responder: Uma DLL feita em VB6 que não use recursos externos ao Runtime do VB6 deixaria de funcionar caso o VB6 perca o suporte me novas versões do Windows?
3- Para mudar de plataforma acredito eu que seria obrigatório migrar para Web, com um PHP, ou algo assim. Isso porque continuar em ambiente windows implica em esbarrarmos em novas tecnologias da Microsoft que impeça o uso de qualquer tipo de aplicação não .Net no futuro próximo. Pois se retirarem o suporte ao VB6, nada impede que qualquer outra apliação não .Net rode também, ou seja, só aplicativos integrados ao frameworks funcionem.
Aqui também cabe uma questão, será que um aplicativo feito em linguagens C puro (não .Net) também não funcionariam numa situação dessas? O problema é aprender tal tipo de linguagem. Para mim vejo isso como inviável, pois não tenho mais idade, [Ô]Saco[Ô] ou desejo de aprender algo tão diferente assim.
Conclusões poderão ser obtidas com nossos debates criteriosos, estudos e pesquisas sobre o assunto. Acho que todos procurando juntos poderemos chegar a conclusões interessantes e soluções viáveis. Como em informática não há forma certa de fazer nada, ou seja, há muitas maneiras de se chegar ao mesmo resultado/objetivo, acredito que aqui não seja diferente.
O que precisamos é usar a criatividade brasileira e força de vontade para pesquisar e encontrarmos uma alternativa viável. Quem sabe o Cleverton consegue algo com a tal DLL do Weber que inclusive poderia dar seu parecer aqui, se é que ainda continua na comunidade.
Então o que precisamos saber e decidir é:
1- Adotar o .Net com ofuscadores?
2- Adotar o .Net como front and, e a parte de segurança da aplicação (criptografia, registro do software, regras de negócio, etc...) ficar em outra tecnologia integrada ao .Net?
3- Mudar de plataforma de desenvolvimento, ou seja, não .Net?
Análises:
1- Adotando essa posição, como já comentei, há vários programas no mercado chamados ofuscadores, uns gratuitos e outros pagos. Sendo assim o que precisamos saber é qual ferramentas dessa é a melhor. O melhor é uma análise criteriosa sobre o resultado obtido por ela, seja no real ofuscamento e dificuldade de reversão/compreensão do código no sua reversão. Se a Ferramenta escolhida não possui ela mesmo uma reversão da própria ofuscação, já li que existem algumas com tal recurso o que as tornaria igualmente inviáveis.
2- Se uma tecnologia auxiliar não .Net poderia resolver isso, seria um caminho, apesar de muito mais complexo e trabalhoso. Como exemplo poderÃamos ter dlls desenvolvidas em VB6 com todos os nossos [Ô]Segredos tecnológicos[Ô] do aplicativo guardados nela. Também poderia ser outra linguagem qualquer, mas aqui terÃamos de saber o que seria mais viável para o desenvolvimento com nossos conhecimentos/ compatibilidade com o .Net (integração) e possibilidade de perpetuação em futuras versões do Windows, pois se não puderem ser usadas quando o VB6 não tiver continuidade, de nada adiantaria. Aqui cabe uma pergunta que não sei responder: Uma DLL feita em VB6 que não use recursos externos ao Runtime do VB6 deixaria de funcionar caso o VB6 perca o suporte me novas versões do Windows?
3- Para mudar de plataforma acredito eu que seria obrigatório migrar para Web, com um PHP, ou algo assim. Isso porque continuar em ambiente windows implica em esbarrarmos em novas tecnologias da Microsoft que impeça o uso de qualquer tipo de aplicação não .Net no futuro próximo. Pois se retirarem o suporte ao VB6, nada impede que qualquer outra apliação não .Net rode também, ou seja, só aplicativos integrados ao frameworks funcionem.
Aqui também cabe uma questão, será que um aplicativo feito em linguagens C puro (não .Net) também não funcionariam numa situação dessas? O problema é aprender tal tipo de linguagem. Para mim vejo isso como inviável, pois não tenho mais idade, [Ô]Saco[Ô] ou desejo de aprender algo tão diferente assim.
Conclusões poderão ser obtidas com nossos debates criteriosos, estudos e pesquisas sobre o assunto. Acho que todos procurando juntos poderemos chegar a conclusões interessantes e soluções viáveis. Como em informática não há forma certa de fazer nada, ou seja, há muitas maneiras de se chegar ao mesmo resultado/objetivo, acredito que aqui não seja diferente.
O que precisamos é usar a criatividade brasileira e força de vontade para pesquisar e encontrarmos uma alternativa viável. Quem sabe o Cleverton consegue algo com a tal DLL do Weber que inclusive poderia dar seu parecer aqui, se é que ainda continua na comunidade.
Tirei um tempo pra dá uma pesquisada, e [txt-color=#0000f0]parece[/txt-color] que a melhor forma é usar ofuscadores mesmo. Tentei achar alguma coisa vinda da própria MS sobre a decomplição dos exe e qual seria sua indicação pra poder proteger, mas não encontrei nada, a não ser MVPs indicando ofuscação.
Olha, como toda linguagem que depende de uma maquina virtual, ela pode ser descompilada como é o que acontece com JAVA e o .NET, só que nenhum programador java se preocupa com isso pois a ideologia deles é apoiar o software livre, mas programadores .NET que pensam em agregar valor no software do que no serviço tem desvantagem neste sentido.
Só que sistemas grandes de verdadade, praticamente é impossÃvel mexer sem uma documentação, principalmente se o código ficar ofuscado.
Mas vejo que a maior parte do pessoal aqui ainda não entendeu que aplicativos WIN32 nativos perderam lugar para aplicativos WEB, clora que existira alguma demanda, mas desde quando voce precisa ter conexão WEB para ter aplicativos ASP.NET rodando na sua empresa? Vocês não conhecem INTRANET? Basta apenas a empresa ter um servidor com o IIS configurado e seu aplicativo instalado nela, que qualquer computador com navegador na rede acessa seu aplicativo. Podendo ser até aquele computador de 10 anos atrás.
Só que sistemas grandes de verdadade, praticamente é impossÃvel mexer sem uma documentação, principalmente se o código ficar ofuscado.
Mas vejo que a maior parte do pessoal aqui ainda não entendeu que aplicativos WIN32 nativos perderam lugar para aplicativos WEB, clora que existira alguma demanda, mas desde quando voce precisa ter conexão WEB para ter aplicativos ASP.NET rodando na sua empresa? Vocês não conhecem INTRANET? Basta apenas a empresa ter um servidor com o IIS configurado e seu aplicativo instalado nela, que qualquer computador com navegador na rede acessa seu aplicativo. Podendo ser até aquele computador de 10 anos atrás.
Mas então comercialmente falando, será que alguém irá desenvolver um ERP em ASP para vender?
Que segurança teria isso se o código fica exposto no servidor do cliente?
Sem falar nos programas corporativos (Meu caso), mas só de aplicativos para desktop como: WinRar, WinZip, Nero, Babylon, Photoshop, entre milhares de outros, será que as empresas desenvolvedoras irão desenvolver isso em .Net?
Será que a Microsiga irá migrar seu ERP para .Net?
Agora falando de programinhas para PetShop, VideoLocadora, etc.. acho que tudo bem.
Que segurança teria isso se o código fica exposto no servidor do cliente?
Sem falar nos programas corporativos (Meu caso), mas só de aplicativos para desktop como: WinRar, WinZip, Nero, Babylon, Photoshop, entre milhares de outros, será que as empresas desenvolvedoras irão desenvolver isso em .Net?
Será que a Microsiga irá migrar seu ERP para .Net?
Agora falando de programinhas para PetShop, VideoLocadora, etc.. acho que tudo bem.
Aproveitando a deixa, eu coloquei uma situação, mas ainda não obtive retorno de colegas.
Tive várias idéias sobre tentar proteger o código, nada ainda confirmado.
1- converter um MSIL do VB.net para C++.net, pois este último é a única ferramenta do VS.net que pode gerar código 100% binário. Então bastaria gerar o MSIL no VB.net, decompilar para C++.net e recompilar pelo C++ para binário, mas não sei se é possÃvel converter de VB ou C# para C++, sei que os dois primeiros é 100% compatÃvel.
2- uma outra situação, como o Ngen só gerar um EXE que funciona na máquina onde foi gerado, surgiu a dúvida: Seria possÃvel gerar o EXE pelo Ngen em cada estação de trabalho? Assim ao distribuir nosso aplicativo MSIL, ao final da instalação o instalador deveria chamar o NGEN e mandar ele compilar no próprio micro. Será que isso funciona?
Nota: Caso o item 2 funcione, o Ngen é um utilitário do VS.net ou está contido no Framewoks/Windows de cada micro sem o VS.net. Se for do VS, ele pode ser distribuÃdo com nossos aplicativos ou não.
Tive várias idéias sobre tentar proteger o código, nada ainda confirmado.
1- converter um MSIL do VB.net para C++.net, pois este último é a única ferramenta do VS.net que pode gerar código 100% binário. Então bastaria gerar o MSIL no VB.net, decompilar para C++.net e recompilar pelo C++ para binário, mas não sei se é possÃvel converter de VB ou C# para C++, sei que os dois primeiros é 100% compatÃvel.
2- uma outra situação, como o Ngen só gerar um EXE que funciona na máquina onde foi gerado, surgiu a dúvida: Seria possÃvel gerar o EXE pelo Ngen em cada estação de trabalho? Assim ao distribuir nosso aplicativo MSIL, ao final da instalação o instalador deveria chamar o NGEN e mandar ele compilar no próprio micro. Será que isso funciona?
Nota: Caso o item 2 funcione, o Ngen é um utilitário do VS.net ou está contido no Framewoks/Windows de cada micro sem o VS.net. Se for do VS, ele pode ser distribuÃdo com nossos aplicativos ou não.
Tópico encerrado , respostas não são mais permitidas