Archivo de la categoría ‘Programación’

Como inhibir el “Ultima vez conectado” de WhatsApp y otros comportamientos: Ingeniería Inversa en Android

Share on Google+Share on FacebookTweet about this on Twitter

Estoy seguro que la mayoría que tenga WhatsApp le gustaría que sus contactos no supiesen cuando estás conectado a él, no son pocos los que envían un mensaje y para saber si lo han leído o no abren de cuando en cuando WhatsApp y ven el estado de conexión del otro para ver cuando fue la última vez que se conectó. Personalmente me da exactamente igual que lo vean o no, pero seguro que la mayoría piensa de otro modo.

Como con la gran mayoría de todos los experimentos, este me llegó después de que un amigo me dijese que su hermano había comprado una aplicación de Android para impedir que sus contactos pudiesen conocer la última vez que estuvo conectado al WhatsApp. Bueno en Android ya sabemos que técnicamente el Ultima vez conectado no es propiamente eso, sino cuando fue la última vez que el usuario tenía en primer plano la aplicación WhatsApp, puesto que en realidad el usuario está siempre conectado. Sabemos que los usuarios de iPhone tienen una opción para deshabilitar esto, los conocemos bien porque son aquellos contactos en los que cuando vemos su estado simplemente no aparece ninguna fecha. En Android no tenemos esta opción, pero eso no quiere decir que no pueda modificarse la aplicación para crear un comportamiento parecido, o incluso mejor.

En realidad este pequeño experimento es solo un ejemplo de la gran utilidad que tiene la Ingeniería Inversa. Pese lo que puedan pensar muchos programadores o defensores a ultranza del código propietario, la Ingeniería Inversa permite conocer mejor el software, descubrir problemas de seguridad para evitarlos, crear Software de mejor calidad… no es una lacra ni un problema, todo lo contrario, es una gran herramienta.

Volviendo al tema de hoy, cuando me dijo este amigo mío sobre dicha aplicación en Play Store sinceramente me extrañó, por la simple razón de que si es un comportamiento de la aplicación en sí, la única forma de eludirlo sería con una modificación de la misma aplicación… a menos que se tratase de un simple truco. Efectivamente, lo que hacen este tipo de aplicaciones no es más que un truco para provocar un efecto similar que puede realmente funcionar bastante bien, aunque tiene muchos problemas asociados sin duda alguna. Para saber en que se basan estas aplicaciones para esconder el estado de conexión de nuestro terminal hay que conocer antes como maneja WhatsApp dicho estado, no hay que profundizar mucho, en realidad es muy sencillo:

La primera cosa que hay que tener clara de nuevo es que en Android las aplicaciones se minimizan, no se cierran (pueden cerrarse también, pero vamos a simplificarlo), esto es debido a que Android es multitarea. Aunque WhatsApp no esté en primer plano continua en ejecución, lo que quiere decir que cualquier mensaje que nos manden, imagen… la recibimos perfectamente en nuestro terminal en ese mismo momento, el que volvamos a poner a WhastApp al primer plano no cambia nada. Teniendo esto en mente, cuando el usuario abre la aplicación o la coloca en primer plano estando minimizada, WhatsApp envía a los servidores de estos un mensaje sobre su estado de forma peródica y constante. Cuando el usuario minimiza la aplicación, este desactiva este comportamiento, con lo que de cara a cualquier otro usuario nuestro estado de conexión cambiará de “En línea” a “Últ. Vez”.  Conocer esto no requiere realmente ser un experto en nada, estoy seguro que muchos que se hayan planteado el “como funcionará…” habrá echo sus propios experimentos de cuando cambia el estado y otras cosas.

Sabiendo por tanto como es el comportamiento de WhatsApp, cualquiera podría imaginar como engañar a WhatsApp, repito, simplemente conociendo como funciona el cambio de estado. Se trataría simplemente de evitar que WhastApp comenzase a enviar esos mensajes a su servidor, y lo cierto es que tenemos una solución muy sencilla a esto, no tener conexión. El no tener conexión (ni WIFI ni datos) impediría evidentemente que WhatsAppe comenzase a enviar los mensajes de estado, pero evidentemente también impediría que WhatsApp pudiese mandar cualquier cosa a otro contacto o recibir mensajes o cualquier otra cosa, pero como ya hemos dicho WhatsApp aun estando minimizado se está ejecutando, y sabemos que el cambio de estado solo sucede cuando tenemos la aplicación en primer plano, es decir la maximizamos. Aplicando la lógica común, nos bastaría tan solo con deshabilitar datos/wifi cuando queremos volver al WhatsApp para escribir un mensaje o leer alguno ya recibido, y volver a conectar los datos/wifi cuando la minimizásemos de nuevo. Estando minimizada y con conexión, recibiría perfectamente mensajes o imágenes o cualquier otra cosa, así como también enviaría nuestros mensajes escritos a nuestros contactos, pues estarían a la espera de conexión.

Esto que he explicado puede hacerlo cualquiera en su casa en cualquier momento, y de echo funciona perfectamente, aunque por supuesto tiene muchos problemas. Las aplicaciones que están en Play Store simplemente automatizan este proceso, pero hacen exactamente lo que he indicado. Hacen que cuando se maximiza (se cambia a primer plano) WhatsApp, se deshabilitan datos y wifi, y se invierte cuando se minimiza WhatsApp. Muchos pueden pensar que es la solución perfecta, pero no solo no es perfecta puesto que no funcionaría siempre, sino que además el usuario perdería mucha funcionalidad en el WhatsApp. Por ejemplo, para mantener una conversación con alguien tendría que estar minimizando y maximizando constantemente puesto que de lo contrario sus mensajes no se enviarían ni el podría recibir nuevos mensajes! Para un mensaje ocasional funcionaría, pero si esa persona quisiese mantener una conversación mínima con cualquiera, tendría que mandar mensaje, minimizar, esperar que el otro respondiese, maximizar, escribir, minimizar.. es evidente que no es práctico de ninguna de las maneras, sin contar que lo único que el usuario podría descargar serían imágenes si tuviese activado el autoaceptar, el resto de contenido no podría descargarlo nunca.

¿Es posible dar con una solución más eficaz? Sí, ingeniería inversa. En el artículo que menciono justo abajo explico mejor que es la Ingeniería inversa para quien no lo conozca, pero digamos que en el software es básicamente el proceso de obtener información sobre como funciona una aplicación de forma interna sin disponer su código fuente original, lo que nos permite incluso modificar la aplicación misma. Recordar que en algunos países la ingeniería inversa es ilegal, aquí en España es legal siempre y cuando no se distribuya su código o cualquier modificación realizada. Es por eso que aunque puedan pedirlo algunos, no puedo colgar ningún WhatsApp modificado lo siento, cada cual que experimente si así lo desea, además la razón de este blog ha sido siempre para enseñar, no para dar.

 

 Muchos de los pasos realizados aquí, los encontramos también en otro artículo que publiqué hace ya meses. En Android, cualquier proceso de Ingeniería inversa tendría los mismos pasos a seguir:

  1. Obtener la aplicación APK (y el paquete odex en caso de ser una aplicación interna de algunos terminales)
  2. Decompilar la aplicación para obtener el código Dalvik equivalente.
  3. Realizar las modificaciones pertinentes.
  4. Recompilar la aplicación, firmarla y alinearla (optimizarla).

Con excepción al paso 3º, el resto son siempre los mismos, existiendo tan solo pequeñas modificaciones entre diferentes casos, pero nada importante. Como tales procesos están explicados en el artículo mencionado, simplemente voy a presuponer que se saben realizar. Existen herramientas incluso que nos permiten obtener un código en JAVA relativamente fidedigno desde la aplicación APK, que aunque no pueda ser recompilado, al menos será mas inteligible para la mayoría de las personas que lo es el código en Dalvik

Obtener por tanto un código que podamos modificar es simple una vez se decompila la aplicación, por ejemplo con apktool. Así que vamos a presuponer que disponemos del código ya decompilado en la carpeta “whats”, y con eso completaríamos los pasos 1 y 2.

El tercer paso sería el más tedioso, puesto que de cientos de archivos que disponemos hay que saber que se quiere modificar, donde hacerlo y como hacerlo. En realidad es lo complicado del caso. En nuestro caso ya sabemos que queremos modificar, queremos suprimir el estado de conexión de nuestro WhatsApp, pero seamos coherentes, tenemos una carpeta con el código decompilado que pesa más de 40MB y contiene más de 4000 archivos. Evidentemente tenemos que acotar nuestra búsqueda, o podríamos tardar años. A este problema se le suma el echo de que inevitablemente tenemos que conocer algo de programación en Android y de como funciona Dalvik, de lo contrario es imposible que pudiésemos encontrar el lugar (o lugares) en el que se implementa dicho comportamiento o como se tendría que modificar. Por suerte para nosotros, el código Dalvik resultante de la compilación es bastante más legible que el código ensamblador de la arquitectura x86. Dalvik es una máquina virtual basada en registros, y en el mismo código podemos ver por suerte la llamada a las funciones que son usadas, así como los parámetros pasados. Esto es una ayuda infinita sin duda, ya que simplemente con conocer a grandes rasgos el SDK de Android, podemos empezar a buscar lo que deseamos.

