[Thread ufficiale] D-Link DVA-5592 (A1) - Firmware modding

[bancodeipugni]

ci va in idle come i netgear ? da spento tener premuto il reset e avviare tenendolo sempre premuto ? dovrebbero lampeggiare 2 led

[dlp]

Con questo firmware DVA-5592_A1_WI_20180823 il confedit nom sembra più in grado di abilitare la possibilità di fare il downgrade del firmware. Vi risulta?

[pimander]

Non ho ancora avuto tempo di analizzare bene il firmware, per cui è da prendere con le molle, ma a occhio hanno aggiornato quasi tutto, kernel, busybox e gli altri eseguibili. Anche la parte dell'upgrade è stata modificata, gestendo anche un "secure version" o qualcosa del genere, poi hanno tolto la cartella cmws dalla web gui, il che mi fa pensare che ci vogliono far credere che il tr069 sia disabilitato mentre non lo è.
Conoscendo la tradizione non mi stupirei se stavolta avessero fatto in modo che non sia più possibile tornare a versioni precedenti. Ho letto qualcuno che ha detto che adbtools funziona e che le pagine web sono sbloccate, ma bisognerebbe anche controllare se la password del voip è ancora visibile, nonché se il trucco trovato da palmerpalm funziona ancora

[dlp]

Tutti i menu della Gui che erano sbloccati prima lo sono anche con il nuovo firmware però alcuni non fanno ciò che devono. Ad esempio il failover è in sola lettura anche se viene impostato read/write quindi non è disabilitabile. La sensazione è che ad ogni aggiornamento si concentrino più sul togliere che sul risolvere. Il Nat loopback non funziona ancora ed è presente nei router di fascia infima da oltre 10 anni. Mah staremo a vedere.

[Bovirus]

@dlp

Ti confermo che adbtools2, usando il file impostazioni salvato con il firmware di agosto 2018, non è in grado di abilitare il downgrade del firmware.

Un'altro bug minore di adbtoosl2 è che salvando il file (xml o bin) non imposta l'esetensione del file e bisogna ricordarsi di aggiungerla manualmente.

[pimander]

Originariamente inviato da dlp

La sensazione è che ad ogni aggiornamento si concentrino più sul togliere che sul risolvere.

Direi che è proprio così

A questo punto bisognerebbe ancora verificare se hanno tappato la falla scoperta da palmerpalm...

[bancodeipugni]

aggiornato il kernel ?
questa sarebbe una novità

sarebbe il primo router broadcom di questi col 35b che lascia il 3.4.11

che versione c'e' adesso ?

[pimander]

Non è detto che sia cambiata la versione, solo i vari moduli sono diversi come dimensione e data.

[palmerpalm]

Originariamente inviato da pimander

Non è detto che sia cambiata la versione, solo i vari moduli sono diversi come dimensione e data.

Non ho ancora analizzato, né provato il nuovo firmware DVA-5592_A1_WI_20180823 sul router, ma, estraendo il file system con binwalk, "decomprimendo" il kernel che si trova nel file vmlinux.lz e guardando le stringhe che ci sono dentro (con il comando 'strings') si vede la seguente stringa identificativa:

Linux version 3.4.11-rt19 (l.fornalczyk@quelo) (gcc version 4.5.4 20120306 (prerelease) (Linaro GCC 4.5-2012.03) ) #1 SMP PREEMPT Thu Aug 23 11:05:53 CEST 2018

Il che ci dice che la versione del kernel è rimasta la stessa, magari il kernel lo hanno recompilato con qualche cambio nella configurazione.

P.S. se a qualcuno interessa, il kernel l'ho decompresso con il seguente script:

#!/bin/bash                                                                                                                                                                                                
# from ADB vmlinux.lz to his components                                                                                                                                                                    
# usage: extract-vmlinux.lz.sh /path/to/vmlinux.lz                                                                                                                                                         
#                                                                                                                                                                                                          
KER=$1
dd if=$KER bs=1 skip=0  count=4 of=1-loadoffset.bin
dd if=$KER bs=1 skip=4  count=4 of=2-entrypoint.bin
dd if=$KER bs=1 skip=8  count=4 of=3-compressedsize.bin
dd if=$KER bs=1 skip=12 count=8 of=4-magic.bin

