Archivo de la categoría ‘Windows’

Router Mitrastar HGW-2501GN-R2: Shell e Ingeniería inversa (para crear firmwares modificadas, por ejemplo) (Actualizado)

Share on Google+Share on FacebookTweet about this on Twitter

mitrastar
Introducción

La historia es sencilla. Aunque en la medida de lo posible siempre uso mis propios dispositivos, me gusta igualmente exprimir cualquier otro chisme que tenga por casa. Unos fuman… yo cacharreo.

En este caso, este fue el router que me entregó el ISP para mi conexión de Fibra, Mitrastar HGW-2501GN-R2. Duró conectado a la línea el tiempo de irse el instalador, pero lo saqué recientemente del “trastero” al ver por los foros de soporte oficiales (y no oficiales) que estaba dando un sin fin de problemas a los usuarios. Como siempre he dicho, opinar podemos hacerlo todos, pero si queremos dar soluciones que sean lo más acertadas posibles, es mejor comprobar las cosas por uno mismo y poder estudiarlas como dios manda. Así que le saqué el polvo y me puse a desentrañar sus más y sus menos.

Un dispositivo es bueno o malo sencillamente a razón de dos cuestiones sencillas, y es lo bueno o malo que sea su hardware y su software. Si el hardware es “malo” las ataduras de manos siempre son mucho peores, porque salvo modificaciones directamente en el hardware poco podemos hacer. Un hardware bueno tampoco hace del dispositivo algo bueno, es fundamental el Software, y sobre el software podemos decir lo mismo.

En el caso del Mitrastar, tenemos un poco de todo. Respecto al hardware no es ni mucho menos de lo peor que podemos encontrarnos en un router como muchos puedan pensar, pero eso no quiere decir que no se hubiese podido mejorar sustancial, sobre todo lo referente a su interfaz wifi. Eso no podemos cambiarlo, tenemos que aguantarnos con lo que hay. No he conectado aun el router por puerto de serie ni lo he sacado de su carcasa, así que los siguientes datos pueden no ser exactos del todo. Por lo que podemos saber el hardware se compone de una arquitectura MIPS:

CPU1: Ralink RT63368F (En Placa)/RT63365 (En Software)
Switch: Realtek RTL8368MB
Wl0: Ralink RT5392
RAM: 128MB
Flash: 64MB

El Switch debe de contar con unos 7 puertos diferentes, apoyado principalmente por el SOC RT63365. El adaptador inalámbrico dista mucho de ser una maravilla, nos encontramos ante un disposotivo 802.11n de dos streams unibanda. Por otro lado contamos con una cantidad más que suficiente de RAM y Flash para todo, lo cual siempre se agradece el no ir siempre bajo mínimos.

El principal problema que se ha tenido es que el software del router (la firmware) ha estado lejos de ser aceptable, salvaguardando por supuesto las propias limitaciones del hardware. Entre las quejas más frecuentes han sido los enormes problemas de batería causados por el router a dispositivos portátiles, la interfaz web de configuración con constantes problemas… En un mundo ideal, como se trata de Software, en el peor de los casos podríamos decir: “Pues si no quieren hacer ellos su trabajo, al menos voy a ver si puedo yo mejorar o corregir alguno de esos problemas de software”. Pero nunca suele ser tan sencillo, las firmwares y los sistemas se protegen precisamente para impedir cualquier tipo de modificaciones al software, siguen sin entender que cuanto más abierto sea un software más probabilidad hay que funcione mejor y con menos fallos/problemas.

 

Acceso Básico

Manos a la obra, partamos desde cero. Instalamos el router, lo tenemos todo funcionando… ¿ahora que?. Aquí entra en juego el primer escollo, y la culpa de esto la tiene principalmente los ISP, nada que ver con los fabricantes del hardware o el software que se instala (por lo general). Los dispositivos que nos entregan actualmente (No solo Movistar) vienen precargados con una configuración básica por defecto con los ajustes básicos de la compaña, como puedan ser los SSID, ajustes de WAN… ahora debido a los servicios avanzados como VoIP o IPTV suele ser necesario además de todo esto ajustes adicionales específicos para cada cliente, así que el router está preparado para conectar a los servidores de ellos después de un reset o cada X tiempo para reconfigurarse con los datos de la línea del cliente. Esto es perfecto porque evita configuraciones manuales uno a uno.

Lo primero que quiero o puede querer cualquiera es realizar pequeños ajustes a nuestro router, ya sea abrir un puerto, configurar una IP diferente… eso lo hacemos como toda la vida de dios, lo más básico y sencillo: La interfaz web del Router. El problema aparece porque la mayoría de los ISP se preocupan y hacen TODO LO POSIBLE para que el usuario, el cliente, tenga acceso a cuantas menos funciones posible del router mejor. Esto se hace por lo general con la creación de usuarios con permisos mucho más restrictivos a los usuarios tipo admin/root con acceso completo. Estos usuarios que crean tienen al final acceso para modificar 3 parámetros y medio y no poder consultar muchas otras configuraciones que pueden ser de interés, con lo que nos limita enormemente, incluso a usuarios con un perfil básico. Esto es algo que la mayoría no toma en cuenta cuando contrata un ISP u otro, pero para mí es esencial y marca mucho el tipo de compañía que tienes delante. Muchos de los amigos que me leen saben mi opinión sobre Apple, y se resumen sencillamente en que no permito que una compañía me diga que puedo hacer o no hacer con mi hardware.

