Archivo del autor

eMail: SPF+DKIM = DMARC

Una pequeña reflexión antes de empezar

No sé como evolucionará la tecnología en el modo que nos relacionaremos unos con otros digitalmente dentro de unos años, pero me gustaría pensar que el eMail seguirá teniendo ese papel imprescindible. No son pocos los que año tras años auguran su muerte en pos de la mensajería instantánea. Es cierto que para la mayoría de adolescentes y jóvenes, el uso que puedan darle al correo electrónico es anecdótico, y generalmente para realizar reservas, compras y otros. Llamadme nostálgico o de la vieja escuela, pero pese a las virtudes que nos brinda la mensajería instantánea (la cual por supuesto uso de forma constante), lo único que supera a un buen correo electrónico cargado de contenido es una carta matasellada. Por supuesto no entramos en el mundo laboral/escolar/empresarial, donde a día de hoy el eMail sigue siendo completamente indiscutible.

Dicho esto, recordemos que el eMail no es algo nuevo, que data al menos desde 1970!! y poco cambiado desde entonces. Eso son casi 50 años, y evidentemente desde entonces todo ha cambiado.

 

Como funciona a groso modo el eMail

Como siempre, antes de entrar en materia “pesada”, para los que aun andan un poco despistados, un pequeño resumen rápido de como funciona el eMail, importantísimo para comprender la importancia de tecnologías como SPF, DKIM o DMARK.

El eMail, pese a que pueda parecer algo complejo es un sistema de mensajería tremendamente sencillo, se basa posiblemente en unos de los protocolos más simples que podemos encontrar a día de hoy como puede serlo SMTP. Otra cuestión que la mayoría desconoce es que pese a que tenemos proveedores de eMail a lo largo y ancho de todo el mundo, en realidad cualquiera puede enviar un eMail sin tener siquiera una cuenta propia, y que incluso podría crearse una sin demasiada complicación. Esto es así porque el eMail se creó como modo de comunicación sencilla, sin mirar cuestiones de seguridad o las posibilidades en la suplantación de identidad o…

La Wikipedia nos deja una imagen que ilustra bastante bien el funcionamiento del eMail:

correo

Un usuario envía un texto correctamente formateado a un servidor SMTP para que realice el envío (1), indicando entre otras cosas quien lo manda y a quien se lo mandamos. Este servidor SMTP lo primero que hace es consultar el destino de dicho correo, para lo cual lee el realm de la dirección de destino, es decir, el dominio al cual se envía, la parte derecha de la dirección, y realiza una consulta DNS al registro MX de dicho dominio, pues dicho registro se usa precisamente para ello, para conocer donde se encuentra el servidor de Correos de dicho dominio (2). El servidor DNS de dicho dominio devuelve la dirección de su servidor de correos (3) al servidor SMTP. Este al conocer ya el servidor al que debe de enviarlo, conecta directamente con el y entrega el correo en dicho servidor (4). Dicho servidor debería de reconocer la dirección de correo a la que está destinado, así que lo colocaría en su bandeja, a la espera de que el destino lo reclamase por medio de POP/IMAP (5).

Esta otra imagen muestra lo que sería un esquema más real de todo ello, más completo (no tenía muchas ganas de crear un esquema propio, así que espero que no se moleste oasis-open.org)

howemailworks

El usuario envía un correo a través del MUA (el cliente email que use) y posiblemente a través de SMTP a su MTA/MDA (Mail Transfer/Delivery Agent). Aquí se almacenará posiblemente en su bandeja de enviados, y como dijimos anteriormente se resuelve la dirección de destino y se procede a su envío, conectando al MTA de destino y entregando el mensaje allí. El MTA de destino lo manda ya por su red al buzon correspondiente y el destino lo recoge de ahí.

No obstante, este funcionamiento tan sencillo deja la puerta abierta a muchas preguntas concernientes a la seguridad de los propios correos electrónicos. Algunas cuestiones de gran importancia:

-Los correos no se mandan cifrados? No, por defecto el correo es un texto plano, si se quisiese cifrar se debería de realizar de un modo punto a punto, con tecnologías como PGP o similar, que a día de hoy siguen sin ser usadas de forma global por la complicación que implica el “compartir” las claves públicas. Lo mismo sucede si mandamos un archivo protegido por contraseña la otro extremo, tendríamos que mandarle la contraseña para poder ver dicho archivo. Eso significa que quien accediese tanto a nuestra bandeja de entrada como la de salida podría ver siempre el contenido de los correos.

-La comunicación se realiza de forma segura?? En su modo más simple no, al ser un texto plano, en cualquier punto se podría escuchar la comunicación y con ello el mensaje. La mayoría de servidores SMTP a día de hoy permiten realizar las conexiones por medio de TLS/SSL, pero… resuelve esto completamente el problema?? Tampoco, el mensaje podría llegar de forma segura al MTA, pero para que TODA la comunicación fuese segura, el MTA debería de mover el correo por su propia red de forma segura también, y transmitirlo al MTA destino de forma segura (que no todos los MTA origen/destino permiten), y el MTA destino por su parte volver a moverlo en su red interna de forma segura, y por último el destinatario recibirlo en su MUA por medio de POP/IMAP usando TLS/SSL. Por lo general el único dato que ve el usuario es si se conecta al servidor SMTP de forma segura o no, pero nada más, y eso es sólo el primer salto.

Pero quizás, el principal problema que se abre en el eMail, es la capacidad de poder crear un eMail desde el remitente que se quiera y poder enviarlo al destinatario que se quiera, es decir, la posibilidad de suplantar la identidad del remitente. Uno podría pensar que para que eso fuese posible se tendría que poder hackear/acceder a la cuenta de un usuario para poder enviarlo desde su cuenta, pero nada mas lejos. Sí, necesitaríamos acceder a la cuenta de un usuario para poder enviar un correo desde dicha cuenta DESDE EL MTA DE SU PROVEEDOR, pero… y si nos saltamos los pasos 1, 2 y 3 de la primera imagen?? Podemos consultar directamente el servidor de correo de cualquier dominio, es algo público, y podemos conectarnos a él directamente para dejar en su bandeja de entrada el correo que queramos, usando de remitente lo que nos de la gana. Y sí, es así de sencillo, tal y como suena. No hace falta decir la importancia de esto, de poder suplantar la identidad de un correo… es decir, poder mandar un correo a quien queramos haciéndonos pasar por cualquier otro..

Debido precisamente a esto, empezó una larga guerra contra el SPAM y el fraude, y se empezaron a crear mecanismos para combatir esto, lo que al final nos llevará a DMARC. Sí, es importante que la comunicación sea segura, pero cuando tenemos encima de la mesa la posibilidad de poder engañar a quien queramos, todo se centró en ello. Recordemos que hace ya tiempo escribí un artículo precisamente hablando de todo esto, de la suplantación del eMail que podemos ver AQUI. Así que hoy veremos precisamente lo contrario, como evitarlo en la medida de lo posible. Para ello vamos a ver las “armas” más habituales de las que disponemos:

  • “Filtro” IP del origen: Listas negras/grises/blancas
  • SPF
  • DKIM
  • DMARC

Antes de seguir, todo lo que veremos a continuación es interesante sobre todo desde el punto de vista de proveedores de correo de nuestros propios dominios. Es aplicable igualmente a los proveedores “públicos” como Gmail, Hotmail… pero estos sistemas son configurados y gestionados por ellos, con lo que usen o no SPF, DKIM, DMARC… no podremos hacer nada, no es algo que podamos habilitar o deshabilitar. Eso sí, recomiendo en este caso usar proveedores que realmente se tomen la seguridad en serio y apliquen los máximos estándares de seguridad.

 

Listas Negras/Blancas/Grises en función del Origen de la IP

Estas listas se llevan usando desde hace ya muchísimos años, y prácticamente todos los proveedores conocidos las usan de un modo u otro. No obstante, aun existen muchos correos empresariales o “domésticos” que carecen de ellas, y aun así, su utilidad como veremos es relativa.

La idea es muy simple… si en teoría cualquiera puede conectarse al MTA de cualquier dominio, vamos a configurar esos MTA para que sólo acepten conexiones desde IPs que ellos consideran legítimas. El problema es que Internet es dinámico, y que no puedes crear una lista blanca rigurosa, porque a fin de cuentas Internet también es “abierto” y cualquiera podría legítimamente querer enviar un correo desde su propio servidor a otra dirección. Así que estas listas se sostienen un poco siempre por pelos, aplicando reglas muy generalistas.

Por ejemplo, casi siempre se impide el entregar un mensaje a cualquier IP que en una de sus listas esté identificada como “dinámica”, pues se supone que si es una IP dinámica debe de ser un usuario malicioso desde su conexión el que quiere entregar el mensaje, y no un MTA legítimo. Otra norma habitual es meter en listas blancas los MTA mas conocidos de los proveedores de correo para asegurarse que estos no se filtren nunca, o meter en lista negra aquellas IPs o rangos IPs que se conocen que proceden de servidores con una fama bastante importante en el uso de SPAM y otros.

Pero como digo estas listas son de todo menos fiables, tal es el caso que por lo general puedes acceder a las web donde las gestionan para indicar falsos positivos, o registrar tu propia IP en caso de ser legítima, o que un rango que antes era sospechoso ahora es válido, o al contrario… Además estas listas no evitan el uso de conexiones Proxy desde otros lugares, es decir, un atacante podría estar realizando la conexión usando un tunel o un proxy o cualquier otra técnica desde servidores o redes que no estén filtradas, y creerme… no suele ser nada complicado encontrar una red o host que puda evadir estas listas.

Un ejemplo de estas listas son las que proporciona Spamhaus, pero hay muchas otras. Estas se implementan a nivel del MTA, comprueba la IP de la conexión que se está realizando y la cruza. Si esa IP intenta entregar un mensaje en dicho MTA y está en una de sus listas negras, denegará directamente la entrega. El mensaje no es que termine en SPAM, es que no atravesará siquiera el MTA de destino. Es un modo muy eficaz de filtrar, pero por desgracia no es muy efectivo cuando uno sabe bien lo que está haciendo. .

Además, este sistema tiene otro problema añadido… un usuario podría estar usando un proveedor de correo legítimo, y usar una conexión SMTP a su proveedor para colocar el mensaje en otro MTA modificando el remitente del correo. Este tipo de correos pasarían completamente este filtrado basado en listas, ya que la IP de origen sería la del MTA legítimo.

 

SPF

LLegamos a la primera gran parte de este artículo.

Pese a que la mayoría ni siquiera sabrá que existe, gracias a SPF me atrevería a decir que más del 80% de los correos SPAM y fraudulentos, acaban precisamente en las bandejas de SPAM, y no penetran a nuestras bandejas de entrada. Se creó como sistema de defensa ante precisamente los intentos de suplantación de correos. Por supuesto tiene sus puntos débiles y SPF no nos protege de todo, pero respecto a aquello para lo que fue diseñado, desempeña su papel muy bien.

Al contrario de como sucedía en el sistema de listas, SPF requiere de cierta configuración/preparación no sólo por parte del MTA de destino, que debe como es natural ser compatible con esta tecnología y poder tomar decisiones en función de SPF, sino que además el dominio del remitente del eMail debe de estar configurado y preparado para ello. Es necesario así un trabajo conjunto de las dos partes. El resultado en cambio es sorprendente. Aquí no se protege realmente a las cuentas de destino propiamente dicho, sino lo que se intenta es que a las cuentas de los destinatarios no lleguen correos que suplantan la identidad de otros dominios, con lo que realmente se está protegiendo a los dominios que quieren usar para suplantar.

Con las listas teníamos el problema de no saber nunca bien si la IP de quien enviaba el correo era legítima o no… SPF viene a solucionar este problema de raíz. Básicamente de lo que se trata es de configurar el servidor DNS del dominio de origen de los correos para indicar precisamente desde que direcciones IP/dominios se permiten enviar dichos correos. Esto puede sonar un poco lioso, pero es muy simple, veamos un ejemplo sencillo:

Sin SPF:

Digamos que Pedro, cuya dirección de correo es pedro@pedrito.com, usa Paypal para realizar compras, algo muy habitual a día de hoy. Bien, pues un atacante quiere intentar engañar a Pedro, y para ello quiere enviar un correo a Pedro haciéndose pasar por Paypal. Es muy facil, saca la dirección del MTA de pedrito.com con una consulta a su registro MX, y se conecta directamente al MTA para redactar su mensaje, y escribe lo siguiente:

mail from: Servicios Paypal <servicio@paypal.es>
rcpt to: Pedro <pedro@pedrito.com>
data

from: Servicios Paypal <servicio@paypal.es>
to: Pedro <pedro@pedrito.com>
subject: Verificación de contraseña

Por favor verifique su contraseña en el siguiente enlace, bla bla bla
.

Aun cuando el MTA de Pedro usase listas, si el atacante es listo habrá sabido como evitarlas, así que a todos los efectos el correo parece legítimo, a fin de cuentas cuando Paypal manda un correo legítimo a Pedro puede ser de echo exactamente igual. El correo podría entrar en la bandeja de entrada perfectamente, y Pedro hacer caso de lo que dice el correo, a fin de cuenta el remitente está claro que es Paypal.

Con SPF:

