Le Glasfaser est le premier ONT tiers que j'avais utilisé après mon retour chez ByTel et pourtant cela n'a pas fonctionné.
Les informations techniques sont très intéressantes.

L'ONT est un Huawei HG8010H avec firmware customisé par ByTel (et FS chiffré).
UI fournit un mode Huawei avec son ONT pour aider à la connexion en effet.

Pour le "Press any key to stop auto run" :
 - bizarrement le code de runDelay oblige à l'afficher (si la valeur est configurée à 0, alors pas de boot automatique)
 - console_status teste si une touche a été appuyée, à priori ça devrait fonctionner, sauf si le code a été modifié, ou si cfe_set_console n'a pas été appelé, ou bien sûr si quelque chose empêche le fonctionnement au niveau HW

Sur l'UART en général :
 - dans cfe/arch/arm/board/bcm63xx_shared/src/bcm63xx_impl2_common.S, l'UART semble ouverte en rw, sauf pour le BTRM (INC_BTRM_BUILD==1)
 - je ne vois pas d'appel à cfe_set_console, c'est peut-être dans un fichier de board absent
 - sans cfe_set_console, il n'y aurait à priori pas de trace, à part dans le CFE ROM (qui a "xprinthook = board_puts;")
 - en recherchant board_getc, je vois que le CFE ROM pourrait avoir une fonction chek_abort_key, et être interrompu en envoyant "a"

Ca s'arrête effectivement à la boot ROM.
Ca confirme donc que le CFE ROM et le CFE RAM sont sur la NAND.

Il n'y a pas toutes les sources de la boot ROM, donc je ne sais pas à quoi correspondent les différentes traces :
 - OTP? / OTPP : probablement la lecture de fusibles OTP pour configurer le SoC (modes de boot, éventuellement chiffrement / signature).
 - USBT : peut-être USB Test, mais il n'y a pas de port USB de câblé

Si c'est possible, on pourrait essayer de faire le court-circuit sur la NAND plus tard : soit entre le CFE ROM et le CFE RAM, soit au moment où le CFE RAM charge le kernel.

Avec un multimètre en test de diode, on peut vérifier si on voit les diodes de protection du SoC avec GND et +3.3V.

Il faudrait tester si la console CFE fonctionne en ayant booté avec le bouton appuyé, on ne sait jamais.

Mais si c'est effectivement désactivé, il ne restera comme options que :
 - attaquer le serveur web du CFE (boot avec le bouton reset) : cfe/board/bcm63xx_ram/src/bcm63xx_httpd.c (ça ne semble permettre que de flasher)
 - attaquer le firmware (vous être déjà plusieurs à avoir essayé)
 - dessouder la NAND pour la lire

Pas de réaction au port série quand il a "planté" ?

Les traces n'indiquent pas si les console réagit ou non aux appuis touche, je suppose que non du coup.
Pour la durée, il ne me semble pas avoir vu quelque chose dans les sources ASUS.
La détection du bouton, et l'init de la PHY 2.5Gbps c'est spécifique à cette cible, mais si le code lance le serveur web, c'est bizarre d'avoir un timeout (à moins qu'il soit arrêté dès le chargement de la page web).

L'interface web est à priori spécifique à Deutsche Telekom.
Les attaques de base sont :
 - directory traversal pour récupérer des fichiers
 - regarder si des valeurs sont passées au shell (system(...) sans protection)
Sinon, il faudrait chercher s'il y a eu des CVE ou des dumps d'autres ONT ou box de Deutsche Telekom (ça pourrait être la même UI).

Pour bloquer, ils auraient pu désactiver le serveur web, il y a un flag pour ça.
Peut-être qu'ils ont gardé un CFE plus proche voire identique au dev, et qu'ils ont un test quelque part, mais dans ce cas ça n'a pas l'air très bien fait.

Puisque la mise à jour se fait via OMCI, il est peu probable de trouver des firmwares.
Et si jamais le firmware est chiffré et signé...