Dependiendo del dispositivo que tengamos instalado y dependiendo del ISP, podremos acceder de mejor modo o no la configuración de nuestro router. En el caso concreto del Mitrastar, tengo que decir sinceramente que chapó por Movistar, ha hecho lo que tenía que haber echo hace tiempo y hacer TODOS. El Mitrastar, como viene siendo ya costumbre desde hace tiempo en los dispositivos de Movistar tiene dos interfaces web, una sencilla para usuarios nóveles que quieren cambiar 3 cosas (llamada Movistar Home Station, aka mhs, y una avanzada. El Mitrastar posee 3 usuarios (en realidad son 4, pero el usuario samba lo obviamos), cada uno con permisos diferentes enfocados a necesidades diferentes:

-“admin”: La contraseña de este usuario podemos encontrarla debajo del router en una pegatina. Este usuario y contraseña nos da acceso a las dos interfaces del router. Es el acceso normal a la interfaz mhs, y si accedemos a la avanzada a través de mhs (o a través de la dirección http://IP/cgi-bin/main.html) nos encontraremos con limitaciones en cuanto que podemos modificar. Esta cuenta por otro lado carece de acceso por terminal (SSH/Telnet…)

-“1234”: La contraseña coincide con la contraseña anterior, y en este caso sería lo más similar a un usuario root. Tiene acceso completo a las opciones de configuración de la interfaz, y es la cuenta que usa el portal Alejandra igualmente para configurar de forma remota nuestros dispositivos (si los tenemos asociados al portal).

-“supervisor”: La contraseña en este caso es siempre la misma, zyad1234, y posee permisos similares al usuario 1234, con el añadido de que con este usuario se tiene acceso por la interfaz web a poder modificar los permisos de los otros usuarios y de sus contraseñas igualmente.

mhs
web

Ahora entenderéis porqué digo que en este caso chapó por Movistar. Cualquiera puede tener acceso completo (al menos por web) al Mitrastar, sin hacer cosas extrañas, sin tener que pelearse, sin acudir a… dicho de otro modo, los técnicos de Movistar no tienen un mejor acceso que nosotros. Gracias a estos usuarios podremos no sólo consultar la mayoría de todas las configuraciones del router, sino que también ajustarlas a nuestro antojo.

Por otro lado, lo primero que se le ocurre a cualquiera es ver como son los archivos de configuración (backup) del router, así que como primer paso para entender un poco todo lo que cualquiera haría sería descargar dicho archivo desde mantenimiento, quizás sea legible o haya algo o algún ajuste que pueda ser de interés. El archivo de configuración del Mitrastar, por suerte, no está cifrado y parece ser un xml totalmente legible, pero que algunas opciones curiosamente las enmascara, todas aquellas donde hay contraseñas. Por qué es esto interesante?? Bueno, yo he dicho que la contraseña de admin y 1234 es la misma, pero a veces no es tan sencillo como prueba/error, o mejor dicho… a veces es más sencillo no tener que estar probando… pero como vemos el archivo de configuración no permite ver estos datos. En cualquier caso, vemos que estos campos llamados “encrypted” comienzan todos por: “41455300”, casualidad que 41 45 53 = AES, lo cual nos daría a pensar que el resto es posible que sea el texto codificado en AES.

 

Acceso Limitado por Terminal

El 99% de las veces nos sobra la interfaz web, pero que pasa cuando nos gustaría poder modifica o consultar cualquier cosilla que no esté presente o tengamos acceso por la interfaz web?? A fin de cuenta presuponemos que nuestro router estará corriendo algún tipo de Linux debajo de él. Para eso es indispensable acceso mediante SSH o Telnet. El problema es que como aplican la mayoría de fabricantes, para negarnos la posibilidad de toquetear las tripas, lo que nos dan es acceso es a una shell limitada… muy limitada. Así, en el caso del Mitrastar si intentamos acceder mediante supervisor o 1234, nos encontramos ante un panorama… “triste”:

ssh

Así pues podemos acceder con las credenciales por defecto, pero los únicos comandos que nos muestra la interfaz como válidos son: ?, exit, save, sys, restoredefault, lan, igmp, wlan, nat. La mayoría de todos ellos tienen subcategorías. No hay nada interesante a priori que podamos hacer desde la shell que no podamos hacer desde la interfaz web. Dos comandos “al azar” muestran dos resultados interesante: mtd y sh, ninguno de los dos listados en los comandos disponibles. El primero nos devuelve que el comando está prohibido, el segundo directamente que introduzcamos una contraseña… ¿quizás existe una contraseña para poder acceder a la shell que hay debajo? Por descontado ninguna de las contraseñas que disponemos es aceptada como válida.

Algo relativamente común a las shell limitadas es que permiten realizar copias de la configuración. A priori podríamos pensar que esos “dump” son iguales que los que podemos obtener desde la interfaz web, pero… que pasa si introducimos por shell limitada “sys dumpcfg”?? Sí, nos devuelve en la consola exactamente el archivo de configuración que pudimos descargar con anterioridad… pero con una salvedad, en esta ocasión los campos de contraseña están en texto plano. Bingo!!

username=”supervisor” web_passwd=”zyad1234″ console_passwd=”zyad1234″

La contraseña es la misma, pero en cambio en el archivo de configuración cifrado vemos que el “resultado” es diferente. Asumimos que además de poder estar cifrado con AES usa algún tipo de SALT, y no sólo una key cualquiera. Aun así esto tampoco nos abre la puerta a mucho más, esta contraseña es de hace mucho conocida y compartida en muchos productos.

 

Acceso a la Shell que hay debajo

Lo que nos interesa es acceder detrás de la shell limitada a la que tenemos acceso. Parece que para esto existe directamente un medio para hacerlo, a través del comando “sh” desde la shell limitada, pero esto nos solicita una contraseña que es totalmente desconocida para nosotros. Aquí empieza realmente el trabajo duro, ingeniárselas de algún modo para poder acceder debajo, aunque sólo sea una vez, y poder echar un vistazo desde una shell completa. No voy a detallar, por cuestiones de seguridad, como logré ese primer acceso, pero sí de que se trata.

Presuponemos que tenemos Linux debajo, con lo que realmente lo primero que desearíamos sería echarle un ojo al archivo /etc/passwd y/o /etc/shadow. Estos dos archivos, en linux, son los que contienen las credenciales de los usuarios y sus contraseñas (cifradas claro está). Pero además contienen la shell que será ejecutada a cada usuario. Es posible que el router posea otro usuario/contraseña que desconocemos o a saber…

Pongamos que gracias a la interfaz web logramos ejecutar de algún modo algún comando dentro de la shell y sacar los datos por el navegador. “cat /etc/shadow” cat /etc/passwd” sería sin duda alguna las primeras pruebas, y pongamos que en un momento dado la interfaz web nos devuelve lo deseado, nada para shadow, y para passwd:

1234:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
admin:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/sh
supervisor:$1$$xxxxxxxxxxxxxxxxxxxx:0:0:root:/:/bin/cmdsh
samba:$1$$xxxxxxxxxxxxxxxxxxxx:500:500:Linux User,,,:/home/samba:/bin/sh

Bingo!! (de nuevo). Parece ser que además de existir un cuarto usuario, samba, el usuario 1234 y el usuario supervisor (que son los dos únicos que tienen acceso por shell) ejecutan una shell extraña llamada “cmdsh”. Sea como sea, si logramos ejecutar con suerte cat, podríamos igualmente intentar sobrescribir el contenido del archivo, igual no existe una protección contra escritura… como dicen, probar no cuesta nada… usando incluso de nuevo cat, se puede enviar el mismo archivo pero modificando la shell a ejecutar, en vez de /bin/cmdsh, /bin/sh. Lanzamos la petición, volvemos a lanzar otra para ver el contenido y… se ha modificado!!. Ejecutemos de nuevo una sesión Telnet/SSH, usuario 1234 (es al usuario que le cambie la Shell), su contraseña… y efectivamente no más shell limitada:

login as: 1234
1234@192.168.1.1’s password:
# ls
bin      boaroot  dev      etc      lib      linuxrc  proc     sbin     sys      tmp      userfs   usr      var
# uname -a
Linux MitraStar 2.6.36 #1 SMP Thu Aug 13 14:04:19 CST 2015 mips unknown
#

 Llegados a este punto ya lo tendríamos todo?? Sí y no. Esto habría que repetirlo siempre, porque si reiniciásemos el router veríamos que el cambio que habíamos realizado al archivo passwd se perdería, teniendo que repetir todo el proceso constantemente. Aun así al menos ya habríamos logrado acceder a la Shell de debajo con plenos permisos administrativos. ¿Podemos mejorar esto? Por supuesto.

Lo primero que viene a la cabeza es: Bien, puedo acceder gracias un exploit, pero parece ser que la shell cmdsh tenía un comando “sh” que solicitaba una contraseña para acceder, y no hay que ser muy listo que lo que permite es acceder precisamente a una shell completa. ¿Donde puede estar esta contraseña? Personalmente el primer lugar donde miraría, teniendo en cuenta que no parece existir otros usuarios en el archivo /etc/passwd, es en el binario de la propia shell, o sino este sabrá de donde obtenerla, dado que es esta shell la que lo solicita. Ya sabemos donde está, así que sólo tenemos que extraerlo. Esto puede hacerse de mil y una forma, dependiendo de las herramientas que tengamos disponibles claro está en la firmware del router:

-ssh/sftp/ftp/scp
-curl/wget
-netcat/nc
-base64
-usb
-…

Cualquier sistema nos vale para enviar donde queramos el archivo en cuestión y poder manipularlo en condiciones, la elección de un sistema u otro dependerá de las utilidades que tenga la firmware y de lo sencillo o no que nos resulte a nosotros mover los archivos. Una vez tengamos el archivo, tan solo tendríamos que decompilarlo y echar un vistazo rápido. Vamos a lo sencillo, si cuando introducimos a través de sh una contraseña cualquiera recibimos: “Password incorrect !” Podemos empezar buscando por ahí, o mirar directamente las posibles funciones… eso nos lleva al siguiente trozo de código:

diss

Curiosamente, justo unas líneas de ahí encontramos una extraña cadena alfanumérica. Bueno, además de que el código en ensamblador es bastante legible, lo que está claro es que compara un string (lo que introducimos por teclado) con el string “c93vu02jp4z04“. Si la comparación es incorrecta, vemos que salta a la posición 0x00402408 (=contraseña incorrecta), mientras que salta a otra posición en caso de que la comparación sea acertada. Dicho y hecho, tan solo tenemos que verificar que ese string es realmente la contraseña para acceder a la shell completa desde la shell limitada. Y no hace falta decir que efectivamente esa es la contraseña de acceso a la Shell.

Llegados a este punto lo tenemos todo, hemos podido acceder gracias a un exploit, hemos podido extraer la contraseña que nos da acceso a la shell completa, con lo que podemos ya hacer con nuestro router lo que deseemos… ¡No tan rápido! ¿Seguro que ya tenemos total libertad?.

 

Acceso (y modificación) a la “nvram” – Autentificarse

Como vimos en la parte del exploit, y si empezamos a jugar con la shell interna, antes o después nos topamos con un problema bastante importante. Sí, podemos usar todas las utilidades de nuestro router, podemos añadir reglas a iptables, ver el estado de todo, controlarlo todo!! ¿Pero como podemos hacer para que los cambios que hagamos sean persistentes?

Vimos que si intentábamos modificar el archivo passwd este volvía de nuevo a su “ser” al reiniciar. Esto nos dice que al menos la raiz de la firmware está protegida contra escritura de algún modo, y de echo no hay que ser demasiado imaginativo para ir entendiendo que el sistema de archivo del router usa SquashFS, un sistema de archivos de sólo lectura que se monta en cada inicio. Ademeás, si miramos realmente la ubicación de la carpeta /etc tenemos esto:

# ls -la /etc
lrwxrwxrwx    1 1234     root            8 Aug 13  2015 etc -> /tmp/etc

La carpeta /etc desde la cual accedemos a /etc/passwd ni siquiera se encuentra en el sistema de archivos SquashFS, sino que el bootloader/kernel genera el archivo de algún modo en cada inicio, por eso pudimos modificarlo con el exploit entre otras cosas, está fuera de la “prisión” de SquashFS. Se genera en cada inicio, con lo que nuestros cambios se pierden. Pero sabemos que todo no es tan negro, porque en realidad debe de existir una zona o partición donde se puedan inscribir datos y estos sean persistente, o algún sistema para poder hacerlo, ya que a fin de cuenta podemos configurar el router a través de la interfaz web, y los datos son persistentes a cada reinicio. Si cambiamos por ejemplo la contraseña del usuario 1234 dicho archivo al iniciar será diferente al original y reflejará el cambio que hicimos por la interfaz Web. Quizás no podamos modificar el sistema de archivo raiz (lo haremos, pero más adelante), pero cuanto menos en teoría deberíamos de ser capaces de realizar cualquier cambio persistente que permita la interfaz web, y eso como mínimo, porque es de suponer que esté donde esté ese “espacio” contendrá quizás otros datos de interés.

Así es realmente como funcionan la mayoría de dispositivos. Los routers suelen tener una zona llamada nvram (RAM no volatil), que contiene parámetros que pueden ser leídos y almacenados con independencia del sistema de archivos. Esto es necesario para poder realizar configuraciones de cualquier tipo, pero incluso el propio router necesita este “espacio” para poder funcionar y configurarse a sí mismo. En muchos dispositivos es bien conocida la herramienta “nvram”, pero si lo intentamos veremos que aquí al menos no disponemos de una herramienta similar. Así que queda hacer un poco de detective y ver si disponemos de alguna utilidad que nos brinde algo similar.

Como podemos acceder a la shell podemos recorrer rápidamente los directorios donde sabemos que es más que posible que se encuentren: /bin, /sbin, /usr/bin… la mayoría de todas las utilidades podemos conocerlas los amantes de linux y muchas otras deducirlas. Otras en cambio podemos ir directamente probando a ver que pasa. Si no damos con la “tecla”, tenemos otro sistema sencillo para hacernos una idea… si la interfaz web cambia los ajustes, la interfaz web debe de saber o tener idea de como realizar esto. Antes o después llegaremos a la conclusión de que hay ciertos binarios que parecen ser los encargados de manejar todo esto, aquellos que empiezan por “tc” que es el acrónimo de TrendChip. Si nos movemos por las carpetas de la interfaz web (/boaroot) veríamos también rápidamente las referencias constantes a tcwebapi, y mira tu por donde tenemos un binario llamado: “tcapi”. Si lo invocamos:

# tcapi
set unset get show commit save read readAll staticGet

 Parece ser que hemos dado con la interfaz que interactúa con la nvram. Con un poco de paciencia y de estudio aprendemos a usar esta interfaz. tcapi funciona de un modo similar a nvram, con show podemos mostrar lo que deseemos (no existe un show all), pero tenemos que especificar que nodo queremos visualizar. Los nodos son precisamente las etiquetas xml que están dentro de nuestros archivos de configuración. Si miramos nuestro archivo de configuración veremos por ejemplo uno de los primeros nodos, “Wan”, así que “tcapi show Wan” nos devuelve efectivamente todo lo almacenado en ese nodo. Podemos pensar que esto no tiene demasiada utilidad ya que a fin de cuenta tenemos el archivo de configuración, pero no hay que ser muy listo para presuponer que el archivo de configuración es sólo una parte de todo. De echo podemos almacenar los valores que queramos en la nvram existan o no existan en el arcivo de configuración, o modificar cualquier otro.

Si alguien ha usado anteriormente nvram (la utilidad) sabrá que para que los cambios se apliquen hace falta realizar un “commit” y seguido de un “save” si se quiere que los cambios se guarden (aplicar no significa guardar, y viceversa). Aquí tenemos lo mismo. “tcapi save” guarda todos los cambios realizados en la nvram, mientras que “tcapi commig nodo” aplica los cambios efectuados al nodo citado. Cuidado!! Estamos modificando la nvram, si guardamos los cambios y estos han sido incorrectos podemos encontrarnos en que sea necesario resetear el router para que vuelva a sus ajustes por defecto.

Quien llegue a este punto se habrá dado cuenta que, de echo, aunque puede usar show, no puede realizar un save y peor aun, un set, devolverá lo mismo que sucedía cuando intentábamos teclear mtd. El acceso por alguna razón a ciertos comandos, incluso teniendo permisos administrativos y a la shell completos, siguen estando restringidos, hace falta algo más para desbloquear esto. Aquí tendríamos de nuevo que empezar a investigar donde buscar y encontrar esto. Podríamos empezar por cmdsh y encontraríamos referencias a un supuesto archivo llamado “/tmp/Authentication”. Antes o después (grep es un gran amigo), daríamos con el binario /usr/bin/syscmd. Si decompilamos y echamos un ojo llegaríamos pronto a una sección bastante interesante:

auth

Vemos demasiada información, pero todo de gran utilidad. Por un lado vemos que aparece de nuevo el archivo nombrado, pero esta vez precedido de un comando completo, y además curiosamente justo encima vemos un “Correct Key imput. Auth…”. Eso ya nos está diciendo que el sistema parece importarle más que el usuario esté “autentificado” ante ciertos comandos que cualquier otra cosa, y que parece que lo verifica seteando el archivo /tmp/Authentification con authenticated. Podríamos hacer la prueba: “echo authenticated > /tmp/Authentication” y veríamos que funcionan mágicamente a partir de este momento tcapi set/save y otros

Antes de irnos a otro lado, podemos ver igualmente en el trozo desensamblado de nuevo la contraseña de acceso a la Shell, y un “EncryptKey” y un “Account_Common”. Quien haya estado ya jugando con la nvram sabrá que en esta se separan los nodos de otros subnodos con guiones, así que por curiosidad si miramos la información del nodo “Account_Common” con tcapi:

# /userfs/bin/tcapi show Account_Common
EncryptKey=MSTC

El resultado es un string: MSTC, que según aparece en la nvram es un “EncryptKey”. Demasiado cerca del código que hace estar autentificado para no tener nada que ver. Si vemos desde la shell que podemos hacer con syscmd, vemos que existe curiosamente un comando que es authKey, y que efectivamente:

# syscmd authKey
Error!
# syscmd authKey MSTC
Correct key input. Authentication done.

Así que en realidad el proceso “real” implicaría autentificarse a través de syscmd con la EncryptKey almacenada en la nvram, MSTC, y eso a su vez produce que el sistema setee el archivo anteriormentes citado. Así que en realidad podríamos realizar la autentificación de cualquiera de las dos maneras: por lo “legal” y a lo “bruto”. Ahora sí, después de esto, podríamos usar algunos de los comandos más particulares (y también peligrosos), como puedan ser: sys memwl, sys memww, sys erase, sys romd, tcapi set, tcapi save…

La nvram permite acceder a todos los parámetros almacenados en nuestra configuración, y además acceder a otros parámetros que podrían ser interesantes, pero eso para otro día. Veamos mejor que más podemos hacer… podemos modificar la nvram, podemos ejecutar cualquier herramienta que tengamos dentro del router, ahora iremos un pasito más, esta vez como poder “modificar” lo que nos queda, el sistema de archivos, e incluso poder instalar/actualizar componentes en ella.

 

Ejecución de comandos desde el archivo de configuración (Nuevo)

Por azares de la vida, me topé días después con que resultaba relativamente sencillo realizar ejecución de código directamente desde el archivo de configuración del router, que no deja de ser gran parte de la nvram. El secreto reside en el nodo “Autoexec”, que si miramos en nuestro archivo tan sólo existe como cierre.

El cfg_manager, por suerte para nosotros, parsea el cfg en cada inicio para cargarlo a la nvram. Al llegar a dicho nodo, si no está vacío, pasa TODO lo que hay en él (sin el nombre de la entrada, sólo los valores de estas) a un archivo llamado autoexec.sh en /etc/, le da permisos de ejecución y acto seguido lo ejecuta. Dicho de otro modo, podemos añadir todo el código que queramos ahí, que será ejecutado al inicio en el Router. Evidentemente de saber esto anteriormente, el proceso de acceso inicial al router hubiese sido mucho más sencillo.

El potencial de esto ya no está realmente en los expertos que sepan modificar la firmware o entrar y salir del Router de forma sencilla, sino que el usuario novel puede de forma sencilla gracias a esto solucionar problemas que pueda tener en el router, o aplica ajustes concretos especiales.

El formato que siguen estas instrucciones es similar al de otros nodos:

<Autoexec>     <Entry
arp_fix=”sysctl -w net.ipv4.neigh.br0.mcast_solicit=0″
dhcp_fix=”echo ‘* * * * * ebtables -D FORWARD -p ipv4 –ip-proto 17 –ip-source-port 67:68 -j DROP’ &gt; /etc/admin; crond -c /etc/” />
</Autoexec>

Ese por ejemplo sería el bloque modificado para realizar dos fixs a la firmware B21, uno el problema de la batería y otro el problema que posee el router que bloquea todo el tráfico DHCP que no sea el suyo propio. Es sólo un ejemplo sencillo, en realidad podríamos realizar casi cualquier cosa. Como vemos la entrada en sí no importa su nombre, es su contenido el que será pasado al archivo autoexec.sh. Tan sólo hay que añadir el bloque que queramos, guardar, cargar la configuración y solucionado.

 

 

Modificando el sistema de archivos raíz

El router usa como hemos dicho SquashFS para montar su raíz. El problema que esto nos origina es que no podemos realizar cambios en él directamente. Para poder hacer esto, en principio, lo que se necesita es modificar directamente la imagen SquashFS con los cambios que deseemos y volver a cargarla. En un sistema más potente o con otras herramientas podríamos incluso pensar hacer el proceso directamente bajo la misma shell, pero aquí estamos limitado tanto en espacio, herramientas y memoria del router, con lo que esta opción no es muy viable. La opción que nos queda es realizar la modificación fuera del router, y volver a escribir el sistema de archivos de vuelta al router.La teoría en realidad es sencilla, la práctica es algo más complicada porque hay que ver como podemos hacer esto.

A priori se me ocurren dos formas. Una, extrayendo en la partición que se encuentre (en caso de ser así) el sistema de archivos, modificarlo, copiarlo de nuevo dentro y volver a copiarlo a su partición con dd/mtd (lo cual puede resultar bastante peligroso si hacemos algo mal y tampoco tengo claro que pueda realizarse sin hacerlo desde el bootloader), o aprovecharnos del propio sistema de actualización de firmware del router, es mucho más seguro pero implica conocer bastante bien como es la imagen de actualización, para poder no solo modificarla, sino también hacer que el router la acepte. Yo he tomado la segunda opción, no quiero tener que llamar a Movistar para decirles que misteriosamente el Mitrastar ha muerto.

Dicho esto, se abren por desgracia una serie de puntos que pueden ser “largos”, pero necesarios. Si queremos modificar la firmware, lo primero que necesitamos es precisamente al firmware, el binario de actualización, y dado que las actualizaciones se realizan por telecarga puede no ser tan sencillo tener una copia de ella, a menos que conozcamos a algún amigo de un amigo que buenamente nos la suministre. Por suerte… hoy tenemos respuestas y medios para todos.

 

Estructura interna de las particiones de memoria

Antes que nada hay que “estudiar” como está organizada la memoria flash del router, hay que ver realmente que particiones hay:

# mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
# cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 “bootloader”
mtd1: 00020000 00020000 “romfile”
mtd2: 0014e7e3 00020000 “Kernel_main”
mtd3: 01090000 00020000 “Rootfs_main”
mtd4: 00006292 00020000 “Defcfg_main”
mtd5: 01d40000 00020000 “Tclinux_main”
mtd6: 0014e7e3 00020000 “kernel”
mtd7: 010b0000 00020000 “rootfs”
mtd8: 00006292 00020000 “defcfg”
mtd9: 01d40000 00020000 “tclinux”
mtd10: 00020000 00020000 “romd”
mtd11: 00020000 00020000 “second_romfile”

Con eso tenemos una visión más que completa del mapa del router, de como se compone internamente.Efectivamente comprobamos que la partición raiz es SquashFS, las particiones /sys, /proc son las habituales. A parte de ello se monta una partición como “ramfs” que como vimos contenía el archivo /etc/passwd, y por otro lado uan con el extraño nombre “usbfs”… es posible que el router tenga internamente puertos USB después de todo, y de echo la interfaz tiene configuraciones para SAMBA.

Lo que se refiere al particionado de la Flash, vemos hasta 12 particiones, y por suerte para nosotros los nombres son relativamente descriptivos. Vemos además que las particiones mtd2-5 estan duplicadas, o al menos eso parece, lo que nos hace pensar en un sistema de doble imagen, muy usado en los sistemas para evitar una mala actualización. Bootloader, kernel, rootfs y rom/cfg parecen evidentes su contenido, mientras que tenemos otra partición algo más extraña con el nombre de tclinux. El tamaño de las diferentes particiones también nos dan otra idea, siendo tclinux la partición más grande con diferencia, más que la suma de las demás, lo que posiblemente nos indique que tclinux es de algún modo “todo”, y de echo, lo es.

Pero pongamos por caso que tenemos la imagen de actualización, nos será más sencillo para explicar su estructura, y más adelante veremos como poder extraerla si queremos desde el router, que es secundario.

 

Estructura de la imagen de la firmware

Actualmente tan sólo existe una firmware completamente oficial, la B14, aunque la B21 se ha distribuido a muchos usuarios debido a los problemas ocasionados por la B14:

Mitrastar b14 113WJI0b14.bin b79d53bb663cbae480532942cc0e961a
Mitrastar b21 113WJI0b21.bin 770a5a52069066dc87978dba949cb1fd

Tomemos la segunda por caso. En lo personal, me gusta siempre antes de cualquier otra cosa, echarle un vistazo a través de un editor hexadecimal a ver que veo. Haciendo un barrido sin demasiada observación, vemos en primer lugar lo que parece claramente una cabecera al comiendo de la imagen, y curiosamente al final de todo el archivo nos encontramos también que termina con “</ROMFILE>” que es precisamente como termina también nuestro archivo de configuración. Si hacemos una pequeña búsqueda con esto, podemos localizar también el inicio de esta parte, que parece que tiene una pequeña cabecera que lo precede especificando que está comprimido y el tamaño que posee, eso lo vemos en el offset 0x011d27d6.

firmware

Como sabemos también que se supone es una imagen SquashFS, podemos buscar su cabecera y ver si se encuentra alguna correspondencia, buscando por los valores “68737173”, y sí… encontramos también una correspondencia de este en el offset ox0014e7e3, que termina de echo justo cuando comienza el archivo de configuración antes citado. Con esto tenemos prácticamente, y sin necesidad de usar ninguna utilidad, el contenido completo de la firmware (aunque queda ver y analizar aun unas cuantas cosas). Lo único que nos queda es una parte, que se encuentra después de la cabecera y antes de la imagen squashfs. Teniendo en cuenta que tenemos la información anterior de las particiones mtd, la respuesta es evidente: Es el kernel. Recordemos que en las particiones teníamos 3 en concreto que estaban duplicadas con el mismo nombre, con la única diferencia a priori de que las particiones más bajas tenían la coletilla main. Bien, por pura lógica asociamos defcfg al archivo de configuración que hemos encontrado, roofs a la imagen squashfs y el otro pedazo que nos queda es el Kernel. Además, como tenemos el tamaño de las particiones vemos también que efectivamente, si dividimos cada parte independientemente, corresponden sus tamaños a los tamaños de las particiones (ojo que dado que el tamaño de erasesize es de 0x00020000, el espacio de las particiones es múltiplo siempre de este valor, con lo que el tamaño excedente se rellena). Con este pequeño análisis, podríamos ya extraer la imagen squashfs a nuestro equipo, y a priori modificarla como nos diese en gana, volver a crear la imagen squashfs y ver como poder volver a montar la imagen de actualización con todo sin romper nada.

 A partir de aquí, tendríamos el trabajo farragoso. Es necesario comprender las cabeceras, el contenido tan sólo es lo sencillo. Diseccionar las cabeceras es un trabajo más meticuloso y estar haciendo comprobaciones, sumas, cuentas, mirar binarios del router en busca de más información… es tedioso. En mi caso empiezo siempre desde el comienzo, identifico lo que parecen ser los “Magic Number”, cadenas de texto descriptivas que pueden indicar versiones, conjuntos de bytes que indiquen tamaños y desplazamientos, checksums… en definitiva, lo que se puede esperar de cualquier cabecera. Diseccionar totalmente la cabecera (las dos que hay) fue lo que más tiempo me llevó. Os desgloso lo que sería la estructura integral de la firmware, incluyendo por supuesto la estructura de su cabecera. Digamos que la imagen de actualización se compone de tres “partes”. La cabecera, la firmware en sí (compuesta de kernel+rootfs/sistema_archivos) y el archivo de configuración:

0x00000000 Header
    0x0000 Cabecera “Magic Number” 04 D0 FC 9C
    0x0004 chipID = “36 33 33 36 38 00 00 00” = 63368 (8Bytes)
    0x000C Padding (16 Bytes)
    0x001C ModelID = 5A596004 (4Bytes)
    0x0020 Tamaño total archivo .bin, incluído cabeceras (4Bytes)
    0x0024 Offset en Memoria rootfs (0x40000 + offset bin) | 0x40000 = Bootloader 0x20000 + romfile 0x20000
    0x0028 Tamaño Rootfs (4Bytes)
    0x00CC Offset en Memoria Kernel
    0x0030 Tamaño Kernel (4Bytes)
    0x0034 Offset en Memoria cfgfile
    0x0038 Tamaño cfgfile (4Bytes)
    0x003C ¿Magic Number?? 01 00
    0x003E Tipo de imagen | main (0x0003),  esclava (0x0002), bin de actualización (0x0001)
    0x0040 Versión Firmware (32Bytes)
    0x0060 Descripción Firmware (32Bytes)
    0x0080 Checksum Rootfs (4Bytes)
    0x0084 Checksum Kernel (4Bytes)
    0x0088 Checksum cfgfile (4Bytes)
    0x008C Padding

0x00000100 Firmware
    0x00000000 Header
        0x000 Cabecera “Magic Number” 32 52 44 48 (4Bytes)
        0x004 Tamaño de cabecera (4 Bytes)
        0x008 Tamaño de la “Firmware” incluyendo su cabecera
        0x00C checksum SquashFS, las particiones _main no llevan CRC, la firm no lo computa en cualquier caso.
        0x010 versión de 2rdh?? Termina con salto de linea (32Bytes)
        0x030 “Salto de linea”/padding (32Bytes)
        0x050 Offset squashfs/tamaño kernel (4Bytes)
        0x053 Tamaño squashfs (4Bytes)
        0x058 Padding
        
    0x00000100 Kernel, lzma
    0x0014e6e3 rootfs Squashfs 4.0 lzma | Sistema de archivos

0x011d27d6 Configuración romfile
    0x0000 Header
    0x0028 romfile comprimido.  ¿Algoritmo fastlz?

 

 Modificación/Creación de una firmware nueva

Bien, teniendo toda la estructura de la imagen de actualización, debería de ser trivial realizar cualquier cambio (añadir, eliminar, modificar) dentro de la firmware. Con linux tan sólo necesitaremos tener las herramientas para crear y extraer squashfs, teniendo en cuenta que la imagen original fue creada en SquashFS 4.0+, usando la compresión LZMA. Esto significa que si no usaron un SquasFS modificado tuvieron que usar SquasFS 4.1, 4.2 o 4.3, ya que hasta la versión 4.1 no se dio soporte oficial a LZMA. Yo lo he realizado todo con SquasFS 4.3, usando como compresor LMZA el SDK de 7zip. Es necesario eso sí, modificar el makefile para habilitar lzma.

Extraída la imagen en nuestro equipo y modificada a voluntad (o añadido los archivos/paquetes que deseemos…) volvemos a empaquetar nuestra imagen squashFS. De nuevo, recordemos que debemos de usar LZMA y realizar la creación sin el padding a 4K. Llegados a este punto, como tenemos toda la estructura de como tiene que la estructura de la imagen de actualización, tan sólo tenemos que realizar el proceso inverso y corregir todas las cabeceras que sean necesarias. Sería muy sencillo crear una pequeña utilidad que pasándole la imagen modificada, el kernel y el archivo de configuración nos crease el archivo final de actualización con todas las cabeceras corregidas. Pero ni he tenido tiempo ni tengo ganas de hacerlo. Así que sigamos.

Con la imagen SquashFS ya modificada, podemos empezar a empaquetar nuestra nueva imagen de actualización. Por suerte para nosotros, la cabecera de la sección perteneciente al kernel+rootfs no se verifica en ningún momento, y aunque podemos por supuesto calcularla, no es necesario ser muy rigurosos. La parte más tediosa es el cálculo del checksum, así que podemos establecerlo tan ricamente como “00 00 00 00” y no pasa nada.

Añadimos al final de la imagen squashfs el archivo de configuración previamente extraído de la imagen inicial. Añadimos encima de este el kernel, y encima del kernel la cabecera secundaria. No es necesario, pero por tener un mínimo de decencia corregimos en esta el tamaño de la “firmware” (que es el tamaño de la cabecera secundaria+kernel+squashFS), el checksum no nos complicamos y lo dejamos en 00 00 00 00, el offset de squashfs no ha cambiado con lo que lo dejamos igual y modificamos el nuevo tamaño que tiene nuesetra imagen squashfs (ahora sí, tan sólo el tamaño de nuestro squashfs modificado)

Por último queda realmente lo que es más delicado, que es reconstruir realmente la cabecera que va a judgar si nuestra firmware es válida, por no decir que si metemos la pata siempre podemos bloquear e inutilizar el router, así que cuidado aquí. Los valores a modificar en realidad son pocos, si tan sólo hemos tocado el sistema de archivos:

    0x0020 Tamaño total archivo .bin -> Es necesario modificarlo porque el tamaño de nuestro squashFS será diferente
    0x0028 Tamaño Rootfs -> El valor es el mismo que se puso en la cabecera secundaria, y hay que modificarlo por lo mismo que el anterior
    0x0034 Offset en Memoria cfgfile -> Al cambiar el tamaño del rootfs, el offset del archivo de configuración cambia. Recordemos que hay que sumar siempre 0x40000
    0x0080 Checksum Rootfs (4Bytes) -> Que checksum??

Bien, tenemos todo menos el checksum de rootfs, el resto son los mismos porque no hemos realizado ninguna modificación. La pregunta del millón es como diablos calcula Mitrastar este valor, puesto que ha podido usar cualquier técnica conocida o desconocida. La mala noticia es que usa un algoritmo propio para calcularlo, la buena noticia es que ya lo tengo recreado, y la mejor noticia es que incluso nos podemos ahorrar su cálculo si sabemos donde mirar (una pena que descubriese esto último más tarde, pero al menos tengo igualmente el algoritmo.

El checksum usado por Mitrastar es una modificación al conocido CRC32, usando una lockup table para agilizar los cálculos, y podemos encontrarlo en el binario cfg_manager. Se puede buscar la función y decompilarla. Es necesario este valor porque el bootloader y el propio cfg_manager comprobarán dicho valor, y si no corresponde al que ellos calculan, el router rechazará dicha imagen. No sólo se usa este checksumo para verificar la firmware, igualmente se verifican tamaños y otros, pero ya hemos dado por supuesto que la cabecera la hemos calculado bien.

Bien, he dicho que aunque tengo creado el algoritmo para calcular el crc32 modificado no es necesario. Esto es porque por suerte para nosotros ya lo calcula el cfg_manager por nosotros. Cuando actualizamos el router (o lo intentamos), justo antes de que este se reinicie (sea la firmware válida o no) escupe en la consola de registro los cálculos pertinentes, sacando por pantalla los checksum calculados y los que tenemos en nuestra firmware. Dicho de otro modo… si actualizamos aun con la cabecera con los checksum incorrectos, y mientras esta el proceso miramos el registro con dmesg, obtendremos algo como esto:

***** MitraStar Confidential Firmware *****
compressedLen = 25194
pTag->kernelChksum = 11b8cc8b
pTag->rootfsChksum = da3878fa
pTag->defcfgChksum = 35842e0b
cal kernelChksum = 11b8cc8b
cal rootfsChksum = da3878fa
cal defcfgChksum = 35842e0b

pTag->modelId = 5a596004
pTag->chipId = 63368
len = 011d8a68
mrd->modelId = 5a596004
mrd->chipId = 63368

Update slave image version

Ready to flash image…

Si los checksum calculados no se corresponden a los nuestros, el proceso fallará, pero podremos anotar el crc calculado, modificar los nuestros para que correspondan y volver a actualizar. Eso le quita a cualquiera tener que decompilar el código en cfg_manager, extraer el algoritmo de verificación y recrearlo en C o en el lenguaje que le guste. Por supuesto el echo de que se calcule el CRC no hay que verlo sólo como para impedir que se realicen modificaciones, sino para garantizar la integridad de estas y evitar una mala actualización.

Si todo ha ido bien, el cfg_manager copiará la imagen de actualización a 4 particiones esclavas, mtd6-9, cada una con su contenido. Al reiniciar el router, el bootloader realizará comprobaciones similares a las realizadas por cfg_manager, y si todo es correcto procederá a copiar las particiones esclavas mtd6-9 a las principales mtd2-5. Si el router se reiniciase (funcionando) sin aparentemente ningún cambio efectuado, posiblemente el bootloader encontró algún problema en la firmware modificada y anuló la copia a las particiones principales, con lo que habría que ver el problema, solucionarlo y volver a cargarla.

Si todo ha sido correcto, llegados a este punto, tendríamos nuestra propia firmware modificada con lo que necesitásemos, ya fuesen arreglos de los problemas que tiene la firmware oficial o nuestros propios añadidos.

Recordemos que dije que no es necesario tener una imagen de actualización. Podemos extraerla a partir de las particiones mtd5 o mtd9, tan sólo con una apreciación: Las particiones mtd5 y 9 estarán posiblemente padeadas para rellenar el resto del erasesize, con lo que hay que eliminar dicho bloque. Por otro lado hay que modificar un byte en la cabecera que especifica el “tipo de partición”. El archivo de actualización tiene que estar en 01, no en 02 o 03. Quitando estos dos cambios, el resultado será una copia 1:1 (exacta) del archivo de actualización original. No es mal truco después de todo.

 

¿Instalación/Actualización de componentes y otros paquetes?

Ahora mismo no he añadido ningún componente extra, pero es más que factible. Hay que tener en cuenta que el router usa una arquitectura MIPS, y que tendríamos que recompilar cualquier paquete o binario para esta arquitectura. Aquí la idea he de decir que no fue mía y me llegó leyendo a un blogero en algún lado, y es que el router usa uClibc como motor, y el proyecto uClibc posee por suerte para nosotros imágenes listas para iniciar desde linux en las que podremos tener las herramientas necesarias para compilar el códígo y paquetes que deseemos, y una vez realizado sacarlo de ahí y meterlo en nuestra firmware modificada:

http://www.uclibc.org/downloads/binaries/0.9.30/


 

Conclusión

Bien, creo que eso ha sido todo. Sin duda alguna un buen entretenimiento del que siempre se aprende, y yo el primero. Quizás lo más útil en este caso no es instalar paquetes o actualizar otros (al menos en principio), pero puede que sí lo sea el poder realizar pequeños cambios aquí y allá, instalar algunos binarios extras como tcpdump, aplicar configuraciones específicas, filtros… tenemos espacio en memoria de sobra a fin de cuenta, y posiblemente tardemos nosotros mismos menos tiempo en corregir algunos de los problemas de la firmware, que esperar que Mitrastar los arregle por nosotros y que Movistar la distribuya.

Por ejemplo, para corregir el problema de la batería de los ARP en la B21, bastaría en principio con hacer el siguiente cambio permanente:

echo 0 > /proc/sys/net/ipv4/neigh/br0/mcast_solicit

Aunque como digo, tan solo es un ejemplo más…

Evento de Google del 24 Julio: Nuevo Nexus 7, Android 4.3 y Nuevo dispositivo ChromeCast

Share on Google+Share on FacebookTweet about this on Twitter

El Google IO 2013 dejó claro que iba a ser orientado casi en su totalidad para los desarrolladores, y quitando Play Services no se anunció ningún producto ni actualización de los ya existentes. Quizás el motivo fuese que este año el Google IO se celebró casi un par de meses antes que el año pasado. Dicho así, era lógico pensar como dijimos muchos que Google lanzaría novedades en Julio, y así han sido. Fundamentalmente han sido 3 novedades en las que se ha centrado toda la conferencia: El nuevo Nexus 7, Android 4.3 y como sorpresa ha sido un dispositivo que han bautizado como “ChromeCast”.

Por supuesto, Google a aprovechado para recordar que las ventas de este último año de Android son superiores al doble del año pasado, que el dinero que se ha pagado a los programadores de aplicaciones estos últimos meses es de 2.5 veces superior al año pasado. Realmente no son números para obviar.

 

Nexus 7

Hace un año Google presentó el que sería el primer Tablet con su sello, el N7. A día de hoy ha resultado ser un éxito indiscutible, un hardware más que capaz a un precio que la competencia podía siquiera acercarse. Un año más tarde, era evidente que Google tenía que mejorarlo… y así ha sido.

-Mismo tamaño, 7,02 Pulgadas, pero no obstante se pone a dieta, ahora es ligeramente más estrecho (conservando el mismo tamaño de pantalla), un pelín mas alto, pero sobre todo más delgado y pesando menos.

-Pantalla FullHD! Si el N7 original ya tenía una gran pantalla HD Ready de 1280×800 con 216ppp, han dado un salto significativo al emplear una pantalla FullHD de 1920×1200, con 323 ppp. Es interesante anotar que Apple llamó originalmente “Pantallas Retinas” a cualquier pantalla con una densidad superior de 300 ppp porque según ellos el ojo humano no era capaz de percibir algo mejor. El iPad 4 actual, llamado retina, posee una densidad de 264 ppp (lo que estrictamente según la definición que Apple daba a sus pantallas Retina, no es Retina). Bien, pues como digo el nuevo N7 tendría una densidad de 323 ppp (El N10 actual posee 300 ppp).

-Incorporación de cámara trasera de 5MP: Muchos se quejaron inicialmente por no poseer una cámara trasera (yo personalmente es algo de lo que podría prescindir, quiero una cámara frontal para videoconferencia, pero no voy a ir haciendo fotos con un tablet). Aun así han implementado una cámara de 5MP traseras para completar aun más el dispositivo.

-CPU/GPU: También se ha modificado el Procesador, y se ha implementado el mismo que usa actualmente el Nexus 4, un SnapDragon Pro 8086 de 4 núcleos a 1.5 GHz, frontera con los Cortex-A15. Según afirma Google, el procesador sería aproximadamente un 50% superior a su predecesor, y hasta un 150% superior que su predecesor gráficamente, en conjunción de Adreno 320. Es decir, que no solo de pantalla vive el hombre. Esto es totalmente lógico. Muchas veces se olvida que el poseer una pantalla con mayor resolución implica tener que trabajar el procesador y la GPU mucho más. No es el caso, pero muchas veces incluso aun aumentando el procesador y la GPU un producto nuevo puede ser más lento que su antecesor por tener una pantalla superior.

-Batería: No tengo los datos de capacidad de la batería actualmente, creo qeu es la misma que su antecesor, pero han mejorado el consumo. Según claman, es capaz de estar reproduciendo sin parar durante 9 horas seguidas contenido en HD.

 -Por último, posee conector HDMI para su conexión a la televisión.

Si lo comparásemos actualmente con el iPad Mini, esto es lo que tendríamos:

Nexus7

El Nexus 7 anterior, que salio a la venta 6 meses antes que el actual iPad Mini, ya era superior al iPad Mini, con lo que es evidente decir que el actual Nexus 7 es muy superior al iPad Mini actual, y posiblemente lo sea al iPad Mini nuevo que saque Apple este año (si lo saca). Lo Cuadriplica en RAM, lo duplica (que se dice pronto) en densidad de píxeles!! Si pusiésemos una foto de calidad en ambos dispositivos, la calidad de la imagen en el iPad mini sería de chiste en comparación. Repito, es evidente que el iPad Mini actual tiene ya algo más de 6 meses y habrá que esperar al nuevo para realizar otra comparación más, aunque en ese caso será el iPad mini el que lleve una ventaja de 6 meses.

 

Android 4.3

Google está tardando en lanzar su Android 5.0 (Lime Pie), es posible que para que la gran mayoría de dispositivos Android estén usando JellyBean, y lo cierto es que a día de hoy ya se ha confirmado que JellyBean posee una penetración superior a GingerBread, que ostentaba el mayor uso. Eso no quiere decir que Google esté parado, y estoy seguro que Android 5.0 está más que avanzada y casi preparada, y todo el tiempo de más que se le de será para mejorarla aun más. Mientras tanto, mientras que eso ocurre (supongo que se lanzará en Noviembre), Google ha añadido algunas mejoras en Android 4.3, sin realizar cambios demasiado dramáticos. De echo para el usuario final, no notará prácticamente nada nuevo, que no quiere decir que no las use sin saberlo o que no se beneficie de las mejoras.

Google Play Game App: En realidad no forma parte de Android 4.3, pero si de android, y está disponible para todos. Es la aplicación de Google que hará de hub par alos juegos, para centralizar de este modo los progresos de ellos, tablones de puntos, logros… cualquiera puede descargarla si lo desea desde ya.

– Control de permisos para Tablets con múltiples usuarios: Recordemos que Android en las tablets posee (tiene la opción) de tener diferentes perfiles de usuarios desde hace tiempo. Así por ejemplo dos personas podrían tener sus configuraciones totalmente diferentes. Bien, la gran novedad es que podrá existir lo que llamaríamos un “Administrador” que podrá definir el control de acceso y permisos que tendrá otro usuario. Así por ejemplo, no solo podrá definir a que aplicaciones tendrá acceso o no el otro usuario, sino que incluso podrá definir algunos permisos por aplicación incluso. Esto evidentemente está enfocado para tablets como el N7 orientadas a un público más juvenil. Básicamente, estoy viendo al Padre impidiendo que el hijo acceda a juegos que el si puede, películas que el padre no quiere que vea… o simplemente facilitarle el uso al pequeño quitandole todo aquello que él no entendería.

-Soporte para Bluetooth 4.0 Smart, un tipo de dispositivos Bluetooth de muy bajo consumo, generalmente dispositivos biométricos que envían constantemente datos a nuestro dispositivo Android. Básicamente aquellos dispositivos que sean compatibles con BT Smart tendrán un consumo energético mínimo.

-Perfil de Bluetooth AVRCP en su stack de BlueTooth, lo cual permite el control remoto de video y audio por Bluetooth en dispositivos compatibles.

-Soporte para OpenGL ES 3.0: Es otra de esas grandes novedades que solo los programadores apreciarán, y es una sorpresa. OpenGL es junto DirectX las API gráficas más comunes que existen en el mundo. DirectX solo es para Windows por supuesto, mientras que OpenGL posee un soporte completo tanto en Windows,  móviles, Linux, OSX, iOS… OpenGL ES epor otro lado es por así decirlo la adaptación de la API OpenGL en dispositivos portátiles, es un subconjunto de OpenGL.  OpenGL ES 3.0 es la versión más actual, y no hace falta siquiera decir que ni iOS ni Windows Phone son compatibles, incluso el nuevo iOS 7 que aun no ha salido, tan solo es compatible con OpenGL ES 2.0, que es lo que usan el 99% de todos sus juegos. ¿Esto que implica? Implica mejores efectos y realismo en juegos, más facilidad a la hora de programar y mayor rendimiento en cualquier aplicación que haga uso de OpenGL.

-APIs para DRM: En realidad Google lo ha tenido bien organizado todo, y con el lanzamiento del nuevo Nexus 7 con pantalla 1080p y el nuevo dispositivo que hablaremos más adelante, se ve que implementar medidas DRM para películas sobre todo era casi una obligación, que por cierto seguro les ha hecho poner proveedores de películas como Netflix.
 
-Mejoras en la introducción de teclado, posiblemente alguna versión nueva de su teclado para Android, me pregunto si habrán dado ya acceso al selector de temas del teclado que sabemos ya incorpora desde hace tiempo.
-Mayor rapidez en el cambio rápido de usuario (para tablets multiusuarios)
 
-Autocompletado al marcar un número. La mayoría de todos los dialers que traen por defecto los dispositivos Android de los fabricantes poseen este tipo de dialers, en los que puedes llamar escribiendo el nombre o empezando a poner el teléfono. Por fin Google lo implementa, espero que permita también la búsqueda por nombre.
 
-Mejora de la localización WIFI en segundo plano… lo cierto es que no sé exactamente que se han referido con esto, habrá que diseccionar el código fuente y ver los cambios reales al respecto.
 
-Incorporación del hebreo y el árabe (idiomas de escritira inversa) y otros idiomas.
 
En realidad no son cambios de calado, pero si desde luego Google quiere cubrir algunos puntos más deficitarios en su Nexus 7, e incorporar mejoras significativas a los programadores. El precio en cambio es ligeramente superior. En realidad era algo que se veía venir, Google lo iba a tener realmente complicado mejorar los 200€ que costaba el Nexus 7 anterior. Aun así se ha acercado bastante, teniendo en cuenta que en cuanto a hardware hay un gran cambio significativo, posiblemente solo la pantalla ya fuese suficiente para entender ese precio adicional.
 
La OTA para Nexus 4, Nexus 7, Nexus 10 y Galaxy Nexus está ya circulando, así como las imágenes completas de todos ellos en el centro de siempre
De igual modo, los repositorios oficiales AOSP de Google están también terminando de ser rebasados con Android 4.3, lo que significa que cualquier ROM personalizada basada en AOSP será actualizada en los próximos dias (seguramente claro, y siempre que así lo deseen)
 
 

ChromeCast

El invitado especial en esta ocasión ha sido ChromeCast. El año pasado vimos en el lanzamiento del Nexus 7 el novedoso e ingenioso Nexus Q, un dispositivo ciertamente interesante, pero lo cierto es que era extremadamente caro para lo que ofrecía, y aunque su potencial era realmente importante, fue un, podemos llamarlo así y sin paños menores, fracaso. Tampoco hay que olvidar que el Nexus Q ni siquiera llego a estar a la venta masiva, y fue presentado más que nada como un experimento.

12 meses después, Nexus Q es historia. No obstante Google entendió lo bueno que podía resultar Nexus Q en muchas ocasiones, así que tomó lo bueno de Nexus Q, añadió algunas ideas más y busco la forma en la que poder poner todo ello en un dispositivo que merezca la pena comprar (caro o no). Y es evidente que así es como ha nacido ChromeCast.

Técnicamente hablando, ¿que es ChromeCast?

chromecast

Eso es ChromeCast. ES un dispositivo de 5 centímetros similar a un simple PenDrive, con una salvedad que lo hace diferente:

-Funciones de Adaptador WIFI
-Salida HDMI
-Versión de Chrome OS en su interior minimalista y personalizada
-Cuesta 35$

Que tenemos si juntamos todo ello? Es sencillo, un dispositivo que puede conectarse virtualmente a cualquier televisor por HDMI y a la par a nuestra conexión WIFI. ¿Y que hace? Básicamente permite “enviar” contenido de CUALQUIER DISPOSITIVO con independencia de la plataforma usada a la tele. Es decir, es compatible tanto con Android como con iOS como con equipos de sobremesa con Chrome.

De este modo, los usuarios pueden por ejemplo entrar en YouTube en su tablet/movil/PC y simplemente dándole a un botón en su aplicación de YouTube y el contenido empezará a reproducirse en HD en la televisión. Algo tan sencillo en concepto pero que sin duda alguna muchos hemos querido hacer mas de una y mas de dos veces. Todo ello sin configuración alguna de nada, simplemente tener conectado el dispositivo a la tele y conectado a nuestra red. Google ha anunciado que actualmente, ChromeCast permite la “recepción” de contenido desde YouTube, Google Movies, Google Music (música también), Google+ Photos, Chrome, Pandora, Netflix… y por supuesto Google asegura que muchos mas están en camino.

Al anunciar conjuntamente el SDK para ChromeCast, nos permite pensar que en realidad cualquier aplicación actual como reproductores de audio o vídeo e incluso juegos, podrían usar esta tecnología en un momento dado. Habrá que ver las limitaciones del servicio.

ChromeCast además funciona usando los servicios en nube de Google. De echo si mandas un vídeo a la tele desde el tablet, y añadir a la cola de reproducción 10 videos más, puedes irte de casa si lo deseas que la tele no tendrá problema en su reproducción. Es más, si cualquier usuario llega a casa podrá controlar inmediatamente la reproducción actual. Esto es aplicable a películas o a cualquier otra cosa, evidentemente no hay que ser muy listo para pensar que el contenido no se envía realmente de un dispositivo a otro en estos casos, sino que es la tele quien por la conexión WIFI De ChromeCast accede a dicho contenido y lo reproduce. Si puede realmente también recibir datos directamente desde otros dispositivos, esto podría hacer de ChromeCast algo muy muy jugoso.

Lo más importante quizás, y lo que realmente ha sorprendido a muchos y ha hecho que ahora mismo ChromeCast esté totalmente agotado, es el precio. Nexus Q era bonito, genial en esencia e idas pero extremadamente costoso para lo que ofrecía. En este caso, ChromeCast cuesta 35 dólares. aun cuando hiciésemos un cambio de 1:1, 35€ es algo que realmente cualquiera en un momento dado puede permitirse, teniendo en cuenta sobre todo cuando les cuesta su pantalla de televisión. Y por 35€ lo que te llevas es algo totalmente portable, útil, ingenioso… Personalmente es evidente que aunque por ahora tan solo se ha lanzado en EEUU, ya me las ingeniaré para tener el mío. Creo sinceramente que en este caso merece la pena.

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.

Comparativa Navegadores 2012/Q2: Internet Explorer 10, Firefox 20.0, Chrome 25.0, Safari 6, Opera 12.12

Share on Google+Share on FacebookTweet about this on Twitter

Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Aunque hayan pasado más de 6 meses, no podía faltar una nueva entrega, sobre todo teniendo en cuenta que no hace mucho Windows 8 fue oficialmente lanzado, y con él por tanto la versión final de Internet Explorer 10. La razón por la cual siempre hago mis comparativas con las versiones aun en desarrollo la he dicho siempre y siguen siendo las mismas, y me limito a hacer prácticamente un Copy/Paste de la comparativa anterior:

a) Chrome y Firefox poseen ciclos de actualizaciones muy rápidos, haciendo por tanto que estos siempre tengan ventajas ante otro tipo de comparativas que los enfrenten ante navegadores con ciclos de actualizaciones más largos como Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas versiones en desarrollo de cada navegador nos permite ser más imparciales. Incluso Microsoft está empezando a lanzar cada cierto tiempo versiones preview.

b) Los amantes del software (geeks y nerds entre otros) siempre deseamos probar y tener a mano lo último que se está cociendo, cambios que verán la luz de forma oficial para todo el público dentro de quizás unas semanas, unos meses o incluso un año. Por tanto es también una buena oportunidad para probar no lo que hay sino lo que tendremos.

 

Por tanto como es costumbre, tanto Firefox como Chrome se han tomando sus respectivas versiones Nighly. Opera no lanza versiones Nighly, pero sí prácticamente  todas las semanas, al igual que Safari. Las versiones de todos ellos se han especificado anteriormente. Para Internet Explorer se ha usado la versión más actual a la que tenemos acceso, que aunque no es una versión en desarrollo, no olvidemos que su lanzamiento oficial conjuntamente a Windows 8 hace tan solo unos días, puesto que por desgracia no tenemos acceso a versiones betas o alpha.

Como siempre, las versiones de 64 bits de Opera, Internet Explorer y Firefox NO CONTARÁN en el tanteo final, y tan solo tendrán un valor presencial en las comparaciones pertinentes, exceptuando en las de compatibilidades con estándares puesto sus resultados serían supuestamente los mismos. Esto es necesario debido a que lamentablemente aun no tenemos disponible versiones de 64 bits de Chrome o de Safari. Hay que anotar que aunque Windows 8 x64 incorpora tanto una versión de 32bits como de 64bits, el navegador siempre ejecutará una instancia en 64bits que tomará el rol de la interfaz, mientras que ejecutará el contenido de las pestañas en instancias separadas, de 32bits si se ejecuta en modo estándar Internet Explorer, o en el modo “puro” de 64 bits si se habilita las funciones de “Modo protegido Avanzado”. En las pruebas de 32 bits se usa el modo mixto (la interfaz siempre se ejecuta con instancias de 64 bits), en las de 64 bits se activa el modo protegido avanzado y todo se ejecuta en 64bits.

Por quinta (y posiblemente última vez), la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces, esto hace que pierda muchos aspectos de compatibilidad. Las razones son las que he dado siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar siempre los navegadores, no sus complementos. De lo contrario, por esa regla de tres, podríamos instalar diferentes plugins o extensiones a otros navegadores para dotarlos de más características o mejoras. Sería evidentemente injusto. Apple es la que no debería de asociar un reproductor multimedia a su navegador.

Por otro lado, posiblemente esta sea la última vez que veamos Safari en estas comparativas. Es muy simple. Aunque Apple no ha hecho hasta la fecha ningún comunicado al respecto, lo cierto es que desde hace ya meses Apple ha eliminado de su web todo comentario, enlace, propaganda… hacia Safari para Windows. Esto no es algo a extrañar realmente, si tenemos en cuenta que el índice de mercado que posee Safari en Windows es prácticamente nulo, e incluso en MAC OS ha dejado de ser la opción predominante. Actualmente se siguen generando no obstante Nighlys casi a diario de Safari para Windows desde el proyecto WebKit, lo cual por tanto no debería de ser un problema continuar dando soporte a este navegador en mis comparativas, pero lo cierto es que estas Build no funcionan de forma totalmente independiente, sino que dependen básicamente de toda la interfaz de Safari y otros. Sin el debido soporte de Safari para Windows, estas versiones serán posiblemente cada vez más inestables, y será cuestión de tiempo que dejen siquiera de generarse. En esta ocasión no han existido mayores problemas, y aunque la build se referencia como Safari 5.2 no hay que engañarse, y os aseguro que se ha usado el código más reciente que posee Safari. Por tanto aunque a efectos teóricos se base sobre Safari 5.2, se estará probando Safari 6+

Por último, respondiendo a algunos comentarios y sugerencias de otras veces, la razón por la cual no se incluyen en la comparativa otros sistemas operativos es muy simple. Si quieres hacer una comparativa que sea mínimamente rigurosa tienes que intentar eliminar todas las variables que sean externas a los navegadores. En una comparativa puedes medir al mismo tiempo una sola variable, no dos. Si introdujésemos en esta comparativa resultados provenientes de Linux por ejemplo, además de tener disponibles menos navegadores no podríamos comparar los resultados obtenidos en Windows con los obtenidos en Linux, no tendrían validez alguna puesto que el sistema operativo sería siempre una variable constante. Es como si queremos comparar el rendimiento de una CPU, y para ello tenemos dos equipos totalmente iguales en el que en uno ejecutamos el programa A y en el otro el programa B para medir el rendimiento. Evidentemente ese test no tiene sentido alguno ya que se está midiendo algo de dos formas diferentes. Siempre que sea posible hay que hacer el esfuerzo de no alterar las condiciones, y es por ello que es necesario realizarlo tan solo sobre un solo OS. Sí, se podría hacer la misma comparativa sobre Linux y ver los resultados, y podríamos llegar a conclusiones similares incluso, pero serían solo válidas para ese OS. Dado que Windows posee una cuota de mercado que roza el 90%, es evidente el motivo de por qué se usa este Sistema Operativo.

 

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 8 Enterprise x64
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 310.61)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11.5.502 (Firefox, Opera y Safari), 11.3.376.12 (Internet Explorer 7), 11.5.31.106 (Chrome)

 

