Cómo bloquear Java compilado clases para evitar descompilación?

Question

¿Cómo bloqueo de Java compilado clases para evitar descompilación?

Sé que esto debe ser muy bien discutido tema en Internet, pero no pude llegar a ninguna conclusión después de referirse a ellos.

Muchas personas sugieren obfuscator, pero que acaba de hacer el cambio de nombre de las clases, métodos y campos difíciles de recordar secuencias de caracteres pero, ¿qué acerca sensible a valores constantes?

Por ejemplo, se han desarrollado el cifrado y descifrado de la componente basado en una contraseña de cifrado basado en la técnica.Ahora en este caso, cualquier persona puede utilizar Java JAD a descompilar el archivo de clase y recuperar con facilidad el valor de la contraseña (que se define como constante) así como sal y a su vez puede descifrar los datos por escrito independiente pequeño programa!

O si dichos componentes sensibles a ser construido en código nativo (por ejemplo, VC++) y llamar a ellos a través de JNI?

Answer 1

Algunas de las más avanzadas de Java bytecode obfuscators hacer mucho más que sólo el nombre de la clase destrozarlo. Zelix KlassMaster, por ejemplo, también puede enviar su flujo de código de una manera que hace que sea realmente difícil de seguir y funciona como un excelente optimizador de código...

También muchos de los obfuscators también son capaces de codificar la cadena de constantes y quitar sin usar código.

Otra posible solución (no necesariamente la exclusión de la ofuscación) es el uso de cifrado de archivos JAR y un cargador de clases que hace que el descifrado (utilizando preferentemente nativo de biblioteca de tiempo de ejecución).

Tercera (y, posiblemente, ofrecer la protección más fuerte) es el uso de los nativos antes de tiempo compiladores como GCC o Excelsior JET, por ejemplo, que compilar el código Java directamente a una plataforma específica binario nativo.

En cualquier caso hay Que recordar que como dice el refrán en estonio "los Bloqueos son para los animales".Lo que significa que cada bit de código está disponible (cargado en memoria) durante el tiempo de ejecución y le da la suficiente habilidad, determinación y motivación, la gente puede y va a descompilar, descifrar y hackear el código...Su trabajo es simplemente para hacer el proceso tan incómodo como usted puede y aún así mantener la cosa funciona...

Answer 2

Como siempre que tengan acceso tanto para el cifrado de datos y el software que se descifra, básicamente hay ninguna manera de hacer que este completamente segura.Maneras en que esto se ha resuelto antes de que se use algún tipo de externo de la caja negra para manejar el cifrado/descifrado, como mochilas, autenticación remota de servidores, etc.Pero incluso entonces, dado que el usuario tiene acceso completo a su propio sistema, esto sólo hace que las cosas difíciles, por no decir imposible -a menos que usted puede atar su producto directamente a la funcionalidad almacenados en la "caja negra", como, por ejemplo, los juegos en línea de los servidores.

Answer 3

Descargo de responsabilidad:Yo no soy un experto en seguridad.

Esto suena como una mala idea:Usted está dejando a alguien cifrar cosas con un 'oculto' clave que le das.No creo que este puede ser asegurada.

Tal vez asimétrica claves podría funcionar:

• implementar el cifrado de licencia con una clave pública para descifrar
• deje que el cliente cree una nueva licencia y se la enviaremos para el cifrado
• el envío de una nueva licencia de vuelta al cliente.

No estoy seguro, pero creo que el cliente realmente se puede cifrar la clave de licencia con la clave pública que le dio.Luego puede descifrar con su clave privada y volver a cifrar así.

Usted puede mantener una separada de clave pública/privada par por el cliente para asegurarse de que usted realmente está consiguiendo cosas desde el derecho de los clientes - ahora usted son responsables de las claves...

Answer 4

No importa lo que hagas, puede ser 'descompilados'.Heck, usted puede desmonte.O mirar un volcado de memoria para encontrar tu constantes.Se puede ver, el equipo necesita saber de ellos, por lo que su código se necesita demasiado.

Qué hacer acerca de esto?

Trate de no enviar la clave como un codificados constante en tu código:Mantenerlo como una configuración por usuario.Hacer que el usuario responsable de cuidar de esa clave.

Answer 5

@jatanp:o mejor aún, se puede descompilar, retire la concesión de licencias de código, y volver a compilar.Con Java, la verdad creo que no hay una adecuada hack-a prueba de solución a este problema.Ni siquiera un mal pequeño dongle podría evitar esto con Java.

Mi propia biz los gerentes se preocupan por esto, y creo que demasiado.Pero, de nuevo, vendemos nuestra aplicación a las grandes empresas, que tienden a regirse por las condiciones de la licencia; en general, un ambiente seguro gracias a la haba contadores y abogados.El acto de la descompilación de sí mismo puede ser ilegal si su licencia está escrito correctamente.

Así que, tengo que preguntar, ¿ realmente necesidad endurecido protección, como los que usted está buscando para su aplicación?¿Qué hace su base de clientes parece?(Empresas?O el adolescente jugador de masas, donde esto puede ser más de un problema?)

Answer 6

Si usted está buscando una solución de licencia, usted puede comprobar fuera de la TrueLicense API.Se basa en el uso de claves asimétricas.Sin embargo, esto no significa que su aplicación no puede ser roto.Cada aplicación puede ser descifrada con suficiente esfuerzo.Lo realmente importante es, como Respondió Stu, averiguar cómo la fuerte protección que usted necesita.