Supongamos el mismo caso, pero en esta ocasión el dominio paypal.es tiene configurado SPF. Evidentemente es igualmente importante que el MTA de Pedro sea compatible con SPF. Bien, Paypal que sabe la importancia y lo que le interesa de que nadie suplante sus correos, hace una pequeña modificación en su servidor DNS, y establece que sólo las IPs 100.100.100.0/24 (por poner un ejemplo) tienen autorización para mandar mensajes.

El atacante escribiría lo mismo y enviaría el mensaje, y se frotaría las manos pensando que lo ha triunfado. No obstante una vez enviado, el MTA que usa SPF, realiza la rutina pertinente. Lee el realm del remitente y anota la IP de este, en este caso paypal.es y pongamos que la IP del atacante fuese 1.1.1.1. Conecta a su servidor DNS (al de paypal.es) y busca a ver si existe un registro TXT que identifique como un registro SPF. Lo encuentra, y obtiene que sólo el rango IP 100.100.100.0/24 tiene autoridad para enviar correos con ese dominio. El MTA compara las dos IPs, ve que la IP del atacante no está dentro de las que el servidor DNS le ha dicho. Paypal indicaba una política estricta SPF (aparece en el mismo registro DNS), así que como no se cumple el criterio establecido, el MTA manda sin pensarlo el correo a la bandeja de SPAM de Pedro, y marca el mensaje con un FAIL en SPF.

 

Gracias a SPF los administradores de los dominios pueden garantizar, hasta cierto punto, que los correos que dicen ser de ellos, sean realmente de ellos, y que de lo contrario sean tratados como SPAM, o sometidos a un escrutinio mayor. La ventaja de SPF es que requiere de muy poco para cualquier dominio implementarlo, no requiere una configuración especial en su MTA, sólo requiere el poder añadir un registro TXT en su servidor DNS. La otra mitad será tarea del MTA de destino, que por cierto a día de hoy la inmensa mayoría usan

Como se hace?? Los registros DNS SPF son sencillos. Lo que necesitamos es crear un registro TXT con el siguiente formato:

"v=spf1 [IP/Dominios permitidos] [Politica a aplicar si no está en permitidos]"

Por ejemplo, si el correo de nuestro dominio está gestionado por Google Apps y queremos añadir como protección SPF, tendremos que crear un registro SPF que permita el envío de los correos por los servidores de Google Apps. Google nos dice que ellos aúnan todos sus rangos bajo el dominio _spf.google.com, así que si añadimos dicho dominio a nuestro registro SPF, realmente estaríamos añadiendo todos los rangos IP que existiesen en el registro SPF de dicho dominio. Pero esto sólo no sirve, con eso tendremos las direcciones que están permitidas, así que hay que decidir que se quiere hacer con aquellas que no cumplen dicho criterio

“v=spf1 include:_spf.google.com ip4:100.100.100.0/24 ~all”

“include:_spf.google.com” indica a otros MTA que reciban un correo de su dominio, que lo acepten si el origen de él está dentro de los registros SPF de _spf.google.com

“ip4:100.100.100.0/24” a lo anterior, se suma a aquellos correos cuyo origen se encuentre entro de ese rango IP

“~all” indica al MTA de destino que hacer con esos correos que lleguen de parte de su dominio en caso de no coincidir con alguna IP anterior. En este caso la tilde expresa un softfail, un fallo, pero no “radical”, a modo que el MTA destino lo tenga en cuenta a la hora de decidir si lo manda a SPAM o no. Si se usase un signo menos, sería un FAIL estricto. Por lo general suele ser más seguro un softfail, por si las políticas del MTA de destino son muy estrictas y eliminan directamente el correo, a fin de cuenta el administrador del dominio de origen podría a ver olvidado alguna IP o malconfigurado el registro SPF. También se podría usar el signo + para identificar un PASS o un ? para indicar un “Neutral”.

El MTA, en función de la política indicada por el dominio marcará dicho correo como Pass, Neutral, Softfail, Fail… y en función de dicho “marcado” actuará de un modo u otro, ya sea entregando el correo en la bandeja de entrada por creerlo legítimo, marcarlo como SPAM, simplemente ignorar SPF y usar otros modos AntiSPAM…

La mayoría de proveedores de correo usan SPF para aplicar diferentes políticas de SPAM. Por lo general cualquiera puede comprobar esto, sólo tiene que mirar la cabecera de cualquier correo que le llega. Tomemos por ejemplo uno de Paypal, y encontramos lo siguiente en su cabecera:

Received-SPF: pass (google.com: domain of servicio@paypal.es designates 173.0.84.226 as permitted sender) client-ip=173.0.84.226;

Es decir, Google ha marcado como Pass dicho correo, puesto que la IP del emisor, 173.0.84.226, dice estar dentro de las permitidas por el dominio origen, Paypal.es. Si mirásemos el registro TXT de Paypal, nos encontraríamos con un registro SPF donde se encontraría incluida dicha IP. Es decir, dicho correo ha sido enviado por un equipo que tiene permitido enviar correos en nombre de paypal.es, Google lo reconoce y lo trata como un correo legítimo.

SPF funciona francamente bien, no obstante no soluciona algunos otros problemas. Por ejemplo SPF no puede garantizar la integridad del mensaje, y basa “solo” su legitimidad en el origen de la IP, que como siempre puede ser relativo. Con esto en mente nació DKIM

 

DKIM

DKIM no viene a sustituir SPF, sino más bien a complementarlo, aplicando una capa de seguridad diferente. DKIM lo que realiza es básicamente un firmado digital del correo que se envía, de modo que el MTA de destino puede verificar su autenticidad leyendo la firma DKIM incluida en la cabecera del correo. Además, no solo puede verificar el dominio emisor, sino también si el mensaje ha sido modificado en lo más mínimo, ya que aunque se modificase una sola coma, la firma se invalidaría, con lo que también garantiza su integridad.

DKIM hace uso de infraestructura de clave pública (cifrado simétrico) para realizar el firmado. Debido a esto, por desgracia, no sólo nos vale con añadir una entrada en el servidor DNS, como hacíamos con SPF, sino que nuestro MTA debe de permitir DKIM, puesto que deberá de firmar todos los correos que enviemos con él. Si nuestro MTA no permite DKIM no podremos hacer uso de esta tecnología.

Como cualquier infraestructura de clave pública, para que funcione el sistema se requiere de una clave publica y una privada. En este caso nuestro MTA generará ambas, guardará de forma segura la clave privada y nos dará a nosotros la clave pública para que la pongamos en el servidor DNS a modo de registro TXT. La idea es simple… el MTA firmará con la clave privada todos los mensajes que enviemos, de tal forma que tan solo la clave pública asociada a nuestra clave privada podrá verificar la firma. Esto requiere que los MTA de destino puedan tener acceso a nuestra clave pública, así que esta es “publicada” en nuestro servidor DNS, a modo similar que se hacía con SPF.

Como toda firma digital, esta no solo verifica que el emisor del correo es efectivamente quien dice ser, sino que si en cualquier momento existe cualquier modificación del mensaje, la firma quedaría rota, con lo que el cliente podría darse cuenta.

Por supuesto tiene sus defectos, de ahí que lo ideal sea combinarlo junto a SPF. Por ejemplo, alguien podría interceptar el mensaje, modificarlo, cambiar el dominio de origen de la firma y volver a firmarlo con una clave privada propia. El MTA de destino podría ver que la firma proviene efectivamente de donde dice venir y la verificaría con su clave privada, mientras que el remitente seguiría siendo el del origen. Pero si se está aplicando al mismo tiempo SPF, este no daría por válido el origen de dicho correo, pues pertenecería a otra IP de las permitidas (a menos que dicha IP se recogiese también en SPF)

En este caso, no se usa DKIM tan extensamente como SPF para clasificar el correo como SPAM, pero sí para crear dominios de… “confianza”. Los MTA ponderan muchas variables a la hora de determinar si un correo es SPAM o no, ó peor incluso, si es un Phising/Scam. DKIM es el modo que tenemos de decir: Ei, este dominio es mío realmente y todos mis correos que voy a enviar van a ir firmados. Eso crea una cadena de confianza, y garantiza en la medida de lo posible que nuestro dominio no sea objeto de suplantaciones.

Como se configura un dominio para usar DKIM?? Bueno, como he dicho son dos partes. En primer lugar se debería de poder configurar el MTA para firmar los correos con DKIM. No todos los proveedores lo permiten, aunque la mayoría de ellos (al menos los más importantes) sí. Tomemos por ejemplo Google Apps, una vez configurado un dominio allí podremos instruir a Gmail para firmar los correos que enviemos desde nuestro dominio. El primer paso por tanto es iniciar la autentificación para dicho dominio que realmente lo que hará será crear las claves públicas y privadas, mostrándonos la clave pública que deberemos añadir a nuestro dominio en forma de registro TXT. Con dicha clave pública, tan solo tendremos que crear un registro TXT asociado a un selector concreto. Por normativa, DKIM almacena en el servidor DNS la entrada TXT bajo el subdominio asociado a dicho selector con el siguiente formato: selector._domainkey.midominio.es.

En “selector” podremos por lo general poner lo que deseemos, incluso podemos usar diferentes selectores, pero el resto es invariante. Esto es así porque cuando nuestros correos se firmen el MTA de destino debe de conocer donde mirar para obtener la clave pública, y el único dato que se suministra en la firma es el selector. Es decir, si usamos en Google Appls como selector “google”, tal como estoy diciendo, la clave pública se podría consultar mirando los registros TXT del dominio en cuestión en google._domainkey.midominio.com. Hagamos la pruena… cojamos cualquier correo que nos hayan enviado desde Gmail y miremos su cabecera. Ahora busquemos en la cabecera la firma, puesto que por suerte y por seguridad todos los correos de gmail se firman, y nos encontramos con esta sección:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
        bh=nzLCaIESeBg8KtAGcaKCJbAggDVfBjZVSa6oLSVMOfU=;
        b=HBNSvMfDejs8TIHnh3vtDeXrtYuRKNivRUm4WMlBo7HWc7+ClZTVosOwheoajzuXZ8.. 

la d indica que dominio está firmando el correo, la s es el selector, la bh el hash del cuerpo del mensaje, la b la firma… Con esos datos, el MTA de destino puede acceder a la clave pública asociada a la clave privada que firmó el correo:

dig 20120113._domainkey.gmail.com txt

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;20120113._domainkey.gmail.com. IN      TXT

;; ANSWER SECTION:
20120113._domainkey.gmail.com. 299 IN   TXT     “k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87…”

Como digo, cualquiera puede hacer la prueba, y ver si los correos que le mandan usan DKIM o SPF, o ambos. Os sorprendería ver la cantidad de proveedores que incluso a día de hoy no usan estos sistemas. Esto toma aun importancia mayor en el mundo empresarial, por lo general usan proveedores o servicios de correo muy deficiente y con unos estándares de seguridad de risa. El uso de DKIM o de SPF debería de ser de obligado cumplimiento para cualquier administrador más o menos competente.

Por desgracia no siempre es viable DKIM. Mientras que por lo general SPF suele ser bastante simple de implementar y general pocos problemas (algunos sí), DKIM es más limitado. Muchas veces no sólo usamos nuestros MUA o el acceso web para enviar correos desde nuestro dominio, muchas veces hacemos uso de herramientas como PHP Mail() que suele ser raro que firmen los correos y además conocer bien el dominio de origen, o usamos forwarders de correo para enviarlos de un lado a otro con lo que no siempre se respeta las cabeceras  o a lo mejor una suite AV en el servidor del trabajo que analiza todos los correos al llegar y modifican su cuerpo indicando que ha pasado ciertos controles, rompiendo también DKIM. Y todo ello sin contar con la aun gran cantidad de servidores que no lo usan, ya sea porque no pueden configurarse para firmar los correos o ya sea porque cuando les llegan correos firmados no realizan ningún tipo de verificación.

 

DMARC

Por último, llegamos al némesis del SPAM y de la suplantación de correo. En realidad DMARC es más la unificación de SPF+DKIM trabajando juntos que una tecnología propia. SPF es muy efectivo para filtrar los correos ilegítimos, DKIM es un genio validando los correos y asegurando si integridad… los dos juntos pueden hacer muy complicada la labor al hacker de turno poder usar un dominio protegido correctamente con fines de SPAM o suplantación de identidad. DMARC no requiere de ambos modos, pude usar uno, el otro o ambos, a fin de cuenta como hemos dicho no siempre puede usarse SPF y no siempre puede usarse DKIM. Hay que entender que nosotros con nuestro dominio podemos enviar un correo desde el mediante infinidad de formas como se ha dicho… podríamos enviar un correo del modo tradicional por SMTP, podría enviarlo el servidor Web que tenemos para enviar notificaciones, podría ser usado nuestro dominio para usar listas de distribución usando servicios externos, o usar servcios de correo marketing como MailChimp para el envío masivo de correos, y todos ellos usarían direcciones de nuestro propio dominio!! Es decir, a veces algunos de los correos incluso que mandemos de forma legítima no seremos capaces de protegerlos mediante SPF y DKIM. DMARC pude ser suficientemente inteligente para entender estos pormenores.

