¿Protege el código .NET de la ingeniería inversa?

La ofuscación es una de las formas, pero no puede proteger contra la violación de la protección de la seguridad de la aplicación. ¿Cómo me aseguro de que no se altere la aplicación y cómo me aseguro de que el mecanismo de registro no se pueda modificar por ingeniería inversa?

También es posible convertir una aplicación C # a código nativo, y Xenocode es demasiado costoso.

C # proporciona muchas características, y es el lenguaje ideal para mi código, por lo que escribir la totalidad de la base de código nuevamente en C ++ está fuera de discusión.

Los certificados seguros se pueden eliminar fácilmente de los ensamblados firmados en .NET.

No puedes.

Hay pasos que puede seguir para hacerlo un poco más difícil, pero finalmente cualquier ejecutable en la máquina local es crackable. Eventualmente, ese código se debe convertir a código máquina nativo y cada aplicación que se puede ejecutar es vulnerable.

Lo que quieres hacer es simplemente dificultar el crackear para que no valga la pena los problemas de la gente.

Algunas sugerencias que tengo para ayudar a proteger su aplicación:

  • Ofuscar su código Dotfuscator tiene una edición gratuita y viene con Visual Studio.
  • Use clave pública / privada o cifrado asimétrico para generar sus licencias de productos. Esto asegura que solo usted puede generar sus códigos de licencia. Incluso si su aplicación está rajada, puede estar seguro de que no lanzarán un generador de claves para su aplicación, ya que es imposible invertir el algoritmo de generación de claves.
  • Utilice un empaquetador de terceros para empacar su ejecutable de .NET en una aplicación Win32 wrapper cifrada. Themida es uno de los mejores. Esto evita que las personas reflejen su aplicación en .NET Reflector y hace que sea difícil deshacer la reversión.
  • Escribe tu propio empacador personalizado . Si los empaquetadores de terceros son demasiado caros, considera escribir el tuyo propio. A veces, los empaquetadores personalizados pueden ser muy efectivos, porque no hay métodos bien publicados sobre cómo desempaquetarlos. El tutorial Cómo escribir su propio empacador brinda mucha información sobre cómo escribir su propio empaquetador Win32.

Sin embargo, al final, si las personas quieren que su aplicación se raje, lo harán. Mire todo el software comercial que tiene una gran cantidad de recursos para proteger sus aplicaciones y, sin embargo, se descifran antes de que las aplicaciones se publiquen al público.

Un ingeniero de ingeniería calificado puede disparar IDA-Pro y cortar su aplicación como la mantequilla sin importar lo que haga. Se puede desempaquetar una aplicación empaquetada y la ofuscación solo evita que pase por el parque. Todo su trabajo duro con su código de licencia complejo se puede deshacer con un parche de un solo byte.

Solo tiene que aceptar que hay una posibilidad muy real de que la gente piratee su software. Hay algunas personas que nunca van a pagar por su aplicación sin importar qué y estas son las personas que no necesitan preocuparse.

Sin embargo, hay muchas empresas que nunca se arriesgarían a una demanda y que felizmente compran licencias de software y muchos usuarios de computadoras que no quieren arriesgarse, no lo encuentran o no son lo suficientemente conocedores de la tecnología como para piratear. Estos son sus verdaderos clientes, y debe concentrar sus esfuerzos en proporcionarles una buena experiencia de usuario e ignorar a las personas que descifran su software.

He pirateado mi aplicación antes, y la tomé como una afrenta personal. ¡Aquí estaba, un desarrollador de poca monta, vertiendo mi corazón y mi alma en una aplicación y esta gente tuvo el descaro de piratear de mí! ¡Estaban sacando dinero directamente de mi bolsillo!

Inmediatamente agregué un montón de código DRM draconiano e intenté sabotear a cualquier persona que usara una copia ilegítima o agrietada. Por supuesto, debería haber estado trabajando para mejorar mi aplicación en lugar de tratar de detener lo inevitable. No solo eso, sino que estaba lastimando a mis verdaderos clientes con todas estas protecciones adicionales que estaba poniendo.

Después de una larga batalla, me di cuenta de que estaba luchando contra las mareas y que todo este tiempo desperdiciado fue en vano. Saqué todo el código del teléfono, excepto las funciones de la licencia barebone y nunca miré hacia atrás.

