Proyecto: Hammerfest II: CWS2FWS/Flasm, Apache... modificando lo que se desee

ATENCIÓN!! Como siempre, no me hago responsable del uso que se le puedan dar a las palabras... letras que aquí expongo. De principio a fin, y como sabéis todos siempre me he limitado a dar información y escribir conocimientos. Mi objetivo no persigue en modo alguno utilizar nada de forma inmoral ni por supuesto ilegal. Tanto Hammerfest como MotionTwin son marcas registradas, si hago un mal uso por error de cualquiera de su contenido, invito a los que tengan derecho sobre ello que me lo comuniquen y en paz. No soy un Jurista ni pretendo serlo, ni tampoco estoy de acuerdo con los Cheats (trampas).


Introducción:


Antes de comenzar... para quien sea capaz de leerse todo, tendrá desde luego con eso mi gran admiración... comprendo que es algo largo, pero creo que merece la pena.

Y para quien quiera esta entrada en formato PDF:

AQUI (descomprimir y listo)

Creo que no tiene ningún sentido que nos pongamos a discutir ahora sobre la intencionalidad o no de esta entrada, así como si debo publicar contenidos de este tipo o no debo de hacerlo. Todo ello creo que quedó completamente claro en mi primera entrada al respecto y sobradamente en los comentarios de esta. Posiblemente aparezcan de nuevo detractores y defensores... así que supongo que mejor evitar lo mismo, pero como he dicho siempre cada cual es libre de dar su opinión.

Al igual que hiciese con anterioridad, voy a intentar copiar el formato de la entrada anterior, intentando mantener los mismos puntos y seguir un orden. En este caso nos vamos a topar con el problema de los derechos de autor, los creadores del juego. Por razones claras, no puedo publicar nada que crea que pueda estar protegido por ellos, con lo que si llega el caso, no os podré poner literales, y quien quiera saber más tendrá que seguir estas letras a la par que va aprendiendo. De todos modos espero que sea lo menos posible.

Que es lo que vamos a aprender aquí? de que vamos a hablar? Bueno... en este caso vamos a aprender cómo se puede estudiar un juego/app flash a fondo, la cantidad de información que podemos obtener de este y de cómo podemos usarla!! Una vez que entendemos esto, veremos cómo podemos "engañar" servidores externos, como podemos descompilar y volver a compilar un objeto flash, como se manejan los archivos temporales del navegador, como se interactúa con contenidos flash.... etc etc etc. Y para quien se dedique o se quiera dedicar a la creación de contenidos de este tipo, pautas para mejorar la seguridad, entre otras cosas. Pondremos de ejemplos en este caso no solo a editar unos puntos, sino ser capaces de modificar virtualmente lo que deseemos de Hammerfest o de cualquier aplicación/juego flash que deseemos. Por simplicidad empezaremos a ver cómo podríamos modificar la rareza de algunos objetos, y podríamos acabar haciendo para que apareciese literalmente el objeto que deseásemos. Si tenemos tiempo, o quizás en otra entrada, veremos lo fácil que resultaría teletransportarse entre niveles



Como se aborda un problema II

En la primera parte nos hacíamos una serie de preguntas a las que fuimos contestando más o menos. Aprendimos a grandes rasgos como funciona internet, que información recibimos, que información enviamos... así como se tratan los contenidos interactivos de estos. Siempre tomamos la misma premisa, que cualquier contenido con el que interactuamos de forma activa desde nuestro PC, de un modo u otro está en nuestro PC, y por ello podemos modificarlo a voluntad si sabemos el qué, el cómo y el dónde. Pero a diferencia de lo que hicimos en primer lugar en el que modificábamos al vuelo el juego, en el que modificábamos (por así decirlo) el comportamiento de este, en este caso no es lo que vamos a hacer.

Es posiblemente una idea que se ha podido plantear alguno... como hemos dicho aquí lo importante no es saber hacer algo o no saber hacerlo, eso se aprende, se piensa se estudia... lo importante es preguntarse el cómo, pensar una medida de "ataque". Y en esta ocasión, según aprendimos en la primera parte, vamos a hacernos otro razonamiento:

Sabemos que podemos modificar lo que sea que se encuentre en nuestro PC. Sabemos que el juego se ejecuta en nuestro PC y por ello pudimos modificar el comportamiento de este. Pero... si el juego se ejecuta en nuestro PC, significa que antes de que se ejecute en nuestro navegador (por así decirlo) se encuentra ya en este, y si esto es así... ¿podría modificarlo ANTES de que este se ejecute?

Todo tiene ventajas e inconvenientes, claro está. Una modificación "al vuelo" de cualquier juego/programa explicada en la primera parte suele ser algo mucho más fácil de hacer. Esto tiene sentido, un programa en ejecución se encuentra en memoria sí o sí como hemos dicho ya, para que el procesador pueda ir ejecutando instrucción a instrucción. Conocer las instrucciones que se están ejecutando es muy fácil, tan solo hay que saber ensamblador e interpretarlas o mirar un simple listado en inet de ellas. Aunque se suelen implementar todo tipo de medidas de protección para que una persona curiosa le dé por mirar en la memoria, como ya hicimos, se suelen poner muchísimas más medidas en el programa que aun no se está ejecutando. Nosotros en la primera parte simplemente con lógica logramos sortear la escasa "seguridad" que tenía MT en el juego una vez que este se ejecutaba. Es cierto que usaba algún que otro método de protección, pero poco más, con paciencia y buen tino es suficiente.

La modificación en disco es algo que suele ser más complejo, y en nuestro caso el problema se complicará por razones que veremos más adelante. Modificar es más fácil, pero no lo es interpretar lo que se está modificando. Algo que está en memoria suele estar ya "limpio", desencriptado, descomprimido... casi con una secuencia lógica, listo para ser ejecutado el código por el procesador. En cambio cuando algo está en disco, lo normal es que esté "empaquetado", encriptado, ensamblado... y solo una vez realizado el proceso inverso se podrá "atacar" el código directamente. La ventaja es que es más fácil obtener un control mucho más amplio de lo que se desea hacer.

Nuestro punto de partida por lo tanto será, como alguno habrá adivinado ya, la edición directa en disco. Pero para poder hacer esto tendremos q ir sorteando una a una las protecciones o las complicaciones que nos podamos ir encontrando. Nos centraremos en cada una de ellas a lo largo de esta lectura. Lo primero que necesitamos saber como hicimos la primera vez será el Dónde, ya que tenemos el Cómo lo vamos a hacer. Y al igual que nos ocurrió antes, nos toparemos con caminos que no nos llevan a ninguna parte y que tendremos que replantearnos de nuevo para llegar al fin.



¿Dónde?

Podemos localizar a grandes rasgos tres problemas fundamentales. El primero es que información es la que debemos editar, donde se encuentra. El segundo, como interpretar dicha información. Y por último como hacer que dicha información pase por legítima, por así decirlo. Luego en este punto vamos a tratar de resolver el primer problema. Que queremos modificar, como localizarlo, donde se encuentra... para poder pasar más adelante al cómo interpretar dichos datos, cómo modificarlos y para terminar cómo "montarlos"

En la primera parte, el planteamiento que nos hacíamos era que al estar en ejecución cualquier aplicación flash, esta debía de estar ejecutándose en algún lugar de nuestro PC. Aquí el planteamiento es el mismo, si se está ejecutando en nuestro PC es que antes ha tenido que pasar por nuestro HDD (Disco Duro) casi con toda probabilidad. Bueno... podría haber pasado directamente a memoria, pero esto no es así, y ahora vamos a explicar por qué, y vamos a hacer un paréntesis para explicar cómo funciona otro rasgo importante de cualquier navegador: El Caché. Pero aun cuando pasase a memoria directamente, explicaremos además como se podría aun así interceptar dichos datos. A fin de cuenta ahora mismo no nos estamos planteando como editar, que interpretar o que... ahora mismo tan solo nos interesa echarle el guante a la aplicación flash en cuestión, ya nos preocuparemos del resto más adelante.


¿Que es el caché?

El caché en los navegadores es un espacio reservado del HDD de cada uno que se encarga de mantener los datos más visitados, más recientes, más importantes... con la idea de que si se vuelve a solicitar una web que estuviese íntegramente en caché, se cargaría al instante. Evidentemente serían datos no actualizados, dado que los datos mostrados vendrían desde nuestro HDD, y no desde el servidor remoto. Normalmente no se guarda una página entera ni muchísimo menos, a veces son solo imágenes, otras veces código.. Cada navegador implementa el caché de forma diferente, y también depende de los ajustes de cada persona. Dado que normalmente la navegación se realiza por los mismos sitios, si mantenemos en caché imágenes que son estáticas con el tiempo y contenidos similares, nuestro navegador no tendrá que ir descargando una y otra vez el mismo contenido cada vez que se visita, y a lo mejor tan solo descargará de nuevo aquel contenido que podamos definir como "dinámico". Por ejemplo, un contenido estático sería el logotipo de una empresa, que al visitar una web siempre fuera el mismo en el mismo sitio incluso con el paso de meses y años. Ese tipo de imágenes mantenidas en el caché harían que esa imagen no se descargase frecuentemente, siempre usaría la misma desde el HDD del PC, ahorrando el tiempo de carga de la misma y ancho de banda. Por el contrario un ejemplo de contenido dinámico sería una web en la que retransmiten un partido de futbol, y que se actualiza a lo mejor cada 30 segundos. Ese contenido no tiene cabida en el caché, dado que el contenido que deseamos es siempre nuevo!! Y si usásemos caché para este tipo de contenido lo que se nos mostraría en el navegador sería siempre datos no actualizados.

