J'ai pu corriger les erreurs dans le dump, grâce à https://github.com/ak-hard/brcm-nand-bch/issues/1#issuecomment-612458535.
La repo en question explique le format du BCH-4 utilisé par les versions plus anciennes du contrôleur, mais la discussion m'a donné les informations nécessaires (le polynôme 0x5803).
Avec https://github.com/StrayLightning/brcm-nand-bch/blob/master/decode.c (après correction d'une petite erreur dans le code), j'ai pu avoir un dump correct.
Bizarrement toutes les erreurs (1 ou 2 bits) sont uniquement dans le premier secteur des pages (aucune erreur sur les 3 autres secteurs).

unblob se débrouille mieux, on a :
 - 0x0000000-0x0200000 : CFE ROM ?
 - 0x0200000-0x03A0000 : UBI image "1886710111" (METADATA, METADATACOPY, filestruct_cfe.bin) => CFE RAM ?
 - 0x03A0000-0x0600000 : ? (pas grand chose : Cmx2W, cferam.000, header sErCoMm, que 256 octets de vraies données)
 - 0x0600000-0x07A0000 : UBI image "1886710111" (même contenu)
 - 0x07A0000-0x0C20000 : identique à 0x03A0000-0x0600000
 - 0x0A00000-0x0A20000 : SCFLMAPOK, et uniquement 240 octets en 0x0A00800, le reste à 0xff
 - 0x0A20000-0x0A40000 : identique à 0x0A00000-0x0A20000
 - 0x0A40000-0x0AA0000 : rien (0xff)
 - 0x0AA0000-0x0C20000 : J.DHP19M01E5 suivi de 0xFF
 - 0x0C20000-0x0C80000 : JFFS2
 - 0x0C80000-0x5C80000 : UBI images "901840304" (rootfs_ubifs, filestruct_full.bin) et "309480860" (lib_squashfs)
 - 0x60C0000-0x7FC0000 : JFFS2
 - 0x7FC0000-0x8000000 : ? (1tbB et des 0xff, Bbt0 et des 0xff)