Pero al margen de este baile entre SPF y DKIM, DMARC tiene algo que no tiene ninguno de los sistemas vistos hasta ahora. DMARC está preparado para que sí así lo configuramos, indicar al destinatario que si no es capaz de lograr un “pass” en DMARC, el correo lo tome por ilegítimo y LO ELIMINE. Es decir, no a SPAM, no a devolver, simplemente eliminación silenciosa de él. Os lo imagináis?? Si por un momento todos los proveedores de correo usasen correctamente DMARC y Paypal usase esta tecnología correctamente, cualquier que intentase falsificar un correo haciéndose pasar por paypal cuya dirección de correo fuese loquesea@paypal.es, jamás llegaría a su destino, el dominio de Paypal quedaría prácticamente blindado y nadie podría usarlo de forma ilícita. Sí, podría usar otro correo parecido, pero no el mismo dominio.

Otra característica especial de DMARC que lo hace único, es que se diseñó de tal modo que los MTA de destino compatibles con DMARC generan reportes diarios que envían al origen del dominio indicando datos valiosísimos, como por ejemplo la cantidad de emails que ha llegado a sus puertas usando dicho dominio, cuantos lograron pasar DMARC y si pasaron SPF o DKIM o ambos… y todo esto es de forma casi automática, el MTA de destino cuando lee un correo con DMARC (y si es compatible con él), además de leer los datos SPF  y DKIM también accede al servidor DNS para recuperar los datos relativos a DMARC, y de allí saca la política a aplicar y como tratar DKIM y SPF de dicho correo, y por supuesto la dirección de correo a la que enviar los reportes diarios. Nada se escapa a DMARC.

Como de útil es esto de los reportes?? Esencial. Los MTA de destino no tienen por qué ser compatibles con DMARC y por tanto generar reportes, pero si tenemos en cuenta que la mayoría de cuentas a día de hoy son correos tipo Gmail, Hotmail, Yahoo… y que todos ellos lo hacen, podemos tener una visión bastante buena de si se están usando nuestros dominios para fines de suplantación o no. Si a esto le sumamos que existen herramientas que nos permiten centralizar todo esto y ordenar y analizar nuestros reportes, el resultado es más que interesante. A continuación algunas imágenes de unos cuantos dominios que tengo que usan DMARC (Y SPF/DKIM):

En primer lugar, para los que creen que eso de suplantar identidades es cosa del pasado y que nadie se centra en hacer estas cosas… esta primera imagen da una visión general, y viene a decirnos que sí, que es necesario usar este tipo de tecnologías:

Captura

Como vemos en la leyenda, en verde tendríamos aquellos correos que fueron enviados y el MTA de destino pudo dictaminar que pasaban DMARC, y por tanto eran legítimos. En un porcentaje pequeño lo que llamamos forwarders, por lo general son correos legítimos pero que son reenviados por diferentes hosts para fines diversos. Y por último en rojo aquellos que fueron enviado supuestamente en nombre de nuestros dominios, pero que al comprobarlos los MTA de destino dictaminaron que no podía pasar DMARC. En todos los casos esta información se extrae de los reportes generados por los MTA de destino, y aunque en dichos reportes no se indica como es natural destinatarios o cuerpos de mensajes o… si se indica las direcciones IP de origen, entre otras cosas, con lo que podemos ver también que host/dominio está enviándolos. Como vemos, en estos 7 días de intervalo seleccionado, yo diría que un 40% han sido correos no legítimos. Dado que ninguno de mis dominios usa actualmente una política DMARC de rechazo, esos correos posiblemente lleguen aun todos ellos a los destinos, aunque casi seguro siempre a la bandeja de SPAM. Con el tiempo, cuando cambie a una política más restrictiva, ninguno de esos correos llegará siquiera a los destinatarios.

En segundo lugar vemos realmente todos los correos que se han enviado clasificados según su origen, y a la derecha un dato interesante… todos ellos pasaron DMARC, pero no significa que todos pasasen simultaneamente SPF y DKIM. Dado que las reglas de mis dominios son “laxas” DMARC puede pasar cuando uno de ellos falla.

Captura2

Por ejemplo, vemos que los que se origina en Godaddy cumplen el 100% SPF, pero no se firman. En cambio con MailChimp pasa exactamente lo contrario, todos son firmados pero SPF no pude verificarse… esto sucede porque MailChimp usa varios dominios como origen, y aunque se pueden añadir las diferentes IPs, el dominio emitido por MailChimp no coincide con el usado en el remitente real, así que SPF falla.

Podemos ver algo similar con los Forwarders:

Captura3

Los Forwarders reenvían los correos, generalmente esto no es malo, lo que pasa es que no todos funcionan igual. Por ejemplo hay Forwarders que preservan la firma y no la alteran, mientras que otros alteran el cuerpo del mensaje de algún modo y rompen la firma.

Y para acabar, por supuesto, tenemos aquellos que quieren usar nuestros dominios como origen de correos fraudulentos:

Captura4

Y no, no son pocos.

 

Desde el punto de vista del administrador del dominio, no requiere nada para habilitarlo en su dominio, sólo crear la entrada TXT correspondiente en su servidor DNS, similar a como se ha realizado anteriormente. Eso sí, si el MTA de destino no es compatible con DMARC simplemente ignorará las directrices configuradas en el registro TXT del servidor de correo, y tampoco generará reportes.

Un ejemplo real de esto.. supongamos q pedro@pedrito.com usa DMARC, y manda un correo a lacasito@gmail.com. Gmail es compatible con SPF, DKIM y DMARC. Pedro firma su correo por DKIM y también usa SPF y DMARC. Cuando el correo llega a Gmail: a) Verifican que SPF es correcto como hemos comentado antes, y lo marca como superado (Pass). b) Verifica la firma y la integridad del correo como hemos dicho anteriormente, como es correcto de nuevo lo marca como superado (Pass). Por último, mira las políticas DMARC que hace Pedro, y lee algo como:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Dado que tanto SPF como DKIM han dado de resultado un superado (Pass), y no hay nada que impida en las políticas DMARC de pedrito que falle DMARC, DMARC se marcará igualmente como superado, y Google enviará un correo a reportes@pedrito.com al final del día con todos los correos que fueron enviados por direcciones de pedrito.com a sus servidores.

Pero que pasaría si DKIM o SPF fallan?? Bueno, aquí depende de como se configuren las políticas. Por defecto, son relajadas, si fallase alguna de las dos por lo general DMARC seguiría siendo superado, aunque como digo esto puede configurarse. Y que pasa si DMARC falla?? Si falla se aplica la política que hay en el registro DNS. En el caos anterior aplica la política “reject”, es decir… si DMARC falla el MTA de destino debe de borrar el correo, rechazarlo. Se podría usar none, y simplemente DMARC no haría “nada”. Esto es muy útil sobre todo al principio de implementar DMARC, a fin de cuenta si de primeras decimos que se rechacen, posiblemente perderíamos muchos correos legítimos por una mala configuración de DKIM/SPF o de alguno de nuestros servicios. Es práctica común usar “none” durante un tiempo de meses, comprobar que funciona todo bien, y pasar poco a poco a rechazarlos.

El formato a usar en el servidor DNS es similar a los anteriores, aunque en este caso de nuevo por normativa se usa el subdominio _demarc. Es decir, que la entrada DNS irá ubicada en _dmarc.midominio.es. Hemos visto arriba como sería, en su versión más simple:

“v=DMARC1; p=reject; rua=mailto:reportes@pedrito.com”

Donde p es la política y rua la dirección de correo para los reportes.

Cualquiera que mire la cabecera de un correo que le ha llegado, pude igualmente ver si su MTA verifica de algún modo estas tecnologías. Por ejemplo si miramos un correo entrante de una cuenta de google.coml, vemos algo así (aunque sería similar en las de GMAIL)

Authentication-Results: mx.google.com;
       dkim=pass header.i=@google.com;
       spf=pass (google.com: domain of ...;
       dmarc=pass (p=REJECT dis=NONE) header.from=google.com

Vemos que Google, en los correos de sus dominios si fuerza una política de Reject. Esto hace que si alguien intenta usar su dominio para falsificar una dirección de correo en su remitente, el MTA de destino si es compatible con DMARC lo eliminará instantáneamente. Vemos igualmente que ese correo ha logrado pasar DKIM, SPF y por tanto DMARC


 

Conclusiones

De verdad aun hay quien cree que no necesita saber nada sobre SPF/DKIM/DMARC?? Está claro que para los usuarios que usen correos ordinarios tipo gmail, hotmail y otros no es tan importante, además ellos no pueden configurar nada, solo tener la esperanza que sus proveedores usen los mejores estándares de seguridad. En este caso Gmail posiblemente es pionero, mientras que Hotmail por ejemplo no los firma y bla bla bla. Pero para el resto de usuarios que usan cuentas personalizadas, o empresariales, o de cualquier otro tipo, es aun más importante usar estas tecnologías. A fin de cuentas, al final, cualquier usuario puede crear una cuenta de gmail o hotmail para enviar o intentar enviar correo falsificado a otra cuenta con el mismo dominio, pero nadie puede crear cuentas de un dominio propio. Además, es evidente que es mucho más… jugoso para los hackers/spammers y otros atacar cuentas personales/profesionales independientes, sobre todo a la hoar de intentar suplantar la identidad de alguien.

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

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…

Fibra Óptica y su implantación en España

fibraoptica

“¿Tienes fibra? ¿Has puesto ya fibra? ¿sabes algo de como va lo de la fibra?

fibra fibra fibra… llevo un año escuchando estas preguntas una y otra y otra y otra… así que, vamos a ver un poco de fibra fibra y fibra.

La tecnología siempre avanza, ya sea en pos de progreso o en pos de la cuenta bancaria de las empresas que las despliegan, pero sea como sea no para. Por suerte para nosotros esto también sucede en las telecomunicaciones, y en mayor o menos medida (y antes o después) nos beneficiamos de ello. A veces es la invención de algo totalmente novedoso y “mágico”, otras veces no es más que poder aplicar de forma práctica y masiva algo bien conocido. Es el caso de la fibra óptica. ¿Por qué hoy? Bueno, quizás porque hace un año era todo el marketing orientado al 4G (que no es 4G sino que es LTE como ya hemos dicho más de una vez), y llevamos ya unos meses en los que el marketing se a ido a la comercialización de la Fibra óptica en los hogares. Para mucho está claro que es y que no es… otros no lo tienen tan claro. De cualquier modo, vamos a ver cosas que posiblemente sepa todo el mundo y cosas que posiblemente sólo sepan un grupo muy reducido. Cosas muy útiles, cosas que no necesitamos y quieren que paguemos, cosas curiosas…

 

¿QUE ES?

Posiblemente la mayoría de las personas sepa que es la fibra óptica a estas alturas, aunque es cierto que la mayoría nunca la ha visto realmente. La fibra óptica en su sentido más amplio es nada más y nada menos que otro sistema de transmisión de información, que en este caso usa para tal transmisión lo que realmente denominamos “fibra óptica”, un filamento muy fino (puede ser más fino que el pelo de un cabello humano), que puede ser de vidrio o de plástico, generalmente muy transparente. Esta fibra hace la función de “cable” en el sentido de conectar dos extremos para compartir información entre ellos, pero a diferencia de los cables ordinarios estos no portan electricidad, tan solo transportan fotones (luz).

Su funcionamiento es “sencillo” de explicar. Usando las propiedades de reflexión (cuando nos miramos en un espejo, la luz se refleja) y de refracción (cuando metemos un boli en un baso de agua y parece que este cambia de dirección y se dobla, la luz se refracta), se usa las fibras ópticas para dirigir y contener el haz de luz que viaja por él. La luz se va reflejando en ángulos muy muy elevados sobre el núcleo de la fibra, haciendo que esta llegue al otro extremo. Pero la luz en sí misma no transmite información útil por así decirlo, en el mundo digital necesitamos a fin de cuenta ‘1’ y ‘0’, ¿cómo se hace para transmitir información por ese medio entonces? La luz no deja de ser una onda electromagnética con la frecuencia que sea. Si emitimos cualquier sonido o cualquier haz de luz a una única frecuencia y de forma constante no podemos extraer nada de ello, y si fuese sonido como mucho escucharíamos un tono constante. Pero si introducimos a esa frecuencia otra frecuencia desplazada tan sólo ligeramente, veríamos como ese sonido (en caso de ondas sonoras) pasaría mágicamente a ser pulsante, y la onda lumínica tendría un comportamiento similar. Ver esto gráficamente es sencillo, pero no deja de ser física y más física… y sería meternos en campos de otros.

Resumiendo lo anterior, gracias al desfase de diferentes frecuencias de la luz dentro de la fibra se logran producir esos “pulsos”, y a fin de cuentas nuestros “unos y ceros”. Cuanto mayor sea el número de frecuencias en las que se puede operar, menor será la longitud del pulso producido (por así decirlo), y por tanto al final una capacidad de transmisión de información mayor. Esto hace de la fibra óptica a día de hoy el sistema de transmisión de información más rápido del que disponemos (que yo conozca al menos).

Este invento dista mucho de ser nuevo, y la fibra óptica viene usándose desde hace décadas. De echo aunque la mayoría a lo mejor no lo sepa, las comunicaciones mundiales a día de hoy se realizan al final en sus tramos troncales por fibra óptica:

Cableado de fibra europeo

A groso modo lo que vemos ahí son las líneas de comunicación troncales (de borde) de Europa, cableado de fibra óptica que conecta básicamente continentes, países… entre sí de forma subacuática. Muchos creen que las comunicaciones se realizan via satélite, pero lo cierto es que el grueso de todo lo enviamos/recibimos por el mundo digital viaja por alguno de las ramas que vemos en este mapa.

No, rotundamente no, no es nuevo. Pero entonces… ¿por qué  ahora tanto bombo con las redes de fibra? Bueno, quizás la fibra sea el modo más eficiente y rápido de transmitir información, pero también tiene muchos inconvenientes. El precio de los equipos necesarios, de la propia fibra, una flexibilidad muy inferior respecto a otros modos de transmisión por cable, una alta fragilidad, complejidad para realizar reparaciones por cortes o fracturas o empalmes… esto ha hecho que la fibra no se haya usado hasta muy recientemente para dar servicio a usuarios domésticos. El abaratamiento de los componentes, la mayor calidad de estos… y por supuesto la cada vez más acuciante necesidad de sustituir nuestro viejo amigo “el par de cobre”, ha hecho posible que las grandes telecos hayan empezado a desplegar de forma masiva sus redes de fibra óptica.

 

¿QUE NOS APORTA? ¿LO NECESITAMOS?

La respuesta rápida y sencilla?? Nos aporta bastante, pero la inmensa mayoría no lo necesita… ni ahora ni en mucho tiempo.

Llevamos meses en los que no paran de bombardearnos con maravillosas ofertas convergentes de fibra que incluyen televisión, móvil… cualquier coas es poco para “picar” y contratar sus súper paquetes de todo incluido. Que si 50mb, que si 100mb, que si mejor que sean 300mb con todos los canales que quieras… pero todo cuesta dinero, y lo primero que tenemos que pensar es si realmente necesitamos o no los nuevos servicios, si estamos dispuestos a pagar por ellos y si técnicamente vamos a poder disfrutarlos.

No me mal interpretéis, lo primero que he dicho es que sí nos aporta bastante, pero realmente la mayor aportación que puede tener para nosotros es realmente la, por fin, independencia del viejo par de hilos de cobre que lleva acompañándonos desde hace muchos muchos muchos años. De echo me parece sorprendente que haya sido capaz de aguantar tanto, y como se fueron creando tecnologías para poder seguir usando nuestro viejo amigo… las conexiones ADSL (la inmensa mayoría al menos en nuestro País) han logrado llegar gracias a ADSL2+ hasta los 24mb/s que no es poco, incluso algún operador ha comercializado en España VDSL con el que es posible alcanzar los 100mb/s en su versión de VDSL2. Pero el cobre tiene dos o tres desventajas enormes con las que hemos tenido que luchar a diario:

a) Distancia: La velocidad máxima alcanzada por ADSL/VDSL está totalmente asociada a la distancia hacia las centralitas, padeciendo de una atenuación enorme en función de esta. Esto ha hecho que aunque todos los operadores nos han ofrecido desde hace ya tiempo conexiones de “hasta 24mb”, sabemos bien que esa velocidad tan sólo podría disponerla quien tuviese la suerte de vivir justo al lado de la centralita. La mayoría de las personas se han tenido que contentar siempre con 6-10Mbs, y eso sin entrar ya en entornos rurales, donde el ADSL era casi una utopía.

