Home » Opinión » La escalofriante historia de la versión filtrada de iOS del HomePod
HomePod D22

La escalofriante historia de la versión filtrada de iOS del HomePod

28 de julio de 2017. Varios empleados de Apple tienen un dispositivo HomePod en sus casas para probarlos y tener una experiencia real de uso. Es algo esencial en el roadmap de cualquier dispositivo que pueda tener la importancia que va a tener el nuevo altavoz de Apple. Este viene con la versión 11.0 de iOS cargada desde que las primeras unidades de ellos han estado viviendo en las casas de algunos afortunados e incluso algún que otro medio de prensa que no puede decir nada hasta que Apple no levante el correspondiente embargo dentro de muchos meses y pocos días antes del lanzamiento.

Pero Apple, justo ese día 28, se disponía a hacer algo crítico: actualizar por over-the-air los HomePod, allí donde estuvieran. Es algo que millones de compradores podrán hacer como algo habitual, pero en el caso del HomePod es más crítico porque no hay una pantalla que te avise del cambio de versión del sistema y no hay forma alguna de mostrar la información o interactuar o aceptar dicha actualización.

HomePod, cuando no sea usado, descargará él solo la nueva versión de iOS cuando esté disponible en los servidores de Apple, como ya lo hacen millones de dispositivos, a través de un simple mecanismo de suscripción RSS en un XML para él mismo. Se descargará e instalará solo, probablemente durante horas donde no hagamos uso de él. Salvo que conectemos con la app compañera que tendremos para los sistemas de Apple, nosotros nunca sabremos qué versión hay instalada: debe ser un proceso transparente al usuario.

Pues bien, comienzan las pruebas y en un servidor público de Apple aparece esta versión disponible para que los altavoces en pruebas lo detecten y lo instalen. Se trata de la versión iOS 11.0.2. Un fichero que sigue disponible a día de hoy, en público, y que Apple no ha retirado ni parece que quiera hacerlo. Las pruebas reales del dispositivo son más importantes, y lo entiendo. Si tenéis curiosidad, este es el fichero XML culpable y aquí tenéis (vía ipsw.me) la versión OTA de iOS 11.0.2 del HomePod. Podéis bajarla pulsando aquí.

En el momento en que esta apareció saltaron las alarmas: y comenzaron a aparecer noticias sobre el propio HomePod. Que lleva iOS (obvio) o que tiene una app que controla su board (sistema) llamada SoundBoard. También que tiene una serie de apps de tipo .app (pero nativas de iOS) que controlan cada elemento (como el caso de la música controlada por una app llamada AirMusic). De hecho, la mayoría de apps comienzan en Air su nombre, como el protocolo de AirPlay. ¿Tal vez Apple pensó en un primer momento llamarlo AirPod, pero luego cambió de idea para no confundir al usuario con los AirPods?

El caso es que los primeros días fueron de descubrimientos relacionados con el nuevo dispositivo. Se confirmó que su pantalla superior (la única) sería de 272×340 en una matriz de LED que casi será como un corazón de Siri pero que según algunas teorías de la conspiración, podría permitir mostrar información en forma de texto o gráficos. Además tendría 1GB de RAM.

Datos del HomePod

Fue el desarrollador Avery Magnotti‏ (@citrusui) el que descubrió e informó al archiconocido Steven Troughton-Smith, de este descubrimiento. La captura sobre estas líneas es suya. En ella vemos un explorador que accede a los diferentes ficheros y dentro de un simple plist tiene la información deseada.

Y aquí vamos a pararnos un momento, porque este es uno de los métodos por el que los desarrolladores consiguen la información: explorando los recursos, apps y ficheros del sistema. Es muy común que los ficheros de listas de propiedades estén por todo el sistema y que nos digan toda esta información, como ficheros de texto abiertos.

Fue después cuando el desarrollador Guilherme Rambo hizo una suposición: ¿y si buscaba la cadena "face" a ver si había alguna información sobre el nuevo iPhone en esa versión de iOS del HomePod? Buscar "cara" tenía un por qué, ya que se hablaba del desbloqueo facial justo en esos días como sistema de seguridad del nuevo iPhone. Es de todos conocido el hecho que Apple borra deliberadamente información relevante de futuros lanzamientos de las versiones de iOS de desarrollo o betas públicas que va sacando, pero esta versión sin duda es una que Apple tal vez no había "limpiado" antes de lanzarla (pensó Rambo). Y así ha sido.

Resulta que esta versión de iOS, al ser aún una versión en pruebas muchos meses antes del lanzamiento, sigue siendo un iOS 11 modificado del real y con toda la información aún cargada de lo que llevaran sus futuros primos iPhone, iPad o Apple TV en las nuevas generaciones que usarán este versión. Por lo que la búsqueda fue fructífera y aquí comenzó el filtrado de toda la información que hemos visto estos días y que sigue continuando.

La búsqueda de "face" le llevó hasta una librería estática: BiometricKit. La misma librería que gestiona el TouchID hoy día, pero que curiosamente incluía una serie de referencias que no están en la actual versión 10 ni en las versiones 11 de desarrolladores. Pero BiometricKit es una librería estática compilada, un binario, por lo tanto no se puede acceder a su código ni desemsamblarlo fácilmente para acceder a este.

Aquí es donde entra en funcionamiento el comando de Unix strings, que permite extraer la información que permanece como cadena dentro de un archivo binario. ¿Y qué mejor que acceder al compendio de todas las librerías del sistema, que se encuentra bajo el fichero dyld_shared_cache? (algo que sucede desde la versión 3 del entonces iPhoneOS). En este fichero se encuentran todas las librerías públicas y privadas de iOS.