No puede asegurar completamente ninguna aplicación (administrada o no). Si los sistemas como la Playstation y el iPad se pueden agrietar, donde el proveedor incluso controla el hardware, ¿qué esperanza tiene tu aplicación? Afortunadamente, realmente no quieres hacerlo. En mi opinión, debe asegurar su aplicación lo suficiente como para que alguien no pueda piratear accidentalmente su producto, y nada más.

Por ejemplo, si usa una licencia por máquina, no debería funcionar solo cuando la instale en una segunda máquina nueva. Querrá un buen mensaje de error para evitar llamadas de soporte técnico adicionales, pero no pierda tiempo extra, lo que dificulta mucho el trabajo y no golpea a los usuarios con la cabeza.

Otro ejemplo es una prueba de tiempo limitado. Ni siquiera se preocupe por cosas simples como si los usuarios pueden simplemente retrasar el reloj del sistema. Alguien que lo hace sabe que está rompiendo su licencia, y siempre que un usuario sepa cuándo están en violación, habrá hecho lo suficiente.

Debe hacer esto porque los usuarios no se preocupan por su licencia. Las licencias son cosas inventadas que a nadie le importan hasta que lo necesiten. Nadie los lee, y realmente no deberían tener que hacerlo. Por lo tanto, la mejor manera de decirle al usuario dónde se encuentran los límites es si el comportamiento fuera de la caja de su aplicación cumple con la licencia. En este primer caso, significa que no se puede instalar o instalar en el modo de versión de prueba la segunda vez. Para este último, podría significar simplemente verificar una fecha de texto sin formato en un archivo de configuración. De cualquier manera, asegúrese de manejarlo de una manera elegante, útil y respetuosa.

Entonces eso explica lo que significa hacer exactamente eso. Pero, ¿por qué no ir más allá? ¿Por qué no tapar cada pequeño hoyo que puedes encontrar? La respuesta está en dos partes. En primer lugar, si alguien cruza el umbral ético de romper conscientemente los términos de su licencia, incluso de una manera sencilla, también estará dispuesto a hacer algo más difícil o peligroso, como sacar su aplicación de un sitio de torrents , y hay una cierta cantidad de peligro involucrado en la ejecución de aplicaciones descargadas de fonts no confiables. Hacerlo más difícil es solo una pequeña molestia para estos usuarios y puede causar problemas con sus clientes que pagan. Mantenerlo simple puede evitar que alguien investigue en su aplicación y libere un crack más completo. Segundo, tienes pocos ojos disponibles para buscar defectos; los hackers tienen muchos y tienen más práctica para encontrarlos. Solo necesita perder una pequeña falla y su aplicación tendrá la misma distribución en los sitios piratas como si no hubiera hecho nada. Tienes que estar en lo correcto cada vez; solo tienen que ser afortunados una vez. Entonces el esfuerzo requerido es muy alto, y la probabilidad de cualquier medida de éxito es muy baja.

En última instancia, si alguien quiere piratear su aplicación (en lugar de solo usarla), y ese es su objective principal, lo harán. No hay nada que puedas hacer para detenerlos. Esta es la naturaleza del software; una vez que los archivos que componen su producto estén en la computadora de un usuario, podrán hacer con ellos lo que deseen. Esto es especialmente relevante en entornos administrados como Java o .NET , pero definitivamente también se aplica al código nativo. El tiempo está de su lado, y dado el tiempo suficiente, se puede romper cualquier seguridad digital.

Como no puede evitar que los usuarios pirateen su producto, lo mejor que puede hacer es involucrar a esta clase de usuarios de una manera que los use en su beneficio. A menudo es posible lograr que funcionen para usted y no en su contra. Con esto en mente, no importa cuál sea su aplicación, probablemente valga la pena mantener una versión gratuita que sea casi completamente funcional y no caduque. La diferencia entre incluso un precio de $ 1 y gratis es enorme, sin más motivo que el hecho de que el cliente no tiene que confiar en usted con su tarjeta de crédito. Una edición gratuita de su producto no solo eliminará eficazmente la distribución pirateada (¿por qué arriesgar una versión pirateada cuando puede ser legítimo por el mismo precio?), Tiene el potencial de expandir dramáticamente su audiencia.