¿Qué importancia tiene esto en los objetos flash? Muchísima!! y la mayoría de todos vosotros alguna vez en algún momento se ha planteado esto aunque sin darse cuenta con los videos de YouTube u otros, que son videos flv, usando el mismo principio que aquí mencionamos. Imaginar que accedemos a YouTube y visionamos un video cualquiera. Lo reproducimos y cuando terminamos de verlo deseamos volverlo a ver. ¿Creéis que el video se volverá a tener que descargar de los servidores de YouTube? Sería una tontería!! Por el contrario podemos reproducirlo mil y una veces, posicionarnos al instante a cualquier punto del video... ¿por qué? porque está ya en nuestro PC. Incluso si cerramos el explorador (dependiendo de la configuración del navegador) y volvemos a visitar el mismo video, posiblemente la carga sea inmediata. Uno de los trucos para poder guardar estos Videos en el PC es lo mismo que estamos explicando aquí, dado que está almacenado en el caché, tan solo tendremos que recuperarlo.

Un objeto flash funciona del mismo modo. El navegador lanzará una petición para recuperar dicho objeto flash (del mismo modo que en YouTube se hace una petición para obtener un video) y el servidor remoto comenzará la transmisión del objeto flash. El objeto flash se irá almacenando en los temporales de Windows y casi con toda seguridad antes o después acabe en el caché del explorador. Al finalizar la transmisión de datos, el objeto estará en nuestro PC!! Da igual que no sepamos donde se encuentra exactamente, pero podremos afirmar con rotundidez que está en nuestro PC. De hecho, sin pensar demasiado, creo ahora mismo que el único o casi el único contenido que no pasa directamente por nuestro PC sino que pasa a la aplicación que sea directamente son los contenidos tipo Streaming, por ejemplo videos en Streaming, en los que se transmite un flujo constante de datos hacia la aplicación que los solicita, y al acabar la transmisión se corta la conexión y listo, si se requiere de nuevo los datos se deben de solicitar todos de nuevo. E incluso en este caso, también es simple interceptar estos datos y almacenarlos (El bueno de VLC siempre ayuda)

¿Alguien se ha perdido? Vamos a ver que tenemos por ahora. Lo que estoy diciendo es que si accedemos a cualquier web en la que se cargue un objeto flash, ya sea una aplicación ya sea un juego ya sea lo que sea, este contenido casi con toda seguridad pasará a formar, por el tiempo que sea, parte del caché del navegador, y si sabemos cómo localizar este caché y dicho objeto en el caché, tendremos el Dónde. Por la misma razón que existen contenidos dinámicos y estáticos, existen métodos por los cuales decir al navegador que el contenido que va a recibir no se almacene en caché, o se puede usar esto también para intentar evitar que el contenido pueda ser accedido en el caché. Pero a nosotros por ahora esto no nos importa (aunque más adelante será un problema con el que nos vamos a topar), lo que nos importa es que en el caché está nuestro objetivo.

¿Donde está el caché? ¿Cómo se encuentran estos archivos temporales del caché?

Bueno esto es más complicado. Cada navegador usa un sistema diferente. En mi caso uso y usaré para todo Firefox, con lo que todo lo que diga a partir de ahora irá orientado a él. Esto no quiere decir que no se haga de modo muy similar con Internet Explorer, Ópera o cualquier otro navegador.

En Firefox hay unos archivos de control que podríamos decir que se encarga de establecer toda la estructura del caché. A grandes rasgos, dado que la arquitectura de la caché en Firefox podría ser tratada en una entrada solo para ella, podemos decir que los archivos independientes que suelen ocupar en tamaño un espacio no despreciable, se almacenan en el caché de forma inalterada, es decir, si es una imagen jpg se creará en el caché la imagen nativa jpg. En el caso de tamaños de archivos despreciables (en comparación con objetos "pesados") como páginas HTML, pequeñas imágenes, páginas de formato CSS... este tipo de contenido se suele almacenar no de forma independiente, sino en bloques dentro de otros archivos. Las peticiones web se almacenan también en este tipo de archivos (Ya explicaremos que son estas peticiones web).

Luego quiere decir que si accedemos a la web X, cargamos la aplicación/juego, accedemos a la carpeta del caché de Firefox, existirá un archivo de nombre indeterminado que es precisamente el juego/aplicación que estamos ejecutando además en dicho momento en RAM, y que es posible que al cerrar el navegador y dejar de ejecutarlo, permanezca aun así en dicha carpeta. Pero... ¿cual es el archivo?

Por cierto, no he dicho la ruta aun del caché de Firefox, pero es algo que no es un secreto ni misterio, una simple búsqueda en google nos quitaría el problema:

Windows Vista:

"C:\Users\[Usuario]\AppData\Local\Mozilla\Firefox\Profiles\aleatorio.default\Cache"

Windows XP:

"C:\Documents and Settings\[Usuario]\Local Settings\Application Data\Mozilla\Firefox\Profiles\aleatorio.default\Cache"


Donde [usuario] es el nombre del usuario de sesión y aleatorio es un nombre generado de forma aleatoria (en realidad no es aleatorio, pero nos da igual). Pues en dicha carpeta se encuentra. Tener en cuenta que la carpeta AppData/Local Settings y posiblemente otras estén ocultas, así que Herramientas de carpetas y ver Archivos/Carpetas ocultas.

Otro modo más simple y rápido de saber cual es nuestra carpeta de caché en Firefox es teclear en la barra de direcciones de este lo siguiente:

"about:cache"

Evidentemente sin las comillas. Ello nos abrirá una pestaña o en la misma, y nos saldrá información acerca de nuestro caché, entre otras cosas donde se guarda de manera local:

Disk cache device

Number of entries:	2842
Maximum storage size:	51200 KiB
Storage in use:	51190 KiB
Cache Directory:	C:\Users\[Usuario]\AppData\Local\Mozilla\Firefox\Profiles\xxx.default\Cache

Luego está claro a que carpeta debemos acudir. Pero incluso en la misma pestaña abierta, podremos darle a un botón que se llama: List Cache Entries que os listará todos los objetos almacenados en el caché, entre ellos debería de estar nuestro objeto flash o nuestro video de YouTube...

El problema es identificar el objeto. Si le damos a List Caché Entries es muy fácil saber si nuestro objeto está o no está dado que hace referencia directa a la URL de origen de dicho objeto. Pero cuando accedamos a la carpeta Caché veremos que los nombres no son nada descriptivos, que parece que son tan solo nombres aleatorios. Ante esto podemos hacer varias cosas para identificar lo que estamos buscando:

a) Aunque no necesario, si limpiamos el caché del navegador ANTES de acceder a la aplicación/juego, tendremos un caché prácticamente vacío, lo que hará encontrar el archivo en cuestión casi al instante. No voy a explicar ahora como se limpia el caché del navegador. Pero el proceso sería Limpiar caché, cerrar navegador y visitar la web de la aplicación/juego flash para que este se cargue, evidentemente hay que hacer que se cargue la aplicación/juego.

b) Con un caché vacío o casi vacío, lo normal sería ordenar los archivos de la carpeta caché por tamaño o por fecha. Por fecha para eliminar posibles entradas que el caché contenga (en caso de no limpiar el caché). Por tamaño porque es lo más identificativo de cara a diferenciar el objeto flash entre cualquier otro objeto, y esto mismo se puede aplicar para videos de YouTube u otros. Es lógico pensar que el contenido flash va a ser de un tamaño considerable en comparación con otros contenidos que se hayan podido descargar. A fin de cuentas las imágenes, código HTML... no ocupa demasiado en comparación con lo que puede ocupar una aplicación/juego flash, que pueden ocupar desde 1MB a 10MB a lo que sea. O lo mismo para un video, que puedes ir buscando tamaños a partir de 3MB por ejemplo. Dado que vamos a suponer que el caché está limpio, posiblemente el archivo de más peso sea precisamente lo que andamos buscando. OJO! los archivos que comienzan por "_CACHE_" son archivos de bloques que NO SON LOS QUE BUSCAMOS, estos los ignoramos, ocupen más o ocupen menos, hay 4 de estos archivos si no recuerdo mal.