En nuestro caso concreto, presuponiendo que tan solo tenemos la idea que mencioné al principio de como/cuando se actualiza el estado de conexión, tendríamos que comenzar por ahí. Lo primero que sabemos es que nuestro estado cambia al volver WhatsApp al primer plano, es decir, en el código tiene que existir algún disparador que se acciona al realizar este cambio de estado en la aplicación. Cualquiera que le guste la programación en Android o simplemente haga un poco de investigación, antes o después encontraría esta imagen en la documentación oficial de Android:

actividad

 

Por supuesto existe documentación extensa sobre todo ello en el portal oficial, pero esta imagen es suficiente. Lo que nos dice esta imagen es que existen funciones concretas que son disparadas cuando nuestra aplicación cambia de estado, ya sea al iniciar la aplicación, al empezar a ejecutarse, al “resumirse”, al pausarse, al pararse, cerrarse, reiniciarse… lo cierto es que tenemos unas cuantas opciones. Si fuésemos un poco curiosos, también sabríamos que la función exacta que se dispara cuando una aplicación pasa de segundo plano a primer plano (maximizarse) se llama OnResume(), y la función que se aplica al pasar de primer plano al segundo es onPause(). Estos nombres pueden causar un poco de confusión ya que en realidad una aplicación en Android no se pausa propiamente dicho, pero obviemos esto.

Es evidente que una aplicación puede tener otros sistemas para detectar si la aplicación se encuentra en primer plano o no, pero siempre hay que partir de presunciones y ver a donde nos llevan, si son un callejón sin salida hay que volver y replantarse el problema para optar por otras opciones. Pero si WhatsApp está usando realmente onResume() para la actualización de nuestro estado, al menos podríamos ser capaces de realizar una gran criba. Así pues, si nos basamos en esta teoría, podríamos usar el comando findstr (en windows) o grep (en linux) para buscar dicha función dentro del código Dalvik, puesto como he dicho el nombre de las funciones se encuentran en él:

E:\Android\Proyectos\Whats>findstr /S /I /M onResume *.*
smali\com\whatsapp\AccountInfoActivity.smali
smali\com\whatsapp\BlockList.smali
smali\com\whatsapp\ContactInfo.smali
smali\com\whatsapp\ContactPicker.smali
smali\com\whatsapp\Conversation.smali
smali\com\whatsapp\Conversations.smali
smali\com\whatsapp\DeleteAccount.smali
smali\com\whatsapp\DeleteAccountConfirmation.smali
smali\com\whatsapp\DescribeProblemActivity.smali
smali\com\whatsapp\DialogToastActivity.smali
smali\com\whatsapp\DialogToastListActivity.smali
smali\com\whatsapp\EULA.smali
smali\com\whatsapp\GroupChatMap.smali
smali\com\whatsapp\LocationPicker.smali
smali\com\whatsapp\MediaGallery.smali
smali\com\whatsapp\MultipleContactPicker.smali
smali\com\whatsapp\OverlayAlert.smali
smali\com\whatsapp\RegisterName.smali
smali\com\whatsapp\RegisterPhone.smali
smali\com\whatsapp\Settings.smali
smali\com\whatsapp\VerifyNumber.smali
smali\com\whatsapp\VerifySms.smali
smali\com\whatsapp\ViewSharedContactActivity.smali
smali\com\whatsapp\wallpaper\CropImage.smali
smali\com\whatsapp\wallpaper\WallpaperPicker.smali

Simplemente con esto, si realmente WhatsApp usa dicha función para el cambio de estado, estaríamos restringiendo la búsqueda de más de 4000 archivos a 25 posibles lugares, en los cuales puede ser por supuesto más de uno. 25 es un número suficientemente manejable como para ir buscando en cada archivo manualmente, pero no soy un sádico y vamos a acotarlo aun un poco más. Con poco de inglés que sepamos y aplicando un poco la lógica común, podríamos cribar estos 25 resultados desechando aquellos que parecen no tener absolutamente nada que ver con la actualización del estado, ya que el listado anterior simplemente nos dice donde se está usando dicha función, pero evidentemente dicha función se usa para muchas cosas, no solo modificar supuestamente el estado:

smali\com\whatsapp\AccountInfoActivity.smali
smali\com\whatsapp\DialogToastActivity.smali
smali\com\whatsapp\DialogToastListActivity.smali
smali\com\whatsapp\ViewSharedContactActivity.smali

La razón por la que he suprimido los anteriores no está basado en que evidentemente antes de escribir estas letras ya sé que modificar o buscar, sino en el sentido común. Si tengo un archivo llamado WallPapperPicker, es de suponer que el punto exacto que estoy buscando no se encuentra en él. Por supuesto, de nuevo se está simplemente presuponiendo, esta aseveración podría ser errónea y llevar a un camino sin salida, con lo que de nuevo tendríamos que dar marcha atrás, aumentar el campo de búsqueda y ver si hay mas suerte.

Por experiencia y por el nombre de los archivos, automáticamente habría optado de los 4 archivos mencionados por el segundo y el tercero, DialogToastActivity y DialogToastListActivity, puesto que precisamente lo que quiero es inhibir el estado de conexión, el cual se refleja en lo que en ingles podría llamarse “toast”. Si esos dos archivos no me diesen la solución que busco, buscaría en los otros dos. En este caso concreto, lo que se busca está exactamente en el archivo DialogToastListActivity.

Este archivo podemos editarlo con cualquier editor de texto, y por suerte es un archivo pequeño, unas 670 líneas. Si buscamos por onResume, vemos que nos lleva a la línea 600 aproximadamente, y vemos que comienza un pequeño bloque de unas 25 líneas en Dalvik, algo sinceramente bastante pequeño. Llegado a este punto llegaría la segunda parte complicada, que punto modificar y como, a lo mejor basta con eliminar, a lo mejor se requiere modificar o quizás es añadir. Esto ya es más complejo porque implica tener conocimientos de Dalvik, que aunque es bastante sencillo hay que entenderlo. En este caso concreto podemos hacer alguna chapuza rápida que funcione relativamente bien, para no tener que entrar en muchos detalles.

Si leemos el bloque, vemos que en un momento dado se llama a la función onResume, y después de ello la siguiente función que se invoca de forma clara es sendEmpyMessageDelayed. Posiblemente la mayoría de programadores de Android conocen dicha función, y quien no la conozca puede buscar información al respecto, pero básicamente lo que hace esa función es enviar un mensaje cada X milisegundos, y aquí la palabra mensaje adquiere un amplio significado.

El pedazo de código que nos interesa sería por tanto:

    .line 8
    iget-object v0, p0, Lcom/whatsapp/DialogToastListActivity;->d:Lcom/whatsapp/jd;
    const/4 v1, 0x0
    const-wide/16 v2, 0xbb8
    invoke-virtual {v0, v1, v2, v3}, Lcom/whatsapp/jd;->sendEmptyMessageDelayed(IJ)Z
    .line 2
    const/4 v0, 0x1

En java, todo ello equivaldría más o menos a:

d.sendEmptyMessageDelayed(0, 3000L)

En Android sería algo así como enviar el mensaje ‘0’ cada 3 segundos desde que la aplicación se resuma. Si estamos en lo cierto y todas las presunciones son ciertas, que pasaría por tanto si elimino dicho bloque?? En realidad en Dalvik hay que tener mucho cuidado porque es un lenguaje basado en registros, con lo que no suele ser bueno eliminar asignaciones a registros, puesto que quizás la línea que esté más abajo use el mismo registro para otra cosa, y si la asignación se elimina tendremos problemas. Por tanto podríamos limiter la eliminación a la línea:

invoke-virtual {v0, v1, v2, v3}, Lcom/whatsapp/jd;->sendEmptyMessageDelayed(IJ)Z

Si eliminamos esa simple línea, y todo lo que hemos dicho se cumple, al resumir la aplicación nunca se comenzaría a enviar el mensaje de actualización de cambio de estado (o lo que sea que contenga en ese punto los mensajes ‘0’). La pregunta es si realmente ese es el punto exacto, o si dicha modificación posee efectos no deseados. Pero para eso la única opción posible es recompilar la aplicación con el cambio realizado y probarlos.

 

En este caso concreto, veríamos que efectivamente simplemente por eliminar dicha línea y recompilando el código, funcionaría perfectamente. No obstante tendría dos efectos secundarios no deseables, aunque serían “mínimos”. Realizando dicho cambio nunca veríamos si el contacto con el que hablamos está o no conectado en ese mismo momento, así como que tampoco nos aparecería el “Está escribiendo…”, pero nada más, todo lo demás funcionaría perfectamente. Este problema es debido a que el mensaje ‘0’ que se envía cada 3 segundos no solo contiene nuestro estado de conexión. Por supuesto que esto puede ser perfeccionado y mejorado para suprimir tan solo nuestro estado de conexión.

