🥠 ⛸️ 🎥 Protegendo e invadindo o Xbox 360 (parte 3) 🏴󠁧󠁢󠁷󠁬󠁳󠁿 👨🏻‍💼 👩🏽‍🤝‍👨🏿

Em 2011, 6 anos após o lançamento do console Xbox 360, os pesquisadores descobriram um fato interessante - se o sinal "0" for enviado para a saída RESET do processador central por um período muito curto, o processador não redefinirá seu estado (como deveria ser), mas sim mude seu comportamento! Com base nesse "recurso", o Reset Glitch Hack (RGH) foi desenvolvido , com a ajuda da qual foi possível comprometer completamente a proteção do Xbox 360, executar código não assinado, abrindo assim o caminho para invadir o próprio sistema e derrotar as unidades DG-16D5S "inquebráveis" .

Vamos dar uma olhada em como o RGH funcionou, como os desenvolvedores tentaram consertar um buraco e como esses patches conseguiram se locomover!

O que é um ataque de falha?

O processador é bem burro, não importa o que os profissionais de marketing digam. Todo o código de alto nível escrito pelos programadores é reduzido à execução de comandos simples - aritmética com números, dados em movimento, saltos condicionais e incondicionais. Supõe-se que o processador sempre execute esses comandos sem erros e o resultado corresponda à documentação.

De fato, compilar o código

i = i + 2;

você confia no fato de que o valor da variável i aumentará exatamente 2, sem nem mesmo perceber como poderia ser.

Os ataques de falha violam essa confiança - o objetivo deles é garantir que o processador seja "buggy" e se comporte errado. Existem várias maneiras de "falha" do processador, por exemplo:

Reduzir a tensão da CPU
Para dar um impulso extra à frequência de referência da CPU
"Shine" na porcentagem de radiação

Existem dispositivos especiais para realizar esses ataques - por exemplo, o ChipWhisperer oferece uma ampla gama de ataques em frequência e potência:

No caso do Xbox 360, uma “falha” ocorre como resultado da exposição à linha RESET. O processador inicia o procedimento de redefinição, mas devido à curta duração do sinal, ele não tem tempo para concluí-lo e continua a funcionar como se nada tivesse acontecido. Mas apenas por este breve momento, enquanto o sinal RESET está ativo, seu comportamento muda!

Processador de falhas

A proteção do Xbox 360 repousa nos gerenciadores de inicialização que se checam em uma cadeia. Por fim, a verificação em cada estágio se resume a chamar a função de comparar a soma de hash com o "padrão". Foi então que eles aplicaram o ataque de falha, forçando o processador a ignorar a incompatibilidade. Um impulso na linha RESET imediatamente após chamar o procedimento memcmp força o processador a "ir" ao longo de outra ramificação e continuar carregando, mesmo se a soma de hash estiver incorreta:

O melhor local para atacar foi encontrado no gerenciador de inicialização do segundo estágio, "CB". Os estágios posteriores são mais difíceis de atacar (e fáceis de corrigir), mas no primeiro estágio de carregamento (“1BL”, ROM) o ataque falhou devido a uma construção ligeiramente diferente do código do programa.

Parece simples, mas, de fato, ao tentar realizar um ataque, muitas nuances foram descobertas.

Primeiro, para realizar com sucesso um ataque de falha, é necessário determinar com muita precisão o momento em que um pulso RESET deve ser aplicado. Se você cometer um erro pelo menos por um microssegundo, envie um impulso muito curto ou muito longo, o ataque não funcionará.

Felizmente, no Xbox 360, cada etapa de inicialização é acompanhada por uma alteração no valor no barramento de depuração POST_OUT. Além disso, a saída de depuração é tão frequentemente organizada que um novo valor POST é definido imediatamente antes de comparar a soma de hash:

Portanto, fechar o local da saída de depuração do site do ataque foi um gatilho extremamente conveniente. POST_OUT é um barramento paralelo e é enviado para 8 locais de teste na placa de circuito impresso, sendo cada um deles responsável por um dos bits do valor. Foi até possível simplificar o esquema de conexão usando apenas um bit e contando o número de alterações em seu estado desde a inicialização do sistema:

Também ocorreu que, devido à alta frequência do processador, é quase impossível chegar ao momento certo em termos de precisão e duração. O tempo de exposição deve ser muito curto, na ordem do tempo de execução de uma instrução pelo processador. Porém, quanto mais lento o processador roda, mais longo o intervalo de tempo nos convém. Portanto, tomamos e desaceleramos o processador!

Em um PC comum, a frequência da CPU é definida como o produto da frequência externa e “multiplicadora” de referência:

Portanto, no Xbox 360, linhas externas da frequência de referência são adequadas para o processador e, dentro dessa frequência, é multiplicado pelo PLL . E nas antigas revisões "grossas" do decodificador, o mecanismo PLL pode ser desativado, tornando o processador mais lento em 128 vezes:

Nas versões “Slim”, o truque PLL não pode ser realizado (a linha não está separada no quadro) e, como não podemos influenciar o fator “Slim”, reduziremos a frequência “referência”!

É gerado pelo chip HANA e pode ser configurado através do barramento I2C:

Infelizmente, não foi possível reduzir muito, "em baixas velocidades", a frequência final do processador começou a "nadar" fortemente, o que reduziu as chances de sucesso. A opção mais estável foi uma desaceleração de 3,17 vezes. Não 128 vezes, mas pelo menos alguma coisa.

Todos? Não, não todos. Está longe de ser verdade que o ataque funcionará pela primeira vez (especialmente no Slim). E se a inicialização falhar, o prefixo será reiniciado e tentará iniciar novamente. Apenas cinco tentativas são iniciadas, após o que o prefixo para e começa a piscar o "anel vermelho da morte". Portanto, também corrigimos o firmware da ponte sul (SMC) para que ele não sofra com o lixo e reinicializamos o prefixo até que fique azul:

Então, obtemos o algoritmo:

patch SMC
diminuir a porcentagem (via PLL ou I2C)
aguardando um gatilho POST
aguardando N microssegundos
enviar impulso para RESET
acelerar por cento de volta

Para maior precisão dos cálculos, tomamos a frequência do mesmo HANA (48 MHz):

E obtemos esse design com base no CPLD Xilinx XC2C64A barato:

Não se esqueça de shamanize com o comprimento e a localização da fiação no RESET (preste atenção à "bobina" na parte inferior da foto) e avance, esperando que o lançamento dê certo em um minuto.

Mas isso é apenas no lado do hardware. Como corrigimos o bootloader e preenchemos nosso código?

Carregadores de patches

Como mencionei, o carregador de inicialização de segundo nível, "CB", está sendo atacado. Este gerenciador de inicialização é criptografado com uma chave fixa, a mesma para todos os consoles, mas apenas o "CB" não pode ser modificado, apenas o atacamos. Mas o próximo já está criptografado com uma chave de CPU, exclusiva para cada decodificador. E para modificá-lo, você precisa conhecer essa chave ...
Ou não?

Nas antigas revisões "grossas" do Xbox 360, o chamado modo "Zero-Pairing", usado no estágio de produção do console, era suportado no carregador CB. O cabeçalho de cada carregador de inicialização no deslocamento 0x10 contém um conjunto de dados de emparelhamento aleatório usado como parte da chave para descriptografia. E se esse conjunto de dados consistisse inteiramente em zeros (“Zero-Pairing”), a chave do processador era ignorada e uma chave fixa e zero era usada!

Com esse truque, foi possível montar uma imagem com o “CB” original, criptografar o próximo carregador de inicialização, “CD” (com seu próprio código) com uma chave zero e executá-la usando RGH!

Nos consoles, "Slim" encerrou esse truque, removendo o modo "Zero-Pairing" e dividindo o "CB" em duas partes. Aqui, "CB" foi dividido em um "CB_A" muito simples e pequeno e criptografado pela chave do processador "CB_B":

Mas a criptografia com o algoritmo RC4 (ou seja, CB_B é criptografada com esse algoritmo) tem uma peculiaridade. No processo de criptografia baseada na chave, é gerado um fluxo de dados pseudo-aleatório, que é “adicionado” binário (operação 'exclusiva ou', 'xor') com os dados de origem. Ao descriptografar, consequentemente, acontece o mesmo, adicionando com o mesmo fluxo pseudo-aleatório retorna os dados ao seu valor original:

Mas a operação de adição binária é comutativa e associativa, o que significa que podemos modificar os dados criptografados sem conhecer a chave, apenas para xor 'e o código criptografado com o patch de que precisamos!

Como resultado, podemos criptografar “CB_A”, corrigir o “CB_B” criptografado (para que ele não execute a descriptografia) e colocar em texto simples “CD” com seu código!

Resumindo, se você montar tudo, o lançamento será mais ou menos assim:
(XeLL é o gerenciador de inicialização do homebrew, Linux, e também mostra as chaves da CPU)

Microsoft revida

Obviamente, a Microsoft tentou consertar tudo.

Na nova atualização do sistema, todos os consoles antigos foram transferidos para uma inicialização "separada" de "CB_A" e "CB_B", fechando assim finalmente o modo "Zero-Emparelhado". No Slim, os gerenciadores de inicialização também foram atualizados. Os novos gerenciadores de inicialização foram seriamente modificados para proteger contra o RGH, a maior ênfase foi colocada na proteção do CB_A:

Saída de depuração completamente removida no POST
A verificação de hash foi refeita e duplicada para garantir a confiabilidade
No código, sleep () foi definido por um tempo aleatório (dependendo da chave da CPU !!)
Adicionada verificação de fusão CBLDV para revogar CB_A

A lista de inovações não deixa chance para a RGH. Mas vamos prestar atenção ao último item da lista - antes disso, não havia verificação de fusão no CB_A! Falha fatal. Além disso, como lembramos, a chave do processador não está envolvida na decodificação de "CB_A". Isso significa que o carregador CB_A vulnerável ao RGH pode ser iniciado em qualquer console e isso não pode ser proibido.

Mas, para começar algo com a ajuda desse "CB_A" vulnerável, você precisa se esquivar um pouco. Se não soubermos a chave da CPU, tudo o que resta para nós é corrigir o "CB_B" existente. Mas e se, em vez de modificar seções individuais, sobrescrevermos completamente o gerenciador de inicialização inteiro? E, por causa disso, "escreva" o antigo carregador de inicialização, que já sabemos corrigir, para substituir o novo? Então eles fizeram:

Criptografamos o CB_A vulnerável da mesma maneira que na imagem original
XOR nosso CB_B com o novo, obtendo a "diferença"
Colocamos no "CB_B" criptografado!

Tudo, novamente, sem saber a chave, substituímos com êxito o conteúdo criptografado e também colocamos o vulnerável carregador de inicialização. Consoles hackear, Microsoft são surpreendidos.

Os desenvolvedores trabalharam duro e, na próxima atualização do sistema ... alteraram levemente o método de criptografia "CB_B", agora a chave de criptografia também se tornou dependente da versão do "CB_A":

Agora, ao tentar xor 'e empurrar os dados para o vulnerável "CB_A" da versão antiga, o carregador de inicialização descriptografou o lixo devido a diferenças nas chaves. E o novo gerenciador de inicialização não pode ser invadido, ele está bem protegido contra ataques glich. Até agora, vitória para a Microsoft!

Corona lança problemas

Enquanto isso, uma nova revisão do Xbox 360, Corona, entrou no mercado e trouxe problemas para modders:

Não há fichas suficientes no tabuleiro, você consegue encontrá-lo? É isso mesmo, o chip HANA estava "escondido" na ponte sul. Não há outro lugar para obter a frequência de 48 MHz para o chip mod, os comandos de desaceleração I2C anteriores não funcionam. Mas o que é isso, o flash NAND de 16 MB, que serviu como armazenamento do sistema Xbox 360 durante todos esses anos, foi traiçoeiramente substituído por um chip de 4 GB com uma interface eMMC! (Verdadeiro, apenas na versão mais barata do console, mas ainda assim):

Mas nada, tudo foi resolvido. Nós descobrimos como ler / gravar memória flash através de um leitor de cartão:

Encontrados novos comandos de desaceleração I2C, um oscilador de cristal externo de 48 MHz substituiu o HANA:

Scripts de compilação concluídos, suporte adicionado para 4 GB NAND ...

Mas a Microsoft continuou colocando palitos nas rodas. Por exemplo, nas novas placas, alguns resistores desapareceram, sem os quais o chip mod parou de funcionar:

É verdade que isso foi corrigido com a instalação de jumpers com um ferro de solda:

