Una vez se me ocurrió un algoritmo matemático iterativo muy largo, ineficiente (a propósito) que implementé en el código Java, para generar una secuencia de bytes pseudoaleatoria. Escribí el código de la manera más extraña, indirecta, confusa y ofuscada que pude (asegurándome de no romperlo), luego finalmente ejecuté el código a través de uno de los mejores ofuscadores de código Java disponibles en ese momento. Básicamente, quería que fuera lo más difícil posible para alguien hacer ingeniería inversa del método por el cual se generó la secuencia de bytes pseudoaleatoria.
Esta fue solo una pieza de un rompecabezas más grande. Tenía otra secuencia de bytes de “aspecto aleatorio” (pero en realidad no aleatoria) que tenía la misma longitud que la secuencia de bytes descrita anteriormente. Cuando estas dos secuencias de bytes se unieron XOR a bit, crearon el contenido de un archivo JAR cifrado y firmado digitalmente, que luego se pudo cargar en un cargador de clases Java personalizado (que lee los bytes del archivo JAR de una secuencia de entrada de descifrado personalizada )
El objetivo de todo esto era proteger un subconjunto de funcionalidades de la aplicación Java con un contenedor de licencias, de modo que el usuario final tuviera que pagar una licencia para usar uno de los módulos cargables de la aplicación principal. La ofuscación y el cifrado se pusieron allí como barreras técnicas para desalentar la omisión del código de aplicación de la licencia.
- ¿Cuál es la solución eficiente para SPOJ CCROSSX?
- ¿Es posible usar los poderes de una matriz de adyacencia para calcular las rutas más cortas que BFS calcularía?
- Si uso un algoritmo de cifrado no tan bueno que inventé dentro de uno real, ¿cuánto más seguros están juntos?
- ¿Cuál es la diferencia entre consultas DNS iterativas y recursivas?
- Cómo hacer que el código de una ordenación de inserción sea más optimizado utilizando una lista vinculada
Me di cuenta, por supuesto, que realmente no hay una forma 100% segura de proteger dicha funcionalidad de ser utilizada de forma gratuita y copiada a otros usuarios finales para que ellos también la utilicen de forma gratuita. No importa cuán ofuscado sea el código y no importa cuán fuerte sea el cifrado (y la validación de las firmas digitales), en última instancia, las clases tendrían que cargarse en la memoria a través del cargador de clases especiales. Una vez que eso hubiera sucedido, sería sencillo que alguien volcara el núcleo de todo el proceso de Java de la memoria al disco, luego los jugosos códigos de bytes de Java de las clases sin cifrar y sin protección podrían extraerse de los archivos . Básicamente, el esquema de licencia no era mejor que la cerradura de la puerta de un baño residencial (que se puede abrir desde el exterior con un picahielos o un destornillador pequeño). Impidió que los usuarios finales honestos eludieran el esquema de licencia, pero no pudo evitar que determinados piratas informáticos finalmente accedan al código funcional sin cifrar y sin protección para usar como quisieran, sin restricciones.
Cualquier software que se ejecute en la computadora del usuario final puede ser pirateado para eludir las restricciones de licencia y habilitar las “funciones pagas” sin tener que pagar, independientemente del idioma en que esté escrito el software. Los ofuscadores y compiladores pueden dificultar la ingeniería inversa del código, pero no imposible. La única forma de garantizar que ciertas funciones de una aplicación de software sean accesibles solo para los usuarios finales con licencia pagada es ejecutar el software en un servidor y ofrecerlo en forma de SaaS (software como servicio).
