Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

05
Jun 2012
AnálisisDesarrolloOpinionesSeguridad y malwareSoftware

Consecuencias de la faclidad de la ingeniería inversa

Mi anterior entradaha quedado demasiado técnica porque no iba destinada aquí, pero en un acto reflejo pensé que podría ser útil ponerla, pero lo cierto es que para el lego, poca utilidad tiene, así que he escrito esta para explicarlo de otro modo.

Todo ello se resume en que según el modelo actual de Windows 8 para Metro, las aplicaciones instaladas en un ordenador (al menos en x86, falta ver qué trae ARM) van a ser fácilmente pirateables y copiables por terceros para aprovechar el trabajo ajeno.

Dicho esto, vamos a ser un poco más precisos.

En primer lugar, todo esto está en el aire. Es decir, que podrían ser palabras vanas el día en que salga la versión definitiva de Windows 8 x86 y x64. De todos modos estamos ante una Release Candidate, lo que quiere decir que sólo se van a reparar bugs pero no añadir ni cambiar funcionalidades. Así que si no pasa nada, es lo que tendremos.

También es muy posible que estos problemas no estén presentes en las versiones ARM, aunque está todo pendiente de qué acceso a ficheros nos van a dejar, tanto a los programadores como a los usuarios. O en otras palabras: si tenemos acceso al sistema de ficheros, el problema estará presente también en los equipos ARM.

***

Hace unos cuando años hacer programas para Windows era un tarea bastante compleja y pesada, cuando había que hacerlo todo con C y C++ (que son lenguajes de programación) usando, como mucho, alguna que otra biblioteca de soporte.

Luego vino Borland y sacó Delphi, que simplificó drásticamente el desarrollo para Windows a costa de crear programas un poco más lentos. Y Microsoft contraatacó con el Visual Basic (o quizás fue al revés, ya no me acuerdo), y el mundo cambió un poquito porque permitió que programadores no muy buenos pudieran crear programas para Windows. Podríamos decir que lo que un programador mediocre podía crear con VB/Delphi, necesitaba de uno bueno en C/C++.

Más tarde entró Java y Microsoft volvió a contraatacar con tres nuevos lenguajes que todavía facilitaban más el desarrollo para Windows, conocidos generalmente como .NET. Estamos en la época de los Frameworks, que son como un conjunto de bloques preparados para juntarlos de forma sencilla y construir aplicaciones más rápidamente.

Aparte de las ventajas en rapidez de desarrollo, estas nuevas tecnologías trajeron de la mano una serie de problemas, y es que lo que el programador creaba no quedaba perdido en el paso de la obtención de los programas finales. Con un poco de paciencia se podía obtener lo que el desarrollador había picado delante de su teclado para generar la aplicación.

Si hacemos distinción respecto a lo que nos importa, en este momento hay dos grandes grupos de lenguajes de programación: aquellos en los que es prácticamente imposible obtener el código fuente a partir del resultado final y aquellos en los que es una tarea trivial. Entre los primeros están C, C++, Delphi, y entre los segundos, C#, Java, Visual Basic .NET, con VB entre medias. Pese a que existen herramientas para desordenarlos programas, obtener el código fuente es relativamente sencillo.

Cuando decimos que un programa es nativo estamos diciendo que, cuando las herramientas de desarrollo toman el código fuente (lo que teclea el programador) y lo convierten en lo que entienden los ordenadores, el resultado es algo que éstos pueden ejecutar directamente sobre el sistema operativo sin necesidad de nada extra, y por lo tanto es código máquinapuro y duro: una serie de unos y ceros bastante difíciles de interpretar. Y dada la idiosincrasia de los compiladores modernos, matemática y entrópicamente irreversible. Estamos, de nuevo, ante Delphi, C y C++.

Cuando decimos que un programa es manejado, estamos hablando de que hay una cosa que se llama máquina virtual situada entre el programa que hemos creado y el sistema operativo. Por lo tanto, el proceso de volcar el código fuente en lo que será nuestra aplicación, en lugar de compilar a código máquina, genera una serie de instrucciones en un pseudo lenguaje máquina que, luego, la máquina virtual debe interpretar y ejecutar al vuelo.

Un ejemplo un poco burdo sería una receta médica cuando todavía se hacían a mano y los médicos tenían esa letra prácticamente indescifrable. Nuestro doctor nos la escribe en un lenguaje que sólo él y el farmacéutico entienden. Cuando tu llegas a la farmacia este último interpreta lo que ha escrito el médico y te da un medicamento. Pues bien, la receta es el pseudo lenguaje máquina, el farmacéutico la máquina virtual, y el medicamento el programa que ves en el ordenador. Y la metáfora incluso sirve para el tema de la ingeniería inversa: tu, con paciencia, puedes llegar a leer la receta.

***

Ahora entramos en el meollo del asunto. Programar en .NET es muy fácil y no requiere grandes programadores con años de experiencia. Eso no quiere decir que para programar en .NET tengas que ser un programador mediocre, y de hecho hay muchos programadores buenos trabajando en ello.