El resultado es que es posible que deba boost el precio de la edición de pago, para que al final en lugar de 2,000 usuarios a $ 20 cada uno, tenga 100.000 usuarios gratuitos, de los cuales 500 estén dispuestos a pagar $ 99 por la edición “profesional”. . Esto le gana más dinero que si pasara un montón de tiempo encerrando su producto. Más que eso, puedes contratar a estos usuarios gratuitos y aprovechar la relación de varias maneras importantes.

Uno es apoyo. Un pesimista aprovecharía esta oportunidad para quejarse del aumento en el costo de la asistencia a 100.000 usuarios gratuitos, pero en su lugar sucede algo sorprendente: su producto se vuelve en gran medida autosuficiente. Esto se ve todo el tiempo con grandes proyectos de código abierto que no tienen dinero para costos de soporte. Los usuarios intensificarán y harán que suceda.

Los usuarios libres generalmente tienen expectativas de soporte reducidas para empezar, y por buenas razones. Todo lo que necesita hacer es marcar la edición gratuita como solo calificando para el apoyo de la comunidad y poner un foro en línea moderado por el usuario para tal fin. Su base de conocimiento de soporte se autogenera, y los usuarios avanzados guiarán a aquellos que necesitan apoyo extra en su nombre. Aún más importante, esto le permitirá identificar y corregir errores más rápidamente, mejorando finalmente la calidad de su producto y reduciendo los costos totales de soporte. Esto no era posible antes porque su base de usuarios no era lo suficientemente grande, pero cuando trata a los usuarios libres como clientes puede funcionar muy bien.

Otro es retroalimentación. Al mirar su foro, aprende importantes ideas de mejora que quizás nunca haya considerado de otra manera. Esto puede permitirle convertir a la mayoría de sus usuarios gratuitos en usuarios pagos y crear un producto más atractivo que atraiga a una audiencia aún mayor.

Finalmente, debes considerar el marketing. Todos estos usuarios gratuitos son ahora fanáticos en lugar de adversarios, y actuarán en consecuencia. No solo eso, sino que a la hora de lanzar su próxima versión estos usuarios habrán pasado por su canal de distribución aprobado, en lugar de algún otro mecanismo desconocido. Eso significa que para su próxima versión, usted comienza a conectarse con una audiencia más grande, altamente interesada y solidaria.

Las mejores características para reservar para la edición profesional son herramientas destinadas a facilitar la implementación y administración corporativa. Un cracker no los verá como una razón suficientemente convincente para hackearlo para su propio uso, pero para una empresa que busca comprar 300 licencias y sacarlo de toda la compañía, es imprescindible. Por supuesto, la edición profesional será pirateada de todos modos, pero de nuevo: no te preocupes porque probablemente no puedas vender el producto a esos piratas sin importar lo que hayas hecho, por lo que no te costará ningún beneficio.

Si bien psicológicamente puede ser difícil regalar su producto tanto, con suerte usted puede entender cómo realmente es la mejor manera de hacerlo. No solo eso, es la única forma de avanzar en el largo plazo. Sé que alguien está por ahí pensando que no quieren hacerlo de esta manera. Después de todo, han vendido su producto bloqueado de $ 20 por años. Pero eso es una lástima, porque si no lo haces de esta manera, eventualmente alguien más lo hará . Y su producto será tan bueno como el suyo, o lo suficientemente cerca como para que se salgan con la suya. Entonces, de repente, su precio parece escandaloso, las ventas caen dramáticamente, y no hay nada más que pueda hacer. Puede optar por un nivel medio adicional si es necesario, pero es poco probable que lo ayude.

En mi experiencia, hacer que su aplicación o biblioteca sea más difícil de descifrar perjudica a sus clientes honestos, mientras que solo retrasa un poco los deshonestos. Concéntrese en hacer un gran producto de baja fricción en lugar de poner mucho esfuerzo en retrasar lo inevitable.

Un secreto que compartes con muchas personas no es un secreto. Si tiene algo secreto en su código, ofuscarlo no es protección; solo tiene que desofuscarse una vez . Si tiene un secreto que no desea compartir con sus clientes, no lo comparta con sus clientes . Escriba su código como un servicio web y mantenga su código súper secreto en su propio servidor, donde solo usted puede verlo.