Otra aplicación práctica de todo ello sería por ejemplo suprimir el envío de “Está escribiendo…” de forma que el contacto con el que hablamos nunca pueda saber si estamos escribiendo o no, lo cual implicaría por ejemplo eliminar un par de líneas en el archivo App.smali sin ningun otro efecto secundario. Podría aplicarse también para producir el efecto opuesto, aparentar estar siempre en línea, o incluso crear en las opciones un botón para habilitar o deshabilitar la actualización de estado a voluntad. En realidad no hay límites, simplemente hay que pensar que deseamos hacer e implementarlo.

conexion

Esa imagen está tomada desde otro WhatsApp el día 9 de febrero mientras ambos mantenían una conversación, en el estado vemos perfectamente que la última vez de conexión de Theliel (Alma Oscura) fue el 30 de Enero, contacto con el que además se estaba hablando en ese mismo momento, con lo que tendría que poner en línea de echo.

 

 Un saludo, y disfrutar de la invisibilidad de WhatsApp.

 

Google I/O 2012: Android 4.1 (Jelly Bean), Nexus 7, Nexus Q y Google Glass

Share on Google+Share on FacebookTweet about this on Twitter

Espectacular Keynote presentado en su mayoría por Vic Gundotra. Las predicciones, rumores y expectativas creadas estos días se han ido cumpliendo más o menos a la perfección durante las dos horas largas que duró la conferencia, dejando como sorpresa totalmente inesperada el llamado Nexus Q y el estado avanzado sin duda del proyecto Glass. Veamos los puntos más candentes de este Keynote, que seguro darán mucho que hablar estos días en los medios de todo el mundo, algunos por su genialidad y otros simplemente por no entusiasmar demasiado (al menos para mi):

 

 

Android (4.1 Jelly Bean)

Es evidente que Android ha acaparado prácticamente todo el Keynote por un motivo u otro, y es que Google ha creado un auténtico ecosistema de gran éxito, mucho más de lo que se pueda imaginar uno si nos atenemos a las cifras que se han echo pública al comienzo de la conferencia: 1 Millón de activaciones diarias. En todo 2011 se contabilizaron aproximadamente unos 100 Millones de dispositivos Android, mientras que en lo que llevamos de 2012 se contabilizan más de 400 Millones, es decir, 4 veces más que el año pasado!! 1 Millón de activaciones diarias (y en aumento) es un número sobrecogedor.

Una vez revelados datos de activaciones (Google no suele mostrar gráficas al estilo Apple para mostrar cuotas de mercado o historias similares), han entrado directamente como era de esperar con Jelly Bean (JB apartir de ahora), la versión 4.1 de Android, que sustituirá la actual rama Ice Cream Sandwitch 4.0.4 (ICS a partir de ahora). Hay que tener en cuenta que JB no es una remodelación tan sustancial como lo fue ICS respecto a Gingerbread, y de ahí que el lapso de tiempo entre ICS y JB no haya sido demasiado. No obstante no quiere decir que no esté exenta de novedades, algunas de ellas esperadas y más que bien recibidas.

Su lanzamiento oficial será a mediados de Julio, en el que se lanzará de forma simultánea la OTA (actualización) para Galaxy Nexus y Motorola XOOM. Se liberará de forma simultánea también el código en AOSP. Sobre el Nexus S no se dijo nada, seguramente verá aparecer la OTA, aunque más tarde. El SDK sin embargo se prometió que aparecería de forma inmediata, y de echo ya es´ta disponible desde el SDK Manager, para que todos los desarrolladores tengan acceso ya a él. También se lanzará lo que han llamado si no recuerdo mal DSK, un SDK para proveer las herramientas de forma fácil a los fabricantes de hardware para que adapten este a JB, dándoles herramientas y código en bajo nivel. Seguro que será de agradecer sobre todo en la comunidad AOSP para soportar modelos más antiguos.

 

Veamos los puntos fuertes de JB ahora

 

-Butter (Mantequilla)

Es el nombre con lo que los ingenieros de Google bautizaron el proyecto de JB orientado a mejorar sustancialmente el rendimiento del sistema de ICS. Básicamente han querido lograr un rendimiento completo de 60fps en cualquier aspecto del sistema, para lo cual han implementando funciones como la sincronización vertical (Vsync) o el Buffer triple (Triple Buffer). Estas dos funciones serán bien conocida para la mayoría de Jugadores de los PCs, y básicamente buscan la fluidez generalizada del sistema, desde la apertura de los menús, giros de pantalla, aperturas/cierres de pantallas…

Por otro lado han implementado al sistema lo que ellos llaman anticipación de pulsación de la pantalla, en conjunción de una escalada automática de la frecuencia de la CPU cuando es necesaria, evitando así pequeñas micropausas debido a esta escalada de la CPU. También se ha creado una herramienta systrace para que los desarrolladores puedan mejorar igualmente el rendimiento de sus propias aplicaciones.

Los resultados se mostraron en dos terminales Galaxy Nexus, uno con ICS y otro con JB, en el que JB exhibía tanto una mayor rapidez en tareas tan simples como abrir/cerrar la lista de aplicaciones, como en la suavidad al hacerlo. Por supuesto para poder medir los tiempos tan ínfimos se usó camaras de alta velocidad para captar los momentos.

El resultado es evidente, mejor rendimiento, más suavidad. Este cambio era muy esperado y se han portado.

 

-Escritorio

El Launcher ha sido remodelado y se ha mejorado bastante la manipulación de las pantallas de inicio. Ahora los Widgets son más flexibles, y los iconos de las pantallas del escritorio se reorganizan automáticamente si el Widget quiere situarse encima de cualquiera de ellos, sin que sea necesario tener que recolocarlos antes de insertar el Widget. También es más fluida la navegación si cabe. Un toque de comodidad para muchos desde luego

 

-Teclado y reconocimiento de voz

Se mejora considerablemente la predicción del teclado, añadiendo biagramas y aproximando su funcionamiento al que pueda usar Swiftkey. Por otro lado se añaden hasta 18 nuevos idiomas de entrada!! cosa que hará feliz a muchas partes del mundo. Queda por ver si al final podremos usar realmente el teclado de Android como teclado principal.

El reconocimiento de voz sufre igualmente una importante mejora, y es que se podrá usar aun cuando no dispongamos de datos, y así quedó bastante claro y funcionando a la perfección en el keynote. Por desgracia esta función tan solo estará disponible al principio en Inglés, aunque se espera que los idiomas principales sean añadidos bastante pronto. Sinceramente un detalle hacia todos ellos que no disponen datos o tienen que operar sin ellos.

 

-Accesibilidad

Para personas discapacitadas se han añadido otras dos buenas mejoras. La primera el control del dispositivo por medio de gestos y la voz para invidentes, y la segunda es la compatibilidad con Braille, cuyo dispositivo podremos conectar mediante Bluetooth.

 

-Cámara de Fotos

Se añade una revisión rápida tipo carrousel para las fotos. Es decir que después de realizar las fotos que sean (pongamos por ejemplo 10 fotos) podremos desplazarnos rápidamente de una a otra dentro de la misma cámara, eliminando la que deseemos simplemente desplazándola hacia arriba, y volviendo a la cámara simplemente desplazando la pantalla hacia el extremo izquierdo. Es cómodo sobre todo a la hora de tomar varias instantáneas buscando la correcta, y quedarnos con la adecuada para descargar el resto. Similar a lo que vemos en el Galaxy S3.

 

-Android Beam (NFC)

A las ya conocidas funciones de NFC se añaden el intercambio por NFC de fotos y vídeos, así como la posibilidad de emparejar de forma automática dos dispositivos por Bluetooth. Creo que la tecnología NFC es muy interesante sin duda alguna y con la llegada de cada vez más terminales compatibles con esta tecnología comenzaremos a darnos cuenta realmente de las posibilidades que tenemos al alcance de la mano, y eso sin hablar siquiera de los tags NFC.

 

-Notificaciones

Uno de los grandes cambios sin duda se los lleva las notificaciones. Si ya de por sí Android ha sido muy superior a cualquiera producto de la competencia por sus notificaciones, estas se vuelven ahora muchísimo más personalificables, pudiendo crear las aplicaciones notificaciones extensibles, anidadas, con imágenes… por ejemplo será posible leer los propios correos electrónicos desde las mismas notificaciones expandiendo la notificación de aviso sin necesidad de entrar en la aplicación de correo.

 

-Google Search y Google Now

Junto con Butter y las nuevas notificaciones, conforman los cambios más notables que se han realizado. En este caso Google ha remodelado de forma sustancial Google Search, aproximándolo como ya vimos a ese “Asistente Virtual”. No sabemos si es un primer paso hacia Majel o si realmente este es el resultado, pero sin duda alguna es de agradecer. En contra de lo que hizo Apple con SIRI, este nuevo Google Search no mantiene conversaciones bidireccionales por así decirlo (lo cual como dije hace unos días me parece totalmente absurdo), sino que más bien interpreta el lenguaje natural para responder a las preguntas que les hagamos. De este modo Google integra la reciente herramienta de su motor de búsqueda llamada “Knowledge Graph” en Google Search para Android. En las demostraciones se hacían preguntas tan dispares como por ejemplo “¿cual es la distancia a la luna?” o “Imagénes de…” en ambos casos evidentemente mostrando un comportamiento excelente.