ADSL_Line_Rate_Reachb) Redes Viejas: El cobre que prácticamente disponemos todos, sobre todo las redes principales, son viejas, muy viejas. ADSL/VDSL padece enormemente de cualquier interferencia electromagnética, y deterioro de las instalaciones. Esto puede ser tan significante que un cableado nuevo a otro viejo puede marcar una diferencia de varios mb/s.

c) Ancho de banda limitado: Aunque se han logrado alcanzar velocidades muy altas, no son comparables ni pueden acercarse a otras tecnologías de transmisión de información, como pueda ser la fibra óptica. Mientras que el VDSL teóricamente pueda llegar a los 100 megabits por segundos, un sólo hilo de fibra estaría limitada (físicamente, no creo que jamas se alcance dicho límite),en unas decenas o centenas de Terabytes por segundo

Por tanto la ventaja más evidente que tenemos es la sustitución del cobre por un canal totalmente nuevo, moderno, y con unas posibilidades a largo plazo enormes. Las telecos también ganan, mantener la nueva red de fibra es más barato que mantener la red de cobre, aun con las complicaciones que acarrean las reparaciones cuando una fibra se parte. Además pueden ofertar servicios que de otro modo serían imposibles.

Lo curioso es que la mayoría de todas las ofertas con las que nos bombardean poco nada dicen de que estos serán los beneficios más evidentes, ellos prefieren indicar en grande la velocidad que tendrán nuestras conexiones de fibra. Que si fusión 300Mb/s con televisión con Movistar, que si pack ahorro 200Mb de Jazztel, One Fibra de Vodafone/ONO (OJO!! NO ES FIBRA OPTICA, es CABLE)… y se olvidan de indicar algunas cuestiones que son realmente las más importantes:

a) Quitando algunos servidores webs en los que podamos descargar muy rápido archivos pesados y algunos programas P2P, el aumento de velocidad pasará desapercibido para la inmensa mayoría. La navegación web, vídeos, redes sociales, mensajería, correos… lo que es el 95% del tráfico en Internet después de todo, no vamos a notar una mejoría de tener 20Mb/s a tener 300Mb/s. Esto es muy sencillo, si es una web, ya os digo que la mayor parte del tiempo que pasamos mientras que accedemos a la web o no, recae en latencias, el propio navegador web, peticiones HTML… La velocidad la notaremos principalmente cuando realicemos descargas directas, y siempre y cuando los servidores desde los que los descarguemos tengan capacidad para ello.

b) La mayoría de todos los equipos que conectamos a nuestros “routers” a día de hoy es por WIFI, Ya sean televisiones, teléfonos, PCs, portátiles, tablets… Esto no es malo, hemos logrado prescindir de cables… el problema es que me atrevería a decir que ni siquiera un 2% de la población dispone de equipos WIFI cualificados para altas velocidades. En el mejor de los casos dispondrán de dispositivos 802.11n capaces de 150-300Mb/s, pero WIFI no es Ethernet. Si tenemos contratados 300Mb/s por fibra y el router que nos instalan en el mejor de los casos es 802.11n con dos streams haciendo un total de 300Mb/s, eso no significa que podamos disponer de esos 300Mb/s. Primero nuestro equipo tendría que disponer igualmente de una interfaz 802.11n al menos similar (la mayoría que hay ahora mismo son G, y los N mayoritarios son de 150Mb/s). Después, esa es la velocidad máxima hipotética, sólo en un sentido de transmisión (no es full duplex) y sin ningún otro cliente WIFI transmitiendo. Dicho de otro modo, si tienes un cliente y router WIFI de 300Mb/s, en el mejor de los casos, pegado totalmente al router y sin ningún otro dispositivo WIFI, tendrías una velocidad de 10-15MB/s, lejos de los 38MB/s aproximados que puede darte tu línea de fibra de 300Mb/s, (y de ya os digo que lo normal es que se tengan velocidades de 4-7MB/s en instalaciones domésticas normales. Por supuesto este problema no sucede en conexiones Ethernet, donde los routers que nos instalan si son (o deberían de ser todos) GigaEthernet (y a diferencia de WIFI pudiendo trabajar todos los puertos que tiene en Full Duplex simultaneamente), con lo que no tendría que tener problemas en manejar los 120MB/s (ojo, B grande, Bytes, no bits)

Para poder hacer uso de redes de datos de estas velocidades por WIFI a día de hoy es casi imperativo disponer de adaptadores 802.11ac, capaces de transmitir desde los 400Mb/s hasta más de 2000Mb/s, siempre y cuando evidentemente tengamos el equipo adecuado. De lo contrario, o usamos conexiones GigaEthernet o da igual que nos dupliquen la velocidad o la tripliquen, porque por WIFI NO VAIS A PODER disfrutarla en ningún caso.

80211ac_coverage

c) Instalación y cobertura. Nos guste o no es un cable nuevo, y eso requiere una instalación por parte de profesionales. Eso implica primero que nuestro hogar o empresa debe de tener suerte y estar dentro de los municipios por los que en principio se están haciendo los despliegues. Pero el despliegue es lento, llevará años tener cableado como dios manda el País. No podría decir en porcentajes pero no creo que tenga ahora mismo acceso a la fibra óptica (sea cual sea el operador) más de un 10-15% de los habitantes. Por otro lado la instalación es necesaria, y esta puede no ser tan sencilla en muchos hogares. Sí, está claro que muy a las malas puede coserse el cable por la fachada y meterlo hacia el interior por cualquier orificio (o hacer uno), pero esto no suele siempre ser viable o bien visto por muchos. Además depende en gran medida de la pericia del instalador y en los buenos términos que puedas llevarte con él para planificar el mejor modo de instalarla… y ya os digo que a veces es lo más sencillo del mundo, y otras veces es lo más complejo.

d) Recordar que la fibra óptica que se usa aquí en España (y no cuento con la fibra/cable de ONO) prescinde totalmente del cobre, y con ello como habréis imaginado de las redes de teléfono convencional. ¿Esto quiere decir que nos quedamos sin teléfono? No, esto quiere decir que ahora el teléfono pasará a ser sí o sí por VoIP, y esto puede ser muy bueno, bueno, malo o nefasto.

En el escenario ideal, el ONT del operador o el router dispondrá de una toma de teléfono estandar que se podrá conectar a una roseta RJ11 (las de toda la vida) directamente para dar servicio al resto de rosetas de la casa. En escenarios en los que la roseta de teléfono no sea accesible tendremos que conectar directamente el teléfono a dicha toma, con lo que deberemos de dispone de algún juego de teléfonos inalámbricos en la mayoría de los casos.

El teléfono estará alimentado por el propoio router/ONT, si la luz se va en nuestra casa/edificio, perderemos igualmente el teléfono.

Inicialmente la calidad era mala, a día de hoy si la VoIP está bien configurada en los equipos (y debería) la calidad suele ser superior a las que podíamos realizar con anterioridad, además de poder realizar algunos “trucos” de los que hablaremos más adelante, como por ejemplo poder llevar tu número fijo en el móvil.

Aunque duela decirlo, lo cierto es que sea A o sea B, la mayoría de usuarios que disponen de fibra a altas velocidades no disfrutarán a corto plazo sus beneficios. Por supuesto esto no es una norma, y la tecnología funciona realmente. Para aquellos usuarios que dispongan de equipos competentes, conexiones por cable directo, conocimientos competentes… por supuesto podrán beneficiarse de estas altas velocidades. Por ejemplo, para mi en lo personal, el mayor beneficio no viene siquiera de la velocidad de descarga sino de la subida, que ahora mismo rondan desde los 3Mb/s hasta los 30Mb/s (una décima parte de la velocidad de subida en algunos operadores, simétrica en algunos otros). Las mejoras en VoIP o incluso el poder disfrutar de servicios de IPTV (televisión via IP) son puntos importantes a tener en cuenta, pero de nuevo posiblemente no van orientados a una mayoría.

El ADSL morirá posiblemente antes que tarde, pero es probable que sea más por el marketing y la obsesión de la mayoría de querer tener lo mejor que por necesidad. Esto no es malo del todo porque gracias a esto tecnológicamente nos desarrollamos antes, pero es malo porque mata la inteligencia de muchos… hay que tener bien claro que es lo que se necesita, que es lo que van a darnos y como lo vamos a tener. A raíz de eso tomar la decisión que creamos, pero por dios… que no sea para poder fardar a los amigos/compañeros con el: “Es que yo tengo 100Mb/s… pues yo tengo 300Mb/s…” Seamos serios…

 

QUE NOS INSTALAN, COMO ES LA INSTALACIÓN

Vale, a pesar de todo nos decidimos a instalar fibra en casa, después de todo nuestra instalación de cobre es vieja y no nos da más que unos “escasos” 6Mb/s. Además hemos echo los deberes, hemos comprado equipo de altas prestaciones, router 802.11ac que sabemos configurar para nuestro operador, adaptadores wifi ac…  no son necesario porque nuestro operador nos dará el equipo necesario, pero como hemos dicho este equipo es tan solo viable en el mejor de los casos conectado a él por cable. Sabemos que tenemos cobertura y damos el salto… damos el alta, decimos por donde queremos realizar la instalación… y empieza el show.

 

INSTALACION

¿Realmente la fibra optica es un cable dedicado por cliente? ¿Es fibra óptica en todo su recorrido desde las centrales de ellos hasta nuestros hogares?… Bien, a modo particular voy a hablar de como funcionan las instalaciones de Movistar porque las conozco de primera mano, pero casi con seguridad el resto de ISP poseen infraestructuras similares.

En primer lugar, la fibra que se instala se llama FTTH (Fiber To The Home). Este tipo de instalación significa que desde el inicio del recorrido hasta terminar conectado al propio ONT (Terminal de red óptico) todo es fibra. El ONT es lo que en fibra nos hará la función del viejo modem (que no router), y básicamente se encarga de recoger las señales ópticas que recibe, separar los servicios que circula por estas convertirlas a tramas Ethernet, como pueda ser Internet, VoIP o Televisión). Todo ello se pasa directamente al router que nos da servicio. Esto es interesante porque garantiza en realidad la máxima fiabilidad y prestaciones, no son instalaciones en las que la fibra tan solo llega a medio camino y de ahí al usuario va por otro tipo de medios, en este caso el propio cable de fibra óptica muere en el mismo ONT… en realidad muere en la roseta óptica, y de esta sale un pequeño latiguillo al ONT, también de fibra óptica.

