¿Cómo evitar que otros utilicen mi ensamblado de .Net?

Tengo un ensamblaje que no debe usar cualquier aplicación que no sea el ejecutable designado. Por favor, dame algunas instrucciones para hacerlo.

0
agregado editado
Puntos de vista: 1
agregado el autor Darren Kopp, fuente

13 Respuestas

100% completamente imposible sin saltar por algunos aros.

Una de las ventajas del uso de .NET es la capacidad de utilizar la reflexión, es decir, cargar un ensamblaje e inspeccionarlo, llamar dinámicamente a los métodos, etc. Esto es lo que hace posible la interoperabilidad entre VB.NET y F #.

Sin embargo, dado que su código está en un ensamblado administrado, cualquiera puede agregar una referencia a su código e invocar sus métodos públicos o cargarlo utilizando la reflexión y llamar a métodos privados . Incluso si 'ofusca' su código, las personas aún podrán usar el reflejo e invocar su código. Sin embargo, dado que todos los nombres estarán enmascarados, hacer cualquier cosa es prohibitivamente difícil.

Si debe enviar su código .NET de una manera que impida que otras personas lo ejecuten, es posible que pueda NGEN su binario (compilarlo en x86) y enviar esos binarios.

No conozco los detalles de su situación, pero la ofuscación debería ser lo suficientemente buena.

0
agregado
Sí, puede cargar dinámicamente una DLL no administrada y ejecutarla también; sin embargo, debe saber: la dirección de memoria del código, la cantidad/tipo de parámetros, cómo ordenar esos parámetros, etc. Llamar a un código no administrado para hacer cosas es prácticamente imposible sin tener la fuente.
agregado el autor Chris Smith, fuente
No estoy seguro de cómo eso me ayudará ... ya sea que se trate de un ensamblado .net o de un ensamblado nativo, cualquiera debería poder cargarlo correctamente ...
agregado el autor cathy, fuente

Solo requiere que se envíe un código de acceso usando una llamada a función y si no se ha autorizado, entonces nada funciona, como .setAuthorizeCode ('123456') luego, en cada lugar que se pueda usar, haga que verifique si authorizeCode! = 123456 luego arrojar un error o simplemente salir ... No parece una buena respuesta para la reutilización, pero ese es exactamente el punto.

El único momento en que podría ser utilizado es por ti y cuando codificas el código de autorización en el programa.

Solo un pensamiento, podría ser lo que estás buscando o podría inspirarte a algo mejor.

0
agregado

No estoy seguro de si esta es una vía disponible para usted, pero quizás pueda alojar el ensamblado utilizando servicios web WCF o ASP.NET y utilizar algún tipo de esquema de autenticación (LDAP, pares de claves públicas/privadas, etc.) para garantizar solo los clientes permitidos se conectan Esto mantendría su ensamblaje físicamente fuera de las manos de los demás y podrá controlar quién se conecta a él. Solo un pensamiento.

0
agregado

Puedes usar ofuscación.

Eso cambiará

int MySecretPrimeDetectionAlgorithm(int lastPrimeNumber);

En algo ilegible como:

int Asdfasdfasdfasdfasdfasdfasdf(int qwerqwerqwerqwerqwerqwer);

Otros aún podrán usar su ensamblaje, pero será difícil hacerlo razonable.

0
agregado

Puede firmar el ensamblaje y el ejecutable con la misma clave y luego marcar el constructor de las clases que desea proteger:

public class NotForAnyoneElse {
  public NotForAnyoneElse() {
    if (typeof(NotForAnyoneElse).Assembly.GetName().GetPublicKeyToken() != Assembly.GetEntryAssembly().GetName().GetPublicKeyToken()) {
      throw new SomeException(...);
    }
  }
}
0
agregado
Solo pude hacer que esto funcionara luego de convertir los tokens en una cadena, p. BitConverter.ToString (typeof (NotForAnyoneElse) .Assembly.GetN & zwnj; ame (). GetPublicKeyTo & zwnj; ken ())
agregado el autor JohnZaj, fuente
Creo que la opción InternalsVisibleTo que se menciona a continuación es mejor. Es lo mismo que esta respuesta, sin la codificación. Debe firmar los ensamblados para que InternalsVisibleTo funcione. Con ambas técnicas, otros usuarios pueden ver los métodos y llamarlos mediante la reflexión; pero ambas técnicas fallarán si el ensamblado llamante no tiene la misma clave.
agregado el autor Rob Kraft, fuente

