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


491

La ofuscación es unidireccional, pero no puede proteger de romper la seguridad de protección contra piratería de la aplicación. ¿Cómo me aseguro de que la aplicación no sea manipulada y cómo me aseguro de que el mecanismo de registro no pueda ser modificado?

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 toda 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.



@Andreas: ¡Esto es increíble! Voy a intentarlo ¿Alguien lo usa?
Jack

1
@ Jack es solo para aplicaciones de escaparates. No hay una línea de tiempo para las aplicaciones de escritorio (por lo que puedo decir).
Tyler Long

Si quiere nativo sin C ++ arcaico, use Delphi. La facilidad de .Net vino de Delphi de todos modos.
William Egge

Respuestas:


671

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 crackeable. Eventualmente, ese código tiene que convertirse en código de máquina nativo y cada aplicación que se puede ejecutar es vulnerable.

Lo que quieres hacer es hacer que sea lo suficientemente difícil de romper para que no valga la pena los problemas de las personas.

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

  • Ofusca tu 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 producto. Esto garantiza que solo usted pueda generar sus códigos de licencia. Incluso si su aplicación está descifrada, puede estar seguro de que no lanzarán un generador de claves para su aplicación, porque es imposible revertir el algoritmo de generación de claves.
  • Use un empaquetador de terceros para empacar su ejecutable .NET en una aplicación de envoltorio Win32 encriptada. Themida es uno de los mejores. Esto evita que las personas reflejen su aplicación en .NET Reflector y hace que sea difícil desempacar para revertir.
  • Escribe tu propio empacador personalizado . Si los empacadores de terceros son demasiado caros, considere escribir los suyos. A veces, los empacadores personalizados pueden ser muy efectivos, porque no hay métodos bien publicados sobre cómo desempaquetarlos. El tutorial Cómo escribir su propio empaquetador brinda mucha información sobre cómo escribir su propio empaquetador Win32.

Sin embargo, en última instancia, si las personas quieren que su aplicación se rompa, lo harán. Mire todo el software comercial que tiene una gran cantidad de recursos para proteger sus aplicaciones y, sin embargo, están descifrados incluso antes de que las aplicaciones se publiquen.

Un ingeniero inverso experto puede iniciar IDA-Pro y cortar su aplicación como mantequilla sin importar lo que haga. Una aplicación empaquetada se puede desempaquetar y la ofuscación solo evita que sea un paseo por el parque. Todo su arduo trabajo con su código de licencia complejo se puede deshacer con un solo parche de byte.

Solo tiene que aceptar que existe una posibilidad muy real de que las personas pirateen su software. Hay algunas personas que nunca pagarán su solicitud sin importar qué y estas son las personas de las que no necesita preocuparse.

Sin embargo, hay muchas empresas que nunca arriesgarían una demanda y comprarían felizmente licencias de software y muchos usuarios de computadoras que no quieren arriesgarse, lo encuentran mal o no son lo suficientemente expertos en 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 quiebran su software.

He pirateado mi aplicación antes, y la tomé como una afrenta personal. ¡Aquí estaba, un desarrollador de poca monta, volcando mi corazón y mi alma en una aplicación y estas personas tuvieron el descaro de piratearme! ¡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 perjudicando 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 todo este tiempo perdido fue en vano. Saqué todo el código del teléfono de casa, excepto las funciones de licencia básica y nunca miré hacia atrás.


67
Entonces +1 es casi +2. Desearía que más personas finalmente entendieran que simplemente no puedes proteger tu software contra un atacante determinado.
Bombe

102
Ha alcanzado el nirvana de protección de software: no se trata de agregar más protección, se trata de enfocarse en el producto y hacerlo tan bueno que las personas QUIERAN pagarlo. Y para aquellos que lo piratean, nunca habrían pagado de todos modos, por lo que es como si nunca hubieran existido.
Arthur Chaparyan

66
@ Arthur Chaparyan, estoy de acuerdo. Llevó mucho tiempo llegar aquí, pero finalmente he visto la luz. Seguí el camino de protecciones más restrictivas y luchando contra las galletas. Aprendí todo lo que pude sobre ingeniería inversa en un intento de evitar la mía. Finalmente descubrí la ideología correcta
mmcdole

50
Demonios, habría tenido el honor de descubrir que alguien pensó que valía la pena piratear mi software ...
Erik Forbes

