Archivo de la categoría ‘Android’

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.

 

Vulnerabilidades en 2012: Windows 7/8, OSX, SmartPhones y Navegadores

Share on Google+Share on FacebookTweet about this on Twitter

Este año las felicitaciones navideñas y el próspero año nuevo se quedaron en aguas de borrajas, aunque no por eso quiera decir ni mucho menos que los días de escribir algunas cosillas en el blog terminaron. Así que antes de comenzar, aunque vaya un mes tarde, espero que todos pasásemos unas felices navidades, y que este año sea próspero para todos.

Dicho esto, ya el año pasado hice exactamente lo mismo para con los datos de 2011. Así que este año había que hacer lo mismo para el año 2012 que ya hemos dejado atrás. Los datos de nuevo están extraídos desde Secunia y el NIST

Muchos pueden creer que no es importante estos datos, pero sinceramente al menos para mí, no como aficionado a la materia sino como usuario diario de estos software es de suma importancia, lo suficiente muchas veces como para ver si uso el software correcto, o a la hora de aconsejar a otros sobre que productos decantarse. Es algo que siempre me ha sorprendido enormemente, cualquier persona se escandaliza si ve una pantalla de publicidad con un mensaje extraño, pero nadie se escandaliza cuando le dicen que su dispositivo o su equipo se encuentra en serias deficiencia en cuanto a seguridad, y que cualquier Hacker inteligente podría tomar el control de su dispositivo. Cuando intentas contarle esto a las personas te miran raro, o te dicen eso de: “Total para lo que tengo…”. En cambio, es cuando a esa persona le sucede algo por culpa de ello, es ya siempre tarde, y no son uno ni dos ni tres los casos al año, raro es el mes que no leo en mi correo o por cualquier otro medio alguien que tiene un problema, y no precisamente por que el navegador no deja de reenviarle a webs pornográficas.

Es por todo ello, que el principal problema de seguridad que existe a día de hoy es la ignorancia, el creer que nadie puede estar interesado en nuestros datos (cuando son oro puro para muchos), el creer por pura fe lo que le dicen otros, que posiblemente tienen aun más problemas que él, aunque no lo sepa. La mejor forma de enseñar, no es con miedo, no es con críticas baratas, es simplemente mostrando datos, enseñando que hay, que no hay, y que cada cual sea por tanto quien saque sus propias conclusiones.

 

Bien, el objetivo de este post como el del año pasado, es ver el número de fallos de seguridad (vulnerabilidades) acumulado durante este año pasado 2012 en sistemas operativos de escritorio, de dispositivos portátiles y de navegadores web. Eso no quiere decir que no existan otros problemas de seguridad ni mucho menos, los datos que puedo mostrar son datos PÚBLICOS que cualquiera puede tener acceso, en concreto mis datos recogidos son simplemente los CVE registrados. CVE son los reportes (un identificador) que asigna un organismo internacional a vulnerabilidades/fallos de seguridad. Hay que tener en cuenta ciertas cosas a la hora de interpretar los datos

Primero, un CVE NO IMPLICA de modo alguno que un hacker podría hacerse con el control total de tu dispositivo a través de él, un CVE es un problema potencial de seguridad que puede ser explotado con fines malignos o no, y que por supuesto su peligrosidad varía enormemente en relación con el tipo de fallo descubierto. De este modo, tenemos problemas de seguridad menos peligrosos como los que “simplemente” exponen datos de nuestro sistema o datos sensibles al exterior sin nuestro consentimiento, pasando por fallos de seguridad que permiten el Spoofing, el Cracking, escaladas de privilegios, ataques de denegación de servicio… y por supuesto hasta llegar al peor de los males, como es el acceso al sistema, que son vulnerabilidades que se pueden aprovechar para la ejecución de código remoto (digamos, el santo grial siempre del Hacker)

Segundo, hacer una tabla con el número de fallos de seguridad sin tener en cuenta otros datos sería totalmente demagogo, hay que entender muchas veces como se recogen dichos datos, si puede existir una explicación “decente” a dichos números… de lo contrario entraríamos de nuevo en escribir artículos partidistas en los que el redactor siempre haría que ganasen unos y otros en función de sus intereses. Aquí no se trata de ganar o perder, se trata de exponer datos y explicar lo que puede explicarse con las razones que puedan darse. A partir de ahí, cada cual tendrá que pensar un poco por si mismo y sacar sus conclusiones, no creerse los datos expuestos y fijarse simplemente en una tabla de datos.

Por el segundo punto, voy por ello a recalcar con mucho énfasis la gran importancia de esos “atenuantes” o “detonantes” de este número de vulnerabilidades. De echo en mi humilde opinión, que un producto haya obtenido el mayor número de vulnerabilidades a lo largo del año no implica que sea un producto inseguro per sé, eso hace solo un 50%, el otro 50% reside (de nuevo en mi opinión) en las políticas de actualizaciones/distribuciones de los desarrolladores, y del índice de penetración del mercado que posee cada producto. Las políticas de actualizaciones/distribución es esencial para tener nuestros sistemas dispositivos siempre al día, y la penetración del mercado es esencial para entender que plataformas están mucho más expuestas a todo tipo de ataques, a fin de cuenta nadie quiere encontrar un fallo de seguridad que afecte a un 1% de la población, lo intentan buscar en productos que afecte a un 50%, aunque sea 100 veces más complicado el hacerlo.

