¿Cómo bloquear las clases Java compiladas para evitar la descompilación?

Mientras tengan acceso tanto a los datos cifrados como al software que los descifra, básicamente no hay manera de que pueda hacerlo completamente seguro. Las formas en que esto se ha resuelto antes es usar alguna forma de caja negra externa para manejar el cifrado/descifrado, como dongles, servidores de autenticación remota, etc. Pero incluso entonces, dado que el usuario tiene acceso completo a su propio sistema, esto solo hace las cosas difíciles, no imposibles ,a menos que pueda vincular su producto directamente a la funcionalidad almacenada en la" caja negra", como, por ejemplo, servidores de juegos en línea.

Descargo de responsabilidad: No soy un experto en seguridad.

Esto suena como una mala idea: Estás dejando que alguien encripte cosas con una clave 'oculta' que le das. No creo que esto pueda ser seguro.

Tal vez las teclas asimétricas podrían funcionar:

• implementar una licencia cifrada con una clave pública para descifrar
• deje que el cliente cree una nueva licencia y se la envíe para su cifrado
• envíe una nueva licencia al cliente.

No estoy seguro, pero cree que el cliente realmente puede cifrar la clave de licencia con la clave pública que le dio. A continuación, puede descifrarlo con su clave privada y volver a cifrar también.

Puede mantener un par de claves público/privado por cliente para asegurarse de que realmente está recibiendo cosas del cliente correcto - ahora usted es responsable de las claves...

No importa lo que hagas, puede ser 'descompilados'. Diablos, puedes desmontarlo. O mira un volcado de memoria para encontrar tus constantes. Verás, la computadora necesita conocerlos, así que tu código también lo necesitará.

¿Qué hacer al respecto?

Trate de no enviar la clave como una constante hardcoded en su código: Guárdela como una configuración por usuario. Responsabiliza al usuario de cuidar esa llave.

Echa un vistazo al artículo JavaWorld Descifrar el cifrado de código de bytes Java por Vladimir Roubtsov. Explica por qué el cifrado de archivos de clase es en su mayoría inútil.

@jatanp: o mejor aún, pueden descompilar, eliminar el código de licencia y recompilar. Con Java, realmente no creo que haya una solución adecuada, a prueba de hackers para este problema. Ni siquiera un pequeño dongle malvado podría evitar esto con Java.

Mis propios gerentes de negocios se preocupan por esto, y pienso demasiado. Pero, de nuevo, vendemos nuestra aplicación a grandes corporaciones que tienden a cumplir con las condiciones de licencia, generalmente un entorno seguro gracias a los contadores de frijoles y abogados. El el acto de descompilarse en sí mismo puede ser ilegal si su licencia está escrita correctamente.

Por lo tanto, tengo que preguntar, ¿realmente necesitas una protección reforzada como la que estás buscando para tu solicitud? ¿Cómo es tu base de clientes? (Empresas? O las masas de jugadores adolescentes, donde esto sería más de un problema?)

No creo que exista ningún método efectivo de antipiratería fuera de línea. La industria de los videojuegos ha tratado de encontrar que muchas veces y sus programas siempre se ha agrietado. La única solución es que el programa debe ejecutarse en línea conectado con sus servidores, para que pueda verificar la clave lincense, y que solo hay una conexión activa por parte del licenciatario a la vez. Así es como World of Warcraft o Diablo funciona. Incluso difíciles hay servidores privados desarrollados para ellos para evitar la seguridad.

Dicho esto, no creo que las corporaciones medianas y grandes usen software copiado ilegalmente, porque el costo de la licencia para ellas es mínimo (tal vez, no se cuánto debe cobrar por su programa) en comparación con el costo de una versión de prueba.

Si está buscando una solución de licencia, puede consultar la API TrueLicense. Se basa en el uso de teclas asimétricas. Sin embargo, esto no significa que su aplicación no pueda ser descifrada. Cada aplicación se puede agrietar con suficiente esfuerzo. Lo realmente importante es, como Stu respondió, averiguar qué tan fuerte protección necesita.

Puede usar el cifrado de código de bytes sin miedo.