10
Cuando comienzas a depender de las ventas de tu software para una gran parte de tus ingresos, esto cambia las cosas. Parece que alguien te está robando. Sin embargo, entiendo lo que estás diciendo. Me sorprendió la primera vez que encontré grietas para mi software en sitios de torrents.
mmcdole

265

No puede proteger completamente ninguna aplicación (administrada o no). Si los sistemas como Playstation y iPad pueden romperse, donde el vendedor incluso controla el hardware, ¿qué esperanza tiene su aplicación? Afortunadamente, realmente no quieres. En mi opinión, debe proteger 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 instala en una segunda máquina nueva. Querrá un buen mensaje de error para evitar llamadas de soporte adicionales, pero no pase más tiempo haciendo que sea demasiado difícil evitarlo y no golpee 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 solo pudieran retroceder el reloj del sistema. Alguien que hace eso sabe que está infringiendo su licencia, y siempre que un usuario sepa cuándo está violando, usted ya ha hecho lo suficiente.

Debe hacer esto mucho porque a los usuarios no les importa su licencia. Las licencias son cosas inventadas que a nadie le importan hasta que lo necesitan. Nadie los lee, y realmente no deberían tener que hacerlo. Por lo tanto, la mejor manera de decirle al usuario dónde están los límites es si el comportamiento listo para usar para su aplicación cumple con la licencia. En este primer caso, eso significa no instalar o instalar en modo de versión de prueba la segunda vez. Para este último, podría significar 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.

Eso explica lo que significa hacer exactamente eso. ¿Pero por qué no ir más allá? ¿Por qué no taponas cada pequeño agujero que puedes encontrar? La respuesta está en dos partes. Primero, si alguien cruza el umbral ético de romper conscientemente los términos de su licencia, incluso de una manera simple, también estará dispuesto a hacer algo más difícil o peligroso como sacar su aplicación de un torrentesitio - y existe una cierta cantidad de peligro involucrado en la ejecución de aplicaciones descargadas de fuentes no confiables. Hacerlo más difícil es solo una molestia menor para estos usuarios y los riesgos de causar problemas con sus clientes que pagan. Mantenerlo simple puede evitar que alguien profundice en su aplicación y libere una grieta más completa. En segundo lugar, tiene pocos ojos disponibles para buscar defectos; los hackers tienen muchos, y tienen más práctica para encontrarlos. Solo necesita perderse un pequeño defecto, y su aplicación tendrá la misma distribución en sitios piratas como si no hiciera nada. Tienes que tener razón cada vez; solo tienen que tener suerte una vez. Por lo tanto, 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 objetivo 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 el producto están en la computadora de un usuario que van a ser capaces de hacer con ellos lo que quieran. 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, su mejor curso de acción es involucrar a esta clase de usuarios de una manera que los utilice para su beneficio. A menudo es posible hacer que trabajen para usted en lugar de en su contra. Con eso 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 que no caduque. La diferencia entre incluso un precio de US $ 1 y gratis es enorme, si no por otra razón que el cliente no tiene que confiar en usted con su tarjeta de crédito. Una edición gratuita de su producto no solo matará efectivamente la distribución pirateada (¿por qué arriesgarse a una versión pirateada cuando puede ser legítimo por el mismo precio?), Sino que tiene el potencial de expandir dramáticamente su audiencia.

El resultado es que es posible que deba aumentar el precio de la edición de pago, de modo 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 permite ganar más dinero que si pasara mucho tiempo bloqueando su producto. Más que eso, puede involucrar a estos usuarios gratuitos y aprovechar la relación de varias maneras importantes.

Uno es el apoyo. Un pesimista aprovecharía esta oportunidad para quejarse por el aumento del costo de dar soporte a 100,000 usuarios gratuitos, pero en cambio sucede algo sorprendente: su producto se vuelve en gran medida autosuficiente. Usted ve esto todo el tiempo con grandes proyectos de código abierto que no tienen dinero para los costos de soporte. Los usuarios darán un paso adelante y lo harán posible.

