decompiladores
Alejandro Cruzado
Hace unos años que prograno en vb6.
En la actualidad intento aprender VB .NET, pero me tope
con un articulo donde explicaba entre otras cosas que .NET
compila en un lenguaje intermedio y eso hace que sea facil
su decompilacion.
En otro articulo lei que ya hay varios decompiladores
para .Net y que una de las formas de luchar contra esto
era la ofuscacion del codigo.
Realmente esto me parece algo muy peligroso, el codigo
ofuscado podra ser dificil de seguir y leer pero es codigo
al fin. Esto antenta muchisimo contra la seguridad de un
sistema y contra la propiedad intelectual del codigo
fuente.
Alguien sabe si Microsoft piensa hacer algo al respecto
para futuras versiones o no hay planeadas mejoras al
respecto.
Hasta luego y gracias por adelantado.
Fco. Javier Bedoya
No se si Microsoft pretende hacer algo al respecto, pero el VS .NET trae un
descompilador del codigo intermedio para la plataforma .NET.
Es cierto que presenta un peligro en cuanto a privacidad del codigo, pero
aumenta mucho la funcionalidad del mismo (por ejemplo, es un camino para
evitar los problemas de registros y compatibilidades de las DLL).
Y sinceramente, un programa "comercial" medio viene a tener alrededor de
1500 lineas de codigo .NET (VB o C#) (tirando por lo bajo) que en IL pueden
duplicarse facilmente.
Esto ya de por sí es engorroso de trazar, sobre todo si hay bucles, y no
contamos con la reordenacion de instrucciones. Imagínate como sería con el
codigo ofuscado y/o encriptado (existen herramientas para encriptar el
código).
Sinceramente, no creo que debamos preocuparnos, pues aunque el codigo esté
compilado a codigo nativo, siguen existiendo multitud de herramientas para
descompilarlo, por ejemplo el DEBUG de MS-DOS, hasta VB tiene
desensambladores.
Un saludo.
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:16c6601c44817$45378290$a101...@phx.gbl...
Tristan
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art21.asp
Sobre todo la "Nota acerca de la descompilación"
--
Juan Carlos Badiola
MVP - C#
anon...@discussions.microsoft.com
Se que hay programas para desensamblar progrmas de vb6.
Sin embargo esto requiere de un conocimiento mucho mas
avanzado de programación, y la seguridad se basa mucho en
el desconocimiento.
En cambio el articulo que lei en una revista y el articulo
que lei en interner dejan el codigo en c#, exactamente
igual al codigo fuente.
Si se utiliza un ofuscador el codigo es muy dificil de
leer, pero es codigo al fin.
La verdad es que no me puedo quedar tranquilo ante esta
situacón. Acepto que los programas comeciales tiene mucho
codigo, es mas, sin ofuscar da pereza seguir el codigo de
otro. Pero al margen de eso, creo que deja al programador
en una posicion muy debil.
Y si bien tengo entendido que vb6 se podia desensablar,
como dije antes, esto requiere de conocimientos mucho mas
avanzados (creo, porque por lo menos yo no los tengo).
Fuera de eso nunca vi un decompilador para vb6 que
devuelva codigo fuente tal cual fue escrito.
He leido sobre las nuevas herramientas que trae .Net,
algunas las estoy aprendiendo a utilizar; y si son
espectaculares.
Pero en la relacion costo/beneficio a mi parecer, es
negativa, ya que no es un tema menor, es seguridad y
propìedad intelectual.
Realmente estoy muy descepcionado por esto, ya que escribo
sistemas de gestión y para esto leo unas 1000 paginas por
mes entre contabilidad, gestion, programacion y bases de
datos.
El resultado de eso (bueno o malo) termina en codigo
fuente, y me pareceria muy injusto que despues de tantos
años de esfuerzo, venga alguien con un programita bajado
de internet y pueda tener mi codigo, ofuscado, no importa,
pero sigue siendo mi codigo.
Asi que sin animos de hacer polemica, simplemente esta es
mi humilde opinion, y me tiene muy preocupado, me gustaria
escuchar que Microsoft esta buscando una solucion al
respecto.
Agradeceria mucho si pudieran explicarme como es eso de la
encriptacion del codigo, con que software se logra, cual
es la seguridad que brinda, y si tiene alguna perdida de
rendimiento.
Gracias por la paciencia y hasta luego
>-----Mensaje original-----
>.
>
Alejandro Cruzado
escribir mi mail.
>-----Mensaje original-----
>.
>
Tristan
código el programa en ensamblador resultante de desensamblar una aplicación
vb6. Lo que ocurre es que en ambos casos, el código es ilegible, o muyyyy
difícilmente legible.
De todas formas, para aquellos tan obsesionados con la seguridad de su
código, ya existe un compilador a código nativo para vb.net. Pierdes
ventajas, como la seguridad del código manejado, pero posiblemente sean
cosas que te importen menos.
Dudo mucho que MS pueda hacer mucho al respecto, a parte de los ofuscadores.
¿Encriptar el código?. ¿Una desencriptación integrada en el framework?.
Ummmm, tal vez, pero sin ser un experto en seguridad, dudo mucho que se
encuentre algo seguro. La gente de Sun, y el entorno de Java no ha
encontrado otra solución en todos estos años a parte de los ofuscadores.
Alejandro Cruzado
Lo de la encriptacion lo decia en referencia a una
respuesta que dio un integrantes, entendi que habia algo
hecho al respecto, no se me ocurre proponer una cosa asi
porque se muy poco o casi nada de seguridad.
En cuanto a que estoy obsecionado con la seguridad...
si no lo niego, conozco a alguien a quien le robaron
codigo fuente y me comenta que es orrible.
Cuando digo que lo decompilado es codigo, me refiero a que
puede se dificil de leer pero ahi esta.
Si lo desensamblado quiza también lo sea, pero se me
ocurre que es mucho menor la cantidad de gente que puede
leer esto, ya que hacen falta mas conocimientos o al menos
eso me parece.
En cambio, no deben ser tan pocos los que pueda leer
codigo .Net ofuscado.
Que se yo, se me ocurre y puedo estar equivocado, pero en
fin me preocupa mucho.
Me pordias decir mas acerca de la compilacion a codigo
nativo.
Para que versiones de .Net esta disponible, se puede bajar
de algun lado.
Gracias por todo, sepan disculpar la insistencia y hasta
luego
>-----Mensaje original-----
>.
>
Tristan
e-lores
proteger tu código.
1.- Escribir pequeños fragementos de código en IL Assembler, intentando
utilizar instrucciones que no tengan equivalencia en VB.NET o C#.
2.- Utilizar componentes 'no administrados'.
3.- Utilizar WebServices.
Ernesto Lores Garrido.
Tristan
Alejandro Cruzado
He leido un par de articulos mas al respecto.
Pero no llego a comprender del todo que es y como se
escriben componentes 'no administrados'.
Alguien puede darme mas informacion al respecto.
Gracias y hasta luego.
>-----Mensaje original-----
>.
>
Alejandro Cruzado
y pinta bien.
>-----Mensaje original-----
>Este otro tiene mejor pinta, para lo que quieres.
>
>http://www.remotesoft.com/salamander/protector.html
>.
>
Fco. Javier Bedoya
Efectivamente leí en alguna parte, la diferencia entre la ofuscación y la
encriptación de código IL.
Pero no recuerdo donde lo leí.
Intentaré buscarlo de nuevo, y pondré aquí la fuente (se que fué o en :
"Como cambiar a Visual Basic .NET. Appelman [InfoBooks]. o en :
"Programacion Avanzada con Visual Basic .NET. Balena [McGraw Hill-Microsoft
Press]).
Un saludo.
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:16d6301c4482b$fbd35060$a101...@phx.gbl...
Claudio E. Desiderio
Yo todavia no trabajo con vb.net pero si es asi de facil, entonces la
pirateria de nuestras aplicaciones estaria a la orden del dia, no?
Seria muy sencillo crackear nuestros sistemas hechos con vb.net, es asi?
O sea, por mas que usemos hard locks o proteccion x soft, y mas en
latinoamerica, estariamos fundidos, no?
Saludos
Claudio
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:16c6601c44817$45378290$a101...@phx.gbl...
Pedro Luna Montalvo
VB.NET, C#, o cualquier otro lenguaje), como lo ha sido siempre hacer
reversion de aplicaciones Java.
En la mayoria de los casos, un buen diseño de la aplicacion garantizara que
la ofuscacion sera lo suficientemente efectiva como para proteger tu
propiedad intelectual, es decir, si nuestras aplicaciones exponen
componentes que no realizan propiamente el "trabajo", sino que este lo
delega a otras clases internas al proyecto, la ofuscacion de dichas clases
internas dificultaria o frustaria intentos de reversion.
Para otros casos criticos, y muy a criterio personal advierto, cuando tengo
informacion o procesos que son altamente criticos (que podrian provocar
violaciones a seguridad o poner en riesgo integridad de data), prefiero una
combinacion de codigo administrado y codigo nativo (cuando no, yo poniendo
excusas para volver a C++ :) )
Como ultima observacion, siempre sera posible hacer ingenieria inversa al
codigo....incluso al codigo nativo!! Solo que la existencia de lenguajes
intermedios entre el nativo y el lenguaje de programacion hacen que sea
menos dificil interpretar el codigo. Igual, una persona decidida
completamente a crackear el codigo, aunque este en codigo nativo, lo podra
depurar y todarse todo el tiempo que crea conveniente hasta que descubra las
intimidades de nuestros codigos.
Triste el panorama?.... hmmm....aunque un poco iluso, creo que la solucion
definitiva se concentra en una sola palabra: ETICA!!
Saludos
Pedro Luna
Gye, Ecu
"Claudio E. Desiderio" <em...@cidisoft.com> escribió en el mensaje
news:e8rnoRNS...@tk2msftngp13.phx.gbl...
Tristan
soluciones que hemos ido ofreciendo. Hay varias herramientas que generan
código nativo por lo que eso no es un problema.
Alejandro Cruzado
Dice Claudio E. Desiderio: "y mas en
latinoamerica, estariamos fundidos, no?"
Coincido plenamente, por lo menos en argentina muy poca
gente quiere pagar por trabajo intelectual. Si a eso le
agregamos la posibilidad de descompilar algo...
uff "safamo che!!!."
Creo que si bien se ha dicho varias veces que siempre
existe la posibilidad de desensamblar codigo nativo nadie
niega eso o le quedan dudas.
El problema que yo veo, y por lo cual me he puesto tan
reticente, es que la ofuscacion podra desalentar a algunos
o a muchos, pero si tenemos en cuenta que no hace falta
entender todo el codigo, sino solamente la parte donde
este la limitacion de la licencia (Fechas de vencimientos,
cantidad de ejecuciones, cantidad de usuarios, o lo que
sea), y hasta se debe poder hacer debug una vez
descompilado, podemos ver lo debil de la situacion.
Es muchisimo mas facil que desensablar codigo nativo.
A aquel que le parezca lo mismo lo felicito, y espero
algun dia saber lo que el sabe.
Es verdad que la etica es el problema de fondo, quien
puede negarlo, pero sin embargo, son muchas las empresas
que ponen limitaciones a sus sistemas.
De todas formas, bastante me tranquilizaron algunas de las
propuestas que se han dado; los sitios recomendados por
Tristan parecen ser serios y dar soluciones concretas.
Si bien no he podido bajar aun algun demo, lo que se puede
leer ahi parece proteger bastante mas que un ofuscador.
No se si este tema tiene final, pero gracias a todos por
la ayuda prestada.
Hasta luego
>-----Mensaje original-----
>.
>
Alejandro Cruzado
Tristan he leido el articulo en cuestion, ne me queda
claro si el compilador a codgo nativo ya viene en vs .net,
y si siempre es a travez de la linea de comandos.
Por otro lado, cuando habla de precompilacion dice que no
se puede compilar en la pc del desarrollador para lleverlo
despues a la pc de cliente.
Esto ultimo es un poquito engorroso para liberar
soluciones en cd, no te parece? o entendi mal?
POr otro lado alguien puede aclarame un poco mas sobre lo
que es el codigo no administrado, si se puede escribir con
vb .net, o solo con c++ .net.
Gracias y hasta luego
>-----Mensaje original-----
>.
>
e-lores
denomina código administrado. Por el contrario, el código que se ejecuta
fuera del motor de tiempo de ejecución se denomina código no administrado.
Los componentes COM, las interfaces ActiveX y las funciones de la API de
Win32 son ejemplos de código no administrado. Generalmente acostumbro a usar
C++ para generar código no administrado, pero la elección depende de ti.
Saludos.
Ernesto Lores.
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:173ee01c448ad$fda6ddd0$a101...@phx.gbl...
Alejandro Cruzado
Y la mala noticia es que en VB .Net no se pueden escribir
componentes no administrados, no?
>-----Mensaje original-----
>.
>
Fco. Javier Bedoya
Efectivamente, pero en VB6 si puedes escribir componentes no administrados.
Un saludo.
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:17e5901c4498a$6056c3f0$a101...@phx.gbl...
e-lores
inseguro (unsafe) aunque no estoy muy convencido de la diferencia entre
código inseguro y código no administrado.
Si alguien sabe más acerca de esto sería un detalle que lo explicase.
Gracias.
Ernesto Lores.
"Fco. Javier Bedoya" <javier_b...@SPAMhotmail.com> escribió en el
mensaje news:OHCKq6bS...@tk2msftngp13.phx.gbl...
Fco. Javier Bedoya
Según tengo yo entendido, el codigo inseguro es el codigo no administrado.
Ya que al estár fuera del motor de tiempo de ejecución, no puede ser
analizado y/o controlado por este.Una de las ventajas de .NET es que se
pueden definir patrones de seguridad de componentes, de forma que durante la
ejecución de una aplicación, puede decidirse si se usará o no el componente,
en función del nivel de seguridad o confianza que se le haya dado (mediante
atributos a la hora de programarlo).
Un saludo.
"e-lores" <e-l...@noesunemail.com> escribió en el mensaje
news:erkSNxfS...@tk2msftngp13.phx.gbl...
Fco. Javier Bedoya
Para cada mal, existe una solución.
Si te pones a pensar, el problema de fondo, es que se pueda descubrir las
passwords o claves de licencia a una de las aplicaciones desarrolladas en
.NET. Nada más simple de resolver, las passwords o informaciones (datos)
criticos, pueden ser encriptados con las mismas librerias .NET. Ese no es el
problema critico que yo le veo (si es que realmente existe), el problema tal
y como yo lo veo, es el poder abrir la tecnologia usada para resolver un
problema dado sin nuestro consentimiento, tecnología que es precisamente la
que hace mi programa distinto del resto.
Pero como ya se ha visto, hay soluciones para todos los gustos, formas y
maneras de pensar de cada uno y si no tiempo.
Un saludo.
"Alejandro Cruzado" <ahcr...@hotmail.com> escribió en el mensaje
news:1725601c4490a$133382a0$a601...@phx.gbl...
Tristan
verificada. Con código inseguro se permiten crear punteros, como los de C.
Pero el código inseguro sigue siendo código administrado.
Código administrado o gestionado, es aquel que se ejecuta por el CLR. O sea,
el código IL que necesita una máquina virtual para su ejecución. Por contra
tendríamos el código no administrado, o nativo, que es el que ejecuta el
procesador directamente.