As coisas ficaram mais sérias quando as faixas POST_OUT desapareceram do quadro:

Mas aqui a Microsoft não teve sorte, as “bolas” de CPU necessárias para o RGH estavam na linha extrema:

E, é claro, eles conseguiram se conectar a eles. Primeiro, os mais protetores, perfurando levemente a borda do processador e soldando diretamente a bola com a fiação:

E então os chineses lançaram uma estrutura com uma agulha com mola, exatamente apoiada na bola, e o problema foi resolvido para todos os outros:

A última fronteira

Depois de derrotarmos a “coroa”, houve um problema - novas versões do sistema não cederam ao hacking. Para iniciar o RGH, você precisa conhecer a chave da CPU e, para descobrir a chave da CPU, precisa executar o RGH pelo menos uma vez. O problema da galinha e dos ovos em geral.

E então surgiu um pensamento - e não apenas verificamos com autenticação "falha", mas também pularemos a descriptografia! Se der certo, não precisamos saber a chave, coloque "CB_B" bem claro, só isso. Essa ideia formou a base do Double Glitch Hack (DGX):

Esse chip "buggy" a porcentagem duas vezes, o primeiro pulso pulou a fase de descriptografia do gerenciador de inicialização e o segundo pulso pulou a autenticação. Funcionou muito menos estável, já que era necessário pelo menos um lançamento bem-sucedido - então obtemos a chave da CPU e procedemos como antes.

O DGX não foi relevante por muito tempo, depois de três meses os chineses lançaram o “DGX RIP” com imagens que rodam em qualquer decodificador, trabalhavam com o RGH padrão e, é claro, começaram muito mais estáveis:

Essas imagens continham uma versão especial do carregador de inicialização CB_A usada na produção do Xbox 360 e, de fato, é um análogo completo do bom e velho modo "Zero-Pairing". Em vez da chave do processador, este "CB_A_mfg" descriptografou "CB_B" com uma chave nula fixa:

E aqui está a Microsoft. Nesta versão de "serviço" do "CB_A" também não havia verificação de fusão e era impossível bani-la. Foi o suficiente para gravar a imagem de acordo com a revisão do Xbox 360, soldar o chip - e tudo funcionou.

Winchester!

O RGH foi totalmente corrigido apenas na nova revisão do console, codinome Winchester. Pela primeira vez, os processadores CPU e GPU combinados em um chip, a placa foi simplificada o máximo possível:

As faixas POST_OUT não foram apenas removidas. Mesmo se você soldar a plataforma sob o processador:

E mesmo se você soldar o processador em uma versão especial da placa para desenvolvedores, o XDK, onde essas faixas ainda estão lá:

Em POST_OUT, apenas um pulso é visível quando o console é iniciado. Ônibus bloqueado:

Além disso, ele é bloqueado apenas na fase de produção. Se você pegar um processador "limpo" de uma fábrica onde ainda não queimou os fusíveis, POST_OUT funcionará nele!

Mas o RGH não funciona mais. Não importa como você tente dar um pulso de RESET, o processador executa uma redefinição corretamente ou ignora seu sinal devido à sua duração muito curta. Aparentemente, um módulo lógico especial foi adicionado ao processador, filtrando a linha RESET e, finalmente, corrigindo o erro de hardware.

Post Scriptum

Acontece que é impossível invadir a última revisão do Xbox 360?

Sim e não. No momento, existe apenas uma maneira conhecida de executar um sistema modificado nas revisões do Winchester.

O kit de desenvolvimento de software (XDK) contém várias chaves privadas para assinar código compilado. E assim, entre eles, a chave de assinatura "shadowboot", um gerenciador de inicialização de terceiro nível para sistemas XDK, estava desordenada. E com ele, você pode coletar uma imagem assinada legítima com firmware modificado. Apenas trabalhe em consoles comuns de "loja", ele não o fará. Precisamos de um processador com a versão XDK do console ou de uma CPU "limpa" com fusíveis não fundidos (você pode vê-lo no Aliexpress):

E somente então você terá a oportunidade de contemplar essa inscrição nas "informações do sistema" do shell personalizado:

E isso é tudo! Como sempre, estou pronto para responder às suas perguntas nos comentários :)

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

Protegendo e invadindo o Xbox 360 (parte 3)