A partir du filestruct_full.bin, on peut facilement extraire :
 - 96856.dtb : device-tree (pas grand chose dedans, rien d'intéressant dans la ligne de commande passée au kernel)
 - vmlinux.lz : kernel, qui une fois décompressé se trouve être un Linux 4.1.51 en ARM64 (alors que le rootfs est armv7)

unblob a trouvé le /proc/config.gz dans le kernel.
CONFIG_CMDLINE="console=ttyS0,115200 earlyprintk debug irqaffinity=0"
C'est bizarre d'avoir "earlyprink" et "debug" en production.
CONFIG_MTD_OF_PARTS=y donc les partitions doivent être définies dans la device-tree, mais ce n'est pas le cas.
Je suppose que le bootloader les ajoute dynamiquement, avec probablement quelque chose comme "ubi.mtd=0 root=ubi0:rootfs_ubifs" (à moins que ce soit chargé en RAM et booté comme un initrd).

Les deux squashfs (rootfs_ubifs et lib_squashfs) peuvent maintenant être extraits sans erreur.

Les JFFS2 ont toujours un contenu bizarre (surtout les noms de fichiers, et des binaires ELF dont la présence dans une zone rw m'étonne).

Il semble y avoir au moins des restes d'une WebUI complète (mais avec pas mal de fichiers stubs), en plus de celle limitée à laquelle on a accès.
Mais le /usr/sbin/mini_httpd référence des noms de fichiers, donc il y a peut-être un filtrage.

Il y a un setup.cgi, avec des références à sshd et telnet par exemple.

Le mini_httpd référence login.html et login/index.html, qui n'existent pas (à moins que ce soit autogénéré).
Il y a des fichiers autour du login qui sont des stubs :
 - /usr/www-ap/ONT/client/data/Login.json : []
 - /usr/www-ap/data/login.php
<?php
        if(isset($_POST)){
                foreach($_POST as $key => $value){
                        if($key == &#39;LoginName&#39;) $loginUserLoginName = $value;
                        if($key == &#39;LoginPWD&#39;) $loginUserLoginPassword = $value;
                        //
                        if($key == &#39;loginUserChkLoginTimeout&#39;) logout($value);
                        if($key == &#39;loginUserLoginMode&#39;) echo loginUserLoginMode($value);
                        if($key == &#39;chk_sys_busy&#39;) echo chk_sys_busy($value);
                        if($key == &#39;logout&#39;) echo userLogout($value);
                }
        }

        if(isset($loginUserLoginPassword)) echo userLogin($loginUserLoginPassword);


        function userLogin($pwd){
                return &#39;"1"&#39;;
        }

        function logout($val){
                echo &#39;[ ]&#39;;
        }

        function userLogout($val){
                echo &#39;1&#39;;
        }

        function loginUserLoginMode($val){
                echo &#39;enduser&#39;; //admin or enduser
        }

        function chk_sys_busy($val){
                echo &#39;0&#39;;
        }
?>
- /usr/www-ap/data/login.json : 1

Et il y a /usr/www-ap/js/login.js, mais qui semble pas être référencé (à moins que ce soit chargé dynamiquement, ou dans une page générée).

A priori mini_httpd est lancé par /usr/bin/smd, qui charge des plugins dans /opt/lib (ici libsl_http.so).
Donc tout est spécifique, ce n'est pas pratique à analyser.

Dans les URL qui pourraient être intéressantes (à voir si c'est autorisé), j'ai vu "settings_page/configurationBackup.cfg".
Il y a peut-être une login.html ou login/index.html quelque part, mini_httpd et setup.cgi référencent un /tmp/dt_login_flag (peut-être pour le filtrage).

Le "Welcome to your Sercomm GPON Router" est dans /usr/www-ap/lang/Cat13.csv, avec l'ID 1300069.
Mais effectivement je ne trouve pas de getHTMLString(1300069).
En revanche le /usr/www-ap/js/login.js a bien getHTMLString(809004), "Enter your username and password to access your configuration settings.".
Donc on a les URL :
 - data/user_lang.json pour récupérer "salt" (PBKDF2 avec le password pour sauvegarder "dk" dans la session, qui servira à chiffrer certaines requêtes) et "encryption_key"
 - il fait deux hex_hmac_sha256, et utilise data/login.json (donc probablement /usr/www-ap/data/login.php, dont on a une version stubbée sur le DT)

Sur la version DT, le login a clairement été désactivé, mais plus pour donner l'accès que l'enlever.
En revanche, le /tmp/dt_login_flag suggère qu'il y a un mécanisme supplémentaire.

Oui, j'ai vu quelques traces de shell comme ça, c'est soit un script, soit un system().

J'ai trouvé "config" en essayant différentes valeurs de uploadType.
A ce moment là, je me suis dit que si on peut envoyer une config, on peut peut-être faire une sauvegarde.
C'est donc pour ça que j'ai testé download.cgi, mais je n'ai uniquement pu confirmer sa présence, sans trouver comment l'appeler.

A priori download.cgi prend les paramètres this_file et next_file

Je n'ai pas compris l'usage de "this_file" qui semble ne pas être pris en compte dans mes tests, mais peut-être qu'il sert à un redirect une fois l'action effectué...
Pour next_file il semble qu'il y ai une liste d'action pré-défini dans download.cgi qui en fonction du mot clé (proche des nom de fichier à download) execute un script et renvoit le contenu. exemple:
http://192.168.100.1/download.cgi?this_file=status-and-support.html&next_file=eventlog.log le mot clé 'eventlog.log' est mappé au fichier eventlog.txt on peut ainsi récupérer le log de l'ONT (pas très intéressant)

D'autre part il semble que certaines URL nécessitent 2 paramètres "_" et "csrf_token" le paramètre "_" contient le résultat de "new Date().getTime()" (quand appelé depuis un fichier JS) et le csrd_token contient le token qui est injecté par mini_httpd (via cgi) dans les pages HTML via un tag de template, exemple la page "statusandsupport/status.html" contient
<script type="text/javascript">
csrf_token = '@csrf_token#';
</script>
On peut récupérer un token par exemple en appellant:
http://192.168.100.1/setup.cgi?next_file=statusandsupport/status.html

Je ne sais quel mapping décide si une page html doit on nous avoir les paramètre "_" et "_csrf_token" mais par exemple si on appelle "http://192.168.100.1/setup.cgi?next_file=statusandsupport/status.html" on a une response, alors que
http://192.168.100.1/setup.cgi?next_file=statusandsupport/lan.html?_=1&csrf_token=HK70CEDA65JW16333884 nécessite les _ et csrf_token

on note que:

• l'ordre des paramètre semble important donc "_" puis "csrf_token"
• le parametre "_" semble ne pas être validé puisque dans l'exemple précédent _=1 fonctionne même s'il devrait contenir un datetime epoch (résultat de "new Date().getTime()" en JS par exemple
• le jeton csrf n'est pas vérifié avec la meme 'rigueur' selon les pages, on peut parfois réutiliser le meme csrf pour plusieurs appels sur certaines page et 1 seule fois sur d'autre .... (doit y avoir une explication mais je ne l'ai pas)

Enfin comme indiqué par @hwti il a bien les restes d'une ancienne WebUI dans le dossier racine qui semble toujours fonctionner (du moins pour les parties supporté par le modem, par exemple il y a des pages pour la gestion d'un modem 3G qui évidement n'existe pas sur l'OLT). Donc en appellant tous les fichiers json du dossier /data "racine" (en utilisant les paramètres "_" et "csrf_token") on arrive à récupérer les JSON qui servent aux page de l'ancienne WebUI.

quelques exemple:

statussupportstatus.json:
[ { "sys_serial_number": "XXXXXXXXXXXX" }, { "sys_dt_serial_number": "XXXXXXXX" }, { "sys_firmware_version": "090144.1.0.001" }, { "sys_bootloader_version": "0100" }, { "sys_hardware_version": "Glasfaser-Modem 2 Glasfaser.DTV1" }, { "omci_software_version": "\t\t1.0.0.1_19385\t\t\n" }, { "sys_uptime": "0:5:48" }, { "sys_cpu_usage": "47.58%" }, { "sys_reboot_cause": "SW" }, { "sys_memory_usage": "70.08%" }, { "sys_date_time": "2023-06-07T09:28:08Z" }, { "sys_build_time": "2020-09-21 10:04:48\n" }, { "sys_model_name": "Glasfaser-Modem 2" }, { "sys_current_image": "FW1" }, { "sys_fw0_image_size": "13107200" }, { "sys_fw0_image_version": "090144.1.0.001" }, { "sys_fw0_image_crc": "25A0A707" }, { "sys_fw1_image_size": "13107200" }, { "sys_fw1_image_version": "090144.1.0.001" }, { "sys_fw1_image_crc": "25A0A707" }, { "inter_gateway": "" }, { "inter_primary_dns": "" }, { "inter_secondary_dns": "" }, { "inter_firewall": "601036" }, { "inter_ipv6_link_local_address": "" }, { "inter_ipv6_link_global_address": "" }, { "inter_ipv6_gateway": "" }, { "inter_ipv6_prefix_delegation": "" }, { "inter_ipv6_dns_address1": "" }, { "inter_ipv6_dns_address2": "" }, { "lan_ip_network": "192.168.100.1\/24" }, { "lan_default_gateway": "192.168.100.1" }, { "lan_mac_address": "A0:95:7F:39:4A:16" }, { "lan_dhcp_server": "601036" }, { "lan_dhcpv6_server": "601036" }, { "lan_router_advertisement": "601036" }, { "lan_ipv6_default_gateway": "" }, { "lan_port1_switch_mode": "1301722" }, { "lan_port2_switch_mode": "1301722" }, { "lan_port3_switch_mode": "1301722" }, { "lan_port4_switch_mode": "1301722" }, { "lan_port1_switch_speed": "0" }, { "lan_port2_switch_speed": "0" }, { "lan_port3_switch_speed": "0" }, { "lan_port4_switch_speed": "0" }, { "lan_port1_switch_status": "1301724" }, { "lan_port2_switch_status": "1301724" }, { "lan_port3_switch_status": "1301724" }, { "lan_port4_switch_status": "1301724" } ]
on trouve aussi une page sur le TR-069:
settings_tr069.json:
[ { "tr069_mode": "1" }, { "bind_wan_connection": "" }, { "ssl_version": "id:1|value:SSL 3.0|select:0~id:2|value:TLS 1.0|select:0~id:3|value:TLS 1.2|select:0~id:4|value:Auto|select:1~" }, { "tr069_acs_url": "http:\/\/acs.sercomm.com:7547" }, { "url_override_by_dhcp": "1" }, { "tr069_acs_username": "acs" }, { "tr069_acs_password": "XXXXXXXX" }, { "tr069_request_username": "admin" }, { "tr069_request_password": "XXXX" }, { "cpe_port_for_acs_access": "7547" }, { "tr069_inform": "1" }, { "tr069_inform_interval": "3600" }, { "pit_d": "" }, { "pit_t": "" } ],J'ai masqué les deux password qui sont dans le JSON, par contre les URL acs.sercomm.com ne semblent pas publique

J'ai presque cru avoir trouvé quelque chose avec:
settings_access_control.json:
[ { "http_admin_enable_lan": "1" }, { "http_admin_enable_wan": "1" }, { "http_admin_port": "80" }, { "https_admin_enable_lan": "1" }, { "https_admin_enable_wan": "1" }, { "https_admin_port": "443" }, { "ssh_admin_enable_lan": "1" }, { "ssh_admin_enable_wan": "1" }, { "ssh_admin_port": "22" }, { "telnet_admin_enable_lan": "0" }, { "telnet_admin_enable_wan": "" }, { "telnet_admin_port": "" } ],
on peut changer certaines valeur en faisant un POST sur ces mêmes url (ex: curl "-d "telnet_admin_enable_lan=1" avec "_" et "csrf_token" dans l'url, cela change bien la valeur à 1 et la valeur persiste après boot ... mais le service telnet ne démarre pas ... Idem le ssh n'est pas activé pourtant le config est à 1 dans la config par défaut ... il doit s'agir d'un reste non fonctionnel de l'UI d'un autre routeur ... Je n'arrive pas non plus à changer les deux autres clés  "telnet_admin_enable_wan" et "telnet_admin_port" ... (peut-être une vérification supplémentaire dans le cgi sur le fait que l'utilisateur soit logé ou non ...

Enfin on remarque que mini_httpd interdits les transversal path (../) mais en utilisant "%2e%2e%2f" il ne dit rien mais il reste un mapping dans les cgi qui fait qu'on ne peut pas récupérer autre chose que des .json our des .html....

Bon ben encore du boulot ...
 

Si effectivement il manque bien la logique pour lancer un sshd ou telnetd, alors il faut peut-être chercher un system() ou autre à exploiter.

Pour exemple dans les libs chargées par mini_httpd, il y a :
 - /usr/lib/libutility.so : system et popen
    - SYSTEM(const char *format, ...) => system("formatted")
    - STD_SYSTEM => comme SYSTEM
    - FAST_SYSTEM(bool run_in_background, int unused, const char *format) => system("formatted") ou system("formatted &") si run_in_background
    - myPipe(const char *command, char **output) => popen(command, "r")
    - get_numeric_by_cmd(const char *command, const char *prefix_to_search) => myPipe(command, &output)
 - /usr/lib/libslog.so :
    - (pas de référence ?) => app_log_management_init(a, b, name) => "/bin/mkdir /debug/%s" avec name
    - log_log => "/bin/cat %s > %s" sur la rotation des logs, mais les noms /debug/%s/file1 et /debug/%s/file2 viennent de app_log_management_init

Je n'ai pas encore regardé les libs en dépendance des cgi, mais déjà là je vois que :
 - mini_httpd appelle SYSTEM() :
    - sur un login réussi (je ne sais pas quelle requête) => snprintf(buffer, 0x7f, "/bin/mkdir -p %s","/tmp/dt_login_flag")
    - sur login/index.html (GET ?) => snprintf(buffer, 0x7f, "/bin/rm -rf  %s", "/tmp/dt_login_flag")
 - download.cgi appelle system() et SYSTEM()
    - sprintf(buffer, "%s all > %s","/usr/sbin/chip_info_dump","/tmp/debug_ddb")
    - SYSTEM("/bin/touch /tmp/%s", "gpon_ddb.log") ou SYSTEM("/bin/touch /tmp/%s", "gpon_debug.log")
    - SYSTEM("/bin/tar -cvf %s %s", "/tmp/event_monitorlog.tar", "/tmp/monitor_log/")
    - SYSTEM("/bin/cat %s %s %s %s > %s", "/var/voice/voip.conf", "/var/voice/cgi_cli_data", "/var/voice/sip.log", "/var/voice/voice.log", "/tmp/voip_diagnose_info.txt")
    - SYSTEM("/bin/tar -cvf %s %s %s", "/tmp/voip_diagnose_info.tar", "/tmp/*.pcm", "/tmp/voip_diagnose_info.txt")
    - SYSTEM("/bin/rm %s", "/tmp/*.pcm");
 - upload.cgi appelle system(), SYSTEM() :
    - system("echo 3 > /proc/sys/vm/drop_caches")
    - snprintf(buffer, 0x100, "/usr/sbin/fw_ctl -u -d -C -A %s","/var/gpon.img");
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":true}\' &", 1)
 - setup.cgi appelle system(), popen(), SYSTEM() et myPipe()
    - popen("/usr/sbin/ip route list table main") et "/usr/sbin/ip route list table %d"
    - myPipe("/bin/cat /proc/sys/net/nf_conntrack_max", &buffer)
    - myPipe("/bin/cat /proc/sys/net/netfilter/nf_conntrack_count", buffer)
    - snprintf(buffer, 0x32, "\"/usr/sbin/ dhcp6c start %d renew\"", iVar2) ()
    - sur un paramètre "byby", snprintf(buffer, 0x7f, "/bin/rm -rf %s", "/tmp/dt_login_flag")
    - snprintf(buffer, 0x7f, "/bin/mkdir %s", "/tmp/dt_firmware_update_flag")
    - snprintf(buffer, 0x7f, "/bin/rm -rf %s", "/tmp/dt_firmware_update_flag")
    - snprintf(buffer, 0x7f, "/bin/mkdir %s", "/tmp/dt_restart_flag")
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":false}\'", 1);
    - snprintf(buffer, 0x7f,"/bin/mkdir %s", "/tmp/dt_reset_flag")
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":true, \"args\":{\"owner\":%d, \"group\":\"admin\"}}\' &", 2)
    - snprintf(buffer, 0x7f, "/bin/rm -rf %s", "/tmp/dt_firmware_update_flag")
    - snprintf(buffer, 0x7f, "/bin/mkdir %s", "/tmp/gui_update_success_flag")
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":true, \"args\":{\"owner\":%d, \"group\":\"%s\"}}\' &", 2, 2, group); => group semble déterminé à partir de getenv("REMOTE_USER"), ou être NULL (!)
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":true}\' &", 1)
    - snprintf(buffer, 100, "/usr/sbin/umci_ctl -f %s stack get version", "/tmp/tmp_omci_version")
    - SYSTEM("/usr/bin/ubus call smd notify \'{\"notify_id\":%d, \"notify_type\":false}\'", 1)
    - SYSTEM("hal_optical_ctl set_power 0;sleep 3;hal_optical_ctl set_power 1 &")
    - SYSTEM("/usr/sbin/umci_ctl misc save vlan")
    - SYSTEM("/bin/ls -l %s | /bin/grep ^-|/bin/wc -l > %s", "/tmp/monitor_log/", "/tmp/monitor_total_log_num.txt")
    - SYSTEM("/bin/du -sh %s > %s", "/tmp/monitor_log/", "/tmp/monitor_total_log_size.txt")
    - SYSTEM("/bin/tar -cvf %s %s", "/tmp/crash_log.tar", "/tmp/sys_monitor/flash/system_crash_log/")
    - SYSTEM("/bin/tar -cvf %s %s", "/tmp/app_log.tar", files), où files est la concaténation des "/tmp/sys_monitor/flash/application_log/%s ", quand la fonction est appelée avec quelque chose comme "name1|name2|name3"
    - SYSTEM("/bin/rm -rf %s", files), où files est la concaténation des "/tmp/sys_monitor/flash/application_log/%s ", quand la fonction est appelée avec quelque chose comme "name1|name2|name3"

Pour l'instant, seuls les deux derniers pourraient être intéressants a priori, s'il y a moyen de passer des ";command", "&&command", "||command", "$(command)", "&command" dans le paramètre.