Como a DevTeam conquistou o iPhone

 (fabiensanglard.net)
1 pontos por GN⁺ 2024-03-11 | 1 comentários | Compartilhar no WhatsApp
  • O primeiro iPhone, em 2007, não podia ser ativado sem uma assinatura da AT&T nos EUA, e o iPhone Dev Team buscou publicamente uma forma de usá-lo com outras operadoras apenas por software
  • O trabalho foi organizado em 6 marcos: descriptografar o firmware, contornar a ativação, obter permissão de escrita, construir uma toolchain ARM/Mach-O, executar apps de terceiros e desbloquear o bloqueio de operadora
  • O avanço inicial veio da análise do ramdisk dentro de .ipsw e do DMG criptografado, além do uso de uma falha de retransmissão na verificação de ativação do lockdownd para acessar a tela inicial
  • A permissão de escrita foi obtida carregando o ramdisk e o kernelcache no Recovery Mode e depois alterando fstab e Services.plist, fazendo o sistema lidar com o sistema de arquivos raiz em vez de usar o afcd preso em /root/Media
  • O desbloqueio final foi automatizado com o anySIM, que fazia dump, patch e reenvio do firmware do baseband e executava AT+CLCK="PN",0,"00000000"; a Apple respondeu em 27 de setembro de 2007 com o firmware v1.1.1

O iPhone de 2007 e o objetivo da DevTeam

  • A Apple lançou o iPhone em 29 de junho de 2007, com preço de $499 para o modelo de 4 GB e $599 para o de 8 GB
  • Ao sair da caixa, o iPhone ficava inativo e mostrava apenas a tela Connect to iTunes; o usuário precisava assinar a AT&T pelo iTunes
  • Mesmo após a assinatura, o aparelho continuava bloqueado à AT&T
  • No Canadá, não havia cronograma inicial de lançamento do iPhone, e a Apple só chegou a um acordo com a Rogers junto com o iPhone 3G em 11 de julho de 2008
  • O iPhone Dev Team se reuniu com o objetivo de fazer o aparelho funcionar em qualquer operadora apenas por software e publicava com frequência o andamento no blog iphone.fiveforty.net
    • Em 3 de julho de 2007, houve 8 atualizações entre 0h e 21h

Os 6 marcos da DevTeam

  • Para usar um aparelho bloqueado como um smartphone comum, eram necessárias as seguintes etapas
    • Acesso de leitura para entender o sistema: Break DMG Password
    • Sair do estado inativo: Bypass Activation
    • Acesso de escrita para modificar o sistema: Get Write Access
    • Working Toolchain para criar executáveis customizados
    • Unlock para fazer o baseband se conectar a qualquer operadora
    • Um app para automatizar todo o processo: Enable Third-Party Applications
  • Segundo a Wayback Machine, em 6 de julho de 2007, 2 dos 6 marcos já estavam concluídos, e a jornada terminou em 12 de setembro de 2007
  • Na página de status capturada em 25 de setembro de 2007, Decrypt Firmware, Bypass Activation, Get Write Access, Get Working Toolchain, Enable Third-party Applications e Unlock Phone apareciam como concluídos

Análise do .ipsw e leitura do sistema de arquivos

  • O iTunes baixava um arquivo iPhone Software com extensão .ipsw para restaurar o aparelho, e esse arquivo era um zip
  • Dentro de iPhone1,1_1.0_1A543a_Restore.ipsw havia imagens de recuperação img2, a pasta Firmware relacionada ao baseband, o kernelcache do iOS e dois grandes arquivos DMG
    • O arquivo completo de restauração do iOS tinha cerca de 105 MiB
  • O primeiro DMG, 694-5259-38.dmg, era o ramdisk usado na restauração e não era criptografado, então podia ser montado com dd
  • O ramdisk não era o sistema de arquivos completo do iOS, mas permitia verificar as senhas do usuário mobile, usado para executar apps, e do root, que executava os demais processos, em /private/etc/master.passwd
  • O segundo DMG, 694-5262-39.dmg, era o sistema de arquivos do iOS usado na execução normal e estava criptografado
    • A chave foi encontrada em /usr/sbin/asr dentro do ramdisk
    • Como era uma chave e não uma passphrase, não dava para usar hdiutil, então a DevTeam escreveu sua própria ferramenta de descriptografia, vfdecrypt.c
    • Após a descriptografia, obteve-se acesso de leitura a todo o sistema de arquivos em runtime

