¿El archivo de clase java o el archivo jar es fácil de aplicar ingeniería inversa? Porque Java genera un archivo de clase después de la compilación y no archivos exe. ¿Los archivos jar y class son fáciles de descompilar en comparación con c # y C ++? Si es fácil, ¿cómo podemos proteger el código Java para que sea difícil realizar ingeniería inversa?
Sí, los archivos de clase Java son fáciles de aplicar ingeniería inversa. El formato es muy regular y muy limitado: la máquina virtual debe poder verificar que el código cumple con las reglas de tipificación de código de Java. Esto es como la salida de un compilador de C con todas las optimizaciones desactivadas: la estructura del programa es claramente visible. (En el modelo Java, la optimización ocurre en la propia VM, cuando se ejecuta el compilador JIT).
Sin embargo, la gente trata de ofuscación; p.ej. con ProGuard (hay muchas herramientas en ese mercado; esta es gratuita y de código abierto). Por ejemplo, todas las clases y métodos se renombran con cadenas que no tienen sentido para un ser humano (pero la ofuscación también produce un archivo de traducción que el desarrollador guarda para sí mismo, de modo que pueda interpretar los rastreos de la pila en caso de informes de errores). / p>
De forma alternativa, puede procesar su código Java en un compilador de tiempo de anticipación , como JET . Esto tiene algunas restricciones (en particular, el resultado ya no es "portátil", ya que es un código nativo) pero hace que la descompilación sea más difícil (cerca de la complejidad de la ingeniería inversa compilada C o C ++).
Como regla general, la ingeniería inversa tiende a funcionar, y para Java aún más, incluso después de la ofuscación. Es mejor que no utilices la ofuscación como la base de tu seguridad.
También vale la pena señalar que esto es muy similar a los problemas de lectura de códigos en cualquier lenguaje .Net como C #. Es bastante trivial generar código Java, VB.Net o C # a partir de los archivos distribuidos y las técnicas de ofuscación que intentan dificultar la lectura también son similares para ambos.
Hay una serie de herramientas que permiten la descompilación de programas Java, y son bastante fáciles de usar.
Por ejemplo, JD-GUI presenta una vista gráfica de un archivo JAR cargado y hace que la navegación del código sea razonable fácil.
Si alguien quiere modificar el código de una aplicación a la que tiene acceso, eso es relativamente sencillo y está bien documentado, por ejemplo, esto McAfee analiza el proceso de descompilación de un programa, modifica una clase Java y luego vuelve a compilar el programa.
como dijo @ThomasPornin, confiar en la ofuscación es una mala idea para este tipo de problema. Si permite que alguien descargue una copia de un programa, debe asumir que un atacante podría tener acceso a cualquier información dentro del programa y puede omitir cualquier comprobación de seguridad que solo se realice en el lado del cliente.
un pequeño número de archivos de clase o archivos JAR es fácil de usar ingeniería inversa (vea la respuesta de @Thomas). Sin embargo, las aplicaciones Java más grandes, por ejemplo. Los J2EE que usan muchos cientos de archivos JAR y tienen scripts de compilación enormemente complejos pueden ser difíciles de realizar ingeniería inversa solo por la complejidad del código.
Hay herramientas de código abierto y comerciales para ayudar a organizar su código y darle sentido a todo, incluido un interesante complemento de Eclise llamado VERA .
Si solo está tratando de conocer la estructura del código, existen herramientas de introspección que pueden ayudar, así como herramientas de modelado, como Rational Suite / Enterprise Architect, que pueden aspirar los archivos JAR java y proporcionarle modelos UML.
Lea otras preguntas en las etiquetas java reverse-engineering