Cómo proteger el código JavaDesde una perspectiva técnica, echemos un vistazo a cómo proteger eficazmente el código Java de medidas y herramientas de protección comunes: 1. Características de empaquetar java en exe: empaquetar jar en archivos ejecutables es fácil de usar, pero no protege los programas java. No crea que generar un archivo ejecutable tendrá el mismo efecto que un archivo ejecutable normal. Cuando se ejecutan estos programas empaquetados en exe, los archivos jar se liberarán en un directorio temporal, que es fácil de obtener. Las herramientas más utilizadas incluyen exe4j, jsmooth, NativeJ, etc. El directorio temporal de tiempo de ejecución de Exe generado por jsmooth está en el directorio donde se encuentra el exe o el directorio temporal del usuario; el directorio temporal de tiempo de ejecución de exe generado por Exe4j está en el directorio temporal del usuario generado por NativeJ y se abre directamente con winrar; luego se restaura a un archivo jar en formato zip. Obtenga el archivo original. Si es solo por conveniencia de uso y distribución, y no es necesario proteger el código Java, usar estas herramientas es una buena opción. 2. Características del ofuscador de Java: ofusca los archivos de clase y el código fuente de Java mediante uno o más métodos de procesamiento para generar una nueva clase, lo que hace que el código ofuscado sea difícil de descompilar y el código descompilado difícil de leer y comprender. Este ofuscador tiene muchas herramientas y es muy eficaz. Desventajas: aunque el código desordenado no es fácil de leer después de la descompilación, personas experimentadas que dedican más tiempo aún pueden descubrir o calcular el contenido confidencial oculto en su código. Y en muchas aplicaciones, no todo el código se puede ofuscar, a menudo algunas bibliotecas clave, nombres de clases, nombres de métodos, nombres de variables, etc. No debe confundirse con las restricciones sobre los requisitos de uso. 3. Características de aislar el programa Java del servidor: si el programa Java se coloca en el servidor, los usuarios no pueden acceder a los archivos de clase y los archivos de soporte relacionados, y el cliente solo puede acceder a través de la interfaz. Este enfoque puede proteger mejor el código Java en aplicaciones de modelo cliente/servicio. La desventaja es que debe ser un modelo cliente/servicio, lo que limita el alcance de aplicación de este modelo porque la exposición de la lógica siempre es un eslabón débil, los clientes generalmente requieren autenticación de seguridad al acceder a la interfaz; 4. Características de la protección de cifrado de Java: el cargador de clases personalizado cifra archivos de clases y archivos relacionados, descifra archivos relacionados y carga clases en tiempo de ejecución. Para ser protector, un ejecutor de código nativo personalizado también debe proteger el cargador de clases personalizado, las clases relacionadas con el cifrado y descifrado y los archivos de soporte. Este método puede proteger eficazmente el código Java. Desventajas: el código de bytes de Java se puede interceptar reemplazando las clases de Java o las bibliotecas dinámicas de máquinas virtuales relacionadas con la carga de clases en el paquete JRE. Jar2exe pertenece a este tipo de herramienta. 5. Características de AOT: el código Java se compila estáticamente en código nativo y se separa del JRE general. Este método puede proteger el código Java de manera muy efectiva y el programa se inicia un poco más rápido que la JVM general. El más representativo es gcj de GNU, que puede compilar completamente el código Java por adelantado. Sin embargo, gcj tiene muchas limitaciones, como no es totalmente compatible con JRE 5 y no es compatible con JRE 6 y versiones posteriores. Debido a la complejidad de la plataforma Java, es muy difícil precompilar completamente el soporte para las últimas versiones de Java y JRE. Por lo tanto, estas herramientas suelen adoptar un enfoque flexible y se utilizan siempre que se requiere compilación en tiempo real, convirtiéndose en una mezcla de precompilación y compilación en tiempo real. Desventajas: debido a las diferencias con el JRE general y la complejidad de las aplicaciones Java, no todos los archivos jar del programa Java pueden protegerse por completo; solo puede utilizar un entorno de ejecución proporcionado por esta herramienta; Si una herramienta tiene retrasos en las actualizaciones o si necesita una versión específica de JRE, es posible que la herramienta no la admita. El Excelsior Jet es una de esas herramientas. 6. Utilice las funciones de protección de jni: maneje métodos y datos confidenciales a través de jni. Este método es algo similar a "aislar programas Java en el servidor". Puede verse como "aislar" el código y los datos que deben protegerse en una biblioteca dinámica, pero la diferencia es que se puede utilizar en programas independientes. La desventaja es similar a "aislar el programa Java al servidor" mencionado anteriormente. 7. Funciones de protección integral sin salir de JRE: sin compilación previa, sin salir de JRE, utilizando una variedad de métodos de protección suave para evitar el robo de programas Java. De esta forma, debido a diversas medidas de protección, como ejecutores y cargadores personalizados, cifrado, JNI, detección de seguridad, generación de archivos ejecutables, etc. , la protección mejora enormemente y el código Java también se puede proteger de forma muy eficaz.
Desventajas: debido a los cambios en la forma en que existen los archivos jar y la complejidad de las aplicaciones java, no todos los archivos jar en los programas java pueden protegerse completamente y es posible que no todas las versiones de JRE sean compatibles. JXMaker pertenece a este tipo de herramienta. 8. Características de la protección de hardware con bloqueo de cifrado: utilice un programa dedicado relacionado con el hardware para encapsular el programa de inicio de la máquina virtual Java, cifrar los archivos de soporte de la máquina virtual y el programa Java, iniciar el programa de shell y establecer una A relacionada con el hardware. Entorno operativo protegido que puede interactuar con programas integrados en el dongle para mejorar la seguridad. Este método es similar a la "protección integral sin salir de JRE" anterior, pero mediante el uso de dispositivos de hardware especiales, el código Java también puede estar bien protegido. Desventajas: algunas personas piensan que los bloqueos de cifrado son inconvenientes para los usuarios y requieren uno para cada instalación. De la descripción anterior podemos ver: 1. Cada método de protección tiene sus propias ventajas y desventajas y debe seleccionarse según la situación real. 2. Para proteger mejor el código Java, debemos utilizar medidas de protección integrales. 3. Para proteger verdadera y eficazmente el código Java en un entorno independiente, los programas de código local deben cooperar. Por supuesto, la seguridad es relativa. Por un lado, depende del alcance de sus medidas y herramientas de protección; por otro lado, depende de la voluntad y la capacidad del hacker. Los derechos de propiedad intelectual no se pueden proteger sólo técnicamente. En resumen, podemos tomar todas las formas posibles para proteger el código Java y no debemos ceñirnos a esas reglas.