Contorno da ativação

  • Na ativação normal, participavam o iTunes, o servidor da Apple albert.apple.com e o lockdownd do iPhone
    • O iTunes coletava DeviceID, IMEI e ICCID do aparelho
    • Os três valores eram agrupados em um token e enviados ao servidor da Apple
    • O servidor da Apple assinava o token com uma chave privada e o devolvia
    • O lockdownd, aguardando via USB, validava o token com a chave pública da Apple
    • Se o token viesse da Apple e batesse com as informações do aparelho, o estado mudava para Activated
  • O PhoneActivationServer de dvdjon fazia patch no iTunes para acessar o servidor de ativação via HTTP em vez de HTTPS e redirecionava a requisição para seu próprio servidor
  • O ponto central não era criar um novo token assinado, mas usar uma retransmissão: devolver, independentemente da entrada, o mesmo signed token capturado de uma ativação bem-sucedida
  • Segundo George Hotz, o lockdownd não verificava se DeviceID, IMEI e ICCID na resposta correspondiam aos valores reais
  • A DevTeam criou ferramentas CLI que liam um signed token hardcoded de um plist e o enviavam ao iPhone; depois isso foi melhorado com o iPhoneInterface, que funcionava sem iTunes

Permissão de escrita e jailbreak

  • Um iPhone ativado podia receber arquivos como músicas e fotos pelo iTunes, mas o processo responsável pelo upload, afcd, ficava preso em um chroot jail em /root/Media
  • Apenas a partição de usuário era montada como leitura/escrita (rw), enquanto a partição do sistema era somente leitura (r)
  • O objetivo era sair do chroot jail e conseguir escrever também na partição do sistema; daí surgiu o termo jailbreaking
  • O boot do iPhone se dividia em modo normal e Recovery Mode
    • No modo normal, o fluxo era BootROM → LLB → iBoot → Kernel → Normal Mode, e cada etapa verificava a assinatura da próxima
    • O Recovery Mode parava na etapa do iBoot, e o iTunes carregava ramdisk, kernelcache e outros componentes na RAM para entrar no modo de restauração
  • A DevTeam investigou em iTunesMobile.dll como o iTunes escrevia no sistema de arquivos durante a restauração e identificou comandos como mount, umount e ditto
  • O iPHUC era uma ferramenta CLI que se comunicava com aparelhos em Recovery Mode usando métodos privados de iTunesMobile.dll
    • O usuário colocava o aparelho em Recovery Mode
    • O ramdisk era enviado ao aparelho e carregado na RAM
    • O kernelcache era enviado e o kernel era inicializado apontando para o ramdisk
    • O aparelho entrava em Restore Mode
  • O jailbreak em si era feito alterando fstab e Services.plist
    • Em fstab, a partição do sistema passava a ser montada como rw em vez de somente leitura
    • Em Services.plist, era criado um segundo serviço afcd baseado em / em vez de /root/Media
    • Após reiniciar, o iTunes podia ver todo o sistema de arquivos via afcd2, e tanto a partição do sistema quanto a do usuário passavam a ter leitura/escrita
  • Depois, a ativação e o acesso de escrita foram automatizados no app desktop para Mac OS X INdependence

Toolchain e apps de terceiros

  • Há pouca informação pública sobre a toolchain e a execução de apps de terceiros, mas pelo menos 12 pessoas participaram do trabalho
  • Em 19 de julho de 2007, uma binutils toolchain voltada para ARM foi concluída, permitindo que a DevTeam executasse no iPhone programas feitos por ela mesma
  • Com a ARM/Mach-O Toolchain do Nightwatch, o primeiro aplicativo independente Hello World foi compilado e executado no iPhone
  • GeoHotz explicou que, fora da Apple, não havia antes essa combinação de Mach-O com ARM, então foi preciso escrever isso manualmente
  • Outro objetivo da toolchain era reconstruir MobileTerminal.h, expondo funções privadas de iTunesMobile.so, para se comunicar com afc sem rodar o iTunes
  • Algumas apresentações dizem que o kernel verificava a assinatura do executável antes de execl, mas a conclusão aqui é que o primeiro iPhone não fazia isso, e que o mecanismo parece ter sido introduzido no v1.1.1

