Chromecast V1 - Suite
Décryptage du bootflow, exploitation FlashCast, durcissement des accès et instrumentation du premier dongle Google Cast.
Cette suite complète l'introduction au reverse engineering de la Chromecast première génération. On se concentre ici sur les mécanismes bas niveau : cartographie précise du SoC Marvell, déroulé du bootloader, chaînes d'exploitation historiques et méthodes actuelles pour instrumenter ou durcir l'équipement sans rompre l'écosystème Google Cast.
Anatomie matérielle approfondie
Le PCB du Chromecast V1 repose sur un Marvell Armada 1500-mini (88DE3005), un ARM Cortex-A9 simple cœur cadencé à 1.2 GHz, combiné à 512 MB de DDR3L Micron et 2 GB d'eMMC. Le module Wi-Fi/Bluetooth AzureWave AW-NH387 gère le double bande 2.4/5 GHz.
L'accès aux surfaces de test (TP) est facilité par l'enrobage minimal. Les points UART et JTAG sont dispersés au dos du PCB, masqués par des pastilles non étamées.
| Point de test | Signal | Notes |
|---|---|---|
| TP12 | UART TX (3.3V) | Console bootloader, 115200 8N1 |
| TP13 | UART RX | Réception console, nécessite résistance pull-up 10 kΩ |
| TP28 / TP29 | SWD / JTAG TCK-TMS | Non documenté officiellement, sondable avec adaptateur ARM 20 pin |
| TP33 | eMMC CLK | Point d'accroche pour analyse logique lors du boot |
Bootflow & surfaces d'injection
Le pipeline logiciel du Chromecast repose sur un Boot ROM propriétaire suivi d'un U-Boot signé et d'un noyau Linux Chrome OS modifié. Chaque étape effectue une vérification cryptographique SHA-256/RSA contre un jeu de clés brûlées dans les eFuses.
Boot ROM (BL0)
Charge le premier loader signé stocké sur l'eMMC et, si la broche BOOT_SEL est forcée, bascule sur un média USB OTG pour rechercher une image alternative.
U-Boot (BL1)
Expose une console masquée par défaut. Le mode "developer" rétablit les commandes usbboot et, sur les révisions vulnérables, un gadget fastboot capable de charger FlashCast en mémoire.
Kernel Chrome OS
Monte les partitions system, config et cache. Le rootfs est en lecture seule, overlayfs temporaire pour les mises à jour OTA.
Processus Cast
Lance /opt/google/chrome/chromecast_shell et le service Cast Receiver. Les politiques SELinux limitent les accès fichiers.
Interfaces bas niveau
Console série
Une fois le shield retiré, soudez trois fils (TX, RX, GND). Paramètres : 115200 bauds. La commande printenv révèle les variables U-Boot, notamment bootcmd, bootargs et developer_mode.
BOOT_SEL pour basculer entre boot eMMC et USB, pratique pour alterner firmware stock et image d'analyse.
Mode USB Boot
En mode développeur, U-Boot écoute fastboot. Il est possible de charger un initramfs en RAM (fastboot boot initrd.img) pour effectuer un dump non intrusif de l'eMMC via dd et netcat.
Accès CPU
Marvell a implémenté un mode sécurisé. La chaîne TAP répond uniquement si les eFuses JTAG_DISABLE sont intacts. Sur révision V1.1, la désactivation est effective : privilégier UART + glitch pour extraire les registres.
Exploitation FlashCast & variantes
FlashCast est un environnement initramfs conçu par la communauté exploitee.rs. Il profite du boot USB pour amorcer une image busybox minimaliste et offrir une console root sans signature Google.
flashcast.bin.
developer_mode=1.
usb start puis load usb 0 0x82000000 flashcast.bin suivi de go 0x82000000.
/flashcast.d/ pour activer ssh, désinstaller recovery ou rediriger ota.conf vers un miroir local.
Construire un firmware custom
Pour conserver la compatibilité Cast tout en bénéficiant d'un accès root, il est recommandé de générer un initramfs personnalisé qui applique les correctifs à la volée sans modifier l'image noyau originale.
mmcblk0p2 (boot) et mmcblk0p5 (system). Utilisez binwalk -e pour récupérer les composants squashfs.busybox avec dropbear, iptables, tcpdump. Ajoutez des scripts init.d pour monter l'overlay et copier vos clés SSH dans /mnt/stateful_partition.bootcmd pour charger votre initramfs : setenv bootcmd 'run loadkernel; run loadinitrd; bootm ${kernel_addr} ${ramdisk_addr}', puis saveenv./etc/avahi/services/cast-ota.service vers un serveur de test ou bloquez les domaines ota.googlezip.net via iptables pour éviter les relock.dd if=/dev/mmcblk0 of=/mnt/flashcast/backup.img bs=4M) avant tout changement. Cela permet un retour stock via fastboot flash.
Instrumentation et observation
Une fois l'accès root obtenu, il est possible d'instrumenter le runtime Cast pour comprendre les échanges TLS et l'orchestration applicative.
- Hook userland : LD_PRELOAD sur
libcast.sopour logger les messages protobuf avant chiffrement. - Inspection réseau :
tcpdump -i wlan0 -w /tmp/cast.pcapcombiné àmitmproxyvia un AP contrôlé pour analyser la phase Pairing. - Profiling GPU : utilisation de
/sys/kernel/debug/mali0(activable via module) pour suivre la consommation lors des décodages VP8. - Audit SELinux : positionner
setenforce 0temporairement pour tracer les refus (/var/log/audit.log) et ajuster les politiques dans/vendor/etc/selinux/.
strace -ff -p $(pidof chromecast_shell) couplé à un timestamp haute résolution permet de cartographier la latence des actions Cast (join, play, heartbeat).
Contre-mesures Google & retours terrain
Depuis 2014, Google a progressivement verrouillé le bootloader. Les révisions matérielles postérieures intègrent un OTP rendant impossible l'amorçage de binaires non signés. La première génération reste toutefois vulnérable si elle n'a jamais reçu les mises à jour finales.
- Bootloader 19084+ : vérification RSA obligatoire, nécessité d'une faille matérielle (glitch, voltage) pour détourner la vérification.
- Rollback indexes : eFuses incrémentés à chaque OTA majeure. Impossible de flasher un firmware plus ancien sans patch hardware.
- Mises à jour silencieuses :
update_enginedéclenche des reboots nocturnes. Sur un Chromecast rooté, placez un script/usr/local/bin/prevent_update.shpour stopper le service. - Durcissement réseau : depuis 1.36.x, toutes les communications Cast sont TLS 1.2 avec pinning. L'interception nécessite instrumentations locales (hooking, sidecar).
VSYS, VDDA) avec une sonde crowbar contrôlée par FPGA.
Annexes & ressources
Pour aller plus loin, voici quelques pistes de travail complémentaires :
Plan de câblage automatisé
Créer un gabarit 3D imprimé pour fixer la Chromecast sur un banc de glitch et sécuriser les connexions UART.
Diffing d'OTA
Comparer les images .zip officielles et identifier les correctifs au bootloader via binwalk --diff et radiff2.
Pipeline de monitoring
Déployer un agent Fluent Bit sur le rootfs overlay pour remonter les logs Cast vers un ELK local.