…e este poderá correr em qualquer dispositivo não Apple.
Por Hélder Ferreira para o PPLWARE.COM
Já desde que o iPhone 4S saiu, que me andava a questionar se não haveria ninguém curioso em explorar o SIRI… Não é que, depois de algumas pesquisas no Google, encontrei o que eu questionava?
Os programadores da Applidium alegam, num recente artigo feito no seu blog oficial, terem conseguido quebrar o protocolo de segurança do SIRI, depois de vários testes e estudos feitos à aplicação de reconhecimento de voz da Apple.
Com esta quebra do protocolo, qualquer programador poderá usar o protocolo e criar um “SIRI” para Android.
Como parte do estudo feito pelos programadores, eles explicaram de forma técnica como o SIRI comunica.
O Siri (lado do cliente) establece uma ligação segura via porta 443 (associada normalmente ao protocolo HTTPS) ao servidor https://guzzoni.apple.com. Como a ligação é sobre HTTPs, usa certificados SSL para validar se o dominio e o cliente são fidignos. Segundo informaçoes, os hackers conseguiram criar uma “falsa” autoriadade de certificação, adicionaram-na ao iPhone 4S e usaram-na com sucesso para a comunicação entre o Siri (do lado do cliente) e o servidor https://guzzoni.apple.com.
Se abrirmos o url https://17.174.4.4/ somos enviados para o domínio guzzoni.apple.com, então ao que parece a comunicação do SIRI é feita com o servidor chamado de guzzoni.apple.com através de HTTPS.
Como se sabe o “S” em HTTPS significa “seguro”, isto é, todo o trafego feito através do cliente – servidor é cifrado. Neste caso, eles não puderam usar um sniffer, pois os resultados não seriam nenhuns. Eles para resolverem esta situação bastou usarem um simples servidor HTTPS fake,também um servidor de DNS fake de forma a capturar informações da comunicação.
Infelizmente, os programadores concluíram que quem fez o SIRI fez as coisas muito bem-feitas, eles verificam a cada momento se o certificado guzzoni é valido, o que perante esta situação, não puderam usar um certificado falso. Mas também é uma situação que puderam resolver, eles usaram um “root certificate” próprio, o qual faz com que qualquer certificado falso passe a ser um certificado válido.
Basicamente o que eles fizeram foi, configurar um servidor de autoridade de certificação SSL personalizada, e adicionar ao iPhone 4 de forma a certificar a ligação como um guzzoni.apple.com.
Ficaram surpreendidos com o resultado, o que eles prepararam resultou e conseguiram desta forma com que o SIRI enviasse os comandos para o servidor HTTPS deles. Ora aqui estão os cabeçalhos que o SIRI envia:
ACE /ace HTTP/1.0
Host: guzzoni.apple.com
User-Agent: Assistant(iPhone/iPhone4,1; iPhone OS/5.0/9A334) Ace/1.0
Content-Length: 2000000000
X-Ace-Host: 4620a9aa-88f4-4ac1-a49d-e2012910921
Os programadores consideraram alguns aspectos nos headers bastante interessantes, como:
- Os pedidos são enviados usando um método personalizado “ACE” invés do tradicional GET;
- O url pedido é /ace;
- O Content-Length é de quase 2GB, o que, obviamente, não corresponde aos padrões do HTTP;
- O X-Ace-host é uma forma de GUID, parecido a um UDID fornecido pelos iPhones.
Depois de conseguirem parte do que pretendiam, veio a parte mais complicada, desencriptar os dados.
O corpo dos dados estavam em binário e ao usarem um editor hexadecimal, foram presenciados que iniciava por 0xAACCEE, e como programadores de aplicações para dispositivos móveis pensaram logo que como o limite de banda é limitada, era uma excelente ideia terem feito compressão dos pacotes.
Ao usarem a conhecida biblioteca de compressão e descompressão, Zlib, e a partir do quarto byte conseguiram fazer unzip dos dados.
Para desencriptarem os binários basta que usem no Mac OS X o Plutil ou então usando a linguagem Ruby com o CFPropertyList em qualquer plataforma.
Os programadores escreveram algumas ferramentas (https://github.com/applidium/Cracking-Siri) que os ajudaram a perceber o protocolo.
Estas ferramentas apesar de não estarem acabadas, já dão algumas luzes para outros programadores poderem criar aplicações usando o protocolo usado no SIRI. A maior parte das ferramentas estão escritas em Ruby, algumas partes estão escritas em C e outras em Objective-C.
Apesar da quebra do protocolo ter sido feita por exploração da aplicação, a Apple irá certamente arranjar uma forma de resolver esta situação, ou não.