sec - QUANTARMY

Whose router is it? Reverse-engineering a Digi Comtrend GRG-4355u

Wed, 04 Nov 2026 14:00:00 GMT

The router your operator hands you isn't entirely yours. You pay for it in the monthly bill, it lives in your home and carries your traffic, but its firmware is the ISP's call, there are accounts you can't see, and through a remote-management channel the operator can reconfigure, update or re-provision it whenever it likes. For a security reader that's a threat-model question: who really controls this device, and what can an attacker with the sticker credentials do?

This article answers that for a concrete case: the Comtrend GRG-4355u that Digi ships for fiber. We reverse-engineered it —without opening the case, no UART, no JTAG, over the local network only—, found a chain of weaknesses leading from a guest account to root, and then turned it into a neutral, hardened router that no longer answers to the operator. All on our own equipment and line.

Responsible-research note. Everything below is on an owned device, on an owned line, on the LAN, with reversible changes and documented rollback. We publish no credential, no hash, no serial number, and no step-by-step recipe: this is an analysis of vulnerability classes and their significance, not a weapon against an ISP's fleet. One detail worth telling: the AI guardrail we worked with refused to perform the interactive root login itself, so a human ran those steps. Security is also done that way.

The ecosystem: a vendor OpenWrt with shared owners

Before touching anything, the inventory. The GRG-4355u is made by Comtrend (even though Digi distributes it), runs an Airoha EN7581 SoC (four ARM Cortex-A53 cores), and inside runs a vendor OpenWrt with the LuCI interface, kernel 5.4.55, under the firmware label DIG-1.3.22. The units we've seen report hardware 1.1 or 1.2.

The interesting part isn't the hardware photo but the map of who's in charge of it:

Who controls what: three LAN management planes and one remote ISP one

Accounts: there's an admin, a low-privilege user —whose credentials usually come on the sticker— and a root. The catch: logging in over SSH with the normal accounts doesn't give a Linux shell but a restricted vendor CLI (/sbin/cli).
The web plane: LuCI talks over HTTPS to rpcd/ubus, OpenWrt's call bus. That's where configuration decides what each login may read and write.
A hidden control layer: besides the standard firewall (UCI), the vendor installs cxt_acl_lan, its own access control outside UCI. That is, there are rules deciding which ports are open that you can't see in the normal firewall config.
The ISP, above everything: a TR-069 / CWMP agent connects to the operator's management server (ACS) over a separate management VLAN. That channel can push config, firmware and credentials. The homeowner can't turn it off from the interface.

That last piece is the article's thesis: the device's strongest trust link isn't local, it's the operator's.

Reverse engineering: from guest to root, over the network

The goal wasn't to open the case. The challenge was to start from what anyone has —the low-privilege sticker credentials and LAN access— and see how far it goes. It goes all the way to root, by chaining four management-plane weaknesses.

The chain, at the vulnerability-class level: no commands, just the mechanism

V1 · The authorization plane breaks itself. The first weakness is the most elegant and the gravest. In rpcd, each login has a permission list. The low-privilege account belongs, by factory configuration, to a group that lets it write the very configuration that defines its permissions. Put another way: a restricted account can edit the rules that restrict it and promote itself to wildcard permissions. No memory exploit needed; it's an authorization-model failure. It's also the part the project itself prepared for publication, because it's the lesson: the privilege boundary was drawn wrong.

V2 · Exfiltrate the firmware over the network. With broad permissions, the next step is to get the firmware, of which there's no public copy. No UART needed: an authenticated download endpoint of the web stack itself serves whole files including raw block devices, which lets you dump entire flash partitions over HTTPS. It's a class of flaw —file/block reads beyond what's intended— that turns an authenticated session into firmware and NVRAM exfiltration. (The exact request stays out: that's the weaponizable part.)

The offline analysis, and the prize: DES crypt in 2026. With the rootfs in hand (a compressed squashfs), you extract /etc/shadow. And there's the finding a security reader spots instantly: the factory root password hash uses traditional DES crypt —the 1970s scheme, 56-bit, only 8 significant characters—, obsolete for decades. It cracks offline without effort. A current-generation router in 2026 storing its root hash in DES is a first-order hygiene failure.

V · The wall wasn't the password. An instructive detail: having the root password wasn't enough, because the SSH port timed out. Not because of crypto or the password, but because that hidden vendor layer (cxt_acl_lan) had the SSH service disabled by policy, outside the visible firewall. The owner enables it from the vendor's access control and port 22 opens. Lesson: there's security-relevant state the interface doesn't show you.

V3 · Clean persistence. Oddly, changing root's password from the interface fails ("unauthorized user"), but file writing is available with the elevated permissions. So persistence was done the standard OpenWrt way: an SSH public key in root's authorized_keys. Key-based login, without touching /etc/shadow, and with the admin/user accounts intact. Reversible by deleting a file.

V4 · The CLI shortcut. And in case that wasn't enough, the vendor CLI stores its privileged-mode ("enable") password as a double base64 in config, readable by the low-privilege account. That isn't encryption, it's obfuscation: it decodes trivially. A vendor secret stored with reversible encoding is, in practice, a cleartext secret.

What this means

In classes: broken authorization (V1), firmware exfiltration by block reads (V2), weak hash and default password (DES crypt), hidden control layer (cxt_acl_lan) and obfuscated, not encrypted, vendor secret (V4). None requires physical access. Anyone with the sticker credentials and the LAN can, in principle, pull the whole firmware, the NVRAM, and get persistent root. And since the operator manages the device over TR-069, the remote-management plane is as critical as the local one.

What we did next: a neutral, hardened router

Finding root is the fun half. The useful half is taking back control of the device and leaving it fast, robust and under your command, without breaking fiber. Everything that follows is reversible and designed to survive a reboot.

The hardened router, and why own firmware doesn't go on the GRG

Autonomy: TR-069 out. First, remove the TR-069/CWMP agent (easycwmp and the related packages) and disable its daemons. With that, the operator stops managing, updating and re-provisioning the device automatically. It's the change that returns the most control: the router now boots from its saved configuration, with no ACS deciding for you.

Reversible debloat. A home router ships with a pile of services you don't use and that are attack surface: VoIP, DLNA/Samba/FTP, multicast proxy, UPnP, DDNS, SNMP, assorted telemetry. The optimization script turns off around 22 services, saving state so it can be reverted. Key: it's done with an allowlist of what's never touched —the PON stack (the fiber), the firewall, dropbear, rpcd, uhttpd, DNS/DHCP, NTP— so nothing essential breaks.

The optimization we deliberately didn't do. Here's the interesting engineering call: no SQM, no BBR/buffer tuning. It sounds counterintuitive, but the EN7581 does NAT in hardware (HW NAT/PPE); adding software queues or rewriting buffers would pull traffic off the hardware path and make it slower. The AQM is already done by the chip's own queues. The only network tuning was raising conntrack_max (from 16,384 to 65,536) and lowering the console log level. Technical honesty: the CPU governor change was noted but on the EN7581 turns out to be a no-op (it stays userspace), so it doesn't count as an improvement.

Robustness and persistence. The changes live in the overlay (UBIFS), so they survive a reboot. A factory reset does wipe them —by the device's design—, which is why the project has an automated re-entry that puts the router back into its known state without manual work. Every change has its rollback procedure.

The neutral router. The end goal was to put your router behind it and use the GRG only as an ONT. You can, by bridging the Internet VLAN (20) to the 10 Gb port (LAN5): the GRG acts as a dumb ONT and your router routes. In our setup, a second box also ended up as a dumb access point for Wi-Fi.

And own firmware? The honest verdict

The natural question for anyone who gets this far: why not flash real OpenWrt and forget the vendor firmware? The answer, after evaluating it, is that today it isn't viable on the GRG if you want to keep fiber.

The reason is the SoC. The EN7581 is both the router and the ONT (the optical part), and the whole fiber stack —the PON MAC kernel modules, Airoha's network daemon, the OMCI stack— is closed binary and tied to kernel 5.4.55. Upstream OpenWrt has basic EN7581 support (Ethernet, Wi-Fi, routing) but does no PON: flashing it means losing fiber. Reusing the vendor blobs on a modern OpenWrt doesn't work either: the 5.4.55 modules won't load on 6.x kernels and nobody has ported the EN7581 PON stack.

