Firmware do conversor digital Zinwell ZBT-620A "tijolão" com função PVR

[Jefferson]

Código: [Selecionar]

init started:  BusyBox v1.2.1 (2007.04.18-10:43+0000) multi-call binary
Starting pid 15, console /dev/ttyS0: '/etc/init.d/rcSAlgorithmics/MIPS FPU Emulator v1.5

ABORTANDO NESTE PONTO NEM O USB FUNCIONA

 Mount /proc fs
Mount /dev/p

ABORTANDO NESTE PONTO O USB FUNCIONA, MAS NÃO A INTERFACE


Os comandos aparecem no terminal Telnet? Se aparecerem não deve ser difícil escrever um programa, no Windows, que pare a execução em um ponto específico, à escolha do usuário

[Jefferson]

Só de lembrar como foi feita a engenharia reversa das fontes dos firmwares Mediatek, já dá um certo desespero: http://personal.inet.fi/cool/mediatek/documents/Info%20-%20MT1389%20v0.3b%20English.rtf E pensar que precisa: encontrar onde estão as fontes; fazer a engenharia reversa; criar um programa para trocar/editar as fontes. Nossa! Não sei quando (ou se) eu seria capaz de fazer esse processo completo. O máximo que eu conseguiria no momento seria tentar ajudar um pouco ali e outro aqui...

A "scene" MT13x9 se beneficiou muito com essa documentação deixada pelos primeiros hackers. Sem ela como ponto de partida, eu nem teria começado.

[rictad]

rictad,
Um dos motivos que fizeram o pedroacerbi do HTForum querer vender seu ZBT-601 (para você, por coincidência  ) foi a questão do limite de 6h de gravação, que ainda está confuso para mim: esse limite existe tanto para ext3 como para FAT32? Esse limite existe tanto para gravações manuais como agendadas?

Pois é, eu não sei dizer, porque me desfiz do meu "tijolão" (família) e estou esperando o 601 chegar. Mas eu acho que é para os 2 formatos.

De qualquer modo achei a seguinte string no zmw_base_zinwell:

.rodata:0068B058 70 76 72 3A 20 73 74 72+aPvrStreamHasRe:.ascii "pvr: stream has recode 6hrs"<0>

Não existe referência direta à essa string no código (como no caso da string "mke2fs" que você comentou). Portanto para chegar até a referência teria que fazer o mesmo método que você fez para "mke2fs": sabendo o endereço absoluto da string do "limite de 6hrs", procurando nas rotinas relacionadas ao PVR, tentar encontrar a chamada para determinado offset à partir de algum ponteiro, não é?

Isso! Esse seria o método. Acho que (talvez esteja errado) não seja tão difícil retirar essa limitação.

Outra coisa:
Andei bisbilhotando no zmw_base_zinwell (enviado pelo rictad alguns posts atrás), e encontrei os locais onde estão as strings de todas as mensagens exibidas na tela: fica entre B48426 e B61E9E. Cada String aparece 7 vezes:
1,2,3,4,6: em Inglês
5: em Espanhol
7: em Português
O legal é que esses dados não estão comprimidos. Portanto, imagino que podemos mudá-las à vontade. Bem, acho que não tão à vontade assim, pois temos que respeitar o limite de caracteres que já está lá para cada string: trocar por uma menor pode; já trocar por uma maior ficaria mais complicado... Nos firmwares Mediatek, tinhamos à disposição aqueles programinhas pra mudarmos tudo, inclusive alterando o tamanho das strings se necessário... http://personal.inet.fi/cool/mediatek/programs/mtklangeditor.html

Mas eu descobri um modo, que seria alterar o ponteiro das strings para um lugar com mais espaço ou mesmo alterar apenas o offset relacionado à string que se quer aumentar para um outro ponto com espaço disponível. Isso funcionou bem para colocar a string "Rictad v.1.14.4c beta" na versão do firmware. 

Só de lembrar como foi feita a engenharia reversa das fontes dos firmwares Mediatek, já dá um certo desespero: http://personal.inet.fi/cool/mediatek/documents/Info%20-%20MT1389%20v0.3b%20English.rtf E pensar que precisa: encontrar onde estão as fontes; fazer a engenharia reversa; criar um programa para trocar/editar as fontes. Nossa! Não sei quando (ou se) eu seria capaz de fazer esse processo completo. O máximo que eu conseguiria no momento seria tentar ajudar um pouco ali e outro aqui...