En términos generales, hay tres grupos de personas por ahí.

  • Aquellos que no comprarán su software y recurrirán a grietas, o si no encuentran ninguno, no usarán su software en absoluto. No esperes ganar dinero con este grupo. Confían en sus propias habilidades o en crackers (que tienden a priorizar su tiempo según su utilidad y cuán grande es su audiencia. Cuanto más útil sea, más pronto estará disponible).

  • El grupo de usuarios legítimos que comprarán (pagarán) su software, independientemente del mecanismo de protección que utilice. No dificulte la vida de sus usuarios legítimos mediante el uso de un elaborado mecanismo de protección, ya que van a pagar en cualquier caso. Un mecanismo de protección complejo puede arruinar fácilmente la experiencia del usuario y no desea que esto le suceda a este grupo. Personalmente, votaría en contra de cualquier solución de hardware, lo que aumenta el costo de su software.

  • Una minoría que no recurrirá al crackeo “no ético” y pagará por su software porque sus características están protegidas por un mecanismo de licencia. Probablemente no desee que sea extremadamente fácil para este grupo evadir su protección. Sin embargo, todo el esfuerzo que gasta en proteger su software le devolverá el dinero, dependiendo de qué tan grande sea este grupo de personas. Esto depende completamente del tipo de software que esté creando.

Teniendo en cuenta lo que ha dicho, si cree que hay una minoría lo suficientemente grande a la que se puede presionar para que compre su software, implemente alguna forma de protección. Piense cuánto dinero puede ganar de esta minoría en comparación con el tiempo que pasa trabajando en la protección, o la cantidad que gasta en una API / herramienta de protección de un tercero.

Si desea implementar una solución propia, usar la criptografía de clave pública es una buena forma (a diferencia de los algoritmos simétricos) de evitar ataques fáciles. Por ejemplo, podría firmar digitalmente su licencia (número de serie o archivo de licencia). La única forma de evitar esto sería descomstackr, alterar y recomstackr el código (lo que podría hacer más difícil utilizando técnicas como las sugeridas en la respuesta de Simucal).

No puede evitar que las personas descifren su software.

Sin embargo, puede hacer que creen grietas que perjudiquen menos sus ventas. Los generadores clave que pueden emitir un código de registro válido para su software son mucho peores que los parches simples que eliminan los incentivos de registro de su software. Esto se debe a que un crack funcionará solo para una versión de software y dejará de funcionar con la próxima actualización de software que publique. El generador de claves continuará funcionando hasta que cambie el algoritmo de clave de registro, y eso es algo que no desea hacer a menudo porque desilusionará a sus clientes honestos.

Por lo tanto, si está buscando un método para combatir los generadores de claves ilegales para su software y no desea utilizar el cifrado asimétrico debido a los códigos de registro largos que esto genera, puede echar un vistazo a la verificación de clave parcial.

La verificación de clave parcial garantiza que cada generador de claves ilegal solo funcione para una versión particular de su software. Básicamente, lo que hace es asegurarse de que cada versión de su software solo se vincule con el código para verificar ALGUNOS dígitos del código de registro. Qué dígitos son exactamente al azar, por lo que los crackers tendrían que aplicar ingeniería inversa a muchas versiones diferentes de su software y combinar todo esto en un generador de claves para liberar un generador de claves que funcione para todas las versiones de su software.

Si publica nuevas versiones de software de forma regular, esto genera numerosos generadores de claves distribuidos en todo tipo de archivos de piratería de software que ya no funcionan. Los posibles piratas de software generalmente buscan un crack o keygen para la última versión, por lo que es probable que intenten algunos de ellos y abandonen eventualmente.

Utilicé la verificación de clave parcial en mis juegos de shareware más nuevos (C ++) y fue muy efectiva. Antes teníamos muchos problemas con los generadores de claves con los que no podíamos luchar. Después hubo muchas grietas y algunos generadores de claves que funcionaban solo para esa versión particular del juego, pero ningún generador de claves que funcionaría con todas las versiones. Regularmente lanzamos actualizaciones muy pequeñas del juego y para hacer que todas las grietas previamente existentes fueran inútiles.

Parece haber un framework .NET de código abierto para la verificación de clave parcial , aunque no lo he probado.

  • Use la actualización en línea para bloquear esas copias sin licencia.

  • Verifique el número de serie de los diferentes módulos de su aplicación y no use una sola llamada de función para hacer la verificación (para que los crackers no puedan eludir la verificación fácilmente).

  • No solo verifique el número de serie al inicio, realice la verificación mientras guarda los datos, hágalo todos los viernes por la noche, hágalo cuando el usuario esté inactivo …

  • Verifique la sum del cheque del archivo de la aplicación, almacene su sum del cheque de seguridad en diferentes lugares.

  • No se exceda en este tipo de trucos, asegúrese de que su aplicación nunca se bloquee o entre en funcionamiento incorrecto mientras se verifica el código de registro.

  • Crear una aplicación útil para los usuarios es mucho más importante que hacer una
    binario irrompible para cookies.

