Siri cracckato EUREKA!!! addio esclusiva Apple

Ecco qui che vi spiegherò come si è riuscito ad effettuare il crack di Siri, questo permetterà di montare Siri anche su android tra qualche tempo, ma bando alle ciance veniamo al dunque senza perdere altro tempo: Il 14 ottobre 2011, Apple ha introdotto il nuovo iPhone 4S. Una delle sue principali novità era Siri, un'applicazione assistente personale. Siri utilizza una tecnologia di elaborazione del linguaggio naturale di interagire con l'utente. È interessante notare che Apple ha spiegato che Siri funziona inviando dati ad un server remoto (che probabile che Siri funzioni solo su reti 3G o WiFi). Non è stato possibile mettere le mani sul nuovo iPhone 4S, ho deciso di avere un sneak peek di come funziona davvero. Oggi, siamo riusciti a rompere il protocollo aperto di Siri. Il risultato? siamo in grado di utilizzare motori di riconoscimento di Siri da qualsiasi dispositivo. Sì, questo significa che chiunque può ora scrivere un'applicazione Android , utilizzando il codice originale di Siri, o meglio sulla falsa riga, avendo il codice base! O utilizzare Siri su un iPad! Condividerò tutto questo con voi. Il modo migliore per chattare con un server remoto è HTTP, in quanto è il protocollo che risulta più probabile per lavorare in ogni caso. Il modo più semplice per sniffare il traffico HTTP è quello di impostare un server proxy, configurare l'iPhone per usarlo, e guardare a ciò che passa attraverso il proxy. Sorprendentemente, quanto fatto, non saremmo in grado raccogliere tutto il traffico durante l'utilizzo Siri. Così abbiamo deciso di usare tcpdump su un gateway di rete, e ci siamo resi conto che il traffico di Siri era TCP, sulla porta 443, un server a 17.174.4.4. Andando a https://17.174.4.4/ su una macchina desktop abbiamo notato che questo su server è stato presentato un certificato per guzzoni.apple.com. Quindi sembrava che Siri era in comunicazione con un server denominato guzzoni.apple.com su HTTPS. Come sapete, la "S" in HTTPS sta per "sicuro": tutto il traffico tra client e server https viene criptata. Così non abbiamo potuto leggerlo con uno sniffer. In tal caso, la soluzione più semplice è quella di falso un server HTTPS, utilizzare un server DNS falso, e vedere quali sono le richieste in arrivo. Purtroppo, le persone che lavorano dietro Siri ha fatto le cose per bene: si verifica che il certificato Guzzoni è valido, quindi non si può fingere. Beh ... hanno fatto verificare che questo sia valido, ma cosa è, è possibile aggiungere il vostro "certificato root" proprio, che consente di contrassegnare ogni certificato che si desidera e utilizzarlo come valido. Quindi, in pratica tutto quello che dovevamo fare era impostare un'autorità di certificazione SSL personalizzato, aggiungere al nostro iPhone 4S, e utilizzarlo per firmare il certificato personalizzato con uno falso "guzzoni.apple.com". Il risultato? Ha funzionato: abbiamo fatto inviare a Siri un comando per recidere l'HTTPS! Sembra che qualcuno alla Apple in questo periodo abbia perso qualche passaggio! In quel momento ci siamo resi conto come il protocollo di Siri sia opaco. Diamo un'occhiata ad una richiesta HTTP Siri. Il corpo della richiesta è binaria (ci arriveremo in quella successiva), e qui sono le intestazioni: 

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

Un paio di cose interessanti: La richiesta che stiamo utilizzando è un metodo personalizzato "ACE", invece di un GET più usuale. L'URL richiesto è "/ asso" Il Content-Length è quasi 2GB. Che ovviamente non è conforme allo standard HTTP. X-Ace-host è una qualche forma di GUID. Dopo aver provato con altri iPhone4Ses diversi, questo sembra essere legato al dispositivo reale (più o meno come un UDID). Ora passiamo al corpo. Il corpo è un contenuto binari originari. Quando abbiamo guardato con un editor esadecimale, abbiamo notato che è iniziato con 0xAACCEE. Oh, sembra un'intestazione! Purtroppo, non siamo riusciti a capire nulla di quello che c'era dopo. In quel momento c'è stato da riflettere molto seriamente. Come tutte le persone che sviluppano applicazioni mobile, sappiamo che c'è una cosa che è molto importante quando si parla di una rete: la compressione. La larghezza di banda è spesso limitata, quindi di solito è una buona idea per comprimere i vostri dati. Qual è la libreria di compressione più diffuso in giro? zlib: "http://zlib.net/". E 'una libreria molto solida, davvero efficiente e potente . Così abbiamo cercato di intubare i dati binari attraverso zlib. Ma non ci siamo riusciti, ci mancava un header zlib. In quel momento abbiamo pensato "hmm, quindi c'è già questa intestazione AACCEE nel corpo della richiesta? Forse c'è ancora un po di speranza? ". A noi sviluppatori piace mantenere le cose nel sacco e uscire al momento giusto (riservatezza e cautela). 3 byte non sono una buona lunghezza per un colpo di testa. 4 si. Così abbiamo provato un-zippare dopo il 4 byte. E ha funzionato! Ora, non appena abbiamo unziped il contenuto, siamo riusciti ad ottenere alcuni dati sul nuovo codice binario. Non molto comprensibile, ma alcune parti era testuali, ottimo!. Tra questi, abbiamo spostato la nostra attenzione su un Cough: bplist00. Evviva, sembra che i dati siano alcuni plist binari. Dopo aver giochicchiato un po con questo codice binario, abbiamo capito che era fatta di pezzi: Pezzi a partire da 0x020000xxxx sono "plist" pacchetti, xxxx è la dimensione dei dati plist binario che segue l'intestazione. Pezzi a partire da 0x030000xxxx sono "ping" pacchetti, inviati dal iPhone al server di Siri per mantenere attiva la connessione. Qui xx è il numero di sequenza ping. Pezzi a partire da 0x040000xxxx sono "pong" pacchetti inviati dal server di Siri come una risposta al ping pacchetti. Senza sorpresa, xx è il numero di sequenza pong. Decifrare il contenuto di plists binario è molto semplice, si può fare su Mac OS X con il "plutil" riga di comando. O in ruby con CFPropertyList su qualsiasi piattaforma. Possiamo trarre qualche conclusione.... I dati audio: L'iPhone 4S manda davvero i dati audio grezzi. Sono compressi utilizzando il codec audio Speex, il che ha senso, in quanto è un codec specificamente pensati per il VoIP. Le firme: Iphone4s spedisce il suo idwentificatore ovunque. Quindi, se si desidera utilizzare Siri su un altro dispositivo, è ancora necessario l'identificatore di almeno un iPhone 4S. Ovviamente Apple potrebbe mettere in blacklist l'identificatore,ma finchè lo si testa per uso personale non c'è nulla da temere! Il contenuto effettivo: Il protocollo è in realtà molto, molto loquace. Il vostro iPhone invia una tonnellata di cose da server di Apple. E quei server danno risposta una quantità incredibile di informazioni. Per esempio, quando si utilizza text-to-speech, il server di Apple manda in risposta un punteggio confidenziale e il timestamp di ogni parola. Bene ecco quanto....ora fate voi:-)