Los usuarios gratuitos generalmente tienen expectativas de soporte reducidas para empezar, y por una buena razón. Todo lo que necesita hacer es marcar la edición gratuita como la única que califica para el apoyo de la comunidad y crear un foro en línea moderado por el usuario para ese propósito. Su base de conocimiento de soporte es autogenerada, y los usuarios avanzados guiarán a aquellos que necesitan una mano extra en su nombre. Aún más importante, esto le permitirá identificar y corregir errores más rápidamente, mejorando en última instancia 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 gratuitos como clientes, puede funcionar muy bien.

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

Finalmente, debes considerar el marketing. Todos estos usuarios gratuitos ahora son fanáticos en lugar de adversarios, y actuarán en consecuencia. No solo eso, sino que cuando llegue el momento de lanzar su próxima versión, todos 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 comenzará conectado con un público más amplio, altamente interesado y solidario.

Las mejores características para reservar para la edición profesional son las herramientas destinadas a facilitar la implementación y administración corporativas. Un cracker no verá esto como una razón lo suficientemente convincente como para hackearlo para su propio uso, pero para una empresa que busca comprar 300 licencias y expulsarlo en toda la compañía, esto es imprescindible. Por supuesto, la edición profesional será pirateada de todos modos, pero de nuevo: no se preocupe porque probablemente no podrá vender el producto a esos piratas sin importar lo que haya hecho, por lo que no le costará ningún ingreso.

Si bien psicológicamente puede ser difícil regalar tanto su producto, es de esperar que pueda entender cómo es realmente la mejor manera de hacerlo. No solo eso, es el único camino a largo plazo. Sé que alguien está ahí afuera pensando que no quiere hacerlo de esta manera. Después de todo, han logrado vender su producto bloqueado de $ 20 durante 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 salirse con la suya. Entonces, de repente, su precio parece escandaloso, las ventas caen drásticamente 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.


1
@Learning: creció un poco con el tiempo y pasó la conversión automática al umbral CW
Joel Coehoorn el

1
+1 Mejor que la respuesta que le di a la versión anterior de esta pregunta. @Joel No sabía que había un límite.
pipTheGeek

1
No estoy completamente de acuerdo con todo aquí, y de todos modos es un +1 fácil para la presentación y el argumento extremadamente bien pensados.
Beska el

2
Buen argumento, pero pierde un punto sobre la protección de la propiedad intelectual. Si su aplicación tiene algún código que hace algo complejo, la ofuscación puede proporcionar la diferencia entre copiar y pegar el código, y tratar de interpretar y rediseñar el código para que funcione. Esto es particularmente importante con las actualizaciones: si alguien ha copiado su código ofuscado, cuando publique una actualización, tendrá que volver a hacerlo, y como mínimo, le causará más dolor / gasto / tiempo. Si no lo tiene protegido de alguna manera, simplemente copie / pegue nuevamente y funciona.
gregmac

44
Gran publicación: realmente incluye todos los detalles correctos sobre las razones por las que no vale la pena molestarse en escribir una protección de copia compleja. Aunque la pregunta es un duplicado, vale la pena volver a abrirla solo por esta respuesta. Tal vez un mod puede fusionarlo?
EMP

45

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


38

Un secreto que compartes con mucha gente no es un secreto. Si tiene cosas secretas en su código, ofuscarlas no es una protección; solo tiene que ser desofuscado 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.


1
Por cierto, estoy haciendo un proyecto en el que quiero activar un producto "fuera de línea" también (hice un servicio WCF para activar en línea). En este caso, ¿cómo manipulará el código? me puedes dar algunos golpes?
Piyush

1
Idea interesante, pero ¿qué curso de acción recomendaría a alguien que desarrolle una aplicación que debe ejecutarse sin una conexión de datos, como un juego WP7?
Charlie Skilbeck

23

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

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

  • 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 mecanismo de protección elaborado, ya que en cualquier caso van a pagar por ello. Un mecanismo de protección complejo puede estropear 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 recurrirá al craqueo "poco ético" y solo 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 eludir su protección. Sin embargo, todo ese esfuerzo que dedique a proteger su software será rentable, dependiendo de cuán 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 que puede verse obligada a comprar su software, continúe e implemente algún tipo de protección. Piense en cuánto dinero puede ganar con 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 terceros.

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


El uso de una criptografía sólida para proteger / verificar sus licencias es completamente inútil si alguien extrae el código que cancela la aplicación si la licencia no se retira. :)
Bombe

