¿Cómo puedo proteger mi código fuente de ASP.Net de mis desarrolladores?

Parece una posición extraña, pero déjame preguntarte de todos modos.¿Cómo puedo proteger mi código fuente de ASP.Net de mis desarrolladores?

He creado algunas DLL que hacen una especie de mumbo-jumbo mágico que se necesita para mostrar el contenido del sitio web que estoy creando en este momento en ASP.Net. Tengo un pequeño equipo de desarrolladores que pueden ayudarme con esto, pero me temo que robarán mi código (el DLL) y lo usarán en proyectos cuando abandonen mi empresa. En un software, probablemente pueda probar que están usando mi DLL para generar el contenido, pero en un servidor donde las DLL no están disponibles para el público, no puedo.

Así que a pesar de tener un equipo, he estado trabajando en esto solo.

Mi pregunta es. ¿Hay alguna manera que se te ocurra usar para proteger mi DLL (que va a la carpeta bin) para que mis codificadores no puedan robarla o se vuelva inutilizable si se la roban?

Solo quiero proteger lo que entra en la carpeta bin.

Fuente

2009-07-18 Cyril Gupta

Antes de elevar la confianza, interrumpe. Un desarrollador que me robó mi código y fui a un competidor me disgustó. Una vez mordido, siempre tímido. –

Debo confesar ...También he reflexionado sobre esta pregunta. +1 – Cerebrus

Puede hacer que el dll compruebe su entorno y no funcione (sugiero que lo haga dar resultados incorrectos en lugar de romper) si el entorno no se siente como en casa. También deberá ocultar el código para obstaculizar los esfuerzos para eliminar la protección.

Editar: puede usar una variable de entorno, clave de registro, existencia de un contador de rendimiento, una configuración oscura en machine.config, etc., y hacer que se vea como una configuración genuina, luego ofuscar y firmar con un nombre fuerte.

Fuente

2009-07-18 06:27:01

Hay un par de enfoques viables aquí. Pero finalmente elegí el suyo porque es el más malo. Estoy agregando algunos indicadores de compilación a mi DLL que arruinarán los cálculos si es cierto. Ahora solo debo recordar reemplazar el dll de prueba con mi dll de producción antes de subirlo. Gracias –

Esto ralentizará su velocidad, pero al final se podrá crackear: en algún lugar hay una bandera booleana en la memoria que solo necesita modificarse para que pase la verificación. – womp

Es una constante de compilación. Así que, técnicamente, creo que la DLL debería tener solo el código incorrecto compilado. –

Relacionados: https://stackoverflow.com/questions/181991/suggest-a-good-obfuscator-for-net-closed.
Es posible que desee ofuscar su código de forma selectiva (mantener las API públicas como está)

Fuente

2009-07-18 06:00:00 Cherian

Ofuscación no es mi problema. No estoy preocupado por alguien compilando mi código. Me preocupa que alguien tome esa DLL, la ponga en su carpeta bin y la use para crear un sitio web similar al mío. (Es una DLL que hace algunos cálculos especiales). ¿Cómo los detengo? ¿Cómo pruebo que están usando mi DLL en su servidor si eso sucede? –

Cyril, basado en sus comentarios, he actualizado mi respuesta. – womp

Esa es una posición extraña para estar en ... mis condolencias.

En el nivel .Net, lo mejor que puedes hacer es ofuscar tu código cuando lo construyes. Firmar firmemente su ensamblaje le permitirá saber si también está ocurriendo una manipulación.

Otro enfoque que algunas personas han tomado es escribir el código realmente sensible en C++ y compilarlo en un .dll no administrado, y llamarlo desde .net usando interoperabilidad. El bytecode de C++ es mucho más difícil de leer que IL, y esto arroja muchas más barreras para la ingeniería inversa fácil.

Editar: basado en los comentarios de la OP, aquí hay una respuesta actualizada.

Si simplemente le preocupa que roben la DLL que coloca en la carpeta bin de su servidor web, simplemente publíquela en una subcarpeta de \ bin, bloquee la carpeta con permisos de Windows, por lo que no hay forma en que pueden entrar en él, y cambiar su web.config para sondearlo.

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;bin\mysubfolder;" /> 
    </assemblyBinding> 
</runtime>

duda hará que el nombre sea fuertemente el .dll, y mantener su archivo de clave privada en un lugar seguro. Eso hace que su .dll sea identificable de forma única y que se pueda detectar si lo logran.

Fuente

2009-07-18 06:05:36 womp

Eso no responde mi pregunta. No me preocupa la ingeniería inversa. –

¿De qué otra manera crees que robarán tu código? – womp

+1 Su respuesta actualizada es muy interesante, pero ya cambié la DLL para mostrar los resultados incorrectos (que fue más fácil de implementar). Probaré su método tan pronto como pueda y le diré si tiene algún problema de seguridad. Gracias –

Esto puede no ser apropiado para su situación pero podría proporcionarles una DLL proxy que no realiza los cálculos sino que llama a su DLL.

Luego mantiene su DLL en otro servidor al que solo tiene acceso y el proxy lo llama mediante algún tipo de protocolo de comunicación remota.