Por otro lado nace Google Now, que es una de las novedades que son realmente novedades. Google se saca de la manga una herramienta que sería algo así entre una mezcla de asistente personal inteligente y bola de cristal que adivina el futuro, que más que preguntarles nosotros algo, él nos predice lo que queremos en ese momento. Es decir, Google Now tendrá acceso a todos tus datos de Google, desde tu historial de búsqueda, ubicaciones, hora y fecha, calendario, agenda… todo. La idea es simplemente usar este gran compendio de información para ir aprendiendo poco a poco de como es el día a día del usuario y sugerirle opciones a lo largo de su día. Un ejemplo simple:

El usuario se levanta para ir a trabajar como todos los días, Google Now que conoce el día que es, la hora y la ubicación presupone que el usuario se dispone a ir a trabajar y automáticamente sin que este le diga nada o interactúe de alguna forma con su teléfono, Google Now recabará información por ejemplo del tráfico actual y la hora, y si el usuario accede a Google Now en algún momento este le sugerirá tomar a lo mejor una ruta alternativa para ir al trabajo si hay tráfico y la hora es apurada, sin que el usuario le haya dicho absolutamente nada. Otro ejemplo sería si el usuario se le hace tarde en el trabajo y se hace la hora de comer por ejemplo, Google Now le sugeriría en función de varios parámetros y de su ubicación algún lugar para almorzar. O por ejemplo si el usuario se aproxima a una estación de autobuses urbanos, este automáticamente le diría el próximo autobús en pasar.

Por supuesto son solo algunos de los muchos ejemplos y desde Google aseguran que irán añadiendo más y más funciones cada día, y que cuanto más se use, el sistema aprenderá más de nosotros y será infinitamente más efectivo. Como usuario tengo que decir que lo veo con recelo, pero no porque me parezca mala la idea ni mucho menos, sino porque presupongo que tan solo será realmente efectivo en aquellos países en los que todo está totalmente informatizado, dudo mucho que en España tengamos acceso a muchas de esas funciones… por supuesto habrá que esperar y probarlo, y ver como se comporta aquí en nuestras casas. Si funciona tan solo la mitad de bien que aparenta, sinceramente SIRI va a tener que empezar a usar los servicios de Google Now para ubicarse 😉

 

 

Google Play

Otro gran protagonista fue como era de esperar Google Play, nombre con el que recordemos Google aunó muchos de sus servicios bajo un mismo nombre. Todo empezó señalando que Google Play Store ya cuenta con más de 600.000 aplicaciones!! Recordemos que no hace mucho rondaban las 300.000. Actualmente no sé si ya habrá logrado alcanzar al App Store en número de aplicaciones, pero si no lo ha hecho debe de estar bien cerca.

Quedó señalado sobre todo para los desarrolladores que Google está mejorando constantemente las condiciones para estos, haciendo alusión a la bien acogida que ha tenido el pago desde las mismas aplicaciones entre otras muchas medidas. También se han puesto de acuerdo con numerosas nuevas compañías para permitir el pago directamente desde el mismo SIM, facilitando en mucho la labor de cualquier usuario que desea comprar alguna.

A partir de aquí se hicieron de forma rápida como si no tuviesen mucha importancia varios anuncios bastante importantes respecto Google Play. Para empezar, para proteger el código de los programadores y posiblemente la piratería se cifrarán las aplicaciones con una Key que será específica para cada dispositivo (presupongo que similar al sistema actual de Apple, aunque habrá que ver que tipo de cifrado o como se descomprime en memoria la aplicación o si solo será para transferirla). Más interesante si cabe y una de esas grandes noticias ha sido el anuncio de las actualizaciones dinámicas!! Es decir, a partir de ahora no hará falta descargar la aplicación completa cuando existe una actualización, sino que si el desarrollador lo permite evidentemente, nuestro Play Store aplicará simplemente actualizaciones sobre las aplicaciones, ahorrando tanto en tiempo como en ancho de banda. Para el usuario es un ahorro importante, y para los creadores de software una buena ayuda.

Los desarrolladores también se verán “premiados” con el uso C2DM De Google. C2DM es un servicio de Google que permite a los desarrolladores mantener por así decirlo sus aplicaciones en contacto con otros servicios, es algo así como un pequeño almacenamiento en nube temporal que hace de intermediario entre las aplicaciones y el software servidor del fabricante. Esto que parece una tontería es usado de forma extensiva en muchísimas de las aplicaciones actuales. Pues bien, hasta hoy había que pagar si se quería superar una cuota de almacenamiento y otras limitaciones, y a partir de hoy el servicio será totalmente gratuito para todos y sin ningún tipo de limitación. Esto supondrá otro ahorro económico para todo aquel que use este servicio.

De cara al usaurio las mejoras tampoco han sido nulas. Primero el usuario es por supuesto quien se beneficia de forma indirecta de las mejoras anteriores, pero además Google abre dos secciones nuevas a su cada vez más extenso Google Play. Hasta la fecha disponíamos de Play Store, Play Music, Play Books y Play Movies (que no es poco). Y a partir de hoy se dispondrá además de Play Magazines y se añadirán programas de televisión (imagino que entrará dentro de Play Movies), desde series completas, programas… Es evidente que todos estos cambios no llegarán de forma inmediata a España, pero poco a poco irán apareciendo. Recordemos que en España ya tenemos disponible Google Movies y Google Books (aun nos falta por desgracia Google Music).

 

 

Nexus 7

 

Otro de los secretos a gritos que prácticamente todos sabían que llegaría. No puede decirse mucho puesto que todos los rumores se conformaron al respecto, y es que Google por fin se ha decidido a poner a una Tablet su sello de la mano de ASUS. Pero a diferencia de su Galaxy Nexus, esta tablet no solo es interesante desde el punto de vista de que será excepcional para desarrolladores, sino que está orientada a un sector que prácticamente hoy no existe, que son tablets de bajo coste. Y con bajo coste no me refiero a Tablets de mala o dudosa calidad, sino con las más altas prestaciones:

Plataforma Tegra 3: Procesador de 4 núcleos (no se dijo velocidad, presumiblemente 1.3Ghz) y GPU de 12
Pantalla: 7′ como era de esperar (no es de extrañar que veamos próximamente una versión de 10), con una resolución de 1280×800
RAM: No fue comunicado, es de esperar que posea mínimo 1GB
HDD: Creo que no fue comunicado (y si lo fue me lo perdí), pero creo que son 8-16GB
Sensores: WIFI n, Bluetooth, cámara frontal (creo que de 5MP, pero no lo recuerdo), Giroscopio, Acelerómetro, NFC o GPS
Datos: No, pero se le podrá conectar por medio de USB
Medidas: No se dieron, pero el diseño era extra delgado y bastante bonito
Peso: Atención!! 340 gramos!!
Batería: 9 Horas de autonomía

Ni que decir tiene que llegará con Jelly Bean totalmente optimizada para él, y queda lo mejor… el precio. Y es que hablamos de un tablet de la que hemos omitido el precio por algo… saldrá al mercado por tan solo 199$!!, unos 150€ al cambio aproximadamente. Hablamos de un tablet mejor prácticamente en todos los sentidos que el iPad, pero de 7 pulgadas, con un precio muy muy inferior. Sin duda alguna 150€ sí es un precio que estará más que dispuesto a pagar más de uno por este capricho, lejos de tener que desembolsar los 500-700€ que cuestan modelos más grandes o con datos. Repito, 150€. Sí, es “solo” de 7 pulgadas, pero son 150€ por el hardware comentado. Impresionante sin duda. A la venta igualmente a mitad de Julio.

 

 

Nexus Q

 

Conocido anteriormente como Proyecto Tungsten del cual creo que absolutamente nadie conocía. Llevado en total secreto Google se ha sacado de la manga un nuevo dispositivo llamado Nexus Q. Este dispositivo de forma esférica y de un tamaño reducido poseerá un procesador OMAP igual al que posee el Galaxy Nexus, y su función será el de servir de intermediario a televisiones y equipos de sonido para realizar streaming directamente desde la nube, y en constante sincronización y entendimiento con el resto de dispositivos Android del hogar.

Este dispositivo se conectará por ejemplo a nuestro televisor permanentemente a un lado de este o encima de la mesa o… (lo cierto es que es bastante bonito el diseño) y desde cualquier dispositivo Android podremos por ejemplo ver una película que tengamos en Google Movie o por ejemplo cualquier canción que tengamos en Google Music. No es un dispositivo que realizará streaming desde nuestros dispositivos Android al televisor, sino que nuestro dispositivo será el que haga de terminal de control. Si damos la orden de escuchar la canción A de Music, este la tomará de la nube y la mandará a la televisión o al equipo de música, y lo mismo para una película. Se permitirá también la interacción mutua de diferentes dispositivos, por ejemplo podría llegar otro miembro de la familia y añadir a la lista de reproducción del Nexus Q. También se podrán sincronizar entre ellos diferentes Nexus Q de existir, haciendo que todos ellos reproduzcan al mismo tiempo lo que sea (pensar en diferentes habitaciones) o controlar cualquiera de ellos de forma independiente.

