[Cr4z33]

già c'è la procedura completa, ma è un po' complessa

Boh se ci fosse un video che registra il tutto farei anche un tentativo.

[dragonx]

@lorenzocanalelc non sei riuscito a trovare un altro da sbloccare e fare gli screenshot ?

[uomoukko]

Sono deciso a trovare altre strade per sbloccare questo modem.
Attualmente ho un Transceiver SFP RJ45 1000Mb, (marca 10Gtek modello ASF-GE-T)
che posso inserire nella porta fibra per fare i test.
Ho anche un altro Transceiver 10/100/1000 (modello ASF-GE2-T)
vengono riconosciuti entrambi, ma l'altro con connessione fissa è più stabile.

Con mia sorpresa ho notato che nelle opzioni del router l'ostacolo più grande, il VPI/VCI
si può disabilitare e l'ho disabilitato togliendomi parecchi casini.
DOMANDA: E' così semplice togliersi i problemi del VPI/VCI oppure facendo così il modem non
esegue il provisioning?

Comunque ho notato che inserire un cavo di rete nella porta LAN/WAN oppure nel
connettore RJ45 collegato alla porta fibra SFP porta a risultati identici
 - sempre se non mi è sfuggito nulla.

Ho collegato un cavo di rete così
PORTA_WAN(DGA4331) --> LAN_PC
oppure questa configurazione:
PORTA_FIBRA(DGA4331)-SFP-RJ45 --> LAN PC

Mi sono costruito un mini server DHCP in C su Windows per vedere i pacchetti che
passano sulla porta 67/68 UDP e osservare la classica procedura che avviene tra

client-dhcp (la scheda di rete del pc sconfigurata) e il programma server-dhcp montato sul pc
client-dhcp (porta del DGA4331 sconfigurata) e il programma server-dhcp montato sul pc

La procedura è questa:
client:DISCOVER - > server:OFFER
client:REQUEST -> server:ACK
Lo scambio di pacchetti e la configurazione avviene sia per la scheda di rete del pc,
sia per il DGA4331 che ricevono ognuno i due IP stabiliti dal mio programma.

Ho avuto un po' di casini perché Windows mi bloccava i pacchetti UDP e dopo essere
impazzito l'ho scoperto e ho disabilitato il firewall di Windows,
ma effettivamente adesso il sistema funziona.
Ora mi chiedo, come avviene il magico trucchetto? viene passato tramite DHCP
un parametro di inizializzazione? con la famigerata opzione  parametro $35/53 ?
Ho notato che ci sono una marea di codici per questo parametro, e anche
alcuni usati esclusivamente dai Windows
ma quelli che vengono effettivamente usati in fase di scambio sono pochi.
tipo il $1-NETMASK, il $3-ROUTER, il $6-DNS, il $33-LEASE, il $36-CLIENT_IP

Ecco, potreste dirmi se sono sulla buona strada o se sto perdendo tempo
perché tralascio qualcosa di fondamentale?

Grazie.

[LuKePicci]

DOMANDA: E' così semplice togliersi i problemi del VPI/VCI oppure facendo così il modem non
esegue il provisioning?

Dipende, per poterlo cambiare hai dovuto mettere il router in modalità configurazione avanzata (aka sblocco ufficiale)? se sì allora ti ha probabilmente disabilitato cwmp.

Non credo che il VLAN ID sia considerabile un ostacolo, basta avere una scheda di rete realtek (anche usb) per farcela comodamente da Windows come se il VLAN ID non ci fosse, oppure un qualsiasi PC con linux, o un altro switch gestito anche integrato in un router.

Comunque ho notato che inserire un cavo di rete nella porta LAN/WAN oppure nel
connettore RJ45 collegato alla porta fibra SFP porta a risultati identici

Certo, sono due porte della stessa interfaccia.

Ora mi chiedo, come avviene il magico trucchetto? viene passato tramite DHCP
un parametro di inizializzazione?