A "scene" MT13x9 se beneficiou muito com essa documentação deixada pelos primeiros hackers. Sem ela como ponto de partida, eu nem teria começado.

Esse é o ponto! O que aqueles caras fizeram no começo foi fundamental.

Última coisa,
rictad, só me confirma uma coisa: as fontes (da GUI, das CC, etc.) estariam no próprio zmw_base_zinwell, não é?
Pergunto isso pois como você já descreveu no início deste tópico, as Closed Captions têm fontes pequenas e ruins, não é? Seria uma modificação muito legal poder melhorar isso... Falando nisso, além da fonte das Closed Captions, existe outro tipo de problema, como posicionamento problemático, caracteres errados, falta de itálico, etc.?
Eu estou pra criar um novo tópico aqui no Forum descrevendo as particularidades (e os problemas) das Closed Captions da TV Digital (tendo como ponto de comparação as CC da TV Analógica). Só pra adiantar, na minha TV Sony 40EX505 eu detectei os seguintes problemas, sendo que alguns são como certeza devidos a TV, outros devidos a transmissão, e outros que eu fiquei na dúvida sobre o causador:
- Ausência de Itálicos: Vendo o mesmo filme da Globo, na TV Analógica tem itálico, e já na TV Digital, nos pontos correspondentes, não tem itálico. Será isso um problema da transmissão, ou da TV? Por tudo que eu pude deduzir até agora, as CC digitais ,até o momento, são "upconverted" à partir das analógicas: elas não são criadas específicamente para TV Digital (com todos os recursos melhores que poderiam ser usados...).
- Falta de sincronia: na TV Analógica estão bem sincronizadas, e na Digital estão atrasadas: já ouvi falar que é problema das transmissoras, mas não tenho certeza...
- Alguns Caracteres especiais/acentuados errados: também não sei quem é o responsável...
- Formatação errada: fica evidente quando se compara com as CC dos filmes da Globo na TV Analógica, em que as falas ficam localizadas perfeitamente próximas de quem está falando...
- Fonte de tamanho pequeno, e com espaçamento entre os caracteres exagerado...

Sim, as fontes devem estar no zmw_base_zinwell. E o CC é o padrão mesmo. Acho aquilo um absurdo de ruim. Quem depende de closed caption acaba sofrendo um total descaso dos fabricantes.

[rictad]

Código: [Selecionar]

init started:  BusyBox v1.2.1 (2007.04.18-10:43+0000) multi-call binary
Starting pid 15, console /dev/ttyS0: '/etc/init.d/rcSAlgorithmics/MIPS FPU Emulator v1.5

ABORTANDO NESTE PONTO NEM O USB FUNCIONA

 Mount /proc fs
Mount /dev/p

ABORTANDO NESTE PONTO O USB FUNCIONA, MAS NÃO A INTERFACE


Os comandos aparecem no terminal Telnet? Se aparecerem não deve ser difícil escrever um programa, no Windows, que pare a execução em um ponto específico, à escolha do usuário

Sim, aparecem no terminal. Mas como estão no script de inicialização, também é possível modificar o script e criar um novo sistema de arquivos squashfs para ser gravado na flash. No novo sistema de arquivos que eu criei (mas ainda não disponibilizei porque não terminei de configurar), que tem a nova versão do busybox, eu alterei várias vezes esses scripts para permitir que executem automaticamente um binário do firmware encontrado no pen drive.

Seria possível alterar o script para que não chame o zmw_base_zinwell da flash ou chame apenas o do pen drive. Mas isso pode dificultar o uso da única porta USB para testar o PVR, já que o pen drive já estaria montado. Esse é o motivo dos vários mount 00000 que o rafael citou:

Ficam aparecendo insistentes mensagens mount status 00000000 , como eu já havia dito antes.

Rafael, para evitar essa mensagem, e conseguir testar a porta USB com o novo zmw_base_zinwell rodando, você deve criar ao menos 2 partições no pen drive. Assim, você deixa o binário na partição 0 e quando ele for chamado vai montar a partição 1, a qual pode ser usada para testar o PVR.

