Você ofusca seu código Java comercial?[fechado]

StackOverflow https://stackoverflow.com/questions/12088

  •  08-06-2019
  •  | 
  •  

Pergunta

Gostaria de saber se alguém usa ofuscadores Java comerciais/gratuitos em seu próprio produto comercial.Conheço apenas um projeto que realmente teve uma etapa ofuscante na etapa de construção do ant para lançamentos.

Você ofusca?E se sim, por que você ofusca?

É realmente uma forma de proteger o código ou é apenas uma sensação melhor para os desenvolvedores/gerentes?

editar: Ok, para ser exato sobre o meu ponto:Você ofusca para proteger seu IP (seus algoritmos, o trabalho que você colocou em seu produto)?Não vou ofuscar por razões de segurança, isso não parece certo.Então, estou falando apenas sobre proteger o código do seu aplicativo contra concorrentes.

@staffan tem um bom argumento:

O motivo para evitar o encadeamento do fluxo de código é que algumas dessas alterações tornam impossível para a JVM otimizar o código com eficiência.Na verdade, isso degradará o desempenho do seu aplicativo.

Foi útil?

Solução

Se você fizer Ofuscação, ficar longe de obfuscators que modificam o código alterando o fluxo de código e / ou a adição de blocos de exceção e como torná-lo difícil de desmontá-lo. Para tornar o código ilegível geralmente é suficiente apenas para mudar todos os nomes de métodos, campos e classes.

A razão para ficar longe de mudar o fluxo de código é que algumas dessas mudanças torna impossível para a JVM para otimizar eficientemente o código. Com efeito ele vai realmente prejudicar o desempenho de sua aplicação.

Outras dicas

Eu acho que a maneira antiga (clássica) do ofuscação está gradualmente perdendo sua relevância. Porque na maioria dos casos um obfuscators clássicos quebrar um rastreamento de pilha (não é bom para o apoio seus clientes)

Hoje em dia o principal ponto de não proteger alguns algoritmos, mas para proteger a dados sensíveis: API logins / senhas / chaves, código que responsável pelo licenciamento (a pirataria ainda aqui, sobretudo da Europa Ocidental, Rússia, Ásia, IMHO), anúncio conta IDs, etc.

Fato interessante: nós temos todos esses dados sensíveis em Cordas. Na verdade Cordas é de cerca de 50-80% da lógica das nossas aplicações. Parece-me que o futuro de ofuscação é "ferramentas de criptografia de Cadeia".

Mas agora "criptografia String" recurso está disponível apenas em obfuscators comerciais, tais como: Allatori , Zelix KlassMaster , Smokescreen , Stringer Java Obfuscation Toolkit , DashO .

NB. Eu sou CEO da Licel LLC. Desenvolvedor de Stringer Java Obfuscator.

Eu uso ProGuard para o desenvolvimento JavaME. Não é apenas muito, muito bom em fazer arquivos jar menor (essenciais para celular), mas é útil como uma maneira mais agradável de fazer código específico do dispositivo, sem recorrer a IDE-hostil ferramentas de pré-processamento, tais como antena.

por exemplo. 

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

Esta é compilado, ofuscado, eo arquivo de classe acaba como se você tivesse escrito: 

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

Então você pode ter variantes do código Para contornar erros fabricante em JVM / implementações de biblioteca sem aumentar os arquivos finais classe executável.

Eu acredito que alguns obfuscators comerciais também pode mesclar arquivos de classe em conjunto em certos casos. Isso é útil porque as classes mais você tem, maior o tamanho sobrecarga você tem no arquivo zip (jar).

Eu passei algum tempo este ano experimentar vários obfuscators Java, e eu encontrei um para ser milhas à frente do resto: JBCO . É infelizmente um pouco complicado de configurar, e não tem GUI, mas em termos do nível de ofuscação que produz, é incomparável. Você tenta alimentá-lo um loop simples, e se o seu decompiler não falhar tentando carregá-lo, você vai ver algo como isto: 

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

Você não sabia que Java tinha GOTO? Bem, a JVM apoia-los =)

Eu uso ProGuard e recomendo. Enquanto ofuscação faz proteger seu código de atacantes casuais, é principal benefício é o efeito de minimização de remoção de classes e métodos não utilizados e reduzindo todos os identificadores para 1 ou 2 caracteres.

Eu acho que a maior ofuscação parte é inútil: mesmo com código fonte completo é o suficiente geralmente difícil descobrir qual é a intenção Parreira foi (assumindo que não há observações, e não nomes significativos para as variáveis ??locais - que é a caso quando as fontes de geração de re-de código byte). Obfuscation apenas decora o bolo.

Eu acho que os desenvolvedores e, especialmente, os seus gestores tendem a risco muito over-exaggerate de alguém ver o código fonte. Enquanto boas decompilers pode produzir bom código fonte procurando, não é trivial para trabalhar com ele, e os custos associados (para não mencionar os riscos legais) são altos o suficiente para fazer essa abordagem raramente útil. Eu só tenho compilado para depurar problemas com os produtos dos fornecedores de código fechado (impasses na camada de abstração DB, ugh). Bytecode foi realmente ofuscado, eu acho, mas ainda assim encontrou o problema subjacente -. Que era um problema de projeto real

Eu acho que realmente se resume a o seu código Java é para, como ele é distribuído e quem são seus clientes. Nós fazemos tudo o que não obscurecer do que nunca encontrei um que foi particularmente bom e ele tende a ser mais problemas do que vale a pena. Se alguém tem acesso aos nossos arquivos JAR e tem o conhecimento para ser capaz de farejar dentro deles, então há coisas muito mais preocupantes de que eles podem fazer do roubo nosso código fonte.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top