Personalmente no lo veo especialmente útil, es cierto que es como tener nuestro Google Play conectado constantemente a la pantalla de casa o al equipo de música, pero la carencia de no poder reproducir directamente en Streaming contenido que tengamos físicamente en nuestro dispositivo es un lastre. Además, desde mi punto de vista es un juguete caro, y es que posee un precio de 299$, eso sí, ya se encuentra a la venta.

 

 

Project Glass

El momento más espectacular lo dio sin duda alguna la irrupción de Sergey Brin (Co-fundador de Google) mientra Vic hablaba sobre las novedades de Google+. Entró luciendo las gafas de realidad aumentada de las que ya hemos hablado y comenzó conectando en completo directo con el espectáculo que tenían preparado… impresionante.

En primer lugar Sergey por medio de Glass conectó y Hangout (las quedadas de Google+ que permiten videoconferencias de los participantes que sean) con un avión que sobrevolaba el centro de Moscow (donde se está celebrando el Google I/O) en el que estaban listos para ser lanzados en paracaídas. Los 5 paracaidistas contaban todos ellos con unas gafas por cortesía de Google por supuesto y todos ellos como he dicho conectados por Hangout, con lo que en pantalla podíamos verlos a todos, al más puro estilo de los Marines de Alien 2 cuando en el centro de comunicaciones se ve la cámara de cada Marine. Después de unas risas y de terminar de ascender los 4 paracaidistas saltaron al vacío, con las respectivas gafas y por tanto registrando en el Hangout la visión de cada uno de ellos.

Al aterrizar todos ellos en una alta azotea, aparecieron unas bicicletas junto a ellos y se montaron 7 ciclistas para dar el relevo a los paracaidistas, los cuales entregaron una bolsa que debían de dar al propio Sergey. Los 7 profesionales por supuesto montados en sus bicis estaban provistos también con las gafas famosas y de nuevo conectadas al Hangout que en todo momento se veía en la sala del Keynote. Después de realizar algunos saltos espectaculares los ciclistas, llegaron hasta el filo del edificio en el que se entregaba la bolsa a un especialista de rapel, que se precipitó edificio abajo hasta alcanzar un balcón en el que le esperaba otra bicicleta (por supuesto este personaje también con las gafas).

El resto fue tomar la bicicleta, entrar en el recinto del Keynote, atravesarlo y dirigirse hacia la sala del Keynote y de este modo llegar hasta Sergey. Por supuesto en la bolsa había unas gafas.

Se desvelaron algunos datos de las gafas como su conectividad a datos, acelerómetro, cámara, brújula, micrófono… su integración con Google Search y sin olvidar que las gafas mismas proyectan al ojo información diversa, como por ejemplo el tiempo que hace, uan ruta a seguir… sin molestar en absoluto la visión dele usuario. Eso sin contar con la posibilidad de grabar vídeo, tomar fotografías y otros desde una visión de tercera persona.

Se dijo que aun eran incluso un prototipo y que aun quedaba mucho por hacer, que estaban en la búsqueda constante de ideas y otros campos de aplicación. De este modo en todo momento pidió la colaboración de los desarrolladores y otros para compartir ideas, y allí mismo el mismo Sergey anunció que durante el Keynote sería posible (tan solo a los asistentes del Google I/O) una versión “prototipo” de las gafas llamadas “Google Glass Explorer” que podrían comprar, tan solo para estadounidenses y a los presentes. De este modo abrirían el círculo actual del equipo de Google Glass a un público más extenso, sin llegar a poner el producto realmente en la calle. Esto es una idea realmente interesante porque permite a unos disponer de algo totalmente experimental y revolucionario, y a Google a recopilar datos e ideas.

Por supuesto el precio para esas Google Glass Explorer no iba a ser gratuito, y se fijaba en 1500$. Hay que tener en cuenta que para empezar es un prototipo, y que no es un producto al público, de ahí también su elevado precio (no es un producto que se fabrique a granel precisamente). Lo que está claro es que Google Glass ha pasado de ser una mera utopía a algo bien real y cercano.

Quien sabe, igual dentro de poco todos tengamos unas gafas semejantes. Hay que tener en cuenta también que la idea no es tener las gafas que ellos quieran, sino que el artilugio sería posible acoplarlo a otras. Por otro lado no hablamos de algo voluminoso, y su peso sería incluso menor a muchas de las gafas de sol convencionales que tenemos. Muy interesante sin duda alguna

 

 

Google+

En último lugar encontramos las grandes mejoras que se están haciendo en Google+. Para empezar y pese a todo, se estima que Google+ ya cuenta con más de 250 Millones de usuarios, y su uso es mucho más inteligente por parte de los usuarios que el que existe en Facebook. Las grades empresas, medios y personajes famosos se decantan principalmente por esta red por ser bastante más seria que Facebook, sin contar con las características estrella de Google+ como las quedadas (Hangout), la compartición de información y ni que decir tiene la aplicación de Android o la navegación por Google+ desde el propio PC, o los círculos y la posibilidad de compartirlos con otros, o el control absoluto de nuestros datos, o el sistema de notificaciones o…. si los usuarios de Facebook tuviesen solo una idea de lo que brinda Google+, de seguro que hacía mucho tiempo que Facebook estaría bajo mínimos.

Se añade además a Google+ un lugar en el que se centralizarán todas las imágenes compartidas por nuestros contactos, así como la inclusión de Google+ Eventos (funcionalidad similar a los Eventos de Facebook). Las aplicaciones para Android tanto para tablets como para teléfonos vuelve a mejorar aun más (francamente es increible la aplicación, pido a todos que usen una y  que luego usen la de Facebook… es como comparar el paleolítico/facebook con la era espacial/Google+). La versión para iPad aun tardará en llegar con las nuevas mejoras.

 

 

Y por si todo fuese poco, al terminar el Keynote, Vic se volvió a los presentes para decirles (a los 6000 presentes que se dice pronto) que antes de marcharse de Google I/O serían “recompensados” por asistir al evento con lo que llamaron el pack de supervivencia (o similar). Básicamente se REGALÓ a cada uno de los presentes (de los 6000) un set consistente en:

-1 Galaxy Nexus que se actualizaría nada más encenderlo a una pre-versión de JB
-1 Nexus 7 con JB
-1 Nexus Q

Sé de convenciones en las que se regalan llaveros, bolígrafos e incluso Pendrive… Google lo ha hecho con sus tres productos estrellas del momento a todos y cada uno de los 6000 presentes. No sé si alguien ha echado cálculos, pero Google se podría haber gastado fácilmente en esos regalos unos 4 Millones de Euros. Estoy seguro que más de uno lamentará no haber podido asistir. Quien faltó por desgracia fue Larry Page (Cofundador de Google y actual CEO), del que se ha dicho que sufre de problemas en el habla.

Sea como sea, tengo que decir que aunque Nexus Q me ha dejado un poco igual, las mejoras introducidas en Jelly Bean, el novedoso Google Now y las mejoras de Google Search, el por supuesto esperado Nexus 7 y ya ni que decir sobre Google Glass, deja a otras novedades que fueron muchas como el uso de Chrome como navegador predeterminado en el Nexus 7 y otras tantas lindezas casi sin importancia alguna. Muchas de las cosas que hemos hablado están desde hoy disponibles como actualizaciones de las aplicaciones de Android Google Maps que ahora podemos trabajar offline, Google+, YouTube o el SDK de Android. Otras como JB llegarán dentro de dos o tres semanas y otras aquí a españa posiblemente a lo largo del año.

2 horas interesantes que recomiendo a cualquiera que no pudiese seguirlo en directo y que quiera echar un vistazo de lo que traerán los próximos meses, y es que eso es lo mejor de todo! no hablamos de tecnologías, programas, noticias… que tan solo veremos publicadas en algunos medios, sino que es lo que vamos a ver, usar y disfrutar sin duda alguna los próximos meses.

Un saludo a todos!

Google I/O 2012 – En Directo

Share on Google+Share on FacebookTweet about this on Twitter

Google + Apache = mod_pagespeed

Share on Google+Share on FacebookTweet about this on Twitter

Hace unos días, estaba optimizando en la medida de lo posible el blog para que mis visitantes pudiesen cargar la web de una forma más veloz y con menos carga, cosa que siempre es deseable, no por mi blog en concreto, sino para cualquier web que exista. Y me topé sin querer entre una cosa y otra con un mod interesante para Apache. La sorpresa fue cuando el mod corría a cargo de Google. Es posible que la noticia no sea nueva, pero la verdad desconocía este módulo por completo.

Cualquiera que le guste la programación HTML o que haya profundizado aunque sea un poco de la web antes o después termina por encontrar la herramienta Firebug para Firefox (evidentemente). Esta herramienta es maravillosa, esto lo sabe bien cualquier programador HTML/PHP/CSS que pueda estar leyendo, desde el análisis de la propia web, edición insitu, depuración de JS, modificación CSS al instante, cabeceras HTML, peticiones…. francamente es de las herramientas más útiles que existen. Pues bien, desde hace ya bastante tiempo Google mantiene un complemento a este complemento llamado PageSpeed.