Usted puede..

Servicios de Microsoft SLP El Software Potential de InishTech ofrece la capacidad de ayudar a proteger el código sin afectar la funcionalidad de sus aplicaciones.

ACTUALIZACIÓN: (Divulgación: yo trabajo en Eazfuscator.NET) Lo que hace que el Software de SLP de Microsoft sea ​​diferente es la capacidad de virtualizar el código, por lo que definitivamente puede hacerlo. Han pasado varios años desde que se formuló originalmente la pregunta; hoy hay más productos disponibles que también funcionan de manera similar, como:

  • Agile.NET
  • Eazfuscator.NET

.NET Reflector solo puede abrir “código administrado” que básicamente significa “código .NET”. Por lo tanto, no puede usarlo para desensamblar archivos DLL COM, C ++ nativo, código clásico de Visual Basic 6.0 , etc. La estructura del código .NET comstackdo lo hace muy conveniente, portátil, detectable, verificable, etc. El reflector .NET aprovecha Esto le permite mirar en ensamblados comstackdos, pero los descomstackdores y desensambladores no son específicos de .NET y han existido siempre y cuando haya comstackdores.

Puedes utilizar los ofuscadores para hacer que el código sea más difícil de leer, pero no puedes evitar que se descompile sin hacerlo ilegible para .NET. Hay un puñado de productos por ahí (generalmente caros) que pretenden “vincular” la aplicación de código administrado a una aplicación de código nativo, pero incluso si estos realmente funcionan, una persona determinada siempre encontrará la manera.

Sin embargo, cuando se trata de ofuscación, obtienes lo que pagas. Entonces, si su código es tan exclusivo que debe hacer todo lo posible para protegerlo, debe estar dispuesto a invertir dinero en un buen ocultador.

Sin embargo, en mis 15 años o más de experiencia escribiendo código me he dado cuenta de que ser demasiado protector de tu código fuente es una pérdida de tiempo y tiene poco beneficio. Intentar leer el código fuente original sin documentación de apoyo, comentarios, etc. puede ser muy difícil de entender. Agregue a eso los nombres de las variables sin sentido que los decomstackdores generan y el código de spaghetti que crean los ofuscadores modernos: probablemente no tenga que preocuparse demasiado por las personas que roban su propiedad intelectual.

Si desea que la gente pueda ejecutar su código (y si no lo hace, ¿por qué lo escribió en primer lugar?), Entonces su CPU necesita poder ejecutar su código. Para poder ejecutar el código, la CPU necesita poder entenderlo .

Dado que las CPU son tontas, y los humanos no, esto significa que los humanos también pueden entender el código.

Solo hay una forma de asegurarse de que sus usuarios no obtengan su código: no les dé su código.

Esto se puede lograr de dos maneras: Software como servicio (SaaS), es decir, ejecuta su software en su servidor y solo permite que sus usuarios accedan a él de forma remota. Este es el modelo que usa Stack Overflow, por ejemplo. Estoy bastante seguro de que Stack Overflow no ofusca su código, pero no puedes descomstackrlo.

La otra forma es el modelo de dispositivo: en lugar de darles a los usuarios su código, les da una computadora que contiene el código. Este es el modelo que usan las consolas de juegos, la mayoría de los teléfonos móviles y TiVo . Tenga en cuenta que esto solo funciona si “posee” toda la ruta de ejecución: necesita construir su propia CPU, su propia computadora, escribir su propio sistema operativo y su propia implementación de CLI . Entonces, y solo entonces puedes proteger tu código. (Pero tenga en cuenta que incluso el error más pequeño hará que todas sus protecciones sean inútiles. Microsoft, Apple, Sony, la industria de la música y la industria del cine pueden dar fe de eso).

O bien, no puede hacer nada, lo que significa que su código estará automáticamente protegido por la ley de derechos de autor.