De acuerdo, pero como decía, la protección no es para aquellos grupos de usuarios que recurrirán al uso de grietas (se supondrá que existirá).
Mystic

criptografía de clave pública = criptografía asimétrica. Creo que querías decir simétrico.
mmcdole

1
Para ser justos, el tercer punto es parcial ya que supone que una parte de las personas es siempre una minoría. Estoy bastante seguro de que bajo ciertos marcos es una clara mayoría. Tengo juegos en línea con las características multijugador masivo en cuenta porque a) la mayoría de los usuarios son niños con muy bajo normas éticas b) el costo puede ser significativo para los usuarios si se trata de una cuota mensual que arrastra desde hace meses, etc
J RIV

19

No puede evitar que las personas quiebren su software.

Sin embargo, puede hacer que creen grietas que perjudiquen menos sus ventas. Los generadores de claves 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 su algoritmo de clave de registro y eso es algo que no desea hacer a menudo porque desanimará 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 largos códigos de registro que esto genera, puede echar un vistazo a Verificación de clave parcial.

La verificación parcial de claves se asegura de que cada generador de claves ilegal funcione solo para una versión particular de su software. Básicamente, lo que debe hacer 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 exactamente son aleatorios, 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 piratas de software potenciales generalmente buscan un crack o keygen para la última versión, por lo que probablemente probarán algunos de ellos y se rendirán eventualmente.

He usado la verificación de clave parcial en mis juegos shareware más nuevos (C ++) y ha sido muy eficaz. Antes teníamos muchos problemas con los generadores de claves que no podíamos combatir. Posteriormente, hubo muchas grietas y algunos pocos generadores de claves que funcionaron solo para esa versión particular del juego, pero no hubo un generador de claves que funcionara con todas las versiones. Regularmente lanzamos actualizaciones muy pequeñas del juego y para inutilizar todas las grietas existentes anteriormente.

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


1
como la idea, también puede usar diferentes contraseñas para el cifrado asimétrico en diferentes versiones.
Priyank Bolia

Idea interesante, pero ¿cuál es exactamente el problema con un código de registro largo? Hoy en día, nadie lo ingresaría a mano de todos modos; todos lo copiarían y pegarían, por lo que si son 10 caracteres o 100 caracteres no debería haber ninguna diferencia.
EMP

44
@Evgeny: Eso solo es cierto si sus usuarios son usuarios avanzados. Hemos estado creando juegos shareware / casuales durante muchos años y puedo decirte que la mayoría de nuestros usuarios no pueden copiar y pegar. La ventana de registro incluso viene con un manual sobre cómo copiar y pegar, y algunos incluso no lo hacen después de leerlo.
Adrian Grigore

¡Guauu! OK, bueno, obviamente tienes más experiencia que yo en esto, así que no puedo discutir, solo puedo decir que estoy sorprendido. Pero yo diría que si no saben cómo copiar y pegar, entonces debe hacer que el código tenga 200 caracteres de largo, para que aprendan una habilidad informática general muy útil. :)
EMP

1
@Evgeny: Incluso con los códigos de registro cortos, todavía recibimos muchos correos electrónicos de personas que han escrito mal sus códigos y, por lo tanto, pensaron que el código no puede ser válido porque nunca cometerían un error como este varias veces en un fila. Prefiero dejar la enseñanza de TI a otras empresas ... :-)
Adrian Grigore