Sì se leggi la specifica di CWMP ti spiega come implementare l'ACS discovery tramite DHCP. In pratica tu mandi via DHCP l'url dell'ACS da contattare e se gli metti un tuo ACS puoi mandargli lo script con i comandi di sblocco.

Tuttavia questa non è la parte "magica" per quanto riguarda il metodo di root per questo 4331 (che funziona su tutti i tch TIm da una certa versione firmware in poi) sta nell'usare come server ACS uno che dispone di certificati TLS validi compresi nella "whitelist" del technicolor. Trovi tutto spiegato molto meglio nelle prime pagine di questo thread.

[uomoukko]

Uhm.. leggendo la documentazione dell'URL ACS del CWMP
fonte: https://www.qacafe.com/resources/acs-discovery/
leggo che il modem richiede l'URL nel parametro 124 e 60
e  gli viene inviata da TIM nel parametro 125 e 43
Ora, questo è un pezzo del log del mio finto dhcp server

Codice: [Seleziona]

<< LISTENING TO PORT 67 >>
PACKET RECEIVED FROM 0.0.0.0:68 [siz=300]
XXXX PACKET START XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [siz=300] 01=BOOT-REQUEST
HW=01, HWLEN=06, HOPS=00 SESSION=C3-15-68-B9
CLI_TIME=00-04 FLAGS=00 00 -----> UNICAST
CLIADDRESS=00.00.00.00 (0.0.0.0)
CLIADD-SRV=00.00.00.00 (0.0.0.0)
SRVADD-SRV=00.00.00.00 (0.0.0.0)
   GATEWAY=00.00.00.00 (0.0.0.0)
 CLIENT-HW= (DGA4331)
SRV-HOSTN=
BOOT FNAM=
----------- PACKET IS DHCP -----------
                   [$35/53=COMMAND] L=01 [01] DISCOVER
         {$91/145=FORCERENEW CAPAB} L=01 [01]
          [$39/57=MAXLEN DHCP MSGs] L=02 [05][dc] 1500 bytes
             [$37/55=PARAM REQUEST] L=11 [01][03][06][0f][21][2a][33][79][f9][d4][0c]
.............Parameter...List...................................
[$01/1=SUBNET MASK]                ,[$03/3=ROUTER(S)]                  ,
[$06/6=DNS(S)]                     ,[$0f/15=DOMAIN NAME]               ,
[$21/33=STATIC ROUT TABLE]         ,[$2a/42=ADDR NTP SERVER(s)]        ,
[$33/51=LEASE]                     ,{$79/121=CLASSLESS STATIC ROUTE}   ,
{$f9/249=M$ CLASSLESS STAT ROUTE}  ,{$d4/212=OPTION 6RD}               ,
[$0c/12=HOSTNAME]
.............Parameter...List...................................
                  [$0c/12=HOSTNAME] L=08 [6d][6f][64][65][6d][74][69][6d] modemtim
              [$ff/255=OPTIONS END] L=00
XXXX PACKET END XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Per la cronaca, io poi invio un DHCP-OFFER con IP,MASK,ROUTER,DNS,
il modem risponde con DHCP-REQUEST con l'IP da me offerto
 e mi richiede gli stessi 11 parametri della DHCP-DISCOVER,
io rispondo con DHCP-ACK inserendo solo IP,MASK,ROUTER,DNS
e a questo punto il led POWER da rosso diventa verde
e mi si accendono in verde anche LINEA e WEB

Come potete vedere dal log del DHCP DISCOVER, il modem non richiede affatto
i parametri 124 e 60, 125 e 43 ma altri parametri.... alcuni strani come 121,212,249

Stavo pensando come esperimento di "forzargli" la stringa ACS
nel pacchetto DHCP-OFFER che gli invio e magari pure nel DHCP-ACK
per vedere se la prende lo stesso, o anche inserirla in un nuovo DHCP-INFORM
ma prima devo capire in quale parametro metterla
E poi mi chiedo che stringa gli metto? una cosa tipo 192.168.1.4/script
(installando un server http nel computer 192.168.1.4) potrebbe andare?