[rictad]

Outra coisa:
Andei bisbilhotando no zmw_base_zinwell (enviado pelo rictad alguns posts atrás), e encontrei os locais onde estão as strings de todas as mensagens exibidas na tela: fica entre B48426 e B61E9E. Cada String aparece 7 vezes:
1,2,3,4,6: em Inglês
5: em Espanhol
7: em Português
O legal é que esses dados não estão comprimidos. Portanto, imagino que podemos mudá-las à vontade. Bem, acho que não tão à vontade assim, pois temos que respeitar o limite de caracteres que já está lá para cada string: trocar por uma menor pode; já trocar por uma maior ficaria mais complicado... Nos firmwares Mediatek, tinhamos à disposição aqueles programinhas pra mudarmos tudo, inclusive alterando o tamanho das strings se necessário... http://personal.inet.fi/cool/mediatek/programs/mtklangeditor.html
O objetivo disso tudo seria melhorar a tradução das mensagens na tela. Exemplos do que eu vi que poderia ser melhorado (deve haver muito mais...):

Achei o arquivo que havia criado com o bloco de strings Unicode retirado do firmware1.14.4 (esse mesmo que você encontrou). Segue em anexo. É possível abrirmos em um editor hexadecimal e vermos como funciona a sua estrutura. Enquanto as strings ASCII são referenciadas com ponteiros nas próprias rotinas, sendo atualizados com offsets, as strings Unicode possuem uma estrutura de ponteiros no próprio bloco, semelhante à dos menus dos Mediatek.

No início do arquivo temos:
00 01 00 00 5A 68 10 01 00 00 5A 70

A primeira referência diz que a string 0001, mais precisamente a string 001 da língua 0, começa no endereço 0x00005A68 (string "Min"). A mesma string, mas da língua 1 (1001), começa no endereço 0x00005A70.

Daria para fazer um programinha que agilizasse as mudanças e traduções nas strings. O problema é que não há espaço após o bloco, ou seja, se ele aumentar de tamanho tem que ser mudado de lugar. Neste caso, temos que descobrir onde estaria a referência a todo o bloco. Se tiver uma referência em cada rotina, fica mais difícil. Uma solução seria alterar apenas o ponteiro das strings, tirando elas do bloco e as jogando para um lugar vazio. Ainda sim dá problemas, pois acho que em cada versão do firmware o bloco fica em lugar diferente e os espaços vazios seriam outros também. De qualquer forma, fica fácil fazer pequenas alterações manuais.

[zeurt]

Daria para fazer um programinha que agilizasse as mudanças e traduções nas strings. O problema é que não há espaço após o bloco, ou seja, se ele aumentar de tamanho tem que ser mudado de lugar. Neste caso, temos que descobrir onde estaria a referência a todo o bloco. Se tiver uma referência em cada rotina, fica mais difícil. Uma solução seria alterar apenas o ponteiro das strings, tirando elas do bloco e as jogando para um lugar vazio. Ainda sim dá problemas, pois acho que em cada versão do firmware o bloco fica em lugar diferente e os espaços vazios seriam outros também. De qualquer forma, fica fácil fazer pequenas alterações manuais.

Eu dei uma olhada aqui no IDA, e só existem 2 referencias para essa tabela das strings Unicode. São elas:

Código: [Selecionar]

Up   o sub_4364B0+40 la      $t0, unk_B429C0
Down o .got:00BB9978 .word unk_B429C0   
Essa sub_4364B0 parece ser uma rotina chave para acessar a tabela. Ainda não analisei ela com calma:

Código: [Selecionar]