16
  • 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 (de modo que los crackers no puedan omitir 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 suma de verificación del archivo de la aplicación, almacene su suma de verificación de seguridad en diferentes lugares.

  • No vayas demasiado lejos en este tipo de trucos, asegúrate de que tu aplicación nunca se bloquee / entre en mal funcionamiento mientras verificas el código de registro.

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


14

Usted puede..

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

ACTUALIZACIÓN: (Divulgación: trabajo en Eazfuscator.NET) Lo que hace que el potencial de software de los servicios de Microsoft SLP sea ​​diferente es la capacidad de virtualizar el código, por lo que definitivamente puede hacerlo . Pasaron varios años desde que se hizo la pregunta originalmente; Hoy en día hay más productos disponibles que también funcionan de manera similar, como:


2
precios para mi amigo, comprar un software de licencia de Microsoft es demasiado costoso para un ISV normal
Priyank Bolia

Lo he intentado, funciona muy bien, pero solo encripta el código dentro de un método, no todo el conjunto o proyecto, por lo que un cracker puede alterar fácilmente el flujo del programa con inyección de IL
Mohsen Afshin

@ogggre Si agrega enlaces de proveedores, realmente necesita revelar sus conexiones en la publicación. También la versión actualmente disponible de SLP (que yo trabajo en: D) hace genéricos de apoyo. Naturalmente, todas las soluciones tienen sus pros y contras individuales que solo una evaluación puede contextualizar adecuadamente para las personas
Ruben Bartelink

@MohsenAfshin No entiendo lo que está diciendo: el punto es que debe proteger cualquier método en el que la adición / eliminación / cambio de IL representaría una violación de la licencia. Debido a que la virtualización de las cosas no puede ser gratuita, simplemente no tiene sentido 'protegerlo mágicamente todo' como está sugiriendo. Volviendo al punto clave: el objetivo de la Protección de SP es evitar cambios de IL en los métodos que seleccione en función de que son sensibles (además de algunos otros como ruido para evitar plantar , necesita romper este bit aquí -> firmar )
Ruben Bartelink

1
@RubenBartelink Estoy de acuerdo contigo. Lamentablemente, este hilo es demasiado grande con varias páginas de contenido. Al principio quería agregar una nueva respuesta, pero StackOverflow sugirió que es mejor extender la existente. Así que lo hice. Espero que mi pequeña información sea útil. Gracias por una actualización sobre soporte genérico en SLPS y sus correcciones.
ogggre

10

.NET Reflector solo puede abrir "código administrado", que básicamente significa "código .NET". Por lo tanto, no puede usarlo para desensamblar archivos COM DLL, C ++ nativo, código clásico de Visual Basic 6.0 , etc. La estructura del código compilado de .NET lo hace muy conveniente, portátil, reconocible, verificable, etc. .NET Reflector aprovecha esto para permitirle mirar en ensamblados compilados, pero los descompiladores y desensambladores no son específicos de .NET y han existido desde que los compiladores han existido.

Puede usar ofuscadores para hacer que el código sea más difícil de leer, pero no puede evitar exactamente que se descompile sin hacerlo ilegible para .NET. Hay un puñado de productos (generalmente costosos) que afirman "vincular" su 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, debería estar dispuesto a invertir dinero en un buen ofuscador.

Sin embargo, en mis más o menos 15 años de experiencia escribiendo código, me di cuenta de que proteger demasiado su código fuente es una pérdida de tiempo y tiene pocos beneficios. 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 variables sin sentido que inventan los descompiladores y el código de espagueti que crean los ofuscadores modernos: probablemente no tenga que preocuparse demasiado por las personas que roban su propiedad intelectual.


9

¿Realmente vale la pena? Todos los mecanismos de protección pueden romperse con suficiente determinación. Considere su mercado, precio del producto, cantidad de clientes, etc.

Si quieres algo más confiable, entonces sigue el camino de las llaves 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 hay una perfecta).

  • AntiDuplicado
  • Cambia el idioma, usa los buenos trucos que usaron los autores de Skype
  • Servidor de licencias

Y no pierdas demasiado tiempo en ello, porque los crackers tienen mucha experiencia con las técnicas típicas y están a unos pasos de ti. A menos que desee utilizar muchos recursos, probablemente cambie el lenguaje de programación (hágalo a la manera de Skype).


No olvide que es muy posible atacar la parte del software del bloqueo de hardware.
Magnus Hoff

Sí, eso es cierto, la única opción real sería tener la aplicación parcialmente implementada en hardware (alguna combinación extraña de aplicación de software-VHDL, por ejemplo). Sin embargo, esto también sería descifrable ...
Anónimo

¿Qué pasa con los dongles que implementan una estrategia de clave pública / privada? Solo la clave privada del dongle puede descifrar la aplicación y ejecutarla.
mmcdole 03 de

Eso es lo que suele hacer la llave de hardware. Pero puede atacar el dongle: clonarlo o el software responsable de hablar con el dongle (eludir, deshabilitar, etc.).
Anónimo

1
En mi caso realmente valió la pena. Después de implementar la Verificación de clave parcial y cambiar el esquema de clave de registro para un producto existente, las ventas aumentaron de manera significativa. Todo el software se puede descifrar, la pregunta es qué tan alto elevas el listón para el pirata casual del software.
Adrian Grigore

