👺 🤵🏻 🕟 Protegendo e invadindo o Xbox 360 (parte 1) 🧘🏼 🔕 🍈

Você provavelmente já ouviu falar sobre o console do Xbox 360 e que ele está "piscando". Por "firmware", aqui, entende-se um desvio dos mecanismos de proteção internos para o lançamento de cópias de jogos e software proprietário. E aqui surgem perguntas! Quais mecanismos, como eles se locomovem? O que os desenvolvedores fizeram, como eles conseguiram contornar isso? De fato, o tópico é muito extenso e interessante, especialmente para o Xbox 360 - aqui você encontra vulnerabilidades de software, falhas de hardware e magia absolutamente mágica. Interessante? Entre! Na primeira parte, somos apresentados ao hypervisor, unidades e firmware ...

Conheça o assunto

O console Xbox 360 foi lançado em 2005 e não sofreu alterações nas características do ferro desde então. Todo o tempo que foi lançado, eles eram os mesmos:

CPU PowerPC de 3,2 GHz, / 3 núcleos
GPU de 500 MHz
512 MB de RAM
DVD-ROM SATA
HDD SATA (opcional)

Sim, o design mudou com o tempo, os nanômetros diminuíram:

No entanto, todos os jogos funcionaram igualmente bem em todas as "revisões" dos consoles - esse é exatamente o caso quando jogos modernos podem ser executados em equipamentos de 2005.

No momento do lançamento, foi feita uma declaração alta de que o console foi desenvolvido o mais seguro possível - chips personalizados com proteção no nível do hardware e, em geral, os hackers ainda não viram isso:

Haverá níveis de segurança nesta caixa que a comunidade hacker nunca viu antes

O que os desenvolvedores inventaram?

Primeiro , eles fizeram tudo para que o código do programa do sistema não pudesse ser obtido . Uma ROM de 32 KB contendo um carregador primário (1BL) e uma SRAM de 64 KB na qual foi executado foram incorporadas ao processador central. É muito, muito difícil obter o conteúdo de uma ROM a partir de um chip de CPU:

Segundo , fusíveis especiais foram colocados no mesmo processador - jumpers queimados (literalmente, alta tensão), uma espécie de memória que era programável. Os fusíveis incluíam:

Bits de bloqueio da interface JTAG
bits que determinam a finalidade do prefixo (retail / devkit / testkit)
chave exclusiva de processador de 128 bits
Contadores de valor de bloqueio (LDV) para desativar o downgrade

Sim, a quantidade de fusão é limitada. Se você conseguir atualizar seu console 80 vezes seguidas, o contador CFLDV terminará e ... não sei, não tentei fazer isso. Provavelmente, o prefixo não será mais atualizado.

Terceiro , os desenvolvedores implementaram uma cadeia de confiança . Para verificar a autenticidade dos gerenciadores de inicialização, foi usada uma combinação dos algoritmos SHA-1 e RSA-2048 modernos (na época), que excluíam a possibilidade de lançar seu próprio código ou a modificação não autorizada dos gerenciadores de inicialização, mesmo que você tenha conseguido todas as chaves do console e possa reconstruir o sistema. .

Quarto , os desenvolvedores decidiram ir mais longe no princípio de "não confiar em ninguém" e colocar um módulo de hardware especial para proteger a RAM na mesma CPU infeliz ! Com sua ajuda, todas as áreas com código de programa foram criptografadas e o monitoramento de integridade foi ativado nas áreas mais importantes (hypervisor)!

Ao fazer isso, os desenvolvedores se defenderam dos ataques de DMA quando, através de dispositivos externos que têm acesso à RAM, eles modificaram o código do programa do sistema na RAM.

Finalmente , o hipervisor lidou com a diferenciação de direitos nas regiões de memória . Somente ele podia tornar as páginas executáveis, é claro, antes de verificar a assinatura digital, por isso era impossível fazer o download de código não assinado ou executar algo da área de dados, mesmo através de uma vulnerabilidade em algum driver ou jogo (o eixo e os jogos eram lançados com direitos de kernel) .

