A nemmeno un mese dal lancio, la società tedesca fracese Applidium ha crackato il protocollo di Siri.
La metodologia descritta è molto interessante e può essere applicata a casi analoghi.
Siri invia tutti i dati a guzzoni.apple.com utilizzando il trasporto (trasporto, non protocollo, vedremo poi) HTTPS. Il client che risiede su iOS verifica la validità del certificato SSL di guzzoni.apple.com per impedire che il traffico venga dirottato su un altro server tramite DNS poisoning.
Questo non ha però fermato i tecnici di Applidium, che hanno creato un finto host guzzoni.apple.com con un finto certificato SSL emesso e firmato da una finta CA. Il clienti di Siri verifica, infatti, la validità del certificato di guzzoni.apple.com, ma si fida di qualsiasi CA lo garantisca.
Il protocollo del client è simile af HTTP, ma utilizza un comando custom, come si può vedere dall’header di una richiesta inviata al server:
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
Il campo X-Ace-Host sembra essere univoco per ogni dispositivo iOS; la dimensione di quasi 2 Gb non rispecchia la dimensione effettiva del pacchetto inviato, quindi, e non è standard HTTP.
Il payload del pacchetto inviato contiene una firma 0xAACCEE, un byte apparentemente inutilizzato e il pacchetto dati vero e proprio compresso con zlib. I dati sono composti da chunk; per ora sono stati decodificati questi tipi:
- quelli che iniziano con 0x020000xxxx contengono plist, i pacchetti con la voce registrata sono codificato con Speex;
- quelli che iniziano con 0x030000xxxx contengono dei pacchetti di ping dal client al server;
- quelli che iniziano con 0x040000xxxx contengono dei pacchetti di risposta al ping dal server al client.
Lascia un commento