9

Si desea que las personas puedan ejecutar su código (y si no lo hace, ¿por qué lo escribió en primer lugar?), Entonces su CPU debe 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 lo son, 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 den 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 utiliza Stack Overflow, por ejemplo. Estoy bastante seguro de que Stack Overflow no ofusca su código, pero no puedes descompilarlo.

La otra forma es el modelo de dispositivo: en lugar de darles a sus usuarios su código, les da una computadora que contiene el código. Este es el modelo que utilizan 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 más mínimo error 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 ello).

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


8

Desafortunadamente, 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 descompilar 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 tienen ingeniería inversa por los hackers más persistentes (solo mire qué tan rápido se descifran los juegos en estos días). Nada protegerá su aplicación.

Al final, se parece mucho a su hogar, protéjalo lo suficientemente bien como para que sea demasiado esfuerzo (el código de espagueti ayudaría aquí) y para que el asaltante simplemente se mude a su vecino de al lado (competencia :)). Mire Windows Vista, debe haber 10 formas diferentes de descifrarlo.

Existen paquetes que cifrarán su archivo EXE y lo descifrarán cuando el usuario pueda usarlo, pero una vez más, está utilizando una solución genérica que sin duda ha sido descifrada.

Los mecanismos de activación y registro están dirigidos al 'Joe promedio': personas que no tienen suficiente conocimiento tecnológico para evitarlo (o para el caso saben que pueden evitarlo). No te molestes con las galletas, tienen demasiado tiempo libre.


1
Si realmente te molestas en subcontratar tu código de registro en un archivo dll, debes asegurarte de que la DLL tenga que ser diferente con cada nueva versión de tu software. De lo contrario, facilitará aún más que las personas descifren su software. Todo lo que tendrían que hacer es descifrar su DLL una vez y usarlo para todas las versiones posteriores. Incluso los usuarios finales podrían hacer esto una vez que encuentren una DLL agrietada vieja, y esto es aún peor que poner el mecanismo de registro en su código administrado.
Adrian Grigore

8

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

Estas son ideas:

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

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

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

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


no se puede explicar en detalle.
Priyank Bolia

7

Si. Es verdad. El código .NET es extremadamente fácil de realizar ingeniería inversa si el código no se ofusca.

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

Visual Studio incluye una versión de Dotfuscator . Dado que es una versión incluida, definitivamente no obtienes la ofuscación más fuerte posible. Si observa sus listas de funciones, verá exactamente lo que falta (y exactamente lo que hará la aplicación para hacer que su código sea más seguro).

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

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


11
No es solo "si realmente quieren ver cómo funciona su software, lo harán". Si les importa, probablemente puedan adivinar sin mirar. El 99.9% + del software no tiene ningún algoritmo mágico de polvo de duendes. La parte difícil de la programación no es una técnica secreta especial. Solo está haciendo que todas las piezas se alineen y funcionen.
Ken

99
@Ken - ¡Shhhh! No puedes dejar que el resto del mundo sepa que la mayoría de las veces no estamos usando algoritmos mágicos de polvo de duendes.
Justin Niessner

99
Justin: ¿El amor cuenta como un algoritmo mágico? El amor es lo que hace que mis programas sean especiales. No creo que puedas desmontar el amor.
Ken

Babel.NET ya no es gratis. Puede encontrar una lista de los ofuscadores más comunes (gratuitos y comerciales) aquí .
Entrada Salida

6

Bueno, no puede proteger TOTALMENTE su producto de las grietas, pero puede maximizar / mejorar los niveles de seguridad y hacer que sea un poco demasiado difícil ser rajado por los novatos y los crackers intermedios.

