Descompilación .NET, ¿qué tan fácil es?

Question

Estaba buscando el mejor cifrado para una clave de licencia para una aplicación, y alguien dijo que alguien puede descompilar fácilmente la aplicación y luego simplemente omitir la prueba para obtener la clave de licencia.

¿cómo podría alguien hacer eso prácticamente hablando? Entonces tienen mi .dll, tienen que descompilarlo de alguna manera, luego comentar la llamada a la función para verificar la licencia y luego volver a compilarla. ¡El descompilador tiene que ser realmente bueno para que el código aún se compile!

Answer 1

Intente abrir su aplicación con Reflector . Probablemente se sorprenderá :-)

Y una vez que un cracker ha localizado la ubicación correcta en su código, puede usar una combinación de ildasm / ilasm para eliminar el cheque de su aplicación, incluso si el código que Reflector genera no se compilará.

Answer 2

Si el código fuente se compila normalmente, es muy fácil descompilar ensamblados .NET.

Puede usar .NET Reflector , desarrollado originalmente por Lutz Roeder, ahora compatible con Redgate Software. Hay una captura de pantalla en la parte inferior de esta respuesta que le da una impresión de lo que hace Reflector.

Puede navegar por sus espacios de nombres y clases y ver el código fuente y los métodos en su lenguaje .NET favorito. FileDisassembler de Denis Bauer le permitirá (o los malvados hackers) en su caso) para convertirlo en una solución VS y realizar modificaciones en el programa.

Hay algunas contramedidas como usar un ofuscador de código para hacer que su código sea prácticamente ilegible.

Hay otras preguntas interesantes sobre StackOverflow sobre este tema:

• ¿Debería ofuscar una aplicación .Net comercial?
• ¿Cómo descompilo un .NET EXE en código fuente legible de C #?
• Las mejores herramientas / estrategia de ofuscación .NET
• ¿Criptografía .NET para claves de licencia?

Captura de pantalla de Reflector:

Answer 3

Josh Smith también lanzó Crack.NET recientemente, que puede usarse para conectarse a un .NET en ejecución proceso, y luego ábralo en Reflector , incluso si los ensamblajes en el disco son cifrados de alguna manera (para evitar que las personas que usan Reflector los alcancen), aún podrán usar las versiones en memoria

Answer 4

.NET es súper fácil de descompilar. La ofuscación hará que sea un poco más difícil entender lo que está sucediendo, pero alguien que descompila tu código aún puede resolverlo si es persistente.

Aquí hay algunos consejos sobre cómo proteger su código .NET que encontré en línea:

http://blogs.msdn.com/ericgu /archive/2004/02/24/79236.aspx

Solo tenga en cuenta que ninguna de las técnicas discutidas es 100% efectiva, es solo una cuestión de cuántos aros hará que salte la galleta.

Answer 5

La compilación de .NET en general es bastante fácil: para tener una idea de esto usted mismo, simplemente tome una copia de .NET Reflector y pruébalo.

En la mayoría de los casos, no será necesario volver a compilar el código para eliminar una simple verificación de licencia: simplemente parcheando el MSIL hará el truco.

Protegerse contra este escenario produce rendimientos que disminuyen rápidamente: siempre habrá alguien lo suficientemente inteligente como para evitar cualquier verificación adicional que agregue a su código. Por ejemplo, podría agregar una firma digital a su código, y negarse a ejecutar la firma no coincide (lo que indica que el código ha sido alterado, por ejemplo, para eliminar la verificación de licencia).

El juego se convierte en eliminar la verificación de firma (además de la verificación de la clave de licencia). Entonces agrega otro cheque, que luego puede omitirse, etc., hasta el infinito.

Hay toda una industria de código de ofuscación y herramientas de protección de copia para ayudarlo a defender su software contra problemas como este. Depende de usted decidir si vale la pena comprar el esfuerzo adicional de su lado y la molestia que causará a sus clientes legítimos en estas soluciones ...

Answer 6

Si esto es algo de lo que está buscando defenderse, puede leer sobre cómo atacarlo.

Explotación de software por Greg Holland & amp; Gary McGraw es una excelente introducción.

Answer 7

Es mejor no exagerar con la tecnología de clave de licencia. Cualquier cosa que haga puede ser pirateada por un usuario determinado y corre el mayor riesgo de agregar problemas que impidan que los usuarios legítimos usen su aplicación. Incluso he visto que el código que estaba protegido con Hasp Dongles se ha roto. Cifrar su clave de licencia y ofuscar su código debería ser suficiente para obstaculizar los ataques oportunistas, no tiene mucho sentido ir más allá de eso.

Eric Sink escribió un buen artículo sobre este punto, consulte la sección " 4. No moleste a las personas honestas " de " Principios de transparencia "

Answer 8

Incluso sin Reflector, la gente ha estado haciendo esto por años. Básicamente, mira la aplicación con un depurador, algo como lo hará WinDBG, y luego se entera cuando se realiza la verificación de la licencia. Usted observa el valor de retorno y luego simplemente parchea la aplicación para saltar directamente al " todo bien " comprobar.

Recomiendo todo lo que la gente ha publicado anteriormente. Solo tiene que darse cuenta de que es un juego de gato y ratón, y si su retorno de inversión valdrá la pena. Si tienes usuarios que no están intentando jugar con el sistema, entonces algo simple puede hacer. Si tiene algo donde las grietas son rampantes, entonces tendrá que mirar diferentes estrategias e ir desde allí.

No tiene que volver a compilar la aplicación para parchearla: existen muchas herramientas de parche binarias. Y no detendrá a sus crackers más decididos si hay suficiente dinero para ganar.

Answer 9

" Demasiado "

Cualquier tipo de mecanismo de verificación de licencia estándar / habitual es un objetivo para la herramienta de eliminación automática. Y en las pocas aplicaciones comerciales .NET que he reflexionado, estas '' Demasiado trivial '' los controles parecen comunes.

La mejor opción es proteger haciendo que parte del programa dependa del servicio web. Esta no debería ser una interfaz muy parlanchina para evitar ralentizar la ejecución, pero tampoco debería ser muy gruesa, ya que esos trozos podrían descargarse y almacenarse en caché localmente en la "versión descifrada". a menos que la aplicación dependa de que cambien con frecuencia.

Si desea evitar la conectividad de red (algunos usos o usuarios pueden encontrar eso problemático / cuestionable dependiendo de la aplicación a menos que sea algo que describa y proporcione valor) y luego divida parte del programa en una dll nativa o dos y tenga el las verificaciones de licencias en todas las partes de la aplicación y, menos obviamente, en las dll nativas, probablemente sean suficientes para disuadir a la mayoría.