.text:004364B0
.text:004364B0
.text:004364B0                         sub_4364B0:                              # CODE XREF: sub_45EBE0+10j
.text:004364B0                                                                  # sub_61A7B0+208p ...
.text:004364B0
.text:004364B0                         var_18          = -0x18
.text:004364B0                         var_10          = -0x10
.text:004364B0                         var_C           = -0xC
.text:004364B0                         var_8           = -8
.text:004364B0
.text:004364B0 79 00 1C 3C 00 98 9C 27                 la      $gp, unk_789800
.text:004364B8 21 E0 99 03                             addu    $gp, $t9
.text:004364BC D8 FF BD 27                             addiu   $sp, -0x28
.text:004364C0 20 00 BF AF                             sw      $ra, 0x28+var_8($sp)
.text:004364C4 1C 00 B1 AF                             sw      $s1, 0x28+var_C($sp)
.text:004364C8 18 00 B0 AF                             sw      $s0, 0x28+var_10($sp)
.text:004364CC 10 00 BC AF                             sw      $gp, 0x28+var_18($sp)
.text:004364D0 A8 98 99 8F                             la      $t9, sub_4A62E0
.text:004364D4 FF FF 91 30                             andi    $s1, $a0, 0xFFFF
.text:004364D8 09 F8 20 03                             jalr    $t9 ; sub_4A62E0
.text:004364DC 21 80 00 00                             move    $s0, $0
.text:004364E0 10 00 BC 8F                             lw      $gp, 0x28+var_18($sp)
.text:004364E4 21 18 40 00                             move    $v1, $v0
.text:004364E8 01 00 02 24                             li      $v0, 1
.text:004364EC 06 00 62 10                             beq     $v1, $v0, loc_436508
.text:004364F0 C8 9C 88 8F                             la      $t0, unk_B429C0
.text:004364F4 02 00 62 28                             slti    $v0, $v1, 2
.text:004364F8 36 00 40 14                             bnez    $v0, loc_4365D4
.text:004364FC 02 00 02 24                             li      $v0, 2
.text:00436500 22 00 62 10                             beq     $v1, $v0, loc_43658C
.text:00436504 00 00 00 00                             nop
.text:00436508
.text:00436508                         loc_436508:                              # CODE XREF: sub_4364B0+3Cj
.text:00436508                                                                  # sub_4364B0:loc_43658Cj ...
.text:00436508 00 13 10 00                             sll     $v0, $s0, 12
.text:0043650C 25 10 51 00                             or      $v0, $s1
.text:00436510 FF FF 50 30                             andi    $s0, $v0, 0xFFFF
.text:00436514 18 00 00 12                             beqz    $s0, loc_436578
.text:00436518 21 10 00 00                             move    $v0, $0
.text:0043651C 02 00 02 91                             lbu     $v0, 2($t0)
.text:00436520 03 00 03 91                             lbu     $v1, 3($t0)
.text:00436524 04 00 04 91                             lbu     $a0, 4($t0)
.text:00436528 00 16 02 00                             sll     $v0, 24
.text:0043652C 00 1C 03 00                             sll     $v1, 16
.text:00436530 05 00 05 91                             lbu     $a1, 5($t0)
.text:00436534 25 10 43 00                             or      $v0, $v1
.text:00436538 00 22 04 00                             sll     $a0, 8
.text:0043653C 25 10 44 00                             or      $v0, $a0
.text:00436540 25 38 45 00                             or      $a3, $v0, $a1
.text:00436544 0B 00 E0 18                             blez    $a3, loc_436574
.text:00436548 21 30 00 00                             move    $a2, $0
.text:0043654C
.text:0043654C                         loc_43654C:                              # CODE XREF: sub_4364B0+BCj
.text:0043654C 21 28 06 01                             addu    $a1, $t0, $a2
.text:00436550 00 00 A2 90                             lbu     $v0, 0($a1)
.text:00436554 01 00 A3 90                             lbu     $v1, 1($a1)
.text:00436558 06 00 C6 24                             addiu   $a2, 6
.text:0043655C 00 12 02 00                             sll     $v0, 8
.text:00436560 25 10 43 00                             or      $v0, $v1
.text:00436564 0B 00 50 10                             beq     $v0, $s0, loc_436594
.text:00436568 2A 20 C7 00                             slt     $a0, $a2, $a3
.text:0043656C F7 FF 80 14                             bnez    $a0, loc_43654C
.text:00436570 00 00 00 00                             nop
.text:00436574
.text:00436574                         loc_436574:                              # CODE XREF: sub_4364B0+94j
.text:00436574 21 10 00 00                             move    $v0, $0
.text:00436578
.text:00436578                         loc_436578:                              # CODE XREF: sub_4364B0+64j
.text:00436578 20 00 BF 8F                             lw      $ra, 0x28+var_8($sp)
.text:0043657C 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:00436580 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:00436584 08 00 E0 03                             jr      $ra
.text:00436588 28 00 BD 27                             addiu   $sp, 0x28
.text:0043658C                          # ---------------------------------------------------------------------------
.text:0043658C
.text:0043658C                         loc_43658C:                              # CODE XREF: sub_4364B0+50j
.text:0043658C DE FF 00 10                             b       loc_436508
.text:00436590 04 00 10 24                             li      $s0, 4
.text:00436594                          # ---------------------------------------------------------------------------
.text:00436594
.text:00436594                         loc_436594:                              # CODE XREF: sub_4364B0+B4j
.text:00436594 02 00 A2 90                             lbu     $v0, 2($a1)
.text:00436598 03 00 A3 90                             lbu     $v1, 3($a1)
.text:0043659C 04 00 A4 90                             lbu     $a0, 4($a1)
.text:004365A0 00 16 02 00                             sll     $v0, 24
.text:004365A4 00 1C 03 00                             sll     $v1, 16
.text:004365A8 05 00 A5 90                             lbu     $a1, 5($a1)
.text:004365AC 25 10 43 00                             or      $v0, $v1
.text:004365B0 00 22 04 00                             sll     $a0, 8
.text:004365B4 25 10 44 00                             or      $v0, $a0
.text:004365B8 20 00 BF 8F                             lw      $ra, 0x28+var_8($sp)
.text:004365BC 1C 00 B1 8F                             lw      $s1, 0x28+var_C($sp)
.text:004365C0 18 00 B0 8F                             lw      $s0, 0x28+var_10($sp)
.text:004365C4 25 10 45 00                             or      $v0, $a1
.text:004365C8 21 10 48 00                             addu    $v0, $t0
.text:004365CC 08 00 E0 03                             jr      $ra
.text:004365D0 28 00 BD 27                             addiu   $sp, 0x28
.text:004365D4                          # ---------------------------------------------------------------------------
.text:004365D4
.text:004365D4                         loc_4365D4:                              # CODE XREF: sub_4364B0+48j
.text:004365D4 CC FF 60 14                             bnez    $v1, loc_436508
.text:004365D8 00 00 00 00                             nop
.text:004365DC CA FF 00 10                             b       loc_436508
.text:004365E0 06 00 10 24                             li      $s0, 6
.text:004365E0                          # End of function sub_4364B0
.text:004365E0
Em resumo, pelo que eu entendi, o bloco inteiro poderia ser mudado de lugar.
Se o programinha fosse feito, a tabela (os ponteiros) teriam que ser todos reformados, já que mudar o tamanho de uma única string faria com que os endereços (offsets) das strings seguintes ficassem errados, não é?
O total de strings pra rever/traduzir é: 227H, ou seja, 551!  Tudo bem, se tiver como fazer, eu assumo essa tarefa da revisão/tradução se precisar... 