¿Realmente vale la pena? Cada mecanismo de protección se puede romper con suficiente determinación. Considere su mercado, el precio del producto, la cantidad de clientes, etc.

Si desea algo más confiable, siga la ruta de las teclas de hardware, pero eso es bastante problemático (para el usuario) y más costoso. Las soluciones de software probablemente serían una pérdida de tiempo y recursos, y lo único que le darían es la falsa sensación de “seguridad”.

Pocas ideas más (ninguna es perfecta, ya que no existe una perfecta).

  • AntiDuplicado
  • Cambie el idioma, use los trucos agradables que los autores de Skype usaron
  • Servidor de licencias

Y no pierda demasiado tiempo en ello, porque los crackers tienen mucha experiencia con las técnicas típicas y están a pocos pasos de usted. A menos que quiera usar muchos recursos, probablemente cambie el lenguaje de progtwigción (hágalo por Skype).

Lamentablemente, no vas a escapar de esto. Su mejor opción es escribir su código en C y P / Invocarlo .

Hay un pequeño catch-22, alguien podría simplemente descomstackr su aplicación a CIL y eliminar cualquier código de verificación / activación (por ejemplo, la llamada a su biblioteca C). Recuerde que las aplicaciones que están escritas en C también son creadas por ingeniería inversa por los piratas informáticos más persistentes (basta con ver qué tan rápido se rompen los juegos en estos días). Nada protegerá su aplicación.

Al final, se parece mucho a tu casa, protégela lo suficiente para que sea demasiado esfuerzo (el código de spaghetti ayudaría aquí) y para que el agresor se mueva hacia tu vecino de al lado (competencia :)). Mire Windows Vista, debe haber 10 maneras diferentes de descifrarlo.

Hay paquetes que encriptarán su archivo EXE y lo desencriptarán cuando el usuario pueda usarlo, pero una vez más, eso está usando una solución genérica que sin duda se ha descifrado.

Los mecanismos de activación y registro están dirigidos al “ciudadano promedio”: personas que no tienen suficiente conocimiento técnico para eludirlo (o para el caso, saber que pueden eludirlo). No te molestes con las cookies, tienen demasiado tiempo en sus manos.

Además de la protección de compras, usted (o sus desarrolladores) pueden aprender a proteger contra copias.

Estas son ideas:

Al principio, intente escribir un progtwig que se escriba en la consola. Ese es un problema famoso. El propósito principal de esta tarea es practicar la escritura de código de autorreferencia.

En segundo lugar, debe desarrollar una tecnología que reescriba algún código de una manera confiable en CIL de otros métodos.

Puede escribir una máquina virtual (aún en .NET ). Y pon un código ahí. En última instancia, la máquina virtual ejecuta otra máquina virtual que ejecuta el código. Eso es por una parte de las funciones llamadas raramente para no ralentizar demasiado el rendimiento.

Vuelva a escribir un poco de lógica en C ++ / CLI, y mezcle el código administrado con no administrado. Esto endurecerá el desassembly. En este caso, no se olvide de proporcionar binarios x64 también.

Sí. Es verdad. El código .NET es extremadamente fácil de aplicar ingeniería inversa si el código no está ofuscado.

La ofuscación agregará una capa de molestia a las personas que intentan aplicar ingeniería inversa a su software. Dependiendo de la versión que obtenga, obtendrá diferentes niveles de protección.

Visual Studio incluye una versión de Dotfuscator . Como se trata de una versión integrada, definitivamente no obtienes la mayor ofuscación posible. Si mira sus listas de características, verá exactamente lo que se está perdiendo (y exactamente lo que la aplicación hará para que su código sea más seguro).

Hay un par de otros ofuscadores de .NET libres o de código abierto (pero no puedo comentar sobre la calidad o los diversos métodos que usan):

  • Obfuscar
  • Babel.NET

Al final, nada es perfecto. Si alguien realmente quiere ver cómo funciona su software, lo harán.

Bueno, no puedes TOTALMENTE proteger tu producto para que no se agriete, pero puedes maximizar / mejorar los niveles de seguridad y hacerlo un poco demasiado difícil de ser descifrado por los novatos y los crackers intermedios.