Pero tenga en cuenta que nada es indescifrable, solo 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 algunos crackers "no todos" rompan sus aplicaciones. Estos pasos harán que estas galletas se vuelvan locas y quizás 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 tal vez después de cada acción que realice el usuario.
  • Guarde la suma de comprobación MD5 de su aplicación lanzada en su servidor e implemente una rutina que pueda verificar la suma de comprobación del archivo actual MD5 con la real en el lado del servidor y hacer que se active aleatoriamente. Si se ha cambiado la suma de verificación MD5, significa que esta copia ha sido pirateada. Ahora puede simplemente 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) se han modificado, alterado o incluso eliminado. Lo llamo (verificación de integridad del código).
  • Utilice empacadores desconocidos gratuitos para empacar su aplicación. O, si tiene el dinero, busque soluciones comerciales como Thamida o .NET Reactor . Esas aplicaciones se actualizan regularmente y una vez que un cracker desempaqueta su aplicación, puede obtener una nueva actualización de esas compañías y una vez que obtiene la nueva actualización, simplemente empaqueta su programa y lanza una nueva actualización.
  • Publica actualizaciones regularmente y obliga a tu cliente a descargar la última actualización.
  • Finalmente haga su aplicación muy barata. No lo hagas demasiado caro. Créame, obtendrá clientes más felices y los crackers simplemente abandonarán su aplicación, porque no vale la pena su tiempo para descifrar una aplicación muy barata.

Estos son solo métodos simples para evitar que los novatos y los crackers intermedios quiebren su aplicación. Si tiene más ideas para proteger su aplicación, no dude en implementarlas. Solo hará que las crackers tengan una vida difícil, y se frustrarán, y eventualmente abandonarán su aplicación, porque simplemente no vale la pena su tiempo.

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

Ahora ve e implementa algunos juguetes para las galletas ...


5

Hay Salamandra , que es un compilador .NET nativo y enlazador de Remotesoft que se pueden implementar aplicaciones sin el marco .NET. No sé qué tan bien está a la altura de sus afirmaciones.


La respuesta es bastante fácil: es una pena, que la mayoría de las respuestas hablan de ofuscación. La ofuscación es buena para detener el primer intento (como Reflector) de buscar en su código, eso es todo. Eso no es malo. Y, por supuesto, no hay nada que detenga a los hackers reales que entienden el código de ensamblaje, además de escribir una aplicación SAAS (incluso entonces pueden intentar hackear su servidor). Pero hay más, hay herramientas como Salamander, .NET Reactor y otro mencionado, que proporcionan (tal vez) casi la misma forma de seguridad sin compilar que un Win32 .exe compilado en C ++. ¿Cuál de esas herramientas es mejor? No puedo juzgar todavía.
Philm

5

Si Microsoft pudiera encontrar una solución, no tendremos versiones pirateadas de Windows, por lo que nada es muy seguro. Aquí hay algunas preguntas similares de Stack Overflow y puede implementar su propia forma de protegerlas. Si está lanzando diferentes versiones, entonces puede adoptar diferentes técnicas para diferentes versiones, de modo que para cuando se rompa la primera, la segunda pueda asumir el control.


5

Reactor .NET

Actualizar

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

.NET Reactor proporciona protección completa para su propiedad intelectual confidencial al convertir sus ensamblados .NET en procesos no administrados que no pueden entenderse como CIL y que ninguna herramienta existente puede descompilar. 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 sus condiciones de licencia y proteger su flujo de ingresos mediante el uso de bloqueos 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.


3
Traté de contactar a esos tipos con alguna pregunta que tenía sobre su producto, pero nunca respondieron. ¿Has probado su producto? He ido con ensamblaje inteligente y tanto su producto como su soporte son muy buenos. Pero como ya dije en la pregunta, la ofuscación es unidireccional, pero no una prueba completa.
Priyank Bolia

1
Tuve algunos problemas con su producto antes y luego hice una pregunta sobre los íconos de alta resolución en groups.google.se/group/net-reactor-users y obtuve una respuesta y una solución, pero ahora parece que son difíciles de apoderarse de. Para mala - es un gran producto y sigo usarlo
loraderon

2
Si "ninguna herramienta existente puede descompilar", ¿por qué aparece como un ofuscador / empaquetador compatible en la página de características de dedot
Jared Thirsk

Probablemente porque es una declaración antigua y no han actualizado su página web. Ya no soy usuario de ninguna herramienta de ofuscación.
loraderon

de4dot es una herramienta muy poderosa. Lo he intentado contra varios ofuscadores y hace un gran trabajo. Sin embargo, no pudo manejar archivos protegidos .NET Reactor (v6.0). Tal vez de4dot no está actualizado.
Entrada Salida

4

