Encriptar ByteCode

É claro que isso pode ser quebrado - o próprio artigo diz como “quebrar” o esquema de usar um classloader especial.

É verdade que o class encriptado não é 100% seguro. Mas isso nada é.
A primeira regra de segurança é: Algo é tão mais seguro quanto maior for o custo para violar a sua segurança.
Então, sempre é possivel violar qualquer segurança se vc tiver os recursos necessários (conhecimento , tempo e dinheiro)

O que o artigo do Javawold citado se esqueceu de dizer é que para que o esquema de encriptação funcione é necessário implementar um SecurityManager, de forma que apenas o codigo que passou pelo classloader de encriptação possa ser admitido.
O mesmo SecurityManager pode ser usado para desabilitar o uso de ferramentas que “leêm o codigo directamente da JVM” como os profilers e os debugers.
Então, a questão é : até onde vc quer deixar seu codigo seguro?
Se vc acha que uma compilação nativa o deixaria mais seguro, desengane-se .
Afinal existem por ai um monte de crack para programas nativos.

O esquema de encripatação funciona. Mas quando maior for o nivel de segurança que vc quer, maior terá que ser o seu trabalho em implementá-lo. O nivel do artigo é o básico do conceito e implemenação, e já serve melhor que o .class puro, mas ha mais que se pode fazer.

Uma forma de melhorar um pouco o programa do sr. Roubtsov é fazer o seguinte:

Em vez de executar seu programa pelo java.exe (ou javaw.exe), ele só pode ser executado por um programa seu, de código nativo (C/C++), que carrega a JVM (JVM.DLL) e implementa algumas funções em código nativo, como a criptografia e o carregamento de novas classes.
(E obviamente as classes do seu programa, em vez de estarem agrupadas em arquivos .class ou .jar, podem estar em um formato proprietário seu. Já que vai criptografar os arquivos mesmo…)
Isso complica as coisas um pouco, mas se você for esperto suficientemente, pode até retardar um pouco um cara que queira atacar sua aplicação.

Vou deixar aqui um comentário geral porque este assunto é bastante recorrente.

Quem está pensando em encriptar os seus .class normalmente veio de plataformas como Delphi e Microsoft de codigo nativo. Além disso veio também de paradigmas de distribuição de código proprietário que assumem que codigo nativo é seguro (no sentido de ser irreversivel).
Isto é conhecido como provider-locking. A ideia é que o cliente fica amarrado ao fornecedor porque não tem como alterar o programa ele mesmo.

Ora, código nativo não é irreversivel. Mas mesmo que fosse, não é com bandaids tecnologicos que se resolve a questão.
A questão resolve-se com uma clara licença acompanhando o software/codigo. A licença tem que ser clara, e ha que haver a certeza que a pessoa leu a licença antes de usar o software (ou pelo menos teve essa chance) . É por isso que os instaladores mostram uma licença.
Se alguem violar a licença o problema é judicial e não tecnológico.

A melhor forma de proteger o seu codigo é deixar o codigo aberto.
Primeiro porque sendo aberto ninguem vai querer quebrá-lo.
Depois, o fato de ser aberto deixa as pessoas seguras de que vc não está escondendo nada (vc está?).
As pessoas podem até mudar o seu codigo, mas isso é muito mais complicado que desencriptar classes. Ha que entender a sua logica.
Por outro lado, código aberto deixa outros participar. E essa participação faz a aplicação melhor, e mais segura (em outros aspectos que não o codigo, mas no funcionamento)

Pense: quantos projetos de codigo aberto existem ? Quantas pessoas se dão ao trabalho de os ler ?

Se o seu problema é proteger algum algoritmo proprietário então o que vc tem que fazer é patentear o algoritmo. O algoritmo em si. O algoritmo sempre será seu. Mas querer ele só para si não é rentável.

Java tem uma grande historia porque trouxe muitos parceiros para si. E isso foi possivel porque o codigo foi aberto. Hoje o codigo é totalmente aberto mas vc já o leu ? quanto já o leram e entenderam ?

Se o seu algoritmo é muito dificil, faça a patente, mas lembre-se que se ninguem o usar essa patente não vale nada. Java é patente da Sun, mas seu codigo é visivel por todos. Melhorável por todos.
Se o seu algoritmo é simples, qualquer um poderá criar um semelhante, sem nunca ver seu codigo.

Enfim, tlv vc não queira encriptar seus class no final das contas

É isso aí, Sérgio.

Pô, Sérgio!

Fiquei até emocionado… :lol:
É isso aí! 8)

Exelente texto Sérgio!

clap clap clap sergio!!

Eu sei que esse tópico já é antigo, mas garimpando sobre segurança do código em Java acabei caindo aqui, e gostaria de uma opinião de vocês.

No caso de aplicações desktop, onde eu coloco os dados de conexão com o banco de dados (url, login, password, etc…), se alguém utilizar um programa desses para decompilar poderia acessar os .class e ver esses dados não? Como esse sistema é instalado no computador de vários usuários pode existir algum “metido” que acabe futricando no banco… alguém vê alguma solução pra isso?

[]´s