Como resultado, o sistema operacional Xbox 360 estava bem protegido e, portanto, o DVD-ROM foi escolhido como o primeiro vetor de ataque.

Começamos ... backups!

No Xbox 360, um DVD de camada dupla foi escolhido como a principal mídia para jogos. Naturalmente, mecanismos de defesa também estavam presentes aqui:

a troca de dados com DVD-ROM foi criptografada com uma chave única
no início do disco, havia “setores de segurança” especiais para confirmar o licenciamento
arquivos executáveis em disco foram assinados digitalmente

Mas muito menos atenção foi dada à proteção da unidade de DVD do que ao sistema principal. O console do jogo mostrou muita confiança na unidade de DVD - foi o DVD-ROM que determinou o licenciamento do disco. Além disso, o firmware foi armazenado na memória externa e pode ser lido pelo programador:

Como resultado, em 14 de maio de 2006, a commodore4eva (c4eva) lançou o primeiro firmware modificado para acionar o modelo TS-H943:

README para a liberação do firmware

— Xtreme firmware for TS-H943 Xbox 360
— Here it is, the long awaited World first Xbox 360 backup firmware modification to boot all game backups!

Features
— Boots all Xtreme Xbox 360 backups
Boots all Xtreme Xbox 1 backups
Boots all Xbox 360 originals
Boots all Xbox 1 originals on Xbox 360
Xtreme0800 extraction firmware enables drive to function natively under Windows without any hardware conversion/adaptors
Use on Xbox Live at own risk

Technical details
— Reads Xbox 360 security sector from PSN 04FB1F (Layer 0)
Reads Xbox 1 security sector from PSN 605FF (Layer 0)
Security sector must be extrated using Xtreme0800 360 firmware for Xbox360 games and Xbox 1 games
Will not boot Xbox 1 backups made with Xbox1 605b 0800 firmware (maybe in future release)

O firmware leu os setores de segurança de áreas fixas em um disco de DVD e enganou o console, fazendo pensar que um disco licenciado foi inserido.

Ao mesmo tempo, o firmware 0800 foi lançado, projetado para criar cópias de jogos e ler setores de segurança. A unidade Xbox 360, que brilhou com esse firmware, foi detectada no computador e conseguiu ler completamente os setores do disco do jogo.

Leia-me sobre o uso do firmware 0800

Extracting Security Sector
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following four custom cdb commands:

AD 00 FF 02 FD FF FE 00 08 00 01 C0
AD 00 FF 02 FD FF FE 00 08 00 03 C0
AD 00 FF 02 FD FF FE 00 08 00 05 C0
AD 00 FF 02 FD FF FE 00 08 00 07 C0

Then save hexadecimal display as bin file as SS.bin

Creating a game backup
— Ensure DVD drive has been flashed with Xtrm0800.bin firmware. Drive can now work under Windows.
Extract Isobuilder.rar
Insert original game disk into drive and wait for windows to detect disk change
Run DVDinfoPro
Enter the following custom cdb command to unlock drive: (game data visable)

FF 08 01 01

Run Isobuster
Right click on DVD and select Extract From-To
Click Length and enter number of LBAs as follows:

Xbox 1 Original Number of LBA to read 3431264 decimal
or
Xbox 360 Original Number of LBA to read 3567872 decimal
Select User Data (2048 bytes/block)
Click Start Extraction
Enter filename as game.iso and click Save
Upon read error dialogue box choose fill with blank zeros for sector and select use this selection for all errors
Copy game.iso and ss.bin to the relevent isobuilder directory (Depending on Xbox 360 or Xbox 1 game)
Run build360.bat (Xbox 360 game) or build.bat (xbox 1 game)
Ensure your burner will set the booktype of DVD+R DL to DVDRom
Burn with CloneCd and choose the image.dvd file

Outro jogo pode ser parcialmente copiado com o seguinte truque:

colocar em um computador DVD-ROM disco comum de duas camadas
espere até que se acalme e pare de girar
com um clipe de papel, abra a bandeja e altere a unidade para o jogo no Xbox 360
feche a bandeja e faça uma imagem de disco!

(Não funcionou em todos os modelos de DVD-ROM)

O mais importante é que a unidade foi flasheada exclusivamente por software, com comandos ATA especiais. O kit incluiu um programa especial para ler o firmware original e escrever modificado. No firmware original, a chave estimada foi armazenada, com a qual a unidade foi vinculada ao Xbox 360:

A perda da chave significava que mesmo os discos licenciados não podiam ser lançados; portanto, alguns escreviam a chave em um notebook e a salvavam sempre que possível, esse era o conhecimento mais estimado.

Um tópico separado foi o pânico sobre o jogo online. Todo mundo temia que a Microsoft descobrisse que a unidade foi modificada e desabilitaria remotamente o console. Alguns até fizeram um mod de hardware para alternar entre o firmware de fábrica e o firmware modificado:

Eles tocaram no firmware original "licenciado" e, com uma conexão à rede, desconectaram-no vergonhosamente no cabo da Internet modificado. A propósito, o pânico não foi em vão, mas esses modos foram completamente em vão, tudo foi registrado sem conexão com a rede.

Exatamente um mês depois (15 de junho de 2006), o firmware foi portado para outro modelo de unidade, que foi instalado no Xbox 360 naquele momento - Hitachi GDR3120L. Ele também tinha uma unidade flash externa contendo firmware:

Esta unidade estava melhor protegida:

o firmware foi armazenado na ROM em forma criptografada
havia controle de integridade no firmware
para sobrescrever o firmware, você teve que entrar em um "Modo B" especial

E se os pesquisadores conseguiram os dois primeiros pontos, o feito da tradução no "Modo B" deveria ser repetido por todos os ~~jovens~~ piscadores.

Esta ação foi proposta para ser executada usando um disco de inicialização especial com o Slax Linux ou fazendo um curto-circuito nos fios na inicialização. Foi necessário um curto-circuito nos contatos 0 e 9 do conector de energia da unidade. Por exemplo, com alfinetes!

Nos dois casos, após esses abusos, a unidade foi definida no Windows como uma unidade de DVD comum, onde foi recolhida, ~~estuprada~~ e costurada.

Após o primeiro lançamento, os firmwares personalizados foram finalizados, a estabilidade foi aprimorada, o suporte para novos jogos foi adicionado, em geral, tudo estava como de costume.

Resposta da Microsoft

Os desenvolvedores das alegações de que o console "inquebrável" foi hackeado, responderam simplesmente:

O sistema não foi invadido, apenas aprendemos a lançar cópias de jogos, estamos trabalhando nele

resposta original

The core security system has not been broken. However, it is reported that the authentication protocol between the optical disc drive and the console may be attacked, which if accurate could allow people to play illegally copied games. Our security team is aware of this and we are investigating potential solutions to this issue. The Xbox 360 platform was designed to be updated, and we are prepared to respond appropriately should any unauthorized activity be identified.

O que realmente foi feito para corrigir a situação:

O Samsung TS-H943 começou a vir com o firmware ms28, que não entrava no modo de firmware pelo conhecido comando ATA
O Hitachi GDR3120L apareceu com o firmware 0078 e 0079, não piscando nem no modo B
Aparecem as novas unidades BenQ-LiteOn VAD6038
As primeiras "proibições" pontuais de piratas no Xbox Live começaram; os piratas eram proibidos de jogar online para sempre

Se tudo fosse inequívoco e irreparável com a proibição (naquele momento), os pesquisadores logo descobriram os impulsos:

Para Hitachi encontrado desbloquear o modo de firmware através de um disco de áudio especial
O Samsung ms28 e o BenQ VAD6038 entraram perfeitamente no modo firmware através de controladores baratos SATA VIA 6421