[zeurt]

Para quem não usa Linux rotineiramente, está com preguiça de usar um Live Linux, ou está com preguiça de compilar o Squashfs tools com LZMA para o Windows, aqui estão os binários já compilados: http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip
Créditos para o russo Nikolay Pelov, deste site: http://www.nicksoft.info/

Já testei, e está funcionando perfeitamente: foi possível extrair os binários zmw_base_zinwell à partir dos blocos CODE dos firmwares .zim do ZBT633/601 exportados pelo Zimview (conforme explicados pelo rictad em um de seus posts iniciais deste tópico).

[zeurt]

rictad,
Eu notei que o ZBT-601 não tem Porta Ethernet. Isso não torna a recuperação, após atualização mal sucedida, difícil, ou praticamente impossível com as ferramentas que contamos até o momento?
Afinal, quando estamos no CFE, a única alternativa para gravar os blocos do firmware na flash não é pela rede? Ou eu perdi alguma informação?

[rictad]

Para quem não usa Linux rotineiramente, está com preguiça de usar um Live Linux, ou está com preguiça de compilar o Squashfs tools com LZMA para o Windows, aqui estão os binários já compilados: http://download.nicksoft.info/linux/backuplivecd/squashfs-tools.zip
Créditos para o russo Nikolay Pelov, deste site: http://www.nicksoft.info/

