¿Cómo proteger las clases compiladas de Java?

Question

Lo sé, se han hecho muchas preguntas similares aquí. No estoy preguntando si puedo proteger mi clase compilada de Java, porque obviamente dirá 'no, no puede'. Me pregunto cuál es el método más conocido para proteger las clases de Java contra la descompresión. Si conoce algún trabajo de investigación o académico en este campo, hágamelo saber. Además, si ha usado algunos métodos o software, ¿comparta su experiencia? Cualquier tipo de información será muy útil. Gracias.

Answer 1

En primer lugar, si usted está apuntando "sólo" el mercado de Windows hay una muy fácil de prevenir las ".class a .JAVA" descompilación: utilizar una herramienta como Excelsior Jet que transformará el .jar en un . exe.

Esta es infalible: es imposible para obtener el archivo .java regreso si utiliza Excelsior Jet (siempre y para todo el pueblo diciendo "es imposible impedir la descompilación de un archivo .class "). Sin duda, un atacante podría lanzar SoftIce y tratar de rastrear su .exe, pero que será un poco más complicado que el uso de JAD para descompilar el .class a un .javay ciertamente no permitirá encontrar el archivo .java.

Ahora quizás esté apuntando a OS X y Linux también o no tiene $$$ para despedirse de Excelsior Jet.

Estoy escribiendo un software comercial escrito en Java. Ese software solo tiene sentido si hay una conexión a Internet. Por lo tanto, "protegemos" nuestro software, entre otros, teniendo parte de la computación en el lado del servidor: tenemos varios .class que no funcionarán a menos que se generen desde el lado del servidor y los enviemos por el cable (y lo que se envía por el cable es siempre diferente: estamos generando archivos únicos .class en el lado del servidor).

Esto requiere una conexión a Internet, pero si el usuario no le gusta cómo nuestro software funciona entonces él es libre de comprar un producto inferior de nuestro competidor;)

Descompilación no va a hacer mucho bien: se necesita activamente para romper el software (es decir, reproducir lo que está sucediendo en el lado del servidor) o no podrá usarlo.

Usamos nuestra propia "ofuscación de cadena" antes de usamos Proguard. También hacemos instrumentación de código fuente (podríamos haber hecho también una instrumentación bytecode) donde eliminamos muchas cosas del código (como el "assert" que comentamos) e introducimos una "ofuscación de flujo de código" al azar [el software puede tomar diferentes caminos aún obtienen el mismo resultado, esto es algo que realmente hace que el software sea difícil de rastrear]).

Luego usamos Proguard (que es gratis) para aplanar toda nuestra jerarquía OO y ofuscar el código ya-código-flujo-y-cadena-ofuscado.

Así que nuestro flujo es:

• ofuscación cadena
• ofuscación de código aleatorio flujo
• Proguard
• última .jar que depende de .class que están (diferente) genera dinámicamente en el lado del servidor.

Además de eso lanzamos actualizaciones muy regulares (y automáticas) que siempre aseguran modificar un poco nuestro esquema de protección cliente/servidor (para que con cada lanzamiento un atacante hipotético tenga que comenzar desde cero).

Por supuesto que es más fácil tirar la toalla y pensar: "no hay nada que pueda hacer para que la vida de un atacante más difícil porque JAD puede encontrar de vuelta el archivo .java todos modos" (que es más que muy discutible y abiertamente incorrecto en el caso donde usted usa un convertidor .class to .exe para proteger su clase de decompilación).

Answer 2

Un ofuscador (ver http://java-source.net/open-source/obfuscators) "codificará" el código de modo que no tendrá ningún sentido cuando se descompile.

Answer 3

Existen varios métodos:

• ofuscación
• cifrado de software (flawed)
• cifrado de hardware (nearly unbreakable but the performance hit is huge)
• La compilación nativa

todas describe en detalle en mi artículo Protect Your Java Code - Through Obfuscators And Beyond

Answer 4

Entonces, ¿cómo puedes proteger tus clases para que no sean decompiladas? Una respuesta es Crema. Crema codifica la información simbólica en sus archivos .class para que sean menos vulnerables a la descompilación. La información simbólica que Crema codifica incluye el nombre de la clase, su superclase, interfaces, nombres de variables, métodos, etc. La máquina virtual Java (JVM) necesita estos nombres simbólicos para vincular sus clases con los paquetes de la biblioteca. Crema codifica estos nombres simbólicos y hace referencias a ellos de la misma manera para que la JVM aún pueda lograr la vinculación correcta entre las clases y los paquetes.

Entonces, ¿cómo funciona Crema? Básicamente, antes de distribuir sus archivos de clase en Internet, ejecute Crema en ellos. Crema codificará la información simbólica contenida en ellos, y colocará cada nueva clase en el archivo 1.crema. Su trabajo entonces es renombrar 1.crema a algo como filename.class antes de distribuirlo en Internet.

HOW TO PROJECT JAVA COMPLIED CLASSSES

Answer 5

Puede probar el Java Protector. Es una mejor manera que la ofuscación. Hace un Native ClassLoader al modificar la fuente de OpenJDK, puede encriptar las clases que desea proteger por AES y analizarlas en su JRE personalizado. Puede publicar su software con el JRE y distribuirlo su seguridad de software.