P.S. So bene che il modem potrebbe non richiedere la stringa ACS semplicemente perché
  vede il VPI/VCI disabilitato. Ma non richiederla significa anche non accettarla?
  Oppure potrebbe rifiutare tutte le stringhe offerte diverse da quella richiesta,
  o rifiutare quelle non-HTTPS, però non si sa mai, magari c'è qualche falla nei controlli sul
 protocollo DHCP

@LuKePicci per togliermi dalle scatole il Vpi/Vci vanno bene tutte le schede (usb/non-usb) realtek?
perché stavo pensando di prenderne una per approfondire i miei test.
Sai mica indicarmi un modello di un'ottima scheda realtek con vpi/vci,
magari usb così la metto e tolgo facilmente?
Poi il VPI/VCI si setta da Proprietà della scheda di rete/Avanzate?
perché io sul pc ho una Intel I211 e l'unica proprietà che ci si avvicina è "Priorità pacchetti e VLAN"

[LuKePicci]

Puoi provare a forzarlo mandandogli comunque il messaggio ma se hanno fatto le cose per bene lo ignorerà.

Quando metti il router in modalità sbloccata (anche mantenendo il VLAN ID originale di TIM), lui disabilità la telegestione perchè fuori da rete TIM sarebbe una falla di accesso remoto.

Si le realtek (non solo le USB, e non solo le realtek ma quasi tutte le USB sono realtek e vanno bene) hanno l'opzione per il VLAN ID. Non stiamo parlando di VPI/VCI, quello c'era nelle reti ATM, quindi ADSL. Se la prova la fai dalla porta WAN ethernet SFP o RJ45 devi usare VLAN ID. L'adattatore ethernet di realtek infatti di fa impostare VLAN ID, non VPI/VCI.

Ci tengo a ripeterti che il TIM HUB si rifiuterà di connettersi alll'ACS URL che gli darai a meno che tale ACS non giri su https ed abbia un certificato TLS che lui riconosce come valido. Per questo avevamo suggerito di metterlo su qualche cloud come azure.

[uomoukko]

Prima di tutto vorrei ringraziarvi per l'aiuto che mi state offrendo,
soprattutto grazie alla pazienza di LukePicci.
Io sono un po' lento a capire questi meccanismi e non sono 24h/24 sul problema,
ma ovviamente è mio interesse riuscire a far qualcosa, e comunque
penso che le spiegazioni possano essere utili a chiunque altro si voglia
cimentare nell'impresa

La scheda USB che ho ordinato offre la compatibilità IEEE 802.1Q
che sembrerebbe essere quello che cerco.
Leggendo le specifiche vedo che la nuova scheda ha un hardware che
semplicemente legge i 4 bytes del VLAN TAG e, se corrisponde al numero
di TAG scelto, fa passare il pacchetto, privo dei 4 bytes, altrimenti niente.

[il tag prevede 2 bytes fissi a 0x8100 e altri 2 bytes dei quali 12 bit
contengono il VLAN ID che arriva fino a  2^12=4096, ma 0 e 4095 sono riservate]

Allora avrei due domande:
- che numero di VLAN ID usa TIM?
- capisco che non ci debbano essere falle di sicurezza, però mi sembra strano
amministrativamente parlando, che quando ho il TIM HUB sbloccato,
(che è una cosa permessa), non posso né avere il provisioning
né ricevere aggiornamenti remoti.
cmq adesso come faccio? il reset del modem rimette le cose come stavano, no?

e adesso curiosità mie relative al sito TCH:
- nel sito vedo che è stato usato il coffee script: c'è un motivo preciso
di questa scelta, visto che - per questo tipo di applicazione - io trovo
il linguaggio C puro molto più semplice?
- come mai il programma TCH richiede IP statico 58.162.0.1 per la scheda di rete PC
e assegna l'IP soltanto al modem, quando si sarebbe potuto usare
lo stesso mini-server DHCP contenuto nel TCH per inizializzare
sia l'indirizzo della scheda di rete PC che quello della porta
WAN del modem, lasciando la scheda PC con IP dinamico di default
(come faccio io nel mio programma) e quindi semplificando la procedura?

