Proteger de la descompilacion
Richard Villalón
Cesar Rivera
En mi caso utilizo aplicaciones como ildasm.exe para los
programas desarrollados en .NET y javap.exe para las
diseñadas en java, con el fin de decompilarlos.
idlasm.exe se encuentra en la carpeta "bin" del .NET
Framework. No te decompila exactamente en lenguaje VB sino
en el lenguaje "intermedio" que entiende el intérprete
de .NET. Aunque parece Assembler, es sorprendente lo fácil
que se puede entender, algo que no es conveniente. Por
ejemplo,
ldfld class [System.Windows.Forms]
System.Windows.Forms.Label Subnet.Form1::txtSubred
ldstr ""
callvirt instance void [System.Windows.Forms]
System.Windows.Forms.Control::set_Text(string)
es simplemente txtSubred.set_Text("") en J# o el
equivalente txtSubred.Text=""
Ahora, ¿como nos protegemos?, hay aplicaciones para tal
fin pero son comerciales (por ejemplo, obsfucators, creo
que así se escribe) cuya función es "envolver" el código
en un enredado juego de instrucciones que realizan la
misma función pero la salida que genera ildasm.exe es
practicamente inentendible.
Desconozco por los momentos si hay una aplicación que
realiza este proceso que sea freeware.
>-----Mensaje original-----
>.
>
Richard Villalón
tema tan en serio.
Saludos
"Cesar Rivera" <racehpN...@yahoo.com> escribió en el mensaje
news:ba5201c47987$e1798580$a501...@phx.gbl...
Angel. E. Ruiz. Pastor
Dotfuscator Community Edition viene con el VS 2003
Saludos cordiales,
Ángel Ruiz
[MS Visual Basic Developer MVP]
Caracas - Venezuela
"El conocimiento es un bien, que crece a medida que se comparte"
"Richard Villalón" <r...@cantv.net> wrote in message
news:Ou2WZGX...@TK2MSFTNGP11.phx.gbl...
Heich
DotFuscator
http://tinyurl.com/6h7sm
Saludos
--
Heich
heichito[arroba]hotmail[punto]com
Daria todo lo que se por saber la mitad de lo que ignoro.
----------------------------------------------------------
NOTA: este mensaje se proporciona TAL CUAL.
Sin ningun derecho o garantia
Guia de Netiquette:
http://www.geocities.com/heich_programmer/Netiquette.html
----------------------------------------------------------
"Richard Villalón" <r...@cantv.net> escribió en el mensaje
news:Ou2WZGX...@TK2MSFTNGP11.phx.gbl...
Alejandro Cruzado
Hay varios ofuscadores de los que elegir.
Pero la verdad es que sólo la ofuscación del código no termina de
convencerme.
Hay una empresa, www.Remotesoft.com, que tiene una herramienta llamada
Salamander Protector que parece muy buena, si te contactas podes mandarles
alguna dll o exe y te lo devuelven protegido para que puedas probarlo.
Otra aplicación que protege ejecutables de .net se llama thinstall.
Fuera de esto y de los ofuscadores no conozco otra herramienta para proteger
codigo de vb.net. Si alguien sabe algo mas, agradecido.
Hasta luego.
"Richard Villalón" <r...@cantv.net> escribió en el mensaje
news:Ou2WZGX...@TK2MSFTNGP11.phx.gbl...
Tristan
Para empezar el propio vs.net 2003 incluye un ofuscador
integrado.
Por otro lado hay muchos otros en el mercado. Lógicamente
los que mejores resultados dan, tienen mayor precio.
Además hay una solución completamente distinta. Utilizar
alguna de las herramientas que enlazan el framework con
tu aplicación, es decir algo similar a compilar a código
nativo:
Thinstall
http://thinstall.com
Remotesoft Salamander .Net Linker
http://www.remotesoft.com/linker/
Alejandro Cruzado
Una cosa más acerca de la decompilación.
Muchos desarrolladores comentan las ventajes del codigo intermedio,
gestionado, de .net.
Y quiza, aunque este codigo sea mas facil de decompilar, esten conformes con
el nivel de seguridad dado por la ofuscación.
Pero por otro lado, a algunos otros no nos parece lo sufucientemente segura
la ofuscación.
Por lo tanto, si hay empresas que comercializan herramientas diferentes a
los ofuscadores, para linkear y proteger el codigo fuente, por que Microsoft
no las incluye como una altermativa más a la ofuscación (que si ofrece).
De esta forma cada desarrollador podria elegir que tipo de ejecutable o dll
desea compilar.
La propiedad intelectual me parece un tema demasiado importante como para
que no se pueda elegir y se deba comprar una herramienta de terceros (como
Salamnder Protector o Thinstall) para compilar en algo parecido a codigo
nativo.
Esta es mi humilde opinion, gracias a todos y hasta luego.
"Richard Villalón" <r...@cantv.net> escribió en el mensaje
news:Ou2WZGX...@TK2MSFTNGP11.phx.gbl...
Richard Villalón
Si pienso mal entonces porque no le da la importancia a la descompilación
son un software dificil de descompilar?
Saludos
"Alejandro Cruzado" <ahcruzado@hotm...> escribió en el mensaje
news:%23JRf08p...@TK2MSFTNGP12.phx.gbl...
Tristan
todos.
Lo mismo habrás que decir de Sun y el resto de empresas que desarrollan
software Java, puesto que tiene exactamente el mismo problema.
¿No podría ser también por que el código nativo, aunque sea más seguro para
el programador, es menos seguro para todo lo demás?. Una de las ventajas del
código intermedio es que es verificable. Cuando todo el software de una
máquina este basado en código intermedio, será muy difícil crear código para
explotar agujeros. Compilando a código nativo esa ventaja se pierde. Además,
también se pierde la posibilidad futuro de portabilidad.
¿Que solución habrías implementado tú?.
--
Juan Carlos Badiola
MVP - C#
Alejandro Cruzado
No se si el codigo intermedio sea mejor para todos.
Aunque asi sea, ne estoy de acuerdo en que el desarrollador
se vea obligado a compilar asi.
Es como pedirle a coca cola, que para que todos lo que
tomamos su gaseosa estemos mas seguros, nos den la
formula y cada uno de los componentes con los que esta
hecha.
Mas seguro para todos?
Sistemas Crackeados van a seguir existiendo. Programas
dañinos lo mismo.Si el codigo intemedio mejora un poco
esto a expensas de entregar el codigo fuente con la
aplicación, la relacion costo beneficio es negativa.
Si la idea es esa, entonces por que Visual C++ .net si
puede hacer codigo nativo.
Tampoco me imagino el dia donde todos compilen con codigo
intermedio.
Microsoft llegaria a vender el office y demas programas en
codigo intermedio?
El poblema esta en que no se pueda elejir.
Cual es el problema con que el desarrollador pudiera
elegir en que compilar, si de todas formas, segun lo que
dicen, la mayoria utilizaria codigo intermedio
porque estan conformes con el mismo.
O el miedo es que si se da esa posibilidad nadie lo use?
Gracias a todos y hasta luego.
>-----Mensaje original-----
>.
>
Tristan
Todo el software dañino que conozco se basa en algún error de código
imposible en un entorno con recolector de basura: desbordamiento de buffer,
"dangling pointers", etc... Lamentablemente la mayor parte de software
actual está basado en C/C++, en que estos errores son muy comunes.
"Si la idea es esa, entonces por que Visual C++ .net si puede hacer codigo
nativo."
VC++.net puede crear dos tipos de código, gestionado, y no gestionado.
Cuando creas código gestionado tienes acceso a las capacidades de .net. Solo
el código gestionado tiene derecho a llamarase vc++.net, el no gestionado en
realidad es simplemente vc++, de toda la vida. NO PUEDES ACCEDER a un método
de ninguna clase .net desde código no gestionado.
Además, el código no gestionado se reconocerá como tal y su ejecución podrá
ser impedida en sistemas en los que la seguridad sea importante. Es más,
dentro del código gestionado, se puede detectar que código es seguro y cual
no.
En cuanto a la fórmula de la coca cola, como te digo hay múltiples
soluciones. ¿Has probado algún ofuscador?. ¿Has comprobado si se puede o no
descifrar el código?.
Por otro lado, si existe la solución que pides. Como ya he dicho, existen
linkers que producen "código nativo". No es exactamente código nativo, pero
probablemente si al nivel que necesitas. Lo que no tengo claro es como
funcionará esto cuando el api nativo de los nuevos OS sea .net y no win32.
¿Como enlazar las nuevas apis?.
Alejandro Cruzado
"En que te basas para decir que van a seguir existiendo
programas dañinos?."
Me baso en la idea siguiente: Podran existir nuevas
herramientas para mejorar la seguridad, como el codigo
gestionado, etc. Eso no lo discuto, pero los programas
dañinos existen porque hay programadores que desean
escribirlos.
Mientras existan estas personas, a mi criterio seguirá
existiendo codigo dañino.
Como lo haran, el tiempo lo dira...
Realmente me parece muy linda la idea de que no exista el
codigo dañino pero me suena un poco utopico.
De todas formas mi problema no pasa por ahi, no me dedico
a eso, solo hago sistemas de gestión y pretendo que nadie
lo creckee ni tenga el codigo fuente.El problema esta en
que puede ser mas seguro para el usuario, pero mas
crackeble para el desarrollador.
"Si la idea es esa, entonces por que Visual C++ .net si
puede hacer codigo nativo."
"VC++.net puede crear dos tipos de código, gestionado, y
no gestionado. Cuando creas código gestionado tienes
acceso a las capacidades de .net. Solo el código
gestionado tiene derecho a llamarase vc++.net, el no
gestionado en realidad es simplemente vc++, de toda la
vida. NO PUEDES ACCEDER a un método de ninguna clase .net
desde código no gestionado."
Justamente eso.
Visual c++ .net con derecho o sin derecho a llamarse .Net,
puede compilar codigo nativo.
No usara nada de .net, barbaro. O la parte que uses
de .net es siempre gestionado. ok perfecto.
Por que no hicieron lo mismo con vb.net. porque ecambio
mucho desde vb6? y sería mucho trabajo?.
Algunos no queremos compilar asi.
Quiza no todos le demos la misma importancia y me parece
perfecto. Pero los que pensamos de otro modo tenemos que
arreglarnos con un ofuscador?.
"Además, el código no gestionado se reconocerá como tal y
su ejecución podrá ser impedida en sistemas en los que la
seguridad sea importante. Es más, dentro del código
gestionado, se puede detectar que código es seguro y cual
no."
Ok. Aun mejor, las personas que desconfien del codigo no
gestionado, pueden evitarlo y asi, quiza mi sistema con
codigo nativo no corra es sus computadoras y yo pierda
clientes
Por lo tanto mi sistema no sería peligroso para ellos.
"¿Has probado algún ofuscador?. ¿Has comprobado si se
puede o no descifrar el código?."
Probe el DotFuscator, tambien el de remotesoft, y 3 o 4
ofuscadores no tan conocidos.
Me falta probar un tal demeanor o algo parecido. He bajado
el demo pero no le he instaldo aun.
Esto ya lo hemos hablado en otra oportunidad.
Acepto, y con ganas, ya que me interesa que esto sea bueno
para los desarroladores, que el ofuscador complica el
codigo muchisimo. Es ilegible.
Pero si hay gente (no creo que mucha) con capacidad de
desensamblar cosas que estan en codigo nativo, creo que
mucha mas gente puede crackear algo con codigo ofuscado.
"Por otro lado, si existe la solución que pides. Como ya
he dicho, existen linkers que producen "código nativo". No
es exactamente código nativo, pero probablemente si al
nivel que necesitas."
Ok esto es lo que llega a tranquilizarme.
Tengo una dll protegida con Salamander Protector que me
han devuelto del sitio de remotesoft.
Pero a lo que apuntaba en el mensaje anterior, es por qué
si existen estas herramientas, no puede microsoft
incluirlas con el .net.
Salamnder obfuscator + Protector vale casi u$s 2000.
Eso en Argentina son $6000. 12 Suledos minimos por dar
alguna referencia.
Creo que una utilidad como estas debería venir con .Net,
de la misma forma que trae dotfuscator.
Trayendo una utilidad de estas, todos estariamos conformes
y se terminaria la discución.
El tema es polemico de por si, agradezco a todos por las
ideas, a vos Tristan lo mismo.
Mi intencion no es hacer polemica con nadie, tan solo
quisiera poder decidir como compilar mi sistema.
Luego otros decidiran si lo instalan o no en sus equipos.
Gracias y hasta luego
>-----Mensaje original-----
>.
>
Tristan
Además tiene pinta de ser una de esas discusiones interminables en que cada
uno seguirá viendo las cosas igual.
"Pero si hay gente (no creo que mucha) con capacidad de desensamblar cosas
que estan en codigo nativo, creo que mucha mas gente puede crackear algo con
codigo ofuscado"
Pero como bien dices, eso tan solo es una creencia. No se si está comprobado
en la práctica. Lo que se es que continuamente se ven programas crackeados,
compilados de forma nativa. No tengo ni idea de que es más fácil de
crackear. Nunca me he dedicado a algo así.
"Algunos no queremos compilar asi. Quiza no todos le demos la misma
importancia y me parece
perfecto. Pero los que pensamos de otro modo tenemos que arreglarnos con un
ofuscador?."
No, los que pensais así podeis seguir utilizando vb6. Nadie os lo va a
impedir. Además sigue y seguirán existiendo herramientas de desarrollo de
otras empresas. Tampoco os va a impedir nadie utilizarlas. Microsoft tan
solo ha seguido su camino, el que le parece más conveniente. Muchos opinamos
que ya era hora de un cambio así (yo odiaba vb6), otros opinan que no. Por
eso seguirá habiendo muchas opciones, para responder a los gustos y
necesidades. Utiliza lo que te parezca más conveniente.
Además no olvides que vs.net si incluye algo para crear código nativo, VC++.
No es cierto que no hayan incluido algo así. Tan solo es que vb.net está
completamente basado en .net. Para crear un formulario con VC++ y código no
gestionado, hay que seguir utilizando las apis win32 o las librerías MFC. No
creo que tuviese ningún sentido utilizar vb.net de esa forma. ¿Tu crees que
lo utilizarías?.
"Pero a lo que apuntaba en el mensaje anterior, es por qué si existen estas
herramientas, no puede microsoft incluirlas con el .net. Salamnder
obfuscator + Protector vale casi u$s 2000."
Bueno, esa me parece una buena razón por la que MS no lo ha incluido. Es un
software caro, que requiere muchas horas/hombre. Creo que solo responde a
necesidades concretas de unos cuantos. Ten en cuenta que igual que
RemoteSoft cobra por él, Microsoft tendría que hacerlo. A Microsoft no le
sale gratis desarrollar, le costará más o menos lo mismo que a RemoteSoft.
De todas formas, yo creo que sería una mala idea incluir algo así en vs.net.
Es prácticamente acabar con todas las ventajas de .net. Como se dice en mi
tierra, para ese viaje no hacian falta alforjas. Es mucho más complejo crear
un entorno como .net que haber hecho algo nativo desde el principio. Como
digo, algunos creemos que esa complejidad es para bien, otros que no.
Cuestión de gustos. Sigue el tuyo propio.
Alejandro Cruzado
Tristan como decís esta discusión es interminable, no
concuerdo con vos
en lo que ya venimos discutiendo, en cuanto al resto, de
lo que escribiste
en el ultimo mensaje, concuerdo en varias cosas.
"No, los que pensais así podeis seguir utilizando vb6.
Nadie os lo va a
impedir. Además sigue y seguirán existiendo herramientas
de desarrollo de
otras empresas. Tampoco os va a impedir nadie utilizarlas.
Microsoft tan
solo ha seguido su camino, el que le parece más
conveniente. Muchos opinamos
que ya era hora de un cambio así (yo odiaba vb6), otros
opinan que no. Por
eso seguirá habiendo muchas opciones, para responder a los
gustos y
necesidades. Utiliza lo que te parezca más conveniente."
Eso es verdad, puedo seguir utilizando vb6 y quiza es lo
que haga en el corto
plazo. Pero como sabrás, hay que tratar de estar al día
con las cosas nuevas.
Llegara el momento donde vb6 no pueda conectarse a alguna
versión de SqlServer,
tenga problemas con algún futuro sistema operativo, etc.
Lo que sucede con el tema de vb.net, por que se da esta
discusión, es que
los que pensamos así, y nos hacemos este drama, es porque
queremos usar esta plataforma.
Es que realmente esta buena y tiene cambios asombrosos. Y
perder todo
esto (en el caso de que uno decida dejar de usarla) por no
poder compilar en código nativo
es una lastima.
"Pero a lo que apuntaba en el mensaje anterior, es por qué
si existen estas
herramientas, no puede Microsoft incluirlas con el .net.
Salamnder
obfuscator + Protector vale casi u$s 2000."
"Bueno, esa me parece una buena razón por la que MS no lo
ha incluido. Es un
software caro, que requiere muchas horas/hombre. Creo que
solo responde a
necesidades concretas de unos cuantos. Ten en cuenta que
igual que
RemoteSoft cobra por él, Microsoft tendría que hacerlo. A
Microsoft no le
sale gratis desarrollar, le costará más o menos lo mismo
que a RemoteSoft."
Si bien debe tener un costo para Microsoft, no creo que
sea el mismo,
No tengo la menor idea del tamaña de Remotesoft, pero
Microsoft es la empresa de
software mas grande del mundo, supongo que tiene otra
estructura, experiencia, etc.
Mas allá de esto, que debe ser imposible saberlo, sigue
siendo mi expectativa,
que Microsoft incluya una herramientas de estas en .net,
ya que el poder de negociación de
Microsoft es mayor que el de los que tenemos"necesidades
concretas de unos cuantos".
"De todas formas, yo creo que sería una mala idea incluir
algo así en vs.net.
Es prácticamente acabar con todas las ventajas de .net.
Como se dice en mi
tierra, para ese viaje no hacían falta alforjas. Es mucho
más complejo crear
un entorno como .net que haber hecho algo nativo desde el
principio. Como
digo, algunos creemos que esa complejidad es para bien,
otros que no.
Cuestión de gustos. Sigue el tuyo propio."
Por que te parece que es "acabar con todas las ventajas
de .net", si solo
unos pocos compilaríamos en código nativo.
O por el contrario, si te parece que muchos?
tantos dejarían de usar el código gestionado?
Si tantos dejarían de usarlo? es tan bueno?
A la larga, creo, que si no lo incluyen, terminare
comprando algo de esto.
Ya que .net me gusta bastante, y creo que migrar todo a
C++ lleva un tiempo mucho mayor.
Bueno en este tema creo, que nunca estaremos de acuerdo,
así que espero a que salga algún otro
par poder cambiar ideas sin discutir tanto.
Saludos a todos y gracias.
>-----Mensaje original-----
>.
>
Tristan
recursoso que aporta .net, se debe compilar a código intermedio.
¿Podría haberse hecho de otra forma?. Muy relativamente. No veo como podría
transmitirse la herencia tal y como se transmite entre lenguajes si la
compilación fuese nativa. Algo así como COM, pero de hecho ni COM ni Corba
admiten herencia de implementación, no debe ser sencillo. Tampoco veo como
podría funcionar reflection. Hay varias cosas que creo que no serían
posibles con compilación nativa. Habría que crear por tanto dos plataformas
completamente independientes.
Por otro lado esos linkers que producen "código nativo", en realidad no
hacen tal cosa. Tan solo enlazan las librerías de .net necesarias para la
ejecución del código, en lugar de depender del framework. Esto permite un
mayor de grado de ofuscación, pero poco más. El código sigue siendo IL.
En resumen, lo que quiero decir es que sería IMPOSIBLE crear algo como .net
basado en código nativo. Como te digo vc++.net compila a código nativo
aquellas cosas que no son .net y que no acceden a ninguna de las capacidades
de .net.
Alejandro Cruzado
Ok. No se si se podria havbr hecho de otra forma.
Pero seguimos con lo mismo, fijate que una herramienta
externa protege el codigo.
Esta discusión se torno tan infinita, que creo que voy a
terminar comprando el salamnder para no tener que hacerme
mas drama.
Saludos
>-----Mensaje original-----
>.
>
Alejandro Cruzado
Tristan sigo con el tema, pero no con la discusión que ya
se puso aburrida.
En la página de remotesoft hay dos herramientas.
Un Linker y Salamander Protector.
Por lo poco que explica la página no parecen hacer lo
mismo.
l linkeador junta librerias.
No tengo claro si protector linkea algo. La dll que tengo
protegida con esa utilidad era de juguete, creo que le
puse solo dos propiedades, no ocupaba casi nada de
espacio, tendría que fijarme, pero creo que ocupaba 6 k,
pero una vez protegida no crecio casi nada.
Tenes conocimiento de lo que hace Protector, si linkea
algo?
Saludos
>-----Mensaje original-----
>.
>
Tristan
necesidad de ocultar mi código. Peor intentaré ayudarte.
Creo que ambas herramientas son completamente distintas:
Por lo que puedo entender, Protector, compila a código nativo el código del
método, pero mantiene la declaración en IL. No enlaza ninguna librería. Lo
que hace es proteger el código, pero sin eliminar la necesidad del
framework. Entiendo que es la solución que necesitas.
Por el contrario, .NET Linker, lo que hace es enlazar las librerías
necesarias del framework en un paquete. De esta forma se evita la necesidada
de tener instaladoi el framework, pero creo que no hace ofuscación. Pero si
parece dificultar mucho la descompilación, sobre todo si se usda en
combinación con Protector.
Tristan
muy buena pinta:
Alejandro Cruzado
tristan te comento que a thinstall lo he porbado.
He bajado la demo, pareciera ser muy bueno.
Lo que no me quedo claro, ya que no he tenido todo el
tiempo para probarlo, y yua se me vencio la demos, es si
protege dlls.
Me parece que solo las protege si permites que se linkee
dentro del ejecutable.
De todas formas, pareciera ser muy bueno, es una
alternativa más.
Habra alguna herramienta mas de estas por ahi?
Alguien conoce alguna mas?
Saludos
>-----Mensaje original-----
>.
>
Alejandro Cruzado
Gracias y saludos
>-----Mensaje original-----
>.
>
Paulo Conde
--
Saludos
Paulo G. Conde M.
+58-416-4721293
+58-273-5412395
paulo...@hotmail.NO_SPAM.com
Barinas, Venezuela
Jonathan Clark
> se puso aburrida.
> En la p gina de remotesoft hay dos herramientas.
> Un Linker y Salamander Protector.
Tambien, esto hace un archivo de EXE para .NET:
http://thinstall.com/help/_netsupport.htm