c) Una vez que tengamos claro o casi seguros que archivo es el que estamos buscando, deberíamos de comprobarlo de algún modo. Lo primero será copiar dicho archivo al escritorio de Windows para tenerlo más accesible y evitar además que se elimine del caché por algún método ya explicado. Una vez en el escritorio tenemos varias formas de verificar si tal archivo es o no es el que necesitamos:

Opción A: Dado que es un contenido flash, nuestro navegador debería ser capaz de abrirlo directamente. Para hacer esto tan solo tendríamos que renombrar el archivo con la extensión de objeto flash: "swf" y arrastrarlo a nuestro navegador. Posiblemente el navegador cargaría el objeto flash sin problema alguno... pero quien lo haga, se dará cuenta en el caso de aplicaciones como Hammerfest que, o se le bloquea el navegador o no aparece absolutamente nada... no, no es un error, es debido a que muchas aplicaciones/juegos flash se componen en realidad de dos partes, sobre todo cuando es una aplicación/juego que interacciona con un servidor y en la que la aplicación/juego interacciona de algún modo con la sesión de cada jugador. Estas partes podríamos categorizarlas como el programa cargador y el programa aplicación. El cargador se encargaría de asociar por así decirlo una cuenta, una sesión, un... a la aplicación principal, además de encargarse de asuntos de seguridad, control de cuentas, intermediario en la transmisión de datos... dejando la aplicación tan solo para eso, para la aplicación en sí, sin preocuparse esta de si ha existido errores en la transmisión de datos, si todo es correcto... etc etc. Esto es u esquema muy común en este tipo de contenidos. Debido a esto, la aplicación "sola" no puede ser ejecutada en un navegador, puesto que depende del cargador que es quien le pasará los parámetros necesarios para hacerla ejecutar correctamente.

Opción B: A estas alturas supongo que el que más o el que menos tendrán un editor hexadecimal en su PC, y si no es así... ya está tardando. Yo recomiendo WinHex, pero cada cual que use su favorito. La opción A es rápida y simple, aunque no garantiza al 100% que sea lo que andamos buscando. Lo que nos interesa con esto es saber si la cabecera del archivo coincidiría con la cabecera de un objeto flash swf. La cabecera de un objeto flash, los primeros 3 bytes del archivo, corresponden con "SWF", 46 57 53 en hexadecimal ó a "CWS" 43 57 53, como podemos ver en estas dos capturas de un tema flash para mi móvil que estoy creando:



Con dichas cabeceras sé que aunque el navegador no quiera abrir dicho contenido, son objetos flash. Si tenemos en cuenta el tamaño, la fecha y el navegador vacío... está claro.

Hay herramientas que hacen de todo esto mucho más fácil, y simplemente interceptan la petición flash y permiten almacenarla en disco directamente. Pero me gusta hacer las cosas a la vieja, sin depender de ningún programa en la medida que pueda.

Aunque nadie se lo plantee, en las dos imágenes posteadas aparece lo que será una de las cuestiones claves en el siguiente capítulo, pero como estoy diciendo, será cosa del siguiente capítulo.



El otro modo del que hablaba, pasaría por interceptar la petición al servidor web que hace nuestro navegador y descargar el objeto flash directamente con cualquier gestor de descargas o desde nuestro propio navegador si deshabilitamos los complementos que hagan que el contenido flash se "ejecute", permitiéndonos descargar dicho contenido.

¿Como interceptar estas peticiones?

Hay muchas soluciones. Desde mirar el código fuente de la web que abre la aplicación/juego en cuestión, algún complemento de Firefox para mirar cabeceras, un servidor proxy... o evidentemente mi favorito, un Sniffer. Un Sniffer no solo nos va a servir para esto, sino que nos puede dar siempre una información valiosísima y muy útil. Un Sniffer, entre otras muchas cosas captura perfectamente cualquier petición realizada, con lo que nos es muy simple conocer la ruta exacta del objeto flash, así como si existe alguna dependencia o el nombre mismo real del archivo en el servidor.

A continuación os dejo una petición (y su contestación) de un objeto flash, vista desde WireShark, precisamente el mismo tema flash que estoy creando:



Hacer clic para ver más grande.

Como se puede observar en la imagen, la parte superior roja hace referencia a la petición que realiza nuestro navegador, mientras que la parte azul hace referencia a la contestación por parte del servidor.

Si os fijáis, las dos primeras líneas son:

"GET /Desktop.swf HTTP/1.1
Host: www.theliel.es"

La primera dice que quiere obtener el archivo /Desktop.swf que hace referencia a dos cosas. La primera al nombre del archivo y la segunda a la dirección en el host donde se encuentra, en este caso en "raíz".

La segunda línea lo dice ella misma, es el host. Luego quiere decir que el archivo flash que desearíamos descargar se encontraría en la dirección "www.theliel.es/Desktop.swf". Luego con cualquier gestor de descargas o modificando el comportamiento de nuestro navegador, podríamos tener de forma clara también cualquier objeto flash en nuestro escritorio.

Usar WireShark es fácil, aunque requiere quizás de algo de práctica para ver las cosas con claridad. Para quien prefiera algo más facilito pero al estilo de WireShark podría probar también con un programa gratuito llamado Paros, que es un pequeño proxy que intercepta cualquier petición y muestra de forma estructurada las peticiones realizadas a cada host, de modo que si lo activamos y abrimos cualquier web con cualquier contenido, en Paros nos irá apareciendo toda la estructura de archivos de dicha web, incluyendo objetos flash, con sus nombres reales y rutas, siendo idóneo para los menos acostumbrados. Configurar Paros es muy fácil, pero requiere de un pequeño cambio, dado que Paros actúa de proxy, y tenemos que hacer que el contenido pase por él. Tan solo debemos de acceder a las opciones de red de Firefox:

Opciones/Avanzadas/Redes/Configuración. Estableceremos servidor proxy manual a la dirección de loopback de nuestro PC: 127.0.0.1 y el puerto el que servirá Paros, que por defecto es el 8080. Una vez modificado esto y con paros funcionando, podremos ver que funciona perfectamente, cualquier página visitada quedará registrada íntegramente en Paros:




Como podemos ver es un poco lo mismo. En Request tendremos las peticiones y en Response la contestación. En el ejemplo, simplemente abrí la web de mi blog, y vemos parte del árbol que se ha generado a partir de ello (no está completo). Por ejemplo podemos ver cosas curiosas, como que se hace una petición a YouTube de un video!! Claro, en mi blog tengo un enlace a mi video de iPod Touch, y aparece aquí, aunque en otro dominio y no es el video en sí, sino el reproductor de YouTube que implementa Bloggers. Y aun así, si os fijáis, aparece la ruta exacta a dicho reproductor (que no deja de ser u objeto flash). Con Paros, para quien no esté acostumbrado, podrá crear un árbol completo sobre la web que quiera estudiar y ver las dependencias de archivos, los dominios, los nombre de los archivos... datos que a la larga nos harán falta de un modo u otro. Luego ya sea pro WireShark, ya sea por Paros... recomiendo usar un sistema similar. De momento cada cual puede conformarse con la captura de caché, pero ya veremos los problemas que aparecerán más tarde.

Descargar Paros Proxy

Notas: Hace falta tener instalado el JRE desde la web oficial de Sun, que se puede obtener desde AQUI (y seleccionar la plataforma). Después de usar Paros recordar volver a deshabilitar proxy en las opciones de Firefox o no os funcionará el navegador con Paros cerrado.


Bueno, creo que queda claro suficientemente el Dónde, quien haya terminado de leer este capítulo, debería de ser capaz de saber capturar cualquier contenido desde caché o desde un proxy como Paros o WireShark. Así que ahora de todo esto nos olvidamos y simplemente vamos a suponer que tenemos en el escritorio un archivo llamado: Test.swf (por ejemplo) que será la aplicación/juego que queramos estudiar, ya la saquemos desde Paros y conservando el nombre original que extraída del caché con un nombre raro y renombrado. No importa.



Interpretando, Jugando con los editores hexadecimales

De acuerdo Theliel, tienes en el escritorio un archivo swf que ocupa lo suficiente como para volvernos locos buscando algo de interés. ¿Qué podemos hacer ahora con esto? Bueno, es interesante pensar en las alternativas, en diferentes planteamientos posibles. Se me ocurren muchas alternativas, algunas de las cuales sé de buena tinta que ya han sido usadas por más de uno, pero siempre corre el mismo riesgo, no implica que toda idea pueda acabar en un éxito. Muchas nos llevarán de nuevo a callejones sin salidas, otras veces no seremos capaces de continuar y es posible a lo mejor que no encontremos salida!! Pero vamos a intentarlo. Así que antes de ver las diferentes técnicas o sistemas que podemos aplicar, tenemos que conocer antes algo de flash, sería poco prudente por nuestra parte intentar abalanzarnos así como así contra un objeto flash, sería temerario igualmente cruzar un pantano lleno de serpientes venenosas con los ojos cerrados.

Así que vamos por el principio: ¿Que es flash?

