Arquitetura do PlayStation 3

Tudo o que você acabou de ler precisa ser protegido de alguma forma contra o acesso "não autorizado". A seguir, você terá uma visão geral de como a Sony lidou com isso.

Resumo da base de segurança

Várias partes do console já fornecem recursos de segurança que não exigem nenhuma implementação manual no software:

• O SysCon, o chip proprietário obscuro (brevemente mencionado no processo de inicialização), controla as linhas de alimentação do Cell, do RSX e do Southbridge. Sua memória EEPROM contém registros que são lidos pelos módulos do sistema operacional para determinar quais funções estão habilitadas e quais não estão .
  • Embora eu use a palavra "obscuro", o SysCon é apenas um microcontrolador, seja um ARM7TDMI-S comercial (isso mesmo, o PS3 compartilha parte de seu DNA com o Game Boy Advance e até mesmo com as últimas revisões do PS2), aprimorado com suporte ao MagicGate, ou uma variante personalizada NEC 78KOR . O firmware interno do SysCon é o mais intrigante.
  • O SysCon e o Cell se comunicam entre si usando uma interface serial (SPI) que se conecta ao componente TEST do Cell . O TEST fornece muitas funções de depuração no Cell, embora o SysCon só se conecte à porta de "lógica pervasiva", permitindo que o SysCon gerencie áreas como energia ou térmica .
• O Cell abriga uma memória ROM oculta que armazena rotinas de inicialização não criptografadas sem se preocupar com bisbilhoteiros.
• Os modos de privilégio do Cell e o modo isolado do SPE impedem que os programas acessem recursos não autorizados.
• O Southbridge criptografa perfeitamente o conteúdo do disco rígido usando AES.
• O subsistema Blu-ray é outra fortaleza protegida, e seu conteúdo de disco é criptografado usando uma chave encontrada na área de "marcas de ROM" do disco (inacessível por leitores convencionais) .

Além disso, a Sony implementou as seguintes proteções no software:

• Uma complexa cadeia de confiança começa com o boot ROM não criptografado do Cell e termina com uma interface gráfica de usuário (XMB) que carrega apenas binários criptografados (pela Sony) sob um Kernel e Hypervisor.
  • A cadeia de confiança implementa múltiplos algoritmos de criptografia, incluindo algoritmos assimétricos como RSA e ECDSA e sistemas simétricos como AES, combinados com HMAC e SHA-1 (para confirmar a integridade dos dados).
• Algumas chaves de criptografia são produzidas durante a fabricação do console, o que significa que, se o hackers encontrarem e vazarem essas chaves, elas não funcionarão em outros consoles. No entanto, isso tem um custo para a Sony, pois ela não pode corrigir o software criptografado com essas chaves depois que o console sai da fábrica.
  • Essas chaves especiais são usadas para o bootldr e o metldr (os estágios iniciais de inicialização).
• Os jogos devem chamar o Kernel para acessar o hardware, que por sua vez solicita o acesso ao Hypervisor. Essa "cebola de abstração" impede que as vulnerabilidades do jogo aumentem os privilégios, em teoria.

Derrota

Sabendo o quanto esse console é poderoso, você esperaria que os hackers se contentassem apenas com os recursos limitados do OtherOS? Creio que nem a Sony esperava, a empresa tentou proteger fortemente algumas áreas, enquanto deixou outras meio desprotegida, como os hackers demonstrariam mais tarde.

Vamos dar uma olhada em como algumas de suas fortalezas foram quebradas por hackers independentes de vários lugares do mundo. Tenha em mente que a comunidade de hacking do PS3 era muito ativa, com muitas ferramentas e documentação produzida a cada ano. Então, vou me concentrar em alguns marcos que abrem caminho para um influxo de conteúdo e desenvolvimento caseiro. Você pode encontrar mais informações em PS3History .

Contornando o Hypervisor

