online - ¿Cómo bloquear clases compiladas de Java para evitar la descompilación?
leer.class java (10)
@jatanp: o mejor aún, pueden descompilar, eliminar el código de licencia y volver a compilar. Con Java, realmente no creo que haya una solución apropiada a prueba de intrusiones para este problema. Ni siquiera un pequeño y malvado dongle podría evitar esto con Java.
Mis propios gerentes de negocios se preocupan por esto, y pienso demasiado. Pero, una vez más, vendemos nuestra aplicación a grandes empresas que tienden a cumplir con las condiciones de licencia, generalmente un entorno seguro gracias a los contadores de frijol y abogados. El acto de descompilarse puede ser ilegal si su licencia está escrita correctamente.
Entonces, tengo que preguntar, ¿ realmente necesita una protección reforzada como la que está buscando para su aplicación? ¿Cómo se ve su base de clientes? (¿Empresas o las masas de jugadores adolescentes, donde esto sería más un problema?)
¿Cómo bloqueo las clases compiladas de Java para evitar la descompilación?
Sé que este debe ser un tema muy bien discutido en Internet, pero no pude llegar a ninguna conclusión después de referirme a ellos.
Muchas personas sugieren obscurecer, pero simplemente renombrar clases, métodos y campos con secuencias de caracteres difíciles de recordar, pero ¿qué pasa con los valores constantes sensibles?
Por ejemplo, ha desarrollado el componente de cifrado y descifrado basado en una técnica de encriptación basada en contraseña. Ahora, en este caso, cualquier persona promedio de Java puede usar JAD para descompilar el archivo de clase y recuperar fácilmente el valor de la contraseña (definida como constante) y salt y, a su vez, puede descifrar los datos escribiendo un pequeño programa independiente.
¿O deberían integrarse componentes tan sensibles en código nativo (por ejemplo, VC ++) y llamarlos a través de JNI ?
Algunos de los ofuscadores de códigos de bytes de Java más avanzados hacen mucho más que simplemente cambiar el nombre de clase. Zelix KlassMaster , por ejemplo, también puede codificar el flujo de código de una manera que lo hace realmente difícil de seguir y funciona como un excelente optimizador de código ...
Además, muchos de los ofuscadores también pueden codificar tus constantes de cadena y eliminar el código no utilizado.
Otra posible solución (que no excluye necesariamente la ofuscación) es utilizar archivos JAR encriptados y un cargador de clases personalizado que realice el descifrado (preferiblemente utilizando la biblioteca nativa de tiempo de ejecución).
En tercer lugar (y posiblemente ofreciendo la protección más sólida) es utilizar compiladores nativos de antemano como GCC o Excelsior JET , por ejemplo, que compilan su código de Java directamente a un binario nativo específico de la plataforma.
En cualquier caso, debes recordar eso, como dice el refrán en estonio "Las cerraduras son para animales". Lo que significa que cada bit de código está disponible (cargado en la memoria) durante el tiempo de ejecución y con la suficiente habilidad, determinación y motivación, las personas pueden y van a descompilar, descifrar y piratear tu código ... Tu trabajo es simplemente hacer el proceso tan incómodo como puedes y aún así mantener el funcionamiento ...
Descargo de responsabilidad: no soy un experto en seguridad.
Esto suena como una mala idea: le estás permitiendo a alguien encriptar cosas con una clave "oculta" que le diste. No creo que esto pueda hacerse seguro.
Tal vez las claves 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 encriptación
- envíe una nueva licencia de vuelta al cliente.
No estoy seguro, pero creo que el cliente puede encriptar la clave de licencia con la clave pública que le diste. A continuación, puede descifrarlo con su clave privada y volver a cifrar también.
Podría mantener un par de claves pública / privada por cliente para asegurarse de que realmente está recibiendo las cosas del cliente correcto; ahora usted es responsable de las claves ...
Eche un vistazo al artículo de JavaWorld Cracking cifrado de código byte de Java por Vladimir Roubtsov. Explica por qué el cifrado de los archivos de clase no tiene ningún sentido.
No creo que exista ningún método efectivo antipiratería fuera de línea. La industria de los videojuegos ha intentado encontrar eso muchas veces y sus programas siempre se han resquebrajado. La única solución es que el programa debe ejecutarse en línea conectado con sus servidores, para que pueda verificar la clave de lincense, y que haya una sola conexión activa por parte del licenciatario a la vez. Así es como funciona World of Warcraft o Diablo . Incluso es difícil que haya servidores privados desarrollados para eludir la seguridad.
Habiendo dicho eso, no creo que las medianas / grandes corporaciones usen software copiado ilegalmente, porque el costo de la licencia para ellos es mínimo (quizás, no sé cuánto pueden cargar para su programa) en comparación con el costo de una versión de prueba.
No importa lo que hagas, puede ser ''descompilado''. Diablos, puedes desarmarlo. O mira un volcado de memoria para encontrar tus constantes. Usted ve, la computadora necesita saberlos, por lo que su código también lo necesitará.
¿Qué hacer con esto?
Intente no enviar la clave como una constante codificada en su código: manténgala como una configuración por usuario. Haga que el usuario sea responsable de cuidar esa clave.
P: Si cifro mis archivos .class y uso un cargador de clases personalizado para cargarlos y descifrarlos sobre la marcha, ¿evitará esto la descompilación?
R: El problema de la prevención de la descompilación de código byte Java es casi tan antiguo como el lenguaje. A pesar de la variedad de herramientas de ofuscación disponibles en el mercado, los programadores Java principiantes siguen pensando en formas nuevas e inteligentes de proteger su propiedad intelectual. En esta instalación de Q & A de Java, disipo algunos mitos en torno a una idea que frecuentemente se repite en los foros de discusión.
La extrema facilidad con la que los archivos .class de Java se pueden reconstruir en fuentes Java que se parecen mucho a los originales tiene mucho que ver con los objetivos de diseño de código byte Java y las compensaciones. Entre otras cosas, el código de bytes de Java fue diseñado para compacidad, independencia de plataforma, movilidad de red y facilidad de análisis por intérpretes de código de bytes y compiladores dinámicos JIT (just-in-time) / HotSpot. Podría decirse que los archivos .class compilados expresan la intención del programador, por lo que 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 hacerlo más difícil. Por ejemplo, como un paso posterior a la compilación, podría dar masajes a los datos .class para hacer que el código de bytes sea más difícil de leer cuando se decompila o más difícil de descompilar en código Java válido (o ambos). Las técnicas como la realización de sobrecarga de nombres de métodos extremos funcionan bien para las primeras, y la manipulación del flujo de control para crear estructuras de control que no es posible representar a través de la sintaxis de Java funciona bien para las últimas. Los ofuscadores comerciales más exitosos usan una combinación 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 método y el cambio de nombre de campo pueden provocar que las llamadas de reflexión dejen de funcionar. Cambiar los nombres reales de clase y paquete puede romper varias otras API de Java (JNDI (nombres de Java e interfaz de directorio), proveedores de URL, etc.). Además de los nombres alterados, si se altera la asociación entre los desplazamientos de código de byte de clase y los números de línea de origen, la recuperación de los rastreos de pila de excepción 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. Encriptar, no ofuscar?
Tal vez lo anterior te haya hecho pensar: "Bueno, ¿y si en lugar de manipular el código de bytes encripto todas mis clases después de la compilación y las descifre sobre la marcha dentro de la JVM (que se puede hacer con un cargador de clases personalizado)? Entonces la JVM ejecuta mi código de bytes original y, sin embargo, no hay nada que descompilar o ingeniería inversa, ¿verdad?
Lamentablemente, estarías equivocado al pensar que fuiste el primero en proponer esta idea y en pensar que realmente funciona. Y la razón no tiene nada que ver con la fuerza de su esquema de cifrado.
Puede usar el cifrado de código byte sin miedo.
El hecho es que el documento citado anteriormente "Cracking Java byte-code encryption" contiene una falacia lógica. El principal reclamo del documento es que antes de ejecutar todas las clases debe descifrarse y pasarse al método ClassLoader.defineClass(...) . Pero esto no es cierto.
La suposición omitida aquí se proporciona 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 java protegida a iniciar no solo estas clases, sino incluso descifrarlas y pasarlas a ClassLoader . En otras palabras, si está en JRE estándar, no puede interceptar el defineClass(...) porque el java estándar no tiene API para este propósito, y si usa JRE modificado con ClassLoader parchado o cualquier otro "truco de hacker". no puede hacerlo porque la aplicación java protegida no funcionará en absoluto, y por lo tanto no tendrá nada que interceptar. Y absolutamente no importa qué "buscador de parche" se utiliza o qué truco es utilizado por los piratas informáticos. Estos detalles técnicos son una historia bastante diferente.
Si está buscando una solución de licencia, puede consultar la API de TrueLicense . Se basa en el uso de claves asimétricas. Sin embargo, no significa que su aplicación no se puede descifrar. Cada aplicación se puede descifrar con suficiente esfuerzo. Lo que realmente es importante, según contestó Stu , es descubrir qué tan sólida es la protección que necesitas.
Siempre y cuando tengan acceso a los datos encriptados y al software que los descifra, básicamente no hay forma de que pueda hacer esto completamente seguro. Las formas en que esto se ha solucionado antes es utilizar 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ícil, no imposible, a menos que pueda vincular su producto directamente a la funcionalidad almacenada en la "caja negra", como, por ejemplo, los servidores de juegos en línea.