Si acudimos a la Wiki nos vamos a topar con buena información al respecto, pero creo que es mejor que cada uno se haga su propia idea. Yo veo flash como un objeto, una caja. Una caja en la que dentro podemos encontrar por ejemplo pistas de video y de audio, podemos encontrar gráficos vectoriales que pueden ser animados o lo más importante para el caso que nos ocupa, un lenguaje de Script de "programación", llamado ActionScript. Este lenguaje maneja imágenes, videos, vectores... etc etc etc, todo ello objetos que se encuentran dentro de nuestro objeto flash. Al ser Flash un lenguaje en sí mismo (ActionScript) es necesario que alguien haga de intérprete de dicho lenguaje!! Y efectivamente nos topamos con que Flash actúa como una máquina virtual. Esto no es raro, dado que para que podamos visualizar contenido Flash en nuestros navegadores necesitamos instalar previamente dicha Máquina virtual, llamada para tal efecto el reproductor "adobe flash player". Pero no deja de ser una máquina virtual. ¿Qué significa esto?

Cuando creamos un contenido Flash, añadimos a este los objetos que necesitamos, todo el contenido estático que luego será usado por nuestro código en ActionScript para manejarlo. Así por ejemplo añadiremos nuestras imágenes que formarán nuestro monigote, los sonidos del paisaje, las fotos de fondo... lo que sea. Y por otro lado tendremos que escribir un código (o se generará este en parte) para hacer que nuestro monigote (que a lo mejor no es más que una sucesión de 4 imágenes estáticas) ande, corra, salte, vuelve, beba agua, vaya al servicio... o lo que sea. Digamos que ActionScript hace todo, es la programación de la aplicación/juego Flash. Os imagináis poder echarle el guante a este código? Simplemente nos bastaría con saber programación en ActionScript para desentrañar todos los misterios de cualquier aplicación/juego del que tuviésemos dicho código!!

Una vez acabada la aplicación/juego, se compila y comprime (o no) y se genera el archivo swf final que será colgado de cualquier servidor con las instrucciones dadas para que sea ejecutado en los exploradores de medio mundo. Ese código en ActionScript se compila como sucede con cualquier código de PC, y pasa a código máquina. Dado que Flash actúa en un modelo de máquina virtual, este código compilado no es interpretado para nuestro PC, pero sí por el reproductor que tiene ya instalado nuestro navegador, Flash Player. Este es capaz de abrir el archivo flash, saber que es una imagen, que es un sonido... y traduce a instrucciones de PC los códigos en ensamblador flash leídos por la aplicación/juegos en ejecución. Lo vemos mejor ilustrado en un ejemplo:

En ActionScript -> A=B * C
ActionScript Compilado ->

"constants "A", "B"
push"A", "B"
getVariable
push "b"
getVariable
multiply
SetVariable"

Que no son más que instrucciones ensamblador para Flash. Cuando se compila tan silo se genera el código hexadecimal correspondiente a cada instrucción. Sí, la dificultad de interpretar Flash en ensamblador es que Flash es un lenguaje de pila. Pero eso lo dejaremos para otro día.


De todos modos con esto podemos tener una idea bastante clara de lo que es la tecnología flash y de cómo funciona, y tendremos algunas ideas nuevas de cómo podríamos abordar el problema.


a) La opción más normal y lógica a seguir pasaría por descompilar la aplicación/juego flash e intentar de este modo tener acceso al código ActionScript. Esto suena más fácil de lo que parece, dudo que exista a día de hoy algún desensamblador en condiciones para Flash. Aun así sería una opción más que posible, y seguramente nos funcionaría al 100%. Pero esto implicaría primero que nuestro desensamblador hiciese su trabajo en condiciones, saber nosotros ActionScript y ser capaces de manejar un código considerable que ni siquiera hemos escrito, y para colmo ser capaces de recompilar de nuevo TODO el objeto flash para que los cambios realizados pudieran ser útiles. Es una posibilidad, y la trataremos en su debido tiempo... tiene sus pros y sus contras.

b) La opción a es buena, pero para quien no tenga conocimientos puede ser un camino más que bloqueado. Muchas veces en cambio podemos optar por métodos más sutiles que no siempre serán válidos pero que a veces nos podrán funcionar y muy bien. Sí, con muchas limitaciones la mayoría de las veces, pero lo suficientemente efectivos para no meternos en otros berenjenales. Vamos a centrarnos primero en esta opción, y dejaremos la opción A para más adelante.

Hemos dicho que tenemos el objeto flash en el PC y también que dentro de él seguro que encontraríamos código en ActionScript, imágenes, sonidos... Pero no deja de ser un contenedor nuestro objeto Flash. Antes de continuar vamos a hacer un símil con el formato de Audio/Video MP4. MP4 no es más que un contenedor en el que podemos encontrar Audio, Video, pistas de subtítulos, pistas de capítulos... etc. Si el contenedor no estuviese muy protegido o encriptado o comprimido... sería muy fácil abrir con un programa o incluso un editor hexadecimal y buscar el principio y fin de la pista de subtítulos por ejemplo, o de la pista de audio. El mismo concepto podríamos aplicar a u objeto Flash.

¿Que queremos decir con esto? que antes de intentar descompilaciones extrañas, sistemas rebuscados... vamos a intentar ir a lo fácil. ¿Qué pasa si dicho objeto flash lo abro directamente con mi editor hexadecimal? ¿Podré encontrar información de interés o tan solo símbolos extraños y valores sin sentido?

Pues señores, esto es una lección práctica así que a probar!! Yo continuaré con mi ejemplo basado en mi tema para mi móvil, para que después digan los amigos de MT que no tengo consideración con ellos!! Pero cada cual puede seguirme con el objeto flash que más les guste. (Dije que no pondría ningún material que pudiese atentar con los derechos de autor de Hammerfest, pero nunca dije que pudiese descompilar o modificar o jugar con un archivo creado por mí mismo. Las cosas de la vida)

A lo que íbamos. Vamos a ver qué sucede cuando abrimos directamente el objeto flash en nuestro editor hexadecimal (es la misma imagen que la anterior):



Sin embargo, después de recorrer todo el archivo no he encontrado nada que me pueda servir. Quizás no sea una buena idea después de todo... ¿o sí? Ahora entra el conocimiento puro y duro que hayamos podido aprender de Flash. Hemos hablado de las cabeceras de los archivos flash... ¿pero nadie se ha preguntado por qué existen dos cabeceras diferentes? Tenemos una cabecera CWS y otra FWS. Dije hace un buen rato que cuando se compila un objeto flash para generar como paso final el archivo .swf, entre otras opciones, podemos optar por la compresión de dicho objeto. El objetivo de la compresión es obvio, hacer que dicho objeto flash ocupe menos, aunque tiene una segunda función igual de interesante... ocultar contenido potencialmente accesible sin más. Actualmente, para cualquier creador de contenidos flash ya sea por ahorrar espacio como para ocultar rastros, la compresión es bien necesitada. Si no hay nada que ocultar a veces la compresión no obstante no es recomendada, el dispositivo final tendría que descomprimir antes y a lo mejor el espacio ahorrado podría ser mínimo o inexistente, dependiendo del contenido de dicho objeto flash.

Como podemos saber si el contenido del objeto flash se encuentra comprimido o sin comprimir? es fácil, mirando la cabecera. Precisamente la C de CWS significa "Compressed", mientras que los archivos flash con cabecera FWS no se encuentran comprimidos. En las dos imágenes que posteé en su momento pertenecen al mismo archivo, compilado igual, uno comprimido y otro sin comprimir. En mi caso el tamaño de archivo es prácticamente el mismo, pero podemos encontrar sorpresas en la versión no comprimida:


Si comparáis las dos imágenes, está claro que los datos son dispares, pero tampoco hay nada legible. No obstante, si en mi editor hexadecimal me desplazo a lo largo del archivo swf (no comprimido) al igual que hice anteriormente con el comprimido, me encuentro por ejemplo cosas de este tipo:




Interesante... muy interesante. Esto está un poco mejor... parece código de alguna clase. No digo que en este caso pueda servirnos para algo, o puede que sí... quien sabe... pero es un punto de partida. Para empezar porque si lo mostrado sí tuviese sentido claro para nosotros, podríamos simplemente modificar un valor y guardar. Con suerte sería suficiente, si obviamos posibles problemas por checksum y otros.

Normalmente, la mayoría de contenidos Flash contienen datos de interés de este tipo, y cuanto mayor sea la aplicación/juego, más uso intensivo se le da a este tipo de contenido. ¿Pero por qué? Tiene su lógica:

Pensar en una aplicación empresarial, por ejemplo la gestión de parques naturales de España. Imaginar que desde dicha aplicación se controla todo:

- Gestión
- Mantenimiento
- Visitas
- Animales
- Personal
- Facturación
- etc