Fuente

2009-07-18 06:20:37 LachlanG

Puede hacer que el dll hable con un tercero de confianza (que probablemente sería un servidor del que usted tendría control) para hacer un poco de agitar la mano para asegurarse de que se supone que se debe ejecutar.

Algo a lo largo de las líneas de

A. Hey, I'm sitting at [hostname->taken from env vars], can i do my job? 
B. (checks records of registered hosts) Yes you can. 
A. Thanks. (does what it does best)

edición: De grueso, si alguien más sabe que está haciendo esto, se podría obligar a la dirección remota a una máquina de su elección ... y en ese momento realmente no ha arreglado su problema original.

Fuente

2009-07-18 06:27:21 nilamo

Ese tipo de cosas piden un crack. Sin embargo, aún así los ralentizaría. – womp

También podría ralentizar la aplicación si los tubos son un poco lento. – nilamo

No sé mucho sobre el sistema legal en India, pero asegúrese de hacer que firme algún tipo de NDA, y dejarle en claro que lo toma en serio y lo demandará si lo violan.

Y, si es posible, solo exponga su DLL a través de un servicio de Windows o un servidor COM fuera de proceso para que pueda aislar su DLL donde no puedan acceder directamente.

Si tienen acceso físico a su DLL, y son desarrolladores medianamente competentes, entonces probablemente no hay mucho que realmente pueda hacer desde el punto de vista tecnológico para evitar que lo usen. Puedes ralentizarlos un poco, pero inevitablemente obtendrán lo que quieren si tienen acceso al binario. Negarles el acceso al binario es la única manera efectiva de prevenirlo.

Sin embargo, si la DLL procesa la entrada del usuario de cualquier manera y proporciona contenido para mostrar como resultado, puede poner algún tipo de "Huevo de Pascua" que arroje una firma distintiva de algún tipo basado en algún oscuro pero entrada específica. Dependiendo del sistema legal que pueda ser lo suficientemente bueno para abrir una investigación y obligarlos a otorgar acceso a los investigadores para demostrar que no están robando su tecnología. A menos que sepan que está allí, probablemente no lo busquen y lo desactiven antes de que tenga la oportunidad de invocarlo.

Fuente

2009-07-18 06:59:20 Gerald

Sí, han firmado una NDA. Pero una demanda legal en la India tarda década (s) en resolverse. Hubiera adoptado el enfoque de huevo de Pascua pero la DLL está hecha para usar en ASP.Net. Si lo dicen en línea en un servidor, no puedo hacer nada para llamar a las funciones. Residirá en el contenedor. Creo que mi mejor opción es no permitirles acceder a la DLL correcta. –

Sí, lo que quise decir es que si DLL procesó la entrada del usuario desde el sitio. Sin conocer la naturaleza real del código, es difícil saber si tiene sentido, pero si, por ejemplo, la entrada al archivo DLL se basa en los datos del formulario que ingresa un usuario, ese podría ser su conducto t o invocar el huevo de Pascua, si el resultado de la DLL se muestra al usuario. Pero si las demandas legales toman tanto tiempo, probablemente sea un punto discutible de todos modos, y estoy de acuerdo en que no darles acceso a la DLL correcta es probablemente la mejor opción. – Gerald

Crearía un servicio web en un servidor seguro que expondría las funciones de su dll. Una vez hecho el desarrollo, puede cambiar las partes del código que llaman al servicio web para llamar al dll directamente.

Fuente

2009-07-20 02:50:29 JBrooks

Suena como una estrategia viable, pero eso aumentaría el tiempo de retraso para los desarrolladores de mmy. Hice el dll falso (dll da resultados incorrectos), por lo que mis desarrolladores nunca saben que están trabajando con un placebo y obtendrán una desagradable sorpresa si alguna vez alguien intenta ponerlo en producción. –

Estoy de acuerdo con la estrategia de LachlanG de distribuir una DLL proxy en lugar de dar a los desarrolladores acceso a la de producción que podría ser fácilmente descifrada e invertida.

Otra opción que puede explorar es proteger su DLL de "dongle". Me tropecé con tu pregunta mientras buscaba una solución a mi problema. Estoy explorando esta opción ya que estoy en el mismo lugar pero con una solución aún más vulnerable basada en PHP.

Encontré que Keylok ofrece un producto competitivo a un precio asequible que estoy considerando. Aún no se ha visto cómo proteger las llamadas API en PHP, cuyo código no es binario ni ofuscado. No preveo ningún problema con una DLL.

Era un gerente de proyecto para una compañía que protegía su software de integración SAP con este tipo de llaves. El producto final fue un CD con el código, el manual de instalación, el dongle y una factura de licencia por $ 200k. Sweeet !!! ¡Fue hace 10 años, y aún no he oído de ninguna piratería o historias de infracción de derechos de autor de ellos!

Espero que esto ayude.

Fuente

2009-12-30 07:01:48 Machetero

¿Cómo puedo proteger mi código fuente de ASP.Net de mis desarrolladores?

Respuesta

Cuestiones relacionadas