Aquí hay una idea: podría tener un servidor alojado por su empresa al que todas las instancias de su software necesitan conectarse. Simplemente hacer que se conecten y verifiquen que una clave de registro no es suficiente, simplemente eliminarán la verificación. Además de la verificación de la clave, debe hacer que el servidor realice alguna tarea vital que el cliente no puede realizar por sí mismo, por lo que es imposible eliminarla. Esto, por supuesto, probablemente significaría mucho procesamiento pesado por parte de su servidor, pero dificultaría el robo de su software, y suponiendo que tenga un buen esquema de claves (verificar la 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.


55
¿Qué pasa si el servidor está caído o los usuarios no tienen acceso a Internet siempre? Su método simplemente frustrará a los clientes al tener tantos viajes de ida y vuelta frecuentes a los servidores de Internet solo para usar una aplicación.
Priyank Bolia

Concuerdo completamente. Es por eso que dije "esto es probablemente más invasivo de lo que quieres ..." en mi última línea. Solo estaba ofreciendo al OP la mejor solución que pensé que era técnicamente factible, no el mejor enfoque para mantener contentos a los clientes :)
rmeador

En el primer trimestre de 2010 (varios meses después de que se escribió esta respuesta), la compañía de desarrollo de juegos Ubisoft lo intentó, y aparentemente la carga en los componentes del lado del servidor fue tan grande que los juegos no se podían jugar. Impresión general del SW: "problemas de instalación, no se puede usar sin conexión, invasivo y poco confiable ". Entonces, si decide que el procesamiento del lado del servidor es el camino a seguir, asegúrese de que realmente puede escalar a la demanda.
Piskvor salió del edificio el

3

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


3

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



2

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

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

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


2

Solo para agregar una advertencia: si va a usar ofuscación, ¡verifique que todo siga funcionando! La ofuscación puede cambiar cosas como los nombres de clase y método. Entonces, si usa la reflexión para llamar a ciertos métodos y / o clases (como en una arquitectura de complemento), su aplicación podría fallar después de ofuscarse. También los seguimientos de pila pueden ser inútiles para rastrear errores.


2

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


2

Cómo asegurarse de que la aplicación no sea manipulada, y cómo asegurarse de que el mecanismo de registro no pueda ser modificado.

Ambos tienen la misma respuesta muy simple: no entregue el código objeto a terceros que no sean de confianza, como (aparentemente) sus clientes. Si es posible 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 X a un servidor de aplicaciones (o conexión de escritorio remoto , supongo, para Windows).

Si se le da el código objeto a personas de tipo nerd, y se cree que su programa podría ser divertido de la grieta, que se consigue agrietada. No hay forma de evitarlo.

Si no me cree, señale una aplicación de alto perfil que no ha sido descifrada ni pirateada.

Si utiliza las llaves de hardware, la producción será más costosa y sus usuarios lo odiarán por ello. Es una verdadera puta arrastrarse por el piso conectando y desconectando sus 27 dispositivos USB diferentes porque los fabricantes de software no confían en usted (me imagino).

Existen paquetes que cifrarán su EXE y lo descifrarán cuando el usuario pueda usarlo.

Por supuesto, la forma de evitarlo es descifrar la prueba de "puedo usarlo" para que siempre vuelva verdadero.

Un truco desagradable podría ser utilizar los valores de bytes de los códigos de operación que realizan la prueba en otro lugar del programa de una manera sucia que hará que el programa se bloquee con alta probabilidad a menos que el valor sea el correcto. Sin embargo, te vincula a una arquitectura particular :-(


No es un punto de bloqueo es fácil de depurar, y anular el código en .NET para evitar esa verificación. Además, ¿cómo va a cambiar los códigos de operación en .NET? ¿Puede explicar esto?
Priyank Bolia

Oh. Tenía en mente trucos C; digamos, tome la dirección de la función de validación, sume los 10 primeros bytes en esa matriz de caracteres (eche el puntero de la función); elija cualquier función f y almacene [la dirección de f menos la suma anterior] en fptr. Siempre llame a f como * (fptr + esa suma). Precomputar "esa suma"
Jonas Kölker

2

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


2

Cuando se trata de .NET, si está lanzando una aplicación de formularios Windows Forms (o cualquier aplicación en la que el cliente tenga el archivo ejecutable portátil), se puede descifrar.

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


2

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

Dotfuscator oculta su código y .NET Reflector muestra un error cuando intenta descompilarlo.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.