¿Cómo bloquear las clases Java compiladas para evitar la descompilación?
¿Cómo bloqueo las clases Java compiladas para evitar la descompilación?
Sé que este debe ser un tema muy discutido en Internet, pero no pude llegar a ninguna conclusión después de referirlos.
Mucha gente sugiere ofuscador, pero simplemente cambian el nombre de 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 cifrado 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 (definido como constante), así como salt y, a su vez, puede descifrar los datos escribiendo un pequeño programa independiente.
¿O deberían crearse 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 alterar los nombres de las clases. 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 las 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 cifrados y un cargador de clases personalizado que realice el descifrado (preferiblemente utilizando una biblioteca de tiempo de ejecución nativa).
En tercer lugar (y posiblemente ofreciendo la protección más sólida) es utilizar compiladores nativos anticipados como GCC o Excelsior JET , por ejemplo, que compilan su código Java directamente en un binario nativo específico de la plataforma.
En cualquier caso hay que recordar que como dice el dicho en estonio "Los candados son para los animales". Lo que significa que cada fragmento de código está disponible (cargado en la memoria) durante el tiempo de ejecución y, con suficiente habilidad, determinación y motivación, las personas pueden descompilar, descifrar y piratear su código... Su trabajo es simplemente hacer que el proceso sea lo más incómodo posible. puedes y aún así mantener la cosa funcionando...
Mientras tengan acceso tanto a los datos cifrados como al software que los descifra, básicamente no hay manera de que esto sea completamente seguro. Las formas en que esto se ha resuelto antes es utilizar algún tipo 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 sólo hace que 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.