Las versiones usadas en cada caso, correspondería con las versiones que dicho producto ha tenido durante estos pasados 365 días. Por ejemplo en el caso de Windows, se han sumado los fallos de seguridad de Windows 7 de TODO el año conjuntamente con los de Windows 8 de TODO el año (desde que se terminó la versión de oro en Agosto. Lo mismo para cada producto. El índice de penetración de mercado se calcula simplemente tomando el porcentaje global de cada producto, y este a su vez se divide en función del índice de penetración que posee dicha versión dentro de dicho producto, si posee más de una versión ese producto en el período a tratar (2012), se suma dicho porcentaje. Es  decir, que si Windows posee por ejemplo un 90% de cuota de mercado y fuésemos a tratar SOLO windows XP, y que este fuese un 50% de todos los Windows instalados, el porcentaje real de Windows XP sería por tanto de un 45%, el 50% de ese 90%. Es simple.

 

Sistemas Operativos: Windows 7/8 VS OSX Lion/Montain Lion

Escritorio

 

Los datos son escalofriantes un año más, tanto en fallos de seguridad como en cuota de mercado.

  • Windows 7 en conjunto con Windows 8 poseen una cuota de mercado aproximado de un 50%, y terminaron el año con solo 50 fallos de seguridad
  • OS X Lion en conjunto con OS X Montain Lion posee una cuota de mercado conjunta aproximado del 5%, y terminaron el año con la friolera de 164

Los datos que tendríamos que obtener serían totalmente inversos, dado que Windows 7/8 posee una cuota de mercado 10 veces superior, el número de fallos de seguridad quizás no tendría que ser proporcionalmente también diez veces superior, pero evidentemente superior. En cambio el panorama no es así. A pesar de que Windows 7/8 están asentados en el 50% de los PCs de escritorio (un 92% aproximadamente todas las versiones de Windows en su conjunto), y a pesar de que OS X tan solo posee una cuota de mercado (sumando todas sus versiones) de un 6-7%, OS X posee una tasa de problemas de seguridad muy superior a Windows, la triplica!! Con el índice tan bajo de cuota de mercado y dicha tasa de problemas, teniendo en cuenta que OS X es igualmente software de código cerrado, deja claro sin lugar a dudas que es un sistema muy vulnerable.

Como ya dije anteriormente, hay que ver también la política de empresa de cada desarrollador de cara a las actualizaciones o el despliegue de su software. Una tasa alta de fallos de seguridad es mala, pero dentro de lo malo puede ser menos malo si se implementan políticas de actualizaciones rápidas, de respuesta inmediata ante cualquier tipo de vulnerabilidad que se descubra. Estos datos son igualmente públicos y se conoce la política de estas dos grandes empresas ante los fallos de seguridad:

  • Microsoft: Publicación estándar mensual de todos los boletines de seguridad, así como actualización de las definiciones de malware y otras actualizaciones (no de seguridad). Dicha publicación se realiza el segundo martes de cada mes. Al margen de este ciclo estándar, a veces también se han lanzado actualizaciones esporádicas en cualquier momento del año cuando se había detectado un problema de seguridad muy grave o para solucionar un fallo existente que ya se estaba usando para causar estragos. Eso quiere decir que en el año 2012 Microsoft lanzó sus actualizaciones en al menos 12 entregas.
  • Apple: No posee un calendario fijo de actualizaciones, suele lanzar sus actualizaciones en forma de macropaquetes, distribuidos a lo largo de todo el año. El problema es que a lo mejor en todo el año tan solo lanza 3-4 de estos. Eso quiere decir que aun cuando aparece un fallo de seguridad grave, el usuario puede necesitar de al menos unos meses para que Apple haga caso. A lo largo de 2012 Apple lanzó 5-6 paquetes de este tipo, y solo intervino en una actualización espontánea no ante la gravedad del fallo de seguridad que les afectaba, sino porque dicho fallo saltó a los medio de prensa. Es una pena, pero Apple tan solo lanza actualizaciones de forma rápida cuando el problema se ha hecho eco en los medio.

De nuevo, otro fracaso por parte de Apple y su OS X, fracasa en fallos de seguridad al año, fracasa en número de fallos de seguridad si tenemos en cuenta la tasa de mercado estrepitosamente, y lo que es peor, la política de actualización de Apple es pésima, lo que hace que los usuarios sean propensos de sufrir problemas de seguridad por exploits y otros medios que llevan circulando por la red a lo mejor durante meses, sin que Apple haga nada.

 

SmartPhones: Android VS iOS VS Windows Phone

 smarphones

 

En este caso no tenemos dos competidores, tenemos 3, y si bien es cierto que Windows Phone aun no tiene una cuota de mercado importante, es previsible que vaya subiendo poco a poco. Pero discutamos estos resultados teniendo en cuenta la penetración en el mercado que tiene cada OS:

  • Windows Phone posee tan solo un 3% aproximadamente de cuota de mercado dentro de los Smartphones, y tan solo se ha conocido un boletín CVE en todo 2012. Este resultado por tanto es totalmente consistente, es decir, con una tasa de mercado que ronda el 3%. al margen de lo seguro o lo inseguro que sea el sistema, es comprensible que el número de fallos sacados a la luz en este año sea mínimo. De nuevo esto no quiere decir que el sistema sea más o menos seguro que el resto, pero al menos sus datos son repito consistentes.
  • Android posee un índice de mercado entorno al 75%, eso quiere decir que más o menos 3 de cada 4 dispositivos Smartphones que se venden es Android. A pesar de ello terminó el año con 8 CVE, un dato bastante bueno para tener un 75% de cuota de mercado, ya que implica que Android es a día de hoy la plataforma más… “jugosa” de cara a los Hackers
  • iOS posee una cuita de mercado entorno al 15%, que no es poco ni mucho menos, pero en su caso terminó el año con la friolera de 94 fallos de seguridad. Que sea mucho o poco no podemos juzgarlo de forma sencilla, pero si simplemente lo comparamos con Android que posee una penetración de mercado 5 veces superior y menos de la décima parte de fallos de seguridad…

Estos datos son aun más inexplicables si tenemos en cuenta otro factor que aun no se ha comentado, que es que software que vamos a ver aquí, es de código libre. Cuando un software es de código libre cabe esperar que en igualdad de condiciones registre siempre un mayor de fallos de seguridad publicados. Esto es muy sencillo de entender, si es de código abierto CUALQUIERA puede acceder al código fuente y buscar y encontrar vulnerabilidades de forma mucho mucho mucho más sencilla. Esto lo veremos con claridad un pelín más adelante con los navegadores Web.

Bien, Android es de código abierto, y además posee una cuota de mercado de un 75%, esto significa que los resultados habrían sido consistentes y relativamente lógicos si fuese Android y no iOS quien tuviese esos 94 fallos de seguridad. Es más, si así hubiese sido, durante un mes estaríamos escuchando en todos los medios lo vulnerable que es Android. Lejos de eso, es iOS con tan solo un 15% (mucho si tenemos en cuenta el total, poco si lo comparamos con Android), a pesar de código totalmente cerrado, alcanza la friolera de 96.

En cuanto a políticas de actualizaciones y distribuciones:

  • Microsoft al igual que hace con su OS de escritorio, suele ser relativamente rápido a la hora de tapar cualquier problema de seguridad. No podemos saber no obstante su política exacta ante Windows Phone, puesto como ya se ha dicho con tan solo un fallo de seguridad en 2012 no se puede cuantificar demasiado bien su tiempo de respuesta.
  • Google por su parte es conocido en todos los ámbitos por dar siempre una respuesta casi inmediata ante cualquier fallo de seguridad, este es inmediatamente corregido en los repositorios AOSP para que cualquiera pueda aplicar el fix que sea necesario. Aquí hay que indicar que existe un retraso significativo no a la hora de actuar contra el problema, sino en que los fabricantes lo adepten. No es un fallo de Google de echo, es de las políticas de cada uno de los fabricantes. Lo general es que ante un fallo de seguridad grave, los fabricantes puedan tardar en lanzar actualizaciones a sus dispositivos hasta dos y tres meses.
  • Apple aplica la misma filosofía que con OSX, hasta que el fallo no trasciende a los medios de comunicación le da igual la gravedad del problema, y por desgracias tenemos muchos ejemplos de ello. De echo, precisamente aparece en los medios, porque es algo fragante que está totalmente extendido. Así aun recordamos todos el fallo de seguridad que permitía tomar el control de cualquier iPhone simplemente a través de unos SMS que se enviaban, o al menos 4-5 fallos de seguridad críticos que permitían igualmente apoderarse del control total del dispositivo simplemente haciendo que el usuario accediese a una web concreta. Fueron necesario meses y meses antes de siquiera lanzar una actualización para ello, a lo que a partir de aquí hay que sumar el tiempo que tardaría cada cual en aplicar dicha actualización.

 

Navegadores WEB: Opera 11/12, Internet Explorer 9/10, Firefox 10..17, Safari 5/6. Chrome 17..23

 navegadores

 Veamos en esta ocasión la consistencia de los fallos de seguridad de cada navegador atendiendo a su cuota de mercado, aunque en el caso de los navegadores hay que añadir un factor adicional que posee tanto Firefox como Chrome y que se debe de tener muy en cuenta:

  • Opera registra el menor número de fallos de seguridad, con tan solo 34 boletines CVE si sumamos los fallos de seguridad de todo 2012 a las versiones que estuvieron en funcionamiento en él, pero hay que tener en cuenta que posee una tasa de mercado muy pequeña, entorno al 3%. Es necesario por tanto ver el resto de navegadores para ver si sus datos son consistentes, y lo cierto es que más o menos si lo son. No es una tasa demasiado elevada, era de esperar que al tener tan poca tasa de mercado sería el que menor número de boletines acapararía. Aun así, desde mi punto de vista, para tener tan solo 3% de cuota me parece un valor alto
  • Internet Explorer 9 y 10 suman un total de 39 problemas de seguridad, algo más que Opera, pero con una gran diferencia, y es que IE tiene una penetración que ronda el 39%, eso multiplica por 10 la expansión de IE frente a Opera, y aun así tan solo llega a 39. Este dato es muy sorprendente.
  • Firefox si lo comparamos con los datos del año pasado a sufrido un incremento exponencial (que ya veremos debido a que), terminado 2012 con 216, muy superior a los 39 de IE sin duda alguna, y posee un share entorno al 25%, nada despreciable tampoco.
  • Safari alcanza los 274, pero en este caso el share de este es igualmente mínimo, rondaría el 6%.
  • Chrome por su parte comparte todos los pros y contra de Firefox, solo que en este caso llega a los 277 boletines, con un mercado que ronda el 36%, eso significa la segunda posición en cuanto a su uso.

Antes de analizar esto, hay que tener en cuenta que tanto Chrome como Firefox son de código abierto, y que ambos ademeás poseen ciclos de productos muy cortos, solo hay que ver que en todo 2012 el resto de los navegadores difícilmente cambiaron en uno la versión de sus productos, mientras que Firefox vivió 2012 con 8 versiones diferentes, y Chrome lo hizo con 7. Esto es a tomar muy en cuenta, ciclos cortos permiten un progreso más rápido de los navegadores, pero también implica que aparecerán más problemas de seguridad, aunque (y esto es importante) solo afecten a versiones concretas de ellos. Es decir, Chrome y Firefox poseen una tasa mucho más alta fundamentalmente a que participan con muchas más versiones, pero no quiere decir que todos esos fallos de seguridad afectasen a todas las versiones, de echo si dividimos el número CVE entre el número de versiones lanzadas, vemos que el resultado es mucho más cercano al que logra obtener IE.

Dicho esto, de todos modos el ganador indiscutible es Internet Explorer, aunque es cierto que es de código cerrado, con una tasa tan grande de mercado y con tan solo 39 fallos de seguridad en todo 2012, nadie puede acercarse. Impresionante trabajo por marte de Microsoft. El segundo lugar sería más complicado, Opera tiene un resultado muy bueno, pero un 3% es muy poco significativo, por tanto el segundo lugar sería quizás para Firefox, sí, son 216 CVE, pero si tenemos en cuenta que posee un 25% de mercado, ciclos cortos y de código libre, hay que entender el gran trabajo que hay de fondo. Del mismo modo y rozando los talones estaría Chrome con algunas más, aunque también con un porcentaje de mercado algo superior. Después si situaría a Opera, y por último tendríamos Safari, que aun cuando tendría que partir de una postura ventajosa como Internet Explorer, fracasa estrepitosamente en todo. Con tan solo un 6% de mercado, aun asiendo de código cerrado y con ciclos largos, obtiene el el segundo peor número, muy cercano al de Chrome, con 274. A diferencia de Chrome, Safari no tiene excusa alguna de tal número de fallos de seguridad, y tampoco puede culparse a las diferentes plataformas ya que desde Safari 6, este tan solo se usa en OS X.

Las políticas de actualizaciones y distribución en algunos casos son las mismas ya comentadas:

  • Opera actúa ciertamente con bastante rapidez ante cualquier problema de seguridad, no tiene una actuación inmediata, pero se puede tener la cierta seguridad de estar protegido por fallos de seguridad que salen día a día. Si es un fallo crítico, posiblemente tendrían una actualización lista en dos o tres días.
  • Microsoft aplica a Internet Explorer su misma política que a Windows, usa los boletines de seguridad mensuales de Windows para actualizar Internet Explorer, y solo cuando un problema grave de seguridad es detectado se plantea el lanzamiento de una actualización fuera de su ciclo normal. Eso nos dice que con seguridad Internet Explorer suele estar actualizado y protegido con un intervalo de un mes, y si es urgente de nuevo casi de forma inmediata, unos días como mucho
  • Mozilla y Google al usar un navegador de código abierto y ciclos cortos, la actuación ante problemas de seguridad es prácticamente inmediata, en cuanto es conocida o comunicada, sin importar demasiado el grado de importancia que tenga problema encontrado es corregido con la mayor presteza en los repositorios oficiales, y en cuanto son probados se lazan actualizaciones inmediatas al propio navegador, que se actualiza el sólo sin intervención siquiera muchas veces del propio usuario. Sin duda alguna son las dos compañías que reaccionan más rápido ante cualquier amenaza. Bravo por ambos.
  • Apple por su parte usa también la misma filosofía que en OS X o en iOS, actualizaciones esporádicas en las que aprovechan para parchear todo lo que tengan pendiente, no importa si el fallo de seguridad lleva circulando dos días o un mes, si no ha trascendido a la prensa no cambian su calendario. Eso hace evidentemente que el navegador del usuario se encuentre constantemente en peligro, y más si vemos el gran numero de fallos que acumula, con 274 fallos de seguridad tenemos una media de 0.7 fallos diarios, lo que quiere decir que el usuario de Safari está sencillamente “jodido”, usar Safari implica estar expuesto a cualquier Hacker básicamente.

Pronto será el Pwn2Own como todos los años, en el que los navegadores se expondrán en un concurso de Hackers a ser destrozados. Aquí es donde vemos realmente no lo bueno o malo que sea el navegador en aguantar (que también), sino las políticas de empresa de cada cual. Cuando veos que dos o tres días antes del Pwn2Own Apple lanza apresuradamente un macro paquete de actualizaciones, algo te dice que es mejor huir de dicho navegador. Google hace lo mismo no nos engañemos, aprovechará días antes para parchear al máximo Chrome e intentar pasar indemne la prueba del Pwn2Own, pero en su defensa tenemos que decir que es un patrocinador oficial del Pwn2Own y que hace precisamente estos días una competición similar, dicho de otro modo y pese a intentar aprovecharse el día antes para actualizar su navegador, posiblemente es la empresa que se toma más en serio la seguridad de los 5, o al menos lo demuestra. Microsoft el año pasado ya optó por jugar limpio y no lanzar ninguna actualización a destiempo, es decir, fue el único que jugó limpio…. veremos este año que sucede.

Es por eso que aunque Firefox o Chrome posean las tasas mas altas de problemas de seguridad (quitando Safari), es casi imposible que ninguno de esos fallos de seguridad pueda afectar al navegador, a menos que alguno de ellos sea lo que se conoce como un Zero Day Exploit, es decir, un exploit que se aproveche de un fallo de seguridad que aun no ha sido comunicado o hecho público. Es la única forma, puesto de lo contrario si el usuario mantiene su navegador actualizado (que generalmente se automantienen ellos), estará siempre protegido. Internet Explorer es igualmente complicado atacarle con un CVE ya publicado, aunque es posible, si un exploit aparece para aprovechar un CVE, con suerte es posible usarse durante unos días. Ese es el problema de Sarafi, que es posible usar contra él exploits que afectan a CVE publicados incluso meses antes, sin que el usuario pueda hacer nada al respecto porque no hay ninguna actualización que le protega ante ellos, y hablamos de exploits y fallos de seguridad, aquí no sirven de nada los corta fuegos o cualquier otro tipo de medidas.

 

Tener un número alto de fallos de seguridad es malo, este número es alto o bajo solo si lo comparamos con productos similares y vemos que número podría ser más o menos aceptable o lógico, es cuando vemos la capacidad realmente de los programadores y lo serio que pueden tomarse la seguridad. Pero eso no hace ni mucho menos que nuestros dispositivos sean más o menos seguros, es importante, pero no es algo que lo decida por completo, como hemos dicho con Google o Mozilla, es incluso más importante el tener una actuación inmediata ante cualquier problema, es la única forma de tener la certeza, o al menos la garantía más alta, de que estamos seguros. Vale, no hay nada seguro, y un exploit Zero Day hará trizas cualquier sistema por protegido que esté, pero hay que poder encontrarlo y usarlo. Y sí, los hay, siempre los habrá.

Un saludo.

Niantic Project – Ingress

Share on Google+Share on FacebookTweet about this on Twitter

El lector habitual, sabe que no suelo hacer publicidad ni demagogia barata a nadie, y que rara vez publico un producto, sino que generalmente son ideas. No puedo definir Niantic como producto… tampoco como idea.  Definir de forma sencilla que es el “Proyecto Niantic” sería complicado, e incluso algunos me criticarían si dijese que el “Proyecto Niantic” fue sacado de los laboratorios de Google (como el propio Brandon Badger dijo), y más aun si especulase siquiera que se trata de un “juego”. Sin embargo es todo eso y algo más. Pero lo cierto es que de algún modo sería conveniente definirlo.

Un pequeño resumen para quien ande perdido. Hace más o menos un mes (El 1 de Noviembre) apareció una web un tanto enigmática llamada “Niantic Project“. Al principio nada se supo ni se tenía siquiera idea de lo que se estaba cociendo, la web tan solo mostraba lo que parecía ser un tablón de corcho típico donde se colocan papeles y otros, y un tal P.A.C hacía una pequeña introducción con este vídeo:

  

 

Aunque el “Proyecto Niantic” lleva casi un mes puesto en marcha de forma pública, no ha sido sino hace unos 10-15 días cuando ha empezado a atraer las miradas de medio mundo por enlazar su historia con Ingress, aunque de eso hablaremos más adelante. Como digo, todo empezó con ese 1 de noviembre en el que se veía un tablón casi desnudo en la web citada. Cada día transcurrido, la web se actualiza añadiendo al tablón un día más, en el que se cuelgan nuevos enigmas en forma de vídeos, acertijos, pistas, informes… desgranando muy poco a poco y solo para los que son capaces de entender los galimatías no solo que es el Proyecto Niantic, sino toda una trama de conspiraciones, pseudociencia, experimentos… que hay detrás de ello.

Así pues, el Proyecto Niantic nace a primera vista como una web que intenta seducirnos para que descubramos los enigmas que van publicando con un trasfondo sencillamente impresionante. Los Enigmas y la trama son lo suficientemente complicadas que no se ha creado para trabajar individualmente, sino que a día de hoy Google+, IRC, Facebook… en todos los medios es fácil encontrar respuesta para la mayoría de los secretos que se han ido desvelando por ahora, y por supuesto nadie quita que aun queden muchos por descubrir, sin contar que los días siguen pasando… y el tablón continúa publicando puntualmente actualizaciones. Cuando hablo de enigmas y de conocer todo el trasfondo y la historia, solo diré que en los días que llevamos (29 ya) hemos tenido que lidiar con Morse, Braille, Ruso, conocimiento básico de HTML, diferentes cifrados desde simples a muy complejos, análisis de imágenes…

La grandeza del proyecto no obstante, desde mi punto de vista, no radica ya siquiera en que pueda o no tener los laboratorios del proyecto Niantic en Google, sino que TODO el material que encontramos podría pasar por real. Hablamos de decenas de imágenes, transcripciones de audio, grabaciones de voz, vídeos supuestamente amateurs sobre Niantic Project, supuestos documentos secretos… Y eso sin contar con la gran comunidad que se ha formado alrededor de ello en la que encontramos ya cientos y miles de imágenes artísticas de todo tipo, conspiraciones de todo tipo… y por supuesto el gran interés de todos: Poder entrar en “esa otra parte” llamada Ingress

 

 

 

Siento el secretismo con todo ello, pero hay que entender que aquel lector que no haya oído hablar absolutamente de todo esto, quizás podría interesarle realmente como a tantos otros, y desgranar más información sería sencillamente una equivocación y se arrepentirían de haber leído este pequeño artículo. Pero volviendo al tema… ¿que es Ingress?

Oficialmente, Ingress es una aplicación para Android que encontramos en Play Store que cualquier usuario de Android puede instalar. Pero antes de correr a hacerlo hay que entender que tan solo se puede acceder a ella (una vez instalada) por medio de una invitación. A esto se le llama beta privada… aunque todo aquel que siga el Proyecto Niantic podría encontrar que tal vez no es solo una cuestión de ser una beta privada.

Ingress se perfila en principio como una aplicación de realidad aumentada en la que interaccionamos en el mundo real gracias a nuestros dispositivos, que lo único que requieren es tener GPS, tener deshabilitado las ubicaciones falsas y una conexión a datos. Por supuesto son muchos que ya aseguran que es el primer juego de realidad aumentada con calado mundial, otros en cambio más en la línea de Niantic Project preferimos referirnos a Ingress como una herramienta. Su conexión con Niantic Project es directa, aunque eso tan solo podrán conocerlo bien quien siga dicho proyecto. Eso no quiere decir que cualquiera que quiera en el presente o futuro probar Ingress deba de pasar por entender siquiera que es Niantic, nada más lejos!! Puede/podrá hacer uso de una de las aplicaciones más adictivas y mejor pensadas de los últimos años (sin duda alguna), con la única excepción que habrá veces que no comprenda el trasfondo de todo ello o el significado de algunos documentos.

¿Que podemos decir de Ingress? Bueno esto es más fácil para que todos lo entiendan. Nada más ingresar el código, recibiremos en la misma aplicación unos mensajes que empezarán a explicarnos algunas cosas, así como ofrecernos un pequeño tutorial para conocer las funciones principales de la aplicación y de como usarla. En cualquier caso se nos solicitará un Nick por el cual seremos conocidos dentro de Ingress, y tendremos que escoger a que facción pertenecer. Iba a cometer el error de decir eso de “Los buenos y los malos”, puesto que en realidad nadie es bueno y nadie es malo, es más una concepción de como cada cual ve las cosas. Lo que está claro es que o te unes a la causa de “The Enlightenment” (Los iluminados) o “The Resistence” (La resistencia). Escogido esto, para dicha persona, empezara a formar parte de lo que posiblemente sea la primera “Guerra” virtual a nivel mundial, solo que aquí no disparamos, no matamos, la guerra que se desata es (siempre dentro de Niantic e Ingress) por el “adoctrinamiento” del resto de la humanidad. Para ello será necesario la captura de Portales situados en lugares de “poder” o “únicos”, establecer defensas, enlazar unos con otros, interactuar dentro de la misma facción unos con otros si es necesario, establecer estrategias, avanzar…

 

No es tan complejo como cabría de esperar, sino la facilidad con la que cualquier persona del mundo puede adentrarse en este mundo y aportar su grano de arena a la causa, ya sea la de los Iluminados o la de la Resistencia. ¿Tienes un portal cerca? Si no lo sabes es porque aun no tienese una invitación, y para eso tan solo la suerte puede ayudarte ahora mismo, lo mejor es acudir a las vías ordinarias en Ingress y Niantic Project para solicitar tu invitación, y mientras que llega tu oportunidad o no, intenta desentrañar los secretos del Proyecto Niantic, para el cual no hace falta acceder a Ingress. ¿Y que pasa si no tienes uno cerca? No desistas, busca, colabora buscando y enviando nuevos sitios, es posible que en cualquier momento encuentres no uno… sino decenas de ellos.

Y si lo tienes… espero que hayas tomado ya el control sobre él y esté bien protegido, o de lo contrario no durará mucho en tu facción.

Un saludo.

 

 

 

Nexus 7 Vs Ipad Mini | Nexus 10 Vs iPad 4

Share on Google+Share on FacebookTweet about this on Twitter

La guerra está servida… aunque a estas alturas y con la agresividad con la que Google quiere zanjar el asunto, todo parece que está más que sentenciada.

Google tenía planeado lanzar un evento este 29 de Noviembre en Nueva York, pero por causa del huracán Sandy fue cancelado. No obstante, eso no impidió que lanzase sus novedades: Nexus 4, Nexus 7 (mejorado) y Nexus 10. Estos lanzamientos por otro lado coinciden casi en fecha con el propio iPad mini de Apple, y no demasiado del iPad 4, con lo que me ha parecido buena idea ponerlos todos juntos en una tabla a ver que pasa. Veamos una pequeña comparación cualificable, en la que pediría especial atención al precio, que es cuanto menos interesante:

 

 

-Fecha de fabricación:

En este caso, 3 de los 4 productos están al salir del horno, de echo ahora mismo no se han servido aun ningún Nexus 10, iPad Mini o iPad 4. En el caso del Nexus 7 hay que indicar que ya lleva unos meses en el mercado, y por consiguiente al ritmo que avanza este tipo de tecnología debería de quedar atrás que el iPad Mini (con quien compite).

 

-Precio

Creo que uno de los puntos más importantes sin duda. Puede que para los ricos despreocupados esto no sea un factor demasiado importante, pero teniendo en cuenta que esos ricos despreocupados tan solo son una minoría, hay que decir que para la gran mayoría el precio es un punto a tomar muy en cuenta. Tampoco es cierto eso que piensan muchos snobs “Cuanto más caro mejor”, es la gran mentira repetida a lo largo de los años, pero es simple… si es caro y ellos son los únicos que pueden pagar eso es que es un producto tan solo para destacados. Es triste esta forma de pensar pero lo cierto es que por desgracia más de las personas que pensamos piensan así. Sea como sea, veamos que nos dice el precio.

Dentro de la lucha entre Nexus 7 e iPad Mini el precio es descaradamente desproporcionado. En sus modelos más básicos la diferencia es de 130€ a favor de Nexus 7, pero si nos vamos a los modelos de 32GB con datos, la diferencia se dispara a 260€. Es decir, que entre los dos dispositivos de 32GB de WIFI+Datos, el Nexus 7 cuesta 260€ menos!! No es solo una barbaridad, es que si miramos los números, por 559€ que desembolsaríamos por un iPad Mini de 32GB con WIFI+datos podríamos sacar un Nexus 10 de 32GB (eso sí sin datos) y aun así nos ahorraríamos 59€ que podríamos invertir en un adaptador 3G USB para conectar a nuestro tablet. Quien quiera verlo de otro modo, el precio del iPad Mini puede casi doblar el precio del Nexus 7.

Dentro de la lucha entre Nexus 10 e iPad 4 el precio no es tan fragante como en el caso anterior, aunque ello no quiere decir que no sea también importante. En el caso del Nexus 10 aun no hay modelo con WIFI+Datos, aunque es de suponer que el precio incrementado será igual que en el caso del Nexus 7 (unos 50€ más). Sea como sea, tanto en el modelo de 16GB como en el de 32GB el Nexus 10 es 100€ más barato. Para quien ande despistado, sí, la diferencia es menor que con el iPad Mini Vs Nexus  7 (130-260), pero hablamos aun así de 100€ de diferencia, un 25% más caro.

Por supuesto, el precio por sí solo no nos dice nada, puesto que si un producto es infinitamente superior a otro tiene que verse reflejado también en el precio. Al igual que no podemos decir que lo caro es siempre mejor, tampoco podemos decir que lo barato es siempre lo mejor. Por eso es necesario el resto del artículo, sino habríamos acabado aquí. Hay que ver que compramos por todo ese dinero.

 

 -Procesador

Apple a optado en el iPad Mini por usar el mismo procesador que el iPad 2, con lo que Apple puede reutilizar sus procesadores fabricados y no usados para sus iPad 2. Esto es una solución efectiva y económica, el problema es que es un procesador bastante viejo en los tiempos que corren, y no es ni de lejos comparable al poder del procesador del Nexus 7 con la arquitectura Tegra 3 de 4 núcleos. Esto no hace del Nexus 7 más eficiente y más rápido solo en su CPU, sino que también en su GPU (apartado gráfico). Ambas arquitecturas están basadas en Cortex A9, el iPad mini un procesador de doble núcleo a 900MHz-1GHZ mientras que el Nexus 7 lo hace con 4 núcleos a 1.3GHz cada uno, y sobre el apartado gráfico poco que decir, más de lo mismo.

Aquí no termina todo, y es que mientras que Apple ha dotado al iPad Mini con 512MB de RAM, el Nexus 7 anda sobre 1024MB (1GB) de RAM, es decir el doble. Como ya he dicho en otras comparativas, la RAM es solo necesaria cuando se usa, pero en cualquier caso 512MB me parece algo pobre en los días de hoy. Se ve que con esta reutilización de componentes Apple quiere que le salga barato la fabricación del iPad Mini, y con los precios tan altos se garantiza un beneficio más grueso que nunca

En el otro frente, vemos como Apple con el iPad 4 reutiliza en este caso el procesador A6 del iPhone 5, manteniendo prácticamente todas las características de este. Si tengo que hacer una aclaración, ya que en la comparativa del iPhone 5 dije que el A6 usaba la arquitectura ARM Cortex A15, lo cual no es cierto, al parecer Apple usó CortexA9. Eso quiere decir que en este caso estamos igualmente ante un procesador ARM Cortex A9, de doble núcleo a 1.4GHz cada uno. El Nexus 10 en cambio si se ha actualizado para usar la arquitectura Cortex A15 de la mano de la plataforma Exynos 5. Puede pensarse que no tiene sentido que el Nexus 7 se base en un procesador de 4 núcleos y el Nexus 10 tan solo en uno de dos, pero os recuerdo que no de núcleos vive el hombre, ni tampoco de GHzs. La arquitectura aquí dice más que nada, y en igualdad de condiciones un Cortex A15 es en bruto un 40% más rápido que un Cortex A9. Dicho de otro modo, es más que evidente que el procesador Exynos 5 sobrepasa en todo al A6X de Apple que usará en su iPad 4.

Para terminar, Samsung se ha asegurado que el Nexus 10 vaya sobrado, con 2048MB de RAM, frente a los 1024MB que montará Apple en su iPad 4. De nuevo una diferencia del doble.

Como vemos, en el caso de rendimiento, velocidad y uso de la última tecnología, la familia Nexus da una buena paliza a la familia iPad.

 

-Pantalla

La pantalla suele ser otro de los detalles escabrosos. Apple continúa con su marketing en asegurar que no hay nada mejor que sus pantallas retina las cuales tienen más definición que ninguna y los mejores colores. El problema es que lo de los colores hace tiempo que se desmintió, y por si fuese poco, ahora como veremos, sus pantallas retinas se han quedado “turbias” ante las pantallas de la competencia. Esto no quiere decir que sean malas, ni mucho menos, lo que quiere decir es que tampoco pueden decirse ya que tengan mayor definición.

Siempre he dicho que los dpi son muy importantes, aunque dependen más que otra cosa de la distancia de visionado. Cualquiera que lea comparativas mías pasadas siempre he dicho lo mismo, más mejor pero… es necesario? No. En este caso son las pantallas Nexus con mucha más definción, pero igualmente digo lo mismo que decía hace un año cuando las pantallas de Apple tenían mayor definición: A ciertos niveles, es imposible captar diferencia alguna.

En cuanto al tamaño, primero, es cierto que no poseen exactamente las mismas proporciones y tamaños, pero las diferencias en números (no en pulgadas) son casi los mismos. Así por ejemplo Apple en el iPad mini no usa 7 pulgadas realmente, sino 7.9, mientras que el Nexus 7 son 7 pulgadas exactamente. En el caso del iPad 4 y el Nexus 10 si están mucho más igualados. Aun así, la diferencia de tamaño práctica entre el iPad mini y el Nexus 7 es mínima, unos milímitros mas alta y un centímetro o dos más de ancho. Aun así, evidentemente adoptamos la premisa que cuanto más grande mejor (aunque esto no sea cierto para muchos). He optado por decir que es mejor el tamaño del iPad Mini, pero con reservas. En general desde mi punto de vista, cuanto más grande la pantalla mejor, el problema es que las 8 pulgadas están muy cerca de las 10 pulgadas, y por ende uno puede pensarse cambiar de categoría. Por otro lado las 7 pulgadas están mas cerca de las 4-5 pulgadas que se imponen en los móviles, con lo que si fuese algo más pequeño optaríamos siempre por el movil. Cuestión de gustos en este caso.

 

Samsung no ha dejado nada suelto, y para hacer frente al marketing absurdo y sin sentido de las pantallas retina de Apple, ha optado simplemente por poner pantallas con mayor definición que ellos. Así, mientras que el iPad mini tan solo posee una resilución de 1024×768 con 163 dpi, el Nexus 7 lo hace con resolución 1280×800 y 216 dpi. Es cierto que el Nexus 7 es algo más pequeño y por tanto es más fácil obtener (como he dicho siempre) una densidad de píxelese mayor (si tienes los mismos píxeles y la pantalla es más pequeña, la densidad es mayor). Aun así, en este caso es una diferencia de unos 50-60 dpi. Esto es apreciable? Tss, depende de a que distancia se vea la pantalla. Evidentemente la pantalla del Nexus 7 es mejor, pero cuanto mejor en cuanto definición? Bueno, un tablet de 7-8 pulgadas es obvio que se usará a una distancia visual más cercana que la usada en un tablet mayor, por tanto la diferencia en este caso sí puede ser quizás algo apreciable, usaríamos estos tablet de forma general a unos centímetros de nosotros, 15-20 cm diría yo.

En la gama de las 10 pulgadas, Samsung no ha escatimado tampoco. En este caso la diferencia en tamaño es mínima (9.7 pulgadas vs 10 pulgadas), y sin embargo hay una gran diferencia entre ambas pantallas. Apple la llama pantalla retina con una resolución de 2048×1536 y un dpi de 264 (nada despreciable), pero samsung lo hace mejor, con 2560×1600 y un dpi de 300. De nuevo, es evidente que la pantalla del Nexus 7 posee una mayor definición, pero si nos hacemos la misma pregunta de si esto puede “notarse” o no… tengo que decir que no. Al cesar lo que es del cesar, e igual dije en tantas otras cuando la pantalla de Apple tenía más definición que la diferencia NO SE NOTABA, aquí digo lo mismo, esos 40 dpi no se van a notar, a menos que uses el tablet a 1 centímetro de tu nariz. son mejores las de la familia Nexus? Sí. Se nota?? Ts..

 

Para terminar, ya hemos dicho que no solo podemos atenernos a la definición, es igualmente importante la calidad e intensidad de los colores. En este aspecto siempre ha perdido Apple y continua perdiendo. Las pantallas de Samsung poseen rangos dinámicos de contraste muy superiores, con tiempos de respuesta mucho mejores e incluso en esta ocasión se ha mejorado también el ángulo de visionado. Es decir, que se mire por donde se mire (nunca mejor dicho) las pantallas de Nexus 7 y Nexus 10 también ganan de lejos hoy.

 

-Almacenamiento

Ya hemos hablado mucho de esto. Cuanto es mucho cuanto es poco. Con la familia Nexus tienes modelos de 16 y 32, con iPad tienes también disponibles modelos de 64. Mucho o poco depende de cada cual, personalmente con 3GB de espacio tengo suficiente para TODO, y si quiero películas o las veo por medio de Google Play o a través de un HDD externo conectado por OTG. Es decir, que si hubiese modelo de 8GB que fuese aun más económico, sería mi elección. Otros en cambio quieren almacenamiento masivo para poner toda su música y películas dentro, para los que evidentemente 16 o incluso 32GB podría ser poco. Quien usa la tecnología de buena forma, os aseguro que con 8-16GB sobra teniendo en cuenta el uso de la nube que hacemos hoy en día, pero por supuesto siempre es bueno tener opciones. Es pro eso que evidentemente es mejor poder optar para quien lo quiera el modelo de 64GB

Ninguno de los dispositivos vistos hoy pueden expandirse por medio de uUSB, no obstante la familia Nexus gana gracias a dos funciones que no existen en los iPad. La primera es el conector uUSB, que nos permite tener un conector universal, un conector que sabemos que comparte la gran mayoría de usuarios y que por tanto el 90% de todos los cargadores o periféricos son compatibles. La segunda es la posibilidad de usar ese uUSB como un USB host gracias a OTG, dicho de otro modo podemos conectar cualquier dispositivo USB que tengamos en el terminal! Desde discos duros externos, lectores de tarjetas, teclados, ratones… lo que deseemos. Sinceramente, simplemente por la posibilidad de conectarle cualquier teclado o ratón sin necesidad de un dock o similar ya gana muchos puntos para mi.

 

-Comunicaciones

Mientras que el iPad Mini, Nexus 7 e iPad 4 poseen versiones tanto solo WIFI como WIFI+3G, el Nexus 10 aun no ha salido con una versión con datos. Es evidente que el lanzamiento es inminente, y que no pasarán ni 3 meses hasta que veamos un Nexus 10 50€ más caro con WIFI+Datos. Pero sea como sea ahora mismo NO. Es decir, ahora mismo quien necesite un tablet con datos además de WIFI de 10 pulgadas, le recomendaría un modem 3G USB (que puede conectarse por OTG al Nexus 10 por supuesto)

Quitando esta aclaración, los otros tres dispositivos poseen las mismas funcionalidades de redes. Sobre la tecnología 4G (LTE) no está del todo claro si Apple lanzará modelos LTE en algunos países (recordemos que ahora mismo hay muy pocos lugares en el mundo con soporte para LTE). Si es el caso, es evidente que sería un punto a favor para la familia iPad. Aquí en España para quien se lo esté preguntando, lo máximo que dan nuestras redes son los 7-12Mbs, y cualquiera de estos modelos son capacedes de llegar hasta los 42Mbs. Con eso lo digo todo.

 

-Cámara

Sin duda fue una de las primeras revoluciones en la telefonía móvil, pero y en este tipo de dispositivos? Tener una buena cámara en un móvil tiene una doble funcionalidad: La toma de fotos rápidas estés donde estés para cuando no tienes a mano una buena cámara reflex de toda la vida, o para hacer video llamadas. Pero ¿y en un tablet? Un tablet no es un teléfono ni está pensado como tal. Un tablet supuestamente tiene más semejanza a un PC, y me gustaría que llegado a este punto levantase la mano quien me diga que con la WebCam de su PC se dedica a hacer fotografías. Es evidente que cuanto más grande es el dispositivo, menos sentido tiene una cámara/lente potente para captar el mejor momento, ya que NO SE VA A USAR PARA HACER FOTOS. No soy amante de los Tablet tal y como se conciben ahora mismo, pero entiendo aun menos el propósito de una cámara trasera para tomar fotos. Sinceramente, ¿quien usa un tablet de 10 pulgadas para hacer fotos con la cámara trasera? Aun no he visto absulutamente a nadie en el mundo decir: “Mas a la izquierda, mas ha la derecha, perfecto, esperar que sujeto mi tablet de 10 pulgadas para hacer una foto…” más cuando estamos en un mundo que todos tienen un teléfono con cámara trasera infinitamente más manejable para esa tarea.

Ahora bien, cámara frontal? Por supuesto, si pienso que es necesario, las video llamadas están a la orden del día, y es necesario una cámara frontal para ello, que incluso nos valdría para hacer alguna foto rápida en algún momento. Que resolución o de que calidad? Bueno, si tenemos en cuenta que Full HD es 1920*1080 y que eso nos da un total de 2MP, creo que una cámara frontal de 2MP sería más que suficiente, pero por supuesto todo esto es tan solo mi humilde opinión.

Dicho esto, el iPad mini y el Nexus 7 implementan ambos cámara frontal de 1.2MP, pudiendo transmitir por tanto vídeo en HD Ready (1280*720). Pero en este caso solo el iPad mini cuenta con cámara trasera, en particular de 5MP. Por supuesto mejor tenerla que no tenerla, pero como ya he dicho desde mi punto de vista la podrían eliminar.

Dentro de los hermanos mayores, ambos cuentan con cámaras traseras de 5MP (lo mismo, por mí sobran), y en este caso hay diferencia en las frontales, usando el iPad 4 una cámara de 1.2MP (la misma que el iPad Mini) y el Nexus 10 lo amplía a 1.9MP, con lo que estaría en el umbral de poder transmitir vídeo en Full HD (sin llegar a él aun)

Las lentes no obstante (al margen de los MP) son mejores las de la familia Nexus, sin contar el siempre buen añadido del Zero Shutter lag o la posibilidad de poder tomar una foto a la par que se está grabando un vídeo (tampoco entiendo mucho la utilidad de esto último, pero es un añadido más).

 

 -Sensores

A día de hoy es ya un estándar prácticamente. Los dispositivos Android montan el pack básico (Acelerómetro, luminosidad, proximidad, giroscopio…) con el plus del sensor NFC, el barómetro en algunos modelos y el magnometro. Ya he dicho en otra ocasión que aunque parezca una tontería le barómetro, es bastante útil a la hora de fijar el GPS, y el sensor NFC es otro gran salto. Apple continúa sin querer añadir NFC, y el problema que tiene eso es que cuando se decidan a ponerlo no lo harán bien ni tendrán la experiencia que el resto dle mercado, será incompatible y demás. En cambio, el poner NFC cada vez más dispositiovos, dentro de un año la grán mañoría tendremos NFC, y las cosas se verán de otro modo. Util para muchas tareas… inservible para otras no digo que no.

 

-Dimensiones

Las dimensiones dependen evidentemente del tamaño en pulgadas del dispositivo. Por eso nos centramos más en el peso y en lo fino que sea. En este aspecto, el iPad Mini gana al Nexus 7, al ser más delgado y más ligero, aun cuando este es más grande. En el caso del Nexus 10 y el iPad 4 se invierten las tornas, y es el Nexus 10 quien es más fino y más ligero, siendo además más grande.

 -Batería

Por mucho que duela, la tecnología de las baterías es lo que menos ha evolucionado con el tiempo. Prácticamente todas las baterías son iguales, lo único que las diferencia es el tamaño y la forma.

Que batería dura más? Pues a día de hoy por lo general quien tenga la batería más grande. Hombre, no es cierto esto totalmente. Lo cierto es que como no ha avanzado mucho la tecnología de las baterías actuales, todas las mejoras en realidad recaen sobre lo bueno o lo malo que es el hardware en conservar esa batería, es decir, en perfeccionar al máximo el consumo. A menor consumo, la batería dura más, así de simple.

En estos casos, las baterías de la familia iPad son más grandes, aunque eso no es garantía absoluta. Tendríamos que acudir a los datos oficiales de los fabricantes, esos que dicen que el iPad 4 tiene una autonomía de 10 horas de duración en funcionamiento contínuo frente a las 9 del Nexus 10. El problema con estos datos oficiales es que el consumo de batería es totalmente subjetivo, y depende en su mayor parte de las condiciones que hicieron dar esos valores. Se estaba navegando? Se tenía WIFI/BT/NFC encendido? Se transmitían archivos? Es imposible. De echo las comparativas de batería son las más complicadas de establecer, solo los días y semanas y meses de uso pueden decirte si tienes una mejor o peor batería o si una actualización de software mejora el consumo o no. De otro modo…

 

 

Conclusión:

Para mí es claro, evidente por todos los lados. Tanto el hardware de la familia Nexus como su sistema operativo (Android Jelly Bean 4.2) es claramente superior. Pero es que además de esto, el precio también es significativamente inferior. Exceptuando en la posibilidad de optar por modelos de 64GB, la cámara trasera del iPad Mini o el modelo 3G que aun no está disponible para el Nexus 10, todo lo demás son ventajas a favor de Nexus. Hardware más potente, hardware más actual, mejores pantallas, mejores sensores… y un precio bastante inferior.

En cuanto al Software, estoy seguro que muchos dirán que es mejor iOS que Android, otros que mejor el AppStore que el Play Store.. Hay cuestiones que son simplemente gustos de cada uno, otras cosas son objetivas. El hardware es objetivo, la eficiencia de un OS es objetiva. En el momento de estar escribiendo estas letras, posiblemente tanto el Play Store como el AppStore estén igualados en cuanto al número de aplicaciones. En cuanto a la calidad de las aplicaciones tengo que decir que el 90% de TODAS las aplicaciones en cualquiera de los dos Stores no vale absolutamente para nada, y que tanto uno como otros tienen aplicaciones estrellas. Por un lado tenemos toda la integración perfecta y excepcional de los servicios de Google (Gmail, Maps, Gtalk, Earth, Translator, Chrome, Music…) en la otra cara tienen servicios iCloud como los llama Apple. Dos formas diferentes de ver el mercado quizás, o dos formas de ver negocio. Personalmente ya sabéis mi predilección. Pero eso para otro artículo, aquí hemos venido a hablar de hardware, no de software, eso lo dejamos para otro día (que no por ello no deja de ser interesante)

Si tuviese que escoger uno de los 4? no soy pro tablet, pero si tuviese, descartaría los tablets pequeños e iría directamente a los grandes. No es una cuestión de precio, sino de versatilidad y utilidad, y para un tablet de 7-8 pulgadas tengo el móvil. Y dentro de las 10 pulgadas, es evidente que en mi caso gastaría exactamente 399€, un Nexus 10 de 16GB solo WIFI (aun cuando existiese la versión de datos). Menos mal que no tengo que hacer esa elección, y esos 400€ los invertiría en otras cosas antes que un tablet, que para eso tengo el movil y sino un buen portatil de 13” tipo ASUS UX31A. Para gustos colores.

 

Un saludo.

WhatsApp: Secretos que todo buen bromista usuario debería de conocer

Share on Google+Share on FacebookTweet about this on Twitter

He aquí otro gran ejemplo de lo que la tecnología nos brinda: WhatsApp, y otro gran ejemplo del desconocimiento que se tiene de la tecnología. Nadie duda ya que la tecnología haya relanzado nuestro modo de vida, sin contar con los cambios profundos que ha sufrido nuestra sociedad actual debido a ella. Posiblemente uno de los grandes cambios que hemos sufrido en estos últimos años haya sido la manera de comunicarnos unos con otros. Desde las antiguas Cartas postales, pasando por el telégrafo, el teléfono fijo, el correo electrónico, el teléfono móvil, la mensajería instantánea, las redes sociales… la tecnología a día de hoy nos permite comunicarnos prácticamente con cualquier persona del mundo en tiempo real, ya sea por mensajes, por videollamadas… y esto realmente es increible y no seré yo quien diga que esto es algo dañino. Lo que es dañino es vivir en la ignorancia sin preguntarnos como funcionan las cosas o el peligro que puedan entrañar dichos sistemas de comunicación.

Son malas las redes sociales? No, lo que es malo es ceder tu alma a Facebook haciéndole dueño de toda tu vida personal. Es malo el uso de WhatsApp? No, lo que es malo es hacerse fotos/vídeos desnudos y enviarlos a cualquier persona desde redes públicas. Lo que quiero decir es que cualquier herramienta es buena siempre y cuando se sepa usar, o al menos que sepamos los pros y los contras que ellas acarrean, y así podemos decidir si nos compensa o no usarlos. Bien, pues como ya he dicho hoy le toca a esa gran aplicación que estoy seguro la gran mayoría de los lectores tienen o conocen (yo el primero): WhatsApp. ¿El por qué de esta publicación? Sinceramente por dos motivos. El primero por la gran cantidad de fallos de seguridad y privacidad que tiene desde mi punto de vista, y segundo porque como ya he dicho a día de hoy posiblemente sea una de las aplicaciones para dispositivos portátiles más usadas (sea cual sea la plataforma). Y por qué no, también he decir que me ha causado grandes momentos de risa floja gastando alguna que otra broma…

Por descontado, antes de comenzar quiero recordar como es costumbre que el interés particular es mostrar y enseñar las virtudes y defectos de esta aplicación, no enseñar a otros lammers o usuaurios malintencionados a aprovecharse de ellos! sino a proteger a los usuarios que puedan sufrirlos. Dicho esto, vamos a tocar algunos temas interesantes:

  • Apuntes generales sobre el funcionamiento de WhatsApp: Transmisión de datos, recepción, servidores de WhatsApp…
  • Historiales de conversaciones: Utilidad, peligro, Desencriptado de las copias de seguridad…
  • Aplicación práctica: Manipulación de los “metadatos” de los mensajes para la creación de miniaturas falsas en las imágenes transmitidas o el envío de imágenes gigantescas para agotar los datos de cualquiera

 

 

Funcionamiento

 Bueno, el funcionamiento de WhatsApp está muy bien pensado y aunque aquí deje algunos tirones de oreja no implica que no esté de acuerdo con la gran mayoría del sistema usado.

En realidad, WhatsApp no ha creado nada nuevo de cero (o muy poco), sino que ha cogido lo mejor de cada programa de mensajería que ya teníamos y lo ha puesto todo junto. Eso no quiere decir que sea el mejor programa de mensajería, o que sea imprescindible, e incluso personalmente considero mucho más imprescindible Google Talk. No obstante la gran ventaja que ha hecho de WhatsApp que su uso sea exponental no ha sido ni mucho menos el poder compartir fotos, vídeos o ser multiplataforma. Lo que ha hecho de WhatsApp tan extendido ha sido a su vez lo que yo considero el peor fallo que tiene: No hace falte añadir/aceptar a nadie.

Los usuarios que lo instalan tan solo tienen que acceder al programa y este les dice automáticamente no solo quienes lo usan!! sino también el mensaje personal de cada uno, si está en línea, cuando fue la última vez que se conectó… es decir que tan solo te hace falta el número de teléfono de una persona para saber todos esos datos, e incluso si quieres ponerte en contacto con él o aplicar alguna de las “técnicas” pernisiosas que veremos al final del todo. No necesitas que el conocido o desconocido te acepte, te conozca… si tiene WhatsApp, puedes hablar con él. Sí, muchos dirán que puedes bloquear a quien quiera por supuesto, pero para cuando llegue ese caso igual ya es tarde. ¿El lado positivo de todo ello? Fácil, que no tienes que agregar a nadie y lo que ello implica. Como vemos, ya desde el comienzo vemos el balance constante que hay que tener entre Comodidad Vs Seguridad y privacidad… en este caso el usuario prefiere Comodidad… (craso error en mi opinión)

 

Para entender el funcionamiento de WhatsApp por desgracia, tenemos que entender aunque solo sea por encima como funcionan las plataformas móviles que tenemos la inmensa mayoría a día de hoy, ya sean dispositivos Android o iOS. Podría citar también Windows Phone o BlackBerry, pero sinceramente solo Android copa casi el 70% del mercado, si a eso le sumamos la aportación de iOS… ¿Por qué es importante como funcionan nuestros dispositivos? porque para ser posible usar ciertos servicios, muchas veces la limitación o viene de la imaginación del de fuera, sino de nuestros dispositivos en sí mismos.

Enviar un mensaje desde un dispositivo a otro es fácil y no tiene complicación alguna, pero.. ¿que pasa si el otro dispositivo no está disponible? A fin de cuenta, de que sirve un programa de mensajería de este tipo si tan solo podemos ponernos en contacto con nuestros allegados cuando la otra persona tiene cobertura de datos o WIFI. Esta tontería implica automáticamente la necesidad de una infraestructura importante y una forma totalmente diferente de enfocar este tipo de programas. No sirve los métodos tradicionales de realizar comunicaciones directas Origen<>Destino, que aunque suelen ser mucho más rápidos y seguros no son viables a menos que Origen y Destino estén siempre 24 horas al día conectados. Eso hace necesario un servidor (o varios) de la compañía del programa (en este caso WhatsApp) que centraliza TODO. Dicho de otro modo, cada mensaje, imagen, contacto, vídeo… que se transmite (o creemos transmitir) a un contacto, dichos datos en realidad NO VAN a nuestro contacto, se envían siempre absolutamente todos a los servidores de WhatsApp. El servidor de WhatsApp está en contacto continuamente con cada dispositivo que está conectado a WhatsApp por medio de un canal (supuestamente seguro), que usa no solo para recibir datos del usuario, sino para enviarle (o avisarle) de que tiene un mensaje nuevo.

En realidad es diferente como funciona WhatsApp para iOS o para Android. En el caso de Android, los dispositivos son todos multitarea, lo que implica que WhatsApp se encuentra SIEMPRE ejecutándose y funcionando, si el servidor de WhatsApp recibe un mensaje para nosotros, nos envía el mensaje por medio de ese canal abierto que tiene con nosotros, y nos entrega el mensaje de inmediato. iOS no es así. iOS no es multitarea, lo que implica que cuando el usuario NO TIENE por delante la aplicación de WhatsApp abierta, WhatsApp NO ESTA funcionando. En este caso WhatsApp lo que hace es hacer uso de las notificaciones Push de iOS, envía una notificación Push al dispositivo del usuario para avisarle de que tiene un mensaje para él (NO LO ENTREGA), y hasta que el usuario no acepta la notificación o accede de nuevo a WhatsApp, el mensaje no es recibido por el teléfono. Este de echo es el motivo por el cual es muy sencillo saber si un usuario de iPhone está o no mirando WhatsApp. Ya no solo por que aparezca su estado “En línea”, sino porque WhatsApp nos notifica al emisor con el símbolo de la Aspa o la Doble Aspa si el mensaje lo ha recibido el contacto (Un Aspa implica mensaje recibido en los servidores de WhatsApp, dos Aspas implican que el usuario lo ha recibido). Dado que iOS tan solo puede recibir los mensajes una vez abre WhatsApp, podemos usar esa información. En caso de Android no es posible, ya que obtendremos el doble aspa normalmente en cuanto le enviemos el mensaje, da igual que el usuario lo lea o no lo lea, acceda a WhatsApp o no, porque el mensaje habrá sido recibido por su aplicación sin necesidad de que el usuario acceda a ella.

 

La transmisión de “objetos” (entendiendo por objetos audio, imágenes, geolocalización…) se hace de forma diferente. Cuando cualquier usuario manda un objeto a otro, el proceso es diferente:

  1. En caso de ser una imagen, WhatsApp la redimensiona a un máximo de 800*600
  2. Nuestro WhatsApp transmite primero el objeto a los servidores de WhatsApp en una ubicación a priori aleatoria dentro del servidor de WhatsApp
  3. Una vez que ha transmitido la imagen, envía un “mensaje” al contacto en cuestión, pero este mensaje aunque tiene la misma estructura interna que un mensaje de texto, no contiene texto, sino los datos del objeto que ha enviado, como la ubicación del objeto (la URL donde se encuentra), el tipo de objeto que es (imagen, audio…), nombre del archivo… y otros metadatos
  4. WhatsApp como si se tratase de un mensaje normal y corriente de texto, envía el mensaje (o la petición si es iOS) al destino
  5. El destino recibe un mensaje EXACTAMENTE igual que si fuese de texto, pero los metadatos del mensaje informan al dispositivo que hacer. Es decir, si el dispositivo recibe un mensaje con los metadatos de que tiene que descargar una imagen, accederá a la URL de la imagen (que será donde esté alojada la imagen que nos envío nuestro contacto) y la descargará.

 Esto que puede carecer de importancia, veremos como puede tener gran utilidad para un usuario “listo”.

Este sistema, deja abierta la incógnita sobre dos cuestiones principalmente. La primera, dado que los “objetos” no son enviados al otro usuario en una comunicación directa, si pueden ser accedidos desde otros dispositivos o si alguien puede tener acceso a ellos. La segunda, dado que nuestros “objetos” tienen que ser almacenados de forma temporal en los servidores de WhatsApp, ¿Por cuanto tiempo?

Respecto a la primera pregunta, siento decir que por absurdo que resulte CUALQUIER usuario puede acceder a CUALQUIER contenido enviado por CUALQUIER otro usuario, siempre que se den dos premisas: Conozca la ubicación de dicho archivo y no haya sido eliminado de los servidores de WhatsApp. Tampoco hay que ser alarmista, y resultaría bastante complicado poder acceder a dichos contenidos. Recientemente WhatsApp ha hecho cambios que impiden a priori a este contenido de forma directa (a través de un navegador), pero tan solo afecta a las nuevas versiones y para el contenido que se genera por estas, cualquier contenido que se genere por las versiones antiguas o que fue generado por estas, es totalmente accesible.

Respecto a la segunda pregunta, sinceramente desconozco el tiempo por el cual el contenido continua siendo almacenado en los servidores de WhatsApp y no es eliminado. La teoría podría decirnos que en cuanto el “objeto” es descargado por el usuario en cuestión, dicho contenido se elimina de los servidores de WhatsApp, pero esto no es así. Seguramente podrían excusarse con que si reenvías el mensaje no es necesario volver a enviar el archivo a los servidores de WhatsApp o ni siquiera tener dicho contenido en nuestro teléfono. Personalmente no me vale esa excusa, el único dueño de dicho contenido debe de ser el usuario, y por privacidad, el contenido debería de ser eliminado nada más enviarse. De forma fiable, puedo decir que durante más de un mes el contenido permanece disponible, pero a partir de ahí… puede ser un mes o un año.

 

 

Historial de conversaciones

Aunque no se ha citado en el punto anterior, WhatsApp guarda de forma automática una copia de seguridad de todas las conversaciones que tenemos abiertas en WhatsApp. La utilidad de esta copia de seguridad es la de conservarlas en caso de que actualicemos la aplicación, la desinstalemos y la volvamos a instalar… o simplemente restablezcamos nuestro dispositivo. Sin estas copias de seguridad, sería imposible que nuestro dispositivo pudiese restablecerlas.

Esta función a priori  esencial tiene dos problemas fundamentales. El primero y principal es que esta función no puede deshabilitarse, de nuevo el usuario no tiene capacidad de decidir si quiere esas copias de seguridad o no las quiere, para ser exactos quiera o no quiera su WhatsApp guardará una copia de seguridad (en Android) sistemáticamente a las 4.00 de la noche. Las copias de seguridad son acumulativas por otro lado, lo que quiere decir que lo que contiene una copia de seguridad en el momento de realizarse es una copia exacta de TODAS las conversaciones con todo su historial de mensajes en ese mismo instante. Además, estas copias de seguridad no se sobrescriben por la del siguiente día, sino que se guarda un período mínimo de 7 días, es decir, que se conservan siempre al menos 7 copias de seguridad diferentes, en las que como hemos dicho al ser acumulativas, la más actual contendrá siempre toda la información que puedan tener las otras, siempre y cuando (y aquí está la cuestión) no se haya eliminado ningún contenido.

¿Que pasaría si antes de las 04.00 elimino una conversación completa (o parte de ella) que mantuve dos días atrás con una persona? Que en la nueva copia de seguridad dicha conversación no existiría, pero si existiría en la copia de seguridad de 2 días atrás, y dependiendo de cuando se realizase esa conversación, incluso en las copias de seguridad de una semana atrás o incluso más. Esto es interesante desde el punto de vista de la privacidad, puesto que podríamos recuperar de forma legítima o ilegítima el contenido de conversaciones de WhatsApp que fueron borradas tiempo atrás.

 

El segundo problema fundamental al que me refería reside en la seguridad de dichas copias de seguridad. En el caso concreto de iPhone, dichas copias de seguridad se encuentran en la partición pública de este, con lo que bastaría cualquier aplicación que use el protocolo de trasferencia de Apple para acceder a tales archivos. En el caso concreto de Android estas se encuentran en el espacio designado como “SD”, lo cual implica que conectando simplemente el terminal a un PC tendríamos accedo a dichos archivos, o incluso simplemente retirando la SD (en caso de ser externa) y copiarla en otro equipo. Esto no es que suene muy seguro, puesto que sería tremendamente sencillo copiar en segundos todo los historiales de conversación (y lo mismo para imágenes, audios…) que se tenga en WhatsApp.

Ante esta segunda opción, WhatsApp hace unos meses ya implementó por fin un sistema de seguridad de cifrado, haciendo que estas copias de seguridad residiesen de forma cifrada en estos almacenamientos más accesibles por cualquiera. No obstante, el sistema optado por WhatsApp es totalmente inservible. Cifrar las copias de seguridad no es una mala idea, pero entonces tendrías que cifrar no solo las copias de seguridad, sino el historial que usa el propio WhatsApp de forma activa. Es decir, cuando abrimos WhatsApp y vemos todas nuestras conversaciones, estas no son las de las copias de seguridad, que son las que se cifran. Es cierto que los datos de la aplicación en sí están más protegidos y son de más difícil acceso que las copias de seguridad que se almacenan en espacios más sencillos, pero cualquier iPhone puede realizarse JailBreak para acceder al sistema de archivos íntegro, y en Android tres cuarto de lo mismo cuando se Rootea.

No obstante no digo que el sistema de cifrado de WhatsApp sea totalmente inservible por esto (que también), sino porque de forma totalmente inexplicable WhatsApp usó la misma Key de cifrado para absolutamente TODOS los dispositivos. No voy a entrar siquiera en las numerosas alternativas que tendrían a su alcance, pero sí a recordar lo absurdo que es cifrar absolutamente todas las copias de seguridad que WhatsApp hace con la misma clave. ¿Por qué? Porque eso quiere decir que está codificada en la misma aplicación cuanto menos, y que simplemente viendo el código de la aplicación se puede extraer dicha key. ¿A efectos prácticos?

Si conocemos el cifrado usado por WhatsApp y sabemos la clave de descifrado, tendremos desencriptadas las copias de seguridad que deseemos. En este caso, actualmente WhatsApp usa el estándar AES 192, con un esquema de codificación ECB (Electronic CodeBook). Quien quiera saber más de esto puede leer esta publicación de hace tiempo: Cifrado de datos. No tengo nada en contra de usar AES 192 como sistema de cifrado, aunque por otro lado nadie en su sano juicio a día de hoy usaría ECB. Sea como sea, teniendo en cuenta estos datos, solo nos quedaría conocer la clave escogida por WhatsApp para realizar la tarea de cifrado y descifrado (cifrado simétrico), que es:

“346a23652a46392b4d73257c67317e352e3372482177652c”

 

Si usamos por ejemplo OpenSSL para poner todo ello junto, con una simple línea de comando podríamos descifrar las copias de seguridad de cualquier usuario que queramos:

“openssl enc -d  -aes-192-ecb -in cifrado.db -out descifrado.db -K 346a23652a46392b4d73257c67317e352e3372482177652c”

Esto no es un secreto que digamos, y por tanto hace que el cifrado que hace WhatsApp sea totalmente carente de sentido, ya que cualquiera que pudiese tener interés especial en obtener dichas copias de seguridad puede seguir obteniéndolas.

 

 

Aplicaciones prácticas

Lo cierto es que podríamos aplicar todo lo anterior a bastantes aplicaciones prácticas bastante curiosas, ya se sabe que la imaginación es el único límite. Aquí solo voy a centrarme en dos en particular por lo “divertido” o lo “funestas” que pueden llegar a ser y lo simple de llevarlas a cabo.

  • Imágenes Falsas: Imágenes cuya miniatura es una foto y la foto real al verla es otra cosa
  • Imágenes interminables: Imágenes que pueden ocupar 100MB, 200MB… lo que se quiera, obligando a agotar los datos de cualquiera.

 

Hace ya algún tiempo, llegaba a mi terminal por WhatsApp una imagen en la que podía apreciarse en la miniatura de la conversación la foto de un chico “sexy”. Nada más lejos, era un joke, un hoax, ya que en realidad cuando procedías a verla/descargarla en su lugar lo que te encontrabas era con la foto de un mono sacando el dedo. Más exactamente, aquí podemos ver la minuatura que aparecería en la conversación (arriba a la izquierda) y la imagen una vez vista/descargada:

 

 

Esto es posible precisamente por algunas de las cosas explicadas anteriormente. Pero no hay que tomarse este tipo de cosas como simples “bromas” (que puede ser el ejemplo anterior), sino cuestiones a tomar bien en serio, recordemos que los dispositivos Android tienen la posibilidad (activada por defecto) de descargar de forma automática las imágenes. Dicho de otro modo, podríamos enviar todo tipo de bromas de muy mal gusto a cualquier usuario, y las imágenes “de mal gusto” se quedarían en su teléfono hasta que se eliminasen… imaginar que aquel que las está recibiendo no las revisa todas u olvida que están… cualquiera que acceda a su galería de imágenes podrá llevarse una sorpresa desagradable. Y aun cuando las imágenes no se descarguen de forma automática es lo mismo, puedes enviar una imagen a cualquier persona (aunque ella no te conozca) y…

 

Dejando a un lado las cuestiones de siempre y volviendo a esta publicación y al primer punto de las imágenes falsas, ¿como se pueden crear este tipo de imágenes? Las dos cosas que vamos a ver aquí en realidad están basadas en el mismo principio, la modificación de los metadatos de los mensajes que enviamos y recibimos, por lo que antes de seguir vamos a ver que son esos metadatos, como “verlos”, y lo demás vendrá de corrido.

 Vamos a asumir a partir de aquí que el usuario tiene un dispositivo Android con acceso de Root, no es obligatorio ni ser Root ni tener Android, pero por simplificar y facilitar las cosas es lo que vamos a tratar. Así como también para facilitar la lectura vamos a suponer que nuestro número de teléfono es el 666123123 y el de cualquier contacto será siempre 666123124:

 

Cuando WhatsApps se ejecuta tiene que cargar evidentemente nuestras conversaciones, luego eso está en algún lado, y ya hemos dicho que no son las copias de seguridad. Si sabemos buscar en nuestros dispositivos pronto encontraríamos que estos datos se encuentran en la ubicación de nuestro terminal:

/data/data/com.whatsapp/databases/

El archivo en cuestión es “msgstore.db”

Es un archivo de bases de datos, concretamente SQLite, así que el siguiente paso sería abrirlo para ver que es lo que realmente tendríamos dentro, lo cual al ser una base de datos SQLite el proceso sería trivial. Una vez abierto nos damos cuenta la gran información y posibilidades de este archivo:

 

En realidad no es necesario pasarse horas explicando el significado de cada tabla/columna de estas. En nuestro caso nos centraríamos en la tabla “messages” que contendría TODOS nuestras conversaciones tal y como las guarda y gestiona WhatsApp. Cada entrada en la tabla messages corresponde a un mensaje enviado o recibido, y recordemos una vez más que cualquier objeto que se manda o se recibe cuenta también como mensaje, no solo cuando se manda/recibe texto. Dentro de esta Tabla encontramos diferentes campos para cada una de las entradas (los mensajes enviados y recibidos) que podemos ver reflejado en la imagen anterior. El significado de cada campo varía fundamentalmente dependiendo del tipo de mensaje que sea, pero por lo general es fácil conocer cada uno de ellos:

 

_id:

Es el primary Key, el índice de los mensajes por así decirlo, el cual se incrementa en uno cada vez que se recibe o envía un mensaje. Por ejemplo, si tenemos 27176 entradas en la tabla messages y el valor de “_id” del último mensaje es 27455, significa que se han borrado 279 mensajes, lo cual ya de por sí puede ser útil para saber si un usuario es de esos desconfiados (o tiene algo que ocultar) y le gusta ir eliminando mensajes o conversaciones que pudiesen no ser del agrado de otros.

Key_remote_jid:

Designa la persona con la que se intercambió dicho mensaje, exceptuando los mensajes a los grupos o a más de una persona. Si el mensaje es enviado o recibido a un contacto en concreto, este campo comenzará con el número de teléfono de dicho contacto: “34666123124@s.whatsapp.net”. Si es un mensaje enviado a un grupo por el contrario, el formato será similar (no igual), en el que el número será el del creador del grupo y un ID, seguido del dominio @g.us. Ni que decir tiene que este campo sería el indicativo esencial para conocer para quien o de quien era ese mensaje

Key_from_me:

No hay que ser un lince para saber que significa. Es un campo que contendrá un “1” cuando el mensaje es enviado por nosotros y un “0” cuando el mensaje es enviado por otros. Es decir, es el campo que especifica si el mensaje es enviado o recibido.

 key_id:

Es un timestamp (una marca de tiempo) en formato UNIX que se añade a cada mensaje conteniendo el día y la hora de la última vez que se ha accedido a WhatsApp, con un contador adicional que se incrementa en uno por cada mensaje que es enviado durante ese día/sesión. Un ejemplo: “1350766259-45” (Que se traduciría como 20 de Octubre de 2012 a las 20.50. Mensaje 45)

status

Marca con un número que tipo de mensaje es en función de un código numérico de 0-6. Así por ejemplo, todos los mensajes de grupos tendrán en este campo un “0” si son enviados por otros contactos, “4” para los enviados por nosotros y “6” cuando son de control. Para los mensajes normales es similar, existen diferentes códigos para diferentes tipos de mensajes

 needs_push

 Imagino que este campo tan solo es usado en dispositivos como el iPhone, que al no ser multitarea como hemos dicho, accede a los mensajes mediante el sistema de notificación Push de Apple. Es decir que los mensajes no llegan al teléfono hasta que este abre la aplicación en cuestión. Posiblemente este campo marque cierto tipo de mensajes para poder acceder a ellos.

data

En los mensajes de texto, contiene el texto del mensaje propiamente dicho, en los mensajes de objetos este campo estará simplemente vacío

timestamp

Marca de tiempo en formato UNIX de cuando son enviados los mensajes

media_url

Ubicación Web en la cual se encuentra el recurso al que se está intentando tener acceso, por tanto este campo estará vacío en caso de ser un mensaje de texto, y contendrá la dirección a los servidores de WhatsApp de la imagen, el audio… del objeto transferido

media_mime_type

MIME hace referencia al tipo de archivo que se quiere transmitir, es un “código” por así decirlo usado universalmente para indicar a los navegadores web y otras aplicaciones el tipo de contenido al que se está accediendo. WhatsApp hace exactamente lo mismo. Por ejemplo, si se va a transmitir una imagen JPG, el tipo MIME será “image/jpeg”, si fuese un vídeo podría ser “video/3gp” ó “video/mp4”. Este campo no obstante no es a fin de cuentas necesario para WhatsApp, o al menos para todos los dispositivos, si lo eliminásemos veríamos que todo funcionaría igual. Evidentemente si se está transmitiendo texto, este campo estará vacío

media_wa_type

Este campo si es esencial, y es este y no el anterior el que dice a WhatsApp que tipo de contenido se está intentando abrir. Es decir, el que dice si lo que nos han mandado tiene previsualización porque es una imagen y lo tiene que abrir el visor de imágenes o si es un vídeo y tiene que abrirlo el reproductor de vídeo (por ejemplo). En este caso, el valor de este campo es de nuevo un entero de 0-5, cada uno de ellos indentifica un contenido diferente.

0 -> Texto, 1 -> Imágenes, 2 -> Audio, 3 -> Vídeos, 4 -> Contactos, 5 -> Geoposición

media_size

El tamaño del objeto que se transmite en Bytes.

media_name

El nombre del objeto tal y como estaría en nuestro dispositivo, por ejemplo si es una imagen sería el hash de esa imagen con la extensión suya. Evidentemente este campo está vacío para el texto

latitude y longitude

Cuando se transmite un objeto de tipo ubicación (tipo 5), estos campos contienen ni más ni menos que la geolocalización, la latitud y la longitud. En cualquier otro caso, estos campos están a “0”.

thumb_image

Contenido binario que almacena casi siempre la ubicación local (y nombre) del objeto en cuestión. Por ejemplo si es una imagen que ha llegado a nuestro dispositivo, contiene la ubicación dentro de nuestro dispositivo donde se encuentra.

remote_resource

Indica el origen de los mensajes que son enviados dentro de un grupo, el número de teléfono de quien los envía. El formato es el mismo que el usado en Key_remote_jid, de echo realiza la misma función que este, pero en los grupos. (recordemos que en los grupos key_remote_jid  identifica al creador del grupo siempre)

received_timestamp

Otra marca de tiempo, pero en este caso de cuando el mensaje fue recibido. Gracias a este campo y al anterior, podemos saber cuando se envió el mensaje y cuando fue recibido (siempre desde el punto de vista de nuestro dispositivo), que es lo que se usa de forma visual. Un aspa cuando se envía, un segundo aspa cuando se ha recibido (nada que ver si se ha leído o no)

send_timestamp

No se usa, su valor es “-1” siempre, supongo que simplemente porque el campo “timestamp” realiza la misma función

receipt_server_timestamp

Marca de tiempo que especifica cuando el servidor de WhatsApp recibió el mensaje

receipt_device_timestamp

Marca de tiempo que especifica cuando el destino recibe el mensaje. Las marcas de tiempo son todas diferentes aunque tengan nombres diferentes. Así por ejemplo, en cuanto enviamos un mensaje tendríamos la primera marca de tiempo. La segunda sería impuesta por el servidor de WhatsApp que es cuando ellos lo reciben. La tercera sería cuando el usuario recibe en su dispositivo el mensaje y la introduce el dispositivo del destinatario, y al final la cuarta es la que pone nuestro propio dispositivo cuando ha recibido la confirmación de que el mensaje le ha llegado al usuario en cuestión.

raw_data

Contenido binario que contiene una imagen en miniatura de la imagen que se está transmitiendo (cuando el objeto es una imagen)

media_hash

Hash en formato Base64 del objeto transmitido. En realidad no se usa/verifica, o al menos no es enteramente necesario.

 

Con todo esto, ya podemos empezar a ver las grandes posibilidades que tiene conocer este archivo, y es cuando podemos hacernos preguntas ciertamente interesantes, y es cuando podemos empezar a aplicar de forma práctica algunas cosas:

  • Si puedo ver la base de datos, puedo modificarla y volverla a colocar en su sitio? -> Por supuesto, igual que se extrajo se mete de nuevo
  • Que pasa si modifico el campo raw_data y meto otra miniatura? -> Que la miniatura es una imagen y la foto real es otra
  • Que pasa si especifico la URL de un objeto que no está en los servidores de WhatsApp? -> No pasa nada, el destino descargará el contenido desde el sitio remoto que se especifique igualmente
  • Que pasa si modifico el key_remote_jid en un grupo? podría acceder a un grupo ya creado sin invitación? -> Todo es probar a ver que pasa

 

Empecé diciendo que veríamos un par de aplicaciones prácticas sencillas. La primera como enviar imágenes “falsas” a otro contacto y la segunda como enviar imágenes de cientos de MB si queríamos. Visto todo esto es bien simple hacer esto

 

Como enviar imágenes falsas que ni siquiera están en WhatsApp

  1. Extraer la base de datos
  2. Disponer en el PC de la miniatura (por ejemplo en 100×100 pixeles) y de la imagen real
  3. Modificar el campo raw_data con la miniatura
  4. Modificar el campo media_url con la ubicación web en la cual se encuentra la imagen real a trasferir
  5. Modificar por seguridad el campo media_size con el tamaño de la imagen remota
  6. Guardar los cambios y volver a colocar la base de datos en el móvil
  7. Abrir la conversación en la que hemos modificado el mensaje y veremos que ya de por si la miniatura ha cambiado, dejar pulsado y reenviar al contacto que queramos

Al reenviar no estamos cargando de nuevo imágenes, estamos reenviado simplemente los metadatos de esta, con lo que a nuestro contacto les llegará una imagen para descargar con una miniatura que nada tiene que ver con la imagen real

 

Como enviar imágenes gigantescas con el fin de agotar los datos de cualquiera?

  1. Extraer la base de datos al PC
  2. Ubicar en inet alguna imagen gigantesca o cualquier otro contenido que se pueda acceder de forma directa
  3. Modificar el campo media_url con dicho contenido
  4. Modificar por seguridad media_size con el tamaño del nuevo objeto
  5. Guardar los cambios y volver a colocar la base de datos
  6. Abrir la conversación, buscar el mensaje y reenviar a quien queramos

De nuevo, el remitente tendrá dos problemas. Si tiene activada la descarga automática de fotos comenzará sin saberlo a descargar una imagen de 300MB si se quiere (incluso podemos poner la miniatura que queramos). Si no tiene activada la descarga automática basta con poner una miniatura suculenta para que le dé. Para cuando se de cuenta (si se da) ya han podido descargarse decenas de MB. Si el usuario está por WIFI no es un problema, si está por datos uno es capaz de hacerse idea de la “gracia”

Recordemos a todo esto que WhatsApp permite enviar mensajes a todo un grupo o mensajes en multidifusión. Imaginar que pasaría si mandásemos una imagen de 500MB a un grupo de 200 personas, eso sin olvidar que WhatsApp funciona sin necesidad de que otro usuario nos invite, con lo que podríamos directamente enviar una supuesta imagen sugerente (por la miniatura) a cualquier teléfono móvil que tenga WhatsApp instalado con el contenido que queramos, desde una imagen broma a una imagen de cientos de MB que posiblemente nunca podrá descargar del todo y que posiblemente podrá agotar la memoria incluso de muchos dispositivos.

Solo puedo recomendar algunas cosas… deshabilitar las descargas automáticas de imágenes, tener cuidado con que descargamos y en la medida de lo posible usar GTalk 😉

 

Un saludo a todos

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.