Está claro que por muy sofisticada que sea la aplicación, un peso muy importante e imprescindible no recae sobre la aplicación en sí, sino en la base de datos que tendrá detrás de él suministrando todos esos datos. Vale, la aplicación es una maravilla, pero hace faltan los datos del personal, los datos de los animales, los datos de cada parque, los datos de cada visitante, las... todo ello no se implementa evidentemente en la misma aplicación, en realidad no tendría mucho sentido, más que nada pq estos datos pueden crecer o decrecer rápidamente, son dinámicos, están en continuo cambio.

Pero claro... en un entorno empresarial a día de hoy hay servidores que se encargan de administrar dicha base de datos, de dar acceso... pero en una aplicación flash esto como que no, todo debe de ir en el mismo caso. Si grandes tablas o bases de datos se tuviesen que implementar en una aplicación/juego flash, evidentemente no se haría en ActionScript, no sería una forma eficiente ni de implementar ni de corregir. Imaginaros que por lo que sea, se introdujo mal un dato en la aplicación servida, en una app flash que gestiona lo dicho, parques de España y supongamos que no hay una base de datos externa. El programador debería de abrir el entorno de programación, abrir todo el proyecto, ir al punto exacto, modificar el dato por el nuevo, guardar los cambios, recompilarlo todo... mucho trabajo a lo mejor para simplemente modificar un dato. En cambio, si tienes un entorno que sepa por ejemplo simplemente abrir y cerrar un objeto flash correctamente y permite modificar un objeto existente en él, como una tabla, una BD... automáticamente el proceso se simplificaría al máximo. El programador tardaría a lo mejor de 10 minutos (compilar un proyecto flash en condiciones tarda) y cientos de pasos a cuanto... 1 minuto?.

El caso de Hammerfest por ejemplo. Está claro que es lo que usa, principalmente porque se vio en CheatEngine en el capítulo eliminado (Temporalmente). Y segundo porque simplemente es lógico. Hammerfest es un juego/aplicación que se basa principalmente en objetos con propiedades como el valor, como la rareza, como las familias existentes... etc etc que todos sabemos. Os imagináis que los amigos de MT tuviesen a lo mejor que recompilar toda la aplicación Flash simplemente para modificar el valor de un objeto? Hombre, que a lo mejor se puede hacer y compensa!! Pero al menos desde mi punto de vista es algo muy poco efectivo y a la larga una pérdida de tiempo descomunal.

Siguiendo el mismo razonamiento, no sería extraño presuponer que los amigos de MT implementaron este tipo de soluciones. El problema que tienen es que de ser así, los datos podrían ser accedidos de forma simple, y modificarlos también. Evidentemente si fuese el caso de una compresión, esto evitaría poder verlo, con lo que la compresión sería además un método de "protección" adicional para este tipo de datos, con lo que simplemente realizando una descompresión del objeto flash, podría darnos una cantidad de información increíble, e incluso información lista para modificar sin necesidad de recompilar nada ni usar ingeniería inversa, ni saltarse ninguna protección, ni "parchear" en el sentido real de hacer una modificación consistente. Tan solo sería necesario un editor hexadecimal, localizar el punto a modificar y listo.

Por razones de seguridad esta vez no me voy a pillar los dedos y ante la duda esta vez tan solo doy información al respecto que no esté sujeta a ninguna posible ley de propiedad intelectual, de este modo si se repite de nuevo lo sucedido asegurarme que quien realice la petición a Google le salga el tiro por la culata y termine pagando por ello, como fue el caso de un caso en el que la empresa acabó pagando 100.000$ por costas y otros, quien se vea interesado puede leerlo AQUI


Pero nosotros a lo que nos interesa...

¿En mi caso concreto? Un poco lo mismo, mi objeto flash (el tema) se apoya en archivos de texto plano para especificar algunas propiedades que no son especificadas en otros puntos de todo el objeto flash.

En el caso de Hammerfest, casi con toda posibilidad exista algo muy similar, y cualquier propiedad pueda ser editada sin complicación alguna y sin conocimientos de ningún tipo, como pueda ser la rareza de cada objeto, el valor, la familia a la que pertenezca, redirecciones de portales de las paralelas... Quien haya llegado hasta aquí y haya querido experimentar con ello ya se habrá percatado de ello.

Pero claro... aun no hemos desvelado como vamos hacer para descomprimir un contenido flash. A fin de cuenta no estamos hablando de descompilar nada, simplemente de descomprimir. Un objeto flash puede comprimirse usando el algoritmo zlib. Normalmente este proceso se realiza como paso último a la compilación del objeto flash swf. A efectos de nuestro navegador, le da igual que se trate de un contenido flash comprimido o no comprimido. Si está comprimido tardará algo más en ejecutarse puesto que se debe de descomprimir en memoria, si está descomprimido el proceso será más rápido pero el tamaño será mayor, con lo que la descarga será más larga. Todo tiene sus pros y sus contras. A nosotros nos puede dar lo mismo, ya estamos trabajando en local, y si en un futuro necesitásemos comprimirlo de nuevo por el motivo que fuese ya nos preocuparíamos de hacerlo. Esto no es descabellado, yo si creara contenido de este tipo, usaría como medida adicional un Loader (cargador) que especificase un hash del contenido que se ejecuta y que se reenviase al final de la ejecución, con idea de que de alterarse el servidor rechazara la conexión. Aunque es solo un ejemplo, se me ocurren muchos otros, igual como otras posible medidas para también saltarse estas propuestas, como podría ser entonces descompilar el Loader y editarlo con mis datos... pero es como todo... no existe un sistema infalible, pero se pueden poner complicadas las cosas.

A lo que íbamos... Zlib. Como se aplica Zlib a un objeto Flash?? Hombre, es evidente que no se aplica íntegramente a todo el contenido, cualquiera para saber esto podría crear un simple ejemplo flash y compilarlo con diferentes opciones de compresión. Para ahorrar trabajo os lo digo yo, la compresión no se aplica por ejemplo a la cabecera. Pero quitando la cabecera del archivo se aplica íntegramente a todo el archivo. Aquí se abre un nuevo abanico de posibilidades para convertir un archivo flash comprimido -> CWS a un archivo flash no comprimido -> FWS:

a) Podríamos en un editor hexadecimal cortar la cabecera del archivo y lo que quedase aplicarle el algoritmo zlib (para descomprimir) usando alguna herramienta que encontremos (lo cual es complicado), y una vez descomprimido el contenido restituirle la cabecera cortada y modificar CWS por FWS

b) Podríamos buscar alguna herramienta que hiciese el trabajo por nosotros... y os ahorro el trabajo, no es fácil encontrar algo así, aunque por suerte para muchos existe, pero la usaremos en otro apartado que explique más detalladamente cómo se podría descompilar un objeto flash o "reconstruirlo". Además queremos aprender no hacer trampas por hacer trampas, y lo mejor siempre es hacerlo todo a mano.

c) Con suerte hace tiempo encontré un código publicado por "Alex Beregszaszi" de dominio público, es decir, no está atado a ninguna licencia con lo cual su uso es libre. Dicho código hace precisamente eso, convertir directamente un archivo CWS en otro FWS. Yo creo que es el mejor punto de partida, además todo el mundo puede desde compilarlo para la plataforma que desee como proponer mejoras como ver que no es nada malicioso. Os dejo el código subido en un archivo, no quiero extender aun más esta entrada :P:

Código CWS2FWS

Y para quien no quiera complicaciones y lo quiera ya compilado

Programa CWS2FWS

Si alguien quiere compilarlo, creo que la versión que he puesto es la buena, creo que realicé una pequeña modificación dado que el código original tenía un par de errores. En cualquier caso se ejecuta por línea de comandos evidentemente y la sintaxis es simple:

cws2fws. exe [flash CWS] [flash FWS]

Con ese pequeño código podremos convertir cualquier objeto flash comprimido a un objeto flash sin comprimir, y así poder investigar cualquier posible dato "oculto" que existiese. Una vez el objeto flash descomprimido, un simple vistazo por el editor hexadecimal debería de descubrir cualquier texto propenso a ser editable de forma simple. Dado que es un objeto flash estándar sin comprimir, en teoría se podría usar sin problema por nuestro navegador el nuevo objeto flash. Eso sí, aviso, una cosa es modificar un byte y otra cosa es añadir o eliminar datos a la estructura ya creada. Imaginar que nos encontramos en la aplicación de parques naturales lo siguiente:

Original:

"Pagar
-Pedro: 150"

Modificado 1:

"Pagar
-Pedro: 100"

Modificado 2:

"Pagar
-Pedro: 50"


Según lo que estoy explicando, sería muy tentativo modificar Pedro a cero o 5 o algo muy bajo, como en el caso de la modificación 2, en el que se podría estar modificando la longitud del archivo El problema es que de ser así, a la estructura le estaríamos restando a lo mejor un byte. En cambio la modificación 1 podría pasar por buena, dado que no modificaría la longitud, aunque si el valor. Este tipo de medidas son constantemente usadas por cualquier programador. Para poder modificar a libertad se requeriría posiblemente reconstruir el objeto Flash, una "recompilación" pequeña, ya que posiblemente la misma tecnología flash tenga métodos de control de este tipo para impedir archivos dañados, mala transmisión de datos y otras historias.