Em 2010, após três anos de relativa tranquilidade na cena hacking, a comunidade teve uma reviravolta para melhor. George Hotz, um hacker conhecido por desbloquear o primeiro modelo de iPhone (conhecido como "2G") para que pudesse funcionar com qualquer operadora (originalmente apenas na Cingular/AT&T), conseguiu ler e escrever áreas protegidas da memória sem ser interrompido pelo Hypervisor. Ele publicou seu exploit juntamente com um breve resumo em seu blog .

O exploit requer duas coisas: uma instalação do Linux rodando sob OtherOS (para execução de código arbitrário, porém limitado); e um glitcher externo conectado ao barramento XDR (interfaceando a memória RAM principal). Para resumir, o Hypervisor usa uma tabela hash, armazenada na memória RAM principal, para catalogar os endereços de memória com seus níveis de privilégio. Assim, evitando que os programas de usuário acessem os espaços de memória protegidos. O ataque funciona quebrando a integridade dessa tabela para poder escrever sobre ela e, em seguida, usar esse privilégio para modificar as entradas para conceder ao programa atual acesso a todos os cantos da memória.

Em resumo, Hotz descobriu que, sob o Linux/OtherOS, programas podem solicitar ao Hypervisor vários blocos de memória apontando para o mesmo endereço físico, mas se o programa desalocá-los enquanto houver interferência externa no barramento XDR (devido a um glitcher enviando pulsos elétricos), o processo de desalocação termina pela metade . Como consequência, a tabela hash do Hypervisor (residente na memória RAM) ainda contém uma entrada dos endereços alocados, mas ao mesmo tempo, ele pensa que esse espaço foi liberado. O exploit de Hotz prossegue solicitando mais blocos para que o Hypervisor estenda sua tabela com mais entradas, e o processo continua até que uma entrada da tabela hash se sobreponha à localização de memória do bloco que deveria desalocar. Como a tabela hash manteve a entrada antiga concedendo ao usuário acesso a esse endereço, o Hypervisor acaba dando ao usuário acesso para modificar uma entrada da tabela hash! Assim, o exploit altera a entrada para estender o acesso a todo o espaço de memória.

Embora esse exploit tenha exigido um ambiente de execução do Linux em OtherOS, ele foi um grande passo em direção a projetos de engenharia reversa e de pesquisa, já que os hackers agora podiam investigar áreas críticas do sistema que eram originalmente inacessíveis. Vale mencionar que, durante o mesmo período, a Sony lançou a atualização de software 3.21 removendo o OtherOS. Poderia-se pensar que isso desencorajaria os hackers de continuar seu trabalho, mas na verdade isso apenas os motivou a acelerá-lo ainda mais.

PS Jailbreak

Mais tarde em 2010, um grupo identificado como "PS Jailbreak" anunciou (e posteriormente lançou) uma solução única para executar Homebrew diretamente do shell nativo do console (XMB, sob o GameOS) sem a necessidade de manipular o hardware do console. Tudo isso para o desespero da Sony, que em logo seguiu o caminho legal para bloquear as vendas desse produto.

O "PS Jailbreak" consistia em um dispositivo USB que era conectado à porta USB frontal antes de ligar o console. O usuário teria que pressionar o botão power e logo depois o botão eject. Se a instruções fossem executadas com sucesso, os usuários veriam a interface normal do XMB, mas com a adição de uma opção "Install PKG" e alguns aplicativos Homebrew feitos para copiar jogos Blu-ray para o disco rígido e, em seguida, carregá-los.

Por baixo dos panos, esse dispositivo realiza uma enorme quantidade de trabalho, que pode ser dividido em dois grupos :

