[c#] Descompilador .NET
115 views
Skip to first unread message
martin.comparetto
Feb 1, 2013, 8:43:34 AM2/1/13
to Dario Quintana
Hola gente! como est�n?
Hoy me mande una macana y me puse a buscar desompiladores .NET.
Encontr� el JetBrains dotPeek y me salv� el d�a!
Ahora me pregunto, si yo pude descompilar una dll de mi aplicaci�n, pueden
robar mi c�digo?
Prob� con un ejecutable y tambi�n me deja el c�digo tal cual lo escrib�!
Realmente es fabuloso, pero... hay alguna manera de proteger mi c�digo con
VS? Usan alguna herramienta de terceros?
Como se maneja esto?
Saludos a todos!!
--
Mart�n R. Comparetto
Hoy me mande una macana y me puse a buscar desompiladores .NET.
Encontr� el JetBrains dotPeek y me salv� el d�a!
Ahora me pregunto, si yo pude descompilar una dll de mi aplicaci�n, pueden
robar mi c�digo?
Prob� con un ejecutable y tambi�n me deja el c�digo tal cual lo escrib�!
Realmente es fabuloso, pero... hay alguna manera de proteger mi c�digo con
VS? Usan alguna herramienta de terceros?
Como se maneja esto?
Saludos a todos!!
--
Mart�n R. Comparetto
Ramos, Alejandro
Feb 1, 2013, 8:52:17 AM2/1/13
to Dario Quintana
Martín,
Si, esas herramientas son tan fabulosas como peligrosas.
Afortunadamente otras herramientas que nos ayudan a ofuscar el código, una viene con la suite de VS y se llama dotfuscator.
Hay otras tanto pagas como free que nunca use, solo la que viene por defecto, sería bueno que alguien con mas experiencia nos pueda asesorar mas en detalle.
Saludos,
Alejandro
-----Mensaje original-----
De: c#@mug.org.ar [mailto:c#@mug.org.ar] En nombre de martin.comparetto
Enviado el: viernes, 01 de febrero de 2013 10:44 a.m.
Para: Ramos, Alejandro
Asunto: [c#] Descompilador .NET
Hola gente! como están?
Ahora me pregunto, si yo pude descompilar una dll de mi aplicación, pueden robar mi código?
Probé con un ejecutable y también me deja el código tal cual lo escribí!
Realmente es fabuloso, pero... hay alguna manera de proteger mi código con VS? Usan alguna herramienta de terceros?
________________________________
Los datos contenidos en el mensaje precedente pueden tener información de propiedad exclusiva de Molinos Río de la Plata S.A., sus afiliadas o subsidiarias. En virtud de ello, se otorga a éste el carácter de CONFIDENCIAL y se impone a los receptores del mismo la obligación de resguardar y proteger su difusión y de no divulgarlo sin autorización.
Asimismo, si hubiere recibido éste por error deberá comunicarlo, vía email a SeguridadI...@Molinos.com.ar ,o por fax al +54(11)43401105, y proceder a destruir el mensaje en forma inmediata.
Atte. Molinos Río de la Plata S.A.
This transmittal and/or attachments may contain confidential and proprietary information of Molinos Río de la Plata, its afiliates or subsidiaries. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited.
If you have received this transmittal and/or attachments in error, please notify us immediately by mail to SeguridadI...@Molinos.com.ar or by fax to +54(11)43401105 and destroy this message and all its attachments.
Si, esas herramientas son tan fabulosas como peligrosas.
Afortunadamente otras herramientas que nos ayudan a ofuscar el código, una viene con la suite de VS y se llama dotfuscator.
Hay otras tanto pagas como free que nunca use, solo la que viene por defecto, sería bueno que alguien con mas experiencia nos pueda asesorar mas en detalle.
Saludos,
Alejandro
-----Mensaje original-----
De: c#@mug.org.ar [mailto:c#@mug.org.ar] En nombre de martin.comparetto
Enviado el: viernes, 01 de febrero de 2013 10:44 a.m.
Para: Ramos, Alejandro
Asunto: [c#] Descompilador .NET
Hola gente! como están?
Hoy me mande una macana y me puse a buscar desompiladores .NET.
Encontré el JetBrains dotPeek y me salvó el día!
Ahora me pregunto, si yo pude descompilar una dll de mi aplicación, pueden robar mi código?
Probé con un ejecutable y también me deja el código tal cual lo escribí!
Realmente es fabuloso, pero... hay alguna manera de proteger mi código con VS? Usan alguna herramienta de terceros?
Como se maneja esto?
Saludos a todos!!
--
Martín R. Comparetto
Saludos a todos!!
--
________________________________
Los datos contenidos en el mensaje precedente pueden tener información de propiedad exclusiva de Molinos Río de la Plata S.A., sus afiliadas o subsidiarias. En virtud de ello, se otorga a éste el carácter de CONFIDENCIAL y se impone a los receptores del mismo la obligación de resguardar y proteger su difusión y de no divulgarlo sin autorización.
Asimismo, si hubiere recibido éste por error deberá comunicarlo, vía email a SeguridadI...@Molinos.com.ar ,o por fax al +54(11)43401105, y proceder a destruir el mensaje en forma inmediata.
Atte. Molinos Río de la Plata S.A.
This transmittal and/or attachments may contain confidential and proprietary information of Molinos Río de la Plata, its afiliates or subsidiaries. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited.
If you have received this transmittal and/or attachments in error, please notify us immediately by mail to SeguridadI...@Molinos.com.ar or by fax to +54(11)43401105 and destroy this message and all its attachments.
Pablo Pioli
Feb 1, 2013, 9:49:52 AM2/1/13
to Dario Quintana
En principio no hay manera 100% segura de proteger el codigo en .NET (y
en Java para el mismo efecto). Eso es inherente a la plataforma que no
compila a codigo maquina. Si queres proteger el codigo la manera mas
segura es hacer una aplicacion ASP.NET y controlar el acceso al servidor.
Lo que podes hacer ofuscar el codigo haciendolo mas dificil de leer,
pero alguien con determinacion entendera como funciona el programa
(aunque esto vale para cualquier otro lenguaje, hasta C++). Lo que podes
hacer es hacerlo mas dificil.
El tema es que tenes que balancear la seguridad con la comodidad de
mantenimiento. Por ejemplo si tenes un error y logueas el stack trace te
va a ser inentendible a menos que tengas una manera de mapearlo a los
nombres originales de las funciones. Si tenes una DLL con clases
publicas los nombres de las clases y los metodos no pueden ser alterados
porque van a afectar al consumidor de la DLL, lo que podes hacer es
mezclarlo con el ejecutable en un solo archivo pero en ese caso perdiste
la ventaja original de separar las clases en un archivo separado. Y etc.
Uno de los productos mas completos en mi opinion es
http://www.red-gate.com/products/dotnet-development/smartassembly/
Una alternativa un poco mas barata
http://www.gapotchenko.com/eazfuscator.net/download
Saludos
Pablo Pioli
en Java para el mismo efecto). Eso es inherente a la plataforma que no
compila a codigo maquina. Si queres proteger el codigo la manera mas
segura es hacer una aplicacion ASP.NET y controlar el acceso al servidor.
Lo que podes hacer ofuscar el codigo haciendolo mas dificil de leer,
pero alguien con determinacion entendera como funciona el programa
(aunque esto vale para cualquier otro lenguaje, hasta C++). Lo que podes
hacer es hacerlo mas dificil.
El tema es que tenes que balancear la seguridad con la comodidad de
mantenimiento. Por ejemplo si tenes un error y logueas el stack trace te
va a ser inentendible a menos que tengas una manera de mapearlo a los
nombres originales de las funciones. Si tenes una DLL con clases
publicas los nombres de las clases y los metodos no pueden ser alterados
porque van a afectar al consumidor de la DLL, lo que podes hacer es
mezclarlo con el ejecutable en un solo archivo pero en ese caso perdiste
la ventaja original de separar las clases en un archivo separado. Y etc.
Uno de los productos mas completos en mi opinion es
http://www.red-gate.com/products/dotnet-development/smartassembly/
Una alternativa un poco mas barata
http://www.gapotchenko.com/eazfuscator.net/download
Saludos
Pablo Pioli
Angel "Java" Lopez
Feb 1, 2013, 3:58:23 PM2/1/13
to Dario Quintana
Hola gente!
QUe recuerde, habia una opcion de recompilar el exe (luego de ya creado el
exe, desde una línea de comando de las tools de VS o algo asi), a nativo.
Pero compilaba a la arquitectura de la maquina donde se hacia eso.
Entonces, el exe quedaba en formato nativa, en lugar de formato para la VM
de .NET. Eso es lo que hace .NET cuando instala el nucleo del framework, lo
recompila a la maquina donde lo instala, para no tener que compilarlo cuando
lo carga en memoria cada vez
Era asi?
Angel "Java" Lopez
@ajlopez
QUe recuerde, habia una opcion de recompilar el exe (luego de ya creado el
exe, desde una línea de comando de las tools de VS o algo asi), a nativo.
Pero compilaba a la arquitectura de la maquina donde se hacia eso.
Entonces, el exe quedaba en formato nativa, en lugar de formato para la VM
de .NET. Eso es lo que hace .NET cuando instala el nucleo del framework, lo
recompila a la maquina donde lo instala, para no tener que compilarlo cuando
lo carga en memoria cada vez
Era asi?
Angel "Java" Lopez
@ajlopez
Pablo Pioli
Feb 1, 2013, 4:39:26 PM2/1/13
to Dario Quintana
Sí, es la utilidad NGen. Hasta donde se es muy complicado de implementar
porque la optimizacion llega a version de procesador.
En el libro CLR via C# (que no puedo dejar de recomendar fuertemente
para cualquiera que trabaje en .NET) Jeffrey Richter enumera varias
desventajas:
There are several potential problems with respect to NGen’d files:
■■ No intellectual property protection Many people believe that it might
be possible to ship
NGen’d files without shipping the files containing the original IL code,
thereby keeping their
intellectual property a secret. Unfortunately, this is not possible. At
run time, the CLR requires
access to the assembly’s metadata (for functions such as reflection and
serialization); this
requires that the assemblies that contain IL and metadata be shipped. In
addition, if the CLR
can’t use the NGen’d file for some reason (described next), the CLR
gracefully goes back to JIT
compiling the assembly’s IL code, which must be available.
■■ NGen’d files can get out of sync When the CLR loads an NGen’d file,
it compares a number
of characteristics about the previously compiled code and the current
execution environment.
If any of the characteristics don’t match, the NGen’d file cannot be
used, and the normal JIT
compiler process is used instead. Here is a partial list of
characteristics that must match:
• CLR version: This changes with patches or service packs.
• CPU type: This changes if you upgrade your processor hardware.
• Windows operating system version: This changes with a new service pack
update.
• Assembly’s identity module version ID (MVID): This changes when
recompiling.
• Referenced assembly’s version IDs: This changes when you recompile a
referenced
assembly.
• Security: This changes when you revoke permissions (such as
declarative inheritance, declarative
link-time, SkipVerification, or UnmanagedCode permissions), that were once
granted.
Pablo Pioli
porque la optimizacion llega a version de procesador.
En el libro CLR via C# (que no puedo dejar de recomendar fuertemente
para cualquiera que trabaje en .NET) Jeffrey Richter enumera varias
desventajas:
There are several potential problems with respect to NGen’d files:
■■ No intellectual property protection Many people believe that it might
be possible to ship
NGen’d files without shipping the files containing the original IL code,
thereby keeping their
intellectual property a secret. Unfortunately, this is not possible. At
run time, the CLR requires
access to the assembly’s metadata (for functions such as reflection and
serialization); this
requires that the assemblies that contain IL and metadata be shipped. In
addition, if the CLR
can’t use the NGen’d file for some reason (described next), the CLR
gracefully goes back to JIT
compiling the assembly’s IL code, which must be available.
■■ NGen’d files can get out of sync When the CLR loads an NGen’d file,
it compares a number
of characteristics about the previously compiled code and the current
execution environment.
If any of the characteristics don’t match, the NGen’d file cannot be
used, and the normal JIT
compiler process is used instead. Here is a partial list of
characteristics that must match:
• CLR version: This changes with patches or service packs.
• CPU type: This changes if you upgrade your processor hardware.
• Windows operating system version: This changes with a new service pack
update.
• Assembly’s identity module version ID (MVID): This changes when
recompiling.
• Referenced assembly’s version IDs: This changes when you recompile a
referenced
assembly.
• Security: This changes when you revoke permissions (such as
declarative inheritance, declarative
link-time, SkipVerification, or UnmanagedCode permissions), that were once
granted.
Pablo Pioli
Reply all
Reply to author
Forward
0 new messages