Pero tenga en cuenta que nada es imposible de descifrar, solo que el software del lado del servidor está bien protegido y no se puede descifrar. De todos modos, para mejorar los niveles de seguridad en su aplicación, puede hacer algunos pasos simples para evitar que algunas “crackers” no crackeen sus aplicaciones. Estos pasos harán que estas cookies se vuelvan locas y tal vez desesperadas:

  • Ofusque su código fuente, obviamente esto hará que su código fuente parezca un desastre e ilegible.
  • Active varias rutinas de verificación al azar dentro de su aplicación, como cada dos horas, 24 horas, un día, semana, etc. o quizás después de cada acción que el usuario tome.
  • Guarde la sum de comprobación MD5 de su aplicación liberada en su servidor e implemente una rutina que pueda verificar la sum de comprobación actual del archivo MD5 con la real en su servidor y que se active al azar. Si se ha cambiado la sum de comprobación MD5, significa que esta copia ha sido pirateada. Ahora puede bloquearlo o lanzar una actualización para bloquearlo, etc.
  • Intente hacer una rutina que pueda verificar si algunos de sus códigos (funciones, clases o rutinas específicas) en realidad han sido modificados o modificados o incluso eliminados. Lo llamo (verificación de integridad del código).
  • Use empacadores desconocidos gratis para empacar su aplicación. O, si tiene dinero, busque soluciones comerciales como Thamida o .NET Reactor . Esas aplicaciones se actualizan regularmente y una vez que un cracker descomprime su aplicación, puede obtener una nueva actualización de esas compañías y una vez que obtenga la nueva actualización, solo empaca su progtwig y lanza una nueva actualización.
  • Actualice las actualizaciones regularmente y obligue a su cliente a descargar la última actualización.
  • Finalmente, haga que su aplicación sea muy barata. No lo hagas demasiado caro. Créanme, obtendrán más clientes felices y los crackers simplemente abandonarán su aplicación, porque no vale la pena su tiempo para descifrar una aplicación muy barata.

Esos son solo métodos simples para evitar que los novatos y los crackers intermedios rompan su aplicación. Si tiene más ideas para proteger su aplicación, no dude en implementarlas. Simplemente hará que los crackers vivan duro, y se frustrarán, y eventualmente dejarán su aplicación, porque simplemente no vale su tiempo.

Por último, también debe considerar pasar su tiempo codificando aplicaciones buenas y de calidad. No pierdas el tiempo codificando complicadas capas de seguridad. Si un buen cracker quiere descifrar su aplicación, lo hará sin importar lo que haga …

Ahora ve e implementa algunos juguetes para las cookies …

Hay Salamander , que es un comstackdor .NET nativo y un enlazador de Remotesoft que puede implementar aplicaciones sin .NET Framework. No sé qué tan bien está a la altura de sus afirmaciones.

Si Microsoft pudiera encontrar una solución, no habremos pirateado las versiones de Windows, así que nada es muy seguro. Aquí hay algunas preguntas similares de Stack Overflow y puede implementar su propia forma de protegerlas. Si está lanzando versiones diferentes, entonces puede adoptar diferentes técnicas para diferentes versiones, de modo que cuando se descifra la primera, la segunda puede hacerse cargo.

  • Administrar funciones con licencia para una aplicación C ++

  • Asegure un archivo DLL con un archivo de licencia

  • ¿Software de licencias / protección?

Reactor .NET

Actualizar

Jared señaló que de4dot afirma ser capaz de descomstackrlo.

.NET Reactor proporciona protección completa para su propiedad intelectual sensible al convertir sus ensamblados de .NET en procesos no administrados que no pueden entenderse como CIL y que ninguna herramienta existente puede descomstackr. Los hackers no tienen acceso a ninguna forma inteligible de su fuente.

Potente y flexible, las características de licencia de .NET Reactor le permiten hacer cumplir las condiciones de su licencia y proteger su flujo de ingresos mediante el uso de lockings de hardware y software. El administrador de licencias puede crear licencias de prueba o permanentes, en cuestión de segundos. Un kit de desarrollo de software (SDK) completamente documentado, completo con ejemplos, le permite llamar al sistema de licencias directamente desde su código, lo que le permite crear extensiones personalizadas para el sistema de licencias.

