¿Es la mejor manera de proteger mi código fuente de Java el ocultar mi aplicación de escritorio Java dentro de una VM?

Question

¿Es la mejor manera de proteger mi código fuente de Java el ocultar mi aplicación de escritorio Java dentro de una VM?

#1 de Mike Ounsworth (3 votos)

0

Necesito distribuir una aplicación de escritorio Java para el usuario. Estoy buscando diferentes maneras de proteger mi código fuente de la ingeniería inversa.

Un método es distribuir una Máquina Virtual (dice Linux) que contiene la aplicación que se ejecuta dentro de esa VM, y hacer que el usuario root tenga una contraseña, por ejemplo. 50 caracteres El inconveniente es que el tamaño de descarga de mi aplicación es demasiado grande (algunas Gigas). Y la siguiente pregunta es: ¿puede un atacante leer mi código Java desde una imagen de disco VDI?

Otro método es Ahead of Time (AOT) compilando a Native. ExcelsiorJet parece ser la mejor herramienta para eso, sin embargo eso no es gratis. Ofuscar el código fuente NO es suficiente, ya que los que desean leer su código fuente son los que principalmente quieren preocuparse por el flujo de información y la estructura de datos. Este excelente artículo explica más sobre AOT y ofuscación. Ahora la pregunta es: al utilizar ExcelsiorJet para compilar en nativo, ¿está mi código nativo relativamente a salvo de la ingeniería inversa?

Otra forma más: por ejemplo, use C ++ para escribir el código más crítico para la seguridad, compilarlo en nativo real y exponer mi fuente Java sin importancia. Pero esto significa que también necesitaré mantener ambas partes.

source-code protection java

pregunta Ken Po 08.08.2018 - 16:21

fuente

1 respuesta

Lea otras preguntas en las etiquetas source-code protection java

Posibilidad de inyección SQL por valores estáticos o predefinidos Kali Linux y la seguridad del teléfono celular

score 3 · Answer 1

Esta pregunta limita con la opinión / solicitud de recomendación del producto, pero intentaré responder las partes que están en el tema.

En primer lugar, los buenos ingenieros de ingeniería inversa son buenos . Con suficiente habilidad y tiempo, la fuente java, el código de bytes de java, la fuente c ++ y el ensamblaje nativo son equivalentes en términos de mostrar a un atacante cómo funciona su software.

Sobre la base del comentario de @Zymus, estás empezando con requisitos conflictivos, quieres:

Distribuya su código fuente a personas / máquinas en las que no confía, pero
No quieres que sea de motor inverso.

Si la computadora en la que están sentados puede entender y ejecutar su código, entonces (con suficiente esfuerzo) también puede hacerlo el humano. Parada completa.

Cuando tu punto de partida es "Quiero darles mi código, pero no quiero darles mi código" , no me sorprende que no puedas encontrar una solución. .

Respondiendo directamente a sus preguntas:

¿Puede un atacante leer mi código Java desde una imagen de disco VDI?

Bueno, ¿puede la computadora leer (y ejecutar) el código Java desde dentro de una imagen de disco VDI? Si es así, el atacante también puede hacerlo.

La ofuscación del código fuente NO es suficiente,

Bien, volvemos a los requisitos conflictivos aquí; la ofuscación es el acto de hacer código que aún puede ser ejecutado por una máquina, pero es difícil de entender para un humano. Usted dice que no es lo suficientemente bueno: desea permitir que el atacante ejecute su código, pero no lo lea. Eso no tiene sentido.

¿Mi código nativo está relativamente a salvo de la ingeniería inversa?

Otra forma más: por ejemplo, use C ++ para escribir el código más crítico para la seguridad, compilarlo en nativo real y exponer mi fuente Java sin importancia.

¿Por qué asumes que el código nativo es más difícil de usar ingeniería inversa que Java? Claro, hay más curva de aprendizaje para el ensamblaje de ingeniería inversa con herramientas como IDA Pro en comparación con java de ingeniería inversa con jad, pero para un ingeniero inverso experto, el esfuerzo es muy similar.

Me gusta la sugerencia de @Zymus: si hay bits de código que no quieres que tenga el atacante, no se los des; ejecútelo en un servidor y proporcione una API que solo exponga la entrada y salida (menos sensible).