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
viernes, 26 de junio de 2009
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
Suscribirse a:
Entradas (Atom)
Entradas
