Proteger de la descompilacion

¿En que te basas para decir que van a seguir existiendo programas dañinos?.
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?.

Juan Carlos Badiola
MVP - C#

Hola foro:

"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

¿En que te basas para decir que van a seguir existiendo

programas dañinos?.

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?.

Juan Carlos Badiola
MVP - C#


.

Bueno, has planteado muchas cosas y no tengo mucho tiempo para responderlas.
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.

Juan Carlos Badiola
MVP - C#

Hola foro:

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.

Bueno, has planteado muchas cosas y no tengo mucho tiempo

para responderlas.

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.

Juan Carlos Badiola
MVP - C#


.

Pero si es que la clave de todo es que realmente para acceder a los
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.

Juan Carlos Badiola
MVP - C#