Vamos deixar o campo de batalha por firmware de unidade por um tempo, não houve um período muito interessante em que os pesquisadores tentaram criar o firmware "Stealth", para não serem banidos do Xbox Live, se ajustarem a novos jogos com novas "ondas" - versões de atualização do sistema e portam os resultados para tudo uma variedade crescente de firmware e unidades. Mesmo assim, tudo foi costurado, os "backups" foram lançados com sucesso, o Xbox 360 estava ganhando popularidade entre as pessoas ...

Quebrando o eixo!

Como você se lembra da primeira parte da história, o sistema Xbox 360 tinha um hipervisor que controlava tudo e tudo. Então aqui. Em uma versão do sistema, uma vulnerabilidade apareceu repentinamente! Como exatamente os pesquisadores receberam as amostras de código do hipervisor não me é conhecido com certeza. Mas o fato é que, no final de 2006, os pesquisadores lançaram código não assinado no Xbox 360 e, no início de 2007, a vulnerabilidade foi corrigida pelos desenvolvedores:

Timeline:
Oct 31, 2006 — release of 4532 kernel, which is the first version containing the bug
Nov 16, 2006 — proof of concept completed; unsigned code running in hypervisor context
Nov 30, 2006 — release of 4548 kernel, bug still not fixed
Dec 15, 2006 — first attempt to contact vendor to report bug
Dec 30, 2006 — public demonstration
Jan 03, 2007 — vendor contact established, full details disclosed
Jan 09, 2007 — vendor releases patch
Feb 28, 2007 — full public release