Desbloqueio do baseband e anySIM

  • O iPhone era dividido entre a parte de smartphone, onde o iOS rodava, e a parte de baseband, responsável por telefone e modem
    • Os dois sistemas tinham RAM, CPU, armazenamento, firmware e oscilador próprios
    • Eles trocavam comandos AT por uma linha UART montada em /dev/tty.baseband
  • O comando AT necessário para o desbloqueio já era conhecido desde cedo
    • AT+CLCK="PN",0,"xxxxxxxx"
    • xxxxxxxx era a NCK (Network Control Key), considerada única para cada aparelho
    • O número de tentativas era limitado a 3 a 10, depois do que o firmware podia ficar permanentemente preso à AT&T
  • O baseband também tinha BootROM e cadeia de confiança, com verificação de assinatura
  • MuscleNerd explicou que o baseband não tinha uma proteção como DFU/Recovery Mode, então mexer errado na NOR ou nas imagens poderia inutilizar o aparelho permanentemente
  • Em julho de 2007, a DevTeam fez engenharia reversa do baseband dentro do .ipsw e também analisou /usr/local/bin/bbupdater no ramdisk para descobrir os comandos de envio de um novo baseband
  • A primeira CLI, iUnlock, exigia vários arquivos, como o firmware extraído nor e ICE03.12.06_G.fls
  • Depois surgiu o app mais simples anySIM, que podia ser enviado ao telefone e executado com um único botão
  • O anySIM funcionava na seguinte ordem
    • Abria /dev/tty.baseband e configurava os parâmetros do modem
    • Fazia dump do baseband de 4 MiB, ou seja, a NOR, para /tmp
    • Carregava o baseband na RAM
    • Carregava o secpack ICE03.12.06_G.fls vindo do ramdisk
    • Fazia patch dos comandos do baseband na RAM para permitir o desbloqueio com qualquer NCK
    • Reenviava o baseband com patch
    • Executava AT+CLCK="PN",0,"00000000" e AT+CLCK="PN",2

O truque -0x400

  • O firmware do baseband com patch, em condições normais, não passaria na verificação de assinatura e o upload deveria falhar
  • O bypass usava um deslocamento minus 0x400
  • GeoHotz explicou que os primeiros 0x400 bytes não eram usados antes da validação da assinatura, então bastava começar a escrever 0x400 bytes antes
  • Depois, segundo explicações de leitores no Hacker News, o baseband recebia o novo firmware em blocos de até 0x800 bytes
    • Não era um modelo de salvar os 4 MiB completos na RAM, verificar checksum e só então gravar em flash
    • Os bytes recebidos eram gravados imediatamente na flash, mas os primeiros 0x400 bytes ficavam temporariamente em buffer na RAM
    • Quando o upload terminava, o baseband verificava o checksum
    • Se falhasse, os primeiros 0x400 bytes armazenados em buffer não eram gravados na flash e eram descartados
  • O método -0x400 primeiro escrevia dados lixo 0x400 bytes antes da posição original do firmware e, em seguida, enviava o firmware completo de 4 MiB
    • O checksum falhava e os 0x400 bytes de lixo eram descartados
    • Mas o restante do novo firmware já havia sido gravado na flash na posição correta