v=`xxd -p 3-compressedsize.bin`
HEXSIZE=`echo ${v:6:2}${v:4:2}${v:2:2}${v:0:2}`
LZSIZE=`echo $((0x${HEXSIZE}))`

dd if=$KER bs=1 skip=20 count=$LZSIZE of=5-compressed.bin
cat 5-compressed.bin | lzcat > 6-uncompressed.bin

[palmerpalm]

Originariamente inviato da Bovirus

@dlp

Ti confermo che adbtools2, usando il file impostazioni salvato con il firmware di agosto 2018, non è in grado di abilitare il downgrade del firmware.

Un'altro bug minore di adbtoosl2 è che salvando il file (xml o bin) non imposta l'esetensione del file e bisogna ricordarsi di aggiungerla manualmente.

Ho capito perche' si verifica, se pero' si carica un file di configurazione salvato con la vecchia versione, in cui il downgrade era abilitato, dovrebbe ancora essere possibile fare il downgrade.

Comunque con la vecchia versione, quando il downgrade era disabilitato, sul file di configurazione del CPE decriptato c'erano le seguenti righe, nella sezione "DeviceInfo":

                <X_ADB_TR098Ready>true</X_ADB_TR098Ready>
                <X_DLINK_fw_upgr_permitted>false</X_DLINK_fw_upgr_permitted>
                <X_DLINK_customer_ID>WI</X_DLINK_customer_ID>
                <X_DLINK_BsdGuiVisible>true</X_DLINK_BsdGuiVisible>
                <X_DLINK_AllowFirmwareDowngrade>false</X_DLINK_AllowFirmwareDowngrade>
		<X_ADB_PowerManagement>

il programma confedit per abilitare il firmware upgrade/downgrade modificava il relativo "false" in "true". Con il nuovo firmware, salvando il file di configurazione e decifrandolo in modo analogo invece ci sono le seguenti righe:

                <X_ADB_TR098Ready>true</X_ADB_TR098Ready>
                <X_DLINK_customer_ID>WI</X_DLINK_customer_ID>
                <X_DLINK_BsdGuiVisible>true</X_DLINK_BsdGuiVisible>
                <X_ADB_PowerManagement>