O hypervisor tinha um recurso - ao contrário do restante do código, ele foi executado não no espaço de endereço virtual, mas no físico (Modo Real). A transmissão não foi usada, as chamadas foram feitas diretamente (endereços no formato 0x00000000'xxxxxx). Isso foi feito por velocidade ou por simplicidade ... E aqui estava um recurso do espaço de endereço do Xbox 360.

O modo de acesso à memória era determinado por seu endereço físico. Nomeadamente, os bits mais significativos do endereço tinham um propósito oficial. Por exemplo, o endereço 0x00000 0 00'0000201C significava acesso direto ao endereço 0x201C e 0x00000 1 00'0000201C significava que era necessário descriptografar e verificar a integridade em tempo real ao ler o mesmo endereço físico 0x201C.

Portanto, para que a execução seja executada com a criptografia e a proteção ativadas, é necessário consultar endereços como 0x00000 1 00'xxxxxxxx. Somente então o módulo de hardware incluiu mecanismos de proteção. Portanto, no nível do hardware, o bit desejado foi adicionado automaticamente (o registro HRMOR especial foi responsável por isso - Hypervisor Real Mode Offset Register)!

Mais uma vez - assim que o hipervisor acessa um endereço como 0x00000 0 00'xxxxxxxx, a MMU altera automaticamente esse endereço para 0x00000 1 00'xxxxxxxx, incluindo criptografia e proteção! Portanto, qualquer tentativa de executar o código "diretamente" da memória física, sem proteção e criptografia, está fadada ao fracasso ... ou não?

Vejamos o código vulnerável da versão do hypervisor 4532:

// %r0 – 13D8: cmplwi %r0, 0x61 // ID 13DC: bge illegal_syscall // 0x61, , ... 13F0: rldicr %r1, %r0, 2, 61 // 4 13F4: lwz %r4, syscall_table(%r1) // 13F8: mtlr %r4 // lr ... 1414: blrl //

Veja o esquilo? Mas ele é! A instrução Cmplwi funciona com valores de 32 bits , mas rldicr - com 64 bits ! Ou seja, podemos passar o valor 0x20000000'0000002A como o número de chamada do sistema, ele passará no teste (porque a parte inferior de 32 bits é menor que 0x61) e, como resultado, em vez do endereço 0x10EC, o endereço do manipulador será retirado de 0x80000000'000010EC!

E então, como eles dizem, observe suas mãos. Os bits mais significativos do endereço não são iguais a zero, respectivamente, HRMOR não é adicionado ! E como o espaço de endereço real é de 32 bits, o conjunto de 63 bits por nós é simplesmente ignorado. Redirecionamos o hypervisor para memória não criptografada e insegura, simplesmente enviando um número de chamada do sistema incorreto!

Mas espere, para que haja para onde pular, precisamos ser capazes de gravar nossos dados na memória física. Como conseguir isso?

É aqui que o segundo fator entra em jogo - a GPU no Xbox 360 era inteligente, até inteligente demais . Ele deu suporte a uma instrução especial de sombreador, o MemExport, para carregar dados de geometria na memória física. Ou seja, você pode compilar o shader, executá-lo na GPU e, assim, gravar qualquer coisa em qualquer lugar! E o mais importante, os shaders não foram assinados; se você modificar o disco do jogo de alguma forma, poderá substituir facilmente o código do shader.

Uma pergunta permaneceu. Como substituir o código do sombreador no disco do jogo? E aqui cortar a unidade de DVD do console foi muito útil. Nós escrevemos um shader, substituímos na imagem do jogo, gravamos em um disco e lançamos o Linux!

Sim, para executá-lo, tive que iniciar o jogo toda vez, esperar a exploração funcionar, colocar o disco de inicialização no Linux, mas isso era pelo menos alguma coisa!

Como já mencionado, a Microsoft lançou uma atualização do sistema na qual corrigiam a vulnerabilidade do hypervisor. Mas e se você retornar um kernel vulnerável?

Downgrade!

Em geral, a arquitetura do Xbox 360 foi estabelecida como mecanismos de proteção contra o downgrade. Nos fusíveis de hardware do processador, toda vez que um pouco era gravado durante a atualização (valor de bloqueio, LDV aumentava) e se esse LDV não correspondia nos fusíveis e no sistema, o console simplesmente não era iniciado.

Considere a estrutura do carregador de inicialização do Xbox 360, a saber, “Seções do carregador de inicialização”:

Pode-se ver que existem vários conjuntos de gerenciadores de inicialização na imagem, cada um dos quais corresponde a algum LDV. No exemplo, estes são 1888 para LDV 0, 16767 para LDV 3 e 16756 para LDV 2

Portanto, todas as atualizações do próprio sistema foram registradas nas seções 6BL / 7BL e simplesmente “aplicadas” como patches no “núcleo” 5BL 1888 de base . Mas que conjunto de correções a aplicar foi selecionado de acordo com o LDV prescrito nos cabeçalhos dos fusíveis e do carregador de inicialização! E apenas em 5BL, o cabeçalho pode ser modificado, com um grande MAS - o cabeçalho foi verificado com relação à soma de hash HMAC-SHA-1 registrada nele. E foi verificado pelo memcmp comum .

Se você ainda não entende para onde as coisas estão indo, aqui você conseguiu aplicar um ataque de tempo (Timing Attack). A função memcmp padrão completa a comparação imediatamente após a primeira discrepância. Portanto, alterando o primeiro byte do hash e detectando o tempo de execução do memcmp, você pode selecionar o valor desejado (com ele, o tempo de verificação aumentará). Continuando, você pode pegar todos os bytes da soma de hash!

Para a medição, o barramento de depuração POST_OUT foi usado. Funciona como um PC, em diferentes momentos do carregamento, um valor de byte é exibido, pelo qual você pode avaliar onde o processador está em execução no momento e qual erro ocorreu. De fato, são 8 pontos na placa-mãe, cada um dos quais é responsável por um valor específico:

Depois de soldar esses pontos, você pode apenas medir o tempo de execução de cada um dos estágios de download e verificar se ocorreu um erro.

Todo o processo de seleção de hash leva cerca de uma hora:

Como resultado, obtemos uma imagem na qual o LDV atual está instalado para o kernel principal, por causa do qual nenhum patch é aplicado e a versão mais antiga do sistema 1888 é lançada! De onde já é possível atualizar para a versão vulnerável 4532:

Obviamente, a Microsoft corrigiu essa vulnerabilidade atualizando o primeiro gerenciador de inicialização atualizado (2BL, "CB") e queimando o fusível CBLDV, o que tornava impossível o downgrade novamente. Agora, em vez de memcmp, sua versão segura foi usada, com o mesmo tempo de execução, independentemente dos valores de entrada.

JTAG Hack!

Mas aqui, os pesquisadores não desistiram e encontraram uma brecha. Sim, de tal forma que os desenvolvedores nem podiam imaginar.

No modo normal de operação do console, todos os gerenciadores de inicialização são conectados entre si em uma cadeia. Como resultado, a descriptografia de cada carregador de inicialização depende da área de dados no cabeçalho do carregador de inicialização anterior (emparelhando dados). Além disso, a criptografia do código depende da chave exclusiva do processador, portanto você não pode obter e montar uma imagem de trabalho sem conhecer CPU_Key. Ou é possível?

No estágio de produção do console (quando a chave do processador ainda não foi queimada nos fusíveis), um modo especial de inicialização do Xbox 360 é usado quando o emparelhamento de dados é zero (zero-emparelhamento). E essa imagem (com um kernel vulnerável!) Pode ser executada em qualquer console sem nem mesmo saber a chave do processador!
Infelizmente, não haverá um lançamento completo; este erro ocorrerá aqui:

Ou seja, o jogo King Kong não pode ser iniciado, a exploração através de shaders não pode ser ativada ... Mas o kernel vulnerável já está começando! Talvez haja outra maneira de gravar a RAM? Descobriu-se que existe.

Para iniciantes, soldamos três GPIOs gratuitos do console sul do console nos pinos JTAG da GPU:

Em seguida, modificamos o firmware da ponte sul (é criptografada, mas não assinada) e coletamos a imagem com o kernel vulnerável. Então a mágica acontece:

Na inicialização, a ponte sul na GPU JTAG sobe no PCI Express e configura o controlador NAND
Agora, ao ler, o controlador NAND gravará dados na área de memória que precisamos
O núcleo do sistema inicia e informa a ponte sul que o sistema iniciou
A ponte sul puxa o controlador NAND, substituindo a RAM no lugar certo e explora a vulnerabilidade do hypervisor!
O controle é transferido para o nosso código, faça o que queremos

Em suma, eles fizeram tudo da mesma forma que no King Kong Shader Exploit, mas mais bacana - não há necessidade de iniciar o jogo e trocar de disco.

Com base no JTAG Hack, foram criadas versões modificadas do sistema - XBReboot, Freeboot, com verificação de assinatura desativada, onde piratas já estavam andando por aí. Os jogos podem ser lançados não apenas a partir de unidades e discos USB, mas também através do protocolo SMB diretamente de um computador.

É importante ressaltar que um hack de sistema completo deu uma chance àqueles que perderam a chave do DVD e não puderam reproduzir - tendo a chave do processador, não foi difícil extrair a chave do DVD.

Obviamente, aqui a Microsoft fechou rapidamente a vulnerabilidade, atualizando novamente o 2BL e aumentando o valor do CBLDV. Com isso, terminou o épico do hypervisor vulnerável, as pessoas corriam para comprar os restos dos consoles "compatíveis com JTAG" nas lojas - todos queriam brincar com pen drives sem problemas. Foram realizadas discussões em fóruns sobre quais pacotes com data de lançamento são adequados para hackers ...

O tópico de modificações no sistema Xbox 360 parou por quase dois anos, mas o tema do firmware continuou a se desenvolver. E apenas no firmware dos drives LiteOn, a mais extensa batalha entre pesquisadores e Microsoft estourou. Mas mais sobre isso no próximo artigo :)

Links:

relatório do GoogleTechTalks
King Kong Hack
Timack Attack
JTAG / SMC Hack

Proteção e Hacking do Xbox 360, Parte 1
Proteção e Hacking do Xbox 360 , Parte 2
Proteção e Hacking do Xbox 360, Parte 3

PS Qualquer pessoa interessada em detalhes, responderei a quaisquer perguntas sobre o tópico nos comentários!