Llegados a este punto podríamos decir que hemos terminado el cómo interpretar los datos y como modificarlos. Hemos aprendido a obtener un objeto flash cualquiera, copiarlo en el escritorio, descomprimirlo y con suerte al hacerlo tener acceso a datos legibles y modificables de manera simple, tan fácil como editarlo de forma hexadecimal, modificar y guardar. Claro que aun tenemos ciertas restricciones, como una manipulación más exhaustiva, y evidentemente tampoco hemos logrado de forma práctica nada!! tan solo estamos jugando en local con el objeto flash.


Antes de abordar el cómo hacer para que pasemos del estudio a la práctica, vamos a explicar el método a que ya dije hace muchas líneas: Descompilar.

Descompilar tiene el problema de la interpretación. Descompilar el código ActionScript de un objeto flash a ensamblador flash es "fácil". Evidentemente interpretar dicho código ya no es tan fácil. Hay multitud de programas tanto de pago como gratuitos para descompilación flash, claro que cada programa puede hacer una interpretación muy diferente del código flash en ensamblador que recupera el proceso de descompilar. Un programa ideal sería capaz de reconstruir el código tal y como fue escrito por el programador a partir del código en ensamblador. Esto en la práctica es imposible, dado que diferentes códigos pueden producir el mismo código en ensamblador. Podemos obtener aproximaciones que nos sirvan a lo mejor para guiarnos un poco... pero poco más, aunque como he dicho todo depende del decompilador.

No me gusta la decompilación aunque hay veces que no hay otro camino. Tampoco voy a recomendar ningún programa para ello. Lo único que voy a usar es un programa completamente gratuito que permite descompilar y reconstruir, así como descomprimir y comprimir objetos flash de forma simple y rápida. Eso sí, el código decompilado tan solo pertenecerá a texto plano que pueda existir y código ActionScript (que para nuestro caso perfecto) y no se incluirá ni se tratará de abrir el objeto flash y extraer los diferentes subobjetos, como imágenes y otros. Decir que tampoco generará un código "legible", tan solo el código en ensamblador, con lo que quien quiera manipular en mayor medida tendrá que aprender algo de ensamblador Flash, que tampoco es que sea complicado una vez que se comprende. Pero la principal característica estrella de este programa es que nos va a permitir por ejemplo descompilar un objeto flas, modificarlo y reconstruir un nuevo objeto flash igual que el anterior!! pero modificado los cambios que modificásemos, es decir, corrigiendo cualquier incremento o decremento del tamaño de los archivos, checksum... etc etc. Una vez decompilado el código de este modo podremos modificar lo que queramos como queramos, reconstruirlo y funcionando al 100%, sin ninguna limitación.

El programa?

Flasm

podéis encontrar información detallada sobre ensamblador en flash y otros, y lo podéis descargar desde:

AQUI

Aunque existen también versiones para Linux y MAC OS. Y sí, es una herramienta de línea de comandos. El funcionamiento es muy simple, tan solo voy a poner los comandos que puedan ser útiles mayoritariamente:

flasm -d Desktop.swf > Desktop.flm
flasm -a Desktop.flm
flasm -x Desktop_Com.swf
flasm -z Desktop_Dec.swf

La primera decompila el objeto flash Desktop.swf y genera la decompilación en un archivo llamado Desktop.flm (que se puede abrir con cualquier editor de texto)
La segunda compila el archivo (presumiblemente modificado) Desktop.flm dentro de su original Desktop.swf
La tercera descomprime el archivo Desktop_Com.swf, convirtiendo este en un archivo FWS
La cuarta el proceso contrario. el archivo Desctop_Dec se comprime convirtiéndose en CWS

Como vemos la herramienta podría sustituirnos la pequeña aplicación antes expuesta. Pero esto es para aprender, y mejor aprender con la anterior, a menos que se deseen hacer cambios sustanciales en el objeto flash y haga falta recompilarlo. Esto es parte de mi archivo decompilado por Flasm, y la sorpresa como verán la mayoría es de mayúsculas, de lo que parecía en WinHex un tanto caótico y algo de información visible, aquí paso a tener una estructura con muchísima más información, y además nos va a servir para explicar, por último en este capítulo, un par de conceptos más. Dos trozos copiados directamente de mi archivo Desktop.flm, dos sitios diferentes del código, la primera el inicio, la segunda a mediados:

Inicio:

"movie 'Desktop.swf' compressed // flash 7, total frames: 2, frame rate: 20 fps, 240x320 px
protect 'xxxxxxxxxxxxxxxxxx'
scriptLimits recursion 256 timeout 5

defineMovieClip 21 // total frames: 1
end // of defineMovieClip 21
defineMovieClip 22 // total frames: 11
frame 0
stop
end // of frame 0
end // of defineMovieClip 22
defineMovieClip 29 // total frames: 12
end // of defineMovieClip 29"


En esta parte tenemos información como que el archivo original decompilado estaba comprimido, es decir, de tipo CWS. Por otro lado aparece la etiqueta Protect, que quiere decir que el contenido supuestamente está protegido para que no pueda ser abierto en algún IDE, lo cual tampoco es mucha seguridad dado que igual que está esa línea, podría eliminarla directamente desde el archivo y eliminaría con ella la seguridad. Lo que aparece como XXX es la clave en hash MD5, que evidentemente por motivos de seguridad he editado. Lo he puesto para que veáis que esas protecciones pueden eliminarse tan fácil como eliminando dicha línea. Interesante verdad? Y más adelante tan solo vemos lo que parecen son definiciones de clips y también algunos frames y el número de estos... información información!! la información por absurda que parezca siempre es útil. Imaginar cambiar un frame por otro!! a lo mejor en un juego flash esto no sirve para nada, si modifico un frame por otro en mi tema, creerme que el resultado será completamente diferente. En flash normalmente el código se ejecuta sobre "frames" concretos, son como partes. Recordar que Flash nació como contenido dinámico, sobre todo para gráficos en movimiento y ese tipo de cosas, con lo que se conserva siempre el estilo de "frames", y por encima de estos clips.


Más adelante tengo más información interesante. Aparece anteriormente el frame 0... pero es que más adelante tengo el código en ensamblador que se ejecutará en el frame 0!!:



frame 0
constants 'elements', 'Array'... 'Contacts', 'App8_IconName', 'App8_Text', 'walkman'...
push 'elements', 0.0, 'Array'
new
varEquals
push 'App0_IconName', 'PREPLAY_DESKTOP_ICN'
setVariable
push 'App0_Text', 'PlayNow'
setVariable
push 'App1_IconName', 'DESKTOP_WAP_ICN'
setVariable
push 'App1_Text', 'Internet'
setVariable
....


Esto tiene mejor pinta. Es decir, simplemente por lo que veo y sin ser un genio interpreto que si modifico la línea que pone: push "'App1_Text', 'Internet'" por "push 'App1_Text', 'TusMuelas'", sin ser propietario de dicho archivo, sin ser mío el objeto flash... cuando meta el tema a mi dispositivo el icono de Internet ya no se llamará "Internet", sino se llamará "TusMuelas". (En realidad tendría que modificar tb el texto que sale un pelín más arriba y que no aparece pq lo he abreviado, que era largo).

Después de aplicar todos los cambios y guardar el archivo flm, tan solo tendría que recompilar el código con: Flashm -a Desktop.flm y terminaríamos finalmente un archivo Desktop.swf que al meterlo a mi móvil tendría el efecto deseado. Tan fácil como eso. Y esto se extrapola a cualquier aplicación/juego en flash! Incluso los cambios realizados en este ejemplo son sobre código en ensamblador que todo el mundo comprendería, en el caso de encontrarnos texto en plano pues más simple aun, como el que apareció en la primera imagen, que si bien no era en este caso identificativos, en otro si puede serlo.



Hemos acabado otro capítulo. Si todo ha ido bien, y hemos aprendido bien la lección, a este punto deberíamos ser capaces de Localizar un objeto flash en el caché de Firefox o descargarlo directamente, copiarlo al escritorio, descomprimirlo y modificarlo sutilmente ó decompilarlo -> modificarlo -> reconstruirlo, todo gracias a Flasm.

Nos queda el último paso, y por ser el último no es el menos importante, sino quizás el más importante, puesto que hasta ahora hemos logrado realizar modificaciones, sí. Hemos logrado hacer pasar nuestro objeto flash como bueno, sí. Y en caso del tema de mi móvil sería suficiente, dado que tan solo me quedaría enviarlo a mi móvil y listo. Pero en caso de una aplicación/juego flash, no podemos enviarlo de vuelta al servidor de ellos ;), así que intentaremos darle una vuelta de tuerca e intentar jugar o interactuar con una aplicación/juego modificado por nosotros.



Aplicando lo aprendido

