|
      |
Você esta em: PEÇAS XBOX 360/XBOX360 SLIM › X360 GLITCH
    Explicação técnicaO Xbox 360 redefinir hackear falha Introdução / alguns fatos importantes O processador começa a rodar código de ROM (1bl), que então começa a carregar uma assinatura RSA RC4 e crypted pedaço de código a partir de NAND (CB). CB, em seguida, inicializa o mecanismo de segurança do processador, sua tarefa será a de fazer a criptografia em tempo real e verificação de hash de memória DRAM física. A partir do que encontramos, ele está usando AES128 para criptografia e forte (Toeplitz?) Hashing. A criptografia é diferente a cada inicialização, porque é semeada, pelo menos, de: - Um hash do fuseset inteiro. - O valor base de tempo do contador. - Um valor verdadeiramente aleatório que vem do gerador de números aleatórios hardware o processador incorpora. em gorduras, que RNG podem ser eletronicamente desativada, mas há um cheque de "aparente aleatoriedade" (apenas uma contagem de 1 bits) no CB, ele apenas espera por um número aparentemente adequado aleatória. CB pode então executar algum tipo de bytecode simples baseado mecanismo de software, cuja tarefa será principalmente para inicializar DRAM, CB pode, então, carregar o bootloader próxima (CD) de NAND para ele, e executá-lo. Basicamente, CD vai carregar um kernel base a partir da NAND, patch-lo e executá-lo. Isso kernel contém um pequeno pedaço privilegiado do código (hypervisor), quando o console é executado, este é o único código que teria direito o suficiente para rodar código não assinado. Em versões do kernel 4532/4548, uma falha crítica em que apareceu, e todos os conhecidos 360 hacks necessários para executar um dos kernels e explorar essa falha para rodar código não assinado. Em 360 atuais, CD contém um hash dos dois núcleos e vai parar o processo de inicialização se você tentar carregá-los. O hypervisor é um pedaço relativamente pequeno de código para verificar se há falhas e, aparentemente, não os mais novos tem todas as falhas que poderiam permitir a execução de código não assinado. Por outro lado, tmbinc disse que o 360 não foi projetada para resistir a ataques hardware certo como o ataque de temporização e "glitching". Glitching aqui é basicamente o processo de desencadear erros de processador por meio eletrônico. Esta é a maneira que usamos para ser capaz de executar código não assinado. redefinir A falha em poucas palavras Descobrimos que, enviando um pulso de reset minúsculo para o processador enquanto ele é retardado não redefini-la, mas sim muda a forma como o código é executado, parece que é muito eficiente em fazer bootloaders memcmp funções sempre retornam "nenhuma diferença". memcmp é freqüentemente usado para verificar o hash SHA próxima bootloader contra um armazenados, permitindo que ele seja executado se eles são os mesmos. Assim, podemos colocar um bootloader que não verificação hash em NAND, glitch o anterior e que será executado bootloader, permitindo que o código quase todo para ser executado. Detalhes para o corte de gordura Em gorduras, o bootloader que falha é CB, para que possamos executar o CD que queremos. cjak descobriram que, ao afirmar o sinal CPU_PLL_BYPASS, o relógio da CPU é desacelerado muito, há um ponto de teste na placa-mãe que é uma fração da velocidade da CPU , é 200Mhz, quando o traço é executado, 66.6Mhz, quando as botas console, e 520Khz, quando o sinal é afirmado. Por isso, fica assim: - Nós afirmamos CPU_PLL_BYPASS em torno do código POST 36 (hex). - Vamos esperar para começar a 39 POST (POST 39 é o memcmp entre hash armazenado e hash da imagem), e iniciar um contador. - Quando esse contador chegou a um valor preciso (é muitas vezes cerca de 62% de todo o comprimento do POST 39), enviamos um pulso de 100ns em CPU_RESET. - Vamos esperar algum tempo e então nós deassert CPU_PLL_BYPASS. - A velocidade de cpu vai voltar ao normal, e com um pouco de sorte, em vez de ficar AD erro POST, o processo de inicialização continua e CB funciona o nosso CD personalizado. NAND A CB contém um zero-emparelhado , a nossa carga útil em um CD personalizado, e uma imagem modificada SMC. A falha não é fiável por natureza, nós usamos uma imagem modificada SMC que reinicia infinitamente (ie imagens de reiniciar 5 vezes e depois ir RROD) até que o console já foi iniciado corretamente. Em maioria dos casos, a falha sucede em menos de 30 segundos desde a ligação dessa maneira. Detalhes para o corte fino O bootloader que falha é CB_A, para que possamos executar o CB_B que queremos. On slims, não fomos capazes de encontrar uma trilha placa-mãe para CPU_PLL_BYPASS. Nossa primeira idéia foi remover o cristal 27Mhz mestre 360 e gerar nosso próprio relógio, mas ao invés foi uma modificação difícil e não deu bons resultados. Em seguida, olhou para outras formas de retardar o relógio da CPU no chão e percebeu que o chip HANA tinha configurável registra PLL para o relógio 100Mhz que alimenta pares diferenciais CPU e GPU. Aparentemente, os registradores são escritos pelo SMC através de um barramento I2C. bus I2C podem ser livremente acessados, é ainda disponível em um cabeçalho (J2C3). Assim o chip HANA agora será a nossa arma de escolha para diminuir a CPU para baixo Então fica assim: - Nós enviamos um comando para o i2c HANA para abrandar o CPU no POST código D8. - Vamos esperar para começar POST DA (POST DA é a memcmp entre hash armazenado e hash da imagem), e iniciar um contador. - Quando o contador atingiu um valor preciso, enviamos um pulso de 20ns em CPU_RESET. - Vamos esperar algum tempo e depois nós enviamos um comando para o i2c HANA para restaurar clock da CPU regular. - A velocidade de cpu vai voltar ao normal, e com um pouco de sorte, . ao invés de ficar POST erro F2, o processo de inicialização continua e CB_A corre nossa CB_B personalizado CB_B Quando começa, DRAM não é inicializado assim optou-se por aplicar apenas alguns remendos a ele para que ele possa executar qualquer CD, as manchas são: - Sempre ativar o modo zero-pareado, para que possamos usar uma imagem modificada SMC. - Não descriptografar CD, em vez esperar um CD plaintext em NAND. . - Não pare o processo de inicialização se de hash CD não é bom CB_B RC4 é crypted, a chave vem a chave de CPU, assim como nós remendo CB_B sem conhecer a chave CPU? RC4 é basicamente: crypted = plaintext xor pseudo-random-keystream Então, se nós sabemos plaintext e crypted, podemos obter o keystream , e com o keystream, podemos criptografar o nosso próprio código. É assim que: adivinhou-pseudo-random-keystream = crypted xor plaintext new-crypted = adivinhou-pseudo-random-keystream xor plaintext-patch Você poderia pensar que há um problema ovo e da galinha, como chegamos plaintext em primeiro lugar ? Fácil: tivemos plaintext CBS de consoles de gordura, e achamos que os primeiros bytes de código seria o mesmo que o CB_B novo, para que pudéssemos criptografar um pequeno pedaço de código para despejar a chave CPU e descriptografar CB_B O NAND contém CB_A, um CB_B remendado, a nossa carga útil em um costume plaintext CD, e uma imagem modificada SMC. A imagem SMC é modificada para ter reiniciar infinito, e para evitar que periodicamente envia comandos I2C enquanto enviamos nosso. Agora, talvez você paraíso ' t percebeu ainda, mas CB_A não contém controlos de fusíveis de revogação, por isso é um hack unpatchable! Advertências Nada é perfeito, por isso há algumas ressalvas para que o hack: - Mesmo na falha que encontramos é bastante confiável (taxa de sucesso de 25% por tentativa em média), pode demorar até alguns minutos para inicializar código não assinado. - Essa taxa de sucesso parece depender de algo como o hash do bootloader modificado que deseja executar (CD para gorduras e CB_B para slims). - Ela exige hardware precisa e rápida para poder enviar o pulso de reset. Nossa implementação atual Usamos um Xilinx chip (xc2c64a), porque é rápido, preciso, atualizável, barata e pode trabalhar com dois níveis de tensão diferentes ao mesmo tempo. Usamos o relógio 48Mhz espera do 360 para o contador do pulso aleatório. Para o corte slim, o contador ainda é executado em 96MHz (incrementado a ascensão e queda bordas do relógio) O código CPLD é escrito em VHDL. Precisamos dele para estar ciente do código POST atual, nossas implementações usado pela primeira vez todo o POST 8 bits de porta para isso, mas agora somos capazes de detectar as mudanças de apenas 1 bit POST, tornando mais fácil a fiação.Conclusão Nós tentamos não incluir qualquer código direitos autorais MS nas ferramentas de corte liberado. O objetivo deste hack é para executar Xell e outros softwares livres, I (GliGli) não fez isso para promover a pirataria ou qualquer coisa relacionada, eu só quero poder para fazer o que quiser com o hardware que eu comprei, incluindo a execução meu próprio código nativo nele.  X360Glitch
|