[LuKePicci]

Esatto, in pratica tu imposti il VID (VLAN ID) che usa TIM nella scheda USB e ti ritrovi sul PC col traffico pulito senza tag. Il VID lo trovi nelle settings del firmware, i firmware spacchettati li trovi su github. Mi pare che lo avevamo comunque detto qui nei primi post.

Non è semplice trasformare un dispositivo/firmware progettato per vivere al sicuro su una sola rete di un determinato ISP in qualcosa che funzioni in sicurezza al di fuori di essa. Dato che in principio l'ACS di TIM non era nemmeno raggiungibile al di fuori della sua rete l'idea di disabilitarlo viene comoda, anche perchè nessun altro ACS dispone degli aggiornamenti firmware compatibili per questo dispositivo. Il reset riporta il dispositivo alle impostazioni di default, quindi con CWMP attivo e configurazione non sbloccata, quindi sì, va fatto.

L'IP del PC può pure essere dinamico ma allora devi dinamicizzare l'IP che proponi come ACS e webserver al router. Per altri dettagli su tch-exploit chiedi direttamente a BoLaMN, che ha scelto coffee semplicemente perchè gli veniva comodo. E' comunque inutilizzabile con questo dispositivo (a parte le funzionalità extra come TFTP), qui ti serve solo un server DHCP.

[lorenzocanalelc]

Nuovo Firmware Beta AGTHF_1.1.2_001_CLOSED

[uomoukko]

