c# - portable - ¿Cómo evito que mi código sea robado?
reflector.net portable (7)
"... impide que scriptkiddies abra mi código en Reflector y simplemente robe todas mis clases fácilmente".
Desafortunadamente, independientemente de cómo oculte el inicio, es cuestión de media docena de comandos en un depurador para volcar un ensamblaje actualmente en ejecución en un archivo de la elección del usuario. Entonces, incluso si puede iniciar su aplicación como lo sugirió Brian, no es difícil obtener los componentes de esa aplicación en Reflector una vez que se esté ejecutando (puedo publicar una muestra de WinDbg si alguien la encuentra interesante).
Las herramientas de ofuscación se crean a partir de una gran cantidad de experiencia técnica y, a menudo, están diseñadas para hacer que sea difícil para los depuradores asociarse de manera confiable a un proceso, o para extraer información de él. Como dijo Brian: No estoy seguro de por qué estás decidido a preservar la IL y, si quieres una protección significativa contra los chiquillos del guión, es algo en lo que tienes que cambiar de opinión.
¿Qué sucede exactamente cuando ejecuto un .NET exe? Sé que C # está compilado a código IL y creo que el archivo exe generado es solo un lanzador que inicia el tiempo de ejecución y le pasa el código IL. ¿Pero cómo? ¿Y qué tan complejo es el proceso?
El código IL está incrustado en el exe. Creo que puede ejecutarse desde la memoria sin escribirlo en el disco, mientras que los exe comunes no lo están (ok, sí, pero es muy complicado).
Mi objetivo final es extraer el código IL y escribir mi propio lanzador cifrado para evitar que scriptkiddies abra mi código en Reflector y simplemente robe todas mis clases fácilmente. Bueno, no puedo evitar completamente la ingeniería inversa. Si son capaces de inspeccionar la memoria y capturar el momento en el que estoy pasando el IL puro al tiempo de ejecución, no importará si se trata de un exe .net o no, ¿verdad? Sé que hay varias herramientas ofuscadoras pero no quiero estropear el código IL en sí.
EDIT: por lo que parece que no vale la pena probar lo que quería. Lo romperán de todos modos ... Así que buscaré una herramienta de ofuscación. Y sí, mis amigos también dijeron que es suficiente cambiar el nombre de todos los símbolos a un nombre sin significado. Y la ingeniería inversa no será tan fácil después de todo.
el archivo exe generado es solo un iniciador que inicia el tiempo de ejecución y le pasa el código IL.
No exactamente. Existen diferentes formas de configurar su programa, pero normalmente el código IL se compila en un código de máquina nativo que se ejecuta en proceso con el tiempo de ejecución.
En cuanto a los niños, te estás engañando a ti mismo si crees que puedes venderles a ellos o a cualquiera que use lo que redistribuyen. Si no pueden desbloquear tu aplicación, seguirán adelante y encontrarán una que pueden o no pueden usar. Representan exactamente $ 0 en ventas potenciales; no tiene mucho sentido gastar demasiado esfuerzo intentando frustrarlos porque no habrá retorno de su inversión. Un ofuscador básico podría estar bien, pero no vaya más allá de eso.
De manera realista, la mayoría de los desarrolladores enfrentan un desafío mucho mayor desde la oscuridad que desde la piratería. Cualquier cosa que hagas que te impida hacer correr la voz acerca de tu producto te duele más que los piratas. Esto incluye hacer que la gente pague dinero para obtenerlo. La mayoría de las veces, un mejor enfoque es tener una versión gratuita de tu aplicación que los niños no necesiten desbloquear; algo que ya funciona para ellos lo suficientemente bien como para descifrar su aplicación sería una pérdida de tiempo, y no solo una prueba de tiempo o función limitada. Que ellos y tantos otros como sea posible lo extiendan a lo largo y ancho.
Ahora sé que eventualmente necesitas algunos clientes que paguen. La clave es usar toda la atención que recibe del producto gratuito para vender o promocionar algo que sea más rentable. Una opción aquí es también tener una versión premium con características adicionales dirigidas en gran medida a una audiencia de negocios; cosas como facilitar la implementación en una red completa y administrar de esa manera. Las empresas tienen más recursos y es más probable que paguen los aranceles de su licencia. Su versión gratuita sirve para promocionar su producto y darle legitimidad a sus clientes comerciales.
Por supuesto, también hay otros modelos, pero no importa lo que hagas, vale la pena recordar que la oscuridad es el mayor desafío y que las copias pirateadas de tu software nunca se traducirán en ventas. En última instancia (y, por supuesto, esto depende de su ejecución), podrá ganar más dinero con un modelo de negocio que aproveche esos puntos de lo que intentará combatirlos.
"Copiaron todo lo que podían seguir, pero no pudieron copiar mi mente, así que los dejé sudando y robando un año y medio atrás". - R. Kipling
Copiando mi respuesta de esta pregunta (que no está exactamente duplicada pero puede responderse con la misma respuesta, por lo tanto, CW):
Un Windows EXE contiene múltiples "partes". Simplificado , el Código .net (= MSIL) es solo una Parte del EXE, y también hay una Parte de Windows nativa "real" dentro del EXE que sirve como una especie de lanzador para el Framework .net que luego ejecuta el MSIL.
Mono solo tomará la MSIL y la ejecutará, ignorando las cosas nativas de Windows Launcher.
Una vez más, este es un resumen simplificado.
Edit: Me temo que mi comprensión de los detalles de depp no es lo suficientemente buena como para realmente muchos detalles (sé aproximadamente lo que es un encabezado de PE, pero no realmente los detalles), pero me parecieron útiles estos enlaces:
Estructura de la Asamblea NET - Parte II
.NET Foundations - Estructura de ensamblaje .NET
Apéndice: Si realmente desea profundizar, obtenga una copia en la depuración avanzada de .net . El primer capítulo explica exactamente cómo se carga el ensamblaje .net antes y después de Windows XP (desde XP, el cargador de Windows reconoce .net, lo que cambia radicalmente la forma en que se inician las aplicaciones .net)
Personalmente creo que la ofuscación es el camino a seguir. Es simple y puede ser efectivo, especialmente si todo su código está dentro de un exe (no estoy seguro de cuál es la preocupación de "arruinar la IL").
Sin embargo, si sientes que eso no funcionará para ti, quizás puedas encriptar tu archivo ejecutable e insertarlo como un recurso dentro de tu lanzador. La forma más sencilla de manejarlo sería descifrar el recurso exe y escribirlo también en un archivo y ejecutarlo. Una vez que el exe haya terminado de ejecutarse, borre el archivo. También puede ejecutarlo a través de las funciones Emit. No tengo idea de cómo funcionaría esto, pero aquí hay un artículo para comenzar: Uso de Reflection Emit to Cache .NET Assemblies .
Por supuesto, su clave de descifrado probablemente también tendría que estar incrustada en el exe para que alguien realmente determinado pueda descifrar su ensamblaje de todos modos. Es por esto que la ofuscación es probablemente el mejor enfoque.
Si insiste absolutamente en cifrar su ensamblaje, probablemente la mejor manera de hacerlo es colocar su código de programa en ensamblajes de bibliotecas de clases y cifrarlos. Luego, escribiría un pequeño archivo ejecutable de código auxiliar que descifra los ensamblados en la memoria y los ejecuta.
Esta es una idea extremadamente mala por dos razones:
- Vas a tener que incluir la clave de cifrado en tu código auxiliar. Si un hacker 1337 puede usar sus ensamblajes reflejados de manera significativa, puede simplemente robar su clave de cifrado y descifrarlos él mismo. (Esto es básicamente el agujero analógico )
- A nadie le importa tu código 1337. Lo siento, pero eso es duro amor. Nadie más piensa que el código de alguien sea tan interesante como el autor.
Un "secreto" que compartes con miles de personas no es un secreto. Recuerde, sus atacantes solo tienen que romper su esquema de "cifrado" trivial-a-break-porque-the-key-is-right-there exactamente una vez.
Si su código es tan valioso que debe mantenerse en secreto, entonces manténgalo en secreto . Deje el código solo en sus propios servidores; escribe tu software como un servicio web. Luego asegure el servidor.