1. O exploit USB: uma vez que o console é ligado, o dispositivo engana o sistema fazendo-o pensar que está conectado a um hub USB de seis portas e, em seguida, realiza uma sequência complexa de comandos USB até chegar a uma sobrecarga de heap que escalar para o acesso ao Kernel do PS3 (nível 2), em seguida, procede à execução de um payload.
2. O Payload: este é outro pacote complexo que altera o shell original para habilitar funções ocultas disponíveis apenas em unidades de depuração (ou seja, a entrada "install PKG"), desativar a verificação de assinatura (para carregar qualquer módulo/pacote arbitrário); e redirecionar os comandos do Blu-ray para o disco rígido (para carregar jogos do disco rígido). O fato deste programa poder alterar tanto do nível do Kernel nos faz perguntar para que serve o Hypervisor?
   • Para complementar, mais tarde fui informado pelo M4j0r: "Curiosamente, não explora nem mesmo o código da Sony; esta parte do lv2 foi escrita pela Logitech e os desenvolvedores desse exploit podem ter tido acesso ao código-fonte (devido ao hack de 2008)." .

Posteriormente, este produto sofreu engenharia reversa por outras comunidades e, rapidamente, apareceram clones de código aberto (ou seja, PS Groove), no qual muitas restrições foram removidas (por exemplo, os usuários agora podiam desconectar o dispositivo depois que o exploit terminava). Algumas variantes foram até implantadas em uma calculadora da Texas Instruments . De qualquer forma, a Sony agiu rapidamente com a atualização de software 3.42 para remover esta mina de ouro , embora a porta para Homebrew já estivesse aberta.

Menções honrosas

Antes de finalmente falar sobre o grande vencedor da cena homebrew do PS3, deixe-me descrever-lhe alguns métodos que foram desenvolvidos na mesma época:

• O USB Jig: outro pendrive, dessa vez programado para enganar o console para entrar no Modo de Serviço de Fábrica, que é destinado apenas para manutenção do console por pessoal autorizado. O programa embutido no Jig replica o que a Sony fornece para seus engenheiros. A principal vantagem do modo de serviço é permitir um downgrade do console para uma versão compatível com o PSJailbreak. O payload também estava disponível na forma de um aplicativo Homebrew para o PSP . A Sony respondeu corrigindo o modo de serviço para tornar mais difícil restaurá-lo ao modo "normal" ou alterar o firmware dele, desencorajando os usuários a recorrerem ao modo de serviço.
• O Emulador de Disco Óptico (ODE, de Optical Disc Emulator): uma série de produtos de hardware que diferentes empresas (Cobra, E3, etc.) lançaram. Em vez de mexer no firmware do console, eles mexeram na interface SATA/PATA do Blu-ray. ODEs são placas que ficam entre a placa-mãe e a unidade de Blu-ray, agindo como intermediários que enganam o console, fazendo-o pensar que contém um jogo em disco válido, mas, na verdade, está carregando uma imagem de disco de uma unidade USB externa. A história de hackeamento do PS3 contém períodos logos de "inviolabilidade" em que não havia nenhum exploit de software disponível para os novos consoles. Assim, a um preço elevado, os ODEs vieram preencher essa lacuna.
• O Downgrader: à medida que a Sony continuava a mitigar as vulnerabilidades com mais atualizações de software, os usuários não tinham outra opção senão fazer downgrade para um firmware explorável. Assim, empresas como a E3 lançaram equipamentos especializados que podiam sobrescrever o sistema do console "à moda antiga". Ou seja, diretamente programando os chips NAND ou NOR. Por razões óbvias, esse método exigia mais habilidade e paciência em comparação com os métodos baseados em dispositivos USB.
• Vazamentos isolados: este é para fins de pesquisa, ao contrário de uma "funcionalidade" que o usuário verá (mas ainda é imperativo para futuros desenvolvimentos). De qualquer maneira, os dados de revogação (usados para listar certificados comprometidos) são analisados pelo lv2ldr, até aí tudo bem? Bem, foi descoberto que esse processo continha muitas vulnerabilidades. Em primeiro lugar e por alguma razão inexplicável, os dados de revogação podem ser escritos no espaço do usuário. Em segundo lugar, o analisador não realiza verificação de limites nos dados coletados (lá vamos nós novamente). Portanto, os hackers conseguiram criar dados personalizados de revogação que poderiam produzir um estouro de buffer e, em última instância, permitir que eles executassem código arbitrário no modo isolado da SPU. Isso permitiu que eles acessassem dados confidenciais (ou seja, chaves) que presumivelmente estavam protegidos do restante do sistema .

