Solución:
Primero, si está apuntando “solo” al mercado de Windows, hay una forma muy fácil de prevenir la descompilación “.class a .java”: use una herramienta como Excelsior Jet que transformará la .frasco en un .exe.
Esto es infalible: es imposible para recuperar el archivo .java si usa Excelsior Jet (siempre y cuando todas las personas digan “es imposible evitar la descompilación de un .clase archivo “). Seguro, un atacante podría iniciar Hielo suave y trata de rastrear tu .exe pero eso resultará un poco más complicado que usar JAD para descompilar el .clase a un .Java y ciertamente no permitirá encontrar el .Java archivo de nuevo.
Ahora tal vez también esté apuntando a OS X y Linux o no tiene $$$ para pagar por Excelsior Jet.
Estoy escribiendo un software comercial escrito en Java. Ese software solo tiene sentido si hay una conexión a Internet. Por lo tanto, “protegemos” nuestro software, entre otras cosas, haciendo que parte del cálculo se realice en el lado del servidor: tenemos varios .clase que no funcionará a menos que se generen desde el lado del servidor y los enviamos por el cable (y lo que se envía por el cable es siempre diferente: estamos generando únicos, únicos .clase archivos en el lado del servidor).
Esto requiere una conexión a Internet, pero si al usuario no le gusta cómo funciona nuestro software, puede comprar uno de los productos inferiores de la competencia;)
La descompilación no servirá de mucho: necesita activamente descifrar el software (es decir, reproducir lo que está sucediendo en el lado del servidor) o no podrá usarlo.
Usamos nuestra propia “ofuscación de cadenas” antes de usamos Proguard. También hacemos instrumentación de código fuente (podríamos haber hecho instrumentación de código de bytes también) donde eliminamos muchas cosas del código (como la “afirmación” que comentamos) e introducimos alguna “ofuscación de flujo de código” aleatoria [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).
Luego usamos Proguard (que es gratis) para aplanar toda nuestra jerarquía OO y para ofuscar el código ya-código-flujo-y-cadena-ofuscado.
Entonces nuestro flujo es:
- ofuscación de cuerdas
- ofuscación de flujo de código aleatorio
- Proguard
- final .frasco eso depende de .clase que se generan (de manera diferente) dinámicamente en el lado del servidor.
Además de eso, lanzamos actualizaciones muy regulares (y automatizadas) que siempre nos aseguramos de modificar un poco nuestro esquema de protección cliente / servidor (de modo que con cada lanzamiento un atacante hipotético tiene que comenzar principalmente desde cero).
Por supuesto que es más fácil tirar la toalla y pensar: “No hay nada que pueda hacer para dificultar la vida de un atacante porque JAD puede encontrar el archivo .java de todos modos” (lo cual es más que muy debatible y descaradamente incorrecto en el caso de que utilice un convertidor de .class a .exe para proteger su .class de la descompilación).
Un ofuscador (ver http://java-source.net/open-source/obfuscators) “codificará” el código de tal manera que no tendrá ningún sentido cuando se descompile.
Hay varios métodos:
- Ofuscación
- Cifrado de software (defectuoso)
- Cifrado de hardware (casi irrompible, pero el impacto en el rendimiento es enorme)
- Recopilación nativa
todo discutido en detalle en mi artículo Proteja su código Java, a través de ofuscadores y más