Interesse em ajudar...

Tenho interesse em ajudar o projeto, tomei conhecimento dele após dar uma pesquisada sobre como estava a cena do Zeebo após o anúncio do encerramento das atividades do Zeebo (que alías, já anunciaram outro console para 2012).

Eu não tenho Zeebo, não conheço muito de hardware, mas tenho uma boa experiência em reversão de engenharia de rom's adquiridos ao longo de vários anos no romhacking dos mesmos, o que inclui o ASM do processador ARM9/11 e linguagens de programação, como Python, C, Lua e etc.

Sou autor do PUPPy (https://bitbucket.org/hexodin/puppy/overview), um programa que desmonta e remonta os arquivos de atualização do Playstation 3, os *.pup, criei ele após o lançamento das informações pelo grupo fail0verfl0w, até hoje ele é utilizado para criação de CFW's do PS3.

Poderia dar uma olhada em trechos de dumps, nos pacotes dos emuladores e na lógica dos *.key, apesar de saber que são únicos para cada console e isso poderia acabar no não compartilhamento dessa informação para fins de análise.

Fico à disposição para qualquer eventalidade.

@hexodin

Welcome!
Tirando o estudos voltados ao Linux no console, temos alguns relacionados aos jogos ou aplicativos existentes, como por exemplo os emuladores (fix para o joystick e compatibilidade com ROMs), tentativa de resgatar as funções de rede do Zeeboids e/ou os "Boomerang Sports" (Peteca, Tênis, ...) (i.e. documentar o protocolo e emular o servidor oficial), modificar o Opera Mini para remover a proxy de filtro e compressão de dados, etc...

Estou preparando um pack de arquivos e documentação para todos que querem ajudar, mas enquanto isso posso disponibilizar arquivos (jogo/app) avulsos, basta dizer quais tem interesse em olhar.

Pretendo voltar com novas informações em breve, assim que desenrolar por aqui. So, tag along!

@TripleOxygen

Bom, como infelizmente não tenho um Zeebo disponível para me lançar a hackear (e atualmente estou sem condições de adquirir uma amostra) e fazer os testes necessários com o que viria a produzir, posso me oferecer para dar uma olhada nos apps, como por exemplo, esse emulador e suas ROM's e o mod do Opera Mini.

Sobre documentar o protocolo de serviço, infelizmente eu teria que ter um Zeebo hackeado para construir alguma coisa, tendo em vista que teríamos que passar um sniffer para poder logar os pacotes de rede, eu até tenho experiência nisso, pois já tentei, no passado, construir um emulador de um jogo online, mas o absurdo trabalho não me permitiu concluir, apesar do mesmo, na época, já permitir ao cliente do jogo login no servidor emulador.

Endereço: http://pymu.svn.sourceforge.net/viewvc/pymu/trunk/ | Emulador de MU Online - 4 anos atrás.

O que posso fazer é rezar para que o protocolo não esteja criptografado, e que seja possível documentá-lo sem a necessidade da rede oficial estar ativa, mas por experiência própria, posso afirmar que essa parte vai ser realmente muito trabalhosa e ainda mais se o protocolo tiver algum tipo de criptografia.

@hexodin

Já foram feitos os logs da comunicação entre os jogos e o servidor. Os serviços não estão online mais, por isso, temos apenas estes logs como material. O protocolo do Zeeboids, por exemplo, está compactado e/ou criptografado, assim é necessário juntar os logs, que contém os pacotes [pack|crypt]ed, e engenharia reversa do jogo para podermos reproduzi-los. Como o jogo tem a capacidade de gerar e interpretar um pacote, é possível documentar o protocolo, ao contrário da chave 61u.key, por exemplo, que não tem a implementação no console.

Uma dica: quando o servidor ainda estava ativo, se tentássemos acessar a página onde o jogo postava o dados, ela retornava um erro na função "mcrypt_decrypt" (já que pelo browser não era postada nenhuma informação válida). É uma pista, mas qual algoritmo e chave, só vasculhando o executável.

Sobre os emuladores, o Lucas também começará a analisar, qualquer coisa, he is in charge.

Atualizei o File Vault: https://openzeebo.forumeiros.com/t70-atualizacao-do-file-vault#678 olhe a pasta /content/ e /network/captures/apps/

Olá TripleOxygen, vou dar uma olhada nos arquivos que você postou: Sobre a questão da encriptação, você está certíssimo: Será necessário depurar o executável em busca das raw_strings que informam duas coisas básicas para a biblioteca libmcrypt: A cifra e a chave, pois libmcrypt implementa múltiplas cifras de encriptação de dados e tem implementação em várias linguagens.

http://mcrypt.sourceforge.net/

Se esse código está atrelado a um navegador, possivelmente é uma função PHP chamada mcrypt_decrypt: http://www.php.net/manual/en/function.mcrypt-decrypt.php pela sintaxe da função conclui-se que o mais importante mesmo é a chave e a cifra, o modo de operação pode ser testado.

Se for realmente ligada à função PHP, então será fácil achar a raw_string que contém o algoritmo usado, pois ela começará com "MCrypt_" e pode ser qualquer uma dessas constantes:

http://www.php.net/manual/en/mcrypt.ciphers.php

Sabendo qual é o algoritmo, fica mais fácil até reconhecer a string da chave, pois cada uma segue um padrão bem definido, por exemplo, é fácil saber quando algo está criptografado com base64 ou md5 só olhando...

Edit: Feedback pós-férias

Andei dando uma olhada nas férias, abrindo os arquivos no wireshark e vi que o que eu poderia ser útil na montagem de um servidor, mas o problema é que eu teria que ter um Zeebo conectado para testar esse servidor alternativo, mas fazer no escuro fica complicado, criar um emulador de servidor já é uma tarefa complexa, sem condições para testar não dá para mim, então, me disponibilizo mesmo para tentativas de análise e quebra de arquivos, TripleOxygen.

Vi no vault e não vi nada que tenha necessidade de ser analisado em termos de formato de arquivo/criptografia para quebra, se você tiver esse tipo de arquivo, eu posso dar uma olhada para tentar apresentar resultados.

Se possível, você pode tentar entender o protocolo fazendo RE nos executáveis (i.e. análise estática), e isso é o mais exequível já que não tem um Zeebo. Mesmo que tenha, depurar o código passo-a-passo não será possível via JTAG (a menos que consiga remover o watchdog do ARM9). O que poderá usar é logs pela porta de diag. De qualquer forma, ter um Zeebo é sim uma excelente idéia, claro!

Olhe nesta captura do Zeeboids, arquivo "zeeboids_import_111111_AAAAAAAAAAAAAAA_wrong_filtered". Veja um pedido de import ao servidor (tentando resgatar um Zeeboid de ID 111111, com a senha AAAAAAAAAAAAAAA):

Código:

POST /zeeboidsService/PHP/Client/import.php HTTP/1.1
Host: www.zeeboids.com:80
User-Agent: BREW-Applet/0x0108FF1A (BREW/4.0.2.24; DeviceId:  160000; Lang: pt)
Connection: Keep-Alive
Content-Length: 80
X-Method: POST
Content-Type: application/octet-stream

7..q..A1Ut.k%.r.?M...'E.W...]^.......-...R.`.\0...L6z..h.|6Q...'F..m.....DS....z

HTTP/1.1 200 OK
Date: Mon, 20 Jun 2011 15:27:12 GMT
Server: Apache/2.2.3 (Win32) PHP/5.3.0
X-Powered-By: PHP/5.3.0
Content-Length: 19
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

x..5400......
..T.t

No request deve haver o ZID e a senha do Zeeboid, e, provavelmente, o IMEI do console. Mas como vê, não é plain-text. Pode ser desde um gzip básico, ou criptografado com AES, ou ambos, ou whatever. Um simples XOR com 1 byte não seria, por causa da alta entropia dos dados. O reply corresponderia a um "senha errada".

Terá que sujar as mãos com o BREW, já que boa parte dos jogos/apps usam suas APIs, e evitam implementar internamente. Por exemplo, se algum app precisar de calcular um MD5 ou SHA1, vai chamar um set do BREW para isso, e não implementar o algoritmo do zero. Então, terá que entender como estas chamadas acontecem para detectá-las.

Este post no Zeeboclub resume um pouco como funciona http://forum.zeeboclub.com/t2432-programacao-brew-teoria-e-ola-mundo e neste documento http://www.tripleoxygen.net/files/openzeebo/doc/Programming_Model_dev.pdf

BR,

Vou tentar verificar o que está havendo na informação enviada e recebida do Zeeboids.

EDIT:
Bom, de fato, isso é alguma forma criptográfica, como esta informação está sendo enviada via POST para o servidor do zeeboids, que não existe mais, certamente ela está fazendo uso de alguma chave criptográfica interna do console, tendo em vista que isso não deve ser criptografia de via única (ou poderia ser?), mas não tenho pista de qual seja essa chave, sem pista não posso correr testes.

@hexodin

Chegou a olhar algo mais neste tempo? Ainda tem interesse em pesquisar? Tenho novidades neste assunto, por exemplo: a resposta do servidor é apenas compactada com zlib (inflate/deflate). Em Python, seria:

Código:


import zlib

packed = zlib.compress("plain_text_data", 9)
unpacked = zlib.decompress(packed)


O que me confundiu anteriormente, é que o magic da stream era 0x78da, e não 0x789c (padrão zlib). Acontece que 0x78da é para o nível de compactação maior (o 9, no caso).

Infelizmente os dados no sentido jogo -> servidor são diferentes. Praticamente certeza que algum block cipher com realimentação/chaining, pois nos testes que fiz, os dados são sempre em blocos múltiplos de 8 (talvez seja 16, não encontrei um variante pra confirmar) e a alteração de 1 byte apenas causa "avalanche" em todo o produto.

Edit: gotcha, é AES 128 (bloco 16 bytes). O IV e a chave já foram extraídas e a estrutura do pacote, desvendada. Agora é só documentar o protocolo depois de descriptografado. Vou postar as informações no Wiki posteriormente.