PageSpeed permite desde FireBug analizar cualquier web en busca de problemas conocidos de rendimiento, por poner unos ejemplos desde que la web no usa compresión, las imágenes están mal comprimidas, peticiones DNS en demasía, consejos para optimizar el código, código JS o CSS repetido, errores en el código JS o CSS, fallos en las cabeceras que se están recibiendo desde el servidor y como mejorarlas… en fin que hace un chequeo a fondo y en unos segundos. Es muy útil porque no solo identifica posibles problemas (y digo posibles porque evidentemente la aplicación no es perfecta y pueden aparecer falsos positivos) sino que ademas primero valora de 1 a 100 la puntuación de tu site, y segundo porque a cada problema expone si quieres una explicación detallada e igualmente los pasos a seguir para solucionarlos.Esta herramienta se hace fundamental desde por las malas prácticas que se tienen a la hora de programar como simplemente la comodidad. En cambio, no nos damos cuenta que simplemente con 3 tonterías y media, podemos hacer que una web sea 3, 4, 5 veces más rápida. Y todo ello sin costo alguno. Es lo mismo que sucede con la seguridad, los programadores a veces son verdaderos genios en la construcción de algoritmos, pero muchas veces pierden por ello otros puntos como las optimizaciones o la seguridad. En el caso de las web suele ser un poco lo mismo, cargar la web más rápidamente!! lo cual por supuesto influye las imágenes, la comprensión, las peticiones a los servidores, el caché… un sin fin de detalles. Esto además si contamos con los dispositivos portátiles es aun más importante, dado que estos muchas veces tienen limitaciones de transferencias, lo cual una web menos pesada implica también pagar menos.

Bien, la noticia no es por PageSpeed que funciona muy bien, sino que Google ha tenido o tubo una mejor idea. Ya tenemos la herramienta para detectar posibles problemas, ¿por qué no crear un módulo para Apache que pueda de forma automática corregir algunos de esos problemas? Este se llama mod_pagespeed. Evidentemente no es un módulo que sea necesario en muchas ocasiones, pero en muchas otras puede resultar francamente sorprendente!! podemos ahorrarnos varios segundos en cargar una web simplemente por especificar 3 cosas en la configuración del módulo. Lo sorprendente del caso es que el módulo funciona francamente bien.

Por ejemplo, hablemos de las imágenes. Una simple imagen jpg sin optimizar a una imagen jpg o png optimizada de tamaño medio puede tener un ahorro de la mitad de bytes. en la web, todo contenido gráfico suele ser imagen, luego es muy importante tener estas cuestiones presentes. Así por ejemplo si tampoco vamos a usar la resolución de la imagen original, lo ideal es redimensionarla al tamaño que vayamos a usar en la web. Son prácticas que como digo a veces por dejadez o simplemente por desconocimiento no hacemos, lo que se traduce en un tamaño muy superior de carga.

Como he dicho lo que hace este módulo de Apache es realizar muchas de las sugerencias que nos brinda PageSpeed al vuelo. Algunas de las maravillas que hace:

  • Extender el caché (el tiempo de vida de los elementos de la web), de forma que el contenido estático solo se actualice cada mucho tiempo, por supuesto si se detecta modificación en el contenido se refresca
  • Conversión y redimensionado automático de las imágenes. Ojo! evidentemente todo esto se hace al vuelo, no se modifican los archivos de origen, solo como Apache los sirve a los usuarios.
  • Eliminación de los retornos de carro y espacios en blanco de nuestro código HTML (generado por PHP o HTML puro) que pueda ser eliminado, con lo que no solo se sanea el código sino que el tamaño disminuye.
  • Minificación/Compactación de JS y CSS, con lo que el tamaño disminuye.
  • Unificación de CSS en un solo arcivo, con lo que se ahorran peticiones al servidor
  • CSS y JS directamente en el código HTML si son trozos pequeños, con lo que así se evita realizar al servidor una petición extra por dichos archivos externos
  • Eliminación de los comentarios en el código
  • Control sobre cualquiera de los parámetros necesario para las tareas indicada: Umbrales, tamaños, páginas o contenido a excluir/incluir…
  • Otros…

Como he dicho lo mejor es que funciona. Una vez configurado el módulo (ya sea desde Apache o con .htaccess) tan solo hay que ver las cabeceras que nos envía el servidor, así como el código fuente final de nuestra web. En mi caso, si cualquiera lo comprueba, verá que el código es completamente compacto, sin comentarios, limpio y saneado. Evidentemente todo esto puede hacerse a mano y de forma permanente en nuestro código, la facilidad aquí es que todo el trabajo lo hace Apache por nosotros. Evidentemente esto no es “gratis”, estamos forzando a Apache que antes de servir nuestro contenido lo prepare, lo cual si nuestro servidor no tiene suficientes recursos se producirán retrasos a la hora de servir el contenido, y al final puede ser peor el remedio que la enfermedad.

Como todo, es cuestión de probar un antes y un después. Desde mi experiencia funciona genial, aunque aconsejo siempre realizar ciertas tareas a mano y mantener en lo posible el código limpio sin acudir a otros sistemas. Como retoque final es perfecto. Evidentemente hay muchas otras optimizaciones que pueden hacerse y que el módulo en cuestión no podrá realizar, pero para eso también disponemos de PageSpeed como extensión de Firebug, que continuará siendo herramineta fundamental.

Una web optimizada de otra que no lo es no es algo a tomar a risa, hablamos de webs que pueden disminuirse a 4 veces menos y tener retrasos infinitamente menores. Todos queremos tener redes más potentes, navegar con más rapidez y fluidez, pero todo eso no es posible si tenemos prácticas que llevan a relentizaciones y al mal uso de los recursos de los servidores. Yo no suelo leer mi blog, no suelo abrirlo, a mí no me afecta que mi web se abra más rapida o más lenta. Pero si me importa que todo lo que aloje sea más eficiente, que mi servidor funcione mejor y que por supuesto la experiencia del usuario sea al menos aceptable. Eso hace que en la medida que pueda ir haciendo el blog más accesible, más cómodo y más rápido, estará bien justificado.

Un ejemplo de mi configuración actual del módulo:

ModPagespeed on
ModPagespeedAllow *
ModPagespeedEnableFilters extend_cache,remove_comments,remove_quotes,collapse_whitespace,combine_css,rewrite_css,rewrite_javascript,rewrite_images,inline_css,inline_javascript

 

Response Headersview source
Date Thu, 10 Feb 2011 18:50:13 GMT
Server Apache
X-Pingback http://blog.theliel.es/xmlrpc.php
Expires Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control no-cache, must-revalidate, max-age=0, no-store
Pragma no-cache
X-Mod-Pagespeed 0.9.14.6-373
Vary Accept-Encoding
Content-Encoding gzip
Connection close
Transfer-Encoding chunked
Content-Type text/html; charset=UTF-8

 

Lo último por ejemplo que añadí fue la traducción automática de Google para navegadores configurados para otros idiomas (de nuevo gracias Google), cosas que cuestan muy poco de trabajo realizarlas y que puede hacer que mi blog sea más accesible para nuestros amigos de habla no hispana. Ojo!! Recordar que mi blog no se monetiza de ningún modo, no solo no es una fuente de ingreso sino de gasto propio. Con esto quiero decir que el interés que pueda o no tener en que mi blog sea más o menos “visible” y accesible a todos es meramente una cuestión de altruismo hacia vosotros. Pero creo firmemente que muchos os los merecéis, grandes personas hay detrás de mis lectores.

Un saludo a todos,

Theliel.

Android: Algo de Ingeniería inversa para parchear una aplicación, firmarla y volver a colocarla

Share on Google+Share on FacebookTweet about this on Twitter

Como en alguna ocasión he dicho, prácticamente todos los países del mundo es completamente legal la ingeniería inversa de un programa. ¿En que consiste? Bueno, los programadores escriben su código, este luego se compila y enlaza y esto origina el programa resultante, en conjunto por supuesto del resto de los recursos que use. El resultado es un archivo o una serie de archivos que la plataforma para el cual fue compilado pueda ejecutarlo. La ingeniería inversa es simplemente intentar darle la vuelta a este esquema, que a partir de un programa compilado se pueda obtener un código que manipular, es decir, decompilar.

Cuando se habla de parquear todos ya piensan en piratear o saltarse medidas de seguridad pero esto no es para nada una norma. Es más, dentro de Android se usa más estos procesos (al menos parte de ellos) para modificar el aspecto visual de las aplicaciones, los iconos de estas, los colores, música, textos… lo que podríamos llamar los “recursos” de esta. Para hacer este tipo de cosas es necesario poder acceder a los recursos de la aplicación, editarlos y dejarlo todo tal y como estaba… o al menos dejarlo de forma que podamos usarlo después. Pero las dotes de Photoshop prefiero dejarlas a manos de buenos amigos que son realmente unos genios en el diseño gráfico (envidia sana desde luego), y yo prefiero encargarme de los bajos fondos. Por cierto, un saludo para ellos desde aquí, tanto amigos como desconocidos. En este caso por tanto no será cambiar una skin o cambiar el aspecto de una aplicación, sino que sí… en este caso si vamos a ver como saltarnos una restricción que nos imponen.