Con el uso de strings y del famoso comando grep que permite filtrar por un patrón concreto de búsqueda de cadena cualquier archivo, podemos acceder a la información que queramos. Y ahí fue cuando se empezaron a ver llamadas en especificaciones públicas que hacían referencia a los diferentes métodos y propiedades de la clase BKFaceDetectStateInfo con valores como: initFromFaceInfo, faceDetected y unas cuantas más.

https://twitter.com/stroughtonsmith/status/891841607728844801

A partir de ahí, sabiendo que esta versión de iOS contenía más información, han ido buscando más cadenas, más datos (que diría Johnny 5). Rambo vio que había menciones a un método EnrollPearlID muy parecido en nombre al actual método que registra un proceso de TouchID EnrollTouchID. Por lo tanto buscó la cadena "pearl" y de ahí apareció la referencia a Pearl-D22 y suponiendo que este D22 podía ser un código de un iPhone no lanzado, buscó la cadena "D22", que ya supuso extraer toda la información acerca del nuevo modelo.

Y entre otros datos, descubrió dentro del framework de PassKit un fichero llamado Payment_glyph_phone-D22.caar, que hacía referencia a un modelo de iPhone de código D22, que no corresponde a ninguno de los actuales. Los ficheros caar son codificaciones de instancias de árboles de CALayer, con información vectorial de elementos ya dibujados. Este, a la silueta del dispositivo que aparece cuando haces un pago con Apple Pay.

Playgrounds

Y como vemos, y compartió el propio Stroughton-Smith, con un simple Swift Playgrounds podemos abrir el fichero, deserializarlo y mostrarlo como objeto CALayer viendo cómo será el nuevo iPhone en su figura.

El nivel de explorar datos ha sido tan grande que incluso se han encontrado los valores hexadecimales del contorno en puntos que tendrá la parte superior del nuevo iPhone. Valores que han permitido hacernos una idea más real de cómo habrá una parte superior cortada y qué tamaño exacto tendrá. También cosas como que el nuevo iPhone tendrá un modo de detección automática de escenas para la cámara o un modo biométrico múltiple que permitiría validar con más de un sistema a la vez (como huella y detección facial al mismo tiempo).

Por sacar datos, sabemos incluso que el nuevo Apple TV tendría resolución 4K (estoy seguro que solo para streaming pero su interfaz y apps seguirían siendo FullHD) y soporte de HDR10 y Dolby Vision (HDR de 12 bits). Pero todo ello, intuido a partir de propiedades de clases que muestran su especificación. Nada más. Son conjeturas de peso, pero no supone que el nuevo Apple TV saliera ahora, que tuviera esas opciones o que se incluyeran más adelante. Son solo métodos o propiedades de clases que forman parte de una librería de iOS 11.0.2 de un dispositivo que aun no está en el mercado, que tendrá muchos meses de prueba por delante y puede contener información provisional no final que no llegará a los productos finales. Nada más. Por ejemplo, imaginen que Apple no llega a un acuerdo provechoso con Dolby para licenciar Dolby Vision. No se incluiría, aunque haya una propiedad en una clase para ello. Hay que pensar profundamente en esto.

Pero curiosamente, por sacar, hasta se han extraído los sonidos que tendrá el HomePod en la propia UI, de alarmas y notificaciones.

https://www.youtube.com/watch?v=yy-QMMv4Xlk

Como ya hemos dicho, no podemos emocionarnos ni tomarnos todo esto al pie de letra. Toda esta información no es más que el resultado de explorar binarios, ficheros de recursos gráficos o de listas de propiedades. De hecho, no es información como tal porque, por ejemplo, algo tan clave como la resolución del nuevo iPhone no está clara aun. Según los cálculos de Steven Troughton-Smith, a él le salen 1242×2800 de resolución real. 1242 es el ancho de la actual gama Plus, la interna que luego se re-escala a 1080 para caber en un panel FullHD. Pero las fuentes de KGI (el famoso Ming-Chi Kuo) habla de una resolución de 1125×2436, siguiendo las líneas de Apple en cuanto a puntos por pulgada. ¿Quién tiene razón? Nadie lo sabe. De hecho, ni siquiera sabemos si a pesar de ser una resolución 1242×2800, luego tengamos un panel FullHD pero más largo para crear una pantalla 18:9 con la zona de Touch Bar inferior.

Como conclusión, ¿ha sido un error de Apple? No lo veo así. Ha sido un proceso normal de validación de producto en el que tal vez debería haberse capado la información sensible pero no se ha hecho. O tal vez (es mi teoría) a Apple le da exactamente igual y está por encima del bien y del mal. Ellos tienen su proceso, sus pasos, y si por el camino la gente descubre esa información y se entretiene mirando minucias y despertando titulares en el insípido mes de agosto, bienvenida sea la dicha. Los próximos días 4 o 5 de septiembre podrían ser los elegidos por Apple para desvelar todos los misterios, siendo dos semanas después el lanzamiento de iOS 11 final y unos días después de los nuevos iPhone 7 y 7s. Si seguimos los rumores, el 8 (o iPhone) no vería la luz hasta más adelante.

Estamos en un campo divertido con muy poca información, que nos da pistas pero nada grave. Lo justo para mantenernos entretenidos mientras ellos preparan lo que de verdad tendrá importancia. Un saludo y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

Phil Schiller - App Store

Mantener un desarrollo con el precio que se pagó hace años

Analizamos y opinamos sobre el difícil modelo de mantener una app con el cobro realizado en el pasado y las últimas opiniones de Phil Schiller, responsable de marketing de Apple. Opinamos sobre la difícil situación de mantener un producto vivo cuando ya se cobró por él y el usuario no tiene la percepción que debería pagar de nuevo e incluso periódicamente. Un debate abierto para opinar.