Como es costumbre, todos los navegadores son instalados de forma limpia en el mismo equipo, usando para ellos como es de esperar perfiles nuevos, tocando mínimamente las opciones de configuración de los navegadores, como pueda ser la página de inicio, la deshabilitación de la carga selectiva progresiva de pestañas, la activación de aceleración por Hardware y WebGL en Opera y poco más. Esto último es debido a que Opera aun no está entregando su navegador con dicho soporte activado, aunque pueda parecer algo de “trampas” se tomará en cuenta también a la hora de evaluar el navegador.

Tan solo se ha instalado como complementos Adobe Flash Player en todos los navegadores y el complemento para WebM de Internet Explorer. El uso de Flash Player es evidente, necesario para algunos test en los que se desea probar el rendimiento Flash en diferentes navegadores y circunstancias, pero también para compararlo con las funciones nativas de vídeo en HTML5. La instalación por otro lado de WebM en Internet Explorer 10 tiene también su lógica. El futuro HTML5 especifica que los navegadores puedan reproducir vídeo sin necesidad de complementos, pero no estandariza que codecs para hacerlo. Opera, Firefox o Chrome soportan todos ellos el estándar propuesto por Google WebM, mientras que Microsoft y Apple apuestan (al menos por ahora) tan solo por H264. Guerras a parte, la idea no es comparar H264 frente a WebM, sino medir el rendimiento de la tecnología de vídeo para HTML5 y compararla a la tecnología de vídeo de Flash. Todos ellos (excepto Safari) soportan de un modo u otro esta tecnología sin ningún tipo de complemento, por tanto el requerimiento mínimo lo cumplen. Ahora bien, como deseamos medir el rendimiento es necesario que TODOS usen la misma tecnología. Por suerte además, existe un complemento oficial del proyecto WebM para IE, con lo que de este modo podemos hacer uso de la tecnología de vídeo WebM de HTML5 en todos los navegadores por igual, excepto como digo Safari, que queda fuera por la sencilla razón que ni siquiera (fuera de la caja) es compatible sin QuickTime. Si Safari fuese compatible al menos con WebM o HTML5 sin necesidad de QuickTime aun podríamos pensar en incluirlo, pero de lo contrario debe de quedar fuera.

 

