• Non sono ammesse registrazioni con indirizzi email temporanei usa e getta

Sorgenti Firmware decoder basati su CT216T

F

ffxx68

Digital-Forum Junior
Registrato
19 Giugno 2009
Messaggi
51
Per chi si fosse perso un mio vecchio messaggio, sono "disponibili" i sorgenti (tutti in C) alla base di molti firmware basati sul Cheertek CT216T. Si possono trovare su:

http://en.pudn.com/

cercando "0812.rar" (forse una data di revisione? dicembre 2008). Bisogna registrarsi su pudn e caricare almeno 5 file di carattere tecnico, o altri sorgenti, prima di poterli scaricare.

Ho anche scritto la procedura completa per generare il firmware a partire dai sorgenti. Per chi fosse interessato, la trova in "README", su:

http://sites.google.com/site/ffxx78site/files

Da notare nei sorgenti il file "cheer_t_movie.cfg", che contiene la configurazione del FW che viene generato. Per esempio, ci sono i vari tuner possibili:

#NIM_TYPE:= ct221t_DTT2004
#NIM_TYPE:= ct221t_lg352d
#NIM_TYPE:= ct221t_mxl5005
#NIM_TYPE:= ct221t_TD1611
#NIM_TYPE:= ct221t_LH17AS
#NIM_TYPE:= ct221t_lg101d
#NIM_TYPE:= ct221t_lgxx1d
# This is for Majesting DEC543
NIM_TYPE:= ct221t_lg352dN
#NIMMODEL := ct221t_TD1611
#NIMMODEL := ct221t_lg352d
# This is for Majesting DEC543
NIMMODEL := ct221t_lg352dN

O il telecomando:

IR_TYPE = HW_IR_NEC

Oppure, il flag DBTOOL_ENABLE. Se è disabilitato (DBTOOL_ENABLE:=0) vengono rimosse delle parti di codice dalla compilazione e viene generato un FW "wice.ssu", che ha un'intestazione come quella di EnergySystem T5250, o di United DVB9084:

# hexdump -C exec/cheer_t/wice.ssu | head
00000000 63 68 65 65 72 74 65 6b 00 00 00 00 00 00 00 00 |cheertek........|
00000010 32 31 36 00 00 00 00 00 63 61 6c 6c 69 73 74 6f |216.....callisto|
00000020 00 00 00 00 00 00 00 00 30 2e 30 31 61 00 00 00 |........0.01a...|

Se DBTOOL_ENABLE:=1 viene invece generato un FW "ct216-loader.app1.ssu", con un'intestazione come quelli caricati su http://www.megaupload.com/?d=4K41N37K (dal thread "Quale firmware per questo DVB-T scart?"):

# hexdump -C exec/cheer_t/ct216-loader.app1.ssu | head
00000000 43 68 65 65 72 74 65 6b 00 00 00 00 00 00 00 00 |Cheertek........|
00000010 43 54 32 31 36 54 00 00 44 52 32 31 36 54 5f 5a |CT216T..DR216T_Z|
00000020 5f 56 33 30 00 00 00 00 30 31 2e 30 30 2f 30 38 |_V30....01.00/08|

Sebbene non sia riuscito a generare un FW funzionante con il mio Majestic DEC543 (telecomando e pannello frontale bloccati), i sorgenti possono essere un'utile riferimento per capire come "funzionano" 'sti apparecchietti.

ATTENZIONE - Non vorrei scoraggiare gli "esperimenti", ma se generate un FW con questi sorgenti c'è il rischio concreto di riuscire a caricarli ma poi di ritirovarvi un box da buttare, dato che non si riesce a ricaricare l'originale. A me è successo, ovviamente :)
 
Ultima modifica:
Mi accodo immediatamente alla discussione per segnalare agli eventuali interessati (come ho già fatto con ffxx68) che sono disponibile per tutti i test che si rendessero necessari, in quanto ho già reso removibile la flash del mio decoder scart e mi sono costruito un semplice programmatore per porta parallela con il quale posso sempre ripristinare il firmware originale usando il pc.
Tengo anche a precisare che già adesso dalla compilazione si ottiene un firmware parzialmente funzionante (almeno sul mio dispositivo), nel senso che il decoder risponde parzialmente al telecomando (i tasti non coincidono e ne mancano alcuni, ma affiancando un universale ci si può arrangiare) e soprattutto è perfettamente in grado di riprodurre file multimediali (divx compresi).
Se qualcuno è intenzionato a darci una mano si potrebbe pensare addirittura di aggiungere nuove funzionalità come ulteriori codec o il supporto al filesystem NTFS (dopo aver ovviamente sistemato tutti i bachi che notoriamente affliggono gli apparecchi basati su questo chipset).

