encriptación de una aplicación.Net y ensamblajes
encryption dongle (5)
Tengo una pregunta de protección de cifrado / copia.
Estoy escribiendo una aplicación para una empresa que usa un dongle. Por favor, no me diga que la protección del software es inútil, o que debería dejarlo volar libremente en el aire, o que cada vez que paso haciendo esto es un desperdicio; esta no es una pregunta filosófica sobre la validez de la protección del software, sino más bien un cómo hacerlo.
Según tengo entendido, el primer paso para descifrar una pieza protegida de software es quitar todas las llamadas al dongle del código (es decir, parchear el ejecutable). Además, tal como lo entiendo, puedo crear ''nombres fuertes'' en .NET para proteger la aplicación y el ensamblaje, como se explica en este artículo de MSDN .
¿Es suficiente nombrar lo suficiente para garantizar que mi aplicación no pueda parchearse fácilmente? ¿O necesito usar algún tipo de biblioteca de cifrado? Si necesito usar una biblioteca, ¿cuál o dónde puedo obtener información sobre cómo configurarla?
El siguiente paso, por supuesto, es poner algoritmos importantes en el dongle. Me doy cuenta de que estos son solo golpes de velocidad para el cracker dedicado, pero a medida que crece nuestra cuota de mercado, la rampa de velocidad nos ayudará a llegar al punto en que el aguijón de la piratería no se siente tan profundamente (espero).
¡Gracias!
Al firmar su conjunto, será imposible modificarlo sin alterar la firma y, por lo tanto, su referencia. La consecuencia de esto es que una referencia (fuerte) del ensamblaje no se resolverá frente a la versión modificada. Y eso está garantizado contra probabilidades ridículas.
Eso no resuelve tu problema, sin embargo. No completamente, de todos modos. Si empaqueta sus llamadas de dongle, por ejemplo, en un ensamble con un nombre fuerte, y luego hace referencia a ese ensamblaje desde su aplicación, la aplicación no funcionará sin su ensamblaje inalterado, y por lo tanto, no sin el dongle. ¡Pero la aplicación en sí misma puede ser alterada!
Otro medio disponible para ti es la ofuscación. Hay una versión gratuita de un ofuscador incluido con Visual Studio, que se puede actualizar a la fortaleza industrial. La ofuscación hace que el código sea incomprensible sin alterar su comportamiento, y por lo tanto presenta una barrera real para la ingeniería inversa.
Yo diría que la solución está en alguna combinación inteligente de estas dos técnicas.
Y ese es el alcance de mi conocimiento, me temo. Alguien más tendrá que proporcionar la respuesta real aquí (y es embarazosamente mucho más corta que la mía ;-)
El nombramiento fuerte de la Asamblea nunca se diseñó para proteger contra un atacante que tiene el control de la máquina. Desde la entrada msdn en la demora de firma :
El siguiente ejemplo desactiva la verificación de un ensamblado llamado myAssembly.dll.
sn –Vr myAssembly.dll
El objetivo del diseño de nombres seguros es proporcionar la exclusividad del nombre y proteger al usuario (no al editor) frente a un atacante. Si el usuario desea deshabilitar todas las comprobaciones de nombres fuertes, o tal vez incluso quitar su firma y volver a firmar el ensamblaje con su propia clave, técnicamente no hay nada que le impida hacerlo.
Simplemente cargar sus ensamblajes desde un archivo cifrado tampoco es muy útil porque el código de descifrado en sí mismo no se puede encriptar y, por lo tanto, es un objetivo fácil para la ingeniería inversa.
Como lo mencionaron otros carteles, lo que está buscando es ofuscación . Probablemente ya tenga una herramienta de este tipo: Visual Studio (al menos 2005 y 2008) viene con la edición comunitaria del Dotfuscator de PreEmptive Solutions . Microsoft también tiene su propio producto " Licencias de software y servicios de protección ".
Sin embargo, la ofuscación tiene algunas desventajas técnicas:
- puede complicar tu proceso de construcción. Necesita una compilación no ofuscada y ofuscada, porque esta última no se puede depurar.
- Me gusta tener un cuadro de diálogo de error para excepciones inesperadas donde el usuario puede hacer clic en "copiar detalles" y enviarme un correo con información técnica, incluido el seguimiento de la pila. Sin embargo, con ofuscación, puede olvidarse de obtener algo útil de Exception.StackTrace .
- si su código hace uso de la reflexión, entonces hay una buena posibilidad de que las cosas se rompan en la compilación ofuscada, porque el tipo interno y los nombres de los miembros no se conservan.
Hasta cierto punto, la Ofuscación puede ser útil para usted. Pero no es una forma 100% segura. De hecho, no hay una forma 100% segura de proteger cualquier módulo de software. En el mejor de los casos, la ofuscación simplemente hace que consuma tiempo la ingeniería inversa de un programa. .NET Reflector es una herramienta de ingeniería inversa que regenera el código fuente de cualquier ensamblado .NET. Usar Dotfuscator dificultará que el intruso comprenda el código fuente original, pero uno puede esforzarse por tener una buena estimación de ese código fuente si la recompensa es grande.
Si desea usar un dongle y encriptar su programa, este artículo puede serle útil: http://www.gironsec.com/blog/2012/02/dongles-how-do-they-work/
Aquí hay una cita pertinente de ese artículo:
There are 2 ways to implement a dongle. The right way and the wrong way. The right way would be to encrypt your programs and store the encryption key on the dongle and decrypt at run time depending on whether the device is connected or not.
Si están aplicando parches a su ejecutable, un nombre fuerte no ayuda. Sin embargo, le ayudará a asegurarse de que un archivo DLL al que hace referencia es la versión correcta y no ha sido alterado.
puede consultar Salamander o preventivo para ofuscación.
Cifrado que puede ver en Assembly Lockbox , CodeVeil o ThinApp