The realistic alternatives, then, don't go through the GRG:

An "8311" SFP ONT stick (the ONT in a transceiver) in your own router's SFP cage, programmed with the line's identity. Your router is the router; the operator only controls the stick over OMCI.
Bridge mode, which is what we left set up: the GRG as a bridged ONT with your router behind it.

Saying "you can't, and here's what you can" is part of the craft. An honest result is worth more than a promise that bricks the fiber.

Threat model and what we take away

The management plane rules everything else. It doesn't matter how strong the Wi-Fi password is if a local account can rewrite its own permissions and the operator can push config over TR-069. A router's security is decided by who controls its management, local and remote.
Defaults at fleet scale are the real risk. A trivial password and a root hash in DES crypt, if common across the fleet, expose every unit to the same local compromise. DES in 2026 is a hygiene failure that's hard to justify.
Obfuscation isn't encryption. A double base64 "protecting" a vendor secret is a cleartext secret with an extra step. The same goes for any "encoding" an attacker undoes in their head.
There are control planes you can't see. A vendor firewall outside UCI, or a TR-069 you can't turn off from the interface, mean you don't have full visibility of your own device's security state. Taking it back —removing TR-069, mapping cxt_acl— is part of hardening.
Research your own, and with a brake. Own equipment, own line, LAN, reversible changes, and no publishing what arms a third party. A guardrail stopping your root login so a human runs it isn't an obstacle: it's the responsibility model working.

The living-room router turned out to be a complete security target: broken authorization, firmware exfiltrable over the network, 1970s cryptography and an operator with a control channel the owner can't see. Turning it into a neutral, fast device under your command was the reward; the trust map —and who's really in charge— is what we take away.

Resources

OpenWrt — the system the vendor firmware is built on and the reference alternative: openwrt.org.
The 8311 project — firmware for SFP ONT sticks, the realistic path to your "own router" on fiber: look for the 8311 community.
On TR-069 / CWMP and remote CPE management: the Broadband Forum standard (TR-069).

¿De quién es tu router? Ingeniería inversa de un Comtrend GRG-4355u de Digi

Wed, 04 Nov 2026 14:00:00 GMT

El router que te deja el operador no es tuyo del todo. Lo pagas en la cuota, vive en tu casa y lleva tu tráfico, pero su firmware lo decide el ISP, hay cuentas que no ves, y por un canal de gestión remota el operador puede reconfigurarlo, actualizarlo o reaprovisionarlo cuando quiera. Para un lector de ciberseguridad eso es una pregunta de modelo de amenazas: ¿quién controla de verdad este aparato, y qué puede hacer un atacante que tenga las credenciales de la pegatina?

Este artículo responde a esa pregunta sobre un caso concreto: el Comtrend GRG-4355u que Digi distribuye para fibra. Le hicimos ingeniería inversa —sin abrir la caja, sin UART, sin JTAG, solo por la red local—, encontramos una cadena de debilidades que lleva de una cuenta de invitado a root, y después lo convertimos en un router neutro y endurecido que ya no obedece al operador. Todo sobre equipo y línea propios.

Nota de investigación responsable. Todo lo que sigue es sobre un aparato propio, en la línea propia, en la LAN, con cambios reversibles y rollback documentado. No publicamos ni una credencial, ni un hash, ni un número de serie, ni la receta paso a paso: esto es un análisis de clases de vulnerabilidad y su significado, no un arma contra el parque de un ISP. Un detalle que vale la pena contar: el propio guardrail de la IA con la que trabajamos se negó a ejecutar el login root interactivo, y esos pasos los hizo el humano. La seguridad también se hace así.

El ecosistema: un OpenWrt del fabricante con dueños compartidos

Antes de tocar nada, el inventario. El GRG-4355u lo fabrica Comtrend (aunque Digi lo distribuya), monta un SoC Airoha EN7581 (cuatro núcleos ARM Cortex-A53), y por dentro corre un OpenWrt del fabricante con interfaz LuCI, kernel 5.4.55, bajo la etiqueta de firmware DIG-1.3.22. Las unidades que hemos visto declaran hardware 1.1 o 1.2.

Lo interesante no es la foto del hardware, sino el mapa de quién manda sobre él:

Quién controla qué: tres planos de gestión en LAN y uno remoto del ISP

Cuentas: hay un admin, un user de bajo privilegio —cuyas credenciales suelen venir en la pegatina— y un root. Lo llamativo: entrar por SSH con las cuentas normales no da una shell de Linux, sino un CLI restringido del fabricante (/sbin/cli).
El plano web: LuCI habla por HTTPS con rpcd/ubus, el bus de llamadas de OpenWrt. Ahí se decide, por configuración, qué puede leer y escribir cada login.
Una capa de control oculta: además del firewall estándar (UCI), el fabricante instala cxt_acl_lan, un control de acceso propio fuera del UCI. Es decir, hay reglas que deciden qué puertos están abiertos que no se ven en la configuración normal del cortafuegos.
El ISP, por encima de todo: un agente TR-069 / CWMP conecta con el servidor de gestión (ACS) del operador por una VLAN de gestión separada. Ese canal puede empujar configuración, firmware y credenciales. El dueño de la casa no lo apaga desde la interfaz.

Esa última pieza es la tesis del artículo: el eslabón de confianza más fuerte del aparato no es local, es del operador.

Ingeniería inversa: de invitado a root, por la red

El objetivo no era abrir la caja. El reto era partir de lo que tiene cualquiera —las credenciales de bajo privilegio de la pegatina y acceso a la LAN— y ver hasta dónde se llega. Se llega a root, encadenando cuatro debilidades del plano de gestión.

La cadena, a nivel de clases de vulnerabilidad: ningún comando, solo el mecanismo

V1 · El plano de autorización se rompe a sí mismo. La primera debilidad es la más elegante y la más grave. En rpcd, cada login tiene una lista de permisos. La cuenta de bajo privilegio pertenece, por configuración de fábrica, a un grupo que le permite escribir la propia configuración que define sus permisos. Dicho de otro modo: una cuenta restringida puede editar las reglas que la restringen y ascenderse a permisos de comodín. No hace falta ningún exploit de memoria; es un fallo de modelo de autorización. Es, además, la parte que el propio proyecto dejó preparada para publicación, porque es la lección: el límite de privilegios estaba mal dibujado.

V2 · Exfiltrar el firmware por la red. Con permisos amplios, el siguiente paso es conseguir el firmware, del que no hay copia pública. No hace falta un UART: un endpoint de descarga autenticado del propio sistema web sirve ficheros completos incluyendo dispositivos de bloque crudos, lo que permite volcar las particiones de flash enteras por HTTPS. Es una clase de fallo —lectura de ficheros/bloques más allá de lo previsto— que convierte una sesión autenticada en una exfiltración de firmware y NVRAM. (El detalle exacto de la petición queda fuera: es la parte armable.)

El análisis offline, y el premio: DES crypt en 2026. Con el rootfs en la mano (un squashfs comprimido), se extrae /etc/shadow. Y ahí aparece el hallazgo que un lector de seguridad reconoce al instante: el hash de la contraseña root de fábrica usa DES crypt tradicional —el esquema de los años 70, de 56 bits y solo 8 caracteres significativos—, obsoleto desde hace décadas. Se rompe offline sin esfuerzo. Que un router de gama actual, de 2026, guarde su hash root en DES es un fallo de higiene de primer orden.

V · El muro no era la contraseña. Un detalle instructivo: tener la contraseña root no bastaba, porque el puerto SSH daba timeout. No por cifrado ni por la contraseña, sino porque esa capa oculta del fabricante (cxt_acl_lan) tenía el servicio SSH desactivado por política, fuera del cortafuegos visible. El dueño lo habilita desde el control de acceso del fabricante y el puerto 22 abre. Lección: hay estado de seguridad relevante que la interfaz no te enseña.

V3 · Persistencia limpia. Curiosamente, cambiar la contraseña de root desde la interfaz falla ("usuario no autorizado"), pero la escritura de ficheros sí está disponible con los permisos elevados. Así que la persistencia se hizo por el camino estándar de OpenWrt: una clave pública SSH en el authorized_keys de root. Login por clave, sin tocar /etc/shadow, y con las cuentas admin/user intactas. Reversible borrando un fichero.