A quebra da criptografia

Assim como na saga do PSP, os exploits iniciais exigiam muito esforço e poderiam ser facilmente corrigidos pela Sony, resultando em um desvantajoso jogo de gato e rato. No entanto, como aconteceu com o PSP, era apenas uma questão de tempo antes que uma descoberta quebrasse a segurança fundamental deste sistema: sua cadeia de confiança.

Em 2011, George Hotz (junto com a equipe failOverflow) publicou outro avanço: as chaves privadas de criptografias que a Sony usa para assinar binários executados por metldr. Os binários carregados durante essa fase de inicialização são assinados com uma chave ECDSA. Sendo um sistema de criptografia assimétrica, isso significa que qualquer pessoa que possua a chave privada (Sony, e agora outros) pode criptografar e assinar binários, consequentemente, eles parecerão "autênticos" aos olhos do metldr. Como o metldr é o terceiro estágio de inicialização antes de carregar o lv1 (o Hypervisor), isso significa que os hackers poderão personalizar ou desenvolver seu próprio Hypervisor, Kernel e qualquer coisa abaixo dele. Além disso, todos os PlayStation 3 no mercado também pensarão que os binários personalizados são autênticos. No geral, um exploit do tipo Pandora completamente feito por software.

A descoberta dessa chave, que deveria ser computacionalmente inviável, é possível graças ao que é considerado um "erro" na implementação da Sony do algoritmo ECDSA. Para resumir, a fórmula matemática usada para o ECDSA usa um valor aleatório que a Sony nunca mudou em todos os arquivos de atualização que distribuiu , tornando aquele número uma constante, e deixando mais fácil descobrir as outras variáveis. Foi o que acabou acontecendo.

Os efeitos desta descoberta estão descritos nos próximos parágrafos.

A era dos Custom Firmware (CFW)

A quebra de segurança do metldr significou que agora todos podiam criar sistemas "oficiais" para o PS3, o que resultou no surgimento de diversas versões do GameOS que diferentes comunidades produziram com diversas personalizações. Esses sistemas eram modificações dos arquivos oficiais do firmware da Sony (que a Sony distribuía como atualizações) e reempacotados usando as suas chaves vazadas. Assim, eles podiam ser instalados em qualquer PS3. O resultado foi chamado de Custom Firmware (CFW) e tornou o método definitivo para hackear o console, até que a Sony respondeu com medidas mais rigorosas.

Minha instalação do CFW com "menu VSH" aberto. Essa versão (chamada "Rebug") também me permitiu transformar meu console em uma estação de depuração (observe o endereço IP no canto inferior direito, você precisa digitá-lo no depurador para se conectar a um processo em execução) e mexer em meus próprios homebrews.

Enquanto isso, muitos CFW apareceram na rede com muitos nomes (por exemplo, "Rebug", "Ferrox", etc.) e eles continham personalizações como :

• Desabilitar as verificações de assinatura em qualquer módulo instalado ou a ser instalado.
• Permitir a leitura e gravação (o clássico peek e poke) em qualquer endereço de memória, seja usando o Hypervisor (nível 1) ou o Kernel (nível 2).
• Ativar as funções de depuração ocultas para instalar módulos empacotados como arquivos "pkg". Estes arquivos não precisavam ser assinados com as chaves da Sony para funcionar dentro de um ambiente CFW.
• Permitir montar imagens de disco como um disco Blu-ray virtual.
• Restaurar o OtherOS e até mesmo aprimorá-lo removendo as restrições impostas pelo Hypervisor. O resultado foi chamado de OtherOS++.
• Escrever sobre o banco de dados do EEPROM do Syscon para permitir a instalação de qualquer versão de sistema escolhida. Isso também é conhecido como QA Toggling.
• Alterar o estilo do XMB (por exemplo, removendo o aviso de epilepsia, permitindo tirar capturas de tela em jogo, etc.).