Allora Oggi mi è arrivata la scheda Realtek usb e ho subito provato il VLAN ID
che poi era banalmente 835 come scritto sulla pagina "Banda Larga" del modem.
Ho abilitato la VLAN nel modem (l'avevo disabilitata),
poi ho configurato la scheda di rete pure con 835,
e ho verificato che mi assegna correttamente i due IP (al modem e al router).
Esattamente come faceva prima quando avevo il VLAN disabilitato e una scheda di rete normale.

L'unica cosa che vedo dopo l'assegnazione dell'ip (usando wireshark, filtro ip.addr==dga4331)
è una serie di query udp al dns(53) per sapere dove stanno i ntp server (forse per l'orologio).

Poi ho resettato il modem per portarmi nella condizione di impostazioni di fabbrica e..
SORPRESA! il DHCP non funziona più e sembra che ci sia un pacchetto PADI in broadcast
che se non erro è un PPPoE Discovery.. infatti collegandomi direttamente al modem
per verificare tramite WIFI vedo che è in atto una connessione PPP.

Come mai il programma per rootare, il TCH non sembra effettuare una connessione
PPP ma un semplice dhcp diretto? Ma allora il programma TCH funziona col modem
in config estesa (sbloccato) e ppp disabilitato?
Sono profondamente demoralizzato col ppp da gestire mi si crea un ulteriore
livello di complessità sigh
Ci aiuta il nuovo firmware?

[LuKePicci]

Io sono un po' demoralizzato perchè non sembra che tu abbia seguito il mio consiglio di leggere le prime pagine. Il VLAN ID che hai scelto è ovviamente sbagliato, devi usare il VLAN ID che TIM usa sulle linee FWA che sono in DHCP, non PPPoE. NTP serve perchè senza orologio non può validare la scadenza dei certificati TLS (che comunque non viene presa in considerazione dal client CWMP).

[uomoukko]

Si... verissimo, non ho letto le prime pagine, ma ora ho capito, la VLAN è la 83,
i parametri nella DHCP option 43 sono http://58.162.0.1/52162/ e Telstra

stranamente mi veniva questo nel log del modem:

Codice: [Seleziona]

Wed Jul 29 00:28:00 2020 user.err lua: [processvendorinfo] Not allowed to transition from HTTPS to HTTP
Wed Jul 29 00:28:00 2020 user.err lua: [processvendorinfo] Failed to set acs url from dhcp option 43
poi ho resettato impostazioni di fabbrica, e, senza cambiare niente nel programma dhcp server,
e pur lasciando http e non https nella opzione 43, il modem mi si connette
ad un programmino httpd installato sul pc su porta 52162 che ho preparato per testare, e guarda cosa scrive:

Codice: [Seleziona]

2021/10/25 02:20:53 Connect 58.162.0.14:51446 -> 58.162.0.1:52162
recv:[0x16][0x03][0x01]
send:test<br>
DISCONNECT

2021/10/25 02:21:31 Connect 58.162.0.14:44777 -> 58.162.0.1:52162
recv:[0x16][0x03][0x01]
send:test<br>
DISCONNECT
quindi la connessione la fa lo stesso ma in https e guarda guarda i tre bytes sono l'handshake del TLS 1.0
cfr https://wand.net.nz/trac/libprotoident/wiki/SSL

Ora: è possibile forzare in qualche modo la connessione senza crittografia? o anche abilitarla
e sperare che non controlli i certificati? non possiamo abbassare la sicurezza facendo partire da https,
ma poi facendo degradare in plain text visto che in definitiva siamo noi a servire la richiesta e al modem
basta che la connessione sia partita da un https?
sono solo idee magari senza senso...

[LuKePicci]

Le idee hanno senso ma purtroppo in questo firmware c'è applicata una settings che appunto ti forza ad usare HTTPS con certificati validi.

[uomoukko]

A questo punto prima di arrendermi voglio fare altri esperimenti tipo implementare il TLS 1.0 nel mio
mini-server HTTPD per vedere se riesco a degradare la connessione che parte in HTTPS.
Ad una veloce occhiata a quel link sul SSL/TLS che ho messo ieri si legge che se una delle due parti
manda la stringa "<!DO" allora il controllo SSL va a buon fine e la connessione continua in chiaro boh.
Sarà vero?

Ad ogni modo ti chiedo: mi daresti una stringa da passare al modem per testare se ho avuto successo?
una che mi confermi che il modem ha eseguito il comando, tipo per esempio far accendere il led voce o wps
Speriamo bene

Aggiornamento di oggi. ho rifatto il server http includendo la crittografia SSL/TLS
e effettivamente il messaggio che mi da è questo:

Codice: [Seleziona]

2021/10/26 21:18:29    CONNECT 58.162.0.14:34634 -> 58.162.0.1:52162
139660896765760:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1543:SSL alert number 48
2021/10/26 21:18:29 DISCONNECT
e questo anche se ho usato la configurazione SSL_CTX_set_verify(ctx,SSL_VERIFY_NONE,NULL);
che dovrebbe specificare di non verificare il certificato...almeno spero che sia così.
ma ora senti la mia idea: visto che quello che comanda è il server, cioè noi non potremmo usare
una versione di SSL modificata che restituisce al client l'ok invece dell'errore certificate unknown?
o - come temo - forse è il client-modem che verifica il nostro certificato e manda l'errore al server(noi)
che però potrebbe fregarsene dell'errore.. boh sono ad un punto morto mi sa

[LuKePicci]

Trattasi di autenticazione TLS del server, quindi è il client che comanda. Il client in modo di acconsentire alla connessione solo se il server dimostra di essere colui che il client si aspetta, ovvero colui che raggiunto ad un tale nome di dominio (a) presenta un certificato riportante al suo interno il medesimo dominio, (b) ed è anche in grado di provare crittograficamente di essere in possesso della chiave privata associata alla chiave pubblica certificata nel certificato, (c) la cui autorità emittente CA è già inclusa con certificato tra quelle conosciute al client. (d) che ne verifica crittograficamente la paternità.

In altre parole devi impostare sul tuo server TLS un certificato+chiave privata validi e riconducibili ad una delle CA installate nel technicolor. Di norma troveresti installata solo una CA fatta apposta dall'operatore per il CWMP, ma qui ci sono installate tutte le più comuni.