Aquí hay una idea: puede tener un servidor alojado por su empresa al que deben conectarse todas las instancias de su software. Simplemente hacer que se conecten y verificar una clave de registro no es suficiente; simplemente eliminarán el cheque. Además de la verificación de clave, también necesita que el servidor realice alguna tarea vital que el cliente no puede realizar por sí mismo, por lo que es imposible de eliminar. Esto, por supuesto, probablemente signifique un gran procesamiento por parte de su servidor, pero haría que su software sea difícil de robar, y suponiendo que tiene un buen esquema de claves (verificación de propiedad, etc.), las claves también serán difíciles de robar. Esto es probablemente más invasivo de lo que desea, ya que requerirá que sus usuarios estén conectados a Internet para usar su software.

Cualquier cosa que se ejecute en el cliente se puede descomstackr y descifrar. La ofuscación solo lo hace más difícil. No conozco su solicitud, pero el 99% de las veces no creo que valga la pena el esfuerzo.

¡Ofuscar el código! Hay un ejemplo en Ofuscación de C # Code .

Tenga en cuenta que el 99% de sus usuarios no estarán interesados ​​en examinar su ejecutable para ver cómo funciona.

Dado que muy pocas personas incluso se van a molestar en intentarlo y que la mayoría de los ofuscadores pueden solucionarse, ¿vale la pena su tiempo y esfuerzo?

Sería mejor invertir el tiempo en mejorar su producto para que más personas quieran usarlo.

Solo para agregar una advertencia: si va a usar ofuscación, ¡compruebe que todo siga funcionando! La ofuscación puede cambiar cosas como nombres de clase y método. Por lo tanto, si utiliza el reflection para llamar a ciertos métodos y / o clases (como en una architecture de complemento), su aplicación podría fallar después de ofuscarse. También stacktraces podría ser inútil para rastrear errores.

Si está escrito en .NET y comstackdo en CIL , se puede reflejar. Si la seguridad es una preocupación y se debe evitar la ofuscación, entonces le recomiendo que escriba su aplicación usando un lenguaje no administrado, que es, por naturaleza, más difícil de realizar ingeniería inversa.

Cómo asegurarse de que la aplicación no esté alterada, y cómo asegurarse de que el mecanismo de registro no pueda ser modificado por ingeniería inversa.

Ambos tienen la misma respuesta muy simple: no entregue el código objeto a las partes que no son de confianza, como (al parecer) sus clientes. Si es factible alojar la aplicación en sus máquinas solo depende de lo que haga.

Si no es una aplicación web , tal vez pueda permitir el inicio de sesión SSH con reenvío de X a un servidor de aplicaciones (o Conexión a Escritorio remoto , supongo, para Windows).

Si le das código objeto a las personas tipo nerdy, y creen que tu progtwig puede ser divertido de descifrar, se resquebrajará. No hay forma de evitarlo

Si no me cree, señale una aplicación de alto perfil que no se haya descifrado ni pirateado.

Si usa las llaves de hardware, encarecerá la producción y sus usuarios lo odiarán por ello. Es una verdadera puta arrastrarse por el piso enchufándose y desenchufando tus 27 dispositivos USB diferentes porque los fabricantes de software no confían en ti (me imagino).

Hay paquetes que cifrarán su EXE y lo desencriptarán cuando el usuario pueda usarlo

Por supuesto, la solución consiste en descifrar la prueba “can-I-use-it” para que siempre sea verdadera.

Un truco desagradable podría ser utilizar los valores de byte de los códigos de operación que realizan la prueba en otro lugar del progtwig de una manera sucia que hará que el progtwig falle con alta probabilidad a menos que el valor sea el correcto. Sin embargo, te vincula a una architecture particular 🙁

Solo haga una buena aplicación y codifique un sistema de protección simple. No importa qué protección elija, se invertirá … Así que no pierda demasiado tiempo / dinero.

Es imposible asegurar completamente una aplicación, lo siento.

Cuando se trata de .NET, si está liberando una aplicación de Windows Forms (o cualquier aplicación donde el cliente tenga el archivo Portable Executable), se puede descifrar.

Si desea seguir con .NET y desea minimizar la posibilidad de tener su código fuente tomado, entonces puede considerar implementarlo como una aplicación ASP.NET en un servidor web, en lugar de convertirlo en una aplicación de Windows Forms.

Francamente, a veces tenemos que ofuscar el código (por ejemplo, registrar clases de licencia, etc.). En este caso, su proyecto no es gratis. OMI, debes pagar por un buen obfucador.

Dotfuscator oculta tu código y .NET Reflector muestra un error cuando intentas descomstackrlo.

Puedo recomendar el uso de Obfuscator .