Answer 7

No creo que exista algún eficaz sin conexión antipiratería método.La industria de los videojuegos ha tratado de encontrar que muchas veces y de sus programas siempre ha sido crackeado.La única solución es que se debe ejecutar el programa en línea conectado con sus servidores, para que usted pueda verificar el lincense clave, y que no es sólo un activo de la connecion por el licenciatario en un momento.Esta es la forma en Mundo de Warcraft o Diablo obras.Aunque hay servidores privados desarrollado para ellos para eludir el sistema de seguridad.

Habiendo dicho eso, no creo que a mediados de la/las grandes corporaciones uso ilegal copiar el software, debido a que el costo de la licencia para ellos es mínima (tal vez, no sé cuánto se goig a cargo de su programa) en comparación con el costo de una versión de prueba.

Answer 8

Usted puede utilizar el byte de código de cifrado sin miedo.

El hecho es que el citado anteriormente de papel "Cracking Java byte de código de cifrado" contiene una falacia lógica.La principal reivindicación del papel es antes de ejecutar todas las clases deben ser descifrados y se pasa a la ClassLoader.defineClass(...) método.Pero esto no es cierto.

La suposición de perder aquí es a condición de que se están ejecutando en la auténtica, o estándar, java entorno de tiempo de ejecución.Nada puede obligar a los protegidos de java app no sólo para el lanzamiento de estas clases, pero incluso descifrar y pasar a ClassLoader.En otras palabras, si usted está en el estándar de JRE no se puede interceptar defineClass(...) método debido a que el estándar de java no tiene API para este propósito, y si utiliza modificado JRE con patched ClassLoader o cualquier otro "hacker truco" que no se puede hacer porque protegido java app no funciona en absoluto, y por lo tanto usted no tendrá nada que interceptar.Y absolutamente no importa que el "parche" buscador que se utiliza o que truco es utilizado por los hackers.Estos detalles técnicos son muy diferentes de la historia.

Answer 9

Q:Si me cifrar mi .clase de archivos y el uso de un cargador de clases personalizadas para cargar y descifrar ellos sobre la marcha, que impedir a descompilación?

Una:El problema de la prevención de Java byte-code descompilación es casi tan antiguo el lenguaje en sí mismo.A pesar de una serie de ofuscación herramientas disponibles en el mercado, como novato que los programadores de Java siguen pensando de nuevo y de maneras inteligentes para proteger su propiedad intelectual.En el este de Java Q&a de la entrega, me disipar algunos mitos en torno a una idea con frecuencia campean en los foros de discusión.

La extrema facilidad con la que Java .los archivos de clase puede ser reconstruida en Java fuentes que se parecen a los originales, tiene mucho que ver con Java byte-code objetivos de diseño y trade-offs.Entre otras cosas, de código de bytes de Java fue diseñado para la compactación, la independencia de la plataforma de red, la movilidad y la facilidad de análisis por parte de byte-code intérpretes y JIT (just-in-time)/HotSpot dinámica de los compiladores.Sin duda, el compilado .los archivos de clase de expresar la intención del programador tan claramente que podría ser más fácil de analizar que el código fuente original.

Varias cosas se pueden hacer, si no para prevenir la descompilación completamente, al menos, para hacer más difícil la situación.Por ejemplo, como un post-compilación paso que usted puede masajear el .datos de la clase para hacer el byte de código sea más difícil de leer cuando descompilar o más difícil para descompilar válido en Java de código (o ambos).Técnicas como la realización de extrema nombre de método de la sobrecarga de trabajo bien para los primeros, y la manipulación de flujo de control para crear estructuras de control no es posible representar a través de la sintaxis de Java funcionan bien para este último.Los de mayor éxito comercial obfuscators utilizar una combinación de estas y otras técnicas.

Por desgracia, los dos enfoques de la realidad debe cambiar el código de la JVM se ejecute, y muchos usuarios están miedo (con razón) de que esta transformación puede agregar nuevos errores a sus aplicaciones.Además, el método y el cambio de nombre de campo puede provocar la reflexión llamadas a dejar de trabajar.Cambio reales de la clase y los nombres de los paquetes puede romper varias otras APIs de Java (JNDI (Java Naming and Directory Interface), la URL de los proveedores, etc.).Además de la alteración de los nombres, si la asociación entre la clase byte-code compensaciones y origen de los números de línea se altera, la recuperación de la excepción original seguimientos de pila podría llegar a ser difícil.

Luego está la opción de camuflar la original de código fuente de Java.Pero fundamentalmente esto hace que un conjunto similar de problemas.Cifrar, no ofuscar?

Tal vez el de arriba te ha hecho pensar, "Bien, ¿y si en vez de la manipulación de código de bytes de I cifrar todas mis clases después de la compilación y descifrar ellos sobre la marcha dentro de la JVM (que se puede hacer con un cargador de clases personalizadas)?A continuación, la JVM ejecuta mi original de código de bytes y, sin embargo, no hay nada descompilar o realizar ingeniería inversa, haga?"

Desafortunadamente, usted estaría mal, tanto en el pensamiento de que usted fue el primero en llegar con esta idea y en el pensamiento de que realmente funciona.Y la razón no tiene nada que ver con la fuerza de su esquema de cifrado.