Cada test se ejecuta 10 veces en cada navegador. Dado que hay test que son muy dependientes a las condiciones externas (y por tanto capaces de generar resultados extraños), el valor final de cada prueba se ha obtenido calculando la media aritmética de los valores registrados un UNA VEZ han sido descartados los valores “extraños” estadísticamente (por medio de la “Distribución Normal”). De este modo se intenta que los datos obtenidos sean lo más fiables posible, sobre todo como he dicho en aquellos test en los que simplemente una pequeña interferencia en el PC como un acceso a disco por algún proceso de fondo, es suficiente para modificar por completo un resultado.

Cada prueba puntúa de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarse por carencias de este o simplemente produzca un fallo del navegador y sea incapaz de terminar la prueba. En caso de que dos navegadores obtengan el mismo resultado, a los dos se le asignará la misma puntuación, dejando la puntuación restante simplemente sin asignar. Dado que son versiones inestables (al menos algunas ellas) se creará un último “test” que recogerá a modo de resultado la estabilidad del navegador frente a las diferentes pruebas.

 

 

Benchmarks

En esta ocasión no ha habido grandes cambios en los test usados. Si cabe destacar que de momento se ha eliminado de forma temporal el test de PeaceKeeper. La última actualización que hicieron provocó que fuese imposible acceder de forma simple a los resultados parciales, así como no ha sido actualizado algunos de los test que ejecuta a los últimos estándares, con lo que los resultados no son para nada exactos. En cuanto los solucionen, se volverá a incluir.