No obstante, como era de esperar, el cable de fibra que sale desde la central hasta nuestro hogar no es dedicado. En este caso es comprensible, un sólo cable de fibra por cliente sería desaprovechar mucho ancho de banda, sobre todo para ellos, con lo que este cable sufre en dos ocasiones diferentes dos divisiones. El esquema general sería el siguiente:

FTTH-localizacion-de-los-splitter_3

La instalación se despliega desde las centrales, del que sale todo el cableado de fibra (usando monomodo). En su camino sus primeras paradas son las cajas de registro (CR), que componen la estructura principal de la red de fibra. En estas cajas de registro se efectuaría de ser necesario el primer nivel de división de los cables de fibra, usando splitters de 1×4 o de 1×8 según se requiera. Esto significa que un solo cable de fibra se dividie en 4 u 8 nuevos cables de fibra, y esto es importante, TODOS ELLOS CONTENIENDO LA MISMA INFORMACIÓN. Desde las cajas de registro se distribuye la red en lo que se llama red de distribución precisamente, que acaba por lo general en zonas residenciales en las que se coloca la “Caja Terminal”. Estas cajas son bastante visibles, se colocan por lo general en exteriores comunes a la vista de todos, aunque fuertemente protegidas y resguardadas de los elementos, y totalmente estancas. Aquí se realiza el segundo nivel de división, y en esta ocasión se realiza por medio de spliters de 1×8 o 1×16, es decir, se vuelve a dividir cada fibra en 8 o 16. En cualquier caso, combinados ambos niveles de spliters, cada cable de fibra original al pasar por los dos divisores se convertirán a lo largo de todo su recorrido hasta un máximo de 64 fibras, o dicho de otro modo, Movistar por cada fibra que sale de su central puede alimentar y dar servicio a 64 hogares, Y A TODOS ELLOS LLEGA LA MISMA INFORMACION. Las cajas de registro pueden dar servicio a muchos más hogares de 16, pero son cajas a las que llega más de una fibra. Todo esto es tan solo el camino que recorrería una fibra, no significa que en una CR o una caja de registro sólo pueda ir una fibra.

Por lo general la instalación base de la red termina aquí, y empezaría la instalación propia del cliente. Cuando se requiere la instalación de la fibra, se tira un cable desde el hogar/trabajo del cliente hacia la caja terminal. En la caja Terminal se realiza una fusión del nuevo cable con una de las salidas del splitter que aun quede disponible, y en el hogar/trabajo del cliente se introduce el cable por el modio que sea, y este termina en una roseta óptica, en la que se realiza de nuevo la fusión del cable con un pequeño pigtail que posee la roseta, dando por terminada la instalación. El resto es proceder a la colocación de los equipos y conectar por medio de un latiguillo de fibra la roseta óptica y el ONT.

Cuando hablo de fusión hablo de fusión. La fibra no puede “empalmarse” al modo tradicional al que estamos acostumbrados. Antes queríamos sacar una nueva roseta y tan sólo cortábamos el cable, cogíamos otro par de cables de cobre y uníamos de 1 a 2. Esto es imposible en fibra, de echo para hacer eso sería necesario un spliter. Incluso para la reparación por corte/fractura, no podemos simplemente acercar las puntas y enroscaras, no sólo porque se partiría, sino porque la luz viaja por dentro del núcleo de la fibra, no puede interrumpirse o saltar o… es necesario disponer de equipos especiales que sean capaces de fundir ambos extremos que quieran unirse, formando de nuevo un ininterrumpido filamento de fibra.

Como dato de interés, decir que cada cable que sale de la central hasta los 64 clientes que puede alimentar circula la misma información. Es decir, que al ONT de cada usuario llega igualmente toda la información que se envía y se recibe por los otros 63 ONT que pueden estar en funcionamiento, este simplemente discrimina todo el tráfico que no es el que va dirigido a él. Interesante por qué?? Bueno… imaginad que pasaría si de algún modo se le pusiese decir al ONT que dejase de discriminar el tráfico y que quisiésemos que entrase TODO… lo nuestro y lo del resto de 63 clientes.

 

EQUIPOS

Los equipos necesarios son en realidad muy similares a los que posee cualquier conexión DSL. Muchos ven que con fibra les instalan dos dispositivos diferentes mientras que con sus líneas DSL tan sólo disponían de uno. Esto es sólo una media verdad. La mayoría de particulares DSL poseen tan solo una puerta de enlace residencial para ahorrar espacio y porque es más económico a los ISP, el propio aparato integra un Modem al que se conecta el par de cable, un router que da servicio a la red de casa y un punto de acceso WIFI para… para dar wifi. En el caso de la fibra óptica no hay un modem… al menos no en el significado clásico, pero el ONT podemos verlo como tal, un “modem óptico” que además posee funciones algo más avanzadas.

La pregunta por tanto es, que ¿si antes podíamos tener tan solo un dispositivo, porque ahora dos?. En realidad sí existen dispositivos unificados en los que el propio aparato es ONT, Router y WIFI al estilo clásico de las redes DSL, y posiblemente en un año o dos serán los dispositivos que instalen la mayoría de los ISP porque son baratos. No obstante es mucho mejor tener dos dispositivos totalmente diferenciados con funciones bien diferenciadas. Por un lado el ONT que se encarga de lo que tiene que hacer, y por otro lado un router neutro que podemos configurar o manejar como mejor nos convenga, siendo la configuración necesaria para su correcto funcionamiento con fibra mínimo, y pudiendo usar en teoría prácticamente la mayoría de routers comerciales que hay en el mercado, no tenemos que buscar routers específicos que sean también ONT (o modems DSL como pasaba antes)

Dado que el teléfono va por VoIP, o el ONT o el router que tengamos disponible deberá de disponer de entrada de teléfono RJ11 para poder puentearlo a una roseta o a un teléfono. Esto es importante, porque si el ONT que nos han instalado no realiza las funciones telefónicas y estas las deriva en el router que instalan, si sustituimos el router por uno de nuestra elección tendremos que tener esto en cuenta. En cualquier caso deberíamos de poder decirle a los técnicos que nos instalen un tipo u otro.

¿Son buenos los equipos que nos instalan? Tsss, es como todo, son equipos baratos que más que nada realizan las funciones que tienen que realizar, ni más ni menos. En la medida de lo posible siempre recomiendo cambiar el Router por uno de nuestra elección que sea competente. Si vamos a contratar unos cientos de megas al menos disponer de un router 802.11ac, aunque tan sólo podríamos operar en ac si disponemos también de dispositvos en nuestros equipos que lo sean. Por otro lado routers de gama alta proporcionan además una estabilidad muy superior y un sin fin de configuraciones que de otro modo serían imposible, como por ejemplo la instalación de discos duros en el mismo router por USB3, usarlo de servidor DLNA, VPN, copias de seguridad automatizadas… hay de todo.

Las ONT importan menos porque el trabajo que tienen que realizar lo hacen bien por lo general, y si se funde o nos sale mala la unidad pedimos su reemplazo, pero sus funciones son muy delimitadas. De echo es muy normal que las ONT que nos instalan sean igualmente routers que por no ser WIFI o tener prestaciones más limitadas se configuran de tal modo que se desactivan ciertas funcionalidades, y se quedan tan solo para lo básico.

La desventaja por otro lado de usar tu propio router por ejemplo radica en que no vas a tener ningún tipo de soporte técnico por parte de tu ISP para configurarlo o garantizarte su funcionamiento, tendrás que buscarte tu mismo las castañas del fuego para que funcione Internet, VoIP y televisión en caso de que se tenga contratada. De esto encontramos miles y miles de tutoriales en Internet, y no, no cualquier router sirve, pero sí muchos más de los que encontramos en las guías. Un buen router de gama media/alta debería de ser capaz de configurarse por complicada que fuesen los parámetros de la red… ¿Por qué hay tantos manuales y debates sobre sus configuraciones para fibra? ¿Es que son diferentes los protocolos? Si y no.

Las conexiones ADSL se realizaban por lo general con una conexión PPPoE en la que tan sólo era necesario establecer usuario y contraseña que nos proporcionaba el operador y en todo caso las DNS. Prácticamente lo demás venía solo. Con fibra, tal como se está haciendo aquí, la cosa es algo más complicada. Sí, se usa por lo general una conexión PPPoE, pero a partir de aquí la cosa cambia un poco. Tal como se está haciendo aquí, por el mismo cable de fibra óptica viajan los paquetes de datos que componen tanto internet, voip y iptv. Esto o se envía todo junto o se envía al ONT por diferentes frecuencias, pero en cualquier caso en lgún momento es necesario subdividir estos paquetes, para enviar a fin de cuenta los de voip a los teléfonos, iptv al decodificador de televisión o Internet al router en general y el resto de dispositivos. Este mecanismo de diferenciación se realiza por medio de tags, de marcadores, mediante el protocolo 802.1Q, en el que los frames ethernet están marcados con un ID que determina así a que sección de nuestra red van a parar dichos paquetes. Por lo tanto el router que instalemos debe de ser capaz de crear estas… “etiquetas”, o lo que suele ser lo mismo, crear diferentes VLAN dentro de este para poder discriminar el tráfico y enviar a cada lado lo que le corresponde.

vlanPor ejemplo, en el caso de Movistar, el servicio de IPTV se etiqueta por medio de la vlan2, así que como primer paso deberíamos poder configurar el router para redirigir el tráfico etiquetado para vlan2 a un puerto ethernet del router concreto del que enviaremos el cable al decodificador (ademas de tener que configurar posiblemente rutas y otros). Pero incluso para poder disponer de internet tendremos que poder etiquetar el tráfico que venga como ID 6, para que sea enviado a todos los puertos e interfaces wifi, para poder tener servicio. Con VoIP exactamente igual. Por supuesto cada operador puede variar esto como quiera en función de que sistemas usen o de que servicios doten.

Es normal, sus equipos vienen preconfigurados para sus instalaciones, si queremos hacer uso del nuestro, toca encontrar los ajustes adecuados.

Llegados a este punto, si hemos instalado la fibra, si hemos puesto al día nuestros equipos y nuestros dispositivos, la siguiente pregunta es… ¿y ahora que?

 

Y AHORA QUÉ

La fibra y los servicios que nos dan por ella nos da ciertas funcionalidades que como es natural nunca nos las explicarán.. no les interesa realmente. Pero ello no significa que no puedan usarse ciertos servicios realmente interesantes.

-Sobre los servicios de Internet poco podemos decir sobre ello… tendremos ni más ni menos la velocidad contratada, y lo normal es que con una exactitud casi milimétrica, no importa si estamos a 2 metros de la central o a 10km, y realmente cualquier aumento que podamos desear o que por el motivo que sea se “regale” les basta a ellos con tocar un botón. Aquí solo recomendaría en todo caso cambiar las DNS del router (ya sea uno propio o el del ISP) a algunas que no esten bloqueando servicios y webs en España. Con las nuevas leyes han bloqueado páginas controvertidas como pueda ser thepiratebay a nivel de DNS, con lo que bastaría usar servidores DNS decentes y que estén fuera de restricciones absurdas. OpenDNS es muy usado, aunque en lo personal prefiero los servidores DNS de Google, tienen menos latencia: 8.8.8.8 y 8.8.4.4.

-Sobre los servicios de IPTV la cosa es más interesante (a aquellos que la tengan contratada). El servicio de IPTV se dirige a fin de cuentas al decodificador que está conectado al puerto del router preciso. El decodificador al encender lo único que hace es recibir por DHCP una IP/mascara/puerta de enlace que le dará servicio. Esto podemos hacerlo si queremos nosotros mismos en cualquier equipo, y ver por tanto la televisión contratada en cualquier PC. Dada que la IP es única no sería posible a priori visualizarlo de forma simultanea, aunque no imposible. Simplemente copiando los datos de conexión del decodificador en nuestra interfaz WIFI o cable de nuestro PC sería suficiente para recibir todo lo referente a la televisión. El resto recaería sobre el siempre eterno VLC, al cual tan solo tendríamos que especificar el “canal” que deseamos ver, que no son más que direcciones IP y puertos a los que accedería VLC para el correcto visionado. Y una vez por VLC podríamos grabar, retransmitir o cualquier otra cosa que quisiésemos.

-VoIP es igualmente interesante. Si nuestro ISP lo usa basado en los estándares (y debería), si conocemos las configuraciones de cada ISP podríamos configurar cualquier cliente SIP (ya sea en el móvil o en el PC) con los datos pertinentes, y por ende usarlos para realizar llamadas o recibirlas. Esto implica dicho de otro modo que mientras usemos la red de casa (la que usa la fibra) podemos hacer uso de VoIP como deseemos, no solo estar limitados a los teléfonos fijos/inalámbricos, sino también teléfonos IP, nuestro propio movil, el PC…

