Crear programas Java que no sean de ingeniería inversa

Question

¿Hay alguna manera de implementar un programa Java en un formato que no sea de ingeniería inversa?

Sé cómo convertir mi aplicación en un archivo JAR ejecutable, pero quiero asegurarme de que el código no se pueda aplicar ingeniería inversa, o al menos, no con facilidad.

La ofuscación del código fuente no cuenta ... hace que sea más difícil entender el código, pero no lo oculta.

Una pregunta relacionada es Cómo bloquear compilado ¿Clases de Java para evitar la descompilación?

---

Una vez que haya completado el programa, aún tendría acceso a la fuente original, por lo que mantener la aplicación no sería el problema. Si la aplicación se distribuye, no quisiera que ninguno de los usuarios pueda descompilarla. La ofuscación no logra esto, ya que los usuarios aún podrían descompilarlo, y aunque tendrían dificultades para seguir los flujos de acción, podrían ver el código y potencialmente extraer información de él.

Lo que me preocupa es si hay alguna información en el código relacionada con el acceso remoto. Hay un host al que se conecta la aplicación utilizando una identificación de usuario y una contraseña proporcionadas por el usuario. ¿Hay alguna forma de ocultar la dirección del host del usuario, si esa dirección se encuentra dentro del código fuente?

Answer 1

Puede ofuscar su archivo JAR con YGuard . No ofusca su código fuente , sino las clases compiladas, por lo que no hay problema en mantener el código más tarde.

Si desea ocultar alguna cadena, puede encriptarla, haciendo que sea más difícil hacerlo mirando el código fuente (es aún mejor si ofusca el archivo JAR).

Answer 2

La respuesta corta es "No, no existe".

La ingeniería inversa es un proceso que no implica mirar el código en absoluto . Básicamente trata de comprender los mecanismos subyacentes y luego imitarlos. Por ejemplo, así es como aparece JScript en los laboratorios de MS, copiando el comportamiento de JavaScript de Netscape, sin tener acceso al código. La copia fue tan perfecta que incluso los errores fueron copiados.

Answer 3

Si sabe a qué plataformas se dirige, obtenga algo que compile su Java en código nativo, como Excelsior JET o GCJ .

Aparte de eso, nunca podrás ocultar el código fuente, ya que el usuario siempre tiene tu código de bytes y puede Jad it.

Answer 4

Estás escribiendo en un lenguaje que tiene introspección como parte del lenguaje central. Genera archivos .class cuyas especificaciones son ampliamente conocidas (lo que permite a otros proveedores producir implementaciones de compiladores e intérpretes de Java).

Esto significa que hay descompiladores disponibles públicamente. Todo lo que necesitas son unas pocas búsquedas en Google, y tienes un código Java que hace lo mismo que el tuyo. Solo sin los comentarios y algunos de los nombres de las variables (pero los nombres de las funciones permanecen igual).

Realmente, la ofuscación es casi todo lo que puede obtener (aunque el código descompilado ya estará ligeramente ofuscado) sin ir a C u otro lenguaje completamente compilado, de todos modos.

Answer 5

¿No usa un lenguaje interpretado? ¿Qué estás tratando de proteger de todos modos? Si es lo suficientemente valioso, cualquier cosa puede ser de ingeniería inversa. Las posibilidades de que alguien se preocupe lo suficiente como para realizar ingeniería inversa en la mayoría de los proyectos es mínima. La ofuscación proporciona al menos un obstáculo mínimo.

Asegúrese de que su propiedad intelectual (IP) esté protegida mediante otros mecanismos. Particularmente para el código de seguridad, es importante que las personas puedan inspeccionar las implementaciones, para que la seguridad esté en el algoritmo, no en la fuente.

Answer 6

Estoy tentado de preguntar por qué quieres hacer esto, pero lo dejaré solo ...

El problema que veo es que la JVM, como el CLR, necesita poder introducir su código para poder compilarlo y ejecutarlo. Puedes hacerlo más complejo pero dado que la especificación para el código de bytes está bastante bien documentada y existe en un nivel mucho más alto que algo como la especificación del ensamblador x86, es poco probable que pueda '' ocultar '' el flujo del proceso, ya que tiene que estar allí para que el programa funcione en primer lugar.

Answer 7

No se puede hacer.

Cualquier cosa que se pueda compilar se puede descompilar. Lo mejor que puedes hacer es ofuscarte.

Dicho esto, hay algunas cosas interesantes que suceden en la Criptografía Cuántica. Esencialmente, cualquier intento de leer el mensaje lo cambia. No sé si esto podría aplicarse al código fuente o no.

Answer 8

Incluso si compila el código en lenguaje máquina nativo, hay todo tipo de programas que le permiten esencialmente descompilarlo en lenguaje ensamblador y seguir el flujo del proceso (OlyDbg, IDA Pro).

Answer 9

Conviértalo en un servicio web. Entonces eres el único que puede ver el código fuente.

Answer 10

No se puede hacer. Este no es un problema de Java. Cualquier lenguaje que se pueda compilar se puede descompilar para Java, es más fácil.

Estás intentando mostrarle a alguien una imagen sin mostrarla realmente. No es posible. Tampoco puede ocultar su host incluso si se oculta en el nivel de la aplicación. Alguien puede obtenerlo a través de Wireshark o cualquier otro sniffer de red.

Answer 11

Como alguien dijo anteriormente, la ingeniería inversa siempre podría descompilar su ejecutable. La única forma de proteger su código fuente (o algoritmo) es no distribuir su ejecutable.

separe su aplicación en un código de servidor y una aplicación de cliente, oculte la parte importante de su algoritmo en el código de su servidor y ejecútelo en un servidor en la nube, simplemente distribuya el código de cliente que funciona solo como un captador y senter de datos.

Con esto, incluso su código de cliente se descompila. No estás perdiendo nada.

Pero seguro que esto disminuirá el rendimiento y la comodidad del usuario.

Creo que esta puede no ser la respuesta que está buscando, sino solo para plantear una idea diferente de proteger el código fuente.

Answer 12

Con cualquier cosa interpretada en algún momento, debe procesarse " en claro " ;. La cadena aparecerá clara como el día una vez que el código se ejecute a través de JAD. Puede implementar una clave de cifrado con su aplicación o hacer un cifrado básico para cifrar la información de conexión del host y descifrar en tiempo de ejecución ...

Pero en algún momento durante el procesamiento, la información de conexión del host debe dejarse en claro para que su aplicación se conecte al host ...

Entonces, podría ocultarlo estáticamente, pero no puede ocultarlo durante el tiempo de ejecución si ejecutan un depurador

Answer 13

Esto es imposible. La CPU tendrá que ejecutar su programa, es decir, su programa debe estar en un formato que la CPU pueda entender. Las CPU son mucho más tontas que los humanos. Ergo, si una CPU puede entender tu programa, una humana puede.

Answer 14

Preocupado por ocultar el código, ejecutaría ProGuard de todos modos.