Las Webs usadas para el consumo de RAM en este caso, así como los tiempos de inicio en frío/caliente y cierre serán las siguientes:

Bandeja de Gmail, Bandeja de Mail Live (Outlook), La página personal de Facebook, La página personal de Google+, YouTube (http://www.youtube.com/watch?v=KEIdACFBhGE en 360p), Portada de “MARCA”, Portada de “El País”, Google Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser), eBay (http://www.ebay.com/fashion/womens-clothing). Para los test de 20 pestañas, simplemente se han duplicado las 10 anteriores.

 

Test:

  • Rendimiento
    • Tiempo de Inicio en frío (1, 10 y 20 pestañas)
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas)
    • Tiempo de Cierre (20 pestañas)
    • Velocidad de carga de Webs con/sin Caché
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM)

 

 

 

 

 

 

 

 

Tiempo de Inicio en Frío y en Caliente

Comenzamos con los tiempos de inicio del navegador para 1, 10 y 20 pestañas, siempre a caché vacío. Fundamentalmente, no se trata de medir la velocidad de carga de las páginas (que se verá más adelante), sino el tiempo de arranque y carga del navegador ante los 3 supuestos anteriores. Inicio en fío significa que el PC no tiene cacheado en RAM nada, generalmente se realiza ejecutando el navegador una vez el arranque del sistema se estabiliza y se ejecuta pro primera vez este, restaurando la sesión de forma automática (de 1, 10 o 20 pestañas). En esta ocasión no se ha recurrido al sistema de siempre de reiniciar el equipo para vaciar la RAM, sino una aproximación similar más consistente y más rápida. El inicio en Frío se hace para asegurarnos que no hay datos en RAM que puedan agilizar la carga del navegador, pero el propio sistema operativo hace esto de forma automática nada más arrancar, cacheando en RAM librerías y otros de programas que ejecutamos de forma habitual para que después se ejecuten estos de forma más veloz. A esto Microsoft lo llama por ejemplo “Superfetch”. Es decir, que los tiempos de inicio en frío de los navegadores en Windows dependen completamente de esta tecnología. Para evitar esto en lo posible se podría deshabilitar Superfetch (que desestabilizará en parte el sistema) u optar por una opción más simple y eficaz: Llenar la RAM.

El sistema después de un arranque en frío empieza a cachear algunos datos. Si además abrimos cualquier aplicación y la cerramos, una gran parte de la memoria se va llenando con datos antiguos que pueden ser usados a posteriori, esta es la razón por la cual abrir una aplicación la primera vez después de arrancar es más lenta que la segunda. Esto lo hace el sistema pero siempre que existan RAM para hacerlo, a fin de cuentas si el sistema posee RAM que no está usando de forma activa, ¿por qué no usarla para cachear datos? Una forma rápida y totalmente eficaz de inducir a un navegador o cualquier aplicación a un inicio en frío es simplemente colapsando la propia RAM del sistema, obligando a este a consumir todo ese espacio que se había reservado para el caché de las aplicaciones. Esto es fácil, tan solo hay que escribir una pequeña aplicación que nos permita reservar la cantidad de RAM que especifiquemos. Si dispongo de 6GB de RAM libres, de los cuales se usan 2 para caché (y contienen datos), si ejecuto mi aplicación y digo que reserve 6GB más, los 2GB reservados son consumidos, puesto que tiene preferencia la aplicación activa. Crear una aplicación para esto es muy simple, y gracias la propio administrador de tareas de Windows 8 podemos ver en todo momento no solo la RAM libre/consumida, sino también la RAM usada en cada momento en el cacheo de aplicaciones/procesos.

Resumiendo, Inicio en frio en esta ocasión se ha realizado consumiendo toda la RAM del sistema asignada para caché, liberando toda la RAM asignada a la aplicación de consumo (lo que asegura que no hay cacheado nada importante) y ejecutando el navegador. Después de comprar este sistema con el inicio en frío (reiniciar) de toda la vida, los resultados son bastantes consistentes, más exactos y además no requiere reiniciar el sistema.

Inicio en caliente implica por el contrario que el sistema ya ha abierto anteriormente el navegador y ha estado trabajando con él, y por tanto mantiene en RAM mucha de la carga anterior. El tiempo es medido desde que se ejecuta el navegador hasta que todas las pestañas han terminado de cargarse (que no quiere decir que todo el contenido en ellas se haya descargado):

 

[singlepic id=36 w=350 h=228 float=left][singlepic id=35 w=350 h=228 float=center]

  • Chrome: Falló en la carga de algunas pestañas, siendo necesario refrescarlas posteriormente (no se contabilizó ese tiempo extra)
  • Internet Explorer: Múltiples bloqueos y cierres en la carga

 

Tiempo de Cierre

Se ha medido el tiempo de respuesta del navegador a cerrar. En teoría podríamos pensar que estos tiempos son prácticamente inmediatos, pero no lo son. En muchas ocasiones el navegador se mantiene como proceso de fondo durante un largo período de tiempo, lo cual evidentemente no es deseable, sin contar con el consumo de RAM que mantiene. Los tiempos medidos son con 20 pestañas cargadas en los navegadores, contabilizando desde el momento en el que se envía la señal kill al proceso padre, hasta que el árbol de procesos de este es totalmente finalizado, incluyendo el proceso padre evidentemente. Es importante al hablar de proceso “padre” si tenemos en cuenta que navegadores como Chrome o Internet Explorer son multiprocesos, y cada proceso padre ejecuta uno o varios procesos hijos:

[singlepic id=31 w=700 h=456 float=center]

  • Internet Explorer: Grandes irregularidades al cerrearse, diferencias de tiempo…

 

Velocidad de Carga de la Web con y sin caché

Este test posee un doble propósito. Por un lado medir la velocidad con la que los navegadores son capaces de descargar por completo la Web desde los servidores externos, y por otro lado medir la eficiencia del Caché de estos, realizando el test con el caché del navegador activado y deshabilitado. Hay que tener en cuenta que lo que se mide no es el tiempo que tarda el navegador en comenzar a mostrar las páginas o cargarlas por completo, sino el tiempo que tarda el navegador en descargar y preparar TODOS los recursos de las web solicitadas. Es de esperar por tanto que los tiempos en las páginas con el contenido cacheado sea mucho menor. Cada Web (La de Facebook, la d PlayStore, la de Wikipedia y la de eBay) fue abierta de forma aislada y se sumaron los tiempos de todas ellas. Como medida y para la consistencia de los datos, se seguro que el tamaño total de la web era aproximadamente siempre el mismo, y las webs tomadas eran las que presentaban un menor contenido dinámico (invariante):

[singlepic id=30 w=700 h=456 float=center]

 

Consumo de RAM

A día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, pero no por ello hay que malgastarlo. Además, hay que entender que cada dato que es cargado en RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y los discos duros (ya sean SSD o convencionales) siguen siendo con diferencia el elemento más lento del equipo, con lo que esto es de vital importancia. El problema se acrecenta en dispositivos portátiles donde la RAM a veces no es tan “sobrante”, o cuando se está trabajando con otras aplicaciones más pesadas. Los datos mostrados corresponden a la memoria Privada usada por el/los procesos, eso quiere decir que no es exactamente el 100% de la memoria RAM ocupada, ya que no se incluyen pequeños “pedazos” adicionales como por ejemplo el mapeo de archivos adicionales como puedan ser las fuentes, archivos de configuración… No obstante, esta “Memoria Privada” supone una precisión de más del 95%, haciendo que sea más que suficiente para nuestros propósitos:

[singlepic id=42 w=700 h=456 float=center]

  • Safari: Múltiples cierres
  • Opera: Picos entorno al 16-20% de uso del procesador
  • Internet Explorer: Picos entorno al 40-50% dele procesador

 

Reproducción a 1080p

Es evidente que la reproducción de vídeo es crucial en los tiempos que corren en la web, un mundo que busca cada vez más el máximo rendimiento con el mínimo consumo posible, lo que alarga las baterías de los dispositivos portátiles también si tenemos en cuenta que la la reproducción de Vídeo continúa a día de hoy siendo uno de los mayores “comecome” de baterías… sin contar con que la gran mayoría del tráfico producido en inet es por estos. La comparativa es doble, ya que no solo compararemos la eficiencia en la reproducción de un vídeo Full HD a través de Flash, sino que también a través del estándar HTML5 vídeo, usando como sistema WebM. Así podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. Internet Explorer reproducirá WebM a través de un complemento como ya dijimos, más que nada porque IE10 oficialmente posee soporte para el estándar de vídeo de HTML5, lo único que ellos ofrecen de base tan solo el uso de H264 y no WebM. El vídeo reproducido en este caso es el mismo tanto en Flash a 1080 como en WebM a 1080 también, el trailer de “El Hobbit“, lo bueno de este vídeo es que está disponible en Full HD tanto en Flash, en WebM como en H264 (aunque este último no lo vamos a testear)

[singlepic id=50 w=700 h=456 float=center]

  • Opera: Saltos tanto en WebM como en Flash, posiblemente algún tipo de FrameSkip

 

SunSpider, V8 y Kraken

Son los 3 benchmarks más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. En los últimos meses Google ha lanzado otro test nuevo a fin de sustituir básicamente V8, llamado Octane. Me parecería injusto usar los dos de Google, por tanto he optado por usar por última vez V8, y en la siguiente será sustituido por Optane. No obstante, aunque los resultados no los publique, son muy similares a los obtenidos por V8, quedando todos los navegadores más o menos en la misa posición parcial.

Como ya he dicho en muchas ocasiones no soy fan de test sintéticos de ningún tipo, y mucho menos tests que han sido optimizados al máximo por todos los navegadores para obtener buenas puntuaciones. Estos 3 test se toman como estándar por todos los navegadores, lo que quiere decir que puedo asegurar que TODOS los navegadores hacen trampas en estos test según les convenga. No quiere decir que sean totalmente inútiles, ya que muchas optimizaciones son llevadas después a los entornos reales, pero por regla general no son demasiado fiables. Así es previsible que Google obtenga un resultado favorable además en V8, Firefox en Kraken y Safari en SunSpider, más que nada porque los test son suyos.

Más adelante veremos que el rendimiento JS en entornos reales (aplicaciones, código…) que a fin de cuenta son muy dependientes de JavaScript, los resultados son muchas veces totalmente dispares a los test sintéticos:

[singlepic id=46 w=350 h=228 float=left][singlepic id=49 w=350 h=228 float=center]

[singlepic id=37 w=350 h=228 float=center]

 

Normal Mapped, Canvas Performance, VII y Asteroids

HTML5 permite integrar dentro del navegador de forma simple contenidos complejos a través de canvas. Básicamente Canvas define un marco de ejecución de cierto contenido (generado principalmente por JavaScript). Es por ello que en realidad podría verse Canvas como la aplicación práctica del uso pesado de JavaScript. Esto ha permitido suprimir la necesidad de complementos para un gran sin fin de necesidades, con lo que tan solo con disponer de un navegador compatible podemos hacer correr la aplicación sin importar nada más… siempre que por supuesto el navegador sea capaz de ejecutar en tiempo real la aplicación correspondiente, lo cual como digo se fundamenta en JavaScript

Normal Mapped es un test que aunque es claramente gráfico posee una carga de está mínima, siendo el mayor aporte JS, y por ello queda relegado a este grupo de test. Por otro lado, Canvas Performance, es un benchmark muy interesante de cara a que trata de medir el rendimiento no de JavaScript en realidad, sino del contenido ejecutado en Canvas de forma sintética, al más puro estilo de los test sintéticos JavaScript. VII es una demo de un juego creado a modo de test para los navegadores que hace un uso bastante extenso no solo de JavaScript, en este caso de CSS, SVG y de la composición de capas. Asteroids por otro lado es un test ya conocido, con fuerte dependencia JavaScript:

[singlepic id=39 w=350 h=228 float=left][singlepic id=29 w=350 h=228 float=center]

