Migración de Protector4J v5 a v6

⚠️ Por la seguridad de su código, actualice a v6 lo antes posible

La ingeniería inversa asistida por IA está reduciendo rápidamente la barrera para el análisis de código. La fuerza de protección de v5 ya no basta ante el panorama actual de amenazas, y mantenerla expone su código a un mayor riesgo de divulgación. Le recomendamos encarecidamente migrar sus aplicaciones protegidas a Protector4J v6 cuanto antes.

1. Por qué actualizar a v6

Las herramientas de IA facilitan cada vez más el análisis de código y la ingeniería inversa. La ofuscación tradicional de bytecode y el cifrado simple ya no son suficientes ante los nuevos desafíos de seguridad.

Para ofrecer una protección más sólida del código Java, rediseñamos por completo Protector4J v6. Su nueva arquitectura P4JX incorpora más de cien medidas de seguridad en el cifrado del código, la carga de clases, la validación en tiempo de ejecución, la protección contra depuración y otras capas. Incluso con herramientas avanzadas de análisis mediante IA, realizar ingeniería inversa sobre el código protegido sigue siendo extremadamente difícil.

Por ello, v6 presenta diferencias importantes respecto a v5 en la arquitectura de protección, la configuración, la sintaxis de la línea de comandos y el formato de salida.

2. Principales diferencias entre v5 y v6

El cambio más importante es que los archivos cifrados, los entornos de ejecución y los archivos de tarea YAML de v5 no se pueden reutilizar directamente en v6.

3. Configuración sencilla con el modo de compatibilidad

Una protección más sólida requiere más opciones para el alcance de protección, el entorno de ejecución, la disposición, la compatibilidad y las plataformas de destino. Para que no sea necesario comprender todas las opciones antes de empezar, v6 ofrece un modo de compatibilidad.

En la interfaz gráfica, utilice el modo Simple (recomendado):

1. Seleccione el tipo de aplicación.
2. Seleccione el JAR o WAR original.
3. Seleccione la versión de Java y las plataformas de destino.
4. Permita que Protector4J analice la aplicación y elija automáticamente ajustes de compatibilidad conservadores.
5. Confirme el directorio de salida e inicie la protección.

Cambie al modo Advanced solo cuando necesite controlar con precisión el alcance de protección, la disposición de Spring Boot, las opciones de JVM, JavaFX u otros ajustes.

En la línea de comandos, utilice --compat-apply. Esta opción analiza la aplicación, aplica recomendaciones de compatibilidad conservadoras y genera el paquete protegido:

p4j javaapp app.jar dist --compat-apply

El modo de compatibilidad simplifica la configuración, pero no sustituye las pruebas reales. Después de generar el paquete, verifique el inicio, las funciones principales, la reflexión, la serialización, el acceso a la base de datos y el comportamiento de los frameworks de terceros.

4. La sintaxis de la línea de comandos ha cambiado por completo

La CLI de v5 depende de un archivo de tarea YAML:

p4j -t java -f java-task.yml

v6 puede ejecutarse sin archivo de configuración y recibir todos los ajustes como argumentos de línea de comandos:

# Aplicación Java estándar
p4j javaapp app.jar dist --compat-apply

# Aplicación Spring Boot
p4j springboot app.jar dist --compat-apply

# WAR de Tomcat
p4j tomcat app.war dist --compat-apply --context /app

# Biblioteca Java
p4j encode library.jar library.p4jx

Correspondencia de tipos de aplicación:

Tenga en cuenta que encode en v6 protege todas las clases de la biblioteca y requiere un VLX JRE para cargarlas. No es un sustituto equivalente del flujo de v5 que convertía métodos seleccionados en código nativo y permitía seguir utilizando un JRE estándar.

v6 sigue admitiendo archivos de tarea, pero debe exportar un nuevo p4j-task.yml desde la interfaz gráfica de v6:

p4j --task-file p4j-task.yml

No intente modificar y reutilizar un archivo YAML de v5. Los formatos de tarea de v5 y v6 son incompatibles. Vuelva a configurar la tarea en la interfaz gráfica o reescriba el comando conforme a la documentación más reciente de la CLI.

Para consultar todos los comandos y opciones, vea la Referencia de CLI de v6.

5. Migrar de v5 a v6

Siga esta única ruta de migración:

Conservar una copia de v5 → localizar el JAR/WAR original → regenerar con el modo de compatibilidad de v6 → probar → cambiar

Paso 1: conservar el entorno de v5

Conserve el directorio de salida de v5 que funciona y su procedimiento de inicio para poder volver atrás si fuera necesario. No sobrescriba el directorio de v5.

Paso 2: preparar la entrada original

Localice el JAR, el JAR de Spring Boot o el WAR original que no haya sido cifrado por v5. El directorio vlxlib, los JAR cifrados y el vlxjre generados por v5 no se pueden utilizar como entrada de v6.

Paso 3: regenerar con v6

Para el uso interactivo, empiece con el modo Simple de la interfaz gráfica. Para la automatización, utilice directamente argumentos de línea de comandos junto con --compat-apply. Escriba la salida en un directorio nuevo y no la mezcle con archivos de v5.

Paso 4: validar la salida de v6

Inicie la aplicación con el archivo generado run.sh, run.command o run.bat. Publique el vlxjre generado junto con la aplicación. No lo sustituya por el JRE del sistema ni por el entorno de ejecución de otra tarea.

Verifique como mínimo que:

• la aplicación se inicia y se detiene normalmente;
• las funciones principales del negocio funcionan correctamente;
• la reflexión, la serialización, el ORM, los proxies de Spring y la carga de recursos funcionan correctamente;
• el paquete se ha ejecutado en cada sistema operativo de destino.

Paso 5: cambiar el paquete completo

Después de la validación, cambie al directorio de salida completo de v6. Para las actualizaciones posteriores, vuelva a generar un paquete completo desde el JAR o WAR original en lugar de utilizar la actualización parcial de v5 KeySeed + onlyEncryptJarFiles.

6. Recomendación de actualización

La ingeniería inversa asistida por IA está reduciendo rápidamente las barreras para analizar código. Seguir utilizando v5 aumenta el riesgo de exposición del código. Por razones de seguridad, recomendamos actualizar de v5 a v6 lo antes posible.

Realice una migración en paralelo: conserve v5 para poder volver atrás, genere un paquete nuevo con el modo de compatibilidad de v6, valídelo y solo entonces cambie el entorno de producción.

Documentación relacionada:

• Inicio rápido de v6
• Referencia de CLI de v6
• Compatibilidad y alcance de protección de v6
• Archivo de documentación de v5