El material que vamos a usar será el siguiente:

  • Windows 7 (Se puede usa otro OS)
  • El SDK de Android instalado, conjuntamente con el JDK (SDK) de Java
  • Un editor Hexadecimal
  • Un dispositivo Android con acceso a la carpeta /System, ya sea porque está rooteado o por medio de un recovery y usar ADB pull
  • La aplicación APKtool para decompilar/compilar (parte 1, parte 2)

Bien, dado que hablamos de Android hay que conocer un poco cual es el modelo de programación que existe, y a la par que es potente es simple. Ya he dicho que Android usa un sistema de programación JAVA (que no significa que el código generado para Android pueda ejecutarse por una VM JAVA). Básicamente, todo el código compilado para Android se empaqueta en un archivo apk (que no es más que un archivo zip) que contiene por un lado los recursos de la aplicación (imágenes, sonidos, archivos binarios…), por otro lado lo que podría verse como la interfaz de dicha aplicación, la firma y certificado de la aplicación y por último las librerías y el código principal de la misma, generalmente en formato DEX. DEX es por así decirlo el código compilado puro y duro de Android, la compilación para la máquina virtual Dalvik, digamos por así decirlo que es el “ejecutable” de las aplicaciones. Las firmwares de algunos fabricantes usan un sistema híbrido que permiten a las aplicaciones por así decirlo compartir código y otras cuestiones y se las conoce como ODEX. En la práctica lo que supone es que cada aplicación apk posee externa a ella otro archivo que la acompaña en formato ODEX, que contendrá tanto el propio código que contenía el archivo DEX como el código necesario para enlazar a esta el código que no se encuentra ni en el apk ni en el propio archivo ODEX, por ejemplo código compartido por muchas aplicaciones y que se reutiliza (lo que serían algo así como librerías dinámicas).

Es importante conocer si estamos ante el escenario DEX o el escenario ODEX, puesto que es diferente. Si estamos ante una aplicación DEX, tan solo tendríamos que realizar una decompilación, modificación, compilación firma y alineamiento. Pero en el caso de una aplicación ODEX antes de decompilar tendríamos que asegurarnos que podemos suministrar al decompilador la ubicación de esas “librerías externas” que requiere dicha aplicación, para que así al modificarlo y volver a compilarlo tengamos como resultado una sola aplicación DEX completamente independiente de otras librerías (por eso es necesario tener las librerías de “apoyo” de esta aplicación, código que será incluido en el propio DEX cuando compilemos de nuevo, y así poder prescindir del archivo ODEX e incluir el archivo DEX dentro de la aplicació). Al final de la conversión básicamente lo que tendremos será una aplicación DEX.

Vale, ya sabemos como se estructura una aplicación, y parece evidente los procesos de decompilar y volver a compilar (luego vemos como). Pero hay dos procesos que hay que realizar de igual forma, el firmado y el alineamiento. El firmado es obligatorio el alineamiento opcional (aunque recomendable).Cada uno será explicado a la par que vamos a usarlos. Empecemos, para no aburrir, con lo que tenemos entre manos.

El mini proyecto a realizar será parchear la aplicación gratuita del Market “SSHDroid”. Esta aplicación no es más que un servidor SSH para nuestro dispositivo, para poder tener acceso por SSH (Putty) o SCP (WinSCP) para poder copiar, borrar, mover… archivos de forma fácil. Es compatible (no de obligado uso) con teléfonos rooteados, lo que permite entonces un acceso total al sistema por los medios mencionados. Pues bien, esta aplicación se encuentra en dos versiones, la versión gratuita con publicidad y la versión de pago sin ella. Pues bien, iba a instalar la aplicación en el Market cuando leo en la descripción que la aplicación automáticamente no se arrancará si detecta que se ha usado algún sistema para bloquear la publicidad. Aquello la verdad es que me mosqueó, no porque me parezca bien o mal el uso de la publicidad, sino porque de igual forma ninguna aplicación tiene que decirme que tengo o no tengo que hacer. Así que después de que efectivamente comprobase que la aplicación se cerraba nada más abrirla me puse manos a la obra.

 

Al ser una aplicación del Store, es DEX, con lo cual es mucho más sencillo todo. Pero bueno, lo primero es evidentemente extraer la aplicación del dispositivo. Si este está rooteado, tan solo hay que acceder a la carpeta /data/app/ y copiar desde ahí el archivo “berserker.android.apps.sshdroid-1.apk” a la SD y de la SD al PC. O hacerlo si se prefiere por SSH o por ADB. El como extraerlo es indiferente, y pegarla en cualquier sitio que podamos manejarla de forma simple. Yo por comodidad tengo todas las utilidades que voy a usar en el Path de Windows, con lo que puedo invocarlas desde cualquier ubicación, lo que me permite no tener que estar usando las rutas completas mientras trabajo de forma sencilla desde mi directorio de trabajo.

Lo primero es suponer que sistema usa la aplicación para cerrarse, lo cual no es que sea muy complicado adivinarlo. Primero porque el sistema de bloquear la publicidad que uso es puramente un archivo Hosts, lo cual ya me dice que realiza la aplicación para detectarlo. Segundo porque esta aplicación y posiblemente muchas otras usan la plataforma de anuncios admob, la cual ya conozco bien por iPhone OS, y no es la primera ni será la última que parchee  (aunque el sistema para iPhone OS difiere al de Android). Básicamente la aplicación verifica si en el archivo hosts existe alguna entrada “admob”. Si existe la aplicación se cierra. Pues bien. hay una y mil manera para sortear esto, desde la más típica que consiste en continuar la ejecución exista lo que exista en el archivo hosts (sería cambiar básicamente un True por un false o un 1 por un cero) hasta la que voy a usar en esta ocasión, que se basa simplemente en engañar a la aplicación Básicamente con este sistema la aplicación si realiza una comprobación… pero no verificará el archivo /etc/hosts, sino un archivo que no existe, por ejemplo /etc/hostt (cambiando la s última por una t)

Si la suposición es correcta, en algún lugar del código de la aplicación quedará tipificado perfectamente el archivo “/etc/hosts”. Este sistema tiene la ventaja en que localizar el punto exacto es simple, solo tengo que buscar en el código por “/etc/hosts”. Claro que si el código está compilado, dicha cadena de texto no tiene porqué siquiera aparecer. Lo  interesante de este sistema es que tanto en iPhone OS como en Android esta cadena es visible sin necesidad siquiera de decompilar!! En el caso de iPhone es tan simple como editar hexadecimalmente el binario de la aplicación, buscar dicha cadena, modificarla y revalidad la firma. Además, dado que tan solo sustituyo un carácter por otro no corro el riesgo de tener que aumentar o disminuir el tamaño del archivo. Otra ventaja es que ni iPhone OS ni Android poseen sistema de verificación de hash dentro de los propios binarios, lo cual significa que puedo sin temor alguno cambiar una ‘s’ por una ‘t’ y quedarme tan pancho. Eso sí!! al realizar esto la firma en cualquiera de los dos casos se destruye!! No poseen verificación dentro del propio archivo (lo cual sería un “problema” porque habría que reconstruir el hash afectado) pero os recuerdo que todas las aplicaciones tienen que tener una firma válida, y como vimos en el artículo de firma digital cuando se modifica algo que esté bajo una firma digital, esta se destruye y se invalida, lo cual nos obliga a realizar una nueva firma. En Android podemos hacerlo porque Android nos permite firmar nosotros mismos lo que queramos, con iPhone OS podemso hacerlo porque el JB valida también las firmas que realizamos nosotros, no solo las de Apple.

Volviendo al asunto en cuestión, tendríamos dos opciones. La opción rápida sería descomprimir el contenido del apk, eliminar la firma anterior eliminando la carpeta “META-INF”, editar hexadecimalmente el archivo “classes.dex”, buscar la cadena citada y modificarla, guardar el archivo y volver a empaquetarlo en el apk (comprimirlo). Pero esto es posible por el truco explicado de la cadena de texto, que evidentemente es un caso excepcional y generalmente no puede hacerse así. Así que vamos a detallar el proceso ligeramente más largo (tampoco tiene mayor complejidad) q pasa por decompilar antes la aplicación.

Una vez tengamos la aplicación a mano, usaremos APKTool para decompilar toda la aplicación. APKTool decompilará el código para Dalvik y nos lo mostrará en digamos lo que podría ser el ensamblador de este (evidentemente no nos devuelve el código fuente .java):

E:\Android\Apps>apktool d berserker.android.apps.sshdroid-1.apk carpeta-decompilada
I: Baksmaling…
I: Loading resource table…
I: Decoding resources…
I: Loading resource table from file: C:\Users\Theliel\apktool\framework\1.apk
I: Copying assets and libs…

