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

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Entradas recientes

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
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)