A extensión de VoIP, dado que podemos realizar llamadas a través de nuestra línea por VoIP si estamos dentro de nuestra red, nada nos impediría por tanto a través de conexiones VPN a nuestra red usar este servicio desde fuera de ella. ¿Por qué es esto interesante? Bien, cuanto menos tendremos por contratar fibra llamadas a fijos nacionales gratis, y dependiendo del plan contratado también X minutos mensuales a móviles. Dentro de nuestra red por medio de VoIP (usando telefonos, móviles o cualquier dispositivo configurado para usar el servicio de nuestro ISP) podemos llamar como si fuese nuestro fijo normal, la gracia es que si configuramos una red VPN y conectamos nuestro móvil (previamente configurado para poder usar VoIP de nuestro IP), las llamadas se realizarán como si estuviesen desde dentro de nuestra propia red. ¿En definitiva? Usando datos/wifi de nuestro móvil podemos llamar gratis a cualquier fijo nacional y/o consumir minutos gratis que tengamos contratados en el fijo, y la llamada se realizará como si fuese desde nuestro propio teléfono fijo. Ideal para cualquiera que suela tener excedente de datos y gaste más de la cuenta en llamadas.

 

CONCLUSION

Es bien simple. A menos que tengas equipos que realmente sean competentes o tengas unos requerimientos especiales o muy caprichosos… no te compensa pasar por caja, y menos contratar las velocidades altas o los planes de todo incluido, que al final lo que buscan es hacerte rascar la cartera. Es evidente que a lo largo del año en el que estamos y el siguiente, ante una mayor oferta los precios también serán más competitivos, la fibra óptica llegará a más hogares y poco a poco todo estará mejor asentado. Es lógico pensar que en un futuro más cercano que lejos todas nuestras conexiones se realizarán por fibra o de forma inalámbrica, no es un no al progreso ni mucho menos, es siempre más que nada dar un toque de atención a los que se dejan engañar fácilmente con los letreros grandes y las ofertas supuestamente maravillosas.

La fibra óptica es lo que es, funciona muy bien y tiene muchas ventajas. Pero sin equipos realmente adecuados, sin que la mayoría sepa o pueda sacar provecho realmente de lo que ofrece… no hay tampoco ninguna prisa para meterla en casa. En principio sería mucho más adecuada para PYMES o grandes empresas donde sí pueden requerir unos servicios más avanzados para poder dar cobertura además a un gran número de personas, pero para los dispositivos que tenemos en casa y el uso que por lo general la mayoría les da…

Recordar que a los ISP les interesa por los costes de mantenimiento que los que tengan cobre vayan pasándose a la fibra, y de echo ya algunos ISP ofrecen al mismo precio (el servicio más básico al menos) tanto ADSL como fibra en función de si se posee cobertura o no. Esto sí me parece mucho más adecuado y viable como primera toma de contacto, pero como digo siempre que cuando termine el mes no nos de un infarto por uan factura que ha engrosado por servicios que no aprovecharemos queramos o no queramos.

Un saludo.

Google Photos: Activar Agrupación Facial en países en los que no está disponible

Maldita manía de no poder quedarme con los brazos cruzados cuando hay algo que me interesa… a fin de cuenta siempre he defendido que no somos nosotros los que tenemos que ser los esclavos de la tecnología, sino ella nuestra esclava… y eso implica “abusar” de ella o buscarle todas las vueltas posibles para hacernos más sencilla la vida. Google Photos es una de esas herramientas que honestamente le va a facilitar y alegrar la vida a cualquier amante de la fotografía.

google-photos-app-100587709-medium

¿¿ Por qué tanto elogio?? Con los años Google ha ido adquiriendo diferentes compañías del sector fotográfico. Recordemos Panoramio, una comunidad inmensa que comparte sus fotografías en todo el globo, del cual se nutre en gran medida Google Maps. Picasa!! con el que creó los primeros álbumes virtuales para compartir con quien quisiésemos. La suite de filtros fotográficas de Nik Software para Photoshop!! que junto a la adquisición de Snapseed mejoró enormemente (y en parte creó) el gran soporte de edición fotográfica online, en nube y en nuestros propios dispositivos…

Estoy convencido que Vic Gundotra (una excelente persona por cierto y buen fotógrafo), quien fuese Vicepresidente Senior de Google, tubo mucho que decir en como se constituyó originalmente la parte fotográfica que se incluyó en Google+ para sustituir su servicio de Picasa. Google implementó en Google+ Photos un sin fin de opciones. Por un lado espacio ilimitado para aquellas fotos que no nos importase tener en calidad de tan solo 2MP (suficiente para impresión), copias de seguridad automáticas de nuestras fotos desde nuestros dispositivos, aplicación para equipos de escritorio para sincronizar todas nuestras fotos, editor online para retoques cada vez más finos y específicos con mayor cantidad de filtros, soporte para imágenes esféricas gracias a PhotoSphere, compartición de imágenes de forma sencilla, automejorado de fotos, AutoAwesome que creaba combinaciones espectaculares aplicando efectos asombrosos, creación automática de historias basadas en las fotos o incluso creación de vídeos de forma automática a partir de fragmentos de otros.

Quizás el problema que tenía Google+ Photos es que era un producto muy integrado y dependiente de Google+, y esto no gustaba a muchos. Este año como vimos en la entrada anterior Google I/O | Novedades, Google anunció una batería de cambios importantes en Google Photos. Para empezar, desde incluso unas horas después del keynote, el producto se ha independizado de Google+ y ha pasado a llamarse formalmente “Google Photos” como producto propio, web propia, y aplicación propia!! lo que hará que Google Photos llegue a muchas más personas, sobre todo a aquellas que no tenían mucho interés en lidiar con Google+.

Pero además de incluir este divorcio, Google dio un par de noticias que realmente ha cambiado de nuevo las reglas de juego en este sector, y que hace que ahora mismo sinceramente no tenga competencia alguna.

En primer lugar, ampliar el almacenamiento ilimitado de fotografías a imágenes de hasta 16 megapixel y videos de hasta 1080p, hace posible  que no sea una excusa para nosotros sincronizar TODAS nuestras fotos en Google, aunque sólo sea por tener una copia de seguridad de ellas en la nube. Se acabó pagar dinero en espacio en nube para fotos.

En segundo lugar, una aun más interesante función que a día de hoy no ofrece NADIE. Sí… podemos tener nuestras fotos ordenadas en álbumes por años… pero buscar una foto o una serie de fotos en un conglomerado que pueden sumar miles o cientos de miles es casi imposible. En todas las suites de galerías se le permite al usuario etiquetar las fotos de tal modo que si buscas por etiquetas te aparecen las fotos etiquetadas, esto no es nuevo… pero requiere el etiquetado de las fotos, y si tienes miles y miles… de fotos esto es inviable, con lo que al final nadie etiqueta sus fotos. Pero usando lo último en reconocimiento de imágenes, puede que Google haya dado con la fórmula para lidiar con esto…

¿Y si los algoritmos de reconocimiento de imágenes de Google fueran capaces de escanear tus imágenes y “etiquetarlas” de forma automática en función de contenido de estas? Suena a ciencia ficción, pero la realidad es que esto es precisamente lo que han hecho. Los algoritmos de reconocimiento de imágenes de Google, que llevan ya muchos años perfeccionando y siendo noticias de X en X, parecen estar lo suficientemente maduros como para ser viables su uso. Es por ello que el propio sistema de Google Photos permite gracias a esto, dos opciones que pueden parecer imposibles. Por un lado, permite directamente buscar en las imágenes como si de texto se tratase lo que deseemos!! y por otro automáticamente nos realiza 3 agrupaciones.

¿Pero como sería esto puesto en acción??Pongamos que uso el buscador, le doy a la lupa, se me abren las 3 agrupaciones (Personas, Lugares, Cosas) y en la barra de búsqueda busco por perros. Me aparecerán todas mis fotos ordenadas por fecha donde aparecen perros!! si busco por comida fotos en las que hay una mesa de comidad o comida, si busco por puestas de sol, playa, bosques, montañas, personas… es evidente que el sistema no es perfecto y de vez en cuando podemos encontrar imágenes que no corresponden a lo buscado como es natural, pero lo sorprendente es que más del 90% de las veces cumple perfectamente.

 Por otro lado tenemos las agrupaciones. Google crea 3 agrupaciones: Personas, Lugares y Cosas. Dentro de Lugares, nos aparecerán agrupaciones de fotos según el lugar desde donde fueron tomadas, indicando la localización… bendita la geolocalización de las fotos. Dentro de Cosas, esta es una serie de agrupaciones temáticas que Google identifica, como pueda ser: Playa, Coches, puestas de Sol, Boda… la búsqueda puede ser más especifica pero estas agrupaciones son mucho más visibles y directas. Por último, y lo que me lleva a escribir esta entrada es la agrupación llamada Personas

No cabe duda que las otras dos agrupaciones son interesantes, pero Personas creo que excede ambas en su conjunto. Personas agrupa tus fotos en función exactamente de lo que su propio nombre dice… personas. Google te mostrará la cara de cada una de las personas que tenemos en nutras fotos!! Ojo, no dice quien es quien, solo muestra su retrato. Dicho esto si le damos a cada retrato, la aplicación pasará a mostrarnos todas las fotos donde dicha persona aparece!! No importa si con mas años o con menos. Esta opción ya la teníamos en Picasa, pero la diferencia es que ahora es todo automático, sin necesidad de ir etiquetando o diciendo…Y francamente, he de decir que los únicos falsos positivos que he visto en mi caso han sido algunas confusiones entre hermanos.

El único inconveniente de todo ello es que mientras que todo lo anteriormente citado está disponible de forma inmediata para todos, la agrupación “Personas” tan solo está disponible en algunos países (me arriesgaría decir que tan solo en EEUU, pero a saber). Puede ser que Google quiera curarse en salud de que funciona correctamente o puede ser que sea un problema de legislación en otros países… pero sea como sea, lo cierto es que aquí en España tendremos que esperar a poder tener esta función habilitada…. ¿O no?

Por suerte, en este caso (al menos de momento) Google no ha implementado unas medidas de “seguridad” muy contundentes para evitar usar este servicio de “otras maneras”. ¿Como puede conocer Google si accedemos desde territorio estadounidense o español? Bueno hay muchas formas, pero la mas sencilla podría ser mirar en la configuración de la cuenta (datos que pueden cambiarse por el usuario) o simplemente mirando la ubicación del usuario mirando el origen de las conexiones que realiza a Google. Por suerte para nosotros, Google habilita o no esta funcionalidad (os lo digo ya) en función de la localización de la primera conexión que realicemos con la aplicación Photos. Esto significa que cuando estemos conectados a nuestra red WIFI o datos, la conexión se realizará desde España, Google lo identifica y dicha funcionalidad no es habilitada. Incluso la mayoría de aficionados a la informática sabe que no es demasiado complicado realizar una conexión desde otra ubicación, o al menos sabe que esta opción es viable.

En este caso en particular, basta con realizar una primera conexión desde la aplicación Photos. Después de esa primera conexión, Google nos mostrará en los ajustes de Photos la posibilidad de activar dicha opción, tan sencillo como eso. Como debe de ser la primera conexión, si ya hemos realizado esa “primera conexión” anteriormente, será necesario eliminar datos y caché de la aplicación Photos antes de realizar la conexión. Una vez realizada podremos reestablecer nuestra conexión normal puesto que no será necesario volver a realizar las sucesivas conexiones.

¿Cual es la mejor forma de realizar una conexión con Google Photos desde Estados Unidos? Personalmente creo que lo más sencillo es usar la red TOR. Se pueden usar redes VPN que estén operando en EEUU, pero por lo general suele obligarnos a registrarnos en alguna aplicación o alguna página web para poder tener acceso a ella y bla bla bla…. a través de TOR no es necesario registrarse en nada… eso sí… hay que saber como funciona TOR y configurar las cosas para que funcione bien. Dicho esto, ¿como se haría a través de la red TOR?

En Play Store tenemos clientes proxy y Tor para realizar esto de un modo más directo. A mi no me gusta instalar porquerías en el móvil, y por otro lado ya tenía el terminal “preparado” para este tipo de eventualidades, y lo que hago es usar ProxyDroid (Una aplicación que permite redirigir todo el tráfico a un servidor proxy) para enlazar todo el tráfico de mi terminal a mi PC, y de este pasar dicha conexión directamente a TOR. TOR por otro lado si no se configura no puede garantizarte que la conexión final se realice desde un servidor americano, así que en vez de estar probando con diferentes nodos de salida, podemos configurar directamente TOR para que nuestra conexión final saliente venga de un servidor americano… en el archivo de configuración basta con añadir un StrictNode 1 y ExitNode {us} (si la memoria no me falla).

Si se prefiere realizar por VPN, tan solo habría que añadir el VPN directamente en los ajustes del terminal, lo que pasa es que la mayoría que pueden encontrarse o son de pago o usan aplicaciones propias que vete a saber… pero se podría hacer de cualquier modo.

Google IO 2015 | Novedades

io15-color

El Keynote es cosa del pasado, y ahora toca analizar aunque sea brevemente que nos ha dejado y que nos irá dejando a lo largo de este año.

En esta ocasión no pudimos ver tampoco a ninguno de los dos fundadores de Google, Larry Page y Sergey Brin, y la cabeza visible fue de nuevo Sundar Pichai. La presentación comenzó con una increíble puesta en marcha de lo que la tecnología en imagen 360º está creando. En un auditorio más grande del que hemos visto otros años rodeado en su integridad por pantallas como si de una sola pantalla de 360º fuese, se inició en estas durante los primeros 3-4 minutos un “video”/”animación” al estilo Spotlight en el que los espectadores podían seguir el vídeo/animación de 360º como si ellos mismos estuviesen en el centro de la acción.