Ossia le opzioni di X_DLINK_fw_upgr_permitted e X_DLINK_AllowFirmwareDowngrade mancano completamente e l'attuale versione di confedit non le modifica. Se pero' si aggiungono (e l'ho provato modificando a mano tale file) il downgrade risulta abilitato.

Nei prossimi giorni conto di implementare questa modifica su confedit.

[bancodeipugni]

allora per stavolta siamo salvi

si' il kernel evidentemente lo ha buttato fuori la broadcom una volta sola poi hanno girato intorno le varie modifiche i vari brand...

è un kernel anche abbastanza datato siamo sui livelli del 2011

io ho ancora il 2017 se ci sono novità interessanti di sviluppo potrei anche aggiornare

[palmerpalm]

Confermo che anche con la nuova versione del firmware (DVA-5592_A1_WI_20180823.sig) si puo' entrare in "factory mode" e funziona il mio hack per diventare root. Non funziona il caricamento del firmware non ufficiale, perche' lo vede come un downgrade, ma copiando /usr/sbin/custom-upgrade-check.sh in /tmp, modificandolo e poi usando il "mount --bind" si riesce lo stesso a caricare il firmware non ufficiale.

Nei prossimi giorni modifichero' l'hack-script per fare la cosa in automatico e modifichero' il "firmware modification kit" per farlo funzionare con l'ultima versione del firmware.

[Wolf_adsl]

Ciao, con il tool si riesce ad abilitare il pannello del TR69 per abilitare/disabilitare la gestione remota del provider (firmware 2018_04)?

Ciao W_A

[dlp]

Originariamente inviato da Wolf_adsl

Ciao, con il tool si riesce ad abilitare il pannello del TR69 per abilitare/disabilitare la gestione remota del provider (firmware 2018_04)?

Ciao W_A

Si il pannello si attiva. Una volta attivato lo trovi a questo indirizzo: http://192.168.1.1/ui/dboard/setting...ngs/management

[palmerpalm]

Originariamente inviato da Bovirus

@dlp

Ti confermo che adbtools2, usando il file impostazioni salvato con il firmware di agosto 2018, non è in grado di abilitare il downgrade del firmware.

Un'altro bug minore di adbtoosl2 è che salvando il file (xml o bin) non imposta l'esetensione del file e bisogna ricordarsi di aggiungerla manualmente.

Ho aggiornato adbtools2 in modo da abilitare il downgrade/upgrade del firmware anche con l'ultimo firmware DVA-5592_A1_WI_20180823.sig.

L'altro bug minore non l'ho corretto perche' si verifica con il .exe compilato, ma non mi si verifica con lo script python eseguito sotto Linux, dove normalmente "opero".

Ho anche aggiornato "hack-script.sh" per permettere il caricamento di firmware non ufficiale e non firmato, anche quando tale firmware dovesse essere di una versione inferiore rispetto all'ultimo firmware caricato del 23 agosto 2018.

[Totix92]

Originariamente inviato da bancodeipugni

sarebbe il primo router broadcom di questi col 35b che lascia il 3.4.11

No, il Fritz!Box 7581 (Broadcom) già con la prima beta del firmware 6.98 è passato al kernel 4.1.38
e penso sia l'unico modem/router con il Broadcom ad avere un kernel più recente del 3.4.11

[dlp]

Originariamente inviato da palmerpalm

Ho aggiornato adbtools2 in modo da abilitare il downgrade/upgrade del firmware anche con l'ultimo firmware DVA-5592_A1_WI_20180823.sig.

L'altro bug minore non l'ho corretto perche' si verifica con il .exe compilato, ma non mi si verifica con lo script python eseguito sotto Linux, dove normalmente "opero".

Ho anche aggiornato "hack-script.sh" per permettere il caricamento di firmware non ufficiale e non firmato, anche quando tale firmware dovesse essere di una versione inferiore rispetto all'ultimo firmware caricato del 23 agosto 2018.

Grazie. Ne ho approfittato per tornare a gambe levate al firmware DVA-5592_A1_WI_20180405

[bancodeipugni]

Originariamente inviato da Totix92

No, il Fritz!Box 7581 (Broadcom) già con la prima beta del firmware 6.98 è passato al kernel 4.1.38
e penso sia l'unico modem/router con il Broadcom ad avere un kernel più recente del 3.4.11

è anche ora

bisogna vedere se ha la stessa board e monta processore analogo (dubito)

poi non ha l'scp il che lo strozza già in partenza

[Totix92]

Originariamente inviato da bancodeipugni

è anche ora

bisogna vedere se ha la stessa board e monta processore analogo (dubito)

poi non ha l'scp il che lo strozza già in partenza

stesso SoC
BCM63136V
variante del BCM63138 con supporto al voip.
Ovviamente il resto dell'hardware è diverso, ma è pur sempre lo stesso Broadcom medesimo di altri apparati con supporto al 35b
Il D-Link tra l'altro ha anche tutti i moduli Broadcom persino più vecchi di quelli presenti nello Zyxel VMG-8823, driver xdsl compreso.
Volendo potrebbero aggiornali senza problemi, kernel compreso, ma dubito si sbatteranno per farlo continueranno sicuramente sempre sulla base attuale, gli unici che aggiornano frequentemente il tutto sono Asus con il DSL-AC88U e AVM con il 7581, ma anche Zyxel con il firmware non brandizzato del VMG-8823 ( quest'ultima almeno la parte driver xdsl, il resto no. )

[palmerpalm]

Qualcuno nel forum aveva chiesto come ero arrivato a trovare la vulnerabilità sul router che ha permesso di diventare root, mi ero ripromesso di documentarlo ed ho iniziato a farlo. La documentazione è ancora largamente incompleta ma è su GitHub dove ho creato un altro repository: [buildroot-armv7](https://github.com/digiampietro/buildroot-armv7) che, al momento, contiene:

• Tutto il necessario (scripts, file di configurazione ecc.) per creare, su Linux, l'ambiente di emulazione dove far girare gli eseguibili del router.
  
• L'ambiente utilizza una vecchia versione del 2014 di buildroot (necessario per avere la stessa versione di uClibc, di libgcrypt e altre librerie usate nel router).
  
• Tale versione di buildroot non la si riesce a far girare in una versione recente di Ubuntu (provato ma da molteplici errori di compilazione che non spariscono neanche provando versioni più vecchie di gcc), pertanto è stato necessario ricorrere a Docker per creare una immagine basata su Debian Wheezy, che è una distribuzione uscita nel 2013.
  
• In Buildroot viene utilizzato un "external tree", tramite la variabile BR2_EXTERNAL.
  
• Nell' "external tree" sono stati inclusi i file di configurazione (di "defconfig") sia di Buildroot, del kernel che di uClibc ed i file di patch del kernel per aggiungere, principalmente ma non solo, il supporto al file system JFFS2 con la compressione LZMA che non fa parte del kernel standard.
  
• Il root file system, generato da Buildroot, viene poi emulato in Qemu. La macchina emulata, oltre ad avere un processo ARM v7 Cortex-A9, ha anche uClibc, libgcrypt ed altre librerie della stessa versione, o versioni compatibili, rispetto a quelli presenti nel router. E' incluso anche il modulo "nandsim" del kernel per emulare una NAND flash memory dove caricare l'immagine del file system JFFS2 (non ancora documentato sul repository come fare, ma lo farò a breve)
  
• Tutte gli eseguibili e le librerie del root file system della macchina virtuale sono stati compilati con tutte le informazioni di debugging in modo che, almeno le chiamate alle librerie, possano essere facilmente comprese quando si utilizza gdb (Gnu Debugger) per fare del "reverse engineering" sugli eseguibili del router.
  
• Nel root file system della macchina emulata, nelle cartelle /dva-root e /dva-firm, sono stati inclusi i files del router ed i file del firmware e le immagini JFFS2 del root e boot file system del router.
  
• A titolo di esempio è illustrato l'utilizzo di gdb per fare il "reverse engineering" dell'eseguibile sig_verify che verifica la firma digitale del firmware in fase di caricamento. Questo esempio, sebbene non utile al fine di diventare "root" sul router, è comunque interessante perchè si riesce a verificare esattamente cosa fa l'eseguibile e persino a ricostruire il certificato con la chiave pubblica per fare la stessa verifica con OpenSSL.
  

Questa configurazione utilizzata ha richiesto una notevolissima quantità di tempo per essere messa a punto, a causa dei numerosi tentativi, problemi incontrati e correzioni effettuate. Inizialmente, ad esempio, avevo provato con versioni più recenti di Buildroot, ma i binari del router davano errori perchè non trovavano le librerie che si aspettavano; ho allora provato a prendere versioni più vecchie di Buildroot, ma queste non mi si compilavano sulla mia versione di Ubuntu e, dopo molteplici tentativi, ho capito che avrei dovuto usare Docker con una immagine basata su una versione più vecchia di Linux. Poi, dopo aver abilitato la compilazione con i simboli per il debugging, questa impostazione veniva ignorata da uClibc. Ho allora configurato, con "menuconfig" uClibc per utilizzare i simboli di debugging, ma questa impostazione dava degli errori irrisolvibili (almeno da me) in fase di compilazione, ho allora dovuto usare dei workaround che descriverò in seguito sul repository. Una volta compilato uClibc con i simboli per il debugging, il break sulle funzioni di libreria "open" e "read" sembravano essere ignorate, anche qui ho poi trovato un workaround.