Já testei, e está funcionando perfeitamente: foi possível extrair os binários zmw_base_zinwell à partir dos blocos CODE dos firmwares .zim do ZBT633/601 exportados pelo Zimview (conforme explicados pelo rictad em um de seus posts iniciais deste tópico).

Olá zeurt! Essa compilação do Pelov eu já conhecia, mas tem um problema. O unsquash funciona legal, mas o mksquash dá erro com alguns arquivos. Pelo menos na época eu não consegui de forma alguma refazer o bloco CODE com ela. O próprio Pelov diz que não sabe porque em alguns casos esse erro ocorre. O ryan também chegou a me dizer que usava essa versão. Já no caso específico dele, a criação da imagem ocorre com sucesso.

rictad,
Eu notei que o ZBT-601 não tem Porta Ethernet. Isso não torna a recuperação, após atualização mal sucedida, difícil, ou praticamente impossível com as ferramentas que contamos até o momento?
Afinal, quando estamos no CFE, a única alternativa para gravar os blocos do firmware na flash não é pela rede? Ou eu perdi alguma informação?

Pois é. A única forma de recuperar uma gravação mal sucedida (desde que o CFE ainda esteja funcionando) é pela rede mesmo. O fato de o ZBT-601 não ter porta ethernet realmente gera uma certa preocupação para quem for desenvolver. Mas a ideia é testar antes o zmw_base_zinwell pelo pen drive. Se funcionar, é só gerar o bloco CODE. Depois, pode-se testar também o bloco CODE pelo pen drive, montando-o em algum ponto do sistema de arquivos e chamando o zmw_base_zinwell de dentro. Se funcionar também, é só criar a imagem .zim e gravar na flash. Assim, os riscos de ocorrerem problemas após a gravação na flash são reduzidos ao risco padrão de uma atualização mal sucedida.

[zeurt]

Sobre o limite de 6h de gravação:
Andei pensando bastante sobre esse limite, e acabei chegando a algumas conclusões.
Acho que tem sentido existir um limite de tempo de gravação. Por exemplo, digamos que alguém tenha um HDD de 1TB e resolve gravar um programa (apertar REC). Digamos que essa pessoa esqueça dessa gravação, saia de casa, volte, durma, etc. Se não houvesse o limite, seria criado um arquivos gigantesco, ocupando quase todo o HDD??? Ou será que independente de existir um limite explícito, existe algum outro tipo de limitação máxima "natural" para o tamanho possível desses arquivos?
Me parece que o limite de 6h é meio arbitrário, poderia ser mais, ou menos (ou será que existe alguma lógica nesse valor?).
De qualquer modo, na minha opinião, o ideal não seria eliminar o limite (justamente para manter o "dispositivo de segurança" que descrevi acima). Acho que o melhor seria o usuário poder escolher o limite máximo em horas, ou até mesmo poder escolher, caso queira, eliminar o limite. Para isso, também seria necessário termos acesso a estrutura do menu, etc.
Se o usuário pudesse escolher o limite máximo de gravação, estariamos criando indiretamente uma função OTR (One Touch Recording) adaptada. Explico: digamos que se queira gravar as próximas 3 horas de um determinado canal. Seria só ir ao menu e determinar o limite máximo de gravação em 3 horas. Daí, era só pressionar REC (não é tão One Touch, mas é quase... )
Caso não conseguirmos mesmo ter acesso a estrutura do menu, se eu pudesse escolher, eu manteria um certo limite máximo (12 horas??). Ou atá mesmo criar 2 versões de firmware, atendendo a todos os gostos... 

Estrurura de dados do Firmware:
Nos últimos dias, eu tenho estudado a parte de Pure Data do firmware (a parte .data no IDA). Descobri bastante coisa interessante. Falta MUITA coisa ainda, é claro. Mas já é um começo, já dar pra visualizar o "esqueleto" principal da estrutura de dados. Inclusive, acho que encontrei o provável local das fontes (posso estar enganado, mas evidências iniciais indicam isso).
Estou com o rascunho aqui, e após aprimorar um pouco mais essa versão preliminar ALFA, eu postarei esses achados iniciais...