Ciao.
 
Mi viene in mente una possibile strategia di "reverse engineering" da condividere. Con il tool di compressione/decompressione che è compreso nei sorgenti (si chiama "zip2006.exe") sarebbe possibile decomprimere i FW esistenti in giro e confrontarli con i moduli che vengono linkati in quello generato. Da qui si potrebbe forse fare una sorta di "collage", per linkare i moduli di cui non sono disponibili i sorgenti originali, per esempio per un telecomando o un tuner specificio. Non so se sono stato chiaro abbastanza.
Lo so... è un lavorone, ma mi sembra fattibile, in linea di principio almeno...
Andrebbe studiato a fondo il makefile, che descrive la procedura di "impacchettamento".
 
Nella speranza che qualcuno mi segua in questa "impresa", condivido quanto ho trovato fin'ora.

Struttura del file .ssu:

1) Header
2) Stamps, RO, ecc.
3) Zipped BIN
4) FF FF FF ... FF
5) CRC

Per estrarre il binario vanno eseguiti questi passi:

1) cercare l'inizio del file compresso, segnato dalla stringa "9ZZÚZ" (compresa)
2) cercare la fine del file compresso, prima della lunga serie di FF FF FF che riempiono il file fino alla fine
3) estrearre solo la parte compresa tra "9ZZÚZ" e l'ultimo byte prima degli FF di riempimento in un nuovo file (es. temp.gz)
4) eseguire "utility/zip2006.exe d temp.gz temp.bin", per generare il file binario originario

Il file "binario" così ottenuto corrisponde al file ct216-cheer_t.dram.bin, generato dal passo:

> sparc-rtems-objcopy -O binary [...]/0812/exec/cheer_t/ct216-cheer_t.dram.elf [...]/0812/exec/cheer_t/ct216-cheer_t.dram.bin

In termini pratici, il .bin non è altro che una versione "tagliata" del .elf, da cui vengono rimossi intestazione e coda. Dei FW reali abbiamo perciò modo di ricreare solo il .bin, dato che le informazioni contentute nel .elf si perdono nel passo di objcopy.

Il file ELF di input (almeno di quelli generati a partire dai sorgenti - assumo che siano uguali ai FW reali) ha una struttura del tipo:

> sparc-rtems-objdump -h ct216-cheer_t.dram.elf

ct216-cheer_t.dram.elf: file format elf32-sparc

Sections:
Idx Name Size VMA LMA File off Algn
0 .rom_vectors 000013b0 40400000 40400000 00010000 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text 0012dcf0 404013b0 404013b0 000113b0 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .fini 00000000 4052f0a0 4052f0a0 001b8ae8 2**0
CONTENTS
3 .rodata 00071f0c 4052f0a0 4052f0a0 0013f0a0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .rodata1 00000000 405a0fac 405a0fac 001b8ae8 2**0
CONTENTS
5 .fixup 00000000 405a0fac 405a0fac 001b8ae8 2**0
CONTENTS
6 .eh_frame 00001070 405a0fac 405a0fac 001b0fac 2**2
CONTENTS, ALLOC, LOAD, DATA
7 .gcc_except_table 0000058c 405a201c 405a201c 001b201c 2**2
CONTENTS, ALLOC, LOAD, DATA
8 .data 00006540 405a25a8 405a25a8 001b25a8 2**3
CONTENTS, ALLOC, LOAD, DATA
9 .bss 0007efb0 405a8ae8 405a8ae8 001b8ae8 2**4
ALLOC
10 .stab 0007e984 00000000 00000000 001b8ae8 2**2
CONTENTS, READONLY, DEBUGGING
11 .stabstr 0004d48b 00000000 00000000 0023746c 2**0
CONTENTS, READONLY, DEBUGGING

Nel file BIN non sono comprese le sezioni 10 e 11 (usate per il debug).

Nei FW reali mi aspetto che i valori di size e offset potrebbero variare.
 