Como sabemos que tenemos que buscar exactamente, ni siquiera vamos a perder el tiempo cotilleando cada archivo decompilado. Para ello tenemos al buen amigo “grep”:

#grep -r hosts ./carpeta-decompilada

Lo cual nos devuelve casi de forma automática que el archivo implicado es “./carpeta-decompilada/smali/berserker/android/corelib/e.smali”. Por tanto podemos automáticamente ir a dicha ruta, abrir el archivo con un editor de texto cualquiera, buscar “hosts” y encontraremos rápidamente lo que buscábamos, la cadena “/etc/hosts”. Tan solo tendríamos que modificarla a “/etc/hostt” por ejemplo, y guardar el archivo. A partir de aquí es muy simple, ya que la misma aplicación apktool va a hacer todo el trabajo por nosotros:

E:\Android\Apps>apktool b carpeta-decompilada apk_sinfirmar_sinalineal.apk
I: Checking whether sources has changed…
I: Checking whether resources has changed…
I: Building apk file…

Llegado a este momento tendremos la aplicación correctamente compilada en un archivo apk completamente funcional, el problema es que antes de que podamos usarlo tendremos que firmarlo previamente y opcionalmente firmarlo.

Si recordamos, el iPhone OS tan solo puede ejecutar aplicaciones o contenido que ha sido firmado expresamente por Apple y por nadie más. Esto evidentemente impedía que cualquier usuario pudiese ejecutar alguna aplicación casera si así lo desease, y de ahí (entre otras muchas razones) el motivo por el cual se realiza el JB al iPhone OS. Pero Google no es Apple, afortunadamente. Google sí permite la ejecución de cualquier aplicación aunque no haya sido firmada por ellos. Es más, la única firma que se verifica es la del autor de la aplicación, la cual si es obligatoria claro. ¿Por qué? Bueno, básicamente es la garantía de que dicha aplicación no ha sido alterada por ningún intermediario, a la vez que la legitimiza. Pero cualquiera puede crear una aplicación para Android, compilarlar, firmarla e instalarla en su dispositivo!! y para ello no hace falta absolutamente nada, ni que el dispositivo esté rooteado ni nada.

Para firmarlo usaremos las herramientas estándares de JAVA: keytool para la generación del almacén de claves y nuestras claves y jarsigner para firmar la aplicación. Vamos a suponer que el usuario no tiene aun claves para firmar la aplicación:

E:\Android\Apps>keytool -genkey -v -keystore almacen-android -alias Theliel -keyalg RSA -keysize 2048 -validity 3650

Dicho comando nos creará en la carpeta actual un almacen de claves llamado almacen-android, el alias de dicha clave en dicho almacen, el tipo de key (RSA-2048) y la validad de la clave (10 años). Tendremos que introducir una serie de parámetros, como nuestro nombre, contraseña para el almacén y para nuestra clave… etc. El caso es que cuando terminemos tendremos lista el par de claves necesarias. Ya solo queda firmar la aplicación:

E:\Android\Apps>jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore ./almacen-android ./apk_sinfirmar_sinalineal.apk Theliel
Enter Passphrase for keystore:
Enter key password for Theliel:
adding: META-INF/MANIFEST.MF
adding: META-INF/THELIEL.SF
adding: META-INF/THELIEL.RSA
signing: assets/dropbear/dropbear

Una vez terminado el proceso, podemos renombrar dicho archivo a apk_sinalineal.apk, puesto que en ese momento ya estaría firmado.

 

Por otro lado el alineamiento se realiza por una cuestión de mejora de rendimiento. Por diseño, Dalvik es super eficiente a la hora de gestionar el consumo de recursos, intentando en la medida de lo posible usar la mínima RAM posible (entre otras cosas). El alineamiento lo que realiza es asegurarse de que todo el contenido (que no esté comprimido) dentro del APK comience en un offset (un desplazamiento) concreto, particularmente se desea que el comienzo de cada archivo en el APK comience en un bloque de 4 Bytes (32 bits). El alineamiento es indiferente al contenido comprimido dado que antes de poder acceder a este debe de ser extraído del paquete apk, pero el contenido en el apk no comprimido puede ser accedido directamente sin necesidad de extraerse siquiera. Se podría pensar que todo el contenido dentro del apk (que básicamente es un archivo zip… por así decirlo) estará comprimido, pero la mayoría de compresores ignoran ciertos archivos cuando estos son claramente no compresibles (o mínimamente) como por ejemplo imágenes, audio, video… Esto dicho así es complicado de entender, pero es mucho más fácil si se muestra con un ejemplo.

Las dos siguientes imágenes muestran la ubicación interna de la imagen key.png dentro del apk abierto por un editor hexadecimal, el mismo apk, uno antes de alinearse y el otro alineado. Como se puede apreciar, aunque el contenido es exactamente igual, uno parece estar desplazado 6 Bytes hacia la derecha:

APK No Alineado

 

APK Alineado

Una imagen PNG comienza exactamente con los bytes hexadecimales “89 50 4E 47”. Si vemos las imágenes anteriores, en el APK no alineado la imagen comienza en el offset 2E1E6. mientras que el alineado en el offset 2E1EC. Básicamente todo lo que comenté antes, es que para que el APK esté alineado, todo los contenidos que no estén comprimidos dentro del APK (como esta imagen) deben de poseer un offset múltiplo de 4 bytes), es decir, el último valor hexadecimal de su offset global deberá ser 0, 4 8 o C. El primero efectivamente comienza en el offset relativo 6, que no pertenece a un inicio de bloque de 4 Bytes y por tanto no está alineado. Una vez que se alinea el APK, este pasa a estar en un offset relativo C, el cual es el comienzo de un bloque de 4 Bytes y por ende está alineado.

Esta alineación permite al sistema Android acceder directamente a la posición en la que se encuentran dichos datos, minimizando el uso de RAM (de lo contrario, posiblemente haría falta extraer el APK completo, no solo los archivos comprimidos, sino que para acceder a los archivos descomprimidos habría que extraerlos también del APK, mientras que de este modo los elementos no comprimidos pueden ser accedidos directamente desde el APK).

Por algún sitio en la web he leído que la alineación hay que hacerla antes de la firma. No!! La firma va dentro del propio APK, con lo que si se firma después de alinear, la firma destruirá el alineamiento, haciendo la aplicación menos eficiente. No significa que Android no funcione con aplicaciones no alineadas, ojo, significa que usará sensiblemente más RAM. La pregunta que todos se harán en este momento es si realmente las aplicaciones que descargamos del Market o no están correctamente alineadas… o no. Invito a cada cual que investigue, pero de ya le digo que muchas están sin alinear.

¿Como se alinea? Con la aplicación zipalign, especificando el offset relativo que se desea dar a la alineación. En este caso deseamos bloques de 4 Bytes, por tanto el valor a especificar será de 4. Tenemos dos comandos igualmente útiles, uno para alinear y otro para comprobar el alineamiento (como he dicho útil para ver como de despistados son los programadores, y eso que cuando se configura bien el IDE para programar en Android el proceso debería de ser completamente transparente para el programador… curioso como las malas prácticas en la programación se extienden aun cuando es algo simple de realizar y que nos otorga un buen pellizco de RAM extra)_

E:\Android\App>zipalign -v 4  apk_sinalineal.apk apk_alineada.apk
Verifying alignment of apk_sinalineal.apk (4)…
50 META-INF/MANIFEST.MF (OK – compressed)
906 META-INF/THELIEL.SF (OK – compressed)
1819 META-INF/THELIEL.RSA (OK – compressed)

Si quisiésemos simplemente verificar el alineamiento lo realizaríamos con la linea “zipalign -c -v 4 apk_paraverificar.apk. Los archivos comprimidos se mostrarán como OK – Compressed, los archivos alineados como OK y los archivos no alineados como (BAD – X) siendo X el número de desplazamientos necesarios para su alineamiento… es decir, que no se ha alineado la aplicación.

A este paso ya podemos renombrar nuestra aplicación modificada a su nombre de origen por ejemplo: berserker.android.apps.sshdroid-1.apk

Si queremos estar completamente seguro de nuestro éxito, lo mejor será primero desinstalar primero la aplicación que ya tenemos en nuestro dispositivo. Una vez realizado, podemos proceder a instalar nuestra aplicación modificada con ADB: “adb install berserker.android.apps.sshdroid-1.apk”, y ya solo nos quedará verificar si la aplicación se abre o no se abre:

 

Como ya he dicho, ni que decir tiene que esto no es sino un ejemplo de como se podría realizar ingeniería inversa a cualquier aplicación que deseemos. Recordar, que esto es una práctica completamente legal (al menos aquí en España), y que esto nos abre la oportunidad no solo de realizar como hemos visto aqui un pequeño “parche” para poder abrir la aplicación sin tener que renunciar a nuestros anti-publicidad, sino que imaginar que hubiésemos aprovechado para cambiar el color de la interfaz, o el icono de la aplicación, o los textos de esta o… cuestiones que bien conocen los que les gusta el modding,que no el parching. Por ejemplo, mi Market no es verde, es Lavanda

Theliel.

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Creative Commons License
Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.