[singlepic id=51 w=359 h=235 float=left][singlepic id=28 w=359 h=235 float=center]

  • Opera: En Canvas usa algún tipo de FrameSkip, lo cualmejora la puntuación pero produce saltos constantes

 

Tanque de peces (3.000 peces), Pecera (2.000 Peces)

Lo bueno de los peces, es que solo tenemos que añadir más al tanque o a la pecera para aumentar la complejidad. Se han mantenido los 3000 peces en el tanque y los 2000 en la pecera, aunque en esta última ya se ha alcanzado el tope por dos de los navegadores (se incrementará en la próxima). Dos Test similares pero diferentes, orientados ambos al rendimiento gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse de la aceleración hardware de contenido, por lo que es de esperar que Safari fracase estrepitosamente.

Todos los test con fuerte contenido gráfico acompañan igualmente la carga en la CPU y en la GPU, lo cual servirá además para comparar el consumo energético de cada navegador

[singlepic id=48 w=350 h=228 float=left][singlepic id=40 w=350 h=228 float=center]

 

“Come-Cocos” (Browse Hunt)

Un test bastante exigente en todos los aspectos, aunque está en la categoría de gráficos hace un uso extensivo de JS y SVG.  sin duda caprichoso y que prácticamente ningún navegador logra ejecutar de forma correcta, después de muchos meses ninguno es capaz de llegar a los 60 fps.

[singlepic id=32 w=700 h=456 float=center]

 

“Letras” (SpeedReading)

Uno de los mejores test para comprender la importancia de la aceleración gráfica dentro de los navegadores. Pasamos de los 6 segundos en finalizar el test a más de 2500 en el caso de Safari. Posiblemente sea también la última vez que lo veamos en acción, puesto que exceptuando Safari el resto de los navegadores logran “Pasarlo” correctamente, de 6 a 7 segundos no es algo que podamos… “valorar” en demasía.

[singlepic id=44 w=700 h=456 float=center]

 

Psicodélico

Otro test que se ha hecho muy extendido y famoso en toda la red por demostrar el potencial gráfico actual de los navegadores. Existen varias versiones de este test, pero al final siempre es lo mismo: Una imagen que gira sobre si misma a la máxima velocidad posible. A diferencia que el test anterior, es uno de los mejores test para ir comprobando la evolución y el perfeccionamiento del potencial gráfico del navegador:

[singlepic id=41 w=700 h=456 float=center]

 

Webvizbench

Aunque no deja de ser un benchmark, es uno de los mejores ejemplos de canvas compuesto, con una alta carga JavaScript, gráfica, CSS… explota al máximo desde transiciones, composición de capas, animaciones… es de los test más completos que veremos por aqui, y orientado siempre a aplicaciones prácticas que podrían/pueden crearse y que antes eran totalmente impensables. Uno de mis test favoritos:

[singlepic id=53 w=700 h=456 float=center]

 

Tanque de Peces (50.000) y Sistema Solar (4000 planetas), ambos para WebGL

De nuevo, dado que todos los navegadores exceptuando inexplicablemente Internet Explorer 10 y (previsiblemente) Safari soportan WebGL, es ya de obligado cumplimiento su testeo. En realidad Safari si cuenta en esencia con soporte para WebGL, pero este soporte es tan solo para MACOS, por tanto queda exlucído a última posición junto a IE10.

El caso de Microsoft de no dar soporte para WebGL fue explicado hace tiempo por ellos mismos, personalmente no comparto su visión pero es respetable. El problema nace de que puede ser “peligroso” que el navegador pueda tener acceso directo o indirecto al hardware del equipo, como es en este caso el adaptador de vídeo para poder hacer uso de webGL. Navegadores como Chrome, Firefox u Opera no es que no tengan en cuenta este tipo de “problemas de seguridad potenciales”, todo lo contrario, simplemente se centraron en solucionar esas deficiencias. Han pasado ya muchos meses desde que comenzamos a ver WebGL en los navegadores y sabemos por los reportes de seguridad que las primeras versiones que implementaban los navegadores eran como digo potencialmente peligrosas, ya que podría descubrirse (siempre hipotéticamente hablando) un exploit a través de WebGL que a su vez pudiese interactuar con el Driver de vídeo y por ende ejecutar código malicioso en modo Kernel (muy peligroso). Esto se ha ido solucionando con el tiempo, y a día de hoy se usan incluso extensiones de OpenGL específicas como pueda serlo GL_ARB_robustness para protegerse de este tipo de posibles problemas potenciales.

Esto no elimina totalmente el potencial peligro de WebGL, y técnicamente podría encontrarse alguna combinación de shaders,  texturas, geometrías… que desestabilizasen el sistema. En realidad no por un problema del navegador en sí, sino por el propio Driver de vídeo del sistema o una mezcla de ambas cosas. Es un riesgo mínimo y hay sistemas como digo para evitarlo (para empezar unos Drivers actualizados siempre ayuda). Por otro lado hay que destacar que aunque GL_ARB_robustness es una solución muy eficaz (y realmente funciona), es una extensión de OpenGL 3.2, lo que deja fuera prácticamente por diseño a cualquier navegador bajo MAC OS (el soporte de OpenGL bajo MACOS es de muy deficiente a pésimo) y a muchos adaptadores (sino todos) de AMD. Tan solo nVidia y bajo Windows se salvan en gran medida, con lo que se puede comprender en parte el miedo de Microsoft. Repito… hablamos hipotéticamente.

 Es interesante no obstante como los chicos de Mozilla tomaron el test original de Microsoft del tanque de peces (usado anteriormente con 3000 peces) y lo adaptaron a WebGL. Comprobamos como tenemos que elevar a la friolera de 50.000 peces para no alcanzar los 60 fps de tope. Si bajo la aceleración por Hardware por contenido y capas 3.000 peces parecían ser el tope por ahora, el rendimiento por WebGL frente al test anterior es sorprendente:

[singlepic id=47 w=350 h=228 float=left][singlepic id=43 w=350 h=228 float=center]

  • Opera: No es capaz de representar los “planetas” en Sistema Solar

 

Spinnig Balls

Cualquier programa informático generalmente requiere un buen gestor de memoria que esté de forma asidua buscando y liberando cualquier trozo de RAM que ya no use. Esto es útil por dos razones principalmente: Primero porque de lo contrario el consumo de RAM subiría constantemente y terminaría con consumir toda la existente, y segundo porque la ejecución del programa sería cada vez más lenta y los datos en RAM más fraccionados. Esto como digo se evita “reciclando” la RAM cada cortos períodos de tiempo, función que es llevada acabo por lo que llamamos un Garbage Collector (recolector de basura en sentido literal). Los navegadores no son una excepción a esto, y pueden producir en cortos períodos de tiempo muchos objetos nuevos debido a código JavaScript o DOM, los cuales muchos de ellos incluso son destruidos con la misma rapidez. Esto genera constantemente muchos trozos de RAM “basura” que es bueno… es necesario ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable en ninguna circunstancia, sin esto el navegador no tardaría en colapsarse y agotar la RAM del sistema.

El problema de los recicladores es que son funciones/subrutinas que tienen que ser ejecutadas como es natural dentro de los propios procesos, y dependiendo del sistema GC que estén usando pueden incluso detener la ejecución del proceso por completo hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo como una extrañas pausas en un momento dado, un salto en u juego, un drop de FPS momentáneo… cuestiones que realmente no implican que el proceso se ejecute más rápido o menos rápido, sino que se ejecute de forma fluida o no. Esto lo hemos visto en muchos test en los que algunos navegadores no es que obtengan bajos FPS, sino que aplicaciones que aun obteniendo altos FPS son totalmente imposibles de manejar dada las continuadas pausas.

Cualquiera que haya jugado a cualquier juego online conoce los efectos del “lag”, pues bien esto sería algo similar, donde da igual cuan potente sea el equipo, puesto si el lag es alto puedes darte por muerto. La eficiencia o no de cada modelo de GC varía. En algunos programas puede ser mejor un modelo, en otros otro. Por ejemplo se podría hacer un GC simple que cada 2 segundos ejecutase una subrutina para hacer el reciclado, pero el tiempo invertido en ese “limpiado” también variará en función de la última vez que se realizó. Podríamos ejecutar GC cada X segundos, pero cada esos X segundos casi con toda seguridad se notaría una micro pausa. Si no se ejecutase ya sabríamos que pasaría y si se  hiciese cada medio segundo a lo mejor se estaría tb produciendo una latencia y lag por el número de veces que se ejecuta el recolector… es decir, no es nada fácil dar con el mejor sistema, puesto que el mejor sistema depende de cada momento.

Este test mide este comportamiento. Genera muchos objetos a gran velocidad constantemente, y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se esté ejecutando, incluso puede afectar el movimiento del propio ratón, así que ojo. Cada pausa que registra el programa la anota, y la mejor puntuación es para aquel navegador que realiza menos pausas o pausas más cortas. Es decir que un navegador que a lo mejor tienen 10 pausas de 5 ms y otro que posee 5 de 10 ms, el primero obtendrá mejor resultado ya que la implicación es menor y la ejecución mucho más fluida.

[singlepic id=45 w=700 h=456 float=center]

 

Test de compatibilidad HTML5 de Niels

A día de hoy un buen navegador no solo es aquel que es el más rápido, sino que también está en continuo desarrollo para adaptarse a los nuevos tiempos y a los nuevos estándares. El test de Niels es uno de los mejores identificativos para medir la compatibilidad con el futuro estándar HTML5. En las últimas actualizaciones se le ha añadido también algunas otras características ajenas a HTML5 de todos modos. Hay que tener en cuenta que este test al margen de algunos otros añadidos y HTML5 no testea otros estándares igualmente importantes, como puedan ser WebGL, CSS, SVG…

[singlepic id=38 w=700 h=456 float=center]

  • El test de Niels se basa actualmente sobre 500 puntos máximos.

 

Test de compatibilidad WebGL de Khronos

Exactamente igual que testeamos poco a poco las especificaciones HTML5 que van formándose, hacemos lo mismo con las especificaciones de WebGL. WebGL es un estándar para permitir que el navegador pueda ejecutar gráficos avanzados en él, es llevar la API OpenGL a los navegadores. Dos navegadores pueden ser compatibles con WebGL, pero si uno no es compatible en algunas cuestiones de WebGL el resultado puede ser simplemente que el contenido no se visualice o se visualice mal. Mientras buscaba algunos test WebGL interesantes, en muchos casos no todos los navegadores con soporte WebGL podrían ejecutarlos correctamente

[singlepic id=52 w=700 h=456 float=center]

  • Internet Explorer y Safari: No son compatibles
  • Opera: Aunque es compatible, múltiples test provocan cierres constantes

 

IE Center Testing

Microsoft posee desde hace ya tiempo un site con una tabla que muestra la compatibilidad de los diferentes navegadores frente a los nuevos estándares. Los test que se han usado aquí son exactamente los mismos, solo que yo los aplico a mis versiones de los navegadores, y no a las que aplica MS.

Hay que entender que aunque la suite de test que expone Microsoft es bastante completa (siendo a mi gusto el test de compatibilidad mas completo que hay), es totalmente parcial y engañosa. La suite de test creados por Microsoft para probar la compatibilidad de los navegadores se basa en exponer TODAS las compatibilidades que Microsoft sabe que Internet Explorer 10 es compatible, con lo que cabe esperar que Internet Explorer 10 obtenga un 100% en todos los test. En cambio, para muchas otras especificaciones y partes de especificaciones en las que Internet Explorer no es capaz de estar a la altura, Microsoft simplemente no crea test para ellos. Es el caso de muchas especificaciones de HTML5 (que es mucho mejor identificativo el test de niels) o para WebGL. A esto habría que sumarle además errores de los propios tests que conscientemente o inconscientemente Microsoft comete, haciendo que IE 10 sea capaz de pasar dichos test y la competencia no. Esto no es tan extraño, pensar que muchas cuestiones de las especificaciones son totalmente interpretativas, y así por ejemplo Mozilla puede entenderlas de un modo y Microsoft de otro. Otras veces simplemente se deja abierto a elección de cada cual como hacerlo… Supongo que la mejor forma de saber quien de ellos tiene razón es mirando simplemente las implementaciones de cada uno, y si 3 lo hacen de un modo y solo es uno quien la interpreta de otro, posiblemente esos 3 tengan razón. De todos modos aquí nos basamos tan solo en los test de Microsoft tal como ellos los concibieron.

Todo esto se resume con que esta suite es crucial a día de hoy y un excelente trabajo por parte de Microsoft sin duda, pero que quizás tan solo cubre un 60% de un todo, siendo el 60% que cubre el que precisamente interesa a Microsoft por ser compatible con su navegador. Aun así el soporte para CSS, SVG, JavaScript…  es bastante bueno. Quizás la mejor forma de interpretar estos resultados sería eliminando a Internet Explorer de este test, lo que nos daría posibilidad de comparar realmente otros navegadores entre ellos, no contra otro que evidentemente sabemos que va a ganar (se hizo para ello).

[singlepic id=34 w=700 h=456 float=center]

  • Test realizados con la última versión del IE Center de Microsoft, actualizada a 25/10/2012

 

  Test de W3C para CSS 2.1

 Pese al bombo que se le ha dado a las futuras especificaciones de HTML5, posiblemente CSS sean especificaciones mucho más importante que los nuevos añadidos que pueda implementar HTML5. Esto es simple, CSS es usado a día de hoy prácticamente en todas las web del mundo, y cada vez se hace un uso más intensivo de este, tanto para aplicar simples estilos, a crear auténticos efectos de todo tipo.

CSS permite básicamente aplicar estilos, formatos… a cualquier parte de una web, elemento o conjunto de ella de forma que sea simple reutilizar su código, modificarlo… y como cualquier otro estándar ha estado en continuo cambio y evolución. Las especificaciones CSS 2.1 son a día de hoy ya un estándar en uso, no es como HTML5 un estándar en desarrollo, sino que esta por decirlo de algún modo publicado. Es cierto por supuesto que se continúan revisando sus especificaciones añadiendo… pero básicamente está terminado. La evolución de este sería CSS 3.0, que se encontraría en el mismo estado más o menos que HTML5, en pleno desarrollo.

En este caso, me gustaría tener tiempo material para poder lanzar un análisis exhaustivo sobre los navegadores y CSS 2.1 gracias a la suite de W3C, el problema es que hablamos de miles de test y no son automatizados, requieren una constante vigilancia. Es por ello que en esta ocasión he de optar por tomar los datos oficiales de W3C sobre estos datos, y lo que voy a exponer aquí no son pruebas personales y locales, sino los datos del último reporte de W3C. 

Los datos son simples de interpretar, existe un porcentaje de test cubiertos y otro de test cubiertos pasados. Como es porcentual, y teniendo en cuenta que la mayoría de los navegadores tienen cerca del 100% de test cubiertos, podemos usar de resultado final el porcentaje de test pasados cubiertos. Por supuesto este tendrá una pequeña desviación de error, que es menor en tanto y cuanto el porcentaje de test cubiertos sea mayor.

En el futuro intentaré poder pasar manualmente todos los test a cada navegador, puesto que los resultados del W3c no son aplicados a un navegador en particular, sino que se aplican a cada Engine del navegador, y además son acumulativos. Es decir que Safari o Chrome se le asigna el mismo valor (cuando por descontado las puntuaciones serían diferente), y por otro lado no se aplican tan solo a cada versión del navegador en particular, sino en el conjunto de todas ellas. Pese a todo, es interesante tener una visión globgal de la compatibilidad de los navegadores frente a CSS 2.1

Sobre CSS3, el test de Microsoft ya cubre parte de estas especificaciones, y en el futuro incluiré también la suite oficial de W3C de test para CSS3 (muchos de los cuales son los que usa Microsoft)

 [singlepic id=33 w=700 h=456 float=center]

 

 

 

Conclusiones

Si valoramos cada navegador como se dijo al comienzo, los resultados serían por tanto los siguientes:

Resultados Firefox 20 x86 Chrome 25
IE 10 x86
Opera 12.12
Safari 6
Rendimiento 62 41 32 24 35
JavaScript 12 13 11 5 4
Canvas 13 17 14 11 5
Gráficos 28 16 23 20 7
WebGL 10 7 0 7 0
Otros 5 4 1 3 2
Compatibilidad 17 15 12 9 4
Estabilidad 5 4 2 1 4
           
