2009-04-30 13 views
14

¿Cómo protejo los dlls de mi proyecto de tal forma que no puedan ser referenciados y utilizados por otras personas?Cómo proteger dlls?

Gracias

Respuesta

20

La respuesta corta es que más allá de las cosas obvias, no hay mucho que pueda hacer.

Las cosas obvias que usted puede tener en cuenta (más o menos en orden de dificultad creciente y la disminución de plausibilidad) incluyen:

  • enlace estática para que no haya DLL para atacar.
  • Pela todos los símbolos.
  • Utilice un archivo .DEF y una biblioteca de importación para que solo se conozcan las exportaciones anónimas solo por sus ID de exportación.
  • Mantenga el archivo DLL en un recurso y exhíbalo en el sistema de archivos (bajo un nombre adecuadamente oscuro, tal vez incluso generado en tiempo de ejecución) solo cuando se ejecuta.
  • Oculte todas las funciones reales detrás de un método de fábrica que intercambia un secreto (mejor, prueba de conocimiento de un secreto) para una tabla de indicadores de función para los métodos reales.
  • Utiliza técnicas anti-depuración tomadas del mundo del malware para evitar la ingeniería inversa. (Tenga en cuenta que esto probablemente le proporcionará falsos positivos de las herramientas AV.)

Sin embargo, un usuario suficientemente determinado todavía puede encontrar maneras de usarlo. Un desensamblador decente proporcionará rápidamente toda la información necesaria.

Tenga en cuenta que si su DLL es realmente un objeto COM o, peor aún, un conjunto CLR, existe una gran cantidad de información del tipo de tiempo de ejecución que no puede quitarse sin romper su uso previsto.

EDIT: Puesto que usted ha reetiquetado dar a entender que C# y .NET son el medio ambiente en lugar de un puro Win32 DLL escrito en C, entonces realmente debería revisar las disposiciones precedentes para "Usted no puede, pero .. . "

Ha existido un mercado de herramientas de ofuscación durante mucho tiempo para tratar con entornos donde la entrega de fuentes compilables es obligatoria, pero no desea entregar una fuente útil. Hay productos C# que juegan en ese mercado, y parece que al menos uno ha intervenido.

Debido a que cargar un ensamblado requiere tanto esfuerzo del marco, es probable que haya bits de permiso que ejerzan algún control para proveedores honestos y consumidores de Asambleas. No he visto ninguna discusión sobre la seguridad real proporcionada por estos métodos y simplemente no sé cuán efectivos son contra un ataque determinado.

Mucho va a depender de su caso de uso. Si simplemente desea evitar el uso ocasional, probablemente pueda encontrar una solución que funcione para usted. Si desea proteger los valiosos secretos comerciales de la ingeniería inversa y la reutilización, puede que no sea tan feliz.

3

Se puede incrustar en su ejecutable, y extraer y LoadLibrary en tiempo de ejecución y ponen en ella. O puede usar algún tipo de clave compartida para cifrar/descifrar el archivo adjunto y hacer lo mismo anteriormente.

Supongo que ya ha considerado soluciones como compilarlas si realmente no desea compartirlas. Si alguien realmente quiere llegar a él, hay muchas maneras de hacerlo.

+0

En .NET los archivos exe también son ensamblados y pueden ser referenciados. –

+0

¿Cuál es la solución para esto? – Josh

+0

Desafortunadamente, esa es una solución muy fácil de eludir. Es bastante fácil deshacerse del ensamblaje de la memoria una vez que lo haya cargado, permitiendo así que cualquiera pueda usar el ensamblado "encriptado". –

5

Eche un vistazo a StrongNameIdentityPermissionAttribute. Le permitirá declarar el acceso a su ensamblaje. Combinado con una buena herramienta de protección de código (como CodeVeil (descargo de responsabilidad vendo CodeVeil)) estará bastante contento.

12

Estás enfrentando el mismo problema que los defensores de DRM.

Si su programa (que desea ser capaz de ejecutar el archivo DLL) es ejecutable por alguna cuenta de usuario y, a continuación no hay nada que pueda detener un programador suficientemente determinado que puede iniciar sesión como ese usuario de aislar el código que realiza el descifrado y usarlo para descifrar su DLL y ejecutarlo.

Por supuesto puede hacer que sea inconveniente realizar esta ingeniería inversa, y eso puede ser suficiente.

+2

+1 porque +100 no está permitido. – RBerteig

1

Bueno, podrías marcar todas sus clases "público" como "interno" o "interna protegida", entonces se marca conjuntos con [assembly: InternalsVisibleTo ("")] Atributo y nadie más que los ensamblados marcados pueden ver los contenidos.

+0

Reflection permite usar incluso tipos/miembros privados. –

+0

¿Quiere decir que, incluso si aplica el atributo InternalsVisibleTo, Reflector.Net aún puede exponer el código? – Jon

+0

Sí. Alguien también puede usar un desensamblador y ver el contenido de su atributo InternalsVisibleTo y crear un ensamblado con el mismo nombre y obtener acceso. –

1

¿Has probado .Net reactor? Recientemente lo encontré. Algunas personas dicen que es genial, pero aún lo estoy probando.