Como otros años, antes de mostrar novedades, Sunday se centró en dar algunos datos, cuanto menos, impactantes… como por ejemplo que 8 de cada 10 Smartphones que se venden a día de hoy en todo el mundo son terminales Android, que cada vez son más y más modelos (y variados) de Android Wear, más de 35 fabricantes de coches implementando Android Auto… y cómo no, incluso después de 2-3 años comercializándose, ChromeCast sigue liderando ventas en el sector de los dispositivos para Sreaming. De nuevo se quiso hacer hincapié en aquellos países menos desarrollados, donde es dicho por todos los analistas aun hay un enorme potencial.

Entrando en materia, la mayoría de novedades hay que decir que se esperaban aunque sin saber mucho detalle (sin que eso significa que sean menos importantes).

 

Android M

Sin nombre oficial aun, esta nueva versión de Android llegaría si es cierto lo que dicen en el 3º trimestre, no en el 4º como estamos acostumbrados. No sería un cambio tan sustancial como pudo serlo Lollipop respecto a KitKat, más bien una continuación de Lollipop, sin que eso signifique que esté carente de funcionalidades nuevas y mejoras:

-Diseño similar, aunque Google ha cambiado el launcher y la lista de aplicaciones será en vertical

Administrador de permisos: Personalmente una de las inclusiones estrella. Sin ROMs extrañas ni añadidos, el sistema por defecto contará con un gestor completo de permisos por aplicaciones, que permitirá aceptar o denegar cualquier acceso que no deseemos de cualquier aplicación. Se acabó eso de tragar con que las aplicaciones tengan acceso a todo con la excusa de que al instalarla ya aparecían

-Se mejora el navegador interno para aplicaciones, esto para el usuario importa menos, pero de cara a los desarrolladores les da una enorme versatilidad y ahorro de tiempo, además de crear un a mayor suavidad entre el cambio de pantallas y otros (cuando sirven contenido HTML)

-Se mejora la conexión y compartición de contenido entre aplicaciones, además de unificar más las interfaces. Ahora pasar datos de una aplicación a otra es más sencillo, dicho de otro modo.

Android Pay: El nuevo sistema de pago de Google por NFC. Wallet nunca fue bien recibido ni tuvo mucha aceptación. Google ha querido esta vez hacerlo bien y antes de tenerlo listo firmar acuerdos a nivel mundial para que su método de pago esté listo y operativo en el mayor número de sitios posibles. La ventaja de contar con más dele 80% del mercado es que los establecimientos lo tendrán claro… y será de agradecer para todos. Aquí en España, este tipo de avances es raro que lo veamos a corto o medio plazo… es una lástima.

-Soporte para escáner de Huellas: Ya vimos hace tiempo como Apple lo implementó en sus iPhone, e incluso Samsung en sus últimos modelos. Ahora el soporte será nativo. La ventaja de Android frente a iOS en este aspecto es que la API permitirá ser usada en cualquier punto del sistema o aplicación que desee usarla, no estará limitada su uso a bloquear/desbloquear la pantalla y poco más como sucede en iOS.

-Controles de Volumen extendibles: De nuevo otra de esas mejoras que personalmente llevaba mucho tiempo esperando… ahora cuando aumentemos o disminuyamos el volumen podremos extender el control de volumen y acceder igualmente al volumen de notificaciones/alarma/sonido, sin el engorro de que sea el sistema quien dependiendo de la aplicación lanzada controla uno u otro.

-USB Type-C: Se implementará como era de esperar el conector Type-C de USB. Para quien no lo sepa, es básicamente un conector USB que es reversible… es decir no importa si lo colocamos hacia arriba o hacia abajo. También podrán los terminales alimentar otros dispositivos.

Batería: Google ha seguido mejorando todo lo posible el consumo energético, y ha lanzado lo que llama Doze. Este nuevo sistema somete al OS en un estado profundo de suspensión, haciendo que el consumo en StandBy sea disminuido drásticamente. Según los datos de ellos (siempre por supuesto en tela de juicio) en igualdad de condiciones un Nexus 6 gana unas 6horas de autonomía gracias a Doze. Por supuesto supongo que serían mediciones en los que ambos terminales permaneciesen en StandBy todo el tiempo. En cualquier caso es importante este cambio y mejora, ya que sólo mientras dormimos el terminal ya pasa unas 7-9 horas aletargado, y el resto del tiempo aun así también lo pasa en StandBy. Seguro que no veremos como nuestra batería gana 9 horas, pero con que ganemos 30 minutos o incluso 1 hora creo que es interesante.

-El teclado sufre diferentes mejoras en cuanto a la selección de palabras y caracteres… no es algo sumamente importante realmente, aunque cualquier mejora es bienvenida.

Copia de Seguridad automática y Restauración de aplicaciones: En cada versión de Android hemos visto como esto ha ido mejorando… en Android M por fin se culmina el proceso, y ahora TODAS las aplicaciones y datos de estas serán sometidos a un proceso de copia de seguridad, con el fin de si cambiamos o actualizamos o… nuestro dispositivo, este pueda volver casi al estado anterior, no solo descargando las aplicaciones desde Play Store como tenemos ahora mismo, sino restaurando también los datos de estos. Al contrario que sucede en iOS, el espacio usado por las copias de seguridad NO CONTARÁ como espacio usado en nuestra cuenta. Es decir, de cara al usuario son todo ventajas, no tiene que hacer nada, no le compromete en nada, no pierde nada… y gana tener a resguardo todos sus datos. Además los programadores de Apps podrán añadir o excluir contenido a dicha copia en caso de usar el espacio en la SD para esto o cualquier otra cosa. Las copias de seguridad son cifradas y enviadas a los servidores de Google tan solo cuando el dispositivo está cargando, con una conexión WIFI y sin hacer nada.

-Puntos de Acceso 2.0: Se actualiza el sistema de creación de punto de accesos móvil, ahora podremos crear redes 5Ghz si nuestro terminal evidentemente tiene el hardware adecuado.

Google “Now On Tap”: Esta es mi favorita. Google Now se renueva enormemente, y ahora es capaz de interpretar el contenido que tengamos delante en cualquier momento. Si antes Google Now podía darnos información tremendamente útil y personalizada, ahora Now On Tap nos brinda información directamente en pantalla si lo deseamos de lo que estemos haciendo. Por ejemplo, si escuchamos una canción y preguntamos quien es, nos responderá la artista de la canción. Otro ejemplo, nos envían un mensaje o correo electrónico o… diciendo que quedamos en el local X, si abrimos el asistente que aparece como un desplegable inferior nos mostrará al momento sin nosotros decir nada dirección y otros del local X. Esto se extrapola a a cualquier parte del sistema o aplicación!! Que estamos en una web y vemos la foto de un famoso?? Si “desplegamos” Now On Tap nos dirá quien es el de la foto que aparece en el artículo.

-Un largo ETC: Por supuesto no es lo único nuevo, como cualquier versión “grande” los cambios se encuentran por centenas, algunos más relevantes de cara a programadores otros de cara al usuario. En general veremos cambios en todos los aspectos, aunque no lo sean de forma visible todos ellos.

Al igual al año pasado, está disponible para quien la quiera la versión preview tanto para el Nexus 5, 6, 9 y Nexus Player AQUI, en esta ocasión Google asegura que se lanzarán 3 Preview… la primera la que ya está disponible, otra a finales de Junio, otra a finales de Julio, y la cuarta será la final que cabe esperar que sea para finales de Septiembre.

google-io-2015-18

 

Android Wear

Pese a la baja aceptación de los relojes inteligentes, poco a poco se van expandiendo y haciendo normal su uso. Muchos pensaban que iba a ser la nueva revolución pero hay que ser realistas… a día de hoy estamos limitado al tamaño que tienen sus pantallas, con lo que es normal que no sea un gadget para todos. En lo personal no tengo ninguno y a corto plazo no tengo idea de buscarlo, pero es que yo soy de pantallas grandes, y tampoco uso relojes sinceramente (para gustos colores)

No obstante sigue siendo un punto fuerte para Google, y las mejoras en Android Wear son cada vez mayores. Lo que antes parecía un producto sin demasiadas posibilidades, a día de hoy es algo mucho más extensible. Disponemos de más de 4000 aplicaciones específicas para Wear!! y actualizaciones constantes que llegan a TODOS los dispositivos. Hace poco se añadía el uso de GPS o de WIFI de los dispositivos que lo integran, y el número de funciones va en aumento.

Se ha anunciado así, un nuevo sistema de “encendido” en el que el reloj siempre permanecerá en un estado de bajo consumo pero mostrando en pantalla aquella información que deseábamos, como por ejemplo el mismo reloj o una dirección o un texto… por otro lado se han añadido gestos de muñeca para realizar ciertas tareas, reconocimiento gestual de emojis, un launcher mucho más trabajado… Bien, es cierto que estamos limitado a una pequeña pantalla, pero me parece increíble lo que vamos pudiendo hacer sólo con ella.

Por supuesto el principal problema que tienen es el mismo de siempre… un reloj convencional te puede durar años la pila, aquí tendremos que cargar cada día.

1

 

Domótica

 Hace ya algún tiempo que Google compró Nest, una empresa que fabricaba termostatos inteligentes para casas y otros. En su día sonó un poco raro el interés que podía tener Google en un dispositivo de domótica… pero con el paso del tiempo hemos ido viendo realmente el verdadero interés de Google. Actualmente Nest fabrica dos productos realmente interesantes, su termostato y su detector de humos.

Cada vez más y más fabricantes comienzan a fabricar dispositivos inteligentes para los hogares. Empezando por sistemas de vigilancia, cerraduras, luces… incluso electrodomésticos. Estos dispositivos inteligentes por lo general son posible controlarlos por aplicaciones concretas de sus fabricantes. Pero al igual que ha pasado en las SmarTV, es muy costoso para los fabricantes y nada útil para los usuarios el no existir un sistema común que haga no solo mas sencilla la programación, sino que sea posible la interacción de los diferentes dispositivos unos con otros. Así que Google ha comenzado a trabajar duro en un sistema operativo para dichos dispositivos inteligente: Brillo.

Brillo sería un OS abierto basado en Android minimalista llamado a estar integrado en este tipo de dispositivos para unificar poco a poco todas las opciones actuales. Está claro que el usuario prefiere un dispositivo que pueda interaccionar con otro de otra marca y modelo que uno que no. Junto con Brillo, Google ha creado lo que llama Weave, que vendría a ser los protocolos de comunicaciones a usar entre dispositivos Brillo… y por supuesto una interfaz gráfica para poder gestionarlo todo desde nuestros dispositivos.

Es muy pronto para ver el futuro de esto… pero lo que está claro es que quien no apuesta no gana, y Google quiere desde luego cubrir cada una de las opciones que podamos tener en el futuro.

 

Google Photos

Noticia esperada, y tengo que decir que mejor que las expectativas. Google Photos está de echo ya operativo, tanto por web como por Android o iOS. Básicamente viene a independizar por fin de Google+, Photos, quedando este como un producto único.

Evidentemente lo importante de Google Photos no es su divorcio con Google+, sino lo que nos trae:

Almacenamiento ILIMITADO: Anteriormente sabíamos que podíamos optar por imágenes en tamaño nativo (que contaba como almacenamiento personal) o ilimitado… pero este ilimitado nos obligaba a que las imágenes eran bajadas a una resolución de 2MP. El servicio se extiende y aunque aun es posible guardar las imágenes o vídeos de forma nativa (y por tanto cuenta como almacenamiento), el almacenamiento ilimitado permite ahora almacenar imágenes de hasta 16MP… más que suficiente para cualquiera, y los vídeos en Full HD (1080p).

Ordenación automática según el contenido: Impresionante el trabajo de Google en este aspecto. Aunque no es perfecto, de forma AUTOMATICA y sin necesidad de etiquetar las fotos, Google las ordenará según su temática, el lugar donde se tomaron… e incluso en algunos países (aun no disponible en España) nos reconocerá él solo las caras que aparecen en nuestras fotos y al darle a cualquiera de ella nos mostrará TODAS las fotos donde dicha persona aparece. IM-PRESIONANTE.

Búsqueda de contenido en la foto: Por si todo esto fuese poco, ahora podremos realizar búsqueda de nuestras fotos según su contenido!! Es decir, si buscamos por “Playa” se nos motratrán nuestras fotos en la playa, o si ponemos Perro se nos mostrarán nuestras fotos donde aparezca un perro. Repito, todo esto SIN QUE LAS FOTOS ESTEN ETIQUETADAS, google reconoce y escanea el contenido de las imágenes. Sí… no es perfecto, pero funciona bastante bien

-Compartición más sencilla: Se hace posible la creación de enlaces simplemente seleccionando las fotos que deseemos, y dando el consiguiente enlace.

Aconsejo a todos a actualizarla instalarla… no tiene desperdicio. Una pena que la agrupación facial no esté disponible aquí en España… posiblemente por cuestiones legislativas en nuestro país… a saber.

 all-three-v4

Países en Desarrollo