V4 · El atajo del CLI. Y por si faltaba, el CLI del fabricante guarda su contraseña de modo privilegiado ("enable") como un doble base64 en la configuración, legible por la cuenta de bajo privilegio. Eso no es cifrado, es ofuscación: se decodifica de forma trivial. Un secreto de fabricante guardado con codificación reversible es, en la práctica, un secreto en claro.

Lo que esto significa

Resumido en clases: autorización rota (V1), exfiltración de firmware por lectura de bloques (V2), hash débil y contraseña por defecto (DES crypt), capa de control oculta (cxt_acl_lan) y secreto de fabricante ofuscado, no cifrado (V4). Ninguna requiere acceso físico. Cualquiera con las credenciales de la pegatina y la LAN puede, en principio, sacar el firmware entero, la NVRAM y obtener root persistente. Y como el aparato lo gestiona el operador por TR-069, el plano de gestión remota es tan crítico como el local.

Qué hicimos después: un router neutro y endurecido

Encontrar root es la mitad entretenida. La mitad útil es recuperar el control del aparato y dejarlo rápido, robusto y bajo tu mando, sin romper la fibra. Todo lo que sigue es reversible y está pensado para sobrevivir a un reinicio.

El router endurecido, y por qué el firmware propio no va en el GRG

Autonomía: fuera TR-069. Lo primero, quitar el agente TR-069/CWMP (easycwmp y los paquetes asociados) y deshabilitar sus demonios. Con eso, el operador deja de gestionar, actualizar y reaprovisionar el equipo automáticamente. Es el cambio que más devuelve el control: el router pasa a arrancar de su configuración guardada, sin un ACS decidiendo por ti.

Debloat reversible. Un router doméstico trae un montón de servicios que no usas y que son superficie de ataque: VoIP, DLNA/Samba/FTP, multicast proxy, UPnP, DDNS, SNMP, telemetría varia. El script de optimización apaga alrededor de 22 servicios, guardando el estado para poder revertir. Clave: se hace con lista blanca de lo que nunca se toca —el stack PON (la fibra), el firewall, dropbear, rpcd, uhttpd, DNS/DHCP, NTP— para no romper nada esencial.

La optimización que no hicimos, a propósito. Aquí la decisión de ingeniería interesante: nada de SQM ni de tuneos de BBR/buffers. Suena contraintuitivo, pero el EN7581 hace NAT por hardware (HW NAT/PPE); meter colas de software o reescribir los buffers sacaría el tráfico del camino del hardware y lo haría más lento. El AQM ya lo hacen las colas del propio chip. La única sintonía de red fue subir el conntrack_max (de 16.384 a 65.536) y bajar el nivel de log de consola. Honestidad técnica: el cambio de gobernador de CPU se dejó anotado pero en el EN7581 resulta ser un no-op (se queda en userspace), así que no cuenta como mejora.

Robustez y persistencia. Los cambios viven en el overlay (UBIFS), así que sobreviven a un reinicio. Un reset de fábrica sí los borra —por diseño del aparato—, y por eso el proyecto tiene una re-entrada automatizada que vuelve a dejar el router en su estado conocido sin intervención manual. Cada cambio tiene su procedimiento de vuelta atrás.

El router neutro. El objetivo final era poner tu router detrás y usar el GRG solo como ONT. Se puede, puenteando la VLAN de Internet (la 20) al puerto de 10 Gb (LAN5): el GRG hace de ONT tonto y tu router hace de router. En nuestro montaje, además, un segundo equipo quedó como punto de acceso tonto para la Wi-Fi.

¿Y firmware propio? El veredicto honesto

La pregunta natural de cualquiera que llega hasta aquí: ¿y por qué no flashear OpenWrt de verdad y olvidarse del firmware del fabricante? La respuesta, tras evaluarlo, es que hoy no es viable en el GRG si quieres conservar la fibra.

El motivo es el SoC. El EN7581 es a la vez el router y la ONT (la parte óptica), y todo el stack de fibra —los módulos de kernel del MAC PON, el demonio de red de Airoha, la pila OMCI— es binario cerrado y atado al kernel 5.4.55. OpenWrt upstream tiene soporte básico del EN7581 (Ethernet, Wi-Fi, routing), pero no hace PON: flashearlo significa quedarte sin fibra. Reutilizar los blobs del fabricante sobre un OpenWrt moderno tampoco va: los módulos de 5.4.55 no cargan en kernels 6.x y nadie ha portado la pila PON del EN7581.

Las alternativas realistas, por tanto, no pasan por el GRG:

Un stick SFP ONT "8311" (el ONT en un transceptor) en el puerto SFP de tu propio router, programado con la identidad de la línea. Tu router es el router; el operador solo controla el stick por OMCI.
Modo bridge, que es lo que dejamos montado: el GRG como ONT en puente y tu router detrás.

Decir "no se puede, y esto es lo que sí" es parte del oficio. Un resultado honesto vale más que una promesa que brickea la fibra.

Modelo de amenazas y lo que nos llevamos

El plano de gestión manda sobre todo lo demás. Da igual lo fuerte que sea la contraseña Wi-Fi si una cuenta local puede reescribir sus propios permisos y si el operador puede empujar configuración por TR-069. La seguridad de un router se juega en quién controla su gestión, local y remota.
Los valores por defecto a escala de parque son el riesgo real. Una contraseña trivial y un hash root en DES crypt, si son comunes a toda la flota, exponen a cada unidad al mismo compromiso local. DES en 2026 es un fallo de higiene difícil de justificar.
Ofuscación no es cifrado. Un doble base64 "protegiendo" un secreto de fabricante es un secreto en claro con un paso extra. Lo mismo vale para cualquier "codificación" que un atacante deshace mentalmente.
Hay planos de control que no ves. Un firewall del fabricante fuera del UCI, o un TR-069 que no puedes apagar desde la interfaz, significan que no tienes visibilidad completa del estado de seguridad de tu propio aparato. Recuperarla —quitando TR-069, mapeando cxt_acl— es parte del endurecimiento.
Investiga sobre lo tuyo, y con freno. Equipo propio, línea propia, LAN, cambios reversibles, y sin publicar lo que arma a un tercero. Que un guardrail te pare el login root y lo tenga que hacer el humano no es un estorbo: es el modelo de responsabilidad funcionando.

El router del salón resultó ser un objetivo de seguridad completo: autorización rota, firmware exfiltrable por la red, criptografía de los setenta y un operador con un canal de control que el dueño no ve. Convertirlo en un aparato neutro, rápido y bajo tu mando fue la recompensa; el mapa de confianza —y de quién manda de verdad— es lo que nos llevamos.

Recursos

OpenWrt — el sistema sobre el que se construye el firmware del fabricante y la alternativa de referencia: openwrt.org.
Proyecto 8311 — firmware para sticks SFP ONT, la vía realista al "router propio" en fibra: busca la comunidad 8311.
Sobre TR-069 / CWMP y la gestión remota de CPE: el estándar del Broadband Forum (TR-069).

Turning an e-reader into your own system: reverse-engineering the Kobo Libra 2

Wed, 04 Nov 2026 10:00:00 GMT

It is a book reader. An e-ink screen, Wi-Fi, 512 MB of RAM, a SoC NXP stopped calling new almost a decade ago. The kind of device nobody looks at with an attacker's eyes because "there's nothing inside." And yet it has everything that makes a hardware target interesting: a boot chain with no secure boot, an OTA update mechanism that applies packages on implicit trust, a user partition that mounts over USB like any thumb drive, and a counter in the MBR that decides whether the device wipes itself.

This article is the record of what we did to a Kobo Libra 2: reverse-engineering its boot and update mechanism, a static C boot selector that verifies the system by sha256 on every boot, an own kernel, and turning Plato —an open-source document reader— into the device's whole operating system. The public result is called PlatoX and is free software (AGPL-3.0); the personal version, with more things wired in, was called KoboX. We'll keep the two apart carefully, because security lives in the details and mixing editions is lying with precision.