Por lo que tengo entendido muchos han logrado llegar al punto en el que nos encontramos, pero no han sido capaces de llegar más allá. Vamos a intentar explicar diversas posibles técnicas que podrían permitirnos hacer que pasásemos como cualquier otra persona.

En la primera parte de todo esto, hace ya unas semanas, explicábamos que la edición al vuelo simplemente consistía en la modificación in situ de nuestra propia RAM y que quitando eso todo lo demás funcionaba perfectamente. Ahora vamos a intentar pensar cómo podríamos "inyectar" por así decirlo un objeto flash modificado en nuestro PC por otro. Si pensamos se nos pueden ocurrir diferentes buenas ideas, lo cual es bueno, cuantas más ideas tengamos mayor margen de acierto podremos tener, quizás un camino no, pero quizás otro sí. Voy a poner soluciones que se me ocurren, aunque puede haber más:

- Si el Caché contiene un archivo temporal que se reutiliza cuando se vuelve a visitar una web, sustituir el archivo del caché por el modificado sería una buena opción. Al volver a visitar la web el archivo a usar sería el modificado en el caché, con lo que estaría todo hecho.
- En memoria se tiene que descomprimir como dijimos el objeto flash. Podría "inyectar" el nuevo objeto en memoria y sustituir el cargado en el momento de comentar
- Montarme en algún servidor gratuito una aplicación/juego completo en el que subiese los archivos necesarios modificados, dirigir el navegador hacia él, con lo que se cargaría el nuevo objeto y no el "oficial".
- Trabajar siempre que se pueda en Local


Seguro que hay más alternativas pero creo que por ahora nos vamos a quedar con estas y vamos a explicar en qué consiste cada una de ellas, sin entrar en demasiado detalle, que si no leer esto será peor que leer el quijote. Intentaremos que al menos una de todas ellas nos dé resultado. Yo os recomiendo a quien le guste esto es que personalmente vaya explorando otras posibles soluciones o probando las que aquí se exponen, es la mejor forma de aprender.

Vamos a ir desglosando cada una de las posibilidades que se nos plantean:


a) Usar el Caché:

En principio sería la opción más lógica. Si podemos recuperar del caché el archivo que hemos modificado, podremos sustituir el caché con el archivo modificado para que al visitar de nuevo la web se cargue el nuevo objeto modificado y no el viejo. Por extraño que parezca esto es muy complicado. Primero porque es una técnica que es completamente dependiente del navegador a usar, como hemos dicho cada navegador gestiona el caché de modo diferente. Por otro lado los sistemas de caché que implementan los navegadores suelen estar incluso más protegidos que los propios objetos flash que estamos intentando modificar. Jugar con el caché de Firefox es un infierno, sustituir un archivo por otro en el caché con el mismo nombre o mismo tipo no sirve absolutamente para nada. Esto sucede porque existen archivos de control que especifican el tamaño de cada archivo por un hash, más un tamaño especificado en las peticiones de archivo que Firefox almacena, sin contar con que el servidor podría obligar a recargar dichas peticiones con lo que si se modificase en un byte el archivo la carga estaría corrupta.

Sí, es completamente posible hacerlo de este modo, pero creerme que no tengo tiempo para explicaros como manejar el cache de Firefox, teniendo en cuenta además la poca documentación al respecto que hay y lo "engorroso" que resultaría realizar cualquier modificación adicional. Si cada vez que deseo modificar algo tengo que perder 20 minutos en reconstruir el caché de Firefox para que cuele, sin contar en posibles medidas de seguridad por parte del otro servidor...

Pero funciona!!

Eso sí, quien se quiera entretener puede probarlo con cualquier archivo del caché, que para el caso es lo mismo. Si no existiese un método mejor os lo explicaría, pero como tenemos un método mejor y que se aprende también bastante, este método lo descartamos... de momento, pero ei, podemos dejarlo pendiente como un nuevo OffTopic


b) Inyectar en Memoria:

La verdad es que a priori puede parecer lógico, pero si lo pensamos detenidamente va perdiendo fuerza... estaríamos dando mucho por supuesto, como por ejemplo que la inyección se puede realizar después de la carga del objeto flash sin que este haya llegado a empezar a ejecutarse, o tendríamos que encontrar un modo de interceptar la carga y poner nuestro objeto en medio. Y no, tampoco es que sea algo fácil de hacer.

Técnicamente es posible interceptar al vuelo la carga del objeto desde caché a RAM y modificar el acceso para cargar el archivo modificado, esto se suele denominar hook, un gancho, una petición a caché a dicho archivo hace bloquear el caché y suministrar a RAM el objeto modificado. Se podría crear una pequeña aplicación que realizara lo citado, monitorizar el acceso a caché y montar el nuevo objeto.

Nos vale como solución? Pues sinceramente no lo sé, porque personalmente no la he puesto en ejecución nunca. No podría decir ni sí ni no hasta que no lo intentase por todos los medios. Supongo que es posible, pero a lo mejor al hacerlo me toparía con algún problema nuevo que a lo mejor podría superar o no... a fin de cuentas es todo lo que hemos hecho hasta ahora, probar caminos, estudiar posibilidades e intentar avanzar. Aunque a veces tengamos que dar la vuelta y probar otro camino


c) Montar un sitio clónico

También parece una buena idea. Con cualquier programa tipo Spider podría descargar en el PC la web de la aplicación/juego y editando lo que fuese necesario y evidentemente sustituyendo el objeto flash por el modificado, volver a montar la aplicación/juego en un servidor propio y probar suerte.

Al igual que la solución de caché es más dependiente del navegador, esta solución es más dependiente de la aplicación/juego flash que sea en cuestión. Como hemos dicho, normalmente se usan aplicaciones tipo Loaders (cargadores) que entre otras cosas monitorizan este tipo de prácticas, para que no puedan llevarse a cabo. Por ejemplo lo más trivial sería enviar en algún momento y de alguna forma la URL en la que se aloja supuestamente dicho contenido y si no coincide con la original rechazando la conexión. De todos modos, fuese cual fuese la medida de protección, esta podría ser eludida si releemos todas estas letras. A fin de cuentas hemos dicho que podemos modificar cualquier objeto flash... ¿cierto?, podríamos modificar el objeto flash original para lograr el efecto que deseásemos y modificar también el objeto flash que nos estuviese bloqueando, de forma que no realizase comprobaciones claves de protección, comprobaciones de hash... y posiblemente también lo lograríamos.

¿Pros? Este método parece más simple y más cómodo, ya que podríamos realizar cualquier modificación relativamente rápidas una vez sorteadas a base de modificación de los objetos flash implicados las protecciones que pudiesen existir.

¿Contras? El código a modificar podría ser mucho, y dependería prácticamente del conocimiento en ensamblador o tener algún desensamblador que fuese realmente eficaz para saber que parte de código eliminar o añadir o modificar para hacer que el nuevo objeto flash se comportase como nosotros deseamos. Por otro lado cualquier modificación se debería reenviar a nuestro servidor y si es algo pesado tardaría. Y para acabar, trabajar de este modo implicaría conocer más o menos la estructura de la web que deseamos clonar, aunque como hemos visto, con Paros esto es muy fácil. De hecho creo que tiene opciones de Spider.


d) Trabajar en Local

Esta es la opción que recomiendo, todo son ventajas una vez se comprende el funcionamiento, aunque no deja de tener algún que otro contra, pero es la menos dependiente y con mucha diferencia la más rápida. Vamos a ver en que se basa.

Hemos dicho que en una petición Web se añade evidentemente el origen del archivo. En nuestro caso vamos a denominar este origen como "tema.theliel.es" y el archivo será desktop.swf, y lo que me gustaría sería modificar dicho archivo por el mío en una nueva pestaña sin que nadie se cosque del cambio. Imaginar que tengo montado en mi blog un enlace hacia dicho archivo, de forma que cuando hace quien sea clic en dicho enlace, se abre en su navegador otra pestaña con el contenido de dicha ubicación. Su navegador realizará la petición a "tema.theliel.es" del archivo en cuestión, y el servidor tema.theliel.es responderá con el envió de dicho archivo. Así es como funcionan las cosas. Veremos si podemos colocar el nuestro.

Podría modificar con un proxy (como paros por ejemplo) esta petición al vuelo y especificar un nuevo host? Sí, pero el problema sería el mismo, si la aplicación/juego devolviese en algún momento dicha URL estaría cazado. Vale, no puedo interceptar la URL... pero me queda algún AS en la manga? Sí.

¿Qué pasa si monto en mi PC, en Local, un servidor Web propio y hago una especie de página clon en local? Hombre, en principio debería de tener los mismos problemas que cuando lo monto en remoto... pero veremos que no es así, y que además nos ahorramos el tener que subir archivos a remoto. El problema que vamos a tener, el único contra, es que necesitaremos por lo tanto no solo los objetos flash, sino posiblemente más cosas... ya lo veremos.

¿Cómo se monta un servidor Web? Es muy simple, opción rápida, eficiente y fácil? Apache. Apache es un servidor Web completamente gratuito. Lo podemos obtener de:

AQUI (sin soporte para SSL)

La instalación es simple, podemos especificar todo por defecto en la instalación, cuando se nos pregunte por el dominio de red y el nombre del servidor pondremos: "localhost" y dejaremos el resto tal y como está, puerto 80 para todos los usuarios. El correo hace falta ponerlo, inventaros uno si lo deseáis, no importa. Instalación Típica, siguiente, siguiente...

Si todo ha ido bien, una vez terminado de instalar, si abrimos un explorador web y tecleamos en dirección: "localhost" debería de aparecer una página en blanco que ponga:

It works!

Si aparece dicho mensaje, implica que nuestro servidor web está en funcionamiento. Ya podremos colgar lo que deseemos de él. Para no complicarnos, tan solo deberemos de colocar lo que deseemos en la carpeta:

"C:\Program Files\Apache Software Fundación\Apache2.2\htdocs" -> En caso de instalación por defecto.

En la carpeta htdocs se almacenará el contenido web. Eso significa que si creo una página html llamada index.html en dicha localidad y accedo a "localhost/index.html" accederé a dicha web.

Pero hasta que punto esto es útil? A fin de cuentas tener que montar toda la web es lo mismo que lo que hacíamos antes en remoto. No, con esto ganaos dos cosas:

a) No necesidad de replicar una web completa, tan solo aquello que sea esencialmente necesario
b) trabajar en local siempre es mucho más cómodo

Aun así no hemos terminado de explicar el punto A. Vale, tenemos el servidor web Apache funcionando, en dicha carpeta tenemos el objeto flash modificado (!!OJO!! deberá tener el nombre original!! para ello lo ideal sería usar paros o cualquier otro sistema), en mi caso Desktop.swf. Y ahora qué? Si accedo a Tema.theliel.es me continúa cargando en la pestaña el archivo original, no el modificado. Lo que necesito es que cuando se solicite dicha petición se cargue el mío, y que no sea una modificación al vuelo, que podría detectarse por la misma aplicación o por un cargador. Existe algo para hacer esto? Si, se llama "Host"

En todos los sistemas operativos que conozco existe un archivo llamado "Host". Este archivo se encarga de traducir host por otros host. Es decir, es como un redireccionador automático. Este archivo se puede usar de forma inteligente en mil aspectos diferentes!! por ejemplo podríamos hacer que cada vez que solicitásemos la web de google se cargase la web de Orange, o un hacker podría modificar el archivo host de sus víctimas y modificar la web mail.live.com (Hotmail) por un Scam en otro servidor, sin que el usuario se diese cuenta, dado que la redirección se hace de forma completamente transparente, y para todos los efectos la dirección real es la real.

Cual es el secreto de esto? Que yo podría añadir una entrada en mi archivo host que redirigiese las peticiones realizadas a tema.theliel.es a localhost.

El archivo se encuentra en:

"C:\Windows\System32\Drivers\etc\" y se puede abrir con cualquier editor de texto.

la entrada sería exactamente esta:

tema.theliel.es 127.0.0.1

Es decir, todas las peticiones realizadas a tema.theliel.es equivalen de forma interna a una petición a la dirección ip 127.0.0.1, que es la dirección local, dirección de loopback. De ahí la importancia a que se mantenga el mismo nombre de archivo:

El navegador solicita el archivo desktop.swf del servidor tema.theliel.es, pero el PC reenvía en la petición en vez de a tema.theliel.es a 127.0.0.1 sin que nadie se dé cuenta, sin nada que muestre lo contrario. nuestro servidor apache recogerá la petición y devolverá el archivo solicitado, que sí está modificado. En la pestaña del navegador se abrirá el archivo swf modificado bajo la dirección de tema.theliel.es/desktop.swf e internamente para el objeto flash, se encontrará en dicha ubicación, eludiendo cualquier tipo de protección que pudiese existir.

El único problema que tiene como digo es que este proceso redirección TODAS las peticiones, es decir, para el PC cualquier referencia a dicho host la modificará por la otra (de forma interna y sin afectar de manera externa). Luego cualquier archivo que se solicitase de dicho host se debería de servir igualmente desde nuestro servidor web en local, dependiendo de cómo sea el servidor original, esto implicaría tener más o menos archivos que servir.

Si por ejemplo en vez de hacer clic en el enlace que va a desktop.swf fuese un index.html en www.theliel.es/index.html y en dicho index.html se cargase mi archivo "tema.theliel.es/desktop.swf" y otro adicional, "tema.theliel.es/background.bmp" y un montón de imágenes y cosillas cuya ubicación fuese www.thelie.es, lo que tendría que crear en mi carpeta htdocs de apache serían los archivos "background.bmp" (una copia del original) y por supuesto el archivo "desktop.swf" (modificando el original). Luego tampoco tendría que recrear la web completa. Lo mejor para saber que archivos deberíamos o no tener en local, sería usar herramientas como Paros, que ya expliqué con anterioridad. A través de él es fácil ver las dependencias por dominios, y tan solo tendríamos que tener una copia en local de los archivos descargados de dicho dominio en el que se encuentra nuestro objeto flash a modificar.

Claro que también se depende en cierta medida del servidor origen.


Y señores, hemos acabado!! Pero vamos a hacer un rápido repaso, y en conclusiones lo que puede significar todo lo que hemos explicado hasta ahora y si es cierto que se pueden realizar todas las cosas que se dijeron en un principio:


1º. Interceptar el archivo flash original, ya sea por el caché, por descarga directa.
2º. Asegurarnos de que el archivo capturado se corresponde con el objeto flash buscado
3º. Tener información acerca de dicho objeto. Está comprimido? Sin comprimir?
4º. Descomprimir el objeto flash si es un objeto flash comprimido ó desensamblarlo si se prefiere directamente
5º. Abrir dicho objeto ya descomprimido, empezando por un editor hexadecimal (recomendado) e intentando ver si es posible modificar (y sacar provecho) de lo que podamos ver a simple vista, intentando primero sin realizar grandes cambios, cambiar un 2 por un 3, un 3 por un 4...
6º. Si los cambios no son suficientes, descompilar, interpretar el código y buscar algo más claro. Después de la modificación recompilar.
7º. Montar un servidor Web con Apache
8º. Modificar el archivo Host de Windows para redireccionar el contenido deseado a nuestro propio PC como se ha indicado.
9º. Disfrutar con los cambios realizados, y si no se está confirme, volver a editar el objeto flash, volver salgarlo y volver a probar los cambios.
10º. Preguntar las dudas existentes al bueno de Theliel.



Conclusiones

Bueno, esto ya se acaba. Sí, soy consciente de que no he sido tan explícito quizás, pero en realidad la idea tanto de mí primer entrada al respecto como la segunda continua siendo lo mismo, aprender con ejemplos reales. Por tonterías de algunos pues hago las pruebas con contenido propio, pero cada cual es dueño de hacer lo que sea. Si, el título es referente a Hammerfest, lo sé, y no deja de ser una gran segunda parte para continuar aprendiendo y enseñando. Con los procedimientos que he explicado aquí, cualquiera que quisiese tendría conocimientos para modificar cualquier aspecto de HF, algunos de forma trivial quizás como el valor, la rareza... y otros a lo mejor no tan triviales en una primera lectura, pero igual de fáciles, como podría ser el enrutado de portales entre niveles o cualquier cosa que podáis imaginar. Simplemente es acudir al código del objeto flash, interpretarlo y modificarlo según nuestras necesidades.

Lo ideal sería hacerse, como me hice en mi tiempo y como publiqué en el foro oficial hace tiempo, una BD con el identificador de cada objeto, el nombre del objeto, la familia a la que pertenece, el valor, la rareza... etc etc etc. Sé que en muchas páginas encontramos información al respecto, aunque la mayoría no son del todo correctas. Todo esto haría mucho más rápido y comprensible cualquier cambio que se quisiese realizar, es normal... cuanto mejor conoces un sistema, más puedes manejarlo.

Aun así, nos vemos en los comentarios o en el Messenger, para resolver dudas, preguntas o simplemente el cabezoneo de algún bloguero, en el caso de que en investigaciones propias os quedéis atrapados o bloqueados, a fin de cuenta este mundo es un poco así, antes o después te vas a chocar con una puerta que te costará abrir.

Espero que de todo esto se aprenda algo nuevo, y con que tan solo una persona se haya quedado con algo, es suficiente y me doy por bien pagado.

Aun posiblemente tenga material para una tercera parte en la que podríamos explicar más acerca de los navegadores, flash, servidores, hash, seguridad... o incluso reescribir todas estas letras para intentar hacer la lectura más amigable... quien sabe... pero es que por increíble que parezca, uno tiene su propia vida privada, sus trabajos sus estudios... y precisamente no es que sean las mejores fechas para investigar y escribir la biblia.


Mis amigos fieles a iPod Touch e iPhone... espero no marearos demasiado con este tipo de contenido, comprendo que se sale de lo "normal". Y para el resto un saludo y para la próxima.