Como decía anteriormente, desde hace un par de años los países en vías de desarrollo son un punto clave en la hoja de ruta de una empresa como Google. Google no se enfoca a una clientela específica como si suele hacer Apple, la visión de Google siempre ha sido global. Es evidente que si le preguntamos a los señores de Google dirán que su principal obsesión es mejorar al mundo, acercar a TODOS (sin excepción) a la tecnología y hacer las vidas más sencillas. No digo que sea falso porque su historia demuestra que es verdad que son bastante “humanos” en comparación con otras grandes empresas y que siempre han abogado por la universalidad, pero eso no quita el echo evidente que a cuantas más personas puedas alcanzar, más clientes tendrás. Lo que pasa es que en este caso ellos forjan el como llegar hasta unos potenciales clientes que no tienen medios… y es aquí donde la cosa se pone interesante.

La filosofía de Google ha sido una muy sencilla: Si desarrollamos tecnología que sea barata y asequible para la inmensa mayoría (no solo para el 10% rico de la población, donde nos encontramos la mayoría de nosotros), si logramos acercar a todo este gran volumen de personas (miles de millones) redes de alta velocidad, dispositivos asequibles, PCs, educación… si invertimos en todo ello a lo mejor ahora no, pero dentro de 5 años? 10 años?? podamos ver como todo lo invertido en “mejorar” sus vidas pueda recaer en gran parte en nosotros mismos.

Nos encontramos en un mercado que comienza a saturarse, abrir otros horizontes es clave para alguien que quiere tener una presencia a nivel mundial y en cada rincón. Repito… dentro de las estrategias de empresa de cada uno, esta me parece de las más loables… por supuesto al final se busca el beneficio, pero en este caso a la par se está realizando una buena labor. Lejos queda el dar de comer a a cambio de crear zapatillas de deporte.

Android One fue lanzado el año pasado y tuvo realmente una buena aceptación. Un estándar barato y funcional para que los fabricantes pudiesen crear dispositivos “vendibles” en cualquier rincón. Ahora se expandirá a más países. He aquí un ejemplo de lo que comentaba. Google invierte en crear una plataforma barata, firmar acuerdos con grandes fabricantes… y el resultado es que en esos países donde es prohibitivo el coste de un terminal actual puedan adquirir un buen terminal tecnológicamente muy avanzado, que al final contará con Android y los servicios de Google.

Sus ChromeBooks asequibles es otro ejemplo de esto, así como uno de sus actuales Projects X, actualmente conocido como Loon, en el que Google está desarrollando tecnología para poder dotar de redes de alta velocidad a extensas áreas a través de globos aerostáticos… y lo cierto que lo que parecía ser una utopía esta teniendo sus frutos, y a día de hoy Google ostenta el récord (y con creces) del tiempo de vuelo de un globo aerostático, superando a la propia NASA. Eso no quiere decir que Loon pueda llegar a ser un día una realidad, pero toda la inversión realizada al final no deja de ser una inversión en el desarrollo de tecnologías, conocimientos… que al final de nuevo cae en la propia empresa. 

A esta batería, ya presente, de ideas, Google este año ha presentado otras tantas, todas ellas en este caso con la mente puesta en el problema que presentan las redes de baja velocidad de esos países. Aquí, en España, no concebimos salir de casa y no tener una conexión mínimamente 3G+, eso sin contar que ya nos quejamos por no tener una cobertura LTE decente. Imaginad ahora que la tecnología que existe es la actual pero nuestras redes de datos son las de hace 10 años. Cuanto tiempo tardaríamos en abrir una sola web por GPRS?? De echo la propia creación de webs ha ido de la mano del avance de la tecnología y a día de hoy cualquier webmaster no diseña una web pensando que el tráfico lo generarán redes 2G.

Para combatir en la medida de lo posible esto, Google ha creado una versión digamos extra-optimizada de su buscador que clama ser más de 4 veces más rápida, con un consumo de bytes transferidos de un 80% menos!! y una reducción de memoria de más de 80MB. Sinceramente son datos impresionantes. También implementarán lo que han llamado estimador de calidad de la red que de forma automática no descargará las imágenes si estima que la red es lenta. Por supuesto supongo que todo vendrá con un decrimento en algunos aspectos que no conocemos, y de echo estas baterías de cambios tan solo serán aplicadas en dichos países, nosotros no veremos un cambio en ello.

Más?? No queda ahí… se incluirá la visualización de páginas offline, incluso en dichos países se podrá visualizar contenido en YouTube offline (descargarlo para verlo más adelante en un plazo de 48 horas).

La mejor noticia?? Incluso Google Maps permitirá no solo el poder guardar mapas offline, sino la posibilidad de poder buscar, realizar rutas… y sí, hacer uso del navegador paso a paso en aquellos mapas que han sido guardado.

 

Desarrolladores

Al igual que se miman a los usuarios, hay que mimar igualmente a los programadores que invierten en los servicios de Google. Estos no se quedan atrás en cuanto a novedades, algunas realmente esperadas con los brazos abiertos.

Android Studio 1.3: El IDE de desarrollo de Android se actualiza, y en este caso con una mejora considerable de velocidad en la compilación, un nuevo profiler de memoria y… soporte para código nativo C/C++!! Sé de más de uno que va a decir “Por fin… odio JAVA”

-Polymer: Esto lo vimos de forma muy fugaz el año pasado y en una fase muy inicial. Google quería crear una serie de herramientas para que un programador web pudiese crear aplicaciones al más puro estilo de Material Design de Android, o poder imitar el diseño de estas. No se avanzó mucho en este aspecto, tan solo que estará disponible en breve…

-Cocoapods: Otro ejemplo de que las miras de Google van mucho más lejos de lo que las tiene Apple. Cocoapods viene a ser un entorno sencillo para programación en iOS. Recordemos que Google por supuesto tiene la mayoría de sus aplicaciones publicadas en el Store de Apple. Como digo cuestiones de filosofía, para Google lo importante es llegar a todos, para Apple es crear sus ovejas.

-Testing Cloud: Permitirá a los programadores probar sus aplicaciones encima de más de 20 dispositivos actuales! De este modo facilitar enormemente la tarea de depuración y compatibilidad.

Indexación de Aplicaciones: Esto se venía ya viendo… y es que veremos como cada vez más en los resultados de búsquedas en nuestros móviles veremos como aparecen también aplicaciones, una buena forma de que los usuarios puedan por un lado ver que hay aplicaciones sobre lo que buscan (o sobre la empresa, temática…) y los desarrolladores llegarán a más personas.

-Cloud Messaging: Cloud Messaging (GCM) es una plataforma de Google que hace posible el intercambio de información entre los servidores de Google y las aplicaciones creadas para tal efecto. Se usan para un sin fin de usos, pero básicamente lo que hace es eliminar la necesidad de que un desarrollador o empresa tenga que disponer de un servidor dedicado que esté en comunicación con su aplicación. Gracias a GCM las aplicaciones pueden recibir y enviar información en tiempo real a servidores, intercambiar de forma sencilla información… por ejemplo pensad en actualizaciones de localización, mensajes… más de 600 mil aplicaciones hacen usos de ellos, y se envían más de 70 mil millones de estos “mensajes”… bien, pues la noticia es que GCM se expande igualmente a iOS y a Chrome.

-Suscripciones por medio de GCM: Se hace posible la suscripción a páginas/eventos y otros a través de GCM… tengo curiosidad por ver quien es el primero en usarlo y como queda…

-Métricas mejoradas en la consola de desarrollador: Se implementan estadísticas y analíticas más completas. Ahora será posible ver los programadores cuantas instalaciones tienen, cuantas compras, cuantos accedieron a ver la aplicación…

-Páginas de Inicio en Play Store: Los desarrolladores podrán ahora crear su propia página para promocionar sus aplicaciones en Play Store, una página a modo de nexo común, algo que también se venía pidiendo desde hacía tiempo.

-AdMob+Analitycs: Esta boda permitirá obtener unos datos mucho más extensos y valiosos. Por ejemplo, cuanto tiempo pasa cada jugador en un nivel para mostrarle publicidad en el momento concreto y adecuado

-Búsquedas en Google Play categorizadas: Ahora las búsquedas que hagamos se ordenarán según su temática

-Google Kids/Family:  Google crea no solo un “store” dedicado a los más pequeños, sino que todas las aplicaciones estarán marcadas con un código PEG para indicar su idoneidad para los pequeños. Además se crean listados y categorías especiales para los mas chicos, como por ejemplo listados de los personajes más famosos y buscar por ellos aplicaciones relevantes.

Al final, aunque sean mejoras de cara a los desarrolladores, hay que entender que el usuario es al final quien se beneficia de todo. Mayor oferta = mejores precios y mejores contenidos.

 

CardBoard

Vale, empezó como una “broma” e iniciativa inteligente y graciosa en el IO dele año pasado. El año pasado ante el aumento en el CES de dispositivos de realidad virtual (VR) google diseñó una caja de cartón (literalmente) con la que construir de forma sencilla tu propio visor VR con 3 cosas y medias, y usando claro está tu dispositivo móvil. Lo cierto es que Google publicó los componentes los diagramas para construirlo… y por raro que parezca su funcionamiento fue extraordinariamente bueno!!

Bien, un año después hemos visto como el CardBoard de Google es famoso. Se han vendido más de un millón de est0s… visores-cartón, las aplicaciónes para ellos han subido exponencialmente y sinceramente… “mola mogollón”. Este año se ha rediseñado ligeramente el CardBoard original y ahora lo llaman la versión 2.0, que es prácticamente igual pero permite el uso de teléfonos de tamaños de 6 pulgadas, y compatible tanto para iOS como para Android.

Por supuesto uno puede fabricarselo si quiere por si mismo, pero si quiere comprar el set lo puede encontrar por no más de 20€. No es nada caro si tenemos en cuenta cuanto cuesta un visor VR actual… 20€ merece la pena aunque solo sea por trastear. Lo recomiendo, de veras.

cardboard

Además de la actualización del “hardware” (por llamar la caja de cartón de algún modo), se creará lo que han llamado “Expeditions“, la posibilidad básicamente que las instituciones de enseñanza puedan crear literalmente expediciones en VR sobre lo que deseen!! estando además para más inri todos los CardBoard sincronizados entre sí. Dicho de otro modo… os imagináis poder hacer con un grupo de digamos 20 personas, todas juntas una visita virtual en VR por las pirámides de Egipto?? Por supuesto no es algo que puedan crear de forma sencilla (estas expediciones) ya que a fin de cuenta habrá o que diseñar por ordenador el entorno o filmarlo… pero es viable y posible.

 Parejo con Expeditions, y casualmente con el lanzamiento a nivel mundial de SpotLight (antes solo disponible para unos cuantos dispositivos), Google lanza Jump. Jump básicamente se divide en tres partes:

El Hardware: Es una cámara de fotos/video… más concretamente habría que decir que es un dispositivo compuesto por 16 cámaras dispuestas en un array circular que permite filmar el mundo totalmente en 360º. Evidentemente el hardware es “caro”, 16 goPro trabajando juntas harán un trabajo excelente!! pero evidentemente no para particulares.

El Software: Un software es capaz de interpretar todo lo que se ha capturado, unirlo y crear un vídeo 360º que podremos explorar.

Un visor: Con el que podamos reproducir dicha grabación… y que por descontado ya conocemos uno, CardBoard, y el segundo… también más que conocido, YouTube, pues tendrá soporte para vídeos en 360º este verano.

 

Conclusiones

Bien, al igual que el año pasado no se han realizado lanzamientos de hardware, y el IO ha vuelto a ser en esencia lo que debía de ser… un centro no tanto para los usuarios sino para los desarrolladores, y dar esas pinceladas a los usuarios de lo que les queda por ver no solo parte del año que viene sino este mismo año. LA gran ausencia fue de nuevo alguno de los dos fundadores, quiero pensar que estaban invirtiendo su tiempo en cosas más productivas o al menos que no fueron ausencias debidas a la falta de salud.

Android sigue evolucionando, y lo mejor es que a la par Google continúa ofreciéndonos servicios cada vez mejores, gratuitos la mayoría y más útiles. Un ejemplo este año ha sido Google Photos, ya no hay excusa de prescindir de él. Al final, la postura de Google de no focalizar todos sus esfuerzos en una cuestión concreta (como le criticó Jobs en vida a Larry Page quien le dijo que tenían que focalizar productos) esta teniendo un resultado mejor al esperado. Google se afianza no solo en terreno viejo, sino que cada vez va abarcando más espacios y al final esos espacios repercuten directamente en los viejos espacios mejorándolos y dándole constantemente ese aire fresco. Podemos decir que nos gusta más o que nos gusta menos, podemos decir que se han equivocado más de una vez… pero es inevitable reconocer que siempre siempre están en movimiento… implementando las buenas ideas sea de quienes sean sin por ello desmerecer el mérito original, investigando, implementando las suyas propias… y de cuando en cuando sorprendiendo con alguna… “chispa” nueva que sólo Google es capaz de darnos… solo hay que ver el CardBoard o la aplicación SpotLight (es impresionante).

Por supuesto esto es solo el principio, el IO, tanto el KeyNote como las charlas que han ido sucediéndose han dejado muchas más novedades y a lo largo que vayan pasando los días y semanas irán saliendo. Queda por ver si las opciones de Google Maps offline estará disponible para todos, si la agrupación facial se extenderá, si realmente se recibirán OTAs mensuales de Android M (disponible a día de hoy para N5, N6, N9 en versión preview)… ya veremos… ya veremos…

Volver a arriba

Sobre Mí

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