Conclusão e o jogo de gato e rato que veio depois

  • As instruções completas para o desbloqueio totalmente por software foram publicadas em 12 de setembro de 2007
  • Junto delas, foram divulgados casos de sucesso em vários continentes, incluindo o Canadá
  • A Apple respondeu rapidamente em 27 de setembro de 2007 com o firmware v1.1.1 do iPhone
  • A barra de progresso da DevTeam foi reiniciada para Decrypt 1.1.1, Get Write Access 1.1.1, Activate 1.1.1, Unlock 1.1.1 e Enable Third-party Applications 1.1.1
  • A partir daí começou o jogo de gato e rato entre a Apple e a comunidade de hacking do iPhone, e ele continuou depois disso

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-11
Comentários do Hacker News
  • É um método comum em atualizações de firmware. Os primeiros 0x400 bytes são um cabeçalho que o carregador do estágio anterior precisa verificar antes de inicializar este estágio; por isso, ele recebe os dados e grava livremente, mas não grava o cabeçalho
    Como não há cabeçalho, é seguro, pois não leva à execução de código; no fim, ele verifica a assinatura de tudo e, se passar, grava o cabeçalho para tornar a imagem inteira válida
    O truque aqui é primeiro gravar 0x400 bytes de lixo 0x400 bytes antes da posição de gravação desejada. Essa parte é tratada como cabeçalho, apenas fica em buffer e não é gravada de fato, enquanto o restante dos dados transmitidos é realmente gravado na posição desejada. Depois, a verificação de assinatura falha e, como os primeiros 0x400 bytes que originalmente não eram desejados não são gravados, isso é um sucesso
    • A parte chamada de “modo de recuperação” acho que na época era chamada de modo DFU. Era “Device firmware update”, e não tenho certeza, mais de 15 anos depois, se na época chamavam isso de “recovery”
    • iZsh(https://x.com/izsh1911) também talvez saiba, mas perdi contato com ele há mais de 10 anos
  • Como é típico dos textos do Fabien, é bem escrito e muito detalhado. Lembro de ver a análise desse mecanismo de proteção do iPhone na época, e foi realmente uma longa jornada desde então
    Acho que, se alguém explicar melhor também o deslocamento de -0x400 aplicado antes de gravar os dados, a coisa fica totalmente esclarecida
    • O deslocamento de -0x400 parece funcionar mais ou menos assim
      Com Seek(fd, 0xA0020000 - 0x400);, ele busca 0x400 antes da posição onde os dados deveriam ser gravados, e com SendWrite(fd, foo, 0x400, false); preenche com zeros os primeiros 0x400 bytes que queria gravar
      Em seguida, com SendWrite(fd, fw, fwsize, true);, preenche os bytes restantes com os dados reais e chama SendEndSecpack(fd);. O iPhone copia os dados depois dos 0x400 bytes, ou seja, todos os dados que se queria gravar, e então tenta verificar a assinatura, que falha. Se a verificação da assinatura tivesse sido bem-sucedida, os primeiros 0x400 bytes deixados como zero também teriam sido copiados naquele momento
  • Para registro histórico, fui eu que criei o iPHUC, e dei esse nome quando tinha 19 anos. A pessoa que usava o nick “nightwatch” foi uma figura central no jailbreak inicial e na criação do termo “jailbreak”, e era realmente ótima de trabalhar
    Se bem me lembro, o exploit em PDF ou TIFF que desbloqueou o PSP provavelmente também foi obra dele. Acho que ele morava em algum lugar da América do Sul, talvez trabalhando em uma universidade, mas é só isso que sei
    Foi uma época muito divertida e aprendi muito. No entanto, George Hotz colocou em risco a segurança de algumas pessoas que ajudaram no acesso a documentos em japonês, apesar de repetidos pedidos para não fazer isso, o que foi muito frustrante e acabou sendo o motivo pelo qual o dev team deixou o projeto
    • Lembro que havia alguém com o nick “pineapple” que ajudou a entender a arquitetura ARM. Na época, ARM era relativamente novo, e por isso havia muitos abacaxis nas primeiras UIs. Eram pessoas muito boas, e é uma pena eu não ter mantido contato
    • Dentro do que é possível dizer sem risco de processo por difamação, eu gostaria de ouvir mais sobre como George Hotz colocou a segurança das pessoas em risco
  • A estrutura de concatenar DeviceID, IMEI e ICCID para criar um token, enviá-lo ao servidor da Apple, albert.apple.com, para ser assinado com a chave privada da Apple, e então o lockdownd no aparelho verificar com a chave pública da Apple e mudar o estado para “Activated”, soa como uma precursora do OAuth atual
  • Ah, os bons tempos. Quando hackear o iPhone era fácil… ou melhor, muito mais fácil do que hoje
  • Fico curioso para saber com qual ferramenta fizeram o fluxograma. Parece baseado em texto e talvez seja melhor que mermaid
  • Uma história de que me lembro: eu estava no canal de IRC quando o lançamento do iPhone OS 1.1 bloqueou o jailbreak. Um dos métodos descobertos na época era fazer downgrade para 1.0.2, fazer o jailbreak do telefone e então criar um link simbólico do diretório /root/Media, acessível pelo iTunes, para /
    Esse link era mantido durante a atualização e, depois de atualizar o firmware, era possível acessar o rootfs. Na época, o nome era iPhone OS, não iOS
  • Nos primeiros iPhones, parece que o “S” significava segurança. Foi o que acabou acontecendo, já que estavam tentando lançar o primeiro produto
    É parecido com montadoras de carros. É melhor não comprar os primeiros anos-modelo de um produto novo ou de uma plataforma nova
    • Não há consenso sobre o que o “S” significava, e a Apple também nunca revelou oficialmente. “Successor”, “Second” e “Speed” parecem todos fazer algum sentido, mas não há uma resposta real
      Normalmente, o “S” era uma marca para indicar um upgrade incremental em relação ao modelo básico