El hecho es que el documento citado anteriormente "Cracking Java byte-code encryption" contiene una falacia lógica. La principal afirmación del documento es antes de ejecutar todas las clases deben ser descifradas y pasadas al método ClassLoader.defineClass(...) . Pero esto no es cierto.

La suposición omitida aquí es siempre que se ejecuten en un entorno de tiempo de ejecución java auténtico o estándar. Nada puede obligar a la aplicación protegida java no solo a inicie estas clases pero incluso descifre y páselas a ClassLoader. En otras palabras, si estás en JRE estándar no puedes interceptar el método defineClass(...) porque el java estándar no tiene API para este propósito, y si usas JRE modificado con parcheado ClassLoader o cualquier otro "truco de hacker" no puedes hacerlo porque la aplicación java protegida no funcionará en absoluto, y por lo tanto no tendrás nada que interceptar. Y absolutamente no importa qué "buscador de parches" se utiliza o qué truco es utilizado por los hackers. Estas técnicas los detalles son una historia muy diferente.

P: Si encripto mi .archivos de clase y utilizar un classloader personalizado para cargarlos y descifrarlos sobre la marcha, esto evitará la descompilación?

R: El problema de evitar la descompilación de código de bytes Java es casi tan antiguo como el lenguaje en sí. A pesar de una gama de herramientas de ofuscación disponibles en el mercado, los programadores de Java novatos continúan pensando en formas nuevas e inteligentes de proteger su propiedad intelectual. En esta entrega de Java Q & A, disipo algunos mitos en torno a una idea que se repite con frecuencia en foros de discusión.

La extrema facilidad con la que Java .los archivos de clase se pueden reconstruir en fuentes Java que se asemejan mucho a los originales tiene mucho que ver con los objetivos de diseño de código de bytes de Java y las compensaciones. Entre otras cosas, el código de bytes de Java fue diseñado para la compacidad, la independencia de la plataforma, la movilidad de la red y la facilidad de análisis por intérpretes de código de bytes y compiladores dinámicos JIT (just-in-time)/HotSpot. Podría decirse, el compilado .los archivos de clase expresan la intención del programador claramente podrían ser más fáciles de analizar que el código fuente original.

Se pueden hacer varias cosas, si no para evitar la descompilación por completo, al menos para hacerla más difícil. Por ejemplo, como un paso posterior a la compilación que podría masajear el .datos de clase para hacer que el código de bytes sea más difícil de leer cuando se descompila o más difícil de descompilar en código Java válido (o ambos). Las técnicas como realizar la sobrecarga extrema del nombre del método funcionan bien para el primero, y manipular el flujo de control para crear estructuras de control que no es posible representar a través de la sintaxis Java funciona bien para este último. Los ofuscadores comerciales más exitosos usan una mezcla de estas y otras técnicas.

Desafortunadamente, ambos enfoques realmente deben cambiar el código que ejecutará la JVM, y muchos usuarios temen (con razón) que esta transformación pueda agregar nuevos errores a sus aplicaciones. Además, el cambio de nombre de métodos y campos puede hacer que las llamadas a reflexión dejen de funcionar. Cambiar la clase y el paquete reales los nombres pueden romper varias otras API de Java (JNDI (Java Naming and Directory Interface), proveedores de URL, etc.). Además de los nombres alterados, si se altera la asociación entre las compensaciones de código de bytes de clase y los números de línea de origen, la recuperación de las trazas de la pila de excepciones originales podría ser difícil.

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

Tal vez lo anterior ha hecho piensas: "Bueno, ¿qué pasa si en lugar de manipular el código de bytes encripto todas mis clases después de la compilación y las descifra sobre la marcha dentro de la JVM (lo que se puede hacer con un cargador de clases personalizado)? Entonces la JVM ejecuta mi código de byte original y sin embargo no hay nada que descompilar o realizar ingeniería inversa, ¿verdad?"

Desafortunadamente, estarías equivocado, tanto al pensar que fuiste el primero en llegar a esta idea como al pensar que realmente funciona. Y la razón no tiene nada que ver con la fuerza de su esquema de cifrado.