Há também o meu favorito: trazer as funções de depuração de um kit de teste, permitindo que qualquer console de varejo se torne uma estação de depuração. Isso era feito instalando uma CFW com capacidades de depuração ou uma CFW que pudesse converter o console de varejo (chamdo de "CEX") em um modelo de depuração (chamado de "DEX") alterando dados específicos do console na memória Flash.

A resposta rígida da Sony

Semelhante aos eventos que ocorreram após a criação de CFWs para o PSP, a Sony retaliou com duas atualizações de segurança:

Do lado do software, a Sony lançou duas atualizações de sistema que aprimoraram o sistema de segurança:

• Com o sistema 3.56, os binários eram assinados com novas chaves de criptografia resistentes à descoberta anterior do ECSDA , portanto, os criadores de CFW não podiam personalizar os novos binários (já que não possuíam as chaves privadas para recriptografá-los). Além disso, uma nova revisão do aplicativo "atualizador de sistema" (system updater) também foi lançada, que impôs novos certificados nos arquivos de atualização do sistema (PS3UPDAT.PUP). Isto significava que mesmo que os hackers consiguissem empacotar uma nova CFW, apenas os consoles com a versão do sistema 3.55 ou anterior poderiam instalá-lo .
• Posteriormente, a atualização de sistema 3.60 reformulou o processo de inicialização, anulou o metldr e promoveu o lv0 para assumir o bootstrap dos carregadores (lv1ldr, lv2ldr, appldr e isoldr). Isso significava que os hackers não podiam modificar os novos arquivos do sistema sem primeiro quebrar o lv0 (ou seja, encontrando sua chave privada).
  • Isso acabou acontecendo no final de 2012, quando uma equipe chamada "Os três mosqueteiros" publicou as chaves do lv0 , o que abriu caminho para novas CFW feitas a partir de versões do sistema mais recentes do que 3.55. No entanto, devido às mudanças mencionadas no atualizador, apenas usuários com a versão do sistema 3.55 ou anterior (incluindo qualquer CFW com verificações de assinatura desativadas) poderiam instalá-lo.

Do lado do hardware, não apenas os modelos posteriores do PS3 (CECH-25xxx, CECH-3xxx e CECH-4xxx) vieram pré-instalados com uma versão de sistema mais recente que a versão 3.55, mas também continham uma versão diferente do bootldr/lv0ldr (chamdo lv0ldr.1) que não apenas descriptografa e carrega o lv0, mas também buscava um novo arquivo de sistema chamado lv0.2. Este último contém metadados sobre lv0 para garantir que o lv0 não tenha sido adulterado. O lv0.2 é assinado com uma nova chave criptográfica (também é imune à descoberta ECDSA anterior), impedindo assim que hackers pudessem assumir o controle da cadeia de inicialização.

Até o momento esses modelos não conseguem executar um CFW, sendo assim apelidados de invioláveis. No entanto, eles podem executar um "Firmware Híbrido" (HFW) e falaremos mais sobre isso posteriormente.

Conforme o tempo passou, o número de consoles compatíveis com o CFW diminuiu. Portanto, os PS3s que não foram atualizados além da versão 3.55 se tornaram uma espécie de relíquias. Enquanto isso, houve um aumento na demanda por alternativas, como * downgraders* (para retornar à versão do sistema 3.55 em modelos antigos) e ODEs (para jogar jogos pirateados em modelos novos).

O renascimento do Homebrew

Após um longo período de espera para os usuários que perderam a oportunidade de instalar um CFW, no final de 2017, um grupo de hackers lançou o PS3Xploit, uma coleção de exploits e utilitários que trouxe de volta a capacidade de instalar um CFW em modelos antigos sem a necessidade de um downgrader caro (e habilidades de operá-lo).