Total 152 117 95 80 61

 

  • Rendimiento

    El rendimiento de un navegador no sólo se resume en lo rápido que pueda ejecutar un código en JavaScript o los fps que sea capaz de mostrar en cualquier aplicación/juego. De echo, desde mi punto de vista posee un peso más que importante a la hora de escoger uno u otro. ¿Cuantas horas a la semana pasamos delante de un PC/dispositivo con el navegador abierto? Cada vez disponemos de dispositivos más potentes, pero las páginas Web, las aplicaciones Web… cada vez son más complejas igualmente y requieren de esa potencia extra. Por tanto es de extrema importancia que el navegador no solo sea capaz de ejecutar una tarea lo más rápida posible, sino que el propio navegador se comporte de forma ágil y veloz en el sistema. Eso implica que tenga excelentes gestores de memorias propios, que pueda gestionar inteligentemente la carga de nuevos contenidos, reducir en la medida de lo posible los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rápido acceso, reducir la sobrecarga del propio OS… y sinceramente esto es una tarea muy complicada.

    En cuanto a tiempos de inicio se refiere, en este caso es Firefox quien prevalece sobre el resto casi en todas las pruebas. Esto posee una mayor importancia si recordamos que Firefox no es un navegador multiprocesado como es Chrome, lo que significa que los chicos de Mozilla están aunando un esfuerzo increíble en mejorar la respuesta general del Navegador. Chrome e Internet Explorer aunque son multiprocesados (que no quiere decir multihilos, que lo son todos) no son capaces de optimizar lo suficiente el código para estar a la par, pero exceptuando Opera que posee problemas en este caso, no tienen un rendimiento que sea muy alejado.

    El principal problema de abrir múltiples pestañas a la par es la sobrecarga en el navegador, independientemente de la velocidad con la que se carguen después en el navegador. En los navegadores no multiprocesados como Firefox, Opera o Safari la apertura múltiple de muchas pestañas podría provocar al usuario la sensación de paralización/congelación de este hasta que prácticamente todas las pestañas estuviesen cargadas, ya que desde el punto de vista del navegador tan solo estaría llevando a cabo una misma tarea. Para Internet Explorer o Chrome este problema no lo tienen, cada pestaña tiene su propio espacio y sería el propio sistema operativo quien gestionaría por medio de su planificador (Scheduler). Para tratar con ello, tanto Opera como Firefox usan por defecto la carga selectiva de pestañas, es decir, por defecto cuando se abren múltiples pestañas a la par tan solo se cargan aquella que esté en primer plano. El efecto es inmediato, de poder tener el navegador paralizado durante múltiples segundos la navegación es instantánea, y mientras se pueden ir cargando de fondo el resto de las pestañas. Por supuesto a la hora de medir los tiempos, este comportamiento se deshabilitó para que todos los navegadores estuviesen en igualdad de condiciones, como es natural.

    Todo tiene pros y contras, y que una aplicación sea multiprocesos implica inevitablemente otros efectos secundarios cuando no se cuidan demasiado, y que se evidencia en una sobrecarga adicional en la memoria RAM y en el tiempo necesario para finalizar por completo la aplicación. En esta ocasión Chrome ha mejorado en mucho el cierre del navegador, mientras que IE continúa con tiempos muy altos y muy inestables. De cualquier modo, se puede apreciar perfectamente como precisamente Chrome e IE poseen con diferencia el mayor consumo de RAM, mientras que el resto de los navegadores poseen un consumo mucho más amortiguado, llegando hasta las increíbles cifras de FIrefox. Uso increíbles porque si las comparamos con Chrome, para 10 y 20 pestañas Chrome casi duplica el consumo de RAM frente a Firefox. Tanto Opera como Safari poseen un consumo medio no obstante.

    Respecto a la carga de contenido cacheado y sin este, vemos que de nuevo Firefox vence, aunque prácticamente con unos resultados iguales a Chrome, siendo las diferencias complicadas de apreciar. Safari tampoco queda muy lejos de Chrome, e incluso IE no obtuvo unos resultados demasiado malos, sino fuese por algún que otro problema cuando no cachea el contenido.

    Por último, hay que destacar el rendimiento en la reproducción de contenido en 1080p de los navegadores y de la mitificación que otrora intentó Steve Jobs en que Flash es la lacra para el rendimiento, la seguridad, la batería y el pasado. 6 meses después, volvemos a demostrar que flash sigue siendo la opción más viable, más rápida, con menor consumo energético, con mayor rendimiento para la reproducción de contenido audiovisual. Si miramos los recursos usados por el equipo en la reproducción de contenidos en Flash y contenidos en WebM, vemos que las diferencias son notables, aunque en esta ocasión vemos que los resultados son más moderados, lo cual nos dice que posiblemente nVidia al menos habría aplicado algún tipo de aceleración hardware a sus drivers para WebM, y esto se nota. Aun así vemos que es mucho más eficiente Flash, mientras que reproducir en el equipo de pruebas un vídeo 1080p en flash consumía en el peor de los navegadores un 13% de la CPU (menos de un 1% en los mejores casos) y un 11% la GPU (en el peor de los casos), WebM llegó a necesitar en el peor de los escenarios un 13% CPU/20% GPU. sin duda alguna es una gran evolución desde la última comparativa, pero aun así Flash continúa siendo lider.

    Por supuesto, se podría usar otros codec como H264 para la reproducción de vídeo por HTML5, y este poseería mejor soporte para aceleración por hardware que WebM (y mayor calidad), pero h264 está fuertemente patentado y ya explicamos el por qué de usar WebM.

    Estoy convencido que en el futuro se podrá estandarizar el uso de codecs en los navegadores y que la reproducción por medio de HTML5 será tan eficaz como con Flash, pero eso será el futuro, continúa estando lejos. El proyecto WebM no será posible mientras que el soporte para este sea el que estamos viendo.

     

  • JavaScript

    Los test sintéticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya he dicho tantas veces, me parece que son test tramposos que tan solo buscan la buena prensa de los medios. Seamos sensatos, cualquiera que eche un vistazo a los números y luego a los entornos reales ve que existen diferencias cuanto menos graciosas. Así por ejemplo supuestamente Internet Explorer mantiene la primera posición en SunSpider, pero si miramos en Kraken que es un derivado de SunSpider queda lejos de esa posición.

    No hay que ser un genio para darse cuenta que todos los navegadores (sin excepción) optimizan partes de su código a sabiendas de estos test, con la inclusión de Fast Path y otros. Por supuesto que muchas de estas optimizaciones pueden ser llevadas a entornos reales, pero es evidente que la mayoría no, la mayoría tan solo tienen utilidad en estos test, y por tanto su fiabilidad es más que dudosa.

    De nuevo no quiere decir que sean totalmente inútiles este tipo de test, y se aprende mucho de los motores JS de cada navegador, se pueden detectar puntos calientes en ellos, mejorar… eso por supuesto!! pero estos test tienen sentido realmente cuando se comparan no navegadores Vs navegadores de la competencia, sino en todo caso las mejoras existentes en JavaScript entre las diversas versiones del mismo navegador.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. Canvas es una de la infinidad de especificaciones que poseerá el estándar HTML5 y que se están empezando a usar muy poco a poco. Como ya he dicho, Canvas define algo así como un espacio de trabajo en el que se ejecutará un código principalmente en JavaScript, CSS… con lo que es posible la creación de aplicaciones Web complejas, y por supuesto juegos como Angry Bird y tantos otros. El rendimiento de estos “marcos” está ligado íntimamente con JavaScript, pero como veremos en el apartado gráfico también de otros muchos factores.

    Es complicado medir este apartado dado que se puede crear un Canvas con el contenido más vario pinto posible, y es más que posible que en algunas aplicaciones domine un navegador y en otras domine otro. Si vemos los resultados son muy variados, no hay un claro ganador porque como digo es muy dependiente del contenido del canvas. Quizás podamos afirmar que cuando Canvas posee un fuerte componente Javascript, el ganador es Opera o Chrome, mientras que si posee un componente gráfico es Firefox.

 

  • Gráficos

    Hay que tener en cuenta antes de empezar, que aunque esta sección se llame “gráficos” no tiene nada que ver con la elavoración de gráficos complejos 3D ni nada por el estilo, sino test que pueden sacar un provecho enorme de la aceleración hardware. Así por ejemplo tenemos el test de SpeedReading que tan solo se vasa en un marcador veloz de letras, o psicodélico, que no deja de ser una imagen girando sobre sí misma.

    Opera continúa por defecto con esta característica deshabilitada, aunque en esta ocasión ha logrado rebajar de forma considerable el uso de GPU que tenía anteriormente. Internet Explorer o Firefox continuan siendo lideres indiscutibles, siendo muy eficaces tanto en uso de GPU como en rendimiento general.

    Tanto Internet Explorer como Firefox usan el mismo Backend usado de forma muy similar, aunque Firefox lo usa por regla general algo mejor (no demasiado). Chrome por su parte hace algo similar que Opera, usando un backend de OpenGL Safari por contrapartida parece haber abandonado el soporte para Windows, con lo que es más que posible que jamás lo tenga. En la versión de MAC OS posee cierto tipo de aceleración, pero recordemos que MAC OS no posee ninguna API Decente de aceleración hardware 2D, con lo que estos test en MAC OS darían igualmente a Safari la última posición.

    Por último decir que la ventaja de que Opera o Chrome usen OpenGL de backend, es que en teoría debería de ser totalmente compatible con cualquier OS compatible con OpenGL (Linux, Windows XP, MAC OS), mientras que el camino tomado ahora mismo por Firefox e Internet Explorer requieren de DirectX 9+ (recomendando DirectX 10) y Windows Vista/7.

    El futuro parece más o menos evidente. Firefox no solo tiene creado el backend de Direct2D/DirectDraw, sino que posee también un Backend OpenGL para Linux/MAC OS e incluso Windows si se fuerza. Así mismo con el tiempo Mozilla abandonará Direc2D/DirecDraw e implementará un Backend en Windows basado en Direc3D, con lo que se obtendrá no solo un rendimiento superior, sino que será más compatible dentro de los diferentes adaptadores de vídeo y versiones de Windows.

 

  • WebGL

    Opera se sumó hace tiempo al carro de WebGL aunque aun no habilitado por defecto.

    Aunque en el apartado anterior se ha hablado de forma extensa sobre la aceleración de hardware y de contenido gráfico, hay que saber diferenciar totalmente WebGL de ello. En el apartado anterior se mostraba la capacidad de los navegadores para acelerar gran parte del contenido en muchas aplicaciones Web y juegos a través de diferentes APIs, como por ejemplo una imagen girando velozmente sobre ella misma, transiciones rápidas… aplicaciones o juegos que podemos encontrar cada vez más en cualquier lado. No hablamos de apartado gráfico anteriormente porque manejásemos gráficos complejos, sino para especificar que son test que hacen uso extensivo del adaptador de vídeo.

    Pero WebGL es totalmente diferente, con WebGL sí asumimos que vamos a trabajar (o al menos que podemos trabajar) con gráficos complejos. WebGL se crea como iniciativa de poder renderizar en Canvas contenido 2D/3D complejo a través de OpenGL. De prosperar y ser realmente eficiente (que es discutible dado la gran sobrecarga de JavaScript) podríamos encontrar a medio plazo juegos con bastante potencial gráfico ejecutado directamente en nuestro navegador. Como lado negativo se encuentra en que WebGL se basa evidentemente en JavaScript, y la sobrecarga de este lenguajes es muy alta. No podremos por tanto comparar jamás una aplicación/juego programada en C++ y OpenGL que programada en JavaScript y WebGL. Esta tecnología jamás será un sustituto ojo, WebGL no llega para desbancar nada, sino para añadir algo que antes era imposible.

    Gracias a WebGL vimos el increíble trabajo por parte de Google y Zigote con “Body Browser”, que es una aplicación totalmente práctica, útil y funcional. Realizar algo así sin WebGL sería imposible a día de hoy, se debería de instalar algún complemento en el navegador. Aun así, se ha demostrado que WebGL aun está muy lejos de alcanzar el rendimiento que se obtiene con una aplicación nativa en OpenGL.

    Soy defensor de OpenGL, sobre todo por su facilidad a la hora de programar con él, pero la API DirectX es sencillamente mejor y más rápida. Incluso con ANGLE (implementación de OpenGL sobre DirectX) que tiene que hacer de “traductor”, el rendimiento a través de este es superior. En Firefox existe la posibilidad no obstante de usar el soporte nativo OpenGL, pero cuando se opta por este modo, el rendimiento es algo inferior.

    Aun así, no se usa ANGLE por su rendimiento, ya que al final cuando se optimizase WebGL y el soporte nativo es de esperar que el rendimiento de este fuese superior. Se usa ANGLE porque el soporte para OpenGL varía mucho entre diferentes fabricantes. Así por ejemplo, nVidia ofrece el mejor soporte para OpenGL disponible, siendo compatible desde su serie GX 400 con OpenGL 4.3.0. Pero este escenario es totalmente desastroso cuando miramos adaptadores de vídeo Intel, que poseen un soporte para OpenGL mucho más pobre. ANGLE es una solución muy eficaz ya que asegura que sea cual sea el fabricante o el adaptador de vídeo que se tenga instalado, mientras que este sea compatible con DirectX 9.0c podrá ejecutar a la perfección contenido WebGL, y en muchos casos como vemos con un rendimiento superior. Por suerte, Intel está empezando a aplicarse el cuento y entregando controladores decentes para OpenGL en la actualidad, ahora mismo creo que ya soporta en Windows 8 hasta OpenGL 3.0. Recordar que estamos hablando en todo momento de Windows, en Linux o MAC OS no es posible bajo ningún pretexto el uso de la API DirectX, y OpenGL forma parte intrínseca de él. En el caso de Linux es posible usar OpenGL 4.3.0 (la especificación más alta actualmente) siempre y cuando el adaptador de vídeo lo permita, en el caso de MAC OS, este tan solo soporta OpenGL 3.0 y con muchas carencias.

    El test que más nos llama la atención es inmediatamente el tanque de 50.000 peces. Recordemos que realizamos el mismo test bajo HTML5 con 3000 peces, obteniendo Opera en el mejor de los casos cerca de 50 fps. En este caso tenemos el mismo tanque pero usando WebGL, y vemos que es necesario elevar a 50.000 peces para que Firefox no alcance los 60fps. Cualquiera podría decir que si disponemos de WebGL que sentido tiene el test anterior en el que el navegador no podía con 3000. Y volvemos a lo mismo, las peras se parecen a las manzanas en que las dos son frutas, pero nada más. Es más que evidente que si cualquier test html5 se puede pasar a WebGL (con lo que debe de tener un fuerte componente gráfico evidentemente) su rendimiento será infinitamente superior.

 

  • Estándares

    Actualmente parece que existen dos grandes frentes abiertos a la prensa. Si uno es el rendimiento en los test sintéticos, el otro es el proclamar que su navegador es compatible con HTML5, o mejor dicho, pelearse por cual es más compatible en este campo. HTML5 es muy importante en el futuro, pero de nuevo no es el único estándar emergente estos días. Es más, actualmente es infinitamente más usado CSS 3.0 como estándar emergente que HTML5. Tan importante es lo uno como lo otro.

    De nuevo y como era de esperar, todos los navegadores han mejorado su compatibilidad con los estándares existentes, sobre todo en HTML5 como podemos ver en el test de Niels (no podemos compararlo con la comparativa anterior dado que el test de Niels está en constante cambio). Aun así, y pese que Microsoft asegura que en sus test Internet Explorer 10 es el más compatible de cara a HTML5, es Chrome quien posee cierto liderazgo aquí. El problema de Chrome es que aunque es cierto que es más compatible a efectos generales en HTML5 que el resto de los navegadores, no a efectos concretos. Es decir, Chrome implementa la mayoría de funciones de HTML, pero de una forma básica, y lo mismo le pasa con CSS y otras tecnologías. Opera en contrapartida se centra en menos variedad pero de una forma mucho más profunda, intentando cumplir a rajatabla todas las especificaciones de cada sección. Esto hace que en test generalistas como el de Niels Chrome obtenga muy buenos resultados y en otros más específicos como la suite de IE obtenga resultados algo inferiores.

    Sobre la Suite de Microsoft poco podemos añadir, evidentemente es una suite totalmente engañosa para mostrar que Internet Explorer es el navegador más compatible, y en cambio en el test de niels el resultado es deprimente. No obstante Microsoft sigue avanzando a pasos agigantados en cuanto a compatibilidad se refiere, su eterna lacra desde luego… aun a día de hoy muchos webmaster necesitamos crear código redundante y hacer “trampas” para que las web se visualicen correctamente en Internet Explorer, precisamente por no ceñirse a los estándares.

    Sobre WebGL, tanto Firefox como Chrome continúan aumentando su compatibilidad. Opera se ha subido al carro y no ha empezado con mal pie desde luego, aunque en las últimas versiones no es demasiado estable.

    Microsoft optó al final por desgracia de no implementar por ahora WebGL, parece más o menos claro que antes o después lo implementará. Microsoft ya dijo hace tiempo que su postura era dudosa dado a los posibles problemas de seguridad que podrían derivar de WebGL, en cambio como ya explicamos esto es relativo y existen sistemas para evitar estos problemas de seguridad.

 

  • Compilaciones x64

    Internet Explorer 10 ejecuta su interfaz siempre en 64 bits, siendo su chrome en 32bits o 64 bits dependiendo de si se ha habilitado el modo de seguridad avanzada, pero aun cuando habilitamos el modo nativo 64bits vemos que por fin MS se decidió a añadir sus mejoras de rendimiento a la versión de 64bits.

    Firefox continúa ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. Por desgracia recientemente se ha anunciado que durante un tiempo deshabilitarán las versiones de 64 bits problemas a la hora de detectar los fallos de su navegador, pero han asegurado que estarán disponibles para el año próximo.

    Opera continúa con sus versiones de 64 bits, y son bastante decentes.

    Sobre Chrome y Safari por otro lado no hay indicio alguno de que una versión de 64 bits pueda ver la luz a corto plazo… habrá que esperar. Es de suponer que eventualmente Chrome sacará una, pero…

 

  • Consumo energético

    ¿Como puede influir un navegador en el consumo energético de un dispositivo? Pues es fácil, dependiendo en gran medida de los recursos que tenga que hacer uso de él. Para ello tan solo tenemos q observar la carga en la CPU/GPU del sistema para hacernos una idea.

    Cuanto menor sea la carga en ambos menor es el consumo, es evidente, pero no está tan claro cuando tenemos que pensar si es la GPU o la CPU quien prima sobre el consumo. Es decir, es mejor tener un consumo de un 10% CPU y 2% GPU o un 2 CPU y 7% GPU. Sería muy complicado llegar a una decisión unánime sin acudir a un tester de potencia y medirlo directamente, pero si más o menos imaginarlo.

    Mirando las gráficas, parece claro que el navegador más eficiente energéticamente hablando dependería del contenido. En un escenario normal, el mejor resultado sería para Internet Explorer o Firefox, en cambio cuando se entrase en test más complejos el ganador sería Safari (por la sencilla razón de que no usaría la GPU y que no sería capaz de ejecutar correctamente el test). Opera en cambio obtendría el peor consumo de forma general por un exceso en el uso de la GPU, y Chrome tampoco quedaría en muy buen lugar, con cargas de CPU/GPU considerables.

    Quizás en un equipo de sobremesa el consumo energético es lo de menos, pero como siempre pensemos en portátiles.