This is not a jailbreak tutorial. It is a hardware-security case study: what you can learn from a closed device by reading its own firmware, where the real trust boundaries lie, and why "integrity" and "authenticity" are not the same word.

The ecosystem you had to understand before touching anything

First rule of any intervention on someone else's hardware: reconstruct the stock system before changing a single byte. You cannot defend —or break with control— what you don't understand.

The device is a Kobo Libra 2, internal name io, board E70K10, confirmed by reading the PCB table in the firmware's own kobo_config.sh. Inside: an NXP i.MX6SLL SoC (ARM Cortex-A9), a Rohm BD71828 PMIC, a Realtek RTL8723DS Wi-Fi part over SDIO, a 1264×1680 e-ink panel and 512 MB of RAM. The stock software stack, rebuilt piece by piece from the extracted firmware, is a museum of 2015-era embedded Linux:

The stock stack: from U-Boot to Nickel, without a single signed link

Boot: NXP's U-Boot (2016.03-00128 on the 4.38 branch), no signature verification. Whoever controls what the kernel runs as init controls the device.
Kernel: Linux 4.1.15, Kobo's exact build -00868-g58a2758be07, compiled with GCC 5.3.0.
Userland: busybox 1.31.1 as PID 1, glibc 2.19, libstdc++ from GCC 4.9. udev 142, wpa_supplicant 2.9 over OpenSSL 1.0.1u.
The reader: Nickel, Kobo's Qt application, with its store and account.
pickel: a shell wrapper that execs pickel-imx (an ELF). Keep it in mind: pickel is what decides whether the device factory-resets or accepts an update. Without knowing it, it is a security component.

Storage is an eMMC /dev/mmcblk0 with three partitions and several raw zones outside them:

Zone	What it is	Size / position
`mmcblk0p1`	`rootfs` (where Nickel runs)	256 MB ext4
`mmcblk0p2`	`recoveryfs`	384 MB ext4
`mmcblk0p3`	`KOBOeReader` (the "onboard", visible over USB)	29.1 GB vfat
zImage	raw kernel	sector 2048
hwconfig	hardware config	sector 1024
waveform	e-ink table	sector 14336

That 256 MB rootfs and that vfat user partition are not trivia: both bit us later. The reference firmware was pinned to 4.38.23828 (the kernel hashes the system accepts are anchored to it).

Reverse engineering: process and results

With the map in hand, the operational question is a single one: how do you get your own code in without opening the device or touching U-Boot? The answer was inside Kobo's own update mechanism.

The vector: `KoboRoot.tgz` and implicit trust

Kobo updates like this: if the stock init finds a .kobo/KoboRoot.tgz file in storage, it unpacks it over / as root and reboots. In the stock rcS that happens around lines 251–269, with pickel can-upgrade as the gatekeeper. No signature. No origin check. It is a tar/gzip of root-owned files extracted over the system, and binaries must be mode 755.

Put in threat language: the updater is the vector. Anyone who can write to the user partition —which mounts over USB with no credentials— can drop a KoboRoot.tgz that the system will apply as root on the next boot. The device's whole chain of trust rests on nobody dropping a file into a folder. That is the link that turns a closed reader into an open system, and the one a secure-boot design would close.

The boot counter in the MBR

The prettiest finding of the whole reverse-engineering effort wasn't in a binary but in five bytes of the MBR. On /dev/mmcblk0, offsets 0x133–0x137, Kobo keeps a boot counter. On each boot, pickel should-factory-reset increments it; when the index reaches 4, the device shows the factory-reset screen and wipes itself. The only thing that resets that counter is Nickel, which writes the sequence 8d ef 02 d2 00 when it boots cleanly.

The security consequence runs deep: a counter on disk is security state, and if your system replaces Nickel, it inherits its obligations. An own system that boots instead of Nickel and doesn't reset that counter self-destructs in four reboots. We had to replicate Nickel's exact gesture —write 8d ef 02 d2 00 at offset 307, re-read and log— only once Plato had been alive past a time threshold. A mutation test (writing at offset 308) had to fail, and it did. That landed in version 1.0.3, after watching the device wipe itself on the bench.

The bricks, told as what they are: results

The honest part of any hardware work is the list of times you left it unusable. Each brick was a finding about the system:

Permissions (EACCES): we packaged rcS as mode 644. busybox init invokes it with execv, which requires the execute bit → EACCES → nothing boots. Fixed by shipping it 755 with a check_exec guard. (fix 1.0.1)
Space (ENOSPC): we put 44.5 MB into a 256 MB rootfs that was already at 93%. etc/ extracted half-way and the device stalled at the splash, never reaching Plato. The fix was to move Plato to the onboard (vfat) and leave the rootfs with a 29 KB delta, with a hard limit of ≤ 256 KB on the system partition. (fix 1.0.2)
The self-inflicted factory reset: an early debloat phase put everything under /usr/local/Kobo/* on the delete list… including pickel-imx. Next boot: pickel should-factory-reset returns 127, the system reads that as "must reset", enters recovery, reflashes firmware 4.33.19747 and wipes the onboard. Out of that came the project's single most important rule: a protect-list that never touches pickel*, udev, init.d, the U-Boot images or ld.so.preload. Debloat, from then on, was done with 0-byte placeholders inside the KoboRoot.tgz, never rm on the live system.

Expand

When the device no longer boots: RAM recovery over fastboot.

After one of those bricks we had to build a lifeline that didn't require opening the device. The Kobo, like many i.MX6 parts, exposes a fastboot mode that enumerates as USB 18d1:0d02 ("USB download gadget"), but its boot command calls NXP's boota routine and expects an Android boot.img v0, not a classic uImage. With mkbootimg (kernel at 0x80008000, ramdisk at 0x83800000, DTB as second at 0x83000000) the device enumerates as "KoboRescue" in four seconds and boots a rescue system from RAM, without touching the eMMC.

The detail that turned the rescue tool into a dangerous one: disassembling U-Boot we found that _detect_bootmode runs inside bootz, and that holding power + page for a couple of seconds after entering fastboot triggers "recovery cus 9" → root=/dev/mmcblk0p2 → the recovery rcS reflashes 4.33's U-Boot and kernel and formats p1 and the onboard, without asking. The MBR counter doesn't intervene here. The tool was fixed to claim the interface immediately and send getvar:version, disarming the one-second timeout that triggered that path.

Kernel and modules: trust rebuilt from the binary

Wanting to load our own modules (zram, tun) into Kobo's kernel forces you to rebuild the trust Kobo doesn't publish. The kernel verifies vermagic and the per-symbol CRCs; a module built against headers that don't match to the bit is rejected with Invalid argument.

The process was binary archaeology:

Extract the device's own config.gz (via IKCONFIG_PROC) and its kallsyms table: 75,337 symbols.
Rebuild the stock kernel's Module.symvers straight from the official zImage, with an own LZO1X decompressor to open it and locating __ksymtab/__kcrctab with kallsyms: 6,847 symbols, all cross-checked against kallsyms.
Verify each module with check-module.py (vermagic identity) and verify-crcs.sh, recomputing the CRCs from our own sources: 186 equal, 0 different.

The Libra 2 (2021) kernel tree didn't carry this board's drivers, but the Clara 2E (2023) one matched the device config except for one option. The builds came out reproducible: tun.ko and zsmalloc.ko byte-for-byte identical across builds. That's the difference between "seems to work" and "I know exactly what I'm loading into ring 0."

What Plato is, and what PlatoX is

Plato is an open-source document reader for e-readers, written in Rust by Bastien Dejean, meant as an alternative to Nickel: fast, no store, no account. It is the reader; it is not the system.

PlatoX is the idea that gives meaning to everything above: take Plato and turn it into the device's whole operating system. Instead of patching Nickel, we replace it entirely. The device boots a small Buildroot system from RAM, verified by sha256, and lands straight in Plato: no store, no account, no sync service. Technically, PlatoX is Plato 0.9.45 plus a nine-patch series (plato-patches/0001–0009) and a handful of own Rust crates. Nickel stays installed and untouched: if anything fails, the Kobo boots Nickel as always.

It's worth fixing the two names before we go on, because from here it matters:

KoboX (and its evolution KoboX 2 / "0.2 Master Edition") is the full personal firmware, with things that depend on private infrastructure: Tailscale, a terminal, markets, weather, news, Home Assistant, library sync.
PlatoX 0.1 is the public distillation (AGPL-3.0): Plato as the system, the optimizations, the AI assistant and the calculator. Everything personal was removed on purpose, and with it much of the attack surface.

Three layers: verified boot, Plato as the UI, and the Rust crates behind it

The new features on Plato

On top of Plato we added features that turn it into a complete environment. I group them by edition, because a security reader will want to know exactly what code runs in the public version.

In public PlatoX (open source)

Plato as the launcher (patch 0001): paths from the launcher, inputs by name. This is what lets Plato be the system rather than one more app.
Network panel and Wi-Fi picker (patch 0002): a new view/network_panel.rs (+281 lines) that opens, from any view, a panel with Wi-Fi status in readable sentences (Off / Looking for a known network… / Connected to X / No known network nearby), IP and signal. The top-bar icon has four states (wifi-off, wifi-connecting, wifi, wifi-secure) and a poller thread updates it every 2 s, never from the UI thread.
AI assistant (patches 0004 and 0009): on a text selection, Summarize, Translate or Explain; on a book, insights —a short review, an extended review, a summary or a navigable concept map (view/concept_map.rs, +801 lines). It works with your own key: OpenAI, Claude (via the native Messages API with SSE streaming, with claude-opus-5-5 preselected when your key lists it), DeepSeek or any compatible server on your network. Answers are cached offline, and Wi-Fi only comes on when a request needs it, turning off after five idle minutes.
Phone-style calculator (patch 0006): replaces Plato's old command-line calculator with a keypad one. Behind it is the platox-calc crate, with an exact decimal (0.1 + 0.2 = 0.3, not 0.30000000000000004), percent and discount (120 − 15 % = 102, with a "Discount: 18" line), square root and guarded division by zero.
Clean menu, About and System Info (patch 0005): the menu fits on one page, Reboot and Shutdown stay visible, and Wi-Fi management moves entirely into the network panel. Along the way, System Info fixes a bug in Plato itself, which showed the load average multiplied by 100 with a "%" sign, and free memory instead of available memory.
Developer tools (patch 0007): Test All and Benchmark, behind a developer marker, with secret redaction in the diagnostics (no api-keys, tokens or PSKs in the logs).

In KoboX (personal firmware, outside the public version)

This exists and works, but depends on private infrastructure and was removed from the public build to shrink the surface: Tailscale (first in userspace mode, then with TUN and an own module), a terminal (busybox shell over a pty, with fastfetch and ssh), Markets (Yahoo data), Weather (Open-Meteo), News (an own generator with trafilatura in an SSRF-hardened container), Home Assistant (lights and climate through a CONNECT tunnel) and PDF sync against an own Calibre-Web.

The final optimization: faster, more robust, more responsive, more up to date

A reader that takes two seconds to change chapter is unusable, however elegant its architecture. The last phase was a performance campaign with one strict rule: measure on the device, not on the host. These are the medians, iteration by iteration, of version 1.4:

Metric (median)	Before (beta7)	After (beta12)
Page turn (EPUB)	231 ms	31 ms
Chapter change	2967 ms	46 ms
Open / reopen book	1265 ms	74 ms
First paint after power-on	9.4 s	6.9 s
Wi-Fi connected	12–13 s	5.0 s

Chapter change, from 2967 to 46 ms: where it dropped and why

Faster

The work (patch 0003) attacks every layer of the cost:

Page turn: a direct gray8-to-RGB565 copy with a 256-entry table (framebuffer/fast16.rs) and the prerender of the neighbour page on a separate thread (nice 5). beta8's page turn fell from 230.7 to 42.8 ms.
Text and layout: per-word shaping cache, reused HarfBuzz buffers, hyphenation patterns loaded lazily per language, CSS parsed once per document.
Chapters without waits: next-chapter layout in a worker and an on-disk layout cache (prefetch.rs, layoutcache.rs, dlcodec.rs), verified by dev/inode/size/mtime. That's the bar that collapses in the chart.
Compilation: MuPDF, HarfBuzz, FreeType and DjVuLibre built from source with LTO and NEON (layout dropped from 13.4 to 9.8 ms/KB), and the release profile with lto fat, codegen-units = 1 and target-cpu=cortex-a9. The binary shrank from 10,494,280 to 8,851,200 bytes (−16%).
E-ink: partial refresh between pages and a full refresh every 20 to control ghosting, plus zram to stretch the 512 MB.

More responsive

Responsiveness isn't only the UI. Wi-Fi took 10 seconds to scan because of a fixed timeout in the wext driver; switching it to nl80211,wext dropped the scan from 10.5 to 1.4 s and auto-connect to 5.0 s. Shutdown and restart were measured at 0.18–0.23 s between the request and the clean unmount of the onboard.

More robust

Robustness, in this project, is a security property. The heart is platox-boot, a static C program installed as PID 1 on Kobo's system partition. On every boot it verifies the kernel, a boot.manifest and the sha256 of the system image; and if anything fails —or if three boots in a row never reach Plato— it hands control to the stock init, Nickel. Plato's first paint resets that counter.

The boot selector: three checks and a safety net

The kernel-slot writer is just as careful: it writes with dd conv=notrunc,fsync, reads back and checks the sha256, and if it doesn't match it restores the verified previous copy without rebooting, all under timeout 300 and only with the battery at 30% or charging. KoboX 1.4's own init goes further and rejects foreign update packages: it applies only its own, with a manifest (sha256, size, paths, space, battery), and sets any stray KoboRoot.tgz aside without running it. The stable version (Master Edition) rounded this off with atomic config writes and a clean clippy -D warnings across all eight crates.

More up to date

Where the stock system was a 2015 museum, the own userland is today's: Buildroot 2025.02 LTS, glibc 2.41, busybox 1.37, wpa_supplicant 2.12 with mbedTLS and WPA3/SAE/OWE support — and no OpenSSL, no udev and no systemd. There's even an own 4.1.15 kernel rebuilt from Kobo's GPL sources with reliable suspend: the device hung on suspend, and by config bisection we found the cause was, paradoxically, removing CONFIG_PM_DEBUG; those debug messages were hiding a race in the board's suspend, so the fix was to leave it as in stock.

Method note and threat model

What this is and what it isn't, stated plainly:

There's integrity, not authenticity. platox-boot verifies the system's sha256 on every boot, but there are no signatures. A local attacker who can write to the onboard partition can replace the cpio and its manifest at once. This design's threat model is anti-brick and anti-corruption, not anti-attacker with physical access and write permission. Closing that would require the one thing we didn't touch: U-Boot and a root of trust in the SoC.
The API key is stored in plain text, in .platox/config/ai.toml, on the Kobo's own storage. It's documented that way and the recommendation is explicit: use a revocable key with a spending limit. The UI masks it to its last four characters and it never reaches the logs; the diagnostics redact secrets before writing anything.
It doesn't phone home. No telemetry, no account, no update check. The device talks to the AI provider you configure, only when you ask it to, and to pool.ntp.org for the time. Wi-Fi is off unless an action needs it.
Debloat doesn't delete, it hides. It's done with 0-byte placeholders inside the update package and a protect-list that never touches the critical pieces. It is reversible and cannot, by construction, repeat the brick that inspired it.
Supply chain: sources pinned by version and sha256, reproducible kernel and packages, and a check-public.sh that refuses personal data, private infrastructure and Kobo's proprietary files before every release.

What we take away

The updater is the vector. An OTA mechanism that applies packages on implicit trust —no signature, over a partition that mounts via USB— is the front door, not a side detail. If you design hardware, that's where the signature goes.
State on disk is security state. Five bytes in the MBR decided whether the device wiped itself. Whoever replaces the system inherits its invariants; discovering them late costs a device.
Integrity isn't authenticity. A sha256 per boot protects you from corruption and bricking, not from an attacker who controls the bit. Knowing which of the two problems you're solving is half the work.
Bricks are data. Every device we left unusable —permissions, space, one too many pickel-imx on a delete list— taught a system invariant no documentation told us.

A 512 MB reader turned out to be a full hardware-security target: an unsigned boot chain, an implicit-trust updater, security state on disk and a recovery mode with sharp teeth. Turning it into a verified, fast system of our own was the excuse; the trust map that came out of the process is what we take away.

Resources

Plato, by Bastien Dejean — the open-source reader at the heart of it all: github.com/baskerville/plato.
PlatoX — the public edition (AGPL-3.0) of this work; no public repository yet.
Buildroot — the embedded system that boots in RAM: buildroot.org.

Convertir un e-reader en tu sistema: ingeniería inversa del Kobo Libra 2

Wed, 04 Nov 2026 10:00:00 GMT

Es un lector de libros. Pantalla e-ink, Wi-Fi, 512 MB de RAM, un SoC que NXP dejó de considerar nuevo hace casi una década. La clase de aparato que nadie mira con ojos de atacante porque "no tiene nada dentro". Y sin embargo tiene todo lo que hace interesante a un objetivo de hardware: una cadena de arranque sin secure boot, un mecanismo de actualización OTA que aplica paquetes con confianza implícita, una partición de usuario que se monta por USB como una memoria cualquiera, y un contador en el MBR que decide si el aparato se borra solo.

Este artículo es el registro de lo que le hicimos a un Kobo Libra 2: ingeniería inversa de su arranque y su mecanismo de actualización, un selector de arranque propio en C que verifica el sistema por sha256 en cada boot, un kernel propio, y la conversión de Plato —un lector de documentos open-source— en el sistema operativo entero del dispositivo. El resultado público se llama PlatoX y es software libre (AGPL-3.0); la versión personal, con más cosas enganchadas, se llamó KoboX. Vamos a separar las dos con cuidado, porque la seguridad está en los detalles y mezclar ediciones es mentir con precisión.

No es un tutorial de jailbreak. Es un caso de estudio de seguridad del hardware: qué se puede aprender de un dispositivo cerrado leyendo su propio firmware, dónde están los límites reales de confianza, y por qué "integridad" y "autenticidad" no son la misma palabra.

El ecosistema que había que entender antes de tocar nada

La primera regla de cualquier intervención sobre hardware ajeno: reconstruir el sistema de serie antes de cambiar un solo byte. No se puede defender —ni romper con control— lo que no se entiende.

El aparato es un Kobo Libra 2, nombre interno io, placa E70K10, confirmado leyendo la tabla de PCB de kobo_config.sh del propio firmware. Dentro: un SoC NXP i.MX6SLL (ARM Cortex-A9), PMIC Rohm BD71828, Wi-Fi Realtek RTL8723DS por SDIO, pantalla e-ink de 1264×1680 y 512 MB de RAM. El stack de software de serie, reconstruido pieza a pieza desde el firmware extraído, es un museo de Linux embebido de 2015:

El stack de serie: de U-Boot a Nickel, sin un solo eslabón firmado

Arranque: U-Boot de NXP (2016.03-00128 en la rama 4.38), sin verificación de firma. Quien controle lo que el kernel ejecuta como init, controla el aparato.
Kernel: Linux 4.1.15, build exacto de Kobo -00868-g58a2758be07, compilado con GCC 5.3.0.
Userland: busybox 1.31.1 como PID 1, glibc 2.19, libstdc++ de GCC 4.9. udev 142, wpa_supplicant 2.9 sobre OpenSSL 1.0.1u.
El lector: Nickel, la aplicación Qt de Kobo, con su tienda y su cuenta.
pickel: un wrapper de shell que ejecuta pickel-imx (un ELF). Guárdalo en la cabeza: pickel es quien decide si el aparato hace factory-reset o acepta una actualización. Es, sin saberlo, una pieza de seguridad.

El almacenamiento es un eMMC /dev/mmcblk0 con tres particiones y varias zonas crudas fuera de ellas:

Zona	Qué es	Tamaño / posición
`mmcblk0p1`	`rootfs` (donde corre Nickel)	256 MB ext4
`mmcblk0p2`	`recoveryfs`	384 MB ext4
`mmcblk0p3`	`KOBOeReader` (el "onboard", visible por USB)	29,1 GB vfat
zImage	kernel crudo	sector 2048
hwconfig	config de hardware	sector 1024
waveform	tabla e-ink	sector 14336

Ese 256 MB de la rootfs y ese vfat de la partición de usuario no son detalles: los dos nos mordieron más adelante. El firmware de referencia quedó fijado a la versión 4.38.23828 (los hashes de kernel que el sistema acepta están anclados a ella).

Ingeniería inversa: proceso y resultados

Con el mapa en la mano, la pregunta operativa es una sola: ¿cómo se mete código propio sin abrir el aparato ni tocar U-Boot? La respuesta estaba en el propio mecanismo de actualización de Kobo.

El vector: `KoboRoot.tgz` y la confianza implícita

Kobo actualiza así: si el init de serie encuentra un fichero .kobo/KoboRoot.tgz en el almacenamiento, lo desempaqueta sobre / como root y reinicia. En el rcS de serie eso ocurre alrededor de las líneas 251–269, con pickel can-upgrade como guardián. No hay firma. No hay verificación de origen. Es un tar/gzip de ficheros propiedad de root que se extrae sobre el sistema, y los binarios tienen que ir en modo 755.

Dicho en lenguaje de amenazas: el actualizador es el vector. Cualquiera que pueda escribir en la partición de usuario —que se monta por USB sin credenciales— puede colocar un KoboRoot.tgz que el sistema aplicará como root en el siguiente arranque. Toda la cadena de confianza del dispositivo se apoya en que nadie meta un fichero en una carpeta. Ese es el eslabón que convierte un lector cerrado en un sistema abierto, y el que un diseño con secure boot cerraría.

El contador de arranque en el MBR

El hallazgo más bonito de toda la ingeniería inversa no estaba en un binario, sino en cinco bytes del MBR. En /dev/mmcblk0, offsets 0x133–0x137, Kobo guarda un contador de arranque. En cada boot, pickel should-factory-reset lo incrementa; cuando el índice llega a 4, el aparato muestra la pantalla de factory-reset y se borra. Lo único que resetea ese contador es Nickel, que escribe la secuencia 8d ef 02 d2 00 cuando arranca bien.

La consecuencia de seguridad es profunda: un contador en disco es estado de seguridad, y si tu sistema sustituye a Nickel, hereda su obligación. Un sistema propio que arranque en lugar de Nickel y no resetee ese contador se autodestruye en cuatro reinicios. Tuvimos que replicar el gesto exacto de Nickel —escribir 8d ef 02 d2 00 en el offset 307, releer y registrar— solo cuando Plato llevaba vivo más de un umbral de tiempo. Un test de mutación (escribir en el offset 308) debía fallar, y fallaba. Eso llegó en la versión 1.0.3, después de verlo borrarse en el banco de pruebas.

Los bricks, contados como lo que son: resultados

La parte honesta de cualquier trabajo sobre hardware es la lista de veces que lo dejaste inservible. Cada brick fue un hallazgo sobre el sistema:

Permisos (EACCES): empaquetamos rcS en modo 644. busybox init lo invoca con execv, que exige el bit de ejecución → EACCES → no arranca nada. Se corrigió enviándolo en 755 con un check_exec de guarda. (fix 1.0.1)
Espacio (ENOSPC): metimos 44,5 MB en una rootfs de 256 MB que ya iba al 93%. El etc/ se extendió a medias y el aparato se quedó en el splash sin llegar a Plato. La solución fue mover Plato al onboard (vfat) y dejar la rootfs con un delta de 29 KB, con un límite duro de ≤ 256 KB en la partición de sistema. (fix 1.0.2)
El factory-reset autoinfligido: una fase de debloat temprana metió todo lo de /usr/local/Kobo/* en la lista de borrado… incluido pickel-imx. Siguiente arranque: pickel should-factory-reset devuelve 127, el sistema interpreta eso como "hay que resetear", entra en recovery, reflashea el firmware 4.33.19747 y borra el onboard. De ahí nació la regla más importante del proyecto: una protect-list que nunca deja tocar pickel*, udev, init.d, las imágenes de U-Boot ni ld.so.preload. El debloat, además, pasó a hacerse con placeholders de 0 bytes dentro del KoboRoot.tgz, nunca con rm sobre el sistema vivo.

Expande

Cuando el aparato ya no arranca: recuperación por RAM sobre fastboot.

Tras uno de esos bricks hubo que construir un salvavidas que no exigiera abrir el aparato. El Kobo, como muchos i.MX6, expone un modo fastboot que enumera como USB 18d1:0d02 ("USB download gadget"), pero su comando boot llama a la rutina boota de NXP y espera una imagen Android boot.img v0, no un uImage clásico. Con mkbootimg (kernel en 0x80008000, ramdisk en 0x83800000, DTB como second en 0x83000000) el aparato enumera como "KoboRescue" en cuatro segundos y arranca un sistema de rescate desde RAM, sin tocar el eMMC.

El detalle que convirtió la herramienta de rescate en una herramienta peligrosa: desensamblando U-Boot encontramos que _detect_bootmode corre dentro de bootz, y que mantener power + page un par de segundos tras entrar en fastboot dispara "recovery cus 9" → root=/dev/mmcblk0p2 → el rcS de recovery reflashea U-Boot y kernel de la 4.33 y formatea la p1 y el onboard, sin preguntar. El contador del MBR no interviene aquí. La herramienta se corrigió para reclamar la interfaz al instante y mandar getvar:version, desarmando el timeout de un segundo que provocaba ese camino.

Kernel y módulos: confianza reconstruida desde el binario

Querer cargar módulos propios (zram, tun) en el kernel de Kobo obliga a reconstruir la confianza que Kobo no publica. El kernel verifica vermagic y los CRC de cada símbolo; un módulo compilado contra cabeceras que no cuadran al bit se rechaza con Invalid argument.

El proceso fue arqueología de binarios:

Extraer del aparato su propio config.gz (vía IKCONFIG_PROC) y su tabla kallsyms: 75.337 símbolos.
Reconstruir el Module.symvers del kernel de serie directamente desde el zImage oficial, con un descompresor LZO1X propio para abrirlo y localizando __ksymtab/__kcrctab con kallsyms: 6.847 símbolos, todos contrastados contra kallsyms.
Verificar cada módulo con check-module.py (identidad de vermagic) y verify-crcs.sh, recomputando los CRC desde fuentes propias: 186 iguales, 0 distintos.

El árbol de kernel de la Libra 2 (2021) no traía los drivers de esta placa, pero el de la Clara 2E (2023) encajaba con la config del aparato salvo una opción. Las compilaciones salieron reproducibles: tun.ko y zsmalloc.ko idénticos byte a byte entre builds. Esa es la diferencia entre "parece que funciona" y "sé exactamente qué estoy cargando en ring 0".

Qué es Plato, y qué es PlatoX

Plato es un lector de documentos open-source para e-readers, escrito en Rust por Bastien Dejean, pensado como alternativa a Nickel: rápido, sin tienda, sin cuenta. Es el lector; no es el sistema.

PlatoX es la idea que da sentido a todo lo anterior: coger Plato y convertirlo en el sistema operativo entero del Kobo. En vez de parchear Nickel, lo sustituimos del todo. El aparato arranca un pequeño sistema Buildroot desde RAM, verificado por sha256, y cae directamente en Plato: sin tienda, sin cuenta, sin servicio de sincronización. Técnicamente, PlatoX es Plato 0.9.45 más una serie de nueve parches (plato-patches/0001–0009) y un puñado de crates de Rust propios. Nickel se queda instalado e intacto: si algo falla, el Kobo arranca Nickel como siempre.

Conviene fijar los dos nombres antes de seguir, porque de aquí en adelante importa:

KoboX (y su evolución KoboX 2 / "0.2 Master Edition") es el firmware personal completo, con cosas que dependen de infraestructura propia: Tailscale, una terminal, mercados, tiempo, noticias, Home Assistant, sincronización de biblioteca.
PlatoX 0.1 es la destilación pública (AGPL-3.0): Plato como sistema, las optimizaciones, el asistente de IA y la calculadora. Todo lo personal se quitó a propósito, y con ello buena parte de la superficie de ataque.

Tres capas: arranque verificado, Plato como UI, y los crates de Rust detrás

Las funcionalidades nuevas de Plato

Sobre Plato se añadieron funciones que lo convierten en un entorno completo. Las clasifico por edición, porque un lector de seguridad querrá saber exactamente qué código corre en la versión pública.

En PlatoX público (open source)

Plato como launcher (parche 0001): rutas desde el arrancador, entradas por nombre. Es lo que permite que Plato sea el sistema y no una app más.
Panel de red y selector de Wi-Fi (parche 0002): un view/network_panel.rs nuevo (+281 líneas) que abre, desde cualquier vista, un panel con el estado del Wi-Fi en frases legibles (Apagado / Buscando una red conocida… / Conectado a X / No hay ninguna red conocida cerca), IP y señal. El icono de la barra tiene cuatro estados (wifi-off, wifi-connecting, wifi, wifi-secure) y un hilo poller lo actualiza cada 2 s, nunca desde el hilo de la UI.
Asistente de IA (parches 0004 y 0009): sobre una selección de texto, Resumir, Traducir o Explicar; sobre un libro, insights —reseña corta, reseña extendida, resumen o un mapa de conceptos navegable (view/concept_map.rs, +801 líneas)—. Funciona con tu propia clave: OpenAI, Claude (vía la Messages API nativa con streaming por SSE, con claude-opus-5-5 preseleccionado si tu clave lo lista), DeepSeek o cualquier servidor compatible en tu red. Las respuestas se cachean offline y el Wi-Fi solo se enciende cuando una petición lo necesita, apagándose tras cinco minutos de inactividad.
Calculadora estilo teléfono (parche 0006): reemplaza la vieja calculadora de línea de comandos de Plato por una de teclas. Detrás va el crate platox-calc, con un decimal exacto (0,1 + 0,2 = 0,3, no 0,30000000000000004), porcentaje y descuento (120 − 15 % = 102, con la línea "Descuento: 18"), raíz cuadrada y división por cero controlada.
Menú limpio, About y System Info (parche 0005): el menú cabe en una página, Reiniciar y Apagar quedan siempre visibles, y la gestión de Wi-Fi se va entera al panel de red. De paso, System Info arregla un bug del propio Plato, que mostraba la carga del sistema multiplicada por 100 con un signo de "%", y la memoria libre en vez de la disponible.
Herramientas de desarrollo (parche 0007): Test All y Benchmark, detrás de un marcador de desarrollador, con redacción de secretos en los diagnósticos (nada de api-keys, tokens o PSK en los logs).

En KoboX (firmware personal, fuera de la versión pública)

Esto existe y funciona, pero depende de infraestructura propia y se quitó del público para reducir superficie: Tailscale (primero en modo usuario, luego con TUN y módulo propio), una terminal (shell de busybox sobre un pty, con fastfetch y ssh), Markets (datos de Yahoo), Weather (Open-Meteo), News (un generador propio con trafilatura en un contenedor endurecido contra SSRF), Home Assistant (luz y clima por un túnel CONNECT) y sincronización de PDF contra un Calibre-Web propio.

La optimización final: más rápido, más robusto, más responsive, más actualizado

Un lector que tarda dos segundos en cambiar de capítulo es inusable, por muy elegante que sea su arquitectura. La última fase fue una campaña de rendimiento con una regla estricta: medir en el aparato, no en el host. Estas son las medianas, iteración a iteración, de la versión 1.4:

Métrica (mediana)	Antes (beta7)	Después (beta12)
Pasar página (EPUB)	231 ms	31 ms
Cambio de capítulo	2967 ms	46 ms
Abrir / reabrir libro	1265 ms	74 ms
Primer paint tras encender	9,4 s	6,9 s
Wi-Fi conectado	12–13 s	5,0 s

El cambio de capítulo, de 2967 a 46 ms: dónde cayó y por qué

Más rápido

El trabajo (parche 0003) ataca cada capa del coste:

Pasar página: una copia directa de gray8 a RGB565 con una tabla de 256 entradas (framebuffer/fast16.rs) y el prerender de la página vecina en un hilo aparte (nice 5). El page turn de beta8 cayó de 230,7 a 42,8 ms.
Texto y layout: caché de shaping por palabra, buffers de HarfBuzz reutilizados, patrones de guionado cargados en diferido por idioma, CSS parseado una sola vez por documento.
Capítulos sin esperas: layout del siguiente capítulo en un worker y caché de layout en disco (prefetch.rs, layoutcache.rs, dlcodec.rs), con verificación por dev/inode/tamaño/mtime. Esa es la barra que se desploma en el gráfico.
Compilación: MuPDF, HarfBuzz, FreeType y DjVuLibre compilados desde fuente con LTO y NEON (el layout bajó de 13,4 a 9,8 ms/KB), y el perfil de release con lto fat y codegen-units = 1 y target-cpu=cortex-a9. El binario encogió de 10.494.280 a 8.851.200 bytes (−16 %).
E-ink: refresco parcial entre páginas y refresco completo cada 20 para controlar el ghosting, más zram para estirar los 512 MB.

Más responsive

La responsividad no es solo la UI. El Wi-Fi tardaba 10 segundos en escanear por un timeout fijo del driver wext; cambiándolo a nl80211,wext, el escaneo bajó de 10,5 a 1,4 s y la autoconexión a 5,0 s. El apagado y reinicio se midió en 0,18–0,23 s entre la petición y el desmontaje limpio del onboard.

Más robusto

La robustez es, en este proyecto, una propiedad de seguridad. El corazón es platox-boot, un programa en C estático instalado como PID 1 en la partición de sistema de Kobo. En cada arranque verifica el kernel, un boot.manifest y el sha256 de la imagen del sistema; y si algo falla —o si se encadenan tres arranques que no llegan a Plato— cede el control al init de serie, Nickel. El primer paint de Plato resetea ese contador.

El selector de arranque: tres comprobaciones y una red de seguridad

El escritor de la ranura del kernel es igual de cuidadoso: escribe con dd conv=notrunc,fsync, vuelve a leer y comprueba el sha256, y si no cuadra restaura la copia verificada previa sin reiniciar, todo bajo timeout 300 y solo con la batería al 30 % o cargando. El init propio de KoboX 1.4, además, rechaza paquetes de actualización ajenos: solo aplica los suyos, con manifiesto (sha256, tamaño, rutas, espacio, batería), y aparta cualquier KoboRoot.tgz extraño sin ejecutarlo. La versión estable (Master Edition) remató esto con escrituras atómicas de configuración y clippy -D warnings limpio en los ocho crates.

Más actualizado

Donde el sistema de serie era un museo de 2015, el userland propio es de hoy: Buildroot 2025.02 LTS, glibc 2.41, busybox 1.37, wpa_supplicant 2.12 con mbedTLS y soporte de WPA3/SAE/OWE — y sin OpenSSL, sin udev y sin systemd. Hay incluso un kernel propio 4.1.15 recompilado desde las fuentes GPL de Kobo con suspensión fiable: el aparato se colgaba al suspender, y por bisección de configuración encontramos que la causa era, paradójicamente, quitar CONFIG_PM_DEBUG; esos mensajes de depuración ocultaban una race en la suspensión de la placa, así que la solución fue dejarlo como en stock.

Nota de método y modelo de amenazas

Lo que esto es y lo que no es, dicho sin adornos:

Hay integridad, no autenticidad. platox-boot verifica el sha256 del sistema en cada arranque, pero no hay firmas. Un atacante local que pueda escribir en la partición onboard puede sustituir a la vez el cpio y su manifiesto. El modelo de amenazas de este diseño es anti-brick y anti-corrupción, no anti-atacante con acceso físico y permiso de escritura. Cerrar eso exigiría lo único que no tocamos: U-Boot y una raíz de confianza en el SoC.
La clave de API va en claro, en .platox/config/ai.toml, en el almacenamiento del propio Kobo. Está documentado así y la recomendación es explícita: usa una clave revocable y con límite de gasto. La UI la enmascara a sus últimos cuatro caracteres y nunca llega a los logs; el diagnóstico redacta secretos antes de escribir nada.
No llama a casa. No hay telemetría, ni cuenta, ni comprobación de actualizaciones. El aparato habla con el proveedor de IA que tú configures, solo cuando se lo pides, y con pool.ntp.org para la hora. El Wi-Fi está apagado salvo que una acción lo necesite.
El debloat no borra, oculta. Se hace con placeholders de 0 bytes dentro del paquete de actualización y una protect-list que jamás toca las piezas críticas. Es reversible y no puede, por construcción, repetir el brick que lo inspiró.
Cadena de suministro: fuentes fijadas por versión y sha256, kernel y paquetes reproducibles, y un check-public.sh que rechaza datos personales, infraestructura privada y ficheros propietarios de Kobo antes de cada publicación.

Lo que nos llevamos

El actualizador es el vector. Un mecanismo OTA que aplica paquetes con confianza implícita —sin firma, sobre una partición que se monta por USB— es la puerta de entrada, no una pieza secundaria. Si diseñas hardware, ahí es donde va la firma.
El estado en disco es estado de seguridad. Cinco bytes en el MBR decidían si el aparato se borraba. Quien sustituye al sistema, hereda sus invariantes; descubrirlas tarde cuesta un dispositivo.
Integridad no es autenticidad. Un sha256 por boot te protege de la corrupción y del brick, no de un atacante que controle el bit. Saber cuál de los dos problemas estás resolviendo es la mitad del trabajo.
Los bricks son datos. Cada aparato que dejamos inservible —permisos, espacio, un pickel-imx de más en una lista de borrado— enseñó una invariante del sistema que ninguna documentación contaba.

Un lector de 512 MB resultó ser un objetivo de hardware security completo: cadena de arranque sin firmar, actualizador de confianza implícita, estado de seguridad en disco y un modo de recuperación con los dientes afilados. Convertirlo en un sistema propio, verificado y rápido fue la excusa; el mapa de confianza que salió del proceso es lo que nos llevamos.

Recursos

Plato, de Bastien Dejean — el lector open-source en el corazón de todo: github.com/baskerville/plato.
PlatoX — la edición pública (AGPL-3.0) de este trabajo; sin repositorio público por ahora.
Buildroot — el sistema embebido que arranca en RAM: buildroot.org.

sec - QUANTARMY

Whose router is it? Reverse-engineering a Digi Comtrend GRG-4355u

The ecosystem: a vendor OpenWrt with shared owners

Reverse engineering: from guest to root, over the network

What this means

What we did next: a neutral, hardened router

And own firmware? The honest verdict

Threat model and what we take away

Resources

¿De quién es tu router? Ingeniería inversa de un Comtrend GRG-4355u de Digi

El ecosistema: un OpenWrt del fabricante con dueños compartidos

Ingeniería inversa: de invitado a root, por la red

Lo que esto significa

Qué hicimos después: un router neutro y endurecido

¿Y firmware propio? El veredicto honesto

Modelo de amenazas y lo que nos llevamos

Recursos

Turning an e-reader into your own system: reverse-engineering the Kobo Libra 2

The ecosystem you had to understand before touching anything

Reverse engineering: process and results

The vector: KoboRoot.tgz and implicit trust

The boot counter in the MBR

The bricks, told as what they are: results

Kernel and modules: trust rebuilt from the binary

What Plato is, and what PlatoX is

The new features on Plato

In public PlatoX (open source)

In KoboX (personal firmware, outside the public version)

The final optimization: faster, more robust, more responsive, more up to date

Faster

More responsive

More robust

More up to date

Method note and threat model

What we take away

Resources

Convertir un e-reader en tu sistema: ingeniería inversa del Kobo Libra 2

El ecosistema que había que entender antes de tocar nada

Ingeniería inversa: proceso y resultados

El vector: KoboRoot.tgz y la confianza implícita

El contador de arranque en el MBR

Los bricks, contados como lo que son: resultados

Kernel y módulos: confianza reconstruida desde el binario

Qué es Plato, y qué es PlatoX

Las funcionalidades nuevas de Plato

En PlatoX público (open source)

En KoboX (firmware personal, fuera de la versión pública)

La optimización final: más rápido, más robusto, más responsive, más actualizado

Más rápido

Más responsive

Más robusto

Más actualizado

Nota de método y modelo de amenazas

Lo que nos llevamos

Recursos

The vector: `KoboRoot.tgz` and implicit trust

El vector: `KoboRoot.tgz` y la confianza implícita