Por lo tanto Microsoft se ve envuelta en un problema muy grave en la que ella misma se ha metido, por cierto. Para desarrollar aplicaciones para un iPhone o un MAC hay que tener muchas pelotas, más o menos las mismas que para desarrollar para Windows con C ó C++ como se hacía antes y se sigue haciendo ahora, porque por ejemplo el Office de Microsoft y la mayoría de herramientas serias (léase Autocad, Mechanical Desktop, etc.) están hechos así.

Además, en cierta medida Microsoft ha perdido unas cuantas carreras en el segmento móvil. El iPhone y Android les están dando caña, y ahora el iPad también.

Por lo tanto se ven en una seria encrucijada. Si quieren tener muchos programadores que hagan muchas aplicaciones para su Windows Phone, su Metro y su Web, tienen que bajar el listón. O si queremos verlo de otra forma: cuantos más programadores mediocres sean capaces de hacer aplicaciones, más aplicaciones habrá. Y más todavía si los programadores buenos ya están cogidosen otras cosas y no ven futuro (léase dinero).

Por lo tanto, en lugar de cortar por lo sano, Microsoft se ha centrado en potenciar su .NET y extenderlo a todo lo nuevo, léase Silverlight, Windows Phone, Metro… De este modo acercan la creación de programas a muchos desarrolladores.

Y entonces viene el problema. Ya hemos dicho que .NET es fácilmente desensamblable. Eso quiere decir que la mayoría de programas .NET que hay en la calle se pueden revertir a código fuente simplemente empleando una mañana. Dependerá del tamaño del mismo, claro, pero es posible.

Por lo tanto, si accedes al sistema de ficheros de tu teléfono, de tu tableta o de tu ordenador, ahí tienes el ejecutable para desensamblarlo. Cosa que no ocurre en iOS aunque sí en Android (que ciertamente tiene el mismo problema que Microsoft, pero mientras ésta tiene que competir contra Google y Apple, Google sólo compite, de momento, contra Apple).

Pero lo peor no es eso, lo peor está en que hasta ahora, un programa .NET podía estar contenido en un solo fichero EXE o DLL. Aunque no era obligatorio, tu podías meter todos tus gráficos, menús, pantallas dentro de un solo fichero sin más.

Y quien quería ver qué había dentro, tenía que ejecutar un Reflectorpara acceder a tus gráficos y a tu código, cosa que no pasaba con el código nativo, no al menos acceder al código fuente. En general los gráficos siempre han estado disponibles sin mucho esfuerzo, pero siempre podías encriptarlos y sacarlos al vuelo.

Pues bien, con Metro tenemos otra vuelta de tuerca más hacia ese sinsentido, ya que ahora todo va suelto dentro de una carpeta. Si miráis en las capturas de la entrada anterior, veréis una mostrando gráficos como ficheros, y en otra una lista de ficheros XAML, que son la descripción de las pantallas Metro, con lo que copiando dicho fichero y haciendo un poco de magia, puedes obtener las pantallas originales del programa.

Si a eso añadimos la facilidad para obtener el código fuente de tu programa, todo el tema de firmas digitales, certificados únicos y demás se va por la borda porque, una vez has accedido al código fuente, puedes volver a generar una aplicación, reempaquetarla y volver a venderla por tu cuenta.

O quitarle la protección anti copia. O copiar un algoritmo (proceso) difícil. O lo que quieras.

Es evidente que el usuario final no está capacitado para hacer todo eso, pero sí todos los piratones que andan por ahí sueltos.

***

Una última cosa antes de terminar. No penséis que le estoy haciendo una guarrada a Microsoft contándoos todo esto. Al contrario, les estoy haciendo un favor haciéndolo público para que vean lo fácil que es, ya que cualquier piratilla de tres al cuarto está más que capacitado no sólo para saber todo esto, sino para hacer muchas más guarradas.

Es decir, no los estoy enseñando a ellos, si no a vosotros.

Por RFOG | 10 Comentarios | Enlaza esta entrada

10 Comentarios

Enviado el 05/06/2012 a las 19:14 | Permalink

En realidad da igual lo que hagan con el sistema de archivos en Windows RT, porque al ser las aplicaciones Metro comunes bastará con instalarla en un equipo con Windows 8 en vez de RT para acceder a todo.

Enviado el 05/06/2012 a las 22:16 | Permalink

Interesantes ambos artículos.

Lo que me preocupa es la asociación que haces de programar en .NET y ser mediocre. Hombre programadores mediocres hay a patadas y programando en lo que tu quieras convivo a diario con unos cuantos cuyo lenguaje de programación es incluso más oscuro que el C++, el RPG IV.

He corregido mucho, mucho código en C muy mediocremente diseñado, y he visto autenticas maravillas en Java, VB y Delphi (aka Pascal… el Pascal de toda la vida).