Windows 8: Como activarlo usando servidores KMS

Share on Google+Share on FacebookTweet about this on Twitter

 

Para el que no lo sepa aun, Windows 8 llegó a la versión de oro (RTM, Release To Manufacturing) no hace siquiera dos días. Esto significa básicamente que Windows 8 está terminado, y aunque no verá la luz al público hasta dentro de un mes y medio más o menos, no quiere decir que la nueva versión de Microsoft no esté terminada.

Este período de tiempo se usa no para pulir fallos, sino para que los desarrolladores de software, los OEM, los fabricantes de hardware… puedan adaptar sus programas, drivers, dispositivos… a la versión final de Windows 8. Esto siempre ha implicado, y esta vez no ha sido menos, que el mismo día que se termina la versión RTM, esta se filtre a diversos canales, y termine la imagen original de Windows en manos de todo aquel que busque un poco por la red. En realidad esto incluso le viene bien a Microsoft, además de un poco de publicidad, hace que algunos usuarios y expertos en tecnología comiencen a escribir sobre las novedades de Windows 8, un producto ya terminado.

Ya sé que es empezar por el final sin antes explicar el principio, pero hoy no vamos a hacer una review de Windows 8 (eso para otro día), ni tampoco a explicar cada uno de los sistemas de activación y protección nuevos con los que cuenta. Hoy la cosa va a ser mucho más específica, a explicar tan solo uno de los sistemas de activación de Windows 8, y que es el que ahora mismo está usando algunos cuantos para activar copias piratas de Windows 8. Y es que en este mundillo, todo es posible, por difícil que sean las cosas.

 

La mayoría de las copias piratas de Windows 7 eran activadas por medio del uso del sistema OA 2.1 (OEM Activation). Se llegó a asimilar que el sistema más cómodo, rápido (y en teoría infalible) para que las copias de Windows 7 fuesen o pareciesen 100% legítimas era o modificar la Bios para incluir la activación OA o instalar un Loader para emularla. Lo malo de este sistema es que había que tocar la bios que siempre es peligroso o instalar Loaders que no es que lo sean menos. ¿Por qué se usaba este sistema? porque era el único sistema para poder realizar una activación offline. Cualquier otro sistema que se usase, se tendría que realizar una comprobación online del Key introducido, y por descontado que Microsoft bloquearía Keys usadas o inválidas.

Windows 8 ha cambiado este esquema. OA 2.1 se ha actualizado a OA 3.0, y aunque el proceso de cara al usuario es el mismo (una activación totalmente transparente), ya no es posible engañar tan fácilmente al sistema con una modificación de Bios, puesto aunque la Bios es la misma en todos los equipos, no lo es la Key que se le inyecta antes de entregarlo, la cual es únuca, haciendo complicado que pueda usarse una modificación de Bios para aprovechar este sistema. Con esta opción por ahora anulada, tan solo quedaría la activación online que ya hemos dicho no es viable, y la validación de las licencias VL, es decir, licencias múltiples. Este tipo de licencias son las que usan las empresas, como comprenderéis una empresa que tiene o actualiza 10.000 equipos no les van a entregar un sobre con 10.000 keys, sería totalmente inviable. Lo que se hace es usar un servidor KMS (Key Management Serveice)

A groso modo, lo que se hace es que Microsoft entrega una key maestra a una empresa, la cual instala un servidor KMS que gestiona LA EMPRESA. Para que dicho servidor KMS funcione, necesita evidentemente una key maestra, que una vez introducida, esta se valida ANTE los servidores de Microsoft. Si Microsoft da el visto bueno, dicho servidor KMS es activado.

Pero cual es la función de estos servidores KMS? Fácil, activar software de microsoft, en este caso concreto las ediciones de Windows 8 Pro/Enterprise con licencias VL. De este modo Microsoft no tiene que entregar una key a cada equipo, sino que estos son activados de forma temporal (180 días) por medio del servidor KMS de la empresa. La pega es que como he dicho es temporal. Por seguridad y por la licencia misma, los equipos intentarán revalidar su activación por otros 180 días cada 30 días, de este modo mientras el servidor KMS esté en activo, nungún equipo de la empresa tendrá que preocuparse jamás de nada. Si en 180 días no fuese posible la reactivación, Windows 8 pasaría al modo de pruebas.

¿Como afecta esto a la piratería? Bueno en teoría el sistema está perfectamente montado para que no sea posible la activación de copias piratas pero… ¿que pasaría si cualquier usuario instala en su casa una copia de Windows 8 Enterprise con licencia VL? En principio podría instalarla y hacerla funcionar en modo de prueba hasta que la validase en un tiempo de 30 días. Y si ese usuario tiene un padre, un tío un amigo que tiene acceso a un servidor KMS activado que está preparado para activar Windows 8? Pues que si el usuario tiene acceso a dicho servidor de forma directa o indirecta y lanza la petición de activación a dicho servidor… Windows 8 quedaría activado, al menos durante 6 meses.

Por supuesto, es muy posible que dentro de muy poco aparezca un activador portatil que cualquier usuario podrá ejecutar en su mismo equipo para activar su propia copia.

 

Con fines totalmente didácticos, como ya sabéis, tan solo he aplicado todo lo anterior. Lo que sabemos y podemos afirmar:

  • Podemos activar cualquier copia de Windows 8 si tenemos acceso de un servidor KMS activado y con soporte por supuesto para activar Windows 8.
  • Los servidores KMS deben de estar siempre funcionando ya que cada 30 días los equipos activados tendrían que acceder a él para no cumplir los 180 días. Esto hace que generalmente estén ubicados siempre en el mismo lugar (ubicación de red, no geográfica) puesto que los equipos clientes se configuran al inicio y ya está, lo que significa que una vez tengamos acceso a uno de ellos es muy posible que continúe siendo válido por mucho tiempo
  • En teoría un servidor KMS ya activado no requiere de comunicación con Microsoft, con lo que en la práctica usando este sistema las copias piratas serían validadas totalmente como genuinas (al menos durante 180 días).
  • La teoría nos dice que los servidores KMS deberían siempre ubicarse en la red interna de la entidad/empresa/organización evidentemente, es decir que no fuese posible acceder a ellos de forma externa. Pero como todos sabemos la práctica siempre nos ha dicho lo contrario, que a lo mejor 9 de cada 10 sí están detrás de una red interna, pero 1 de cada 10 no, y
    este podría ser alcanzado desde cualquier punto del mundo.
  • Sabemos también que los servidores KMS por defecto usan el puerto TCP 1688 para las activaciones.

Con todo esto, no debería de ser complicado al lector habitual por donde van los tiros. Como ya vimos en el artículo de la “Caza y Captura de iPhone” y en el artículo de “Como consumir los datos de cualquier iPhone de forma remota“. La teoría aplicada sería la misma. Un puerto abierto es siempre un puerto abierto! Lo más importante es que siempre podemos buscarlo. Eso no quiere decir que cada equipo en el que encontremos un puerto TCP 1688 abierto, implique sin lugar a dudas que hemos encontrado un servidor KMS activo y que pueda validar copias de Windows 8 VL. Pero si implica que potencialmente hemos podido encontrarlo.

Al igual que se hizo en el artículo de la búsqueda y captura de iPhone, se aplica el mismo principio. El puerto es lo que buscamos, ¿pero como sabemos donde buscar? Y es aquí donde de nuevo las bases de datos públicas de IP nos rescatan de nuevo. Como vimos en el artículo que explicaba entre otras cosas IP, existen 5 entidades que gestionan los rangos IP de todo el mundo: Ripe, Arin, APNIC, AficNIC y LACNIC. Cada una de ellas se encarga de una zona diferente del mundo. Estas bases de datos son públicas, y entre otras cosas almacenan la pertenencia de cada rango IP asignado por ellos. Eso quiere decir que podemos ser un poco imaginativos y buscar por empresas/entidades/organizaciones que presuponemos tendrán servidores KMS, pero podemos extrapolarlo a cualquier OEM o multinacionales, dado que la mayoría de ellas casi con total seguridad tengan un rango asignado. Estos rangos no son demasiado dinámicos con el tiempo, lo cual quiere decir que podemos construirnos una buena lista de rangos en los que posiblemente pueda encontrarse una presa.

Por supuesto esto no quiere decir que en 10 segundos encontremos uno. Hablamos de que la lista de rangos obtenida puede poseer cientos de miles y millones de posibles direcciones IP, en las cuales se podría encontrar, hipotéticamente, un servidor KMS, y que dicho servidor pudiese estar preparado para activar copias de Windows 8. Dicho así parecería casi imposible, pero como ya he dicho tan solo hay que ser un poco imaginativo, sin contar con que es posible escanear miles de equipos en tan solo segundos.

En el artículo de la caza y captura de iPhone se usaban redes que son más lentas, y aun así en unos días había escaneado cientos de miles y millones de dispositivos de toda clase. Con que tan solo 1 de cada 1.000.000 de equipos escaneados fuese un servidor KMS válido, sería más que factible. 5000 IPs por minuto (y tirando por lo bajo) nos daría 1.000.000 de IPs escaneadas en tan solo 3 horas (no quiere decir que sean 1.000.000 de equipos, solo IPs escaneadas). Pongamos que tan solo 1 de cada 10 IPs está conectada a un PC, ¿33 horas en escanear 1.000.000 de equipos? Aunque tardásemos toda una semana en encontrar un solo servidor KMS válido, este sería casi con toda seguridad válido para uno o dos años y para activar cuantas copias se quisiesen. Y eso sin contar con la colaboración de otros usuarios.

Este sistema es viable por dos razones:

a) El sistema puede automatizarse completamente con un script en Bash por ejemplo, el cual vaya escanenado de fondo todos y cada uno de las IPs que hayamos preparado, ya sea IP a IP o rangos de IP completos. Cada equipo encontrado se registraría en un documento externo para analizarlo después.

b) Como ya he dicho, cada servidor encontrado posiblemente podría ser usado por mucho tiempo, más que nada poque la misma empresa necesita que el servidor esté activado y en funcionamiento!! con lo que aunque pueda ser una gruesa tarea al principio, después compensaría. Es decir, pensando como un pirata no es de extrañar que dentro de poco se filtren servidores KMS. El problema es que posiblemente Microsoft esté al tanto y vaya cerrando el acceso a ellos llamando a los administradores de ese servidor KMS.

c) Podemos acotar la búsqueda si pensamos con la cabeza quien puede tener servidores KMS instalados o como comprobar también de forma automática cuales de ellos están activados y preparados para activar licencias de Windows 8, o incluso Windows 7 (el sistema es el mismo en las VL).

 

Dicho esto y como es costumbre un simple ejemplo práctico. Actualmente digamos que se está usando el servidor xx.xxx.135.121 para realizar la activación. Aplicando la lógica común podemos pensar que dicha empresa u organización posee otros servidores en su red por razones de multiplicidad o simplemente servidores de prueba o… Así que como probar no cuesta nada, tan solo tuve que mirar a quien pertenecía dicha IP y el rango que tenía asignado en la que se encontraba dicha IP: xx.xxx.128.121-xxx.xxx.135.255. Eso nos da un total de 3840 IPs posibles!! Puede parecer mucho, pero es irrisorio.

En tan solo 40 segundos el escaner estana terminado:

Tiempo total: 40 segundos
Hosts posibles: 3840
Posibles servidores KMS descubiertos: 9

xxx.xxx.135.83
xxx.xxx.135.121 <- El servidor KMS filtrado
xxx.xxx.147.41
xxx.xxx.147.49
xxx.xxx.148.34
xxx.xxx.148.246
xxx.xxx.148.226
xxx.xxx.149.236
xxx.xxx.148.249

En 40 segundos he encontrado 9 posibles servidores!! entre los cuales por supuesto se encuentra el que actualmente se está usando. El resto pueden ser servidores sin key maestra o incluso servidores KMS para validar Windows 7 o Windows Vista. Puede también que exista algún otro servidor KMS de Windows 8. Esto podría verificarse uno a uno o automatizando también el proceso, sería muy sencillo.

Una vez se dispusiese de un servidor KMS válido, solo restaría introducir un par de comandos en el sistema para que este se comunicase con el servidor y lo validase:

slmgr /skms servidor.kms.com
slmgr.vbs -ato

 

Es evidente que a día de hoy tampoco es que existan muchos servidores KMS para activar Windows 8, sobretodo porque la versión final no tiene ni 2 días, y hasta dentro de mes y medio ni siquiera estará al público. Es decir, que a día de hoy no creo que muchas empresas o entidades tengan servidores KMS para Windows 8. Posiblemente el servidor filtrado esté usando un emulador con una key maestra filtrada igualmente, quien sabe… pero lo que está claro es que dentro de un mes o dos meses lo que no nos van a faltar van a ser servidores KMS que puedan validar copias de Windows 8. Igual me equivoco y Microsoft cambia las reglas del juego, igual me equivoco y este sistema se queda en desuso por otro mejor… pero lo que está claro es que el sistema es viable y funcional.

Un saludo.

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.