O payload principal do PS3Xploit replica o trabalho de um downgrader de hardware (patcheando os arquivos do CoreOS) inteiramente por software, e funciona da seguinte maneira:

1. O ponto de partida é o navegador da internet do XMB, construído em cima do WebKit. O PS3Xploit usa JavaScript para conseguir executar um código arbitrário no espaço do usuário do sistema (e fora do ambiente JavaScript). Para iniciar a execução, os usuários só precisam abrir o navegador web nativo do XMB, inserir um URL apontando para o host do PS3Xploit e deixá-lo fazer seu trabalho.
2. Acontece que o Kernel fornece chamadas de sistema que podem ser usadas para sobrescrever os arquivos do sistema na memória Flash. Além disso, o Visual Shell (XMB) e seus plugins armazenam rotinas na memória que usam essas chamadas.
3. O PS3Xploit não pode acionar essas chamadas do sistema diretamente devido à proteção do Hypervisor, que impede que o exploit carregue um novo código no espaço do usuário. No entanto, ele pode encontrar uma maneira de sobrescrever a memória Flash "pegando emprestado" as rotinas do Visual Shell.
4. Consequentemente, o PS3Xploit procede com a modificação da pilha de execução do Webkit para redirecionar a execução para as rotinas do Visual Shell. Esse tipo de técnica (corromper a pilha para desviar a execução para outro código residente na memória) é chamado de Programação Orientada a Retorno (ROP, do inglês Return Oriented Programming) e é muito popular na área de segurança da informação. Uma maneira de mitigar isso é implementando a randomização da organização do espaço de endereço (ASLR, do inglês Address space layout randomisation), o que torna difícil adivinhar a localização das rotinas (chamadas de gadgets), mas, como você pode imaginar, o Hypervisor da Sony não tem ASLR.
5. Finalmente, essas chamadas de sistema são acionadas com os parâmetros do PS3Xploit e, assim, substituem os arquivos do CoreOS (a primeira parte do sistema operacional, armazenada na memória Flash) por arquivos patcheados .
6. Agora, o console consegue instalar atualizações de software não oficiais, uma oportunidade que permite o usuário explorar a instalação de um firmware personalizado. No entanto, ainda não é possível fazer downgrade da versão do sistema, porém dado que um CFW atualizado é instalado, o usuário pode instalar mais utilitários para realizar o downgrade da versão do sistema e instalar um CFW mais bem equipado, se desejar.

Como você pode ver, esse presente dos céus trouxe os firmwares personalizados de volta à atenção e tornou os downgraders de hardware e os ODEs obsoletos. Por outro lado, para as unidades que não podiam instalar um CFW de qualquer maneira (os não hackeáveis), a equipe posteriormente ofereceu o PS3Hen, um pacote de exploits diferente que se concentrou em habilitar um subconjunto de funções do CFW (incluíndo a capacidade de executar homebrew). Ele se instala como uma entrada no XMB e o usuário deve executá-lo toda vez que ligar o console para reativar a execução de aplicativos homebew.

A resposta parcial da Sony

Por sorte, a Sony tomou apenas medidas pequenas para bloquear o PS3Xploit (talvez porque esse acontecimento tenha ocorrido anos após o lançamento do sucessor do PS3, o PlayStation 4). Eles lançaram algumas atualizações de sistema que não corrigiram essa cadeia de exploits, mas removeram a rotina usada no Webkit para inicializar a cadeia. Em resposta, os hackers publicaram atualizações de software ligeiramente modificadas que restauraram tal entrada (e de alguma forma, eles não precisavam ser re-assinadas) . Essas atualizações personalizadas foram chamadas de Hybrid firmware (HFW) e, no momento em que este texto foi escrito, são a opção de fato usada para habilitar homebrew em sistemas não-hackeáveis.

E aqui termina a saga anti-pirataria/homebrew. Em minha humilde opinião, não acredito que a Sony esteja interessada em colocar mais esforço no console. Portanto, não esperaria mais jogos de gato e rato neste campo.