El reloj del salpicadero de un Renault Latitude de 2014 marcaba una hora distinta a la real, y por más que el propietario revisó todos los menús, no encontró forma alguna de cambiarlo. Lo que se lo impedía no era una avería mecánica, sino un servidor de mapas apagado por el fabricante a miles de kilómetros de distancia.
El sistema multimedia Carminat LIVE de este vehículo fue fabricado por TomTom. Al comprar el coche, el dueño anterior le ofreció la tarjeta SD de los mapas de navegación, advirtiéndole: “en este coche la necesitas hasta para cambiar la hora”. Incrédulo y convencido de que los mapas estarían desfasados de todos modos, la rechazó y la tarjeta acabó en la basura. Con el tiempo descubriría que cada una de las palabras del anterior propietario era rigurosamente cierta.
El reloj de un coche, rehén de una tarjeta de memoria. Esta decisión de diseño convirtió la legítima propiedad del hardware en un arrendamiento dependiente de servicios externos. Con los servidores desconectados de forma permanente, el único parche capaz de solucionar el problema tuvo que escribirlo el propio usuario.
Ajustar la hora obligaba a recomprar una tarjeta de mapas obsoleta
En el Renault Latitude, la pantalla central está gestionada por una plataforma con el nombre en clave beaumont, equipada con un procesador Samsung S5P6440 y un sistema personalizado de TomTom basado en el kernel Linux 2.6.28.10.
El punto de entrada de la interfaz es PNDNavigator. Ni Renault ni TomTom diseñaron un menú de ajustes independiente para el vehículo: la hora, el idioma y el brillo de la pantalla estaban integrados dentro de las definiciones de interfaz de PNDNavigator, que se leían de forma dinámica desde la tarjeta SD externa. Sin la tarjeta insertada, el sistema del vehículo ni siquiera sabía cómo abrir la pantalla de configuración.
Figura: La pantalla del salpicadero mostrando en estonio el aviso “No maps found!”: la tarjeta SD controlaba mucho más que los mapas de navegación. Fuente: blog.nns.ee
Tras pasar una hora rebuscando por todos los niveles del menú sin encontrar la opción “Ajustar hora”, la solución oficial más directa era adquirir una tarjeta de repuesto: aún se consiguen unidades en el mercado de segunda mano, pero enviarla a Estonia costaba unos 60 euros. Negándose a pagar 60 euros solo por poner en hora un reloj, decidió recuperar el control del sistema por sus propios medios.
Los fabricantes convirtieron los ajustes básicos en un accesorio del mapa
Hace más de una década, la industria del automóvil vivió su primera oleada de digitalización conectada. Los fabricantes querían vender habitáculos inteligentes pero carecían de experiencia interna en software de a bordo, por lo que subcontrataron todo el sistema multimedia a especialistas en navegación como TomTom. Apremiado por los plazos de entrega, el equipo externo trasladó directamente el firmware de los navegadores portátiles (PND) al salpicadero: al arrancar, el coche cargaba primero el navegador y dejaba los ajustes básicos supeditados a este. Al subordinar los ajustes esenciales a la aplicación de navegación, el reloj dejó de funcionar cuando se apagaron los servidores de mapas. El propietario se encontró con un vehículo mecánicamente perfecto pero incapaz de ajustarse al horario de verano.
Bloqueo por hardware y noexec: barreras defensivas contra el dueño
La alternativa más lógica era comprar una tarjeta SD estándar y copiar en ella scripts propios. Sin embargo, el sistema contaba con varias líneas de defensa.
La primera era la vinculación a nivel de chip. El sistema DRM de TomTom verifica el identificador único CID (Card Identification) —grabado en fábrica en el controlador de la memoria y no modificable— y las firmas criptográficas de los archivos cartográficos. Una tarjeta virgen convencional es rechazada en el primer paso.
La segunda barrera residía en la política de montaje: incluso simulando un CID legítimo, el sistema operativo montaba el almacenamiento externo con el parámetro noexec. Ningún binario o script almacenado en la tarjeta tenía permiso de ejecución. Unos mecanismos diseñados originalmente para evitar la piratería de mapas terminaron bloqueando al legítimo propietario que solo quería reparar su automóvil.
Provocar un fallo del kernel para eludir las restricciones de ejecución
El propietario, Rasmus Moorats, extrajo la imagen del firmware del dispositivo, emuló el chip S5P6440 con QEMU en su ordenador y comenzó a desensamblar los binarios. Analizó paso a paso el ejecutable ttn, encargado de procesar master.script, y documentó el protocolo interno de comandos SHEX: este protocolo solo admite un argumento separado por espacios y se lo envía a launchserver, que a su vez lo ejecuta mediante execve —una vía completamente cortada por noexec.
La solución llegó a través del mecanismo de volcados de memoria (core dump) del kernel de Linux. Linux permite configurar el gestor de volcados tras una caída mediante /proc/sys/kernel/core_pattern. El soporte para argumentos en esta directiva se introdujo en el kernel 2.6.24, y dado que el vehículo utilizaba la versión 2.6.28, core_pattern todavía podía modificarse desde el espacio de usuario. Moorats eligió un proceso con fallo garantizado: /bin/dbus-monitor lanza de inmediato una señal SIGABRT si no logra conectarse al bus del sistema. Dado que el kernel ejecuta el comando configurado en core_pattern con privilegios de superusuario (root), esta vía ignora por completo la restricción noexec del sistema de archivos.
Figura: La pantalla del salpicadero notificando la ejecución de master.script; el script personalizado logró ejecutarse en el hardware real sorteando la protección noexec. Fuente: blog.nns.ee
El resultado fue un sistema multimedia capaz de ejecutar scripts personalizados como root, recuperando plenamente la capacidad de ajustar el reloj y la zona horaria del vehículo.
Cuando el código del fabricante queda en el abandono
Una vez que la noticia del jailbreak se difundió entre la comunidad técnica y de aficionados al motor, otros usuarios empezaron a replicar el procedimiento. En los foros de TomTom se confirmó que el mismo método funciona en la versión de firmware Carminat TomTom 8.843. Los hilos de debate revelaron además un hecho llamativo: la navegación GPS no deja de funcionar por la falta de tarjeta; lo único que quedaba inhabilitado era la visualización del reloj. Lo que realmente necesitaba repararse eran los archivos de caché de efemérides satelitales (packedephemeris.ee, ee_meta.tlv, ee_meta.txt). Sustituyéndolos por datos recientes sin conexión, la sincronización horaria y el posicionamiento vuelven a funcionar con total normalidad.
Quienes pagaron miles de euros por un coche completo se ven obligados a recurrir a técnicas de piratería para mantener operativas funciones elementales. Cuando las marcas hipotecan las funciones del hardware a servicios en la nube, el comprador se queda únicamente con un derecho de uso temporal. Los servidores pueden apagarse y el mantenimiento del software puede cesar; liberar el control del sistema es la única vía para que los dispositivos sobrevivan a los fabricantes que los construyeron.
Enlaces de referencia:
- blog.nns.ee: Jailbreaking my car’s navigation system just so I can change the time
- Hilo de debate en la comunidad oficial de TomTom (Carminat TomTom 8.843)
- Discusión técnica en la comunidad Lobsters