Debería poder hacer que todo tenga un alcance interno, y luego usar InternalsVisibleTo Atributo para otorgar solo ese acceso de ensamblaje a los métodos internos.

0
agregado
¿puede vencer a la reflexión?
agregado el autor cathy, fuente

The Code Access Security attribute that @Charles Graham mentions is StrongNameIdentityPermissionAttribute

0
agregado
desde ese enlace: en .NET Framework versión 2.0 y posterior, las demandas de permisos de identidad no son efectivas si el ensamblado que llama tiene plena confianza.
agregado el autor cathy, fuente

En .Net 2.0 o superior, haga que todo sea interno, y luego use las Asambleas de amigos

http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

Esto no detendrá la reflexión. Quiero incorporar algo de la información de abajo. Si necesita evitar que alguien llame, probablemente la mejor solución sea:

  1. ILMerge el .exe y .dll
  2. ofuscar el .exe final

También puede verificar la pila de llamadas y obtener el ensamblaje para cada persona que llama y asegurarse de que estén firmadas con la misma clave que el ensamblado.

0
agregado
¿Esto vencerá el reflejo?
agregado el autor cathy, fuente
No, para vencer la reflexión, necesitas ofuscarte.
agregado el autor Rick Minerich, fuente

Es posible que pueda configurar esto en las políticas de seguridad de acceso de código en el ensamblado.

0
agregado

Como algunas personas han mencionado, use el atributo InternalsVisibleTo y marque todo como interno. Esto, por supuesto, no protegerá contra la reflexión.

One thing that hasnt been mentioned is to ilmerge your assemblies into your main .exe/.dll/whatever, this will up the barrier for entry a bit (people won't be able to see your assemby sitting on its own asking to be referenced), but wont stop the reflection route..

ACTUALIZACIÓN: Además, IIRC, ilmerge tiene una función en la que puede internalizar automáticamente los conjuntos fusionados, lo que significa que no necesita utilizar InternalsVisibleTo en absoluto

0
agregado
Irónicamente, este mismo ensamblaje se está cargando bajo demanda mediante la reflexión. Supongo que no hay una forma infalible de prevenir esto.
agregado el autor cathy, fuente

También puede consultar el uso del Netz compresor y compresor ejecutable.

Esto toma sus ensamblajes y su archivo .exe y los empaqueta en un solo ejecutable para que no sean visibles para el mundo exterior sin un poco de investigación.

Supongo que esto es suficiente para evitar el acceso de la mayoría de los programadores de .net.

Un gran beneficio del enfoque .netz es que no requiere que cambie su código. Otro beneficio es que realmente simplifica su proceso de instalación.

0
agregado

Si el ensamblado fuera un servicio web, por ejemplo, podría asegurarse de que el ejecutable designado pase un valor secreto en el mensaje SOAP.

0
agregado

Parece que estás buscando una herramienta de protección u ofuscación. Si bien no hay una bala de plata, la herramienta de protección que recomiendo es smartassembly . Algunas alternativas son Salamander Obfuscator , dotfuscator , y Xenocode .

Desafortunadamente, si le das tus bytes a alguien para que los lea ... si tienen suficiente tiempo y esfuerzo, pueden encontrar la manera de cargar y llamar a tu código. Para responder de manera preventiva a un comentario, veo que preguntas con frecuencia: Salamander evitará que tu código se cargue directamente en la herramienta Reflector, pero he tenido mejores (es decir, más confiables) experiencias con smartassembly.

Espero que esto ayude. :)

0
agregado