Complimenti per l'analisi!
Avevo già notato queste sequenze ripetute che iniziavano con 9ZZÚZ, ma non le avevo associate allo zip2006.
Il mio firmware contiene 26 di questi blocchi di cui il n.1 è quello principale, i blocchi dal 2 al 6 non so cosa siano (alcuni contengo riferimenti all'audio), i blocchi dal 7 al 20 compreso contengono i messaggi OSD nelle varie lingue (un blocco per lingua), il blocco 21 non so di nuovo cosa sia e i blocchi dal 22 al 26 sembrano contenere immagini o grafica in quanto presentano gruppi di caratteri tutti uguali disposti in modo ordinato.
Il file che ho analizzato io, però non finisce qui: subito dopo l'ultimo blocco c'è una sequenza che inizia con la frase "MPEG-2 Test Sequence, 30 frames/sec." e prosegue con informazioni che sembrano in effetti un video mpeg.
Speravo vivamente che anche il modulo relativo al tuner fosse in un blocco indipendente invece a quanto pare così non è.
Scompattando il blocco principale si possono leggere alcune informazioni interessanti all'interno: ho così scoperto che il mio firmware è stato generato da sorgenti che contengono alcuni modelli di tuner in più, tra cui uno denominato CDT9xTxxx che è probabilmente quello utilizzato nel mio decoder.
Mi riprometto di analizzare ulteriormente il blocco 1 per cercare di ottenere altre informazioni.

Per il momento grazie dei preziosi suggerimenti.

Ciao.
 
ciao - hai già provato a prendere tutto il blocco, dal primo "9ZZÚZ" alla fine del file (esclusi gli FF di riempimento), e fare l'unzip?
 
Ultima modifica:
ffxx68 ha scritto:
ciao - hai già provato a prendere tutto il blocco, dal primo "9ZZÚZ" alla fine del file (esclusi gli FF di riempimento), e fare l'unzip?
Clicca per espandere...
Ci ho provato adesso e come mi aspettavo ha scompattato solo il primo blocco (secondo me dopo quei caratteri c'è qualche byte che contiene informazioni sulla lunghezza dei dati da scompattare).

Ciao.
 
mhh... devo ricontrollare nel file generato dai sorgenti se ci sono più "blocchi".
Il makefile aiuta a capire come è composot il file finale, ma ci sono dei passi finali che "Impacchettano" il FW mediante degli eseguibili proprietari Cheertek, che non si capisce bene cosa facciano... Andrebbe eseguito manualmente ogni passo e visto cosa fa sui file.
 
Per chi fosse interessato (a questo punto sembra che purtroppo nessuno voglia collaborare :crybaby2: ): ho scoperto che i sorgenti si trovano anche su hackchina.com (non ce li ho messi io), dove è possibile scaricarli senza alcuna registrazione o altre formalità.

@ffxx68 : mi puoi passare il tuo makefile? Se metto DBTOOL_ENABLE:=0 nel cheer_t_movie.cfg , quando vado ad effettuare il MAKE IMAGE mi viene fuori un errore nella chiamata a updheader.exe (la cosa strana è che la stessa riga di comando digitata manualmente funziona), anche se poi il file wice.ssu viene generato ugualmente.

Ciao.
 
Silix ha scritto:
Per chi fosse interessato (a questo punto sembra che purtroppo nessuno voglia collaborare :crybaby2: ): ho scoperto che i sorgenti si trovano anche su hackchina.com (non ce li ho messi io), dove è possibile scaricarli senza alcuna registrazione o altre formalità.
Ciao.
Clicca per espandere...

E come?
Mi rimbalza da uno sponsor all'altro ma non riesco a scaricare nulla. :mad:
 
Ricky651 ha scritto:
E come?
Mi rimbalza da uno sponsor all'altro ma non riesco a scaricare nulla. :mad:
Clicca per espandere...

In effetti i link ai download sono poco evidenti, mentre quelli agli sponsor cercano di trarre in inganno in modo da spingere il visitatore a cliccarli.
Comunque l'indirizzo esatto è questo: http://www.hackchina.com/dlpre.php?lang=en&id=33990
Devi aspettare una ventina di secondi (il conto alla rovescia è in caratteri abbastanza piccoli sotto il primo banner grande in alto al centro), dopodichè ti si aprirà la solita immagine di verifica contro i download automatizzati: inserisci i 6 caratteri in essa visualizzati nella casella sottostante e premi il bottone "Download now!".
Posso chiederti se sei interessato a darci una mano o la tua è semplice curiosità?

Ciao.
 
Silix ha scritto:
@ffxx68 : mi puoi passare il tuo makefile? Se metto DBTOOL_ENABLE:=0 nel cheer_t_movie.cfg , quando vado ad effettuare il MAKE IMAGE mi viene fuori un errore nella chiamata a updheader.exe (la cosa strana è che la stessa riga di comando digitata manualmente funziona), anche se poi il file wice.ssu viene generato ugualmente.
Clicca per espandere...
ciao. Si, ho fatto qualche modifica, perchè anche io ricordo degli errori nelle fasi finali, dovuto a qualche path errato o simili, ma non ricordo più quale. Che errore hai tu? Non mi sembra di aver modificato il makefile, comunque lo metto su https://sites.google.com/site/ffxx78site/files
 
ffxx68 ha scritto:
ciao. Si, ho fatto qualche modifica, perchè anche io ricordo degli errori nelle fasi finali, dovuto a qualche path errato o simili, ma non ricordo più quale. Che errore hai tu? Non mi sembra di aver modificato il makefile, comunque lo metto su https://sites.google.com/site/ffxx78site/files
Clicca per espandere...
Grazie, ho visto che il tuo Makefile è modificato per ovviare al problema dei .bat non trovati (anch'io inizialmente avevo aggiunto un ./ prima di ssu.bat 1, ma poi ho preferito includere il percorso /cygdrive/d/CT216-DVB-source/0812 nel path, tanto ho creato uno shell script env.sh per impostare le variabili d'ambiente).
Se non ricordo male, il numero di errore è 63, comunque è dovuto al fatto che updheader.exe restituisce l'help come se venisse chiamato con parametri errati (in effetti nel modo 1 si aspetta come file di input un .bin, mentre gli viene passato un .stp, ma anche correggendo questo errore non funziona).
Stasera provo il tuo file e poi ti faccio sapere.

Devo dire che sono rimasto deluso dall'interesse mostrato verso questo thread. Certo non mi aspettavo la folla, ma siamo praticamente solo noi due.
E' vero che questo è prevalentemente un forum di utilizzatori, ma in altri siti, dove si discute ad esempio di telefonini o tv lcd ho sempre notato la presenza di gruppetti di "smanettoni" che portavano avanti discorsi tecnici e sviluppi vari (dal semplice sblocco di features nascoste alla creazione di vere e proprie rom custom), mentre qui c'è addirittura molta gente che ripropone a rotazione gli stessi quesiti senza nemmeno provare a vedere se sono già state date risposte in merito.Pazienza.

Ciao.
 
Silix ha scritto:
Devo dire che sono rimasto deluso dall'interesse mostrato verso questo thread. Certo non mi aspettavo la folla, ma siamo praticamente solo noi due.
E' vero che questo è prevalentemente un forum di utilizzatori, ma in altri siti, dove si discute ad esempio di telefonini o tv lcd ho sempre notato la presenza di gruppetti di "smanettoni" che portavano avanti discorsi tecnici e sviluppi vari (dal semplice sblocco di features nascoste alla creazione di vere e proprie rom custom), mentre qui c'è addirittura molta gente che ripropone a rotazione gli stessi quesiti senza nemmeno provare a vedere se sono già state date risposte in merito.Pazienza.
Clicca per espandere...

Purtroppo il tempo è tiranno e troppa gente si sta abituando a mangiare solo la zuppa pronta.
Il fenomeno che indichi tu l'ho notato anche su altri forum dove spesso appare qualcuno dal nulla, chiedendo qual'è il prodotto più buono e poi scompare. E magari si in..a :new_cussing: :angry5: pure se nessuno gli risponde entro due ore.

Quanto a questo thread abbi pazienza, magari si smuoverà nei prossimi tempi se un po' di gente mette le mani sui sorgenti.
 
Condivido la "delusione" di Silix... ma ho pazienza :) . D'altra parte, il tempo è poco per tutti... ciao
 
Rinnovo la richiesta - nessuno ha fatto nulla su questi sorgenti?
 
Ultima modifica:
Leggo soltanto adesso questa discussione che trovo veramente molto interessante. Complimenti per le informazioni che avete dato. Per quel che posso vorrei potervi dare una mano, ma la programmazione non è il mio forte. Ho provato un approccio diverso e vorrei un vostro parere e magari un aiuto. Dunque ho fatto questa prova :
Ho aggiornato il decoder con il file apposito e appena ripartito ho tolto la Flash SPI e ne ho letto il contenuto. Confrontandola con il file .SSU utilizzato per l'aggiornamento, ho notato che in pratica è identico, manca soltanto l'header iniziale e il CRC Finale. Sapete come viene calcolato il CRC del file ? Ho provato ad utilizzare i vari calcoli presenti nel software HXD Hex editor ( checksum -32 ) e CRC 32 e ottengo valori diversi rispetto a quelli presenti nel file originale.
Se fosse possibile risalire al calcolo del CRC in pratica facendo il dump della flash si avrebbe a disposizione il file e conoscendo l'hardware dell'apparecchio utilizzarlo per altri simili.

Intanto vi ringrazio e spero che questa discussione susciti l'interesse anche di altri appassionati
 
Devi accedere o registrarti per poter rispondere.
Indietro
Alto Basso