La cosa se pone interesante. El Dev-Team tiene en manos ya el JB y unlook para el iPhone 3GS. El problema es que para que pueda realizarse se necesita crear antes un iboot personalizado para cada iPhone, y para ello se requiere un identificador hardware de este. Lograr esto es facil, pero el problema es que tan solo se puede obtener este identificador una vez se tenga el iPhone comprado. Que sucedería si Apple lanza una revisión nueva del iBoot? Q para esas personas no se podría JB por medio del exploit que se tiene ahora mismo.
La postura es clara, no saldrá a la luz un JB de momento, eso sería darle a Apple la herramienta clara para corregir el bug en el iboot. De momento esperar a la casi segura versión 3.0.1 y ver que pasa, a fin de cuentas Apple no debería tardar en evitar el uso de UltraSn0w para el iPhone 3G, cosa que lograría actualizando el BaseBand.
Al menos no son para nada malas noticias.
martes, 30 de junio de 2009
viernes, 26 de junio de 2009
iPhone 3GS: Jailbreak!! Al menos la antesala
El Dev-Team a confirmado que el Exploit que afecta al iPod Touch Nuevo y que permite el JB, está presente también en el BootRom del iPhone 3GS. Dado que este a su vez tiene el mismo BaseBand que el iPhone 3G, de poderse realizar el JB, UltraSn0W sería igualmente válido para el iPhone 3GS, con lo que se podría liberar.
Está claro que será necesario mucho más que simplemente esto, pero esto es lo fundamental, un exploit para poder tener acceso al sistema. Y ya lo tienen.
El Dev-Team hace la reflexión de si Apple se ha cansado ya de jugar al ratón y al gato... es decir... Es premeditado? se le ha escapado? Dev-Team dice que posiblemente lo único que sucede es que Apple tenía ya preparado y terminado el que sería el bootRom del iphone 3GS, lo cual tiene su lógica si tenemos en cuenta que usa la misma plataforma que el iPod Touch nuevo. Pero por otro lado me extraña mucho que Apple sacara al mercado un producto nuevo y super la caña (según ellos) y que nada mas pisar la calle se pudiese liberar y piratear.
Para mi sinceramente está claro... el tiron de ventas no sería el mismo ni mucho menos si no se pudiese JB. Yo mismo jamás hubiese tenido un Touch de no poderse hacer.
El tiempo lo dirá... de momento la noticia es positiva
Está claro que será necesario mucho más que simplemente esto, pero esto es lo fundamental, un exploit para poder tener acceso al sistema. Y ya lo tienen.
El Dev-Team hace la reflexión de si Apple se ha cansado ya de jugar al ratón y al gato... es decir... Es premeditado? se le ha escapado? Dev-Team dice que posiblemente lo único que sucede es que Apple tenía ya preparado y terminado el que sería el bootRom del iphone 3GS, lo cual tiene su lógica si tenemos en cuenta que usa la misma plataforma que el iPod Touch nuevo. Pero por otro lado me extraña mucho que Apple sacara al mercado un producto nuevo y super la caña (según ellos) y que nada mas pisar la calle se pudiese liberar y piratear.
Para mi sinceramente está claro... el tiron de ventas no sería el mismo ni mucho menos si no se pudiese JB. Yo mismo jamás hubiese tenido un Touch de no poderse hacer.
El tiempo lo dirá... de momento la noticia es positiva
jueves, 25 de junio de 2009
Artículo: Sincronización (Parte I)
Esto es un tema que me hubiese gustado tratar de hace tiempo, pero entre el tiempo por un lado y que hasta la version 3.0 no merecía tampoco mucho la pena a tratar... vamos a intentar explicar que es la sincronización, que ventajas nos ofrece y por supuesto, como podemos hacernos la vida un poco más sencilla. Tenía pensado hacerlo en tan solo una entrega... pero ya me conoceis.
Vamos a intentar ir explicando terminos como Google Sync, mobileMe, SyncML, CalDAV, ActiveSync, LDAP...
Cada vez más, los dispositivos portátiles estan a la orden del día, cada vez con más funciones, cada vez usando más los estándares actuales pudiendo interactuar unos con ellos. ¿El problema?
Este podría ser el perfil de un trabajador de oficina:
Se levanta temprano para ir a trabajar y claro, en el bolsillo o en su maletín está claro que no faltará el móvil, es posible que incluso dos móviles, el de la empresa y el suyo. Es posible incluso que lleve una PDA en vez de teléfono móvil o incluso las dos herramientas. Tomando el café escrutina la agenda en el movil o en la PDA para refrescar en su cabeza las citas del día, y recuerda que debe de comer fuera. De camino al trabajo por tanto llama a su mujer con su movil para decirle que se quedará a comer.
Llega al trabajo y se sienta delante de su PC. ¿Lo primero? Está claro, iniciar sesión en red, revisar los cambios que se hayan podido aplicar en su agenda del día, ahora está más despierto y es más comodo verlo en una pantalla de 24'' y no en un dispositivo portatil. Redactar unos correos desde su cuenta coorporativa, una llamada al jefe y otra a su mujer de nuevo... actualiza su agenda, una cena con un potencial cliente, felicitar el aniversario a los padres... y un compañero le da el teléfono de una amiga de su mujer a quien debe de llamar para organizarle una fiesta. Por la tarde llega a su casa y se ha olvidado de redactar unos correos y recuperar unos archivos del servidor.
Llegados a este punto nuestro sujeto tiene dos opciones. Suponer que está al día él y su empresa en cuanto a tecnologías se refiere o por el contrario que ni le gusta la tecnología ni su empresa le interesa demasiado invertir en ello.
Veamos que sucede a partir de aquí suponiendo primero el segundo caso, es decir, vamos a decir no a la tecnología, por así decirlo:
Son las 7-8 de la tarde y se ha dado cuenta que debe de recoger dichos archivos y enviar dichos correos. Dado que se trata de un correo coorporativo sin acceso al exterior tampoco puede enviarlos desde casa. Deja el maletín en casa y se vuelve al trabajo. Ha tenido la mala suerte ademas de dejar en el maletín tanto la PDA como el movil de empresa, donde había apuntado en la agenda el número de la amiga de su mujer... tenía pensado ahorrar tiempo y llamarla de camino (La oficina está a 30 minutos de su casa). Llega a la oficina, arranca su PC, recupera los archivos del servidor, envia los correos pendientes... En su oficina se cruza con un amigo que le recuerda la despedida de solteros y la apunta en la agenda de su movil personal. Vuelve a casa. Cuando llega ya son las 9 largas, no es hora ya de llamar a nadie para organizar nada... ademas no recuerdas la direccion de tu compañero para enviarle un correo, dicha dirección la tienes en la oficina, en Thunderbirth, así que tendrás que esperar a mañana. Antes de acostarte, con la PDA por un lado, el PC en otro, el teléfono en otro... intentas añadir en la agenda de los demás los nuevos cambios, no quieres que se te escape nada, así como copiar el nuevo número de teléfono. Te pones una notita incluso para recordarte hacer lo mismo al llegar al trabajo, es posible que la secretaria haya añadido algo nuevo a la agenda y claro...
Es evidente que esto sería un infierno y nada productivo. Por otro lado un buen ejecutivo lo que haría sería lo siguiente:
Llegaría a casa, encendería su PC y se conectaría al servidor de su empresa por medio de una VPN. Una vez en red con la empresa, enviaría los correos necesarios y recuperaría los archivos necesarios. Mientras hace todo ello, con el movil personal buscaría en la agenda para llamar a la amiga de su mujer (cuyo número fue grabado en el movil de empresa y está en su maletín) y perfectamente aparecería el número de ella en él. Antes de irse a acostar abriría Lightning en Thunderbirth, revisaría el calendario para el día siguiente en el que ya se habrían añadido de forma automática todos los cambios del día y a dormir.
Esto puede parecer irreal para muchos. Se preguntarán que que personas necesitan coordinar 3 agendas, 4 calendarios diferentes, 5 cuentas de correos... pero es algo bastante normal. Con el correo esto pasa a diario con muchas personas que leen el correo desde sus PCs o desde sus dispositivos portátiles. IMAP nos permite precisamente eso, estar conectados desde donde sea a nuestro correo. Si lo leemos aquí lo leemos allí, si lo enviamos desde aquí recuperaré lo que he leído desde cualquier otro lado. Pero que sucede con el calendadrio, contactos, tareas...
En la actualidad por suerte existen protocolos y sistemas estándares que permiten todo esto y más. ¿Quien no tiene la agenda en su movil y por otro lado la agenda en Gmail con los contactos? O simplemente, quien no tiene dos móviles y alguna vez se ha visto en el problema de tener que pasar los contactos de uno a otro? Y el calendario? citas olvidadas porque esta la añadiste a Windows Calendar y no al calendario de tu iPod, o al revés!!. Si la solución pasa por cada vez que modifico tener que modificar en 6 sitios diferentes... mal negocio. Pues de eso vamos a hablar.
Nos vamos a centrar en tres tipos de datos: Correo, Agenda, Calendario. En realidad esto es aplicable también a las notas y otros, pero nuestro dispositivo no lo permite.
El 1-2-3 de la sincronización:
¿Que es una sincronización? Muchas veces se confunde el término. Normalmente cuando hablamos de sincronizar nos referimos a que dos dispositivos comparten su información para que esta sea la misma en un lugar y en el otro. Si un dato se crea en uno, el dato de algún modo deberá de propagarse hacia el otro dispositivo. Del mismo modo si la sincronización es bidireccional, cualquier cambio realizado en el otro dispositivo se deberá de propagar al nuestro. No solo añadir un dato, lo mismo cuando se modifica, se elimina...
Para esto existen una serie de protocolos y sistemas, algunos de ellos los iremos viendo. Pero antes de entrar en ellos cabe destacar como muy importante lo siguiente.
Aunque existen sistemas para sincronizar datos (ahora los veremos), una de las preguntas inmediatas es ¿Cómo se realiza? Está claro que para que exista una sincronización, del tipo que sea, es necesario acceder al servicio. Cuando por ejemplo abrimos el correo que es lo ¿que estamos haciendo? Enviando datos a nuestro servidor para solicitar la sincronización. Esto es un problema en entornos en los que se necesita tener acceso a la información casi al instante de que esta sea modificada. Imaginar que estamos esperando un correo muy importante. Claro, la solución pasaría por comprobar el correo cada cuanto... 10 segundos? 30 segundos?... Esto para un PC no es un problema, como si queremos comprobarlo cada 10 segundos como si comprobamos cada una hora. Pero imaginar esto en un dispositivo portatil... sería impensable. Aquí podríamos por lo tanto dividir dos tipos de accesos a nuestros datos a sincronizar:
-Polling:
Entenderemos Polling por preguntar. Es el sistema que probablemente use la gran mayoría de las personas, y ojo, no significa que sea malo. Simplemente cuando deseamos obtener la información que sea, ya sea una sincronización o no, solicitamos a nuestro servidor por los nuevos datos. El servidor recoje nuestra petición y nos responde. Cada vez que queramos conocer si tenemso algún dato nuevo, deberemos volver a preguntar. Esto puede ser tedioso si queremos un correo con urgencia o mucho peor... en los dispositivos portátiles. A día de hoy disponemos de una infraestructura inalámbrica muy grande. Tenemos dispositivos 3G, WIFI... en cambio el problema del consumo continua estando presente, y con consumo me refiero a el pago por las tarifas a estas líneas como al consumo de la batería por utilizar dichos recursos.
Realizar Polling implica un consumo de ancho de banda considerable. Imaginar que se configura nuestro cliente de correo para comprobar por correos nuevos cada 1 minuto. Cada minuto una nueva petición, una nueva contestación del servidor. En el caso de que la contestación sea: "No hay datos" la petición ha sido inutil, y esto se repetirá cada minuto. Y además, tan solo tendremos la certeza de tener el mail buscado con un margen temporal de retraso de 1 minuto. Claro que un minuto puede ser poco tiempo... o puede ser un tiempo precioso dependiendo de la urgencia del mensaje. Por otro lado pensar en la gran cantidad de ancho de banda desperdiciado cada minuto, e igualmente del consumo de la batería que llevaría a un dispositivo portatil hacer uso de una red 3G o de WIFI para enviar cada petición. En caso de 3G... el dineral que podría costar un sistema por Polling de un minuto...
-Push
En el otro lado tenemos Push. Push se concibe como el proceso contrario a Polling. Se supone que Polling es un sistema en el que el cliente contacta con el servidor para requerir nuvos datos. Con Push la idea es que será el servidor quien se ponga en contacto con el cliente cuando tenga un dato nuevo. Esto en realidad no es tan simple como puede parecer, puesto que existen muchísimos problemas de otra índole. Antes de entrar en los posibles problemas, las ventajas están claras. Imaginemos Push como un método ideal... nuestro dispositivo simplemente tendría conexión a la red sin hacer uso del ancho de banda y sin estar enviando o recibiendo paquetes, con lo que el consumo de batería lo agradecería enormemente. Llega un correo nuevo a nuestro servidor, nuestro servidor directamente nos envia el correo a nuestro dispositivo y no solo lo tenemos al instante, sino que no tenemos que estar preguntando cada dos por tres, el único ancho de banda que se ha gastado es la recepción del correo.
La mala noticia es que esto no es tan idealista. Evidentemente para que esto pueda hacerse, es necesario que el sevidor se encuentre conectado de algún modo al cliente antes de que el servidor reciba el dato que desea enviar a su vez al cliente. Esto es un problema múltiple. Para que esto sea posible el servidor debería de suponer que siempre conoce nuestra IP, que siempre presupone que hay una regla en el firwall de nuestra red que permita paquetes entrantes sin ser solicitados a nuestro dispositivo, que suponga que nuestro dispositivo estará 24 horas al día disponible... y evidentemente estos supuestos son impensables. ¿En teoría? En teoría sería posible construir un sistema completamente Push... pero no es viable. No obstante estos problemas se atenuan en lo que se pueden.
El problema de la IP siempre será un problema... pero si suponemos que son dispositivos portátiles, las redes 3G suelen otorgar una IP consistente, y suelen estar conectados a la red con dicha IP por mucho tiempo. Con lo que con que al entrar en la red el teléfono o el dispositivo enviara un reconocimiento al servidor, sería suficiente, pero aun así esto implicaría peticiones al servidor, con lo qeu siempre conyeba un tráfico
Por otro lado que nuestro dispositivo esté siempre operativo no puede solucionarse. Se puede imaginar que siempre lo estará, dado que podemos cargarlos mientras se encuentran encendidos... pero es una presunción tan solo. Se deberían implementar mecanismos en los que al apagarse y encender dar a conocer su estado al servidor, lo que conyeva tráfico de datos, lo que se aleja del idealismo de Push
Pero quizás el problema mayor es el de los FireWalls. Si nuestro servidor supiese tan solo con una petición inicial nuestra IP asociada a una cuenta y que nuestro dispositivo se encontrará disponible en las próximas 48 horas (por ejemplo), estaría solucionado. Cuando tan solo tuviese un dato nuevo lo reenviaría a la IP asociada a dicha cuenta y fin del problema. Pero esto en la vida real sería impensable en cuanto a seguridad. Por seguridad, lo normal es que cualquier firewall por pequeño que sea filtre cualquier acceso que no haya sido solicitado. A esto se le llama SPI, es decir, un analizador de los paquetes que entran y salen. Si un paquete llega al dispositivo, ya sea un router o sea un dispositivo final, lo normal es que su firewall compruebe si dicho dispositivo solicitó dicha transferencia. Si no es así el paquete se descarta. Esto es similar (no igual) a cualquier router que opere con NAT. Es evidente que si nos encontrásemos en esta situación (que sucederá muchísimas veces) el problema se complica radicalmente, porque nos obligaría a realizar antes una conexión al servidor para que este nos respondiese. ¿Se puede hacer algo para evitar esto? Sí y no.
Que se me ocurran podrían exister 3 soluciones:
La primera es simplemente deshabilitar cualquier tipo de firewall o NAT en la red a la que estamos conectados, aunque evidentemente esto sería una locura!! un dispositivo abierto completamente a una red?? Claro que en el caso de dispositivos portátiles no vamos a ir instalando Firewalls, pero nuestro router por malo que sea implementara NAT o SPI o los dos. Yo personalmente no lo haría, claro que si estamos conectados a una red 3G el problema no depende de nosotros si este tiene un firewall en sus sistemas, y vuelvo a repetir, que espero enormemente que los tengan, sino hackear un dispositivo portatil conectado por 3G sería coser y cantar, sobre todo cuando cada vez más se usan antenas 3G para los portátiles y otros.
La segunda opción sería menos drástico y simplemente abrir un puerto en nuestros firewall o el firewall de la compañía para permitir cierto tipo de tráfico dirigido a un puerto en concreto. Pero claro... esto tiene el inconveniente que tendríamos que andar configurando nuestros dispositivoos en primer lugar para permitir dichas conexiones, y evidentemente las operadoras deberían especificar con que estandar ellas serían compatibles y en fin... y aun así sería un problema grave de seguridad, un puerto abierto equivale a una brecha por la que se pueden obtener muchísimos datos... más de los deseados.
La tercera opción es la que se suele implementar... rendirnos a la evidencia que usar conexioens directas no es viable en dispositivos portátiles, aunque podría ser la mejor opcion para entornos empresariales y usar dichos sistemas para una red LAN. Pero para dispositivos que pueden conectarse a diferentes redes en diferentes sitios... Aceptar esto, y solucionarlo de la mejor manera posible. Lo que se intenta es mantener una conexión entre servidor y cliente el máximo tiempo posible. Es decir, efectivamente es el cliente quien nada más comenzar solicita acceder al servidor. Pero por el contrario, este no responde, sino que se queda esperando hasta recibir nuevos datos para responder. Cuando el servidor tiene el dato nuevo lo envia como contestación a la petición que a lo mejor se realizó 60 minitos antes, y el correo continua llegando justo en el mismo momento en el que el servidor lo recibe. Una vez el dato llega al cliente, este solicitaría inmediatamente otra petición al servidor y de nuevo se mantendría la conexión el máximo tiempo posible. ¿Inconvenientes? Evidentemente hay muchas peticiones por parte del cliente, una por cada dato recibido más la final, en el mejor de los casos. Digo en el mejor de los casos porque una conexión no se puede mantener activa indefinidamente. Esto ya es algo que depende de la configuración de cada aplicación, dispositivos, routers... por ejemplo, ¿cuanto tiempo es capaz un router de mantener en su tablas NAT o SPI la petición? Está claro que en muchos podrás configurarlo, pero en otros no. Con lo que se debe de establecer un tiempo mínimo y máximo para ello. Después de que ese tiempo se cumpla, si el cliente no recibió ningún dato debería de enviar un paquete al menos tipo Keep-Alive para mantener el canal abierto. A lo mejor no consume tanto como un paquete de datos, pero algo así.
Aun pese a todo, está claro que las virtudes de usar Push en dispositivos de este tipo son muchísimas. En cualquier caso el dato siempre es recivido en el mismo momento en el que llega a nuestro servidor y es evidente que en el peor de los casos, las peticiones realizadas son muchísimo menores que usando Polling. Es evidente que se tendría que buscar cual es el tiempo máximo para no cortar la conexión y otros menesteres, pero continua siedo una opción mucho más ventajosa. Es evidente que tiene un consumo de batería (en caso de dispositivos portátiles) y un consumo de ancho de banda, que sea inferior o no depende tan solo de la implementación y el sistema. Podría ser un sistema Push que andara actualizando las conexiones cada 10 minutos, con lo que a lo mejor en igualdad de condiciones, un Polling de 15 minutos tampoco supondría un consuno excesivo frente al primero.
Evidentemente existen alternativas completamente Push, pero como he dicho en un principio esto no es viable desde mi punto de vista, pero se usa en la actualizada. El método más común es tan solo para dispositivos tipo teléfonos, en los que el servidor envia un SMS al movil del usuario para indicarle que tiene un correo nuevo, y el movil es capaz de autoreconocer dicho sms y conectarse al servidor por 3G o cualquier otra tecnología. La ventaja está clara, notificación al instante y nunca hay ancho de banda desperdiciado ni consumo energético en ello. Evidentemente si hay una infrastructura mayor y SMS involucrados en ello.
Con esto aprendido podemos pasar al siguiente capítulo
Vamos a intentar ir explicando terminos como Google Sync, mobileMe, SyncML, CalDAV, ActiveSync, LDAP...
Cada vez más, los dispositivos portátiles estan a la orden del día, cada vez con más funciones, cada vez usando más los estándares actuales pudiendo interactuar unos con ellos. ¿El problema?
Este podría ser el perfil de un trabajador de oficina:
Se levanta temprano para ir a trabajar y claro, en el bolsillo o en su maletín está claro que no faltará el móvil, es posible que incluso dos móviles, el de la empresa y el suyo. Es posible incluso que lleve una PDA en vez de teléfono móvil o incluso las dos herramientas. Tomando el café escrutina la agenda en el movil o en la PDA para refrescar en su cabeza las citas del día, y recuerda que debe de comer fuera. De camino al trabajo por tanto llama a su mujer con su movil para decirle que se quedará a comer.
Llega al trabajo y se sienta delante de su PC. ¿Lo primero? Está claro, iniciar sesión en red, revisar los cambios que se hayan podido aplicar en su agenda del día, ahora está más despierto y es más comodo verlo en una pantalla de 24'' y no en un dispositivo portatil. Redactar unos correos desde su cuenta coorporativa, una llamada al jefe y otra a su mujer de nuevo... actualiza su agenda, una cena con un potencial cliente, felicitar el aniversario a los padres... y un compañero le da el teléfono de una amiga de su mujer a quien debe de llamar para organizarle una fiesta. Por la tarde llega a su casa y se ha olvidado de redactar unos correos y recuperar unos archivos del servidor.
Llegados a este punto nuestro sujeto tiene dos opciones. Suponer que está al día él y su empresa en cuanto a tecnologías se refiere o por el contrario que ni le gusta la tecnología ni su empresa le interesa demasiado invertir en ello.
Veamos que sucede a partir de aquí suponiendo primero el segundo caso, es decir, vamos a decir no a la tecnología, por así decirlo:
Son las 7-8 de la tarde y se ha dado cuenta que debe de recoger dichos archivos y enviar dichos correos. Dado que se trata de un correo coorporativo sin acceso al exterior tampoco puede enviarlos desde casa. Deja el maletín en casa y se vuelve al trabajo. Ha tenido la mala suerte ademas de dejar en el maletín tanto la PDA como el movil de empresa, donde había apuntado en la agenda el número de la amiga de su mujer... tenía pensado ahorrar tiempo y llamarla de camino (La oficina está a 30 minutos de su casa). Llega a la oficina, arranca su PC, recupera los archivos del servidor, envia los correos pendientes... En su oficina se cruza con un amigo que le recuerda la despedida de solteros y la apunta en la agenda de su movil personal. Vuelve a casa. Cuando llega ya son las 9 largas, no es hora ya de llamar a nadie para organizar nada... ademas no recuerdas la direccion de tu compañero para enviarle un correo, dicha dirección la tienes en la oficina, en Thunderbirth, así que tendrás que esperar a mañana. Antes de acostarte, con la PDA por un lado, el PC en otro, el teléfono en otro... intentas añadir en la agenda de los demás los nuevos cambios, no quieres que se te escape nada, así como copiar el nuevo número de teléfono. Te pones una notita incluso para recordarte hacer lo mismo al llegar al trabajo, es posible que la secretaria haya añadido algo nuevo a la agenda y claro...
Es evidente que esto sería un infierno y nada productivo. Por otro lado un buen ejecutivo lo que haría sería lo siguiente:
Llegaría a casa, encendería su PC y se conectaría al servidor de su empresa por medio de una VPN. Una vez en red con la empresa, enviaría los correos necesarios y recuperaría los archivos necesarios. Mientras hace todo ello, con el movil personal buscaría en la agenda para llamar a la amiga de su mujer (cuyo número fue grabado en el movil de empresa y está en su maletín) y perfectamente aparecería el número de ella en él. Antes de irse a acostar abriría Lightning en Thunderbirth, revisaría el calendario para el día siguiente en el que ya se habrían añadido de forma automática todos los cambios del día y a dormir.
Esto puede parecer irreal para muchos. Se preguntarán que que personas necesitan coordinar 3 agendas, 4 calendarios diferentes, 5 cuentas de correos... pero es algo bastante normal. Con el correo esto pasa a diario con muchas personas que leen el correo desde sus PCs o desde sus dispositivos portátiles. IMAP nos permite precisamente eso, estar conectados desde donde sea a nuestro correo. Si lo leemos aquí lo leemos allí, si lo enviamos desde aquí recuperaré lo que he leído desde cualquier otro lado. Pero que sucede con el calendadrio, contactos, tareas...
En la actualidad por suerte existen protocolos y sistemas estándares que permiten todo esto y más. ¿Quien no tiene la agenda en su movil y por otro lado la agenda en Gmail con los contactos? O simplemente, quien no tiene dos móviles y alguna vez se ha visto en el problema de tener que pasar los contactos de uno a otro? Y el calendario? citas olvidadas porque esta la añadiste a Windows Calendar y no al calendario de tu iPod, o al revés!!. Si la solución pasa por cada vez que modifico tener que modificar en 6 sitios diferentes... mal negocio. Pues de eso vamos a hablar.
Nos vamos a centrar en tres tipos de datos: Correo, Agenda, Calendario. En realidad esto es aplicable también a las notas y otros, pero nuestro dispositivo no lo permite.
El 1-2-3 de la sincronización:
¿Que es una sincronización? Muchas veces se confunde el término. Normalmente cuando hablamos de sincronizar nos referimos a que dos dispositivos comparten su información para que esta sea la misma en un lugar y en el otro. Si un dato se crea en uno, el dato de algún modo deberá de propagarse hacia el otro dispositivo. Del mismo modo si la sincronización es bidireccional, cualquier cambio realizado en el otro dispositivo se deberá de propagar al nuestro. No solo añadir un dato, lo mismo cuando se modifica, se elimina...
Para esto existen una serie de protocolos y sistemas, algunos de ellos los iremos viendo. Pero antes de entrar en ellos cabe destacar como muy importante lo siguiente.
Aunque existen sistemas para sincronizar datos (ahora los veremos), una de las preguntas inmediatas es ¿Cómo se realiza? Está claro que para que exista una sincronización, del tipo que sea, es necesario acceder al servicio. Cuando por ejemplo abrimos el correo que es lo ¿que estamos haciendo? Enviando datos a nuestro servidor para solicitar la sincronización. Esto es un problema en entornos en los que se necesita tener acceso a la información casi al instante de que esta sea modificada. Imaginar que estamos esperando un correo muy importante. Claro, la solución pasaría por comprobar el correo cada cuanto... 10 segundos? 30 segundos?... Esto para un PC no es un problema, como si queremos comprobarlo cada 10 segundos como si comprobamos cada una hora. Pero imaginar esto en un dispositivo portatil... sería impensable. Aquí podríamos por lo tanto dividir dos tipos de accesos a nuestros datos a sincronizar:
-Polling:
Entenderemos Polling por preguntar. Es el sistema que probablemente use la gran mayoría de las personas, y ojo, no significa que sea malo. Simplemente cuando deseamos obtener la información que sea, ya sea una sincronización o no, solicitamos a nuestro servidor por los nuevos datos. El servidor recoje nuestra petición y nos responde. Cada vez que queramos conocer si tenemso algún dato nuevo, deberemos volver a preguntar. Esto puede ser tedioso si queremos un correo con urgencia o mucho peor... en los dispositivos portátiles. A día de hoy disponemos de una infraestructura inalámbrica muy grande. Tenemos dispositivos 3G, WIFI... en cambio el problema del consumo continua estando presente, y con consumo me refiero a el pago por las tarifas a estas líneas como al consumo de la batería por utilizar dichos recursos.
Realizar Polling implica un consumo de ancho de banda considerable. Imaginar que se configura nuestro cliente de correo para comprobar por correos nuevos cada 1 minuto. Cada minuto una nueva petición, una nueva contestación del servidor. En el caso de que la contestación sea: "No hay datos" la petición ha sido inutil, y esto se repetirá cada minuto. Y además, tan solo tendremos la certeza de tener el mail buscado con un margen temporal de retraso de 1 minuto. Claro que un minuto puede ser poco tiempo... o puede ser un tiempo precioso dependiendo de la urgencia del mensaje. Por otro lado pensar en la gran cantidad de ancho de banda desperdiciado cada minuto, e igualmente del consumo de la batería que llevaría a un dispositivo portatil hacer uso de una red 3G o de WIFI para enviar cada petición. En caso de 3G... el dineral que podría costar un sistema por Polling de un minuto...
-Push
En el otro lado tenemos Push. Push se concibe como el proceso contrario a Polling. Se supone que Polling es un sistema en el que el cliente contacta con el servidor para requerir nuvos datos. Con Push la idea es que será el servidor quien se ponga en contacto con el cliente cuando tenga un dato nuevo. Esto en realidad no es tan simple como puede parecer, puesto que existen muchísimos problemas de otra índole. Antes de entrar en los posibles problemas, las ventajas están claras. Imaginemos Push como un método ideal... nuestro dispositivo simplemente tendría conexión a la red sin hacer uso del ancho de banda y sin estar enviando o recibiendo paquetes, con lo que el consumo de batería lo agradecería enormemente. Llega un correo nuevo a nuestro servidor, nuestro servidor directamente nos envia el correo a nuestro dispositivo y no solo lo tenemos al instante, sino que no tenemos que estar preguntando cada dos por tres, el único ancho de banda que se ha gastado es la recepción del correo.
La mala noticia es que esto no es tan idealista. Evidentemente para que esto pueda hacerse, es necesario que el sevidor se encuentre conectado de algún modo al cliente antes de que el servidor reciba el dato que desea enviar a su vez al cliente. Esto es un problema múltiple. Para que esto sea posible el servidor debería de suponer que siempre conoce nuestra IP, que siempre presupone que hay una regla en el firwall de nuestra red que permita paquetes entrantes sin ser solicitados a nuestro dispositivo, que suponga que nuestro dispositivo estará 24 horas al día disponible... y evidentemente estos supuestos son impensables. ¿En teoría? En teoría sería posible construir un sistema completamente Push... pero no es viable. No obstante estos problemas se atenuan en lo que se pueden.
El problema de la IP siempre será un problema... pero si suponemos que son dispositivos portátiles, las redes 3G suelen otorgar una IP consistente, y suelen estar conectados a la red con dicha IP por mucho tiempo. Con lo que con que al entrar en la red el teléfono o el dispositivo enviara un reconocimiento al servidor, sería suficiente, pero aun así esto implicaría peticiones al servidor, con lo qeu siempre conyeba un tráfico
Por otro lado que nuestro dispositivo esté siempre operativo no puede solucionarse. Se puede imaginar que siempre lo estará, dado que podemos cargarlos mientras se encuentran encendidos... pero es una presunción tan solo. Se deberían implementar mecanismos en los que al apagarse y encender dar a conocer su estado al servidor, lo que conyeva tráfico de datos, lo que se aleja del idealismo de Push
Pero quizás el problema mayor es el de los FireWalls. Si nuestro servidor supiese tan solo con una petición inicial nuestra IP asociada a una cuenta y que nuestro dispositivo se encontrará disponible en las próximas 48 horas (por ejemplo), estaría solucionado. Cuando tan solo tuviese un dato nuevo lo reenviaría a la IP asociada a dicha cuenta y fin del problema. Pero esto en la vida real sería impensable en cuanto a seguridad. Por seguridad, lo normal es que cualquier firewall por pequeño que sea filtre cualquier acceso que no haya sido solicitado. A esto se le llama SPI, es decir, un analizador de los paquetes que entran y salen. Si un paquete llega al dispositivo, ya sea un router o sea un dispositivo final, lo normal es que su firewall compruebe si dicho dispositivo solicitó dicha transferencia. Si no es así el paquete se descarta. Esto es similar (no igual) a cualquier router que opere con NAT. Es evidente que si nos encontrásemos en esta situación (que sucederá muchísimas veces) el problema se complica radicalmente, porque nos obligaría a realizar antes una conexión al servidor para que este nos respondiese. ¿Se puede hacer algo para evitar esto? Sí y no.
Que se me ocurran podrían exister 3 soluciones:
La primera es simplemente deshabilitar cualquier tipo de firewall o NAT en la red a la que estamos conectados, aunque evidentemente esto sería una locura!! un dispositivo abierto completamente a una red?? Claro que en el caso de dispositivos portátiles no vamos a ir instalando Firewalls, pero nuestro router por malo que sea implementara NAT o SPI o los dos. Yo personalmente no lo haría, claro que si estamos conectados a una red 3G el problema no depende de nosotros si este tiene un firewall en sus sistemas, y vuelvo a repetir, que espero enormemente que los tengan, sino hackear un dispositivo portatil conectado por 3G sería coser y cantar, sobre todo cuando cada vez más se usan antenas 3G para los portátiles y otros.
La segunda opción sería menos drástico y simplemente abrir un puerto en nuestros firewall o el firewall de la compañía para permitir cierto tipo de tráfico dirigido a un puerto en concreto. Pero claro... esto tiene el inconveniente que tendríamos que andar configurando nuestros dispositivoos en primer lugar para permitir dichas conexiones, y evidentemente las operadoras deberían especificar con que estandar ellas serían compatibles y en fin... y aun así sería un problema grave de seguridad, un puerto abierto equivale a una brecha por la que se pueden obtener muchísimos datos... más de los deseados.
La tercera opción es la que se suele implementar... rendirnos a la evidencia que usar conexioens directas no es viable en dispositivos portátiles, aunque podría ser la mejor opcion para entornos empresariales y usar dichos sistemas para una red LAN. Pero para dispositivos que pueden conectarse a diferentes redes en diferentes sitios... Aceptar esto, y solucionarlo de la mejor manera posible. Lo que se intenta es mantener una conexión entre servidor y cliente el máximo tiempo posible. Es decir, efectivamente es el cliente quien nada más comenzar solicita acceder al servidor. Pero por el contrario, este no responde, sino que se queda esperando hasta recibir nuevos datos para responder. Cuando el servidor tiene el dato nuevo lo envia como contestación a la petición que a lo mejor se realizó 60 minitos antes, y el correo continua llegando justo en el mismo momento en el que el servidor lo recibe. Una vez el dato llega al cliente, este solicitaría inmediatamente otra petición al servidor y de nuevo se mantendría la conexión el máximo tiempo posible. ¿Inconvenientes? Evidentemente hay muchas peticiones por parte del cliente, una por cada dato recibido más la final, en el mejor de los casos. Digo en el mejor de los casos porque una conexión no se puede mantener activa indefinidamente. Esto ya es algo que depende de la configuración de cada aplicación, dispositivos, routers... por ejemplo, ¿cuanto tiempo es capaz un router de mantener en su tablas NAT o SPI la petición? Está claro que en muchos podrás configurarlo, pero en otros no. Con lo que se debe de establecer un tiempo mínimo y máximo para ello. Después de que ese tiempo se cumpla, si el cliente no recibió ningún dato debería de enviar un paquete al menos tipo Keep-Alive para mantener el canal abierto. A lo mejor no consume tanto como un paquete de datos, pero algo así.
Aun pese a todo, está claro que las virtudes de usar Push en dispositivos de este tipo son muchísimas. En cualquier caso el dato siempre es recivido en el mismo momento en el que llega a nuestro servidor y es evidente que en el peor de los casos, las peticiones realizadas son muchísimo menores que usando Polling. Es evidente que se tendría que buscar cual es el tiempo máximo para no cortar la conexión y otros menesteres, pero continua siedo una opción mucho más ventajosa. Es evidente que tiene un consumo de batería (en caso de dispositivos portátiles) y un consumo de ancho de banda, que sea inferior o no depende tan solo de la implementación y el sistema. Podría ser un sistema Push que andara actualizando las conexiones cada 10 minutos, con lo que a lo mejor en igualdad de condiciones, un Polling de 15 minutos tampoco supondría un consuno excesivo frente al primero.
Evidentemente existen alternativas completamente Push, pero como he dicho en un principio esto no es viable desde mi punto de vista, pero se usa en la actualizada. El método más común es tan solo para dispositivos tipo teléfonos, en los que el servidor envia un SMS al movil del usuario para indicarle que tiene un correo nuevo, y el movil es capaz de autoreconocer dicho sms y conectarse al servidor por 3G o cualquier otra tecnología. La ventaja está clara, notificación al instante y nunca hay ancho de banda desperdiciado ni consumo energético en ello. Evidentemente si hay una infrastructura mayor y SMS involucrados en ello.
Con esto aprendido podemos pasar al siguiente capítulo
miércoles, 24 de junio de 2009
Firmware 3.0: UltraSn0w
Una entrada rápida, clara y concisa:
UltraSn0w = Unlock iPhone 3G 3.0 con la baseband de la firmware 3.0
Para ello añadir a Cydia siguiente repositorio:
repo666.ultrasn0w.com
e Instalar Ultrasn0w.
Fácil verdad?
UltraSn0w = Unlock iPhone 3G 3.0 con la baseband de la firmware 3.0
Para ello añadir a Cydia siguiente repositorio:
repo666.ultrasn0w.com
e Instalar Ultrasn0w.
Fácil verdad?
domingo, 21 de junio de 2009
Firmware 3.0: Al Descubierto (II) Sin terminar
Poco a poco voy a ir rellenando esta entrada con los cambios que vaya encontrando en la Firmware 3.0, y cada vez más de forma ordenada, escribiendo por fin una entrada coherente.
Idiomas y diccionarios añadidos:
Argentino (ar)
Checo (cs)
Griego (el)
Croata (hr)
Hebreo (he)
Indonesio (id)
Malayo (ms)
Rumano (ro)
Eslovaco (sk)
Thai (th)
Mis Scripts:
Eliminar espacio/archivos -> Actualiado con nuevos diccionarios, otros logs e idiomas. Por añadir archivos específicos de cada dispositivo.
Eliminar Demonios "inservibles" para salvar RAM -> CommCenter y accesoryd. Verificar mdns
Copia/Restauración Seguridad -> Actualizado
Incompatibilidades:
Formato Agenda y Calendario 2.X -> Incompatible con 3.X -> Convertir a 3.0 mis backup
Seguridad:
Puertos, Conexiones:
TCP 22 (SSH)
TCP 62078 (iPhone-sync)
UDP 5353 (ZeroConf)
Apple Kill? -> Aun por comprobar
User Agent Safati-> Mozilla/5.0 (iPod; U; CPU iPhone OS 3_0 like Mac OS X; es-es) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16
User Agent Cydia -> Telesphoreo APT-HTTP/1.0.592
MobilleInstalation 2.X-> Installd 3.X -> Ver, estudiar y modificar
RegionalVolumeLimits.plist 2.x = 3.x
Idiomas y diccionarios añadidos:
Argentino (ar)
Checo (cs)
Griego (el)
Croata (hr)
Hebreo (he)
Indonesio (id)
Malayo (ms)
Rumano (ro)
Eslovaco (sk)
Thai (th)
Mis Scripts:
Eliminar espacio/archivos -> Actualiado con nuevos diccionarios, otros logs e idiomas. Por añadir archivos específicos de cada dispositivo.
Eliminar Demonios "inservibles" para salvar RAM -> CommCenter y accesoryd. Verificar mdns
Copia/Restauración Seguridad -> Actualizado
Incompatibilidades:
Formato Agenda y Calendario 2.X -> Incompatible con 3.X -> Convertir a 3.0 mis backup
Seguridad:
Puertos, Conexiones:
TCP 22 (SSH)
TCP 62078 (iPhone-sync)
UDP 5353 (ZeroConf)
Apple Kill? -> Aun por comprobar
User Agent Safati-> Mozilla/5.0 (iPod; U; CPU iPhone OS 3_0 like Mac OS X; es-es) AppleWebKit/528.18 (KHTML, like Gecko) Version/4.0 Mobile/7A341 Safari/528.16
User Agent Cydia -> Telesphoreo APT-HTTP/1.0.592
MobilleInstalation 2.X-> Installd 3.X -> Ver, estudiar y modificar
RegionalVolumeLimits.plist 2.x = 3.x
sábado, 20 de junio de 2009
Firmware 3.0: JailBreak -> RedSn0w (Actualizado)
Aun no ha salido QuickPwn para windows, pero si tenemos disponible redsn0w, que tambien nos valdrá para realizar el JB:
Que puede hacer RedSn0w:
JB iPod Touch nuevo y viejo
JB iPhone 2G y 3G
Unlock iPhone 2G
Uso? es la esencia mínima, ejecutar y listo, un muy breve paso a paso y se acabó.
RedSn0w 0.7.2
Creo que no hace falta siquiera que haga un paso a paso:
1º. Restaurar a la 3.0
2º. Ejecutar RedSn0W
3º. Decirle la ruta de la firmware 3.0 cuando la solicite
4º. Decir que si a Cydia
5º. Siguiente, Siguiente...
Ya me han preguntado varias que que pasará con MobileInstallation.
Bueno, aun no me ha dado tiempo ni siquiera de verlo, supongo que Apple usará el mismo sistema y sería igual de simple, educativamente, crear un MobileInstallation 3.0. Ni que decir tiene que no se os ocurra usar una version anterior. Si apple usa el mismo sistema debería de ser simple... dependiendo de la afluencia de personas que quieran ver como hacerlo haré una guía o no, recordar que distribuir software modificado es ilegal, y pese a lo que penseis, no estoy de acuerdo con la piratería de software.
Notas: Si se queda redSn0w congelado en "Waiting For Reboot" o una vez finalizado la pantalla permanece oscura y poco más, es debido a la configuración de los USB:
a) Probar en otro USB, a poder ser que no esté en un HUB
b) Si persiste, en otro PC
Que puede hacer RedSn0w:
JB iPod Touch nuevo y viejo
JB iPhone 2G y 3G
Unlock iPhone 2G
Uso? es la esencia mínima, ejecutar y listo, un muy breve paso a paso y se acabó.
RedSn0w 0.7.2
Creo que no hace falta siquiera que haga un paso a paso:
1º. Restaurar a la 3.0
2º. Ejecutar RedSn0W
3º. Decirle la ruta de la firmware 3.0 cuando la solicite
4º. Decir que si a Cydia
5º. Siguiente, Siguiente...
Ya me han preguntado varias que que pasará con MobileInstallation.
Bueno, aun no me ha dado tiempo ni siquiera de verlo, supongo que Apple usará el mismo sistema y sería igual de simple, educativamente, crear un MobileInstallation 3.0. Ni que decir tiene que no se os ocurra usar una version anterior. Si apple usa el mismo sistema debería de ser simple... dependiendo de la afluencia de personas que quieran ver como hacerlo haré una guía o no, recordar que distribuir software modificado es ilegal, y pese a lo que penseis, no estoy de acuerdo con la piratería de software.
Notas: Si se queda redSn0w congelado en "Waiting For Reboot" o una vez finalizado la pantalla permanece oscura y poco más, es debido a la configuración de los USB:
a) Probar en otro USB, a poder ser que no esté en un HUB
b) Si persiste, en otro PC
viernes, 19 de junio de 2009
Firmware 3.0: JailBreak
Listo, después de un par de días tardes. Vamos por partes... siempre recomiendo lo mismo, partir de un iPod Touch/iPhone recien restaurado a la 3.0
En el momento de escribir este post tan solo está disponible Pwnage tools, así que los usuarios de Windows aun tenemos que esperar un poco para QuickPwn (muy poco diría yo)
Por otro lado POR AHORA!! esta versión tan solo soporta:
JailBreak:
iPhone 2G
iPhone 3G
iPod Touch Viejo
unlook:
iPhone 2G
Por ahora no soportado:
JailBreak:
Touch Nuevo
unlook:
iPhone 3G
-------------------------------------
Claro verdad?
el unlock de los iPhone 3G se llevará a cabo por una instalación desde Cydia de UltraSn0w
el JB de los iPod Touch nuevos se llevará a cabo con una revisión (posiblemente) de Pwnage
Para los usuarios de Windows, esperar un poco. Como siempre no voy a dar soporte para MAC OS, con lo que tan solo hago el favor de poneros un link hacia Pwnage Tools:
Pwnage Tool (Si da error, esperar, que se está terminando de subir)
El problemilla con YT se ha corregido también.
En el momento de escribir este post tan solo está disponible Pwnage tools, así que los usuarios de Windows aun tenemos que esperar un poco para QuickPwn (muy poco diría yo)
Por otro lado POR AHORA!! esta versión tan solo soporta:
JailBreak:
iPhone 2G
iPhone 3G
iPod Touch Viejo
unlook:
iPhone 2G
Por ahora no soportado:
JailBreak:
Touch Nuevo
unlook:
iPhone 3G
-------------------------------------
Claro verdad?
el unlock de los iPhone 3G se llevará a cabo por una instalación desde Cydia de UltraSn0w
el JB de los iPod Touch nuevos se llevará a cabo con una revisión (posiblemente) de Pwnage
Para los usuarios de Windows, esperar un poco. Como siempre no voy a dar soporte para MAC OS, con lo que tan solo hago el favor de poneros un link hacia Pwnage Tools:
Pwnage Tool (Si da error, esperar, que se está terminando de subir)
El problemilla con YT se ha corregido también.
jueves, 18 de junio de 2009
Artículo: ¿Por qué podemos tener acceso a la firmware de pago del iPod Touch?
Muchos me preguntan que de donde se obtienen las firmwares de Apple, que como podemos tener tan pronto los enlaces a sus descargas que si como pueden filtrarse en el caso del iPod Touch que Apple la vende... Vamos a explicarlo:
Antes de empezar, recuerdo por cierto que quienes tengan intención de actualizar o restaurar sus iPhone o iPod Touch con las versiones 3.0 que se filtraron antes del lanzamiento oficial... os aviso que os abstengais, no son las mismas aunque recen ser la misma revisión.
Y a lo que vamos.
Apple usa un sistema simple pero eficiente para llevar a cabo las actualizaciones de sus dispositivos a través de iTunes, desde las firmwares de los iPod, iPod Touch o iPhone o incluso los perfiles de los operadores del iPhone.
Cuando estas en iTunes, este comprueba si existen actualizaciones, ¿cómo? simplemente accede a un xml y lo revisa. Este XML contiene la información de cada una de las firmwares y la documentación adjunta a cada una de ellas, así como los enlaces a cada una de las firmwares. iTunes solo tiene que acceder y buscar si existe una versión superior en dicho XML con un simple parsing de este. Si existe saca por pantalla el aviso y si se acepta, accede al mismo XML del cual obtiene la URL completa de la firmware a descargar.
Este XML se puede consultar desde cualquier PC:
http://phobos.apple.com/version
Si accedemos a él tendremos acceso a todas las URL de las firmware de Apple. Evidentemente algunas antiguas es posible que no existan ya. En realidad los enlaces existen, pero no se muestran en dicho XML. Si queremos descargar cualquier firmware tan solo tenemos que copiar la URL y listo.
¿Pero que sucede con las actualizaciones del iPod Touch? Cualquiera que examine, busque... en dicho XML se dará cuenta que cuando llega a una firmware para iPod Touch se encuentra algo como esto:
"protected://pfd.apple.com/ProtectedAsset/iPodTouch/061-6579.20090527.Xde3T/iPod1,1_3.0_7A341_Restore.ipsw"
la etiqueta "protected" lo dice todo, y evidentemente cambiando "protected" por "www" no es suficiente. Aun así os diré que las primeras versiones de Apple de este sistema, si que era suficiente cambiar dicha etiqueta por "http" y se podía realizar la descargar. ¿Absurdo verdad? Como se tocan los huevos los chicos de Apple.
De la primera versión se pasó a la segunda versión, que es la que se usa ahora, que tampoco es que tenga mucha complicación, aunque mucho más ingeniosa que la primera. Pero antes de explicarla vamos a intentar comprender que problema tiene Apple con ello.
Una firmware no puede firmarse para cada usuario. Bueno, a ver, se podría hacer, pero no sería viable de ninguna forma, desde que el archivo pesaría más, hasta que sería un auténtico engorro por todos los sentidos. Esto quiere decir que la firmware .ipws es la misma para todos (esto no sucede igual cno las aplicaciones, las cuales sí estan firmadas para cada usuario). Ademas esta el problema añadido de que pasaría para aquellos q comprasen el iPod Touch con dicha actualización.
Bueno, ya tenemos el primer problema para Apple. La firmware es igual para todos, bit a bit. Está igualmente claro que quien compra la actualización y le da a actualizar le saldrá y quien no no le saldrá o le saldra un cartel que le diga que la puede comprar. ¿Luego como sabe iTunes que la has comprado o no? Por tu cuenta de AppStore, está claro, pero... ¿que envia itunes a los servidores de Apple para comprobar si está disponible o no (comprada o no)?
Para ello tendríamos que usar un Sniffer en dos PCs, uno con una cuenta que la ha comprado y otro una cuenta en la que no la ha comprado y ver si existe algo diferente, o usar un procedimiento similar.
Sorpresa!! iTunes no envia a los servidores de Apple ninguna información referente a nustra cuenta. Es lógico, nuestra firmware no depende de nuestra cuenta, no se encripta para ella ni para nada. Pero está claro que algo cambia!! Antes de desvelar el secreto vamos a ver los dos ejemplos anteriores, uno con la actualización pagada y otra sin pagar:
1º. Sin Pagar
Se accede a iTunes, este comprueba un XML por actualizaciones, encuentra un protected y decuelve un mensaje de que si se quiere se compre.
2º. Pagando/comprado el iPod Touch con dicha actualizacion
Se accede a iTunes, este comprueba un XML por actualizaciones, encuentra la firmware y la descarga.
¿Cual es la diferencia de los dos casos? el XML.
Podemos decir que quien ha comprado la firmware accede entonces a un XML diferente? Efectivamente, eso es lo que sucede.
Pero entonces, preguntarán algunos, aun no comprendo pq los enlaces que existen son tan solo temporales y con un formato extraño, en el que suele terminar por key=XXXXXXXXXX. Es simple. Cuando se ha comprado la firmware se accede a un XML, siempre se accede al mismo!! y este genera temporalmente un enlace válido a la firmware del iPod Touch. Si la Key no es válida no se podrá descargar, si es válida si. Esta Key se genera en los servidores de Apple, pero no importa que sea temporal o permanente. ¿Por qué? porque en el momento que queramos podremos acceder al XML y este generará una válida.
¿Y cual es este XML? Cualquiera que sepa manejar un Sniffer lo podría saber facilmente:
"http://ax.phobos.apple.com.edgesuite.net/WebObjects/MZStore.woa/wa/com.apple.jingle.appserver.client.MZITunesClientCheck/version?touchUpdate=true"
Ese es el XML que accede un iPod Touch con acceso a las actualizaciones. En realidad es igual al que se usa para acceder a los iPhone o a cualquier otro iPod, salvo que si miramos bien se le ha añadido una coletilla "?touchUpdate=true". ¿Curioso verdad?. Si visitamos ese XML, en apariencia es igual al que nos aparece si visitamos la página primera (que no es más que una redirección a la que acabo de poner sin la coletilla). Pero si buscamos en nusetro nuevo XML por "iPod1,1_3" que sería la versión 3.0 para el iPod Touch viejo, vemos algo muy diferente al "protected", por el contrario nos encontramos con esto otro:
"http://pfd.apple.com/ProtectedAsset/iPodTouch/061-6579.20090527.Xde3T/iPod1,1_3.0_7A341_Restore.ipsw?downloadKey=1245443827_8105f42b8b462d3652857c8d121f9c52"
Sorpresa sorpresa... y eso sí que es un enlace válido hacia la firmware, 100% genuino y desde los servidores de Apple.
¿Ahora bien, hasta que punto esto es legal o no legal?
Por una parte estamos descargando algo desde un servidor de Apple, igual que lo hace quien lo haya comprado o a quien el iPod Touch le viniese de fábrica. Por otro lado se da el caso de que en el caso de que nofuese ilegal, descargamos la firmware, la introducimos en nuestro iPod y una vez que está dentro de él, iTunes ya interpretará que nusetro iPod Touch se compró con ella o que la compramos y nos mostrará las actualizaciones pertinentes, ¿con lo que ya no sería ilegal?
Desde mi punto de vista es legal, pero está claro que no es ético. Es legal porque no se está realizando nada, ninguna práctica ni sorteando ningún sistema... no hacemos ninguna práctica ilegal, y la firmware no dice que tan solo se pueda introducir en los iPod que la compraron, dado que podría venir de fábrica, no es un software exclusivo como en el caso de las aplicaciones ni nada por el estilo. Tampoco estamos distribuyendo software dado que sale de sus servidores... que evidentemente no es ético? evidentemente, puesto que Apple cobra por ello, y aunque no nos parezca correcto lo que hace Apple, tampoco podemos poner la justicia por nuestra mano.
Claro está, todo es desde mi punto de vista...
Un saludo y espero que haya servido para esclarecer algunas cosillas.
Antes de empezar, recuerdo por cierto que quienes tengan intención de actualizar o restaurar sus iPhone o iPod Touch con las versiones 3.0 que se filtraron antes del lanzamiento oficial... os aviso que os abstengais, no son las mismas aunque recen ser la misma revisión.
Y a lo que vamos.
Apple usa un sistema simple pero eficiente para llevar a cabo las actualizaciones de sus dispositivos a través de iTunes, desde las firmwares de los iPod, iPod Touch o iPhone o incluso los perfiles de los operadores del iPhone.
Cuando estas en iTunes, este comprueba si existen actualizaciones, ¿cómo? simplemente accede a un xml y lo revisa. Este XML contiene la información de cada una de las firmwares y la documentación adjunta a cada una de ellas, así como los enlaces a cada una de las firmwares. iTunes solo tiene que acceder y buscar si existe una versión superior en dicho XML con un simple parsing de este. Si existe saca por pantalla el aviso y si se acepta, accede al mismo XML del cual obtiene la URL completa de la firmware a descargar.
Este XML se puede consultar desde cualquier PC:
http://phobos.apple.com/version
Si accedemos a él tendremos acceso a todas las URL de las firmware de Apple. Evidentemente algunas antiguas es posible que no existan ya. En realidad los enlaces existen, pero no se muestran en dicho XML. Si queremos descargar cualquier firmware tan solo tenemos que copiar la URL y listo.
¿Pero que sucede con las actualizaciones del iPod Touch? Cualquiera que examine, busque... en dicho XML se dará cuenta que cuando llega a una firmware para iPod Touch se encuentra algo como esto:
"protected://pfd.apple.com/ProtectedAsset/iPodTouch/061-6579.20090527.Xde3T/iPod1,1_3.0_7A341_Restore.ipsw"
la etiqueta "protected" lo dice todo, y evidentemente cambiando "protected" por "www" no es suficiente. Aun así os diré que las primeras versiones de Apple de este sistema, si que era suficiente cambiar dicha etiqueta por "http" y se podía realizar la descargar. ¿Absurdo verdad? Como se tocan los huevos los chicos de Apple.
De la primera versión se pasó a la segunda versión, que es la que se usa ahora, que tampoco es que tenga mucha complicación, aunque mucho más ingeniosa que la primera. Pero antes de explicarla vamos a intentar comprender que problema tiene Apple con ello.
Una firmware no puede firmarse para cada usuario. Bueno, a ver, se podría hacer, pero no sería viable de ninguna forma, desde que el archivo pesaría más, hasta que sería un auténtico engorro por todos los sentidos. Esto quiere decir que la firmware .ipws es la misma para todos (esto no sucede igual cno las aplicaciones, las cuales sí estan firmadas para cada usuario). Ademas esta el problema añadido de que pasaría para aquellos q comprasen el iPod Touch con dicha actualización.
Bueno, ya tenemos el primer problema para Apple. La firmware es igual para todos, bit a bit. Está igualmente claro que quien compra la actualización y le da a actualizar le saldrá y quien no no le saldrá o le saldra un cartel que le diga que la puede comprar. ¿Luego como sabe iTunes que la has comprado o no? Por tu cuenta de AppStore, está claro, pero... ¿que envia itunes a los servidores de Apple para comprobar si está disponible o no (comprada o no)?
Para ello tendríamos que usar un Sniffer en dos PCs, uno con una cuenta que la ha comprado y otro una cuenta en la que no la ha comprado y ver si existe algo diferente, o usar un procedimiento similar.
Sorpresa!! iTunes no envia a los servidores de Apple ninguna información referente a nustra cuenta. Es lógico, nuestra firmware no depende de nuestra cuenta, no se encripta para ella ni para nada. Pero está claro que algo cambia!! Antes de desvelar el secreto vamos a ver los dos ejemplos anteriores, uno con la actualización pagada y otra sin pagar:
1º. Sin Pagar
Se accede a iTunes, este comprueba un XML por actualizaciones, encuentra un protected y decuelve un mensaje de que si se quiere se compre.
2º. Pagando/comprado el iPod Touch con dicha actualizacion
Se accede a iTunes, este comprueba un XML por actualizaciones, encuentra la firmware y la descarga.
¿Cual es la diferencia de los dos casos? el XML.
Podemos decir que quien ha comprado la firmware accede entonces a un XML diferente? Efectivamente, eso es lo que sucede.
Pero entonces, preguntarán algunos, aun no comprendo pq los enlaces que existen son tan solo temporales y con un formato extraño, en el que suele terminar por key=XXXXXXXXXX. Es simple. Cuando se ha comprado la firmware se accede a un XML, siempre se accede al mismo!! y este genera temporalmente un enlace válido a la firmware del iPod Touch. Si la Key no es válida no se podrá descargar, si es válida si. Esta Key se genera en los servidores de Apple, pero no importa que sea temporal o permanente. ¿Por qué? porque en el momento que queramos podremos acceder al XML y este generará una válida.
¿Y cual es este XML? Cualquiera que sepa manejar un Sniffer lo podría saber facilmente:
"http://ax.phobos.apple.com.edgesuite.net/WebObjects/MZStore.woa/wa/com.apple.jingle.appserver.client.MZITunesClientCheck/version?touchUpdate=true"
Ese es el XML que accede un iPod Touch con acceso a las actualizaciones. En realidad es igual al que se usa para acceder a los iPhone o a cualquier otro iPod, salvo que si miramos bien se le ha añadido una coletilla "?touchUpdate=true". ¿Curioso verdad?. Si visitamos ese XML, en apariencia es igual al que nos aparece si visitamos la página primera (que no es más que una redirección a la que acabo de poner sin la coletilla). Pero si buscamos en nusetro nuevo XML por "iPod1,1_3" que sería la versión 3.0 para el iPod Touch viejo, vemos algo muy diferente al "protected", por el contrario nos encontramos con esto otro:
"http://pfd.apple.com/ProtectedAsset/iPodTouch/061-6579.20090527.Xde3T/iPod1,1_3.0_7A341_Restore.ipsw?downloadKey=1245443827_8105f42b8b462d3652857c8d121f9c52"
Sorpresa sorpresa... y eso sí que es un enlace válido hacia la firmware, 100% genuino y desde los servidores de Apple.
¿Ahora bien, hasta que punto esto es legal o no legal?
Por una parte estamos descargando algo desde un servidor de Apple, igual que lo hace quien lo haya comprado o a quien el iPod Touch le viniese de fábrica. Por otro lado se da el caso de que en el caso de que nofuese ilegal, descargamos la firmware, la introducimos en nuestro iPod y una vez que está dentro de él, iTunes ya interpretará que nusetro iPod Touch se compró con ella o que la compramos y nos mostrará las actualizaciones pertinentes, ¿con lo que ya no sería ilegal?
Desde mi punto de vista es legal, pero está claro que no es ético. Es legal porque no se está realizando nada, ninguna práctica ni sorteando ningún sistema... no hacemos ninguna práctica ilegal, y la firmware no dice que tan solo se pueda introducir en los iPod que la compraron, dado que podría venir de fábrica, no es un software exclusivo como en el caso de las aplicaciones ni nada por el estilo. Tampoco estamos distribuyendo software dado que sale de sus servidores... que evidentemente no es ético? evidentemente, puesto que Apple cobra por ello, y aunque no nos parezca correcto lo que hace Apple, tampoco podemos poner la justicia por nuestra mano.
Claro está, todo es desde mi punto de vista...
Un saludo y espero que haya servido para esclarecer algunas cosillas.
JailBreak 3.0: Retrasos
Vamos por partes. Si, el JB se podrá hacer, así como desbloquear cualquier iPhone en el mercado a día de hoy (sin contar el iPhone 3GS)
Pero por lo visto han aparecido dos pequeños contratiempos que ha hecho que se retrase la salida de este.
Por un lado, parece ser que la aplicación de YT no se lleva muy bien con el nuevo desbloqueo de los iphone. Quien no lo sepa, a día de hoy para que la app de YT funcione correctamente en un iPhone (no afecta esto a los Touch) liberado se debe de parchear unos certificados y unas llaves. No voy a entrar en detalles en ello.
Por otro lado, debido a un bug en la firmware de Apple, debido a un fallo de programación de ellos, está causando que en determinados dispositivos (no en todos, y no siempre) se quede colgado este. En realidad es un fallo de Apple, pero afecta paralelamente al JB, con lo que posiblemente la solución a esto no sea modificar el JB, sino corregir tb el bug de Apple (Bug que puede aparecer tb sin JB)
En un principio estaban estudiando ambos casos para hacer público el JB, pero dado que el primer error no es indispensable han pasado directamente a trabajar en el segundo. Cuando el segundo esté solucionado el JB se hará público. Si para entonces se ha solucionado el primer problema, bien, sino es así, aparecerá un primer JB que no corregirá lo primero, con lo que los iPhone liberados no podrán usar la aplicación YouTube (tampoco esencial, teniendo en cuenta la aplicación MxYube). Posteriormente saldría la segunda versión del JB en cuanto todo fuese funcional.
Evidentemente si se solucionan ambos problemas sobre la marcha, no habrá necesidad de dos JB, tan solo uno.
Así que... un poquito de paciencia, que es madre de la ciencia.
Un saludo
Pero por lo visto han aparecido dos pequeños contratiempos que ha hecho que se retrase la salida de este.
Por un lado, parece ser que la aplicación de YT no se lleva muy bien con el nuevo desbloqueo de los iphone. Quien no lo sepa, a día de hoy para que la app de YT funcione correctamente en un iPhone (no afecta esto a los Touch) liberado se debe de parchear unos certificados y unas llaves. No voy a entrar en detalles en ello.
Por otro lado, debido a un bug en la firmware de Apple, debido a un fallo de programación de ellos, está causando que en determinados dispositivos (no en todos, y no siempre) se quede colgado este. En realidad es un fallo de Apple, pero afecta paralelamente al JB, con lo que posiblemente la solución a esto no sea modificar el JB, sino corregir tb el bug de Apple (Bug que puede aparecer tb sin JB)
En un principio estaban estudiando ambos casos para hacer público el JB, pero dado que el primer error no es indispensable han pasado directamente a trabajar en el segundo. Cuando el segundo esté solucionado el JB se hará público. Si para entonces se ha solucionado el primer problema, bien, sino es así, aparecerá un primer JB que no corregirá lo primero, con lo que los iPhone liberados no podrán usar la aplicación YouTube (tampoco esencial, teniendo en cuenta la aplicación MxYube). Posteriormente saldría la segunda versión del JB en cuanto todo fuese funcional.
Evidentemente si se solucionan ambos problemas sobre la marcha, no habrá necesidad de dos JB, tan solo uno.
Así que... un poquito de paciencia, que es madre de la ciencia.
Un saludo
miércoles, 17 de junio de 2009
Firmwares 3.0: Enlaces (Actualizado III) -> Todas Online
Antes que nada nos hace falta iTunes 8.2, para quien no lo tenga:
iTunes 8.2 (para 32 bits solo, quien necesite el de 64 que me lo pida)
Todas las firmwares 3.0, exceptuando la del iPhone 3GS que esta en el post de enlaces:
Documentación iPhone GSM
iPhone GSM
Documentación iPhone 3G
iPhone 3G
Documentación iPod Touch Viejo
iPod Touch Viejo
Documentación iPod Touch Nuevo
iPod Touch Nuevo
Aun que no está disponible aun las versiones siguientes, si que el Dev-Team ha explicado que el JB estará disponible casi a la par que la version 3.0 oficial. Tan solo el Unlock DE CUALQUIER IPHONE 3.0 se retrasará al viernes, cuando estará disponible el nuevo YellowSn0w para liberar cualquier iphone 3G o GSM con la versión 3.0, incluso el iPhone 3GS de poderse realizar el JB, puesto que ambos comparten el mismo BaseBand
Bueno, ya están disponibles todas las firmware 3.0. Dejaré los enlaces aquí de mientras los paso al otro post, en cuanto esten pasados los eliminaré de aquí. El JB no debería tardar en aparecer.
http://esp.theliel.es/2008/02/enlaces-firmwares.html
Os dejo tambien el change Log de Apple incluido como documentación en la firmware 3.0 de iPhone 3GS:
• Cortar, copiar y pegar, con la opción de agitar para deshacer
• Teclado horizontal en las principales aplicaciones
• Mejoras en la aplicación Mensajes:
- Enviar y recibir fotos, contactos, archivos de sonido y ubicaciones mediante MMS*
- Reenviar y eliminar uno o varios mensajes
• Búsqueda en Mail, Calendario, Notas e iPod
• Búsqueda en todo el iPhone mediante Spotlight
• Compatibilidad con CalDAV y suscripciones en Calendario
• Mejoras en la aplicación Safari:
- Mayor velocidad
- Compatibilidad con HTML 5
- Transmisión de audio y vídeo en tiempo real HTTP
- Autorrelleno de nombres de usuario y contraseñas
• Nueva aplicación para notas de voz
• Sincronización de las notas con un Mac o PC a través de iTunes
• Opción de compartir Internet a través de USB y Bluetooth*
• Búsqueda y descarga de películas, programas de televisión y audiolibros desde la iTunes Store**
• Bluetooth estéreo***
• Acceso automático a redes Wi-Fi
• Mejoras en la aplicación Bolsa
• Más opciones de control parental para aplicaciones, música, películas y programas de televisión
• Creación y acceso a cuentas de iTunes**
• Acceso a cuentas, suscripciones, puntuaciones y favoritos de YouTube**
• Agitar para activar el orden aleatorio del iPod
• Más idiomas, diccionarios y teclados
• Opción de localizar el iPhone (“Find my iPhone”) y borrar los datos de manera remota (“Remote Wipe”) a través de MobileMe (previa suscripción)**
• Compatibilidad con más políticas de Exchange
• Creación y envío de invitaciones a reuniones de Exchange
• Búsqueda del correo electrónico en el servidor (Exchange Server 2007 y servidores IMAP compatibles)
• Búsqueda en el directorio de empresas LDAP
• Compatibilidad con proxies VPN y VPN por petición
• Perfiles de configuración encriptados
• Copias de seguridad de iTunes encriptadas
• Mil nuevas API para desarrolladores, entre las que destacan:
- Compras integradas
- Servicio de Apple de envío de notificaciones
- Compatibilidad con accesorios
- Conectividad entre dispositivos
- Mapas incorporados
- Acceso a la biblioteca del iPod
• Correcciones de errores
Productos compatibles con esta actualización de software:
• iPhone
• iPhone 3G
• iPhone 3G S
* Compatible únicamente con el iPhone 3G y el iPhone 3G S. Requiere compatibilidad con el proveedor de conexión inalámbrica.
** No disponible en todos los países ni en todos los idiomas.
*** Compatible únicamente con el iPhone 3G y el iPhone 3G S.
Documentación Firmware 3.o iPhone 3GS:
http://appldnld.apple.com.edgesuite.net/content.info.apple.com/iPhone/061-6592.20090612.0O8nr/iPhoneDocumentation_3.0.ipd
iTunes 8.2 (para 32 bits solo, quien necesite el de 64 que me lo pida)
Todas las firmwares 3.0, exceptuando la del iPhone 3GS que esta en el post de enlaces:
Documentación iPhone GSM
iPhone GSM
Documentación iPhone 3G
iPhone 3G
Documentación iPod Touch Viejo
iPod Touch Viejo
Documentación iPod Touch Nuevo
iPod Touch Nuevo
Aun que no está disponible aun las versiones siguientes, si que el Dev-Team ha explicado que el JB estará disponible casi a la par que la version 3.0 oficial. Tan solo el Unlock DE CUALQUIER IPHONE 3.0 se retrasará al viernes, cuando estará disponible el nuevo YellowSn0w para liberar cualquier iphone 3G o GSM con la versión 3.0, incluso el iPhone 3GS de poderse realizar el JB, puesto que ambos comparten el mismo BaseBand
Bueno, ya están disponibles todas las firmware 3.0. Dejaré los enlaces aquí de mientras los paso al otro post, en cuanto esten pasados los eliminaré de aquí. El JB no debería tardar en aparecer.
http://esp.theliel.es/2008/02/enlaces-firmwares.html
Os dejo tambien el change Log de Apple incluido como documentación en la firmware 3.0 de iPhone 3GS:
• Cortar, copiar y pegar, con la opción de agitar para deshacer
• Teclado horizontal en las principales aplicaciones
• Mejoras en la aplicación Mensajes:
- Enviar y recibir fotos, contactos, archivos de sonido y ubicaciones mediante MMS*
- Reenviar y eliminar uno o varios mensajes
• Búsqueda en Mail, Calendario, Notas e iPod
• Búsqueda en todo el iPhone mediante Spotlight
• Compatibilidad con CalDAV y suscripciones en Calendario
• Mejoras en la aplicación Safari:
- Mayor velocidad
- Compatibilidad con HTML 5
- Transmisión de audio y vídeo en tiempo real HTTP
- Autorrelleno de nombres de usuario y contraseñas
• Nueva aplicación para notas de voz
• Sincronización de las notas con un Mac o PC a través de iTunes
• Opción de compartir Internet a través de USB y Bluetooth*
• Búsqueda y descarga de películas, programas de televisión y audiolibros desde la iTunes Store**
• Bluetooth estéreo***
• Acceso automático a redes Wi-Fi
• Mejoras en la aplicación Bolsa
• Más opciones de control parental para aplicaciones, música, películas y programas de televisión
• Creación y acceso a cuentas de iTunes**
• Acceso a cuentas, suscripciones, puntuaciones y favoritos de YouTube**
• Agitar para activar el orden aleatorio del iPod
• Más idiomas, diccionarios y teclados
• Opción de localizar el iPhone (“Find my iPhone”) y borrar los datos de manera remota (“Remote Wipe”) a través de MobileMe (previa suscripción)**
• Compatibilidad con más políticas de Exchange
• Creación y envío de invitaciones a reuniones de Exchange
• Búsqueda del correo electrónico en el servidor (Exchange Server 2007 y servidores IMAP compatibles)
• Búsqueda en el directorio de empresas LDAP
• Compatibilidad con proxies VPN y VPN por petición
• Perfiles de configuración encriptados
• Copias de seguridad de iTunes encriptadas
• Mil nuevas API para desarrolladores, entre las que destacan:
- Compras integradas
- Servicio de Apple de envío de notificaciones
- Compatibilidad con accesorios
- Conectividad entre dispositivos
- Mapas incorporados
- Acceso a la biblioteca del iPod
• Correcciones de errores
Productos compatibles con esta actualización de software:
• iPhone
• iPhone 3G
• iPhone 3G S
* Compatible únicamente con el iPhone 3G y el iPhone 3G S. Requiere compatibilidad con el proveedor de conexión inalámbrica.
** No disponible en todos los países ni en todos los idiomas.
*** Compatible únicamente con el iPhone 3G y el iPhone 3G S.
Documentación Firmware 3.o iPhone 3GS:
http://appldnld.apple.com.edgesuite.net/content.info.apple.com/iPhone/061-6592.20090612.0O8nr/iPhoneDocumentation_3.0.ipd
martes, 16 de junio de 2009
Firmware 3.0: Adelanto II
Bueno, pues según parece YellowSn0w estará disponible para el iPhone 3G también, lo que implica que se podrá liberar sin problema alguno
Con un poquito de suerte, tendremos una version lista de Pwnage y QuickPwn para la version 3.0 sobre la marcha, funcionando sobre iTunes 8.2 y sobre todos los dispositivos actualmente en el mercado.
Ni que decir tiene, que aquellos que se dedicaron a piratear aplicaciones no podrán hacerlas andar, y de poderlas hacer andar con parches antiguos... en fin... ellos sabrán como he dicho muchas veces el problema y otros que acarrea usar versiones diferentes de archivos.
Con un poquito de suerte, tendremos una version lista de Pwnage y QuickPwn para la version 3.0 sobre la marcha, funcionando sobre iTunes 8.2 y sobre todos los dispositivos actualmente en el mercado.
Ni que decir tiene, que aquellos que se dedicaron a piratear aplicaciones no podrán hacerlas andar, y de poderlas hacer andar con parches antiguos... en fin... ellos sabrán como he dicho muchas veces el problema y otros que acarrea usar versiones diferentes de archivos.
lunes, 15 de junio de 2009
Firmware 3.0: Adelanto
Bueno, solo restan un par de días para que la version 3.0 vea la luz.
Como va siendo normal, sobre todo porque no se cuantas versiones llevamos ya, vamos a intentar aclarar un poco que es lo que va a suceder y que es lo que yo recomiendo... recomendaría hacer, ya sea para iPod Touch o iPhone.
Es posible que para el mismo día 17 que supuestamente sale de manera oficial no exista un JB oficial. Y digo oficial cuando hablo del Dev-Team, es más, NO usar otro método. Posiblemente existan montones de personas que modifiquen el software de ellos para hacerlo compatible con la nueva versión... sinceramente, hacer una réplica de un software que ni siquiera conoces tan solo lleva a problemas y más problemas.
El Dev-Team tiene casi preparado (es de dominio público) un JB que seguro seguro funcionará con los iPhone GSM/3G y con los iPod Touch primitivos. Sobre los Touch nuevos aun quedaría por verlo, pero lo más seguro es que también. En el caso particular del iPhone 3G estará aun el problema de liberarse o no liberarse... actualmente es posible a través de Yellowsn0w y tan solo con versiones concretas de baseband... luego en principio actualizar completamente a la 3.0 implicará no poder liberarlo a posteriori... aunque esto es solo la teoría.
Sobre los iPhone nuevos que llegarán dentro de unos días también, es evidente que no hay JB ni liberación posible de antemano, y que se pueda o no realizar en el futuro es imposible de saberlo. El iPod Touch/iPhone es un sistema bastante seguro, y aun cuando Apple ha cometido errores en el pasado, cada vez ha sido más meticuloso... tenemos el caso del iPod Touch nuevo, que costó mucho mucho trabajo. Es posible que apple haya incluso modificado todo el sistema del nuevo iphone, con lo que a saber. Luego a partir de ahora, todo lo que se hable no será aplicable para iPhone 3GS.
Por otro lado me da la sensación que el Dev-Team tiene un AS bajo la manga para liberar el iPhone 3G, pero es solo especulación, y evidentemente hasta no estar el iPhone 3GS en la calle y todo el pastel vendido, no sabremos nada al respecto de ser así.
Sobre a como actuar? Pues quien me lea ya lo sabrá de antemano:
1º. Si no nos interesa el JB ni tener nuestro iPhone liberado, descargar el último iTunes 8.2, y actualizar. En caso de iPod a psar por caja
2º. Si deseamos JB, esperarnos a que aparezca la version "oficial" y listo. No pasa nada por esperar
3º. Si deseamos Liberar dispositivo, en caso de iPhone GSM igual que 2, en caso de iPhone 3G o se actualiza con el sistema nuevo que aparezca sin actualizar el baseband o es posible que aparezca un sistema nuevo. Lo que está claro es que con el baseband nuevo no funciona el método de liberar anterior
Y como siempre, en cualquiera de los tres casos. RESTAURAR, no actualizar y ni mucho menos restablecer una copia de seguridad anterior, siempre configurar el iPod/iPhone como dispositivo nuevo
Como va siendo normal, sobre todo porque no se cuantas versiones llevamos ya, vamos a intentar aclarar un poco que es lo que va a suceder y que es lo que yo recomiendo... recomendaría hacer, ya sea para iPod Touch o iPhone.
Es posible que para el mismo día 17 que supuestamente sale de manera oficial no exista un JB oficial. Y digo oficial cuando hablo del Dev-Team, es más, NO usar otro método. Posiblemente existan montones de personas que modifiquen el software de ellos para hacerlo compatible con la nueva versión... sinceramente, hacer una réplica de un software que ni siquiera conoces tan solo lleva a problemas y más problemas.
El Dev-Team tiene casi preparado (es de dominio público) un JB que seguro seguro funcionará con los iPhone GSM/3G y con los iPod Touch primitivos. Sobre los Touch nuevos aun quedaría por verlo, pero lo más seguro es que también. En el caso particular del iPhone 3G estará aun el problema de liberarse o no liberarse... actualmente es posible a través de Yellowsn0w y tan solo con versiones concretas de baseband... luego en principio actualizar completamente a la 3.0 implicará no poder liberarlo a posteriori... aunque esto es solo la teoría.
Sobre los iPhone nuevos que llegarán dentro de unos días también, es evidente que no hay JB ni liberación posible de antemano, y que se pueda o no realizar en el futuro es imposible de saberlo. El iPod Touch/iPhone es un sistema bastante seguro, y aun cuando Apple ha cometido errores en el pasado, cada vez ha sido más meticuloso... tenemos el caso del iPod Touch nuevo, que costó mucho mucho trabajo. Es posible que apple haya incluso modificado todo el sistema del nuevo iphone, con lo que a saber. Luego a partir de ahora, todo lo que se hable no será aplicable para iPhone 3GS.
Por otro lado me da la sensación que el Dev-Team tiene un AS bajo la manga para liberar el iPhone 3G, pero es solo especulación, y evidentemente hasta no estar el iPhone 3GS en la calle y todo el pastel vendido, no sabremos nada al respecto de ser así.
Sobre a como actuar? Pues quien me lea ya lo sabrá de antemano:
1º. Si no nos interesa el JB ni tener nuestro iPhone liberado, descargar el último iTunes 8.2, y actualizar. En caso de iPod a psar por caja
2º. Si deseamos JB, esperarnos a que aparezca la version "oficial" y listo. No pasa nada por esperar
3º. Si deseamos Liberar dispositivo, en caso de iPhone GSM igual que 2, en caso de iPhone 3G o se actualiza con el sistema nuevo que aparezca sin actualizar el baseband o es posible que aparezca un sistema nuevo. Lo que está claro es que con el baseband nuevo no funciona el método de liberar anterior
Y como siempre, en cualquiera de los tres casos. RESTAURAR, no actualizar y ni mucho menos restablecer una copia de seguridad anterior, siempre configurar el iPod/iPhone como dispositivo nuevo
martes, 9 de junio de 2009
Despotricando un poco
Me he quedado meditando un poco...
Apple forzado a bajar precios -> Bueno, pero muy muy insuficientes. Un comentario de Erika Sadun venía a decir que sí, 200-300$ menos, es bueno, pero que aun los 1200-2000$ que cuesta se alejan enormemente a los 300$ de su netbook :P
Apple añade extras a sus Mac -> Bueno, pero muy muy insuficiente. Me pregunto que hará cuando intel anuncie los Core i5:
a) sacar más modelos "nuevos"? No van a durar estos muchos = estafa.
b) no aparecer a corto plazo pq nVidia (quien fabrica los chipset para Apple) no tendrá soporte para Core i7 y Core i5, con lo que a romper contratos con estos y comprarle los chipset a intel?
Sinceramente estoy ya cansado de ver cmo Apple cada 6 meses saca un modelo nuevo de MacBook o iMac que apenas modifica el ya existente. Coño, ahorrate esos 6 meses y cuando los actualices los actualizas de verdad. Y ponen de novedad que, un lector SD?? por dios...
Hacen lo mismo que con el iPhone o el iPod Touch, actualizan modelos existentes por una tecnología ya inferior. Ejemplos?
iPhone GSM cuando los teléfonos móviles 3G existian desde hacia años antes.
iPhone GSM/3G con camara de 1mp?? cuando las camaras de 3MP eran casi lo minimo que se despachaba en el sector medio
iPhone 3GS podrá grabar videos!! y todos aplauden... que novedad señores... mi movil grabar video a 30fps en h264 desde hace bastante tiempo...
Firmware 3.0 podrá enviar MMS para los iphone!!... mejor sin comentarios ¿verdad?
Eso sí, para los Touch les cobramos... otra vez!!
Tecnológicamente era posible en la salida del iPhone primero, sacarlo 3G con camara de 3.0MP (o más) con GPS, grabar video, BT decente... sin incrementar demasiado el precio? nos sa jodío, si mi movil tiene la misma edad mas o menos y tiene todo ello, y me salio gratis... por favor... En vez de eso vamos a hacer que los "flipados" de siempre se compren cada 6 meses un dispositivo nuevo o cambie de MacBook o...
MacBook con novedosa DDR3!! -> Novedosa... tan novedosa que usa DDR3 a 1066, velocidad que se alcanza con DDR2, solo que es más barata y tiene menor latencia (luego es mejor), pero queda mas bonito poner DDR3
MacBook con DisplayPort!! Ultima tecnología!! -> Y no puedes enchufar un triste HDMI, usado en el 99% de los televisores, consolas... cualquier dispositivo HD, siendo el resto 1% o menos los que usan DisplayPort
MacBook con SD!! increible!! -> Dios mío!! estoy eufórico e intusiasmado de la novedad!!
iMac con procesadores Nehalem Xeon para servidores!! -> Wowww, se os ha olvidado retirar los iMac existentes Core 2 Duo por los Core i7? Ahhh claro... esos llegarán en septiembre o en febrero, a sí con suerte logramos vender alguno antiguo.
En serio... No se que es peor, Apple o MicroSoft.
Los primeros que son el todo por el todo por la pasta y a intentar (desde mi punto de vista) la "seducción" haciendo creer a todos los usuarios que lo suyo es siempre lo mejor, lo último, lo más nuevo... bla bla bla... me alegro para quien se lo crea
Los segundos tampoco son mejores... el último software original que creo MicroSoft fue... no, no me acuerdo... lo copian todo!:
Internet Explorer 8 = Firefox
Buscador Bing = Google
Aspectos de Vista = Mac OS
Zune = iPod
NetWork Monitor = WireShark
Por dios de mi vida, tener alguna idea original que se pueda decir: Ole!!! Que me parece genial que copieis las ideas buenas y las implementeis e incluso mejoreis, que está muy bien... pero por favor... tener ideas propias!!
Aun asi, me quedo con Microsoft (y no les tengo simpatía alguna).
Cuando pienso en Apple el sentimineto que me invade es el mismo cuando a estas horas de la noche hago zaping y me quedo mirando al infinito mientras en un canal de televisión, una chica atractiva comienza la presentación de su programa de participación en directo, que promete grandes premios:
"Vamos!! ahora será algo más dificil aun, yo creo que es casi imposible, un animal con 3 Aes!!.. Producción?? no, esto lo vamos a tener que quitar pq es imposible, nadie es capaz de saber un animal con 3 aes en su nombre... por favor cambiarme el juego... o si no haré lo unico que puedo hacer, duplicar el dinero!!" "Hoy lo vamos a poner muy facil... solo tienes que adivinar el animal que tengo en el sobre!! 4000€ solo por decirme el nombre que tengo en el sobre!! llama ahora, seguro que entras y puedes adivinarlo!!" (El animal era el Lobo Marino)
El sentimiento que me invade, lo siento, pero es el mismo que cuando pienso en Apple... es un insulto a la inteligencia!!! Y venga a llamar y a decir animales, que seguro que uno lo acierta... o claro... no suena el teléfono no pq no paseis llamadas, sino pq nadie sabe un animal con 3 Aes... Pero es lo que intentan muchos... corderitos al matadero, todos borregos.
Y digo yo... porque uno no se para a pensar 5 minutos antes? Que vlae, somos animales, pero creo que algo mas listos que los monos no? Que soy un exajerado? puede ser, pero estos programas se forran, al igual que Apple. Mientras puedan mantener un control de algún modo sobre los demas, ya sea haciendo alusión a su gran inteligencia como en estos programas o en el caso de Apple, normalmente presuponinedo una falta de información y un uso intensivo de que su manzana es lo mejor, es lo que usan los mejores, es lo que esta de moda... vaya mundo en el que vivimos.
Ojo! no estoy hablando de que todos sean así, no hablo de que sea mejor Apple o mejor Intelo mejor MS... estoy hablando de los sistemas de captación usados por cada uno, que desde mi punto de vista atentan contra la inteligencia de uno. Si me quieres convencer dame algo más que palabras vacias.
Para acabar, dejo un pensamiento que aparece en el libro de "El caballero de la armadura Oxidada", en el que se dice que cuando uno es guapo, alto, valiente, buen amante, luchador, honesto... simplemente lo és. Apple gasta en publicidad más que todos los creadores de software y creadores de hardware juntos. O en serio creeis que detrás de cada manzana que aparece en las películas no hay un cheque? Si en una película de alta tecnología se ve que los portátiles son de Apple y que son los que usan, es que son los mejores!! lo peor es que hay quien que se lo cree.
En fin, lo siento, no continúo. Mañana es un dia largo para mí y mira, las 4 de la noche y despotricando de unos y otros...
Apple forzado a bajar precios -> Bueno, pero muy muy insuficientes. Un comentario de Erika Sadun venía a decir que sí, 200-300$ menos, es bueno, pero que aun los 1200-2000$ que cuesta se alejan enormemente a los 300$ de su netbook :P
Apple añade extras a sus Mac -> Bueno, pero muy muy insuficiente. Me pregunto que hará cuando intel anuncie los Core i5:
a) sacar más modelos "nuevos"? No van a durar estos muchos = estafa.
b) no aparecer a corto plazo pq nVidia (quien fabrica los chipset para Apple) no tendrá soporte para Core i7 y Core i5, con lo que a romper contratos con estos y comprarle los chipset a intel?
Sinceramente estoy ya cansado de ver cmo Apple cada 6 meses saca un modelo nuevo de MacBook o iMac que apenas modifica el ya existente. Coño, ahorrate esos 6 meses y cuando los actualices los actualizas de verdad. Y ponen de novedad que, un lector SD?? por dios...
Hacen lo mismo que con el iPhone o el iPod Touch, actualizan modelos existentes por una tecnología ya inferior. Ejemplos?
iPhone GSM cuando los teléfonos móviles 3G existian desde hacia años antes.
iPhone GSM/3G con camara de 1mp?? cuando las camaras de 3MP eran casi lo minimo que se despachaba en el sector medio
iPhone 3GS podrá grabar videos!! y todos aplauden... que novedad señores... mi movil grabar video a 30fps en h264 desde hace bastante tiempo...
Firmware 3.0 podrá enviar MMS para los iphone!!... mejor sin comentarios ¿verdad?
Eso sí, para los Touch les cobramos... otra vez!!
Tecnológicamente era posible en la salida del iPhone primero, sacarlo 3G con camara de 3.0MP (o más) con GPS, grabar video, BT decente... sin incrementar demasiado el precio? nos sa jodío, si mi movil tiene la misma edad mas o menos y tiene todo ello, y me salio gratis... por favor... En vez de eso vamos a hacer que los "flipados" de siempre se compren cada 6 meses un dispositivo nuevo o cambie de MacBook o...
MacBook con novedosa DDR3!! -> Novedosa... tan novedosa que usa DDR3 a 1066, velocidad que se alcanza con DDR2, solo que es más barata y tiene menor latencia (luego es mejor), pero queda mas bonito poner DDR3
MacBook con DisplayPort!! Ultima tecnología!! -> Y no puedes enchufar un triste HDMI, usado en el 99% de los televisores, consolas... cualquier dispositivo HD, siendo el resto 1% o menos los que usan DisplayPort
MacBook con SD!! increible!! -> Dios mío!! estoy eufórico e intusiasmado de la novedad!!
iMac con procesadores Nehalem Xeon para servidores!! -> Wowww, se os ha olvidado retirar los iMac existentes Core 2 Duo por los Core i7? Ahhh claro... esos llegarán en septiembre o en febrero, a sí con suerte logramos vender alguno antiguo.
En serio... No se que es peor, Apple o MicroSoft.
Los primeros que son el todo por el todo por la pasta y a intentar (desde mi punto de vista) la "seducción" haciendo creer a todos los usuarios que lo suyo es siempre lo mejor, lo último, lo más nuevo... bla bla bla... me alegro para quien se lo crea
Los segundos tampoco son mejores... el último software original que creo MicroSoft fue... no, no me acuerdo... lo copian todo!:
Internet Explorer 8 = Firefox
Buscador Bing = Google
Aspectos de Vista = Mac OS
Zune = iPod
NetWork Monitor = WireShark
Por dios de mi vida, tener alguna idea original que se pueda decir: Ole!!! Que me parece genial que copieis las ideas buenas y las implementeis e incluso mejoreis, que está muy bien... pero por favor... tener ideas propias!!
Aun asi, me quedo con Microsoft (y no les tengo simpatía alguna).
Cuando pienso en Apple el sentimineto que me invade es el mismo cuando a estas horas de la noche hago zaping y me quedo mirando al infinito mientras en un canal de televisión, una chica atractiva comienza la presentación de su programa de participación en directo, que promete grandes premios:
"Vamos!! ahora será algo más dificil aun, yo creo que es casi imposible, un animal con 3 Aes!!.. Producción?? no, esto lo vamos a tener que quitar pq es imposible, nadie es capaz de saber un animal con 3 aes en su nombre... por favor cambiarme el juego... o si no haré lo unico que puedo hacer, duplicar el dinero!!" "Hoy lo vamos a poner muy facil... solo tienes que adivinar el animal que tengo en el sobre!! 4000€ solo por decirme el nombre que tengo en el sobre!! llama ahora, seguro que entras y puedes adivinarlo!!" (El animal era el Lobo Marino)
El sentimiento que me invade, lo siento, pero es el mismo que cuando pienso en Apple... es un insulto a la inteligencia!!! Y venga a llamar y a decir animales, que seguro que uno lo acierta... o claro... no suena el teléfono no pq no paseis llamadas, sino pq nadie sabe un animal con 3 Aes... Pero es lo que intentan muchos... corderitos al matadero, todos borregos.
Y digo yo... porque uno no se para a pensar 5 minutos antes? Que vlae, somos animales, pero creo que algo mas listos que los monos no? Que soy un exajerado? puede ser, pero estos programas se forran, al igual que Apple. Mientras puedan mantener un control de algún modo sobre los demas, ya sea haciendo alusión a su gran inteligencia como en estos programas o en el caso de Apple, normalmente presuponinedo una falta de información y un uso intensivo de que su manzana es lo mejor, es lo que usan los mejores, es lo que esta de moda... vaya mundo en el que vivimos.
Ojo! no estoy hablando de que todos sean así, no hablo de que sea mejor Apple o mejor Intelo mejor MS... estoy hablando de los sistemas de captación usados por cada uno, que desde mi punto de vista atentan contra la inteligencia de uno. Si me quieres convencer dame algo más que palabras vacias.
Para acabar, dejo un pensamiento que aparece en el libro de "El caballero de la armadura Oxidada", en el que se dice que cuando uno es guapo, alto, valiente, buen amante, luchador, honesto... simplemente lo és. Apple gasta en publicidad más que todos los creadores de software y creadores de hardware juntos. O en serio creeis que detrás de cada manzana que aparece en las películas no hay un cheque? Si en una película de alta tecnología se ve que los portátiles son de Apple y que son los que usan, es que son los mejores!! lo peor es que hay quien que se lo cree.
En fin, lo siento, no continúo. Mañana es un dia largo para mí y mira, las 4 de la noche y despotricando de unos y otros...
lunes, 8 de junio de 2009
WWDC: KeyNote -> Minuto a minuto
Esto es lo que nos deja el WWDC:
Macs:
Alguna cara nueva con soporte para SD (que no tenían)... nada interesante, continuan igualmente caros, antiguos en comparación de los Core i7 disponibles... bua... ni me preocupo de noticiarlo...
Firmware Version 3.0:
Copy/Paste
MMS para los iPhone
Spotlight -> Busqueda entre aplicaciones
Deshacer añadido
Comprar/alquilar pelis desde nuestro dispositivo
Mejorado el control parental
Añadido Tethering, lo que posibilita compartir la conexion de nuestro dispositivo con nuestro PC. Usar 3G para conexion a inet usando el iPhone como modem (queda por ver si es posible usar lo mismo con conexion WIFI)
Safari:
JavaScript mejorado
Autorellenado para Usuarios y contraseña
Find My iPhone para suscriptores a MobileMe
Soporte P2P para juegos Online
Soporte Push para los desarrolladores de aplicaciones, para noticias, puntuaciones... cualquier informacion que se requiera al instante
Parece ser que aparecerá un TomTom por fin, Apple se habrá bajado los pantalones de una vez, ya era hora..
Están presentando muchas aplicaciones... tss... por ahora nada de nuevo iPhone
firmware iPhone 3.0
Firmware 3.0 iPod touch -> 9.95$
Día -> 17 de Junio
Nuevo iPhone 3GS
Mejor transmisión 3G
Nuevo procesador x2 x3 veces más rapido
Camara de 3 MP con autofocus y Macro automático
Grabación Video hasta 30fps
Soporte para OGL ES 2.0
Control por voz
Brújula digital
Soporte para nike+
Mejorada la batería
$299 para el modelo de 32GB
$199 para el modelo de 16GB
$99 para el modelo antiguo 3G (tendran que liquidar almacen)
Fecha salida 19 de Junio
Aunque claro, estos son precios de allí... recordar que en muy pocos sitios se vende libre..
Respecto el nuevo iPhone??
tampoco es que sea algo "nuevo", pero al menos es una mejora más sustancial al iPhone 3G, mejor procesador, camara 3 MP con autofocus... sinceramente mejoras que podrían haber llegado en el iPhone 3G, incluso me parece cortito para un telefono que sale nuevo. Mi teléfono tiene un año o dos y tiene camara de 3.2 y supera en mucho la transmisión de datos por 3G... pero como digo, al menos es algo. Lo que no comprendo es pq tantos aplausos y expectación por algo que desde mi punto de vista no es nada nuevo, no aporta nada... tan solo mejora fallos gordos que lleva arrastrando desde su primera versión... aunq es mi opinión
Nada, otra excusa para sacar el dinero a los que facilmente se dejan impresionar...
Macs:
Alguna cara nueva con soporte para SD (que no tenían)... nada interesante, continuan igualmente caros, antiguos en comparación de los Core i7 disponibles... bua... ni me preocupo de noticiarlo...
Firmware Version 3.0:
Copy/Paste
MMS para los iPhone
Spotlight -> Busqueda entre aplicaciones
Deshacer añadido
Comprar/alquilar pelis desde nuestro dispositivo
Mejorado el control parental
Añadido Tethering, lo que posibilita compartir la conexion de nuestro dispositivo con nuestro PC. Usar 3G para conexion a inet usando el iPhone como modem (queda por ver si es posible usar lo mismo con conexion WIFI)
Safari:
JavaScript mejorado
Autorellenado para Usuarios y contraseña
Find My iPhone para suscriptores a MobileMe
Soporte P2P para juegos Online
Soporte Push para los desarrolladores de aplicaciones, para noticias, puntuaciones... cualquier informacion que se requiera al instante
Parece ser que aparecerá un TomTom por fin, Apple se habrá bajado los pantalones de una vez, ya era hora..
Están presentando muchas aplicaciones... tss... por ahora nada de nuevo iPhone
firmware iPhone 3.0
Firmware 3.0 iPod touch -> 9.95$
Día -> 17 de Junio
Nuevo iPhone 3GS
Mejor transmisión 3G
Nuevo procesador x2 x3 veces más rapido
Camara de 3 MP con autofocus y Macro automático
Grabación Video hasta 30fps
Soporte para OGL ES 2.0
Control por voz
Brújula digital
Soporte para nike+
Mejorada la batería
$299 para el modelo de 32GB
$199 para el modelo de 16GB
$99 para el modelo antiguo 3G (tendran que liquidar almacen)
Fecha salida 19 de Junio
Aunque claro, estos son precios de allí... recordar que en muy pocos sitios se vende libre..
Respecto el nuevo iPhone??
tampoco es que sea algo "nuevo", pero al menos es una mejora más sustancial al iPhone 3G, mejor procesador, camara 3 MP con autofocus... sinceramente mejoras que podrían haber llegado en el iPhone 3G, incluso me parece cortito para un telefono que sale nuevo. Mi teléfono tiene un año o dos y tiene camara de 3.2 y supera en mucho la transmisión de datos por 3G... pero como digo, al menos es algo. Lo que no comprendo es pq tantos aplausos y expectación por algo que desde mi punto de vista no es nada nuevo, no aporta nada... tan solo mejora fallos gordos que lleva arrastrando desde su primera versión... aunq es mi opinión
Nada, otra excusa para sacar el dinero a los que facilmente se dejan impresionar...
WWDC: WordWide Developers Conference '09
Hoy arranca la WWDC.
Es casi evidente que tanto la firmware 3.0 como el nuevo iphone sea presentado de manera oficial, aunque dependiendo de la prisa que se hayan dado, posiblemente no este disponible de manera inmediata. Recordar que vimos exactamente lo mismo hace 12 meses con la presentacion del iphone 3G
Dudo mucho que nos sorprendan demasiado, pero aun asi iremos relatando las noticias que tengamos
un saludo
Es casi evidente que tanto la firmware 3.0 como el nuevo iphone sea presentado de manera oficial, aunque dependiendo de la prisa que se hayan dado, posiblemente no este disponible de manera inmediata. Recordar que vimos exactamente lo mismo hace 12 meses con la presentacion del iphone 3G
Dudo mucho que nos sorprendan demasiado, pero aun asi iremos relatando las noticias que tengamos
un saludo
domingo, 7 de junio de 2009
iTunes 8.2
Hace unos días apareció de manera oficial la version de iTunes 8.2.
Como la mayoría supondrá es una versión para soportar la nueva firmware 3.0 principalmente, así como el más que probable nuevo iphone.
OJO!! por lo que se cuenta lo único que se logrará será no poder realizar JB a nuestros dispositivos!! no parece que sea una medida de protección por parte de Apple, pero de momento deja a nuestro dispositivo sin posibilidad de DFU. Evidentemente no es algo que sea irreparable, y que posiblemente cuando aparezca de manera oficial la 3.0 y con ella el JB, el sistema nuevo sea compatible con dicha versión, pero de momento no recomiendo a nadie instalarla.
Lo único que parece que se ha añadido es la opción Genius para los videos y para el soporte para la firmware nueva, con lo que no es demasiado desde mi punto de vista.
Así que bueno... aunque suele ser siempre positivo actualizar nuestros programas, recomiendo esperar un poco, a fin de cuentas tampoco es que las mejoras sean notables ni muchísimo menos.
Un saludo.
Como la mayoría supondrá es una versión para soportar la nueva firmware 3.0 principalmente, así como el más que probable nuevo iphone.
OJO!! por lo que se cuenta lo único que se logrará será no poder realizar JB a nuestros dispositivos!! no parece que sea una medida de protección por parte de Apple, pero de momento deja a nuestro dispositivo sin posibilidad de DFU. Evidentemente no es algo que sea irreparable, y que posiblemente cuando aparezca de manera oficial la 3.0 y con ella el JB, el sistema nuevo sea compatible con dicha versión, pero de momento no recomiendo a nadie instalarla.
Lo único que parece que se ha añadido es la opción Genius para los videos y para el soporte para la firmware nueva, con lo que no es demasiado desde mi punto de vista.
Así que bueno... aunque suele ser siempre positivo actualizar nuestros programas, recomiendo esperar un poco, a fin de cuentas tampoco es que las mejoras sean notables ni muchísimo menos.
Un saludo.
Elecciones al Parlamento Europeo
Señores, os recuerdo a todos los pertenecientes a la comunidad europea y mayores de Edad que hoy toca ir a votar.
Aquí hemos visto entradas referentes a leyes, a sistemas modernos, a representantes... hoy los elegimos.
Para quien piense que no tiene sentido... es un derecho y un deber, no ir a votar desde mi punto de vista es no creer. Comprendo que la justicia y las leyes no suelen ser muy justas y que el sistema deja muuuuuuuuuuuucho que desear. Pero es lo que tenemos y debemos de procurar que este sistema sea lo más cercano a nuestras ideas.
Así que me da igual que seais Comunistas, De ideas de Izquierdas, de Ideas de Centro, de Ideas de derecha o de Ideas ultraconservadoras. Incluso si no creeis en el sistema, votar en blanco. Pero acudir a las urnas.
No hace demasiado Barack Obama se convertía en el primer presidente negro de la historia americana... y aunque pueda tener unas ideas sociales alejadas de las mías, comprendo que el mundo es un lugar muchisimo mejor y más seguro (desde mi punto de vista claro está) con un presidente como él a lo que supuso la época Bush. Y este hombre no habría sido elegido sin los votos de cada americano.
Vale, sí, el parlamento europeo no es un pais propiamente dicho, pero las decisiones que tomarán sí nos incumbirán a todos!! Me hace mucha gracia cuando alguien me dice: "Total... son políticos, todos son iguales..." Yo les digo: "Y que haces tú para mejorar eso?, ni siquiera fuistes capaz de ir a votar."
Señores, hay que mojarse, y en serio, sinceramente, me da igual que el voto sea en contra de mis ideales o a favor de ellos, pero si creo que el mundo mi pais mi... puede ser mejor con un representante u otro, vale dios que al menos lo dejaré presente con mi voto. A lo mejor no ganan mis ideas de forma mayoritaria, pero al menos lo intentaré y de "perder", lo haré con la misma humildad de aceptar cual es el rumbo que la mayoría de mis paisanos europeos cree que debe de ser.
Ir a Votad!! Recordárselo a los que tengais al rededor!!
Aquí hemos visto entradas referentes a leyes, a sistemas modernos, a representantes... hoy los elegimos.
Para quien piense que no tiene sentido... es un derecho y un deber, no ir a votar desde mi punto de vista es no creer. Comprendo que la justicia y las leyes no suelen ser muy justas y que el sistema deja muuuuuuuuuuuucho que desear. Pero es lo que tenemos y debemos de procurar que este sistema sea lo más cercano a nuestras ideas.
Así que me da igual que seais Comunistas, De ideas de Izquierdas, de Ideas de Centro, de Ideas de derecha o de Ideas ultraconservadoras. Incluso si no creeis en el sistema, votar en blanco. Pero acudir a las urnas.
No hace demasiado Barack Obama se convertía en el primer presidente negro de la historia americana... y aunque pueda tener unas ideas sociales alejadas de las mías, comprendo que el mundo es un lugar muchisimo mejor y más seguro (desde mi punto de vista claro está) con un presidente como él a lo que supuso la época Bush. Y este hombre no habría sido elegido sin los votos de cada americano.
Vale, sí, el parlamento europeo no es un pais propiamente dicho, pero las decisiones que tomarán sí nos incumbirán a todos!! Me hace mucha gracia cuando alguien me dice: "Total... son políticos, todos son iguales..." Yo les digo: "Y que haces tú para mejorar eso?, ni siquiera fuistes capaz de ir a votar."
Señores, hay que mojarse, y en serio, sinceramente, me da igual que el voto sea en contra de mis ideales o a favor de ellos, pero si creo que el mundo mi pais mi... puede ser mejor con un representante u otro, vale dios que al menos lo dejaré presente con mi voto. A lo mejor no ganan mis ideas de forma mayoritaria, pero al menos lo intentaré y de "perder", lo haré con la misma humildad de aceptar cual es el rumbo que la mayoría de mis paisanos europeos cree que debe de ser.
Ir a Votad!! Recordárselo a los que tengais al rededor!!
martes, 2 de junio de 2009
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
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]
Original:
"Pagar
-Pedro: 150"
Modificado 1:
"Pagar
-Pedro: 100"
Modificado 2:
-Pedro: 50"
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
flasm -z Desktop_Dec.swf
La segunda compila el archivo (presumiblemente modificado) Desktop.flm dentro de su original Desktop.swf
La tercera descomprime el archivo
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.
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.
Suscribirse a:
Entradas (Atom)
Entradas