Yo programé mucho para Windows en C primero y en C++ después y luego bastante en Objective C para Mac, pero llegó un momento que para que el cliente (interno o externo) viese lo antes posible una maqueta maquetaba con VB y terminé por darme cuenta que lo mismo daba que aplicaciones que se fundamentaban casi siempre en el motor de base de datos (en mi caso casi siempre DB2 EEE) el lenguaje con el que realizaba el interface para el usuario fuese en el lenguaje A o B. Para lanzar SELECTs y recorrer cursores no necesitas C++, así que pasé a programar casi todo en VB y Java (menos) olvidándome del C++.

¿Me hizo eso más mediocre?… no… me hizo más productivo. Evidentemente cuando había algo que me requería capacidad de proceso fuerte (recuerdo un algoritmo para encontrar rutas optimas en una red) lo programaba en C (ni me molestaba con el C++) lo metia en una DLL y llegado el caso lo llamada desde VB.

La verdad es que luego la vida me llevó por otros derroteros y ya me da una pereza tremenda programar. Lo último que aprendí fue ObjectiveC para aprender a programar aplicaciones iPhone pero por puro hobby, pero llevo bastantes años sin programar. Pero me duele oir hablar mal de VB, producto del que fui beta tester oficial con Microsoft en su versión… agarrate los machos… 2.0.

    Enviado el 05/06/2012 a las 23:18 | Permalink

    Estoy contigo. Ya comenté una vez que no estaba de acuerdo con esta clasificación que suele hacer Rafael de la excelencia de un programador según el lenguaje en que suela programar.

    Miguel
    Enviado el 12/01/2014 a las 17:30 | Permalink

    Coincido ampliamente con vos, no se puede medir la capacidad de un programador por el lenguaje que utiliza.
    Aunque si hay que reconocer que C/C++ y Objective C hacen que el nivel y calidad del conocimiento diferencien a su poseedor del resto. 8)
    Pero siempre prima el ingenio :wink:

Quique
Enviado el 06/06/2012 a las 03:26 | Permalink

Muy interesante. Ayudan mucho la metáfora utilizada.

Yo tampoco creo que el lenguaje utilizado defina calidad del programador. Salvo que lo haga en ensamblador, ya que tengo entendido que eso si es realmente complicado.
Por cierto, ¿Cómo clasificamos quienes programa en .BAT? :)

    RFOG
    Enviado el 06/06/2012 a las 15:10 | Permalink

    ¿BATman-íacos? :-P

      Enviado el 06/06/2012 a las 17:55 | Permalink

      Yo uso WScript para los procesos del sistema… ya no uso. BAT

      Pero claro Wscript y VB es lo mismo casi. :-P

Marcus
Enviado el 06/06/2012 a las 14:59 | Permalink

A ver, no creo que debamos entender este articulo como un debate entre programadores mediocres=.NET vs. programadores decentes=C++. Creo que lo que se intenta expresar es el peligro del modelo que se ha creado para el entorno Metro. La cuestión que se intenta responder es, ¿es preferible bajar el listón de la protección del código, con tal de hacer crecer rápidamente la tienda de aplicaciones y posicionarse cuento antes en el mercado, a costa de la seguridad? El autor cree que no. Y, si lo que dice es cierto, puede que no tardemos en ver este modelo revisado…

Muchas gracias por ambos artículos, no soy programador (no era lo mío) pero me gusta estar informado de todo y creo que estos artículos sí tenían cabida en el blog.

Un saludo.

RFOG
Enviado el 06/06/2012 a las 15:25 | Permalink

Menos mal que Marcus entiende lo que quiero decir.

Me cito: «Programar en .NET es muy fácil y no requiere grandes programadores con años de experiencia. Eso no quiere decir que para programar en .NET tengas que ser un programador mediocre, y de hecho hay muchos programadores buenos trabajando en ello.»

Yo creo que con ese párrafo lo digo bien claro: Si eres un programador «delmon», en C++ poco vas a hacer porque cuando llegues a las 10.000 líneas de código ni tu mismo te vas a aclarar. Puedes ser un programador «delmon», escribir 10.000 líneas en C# y que funcione igual que funcionaría en C++. Pero para esas 10.000 líneas de C#, necesitas 50.000 en C++, y ahí es donde, si eres «delmon», es muy posible que abandones…

De nuevo reitero mi intención, y es que programar en C# no significa que seas mediocre, significa que puedes serlo. En serio, un programador mediocre dura en C++ muy poco porque es incapaz de hacer nada serio más allá de la aplicación chorra típica… y se pasa a C# o Java, en donde, siendo mediocre, puede ganarse el pan.

Y no estoy siendo peyorativo ni mucho menos, y tampoco quiero decir que C++ sea The King ni mucho menos. Claro que hay buenos programadores en C#, Java, VB… pero menos que en otros lenguajes más difíciles…

    Enviado el 06/06/2012 a las 17:58 | Permalink

    También programé mucho en emsamblador… que es solo para muy machos… pero luego hice mucho en COBOL que seguro que es lenguaje de conta les y gente de mal vivir.

    JAJAJAJA

Deja un comentario  

Tu email nunca se publica o se comparte. Los campos obligatorios están marcados con *

*
:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!:
Puedes usar las siguientes etiquetas y atributos HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)