November 15, 2011 at 12:05Siri Communication Protocol Hacked
Applidium’s mobile application developers managed to figure out the communication protocol that Siri uses, so now this speech recognition engine can theoretically be run on any device, including Android, if you know where to get the iPhone 4S ID, and Apple doesn't will add it to the "black list".
A key element of Siri is how the program communicates with the server (Siri only works if you have Internet access). The traffic goes via TCP, port 443, to the server 17.174.4.4. If you try to contact the server https://17.174.4.4/ from the desktop, you will see that he is presenting a certificate in the name guzzoni.apple.com ( Didier Guzzonifrom SRI - one of the creators of this technology).
Since traffic is protected by https, you cannot listen to it with a sniffer. The guys at Applidium decided it was easiest to pick up a fake https server and dns server - and look at the requests from Siri. Of course, you can’t fake a real certificate guzzoni.apple.com , but you can try on behalf of your own certification authority to issue your own valid certificate on guzzoni.apple.com to a fake https server . Since iPhone allows you to add certificates from arbitrary certificate authorities to your phone, this method worked - and now Siri can successfully exchange commands with your own server!
After that, hackers were able to calmly deal with the Siri protocol, it uses unusual methods that do not meet HTTP standards. The title looks something like this:
As you can see, the ACE method is used instead of the usual GET, “/ ace” is requested as the url, the Content-Length field is specified in almost 2 GB. The X-Ace-host field is somehow tied to a device identifier (GUID).
The request body itself is sent in binary form. It starts with 0xAACCEE. The developers suggested that the archived content comes next, that is, the data is transmitted in a compressed form. And so it turned out: the zlib archiver successfully recognized the archive in binary code (starting with the fifth byte after the AACCEE header).
In the unpacked data, binary code was again detected, but with text inclusions. Among the individual words, the attention of the developers was drawn by bplist00 . Obviously this is an indication of the plist binary. Having studied the data in more detail, the developers found several different fragments:
The developers found that Siri sends audio fragments compressed by the Speex codec to the server , and also inserts the iPhone 4S device identifier everywhere. The program and the server exchange a huge amount of information on the slightest occasion. For example, when speech recognition is running, Apple servers send timestamps and a “level of trust” for each word.
For independent work with Siri protocol you can use a set of toolscreated by Applidium programmers.
A key element of Siri is how the program communicates with the server (Siri only works if you have Internet access). The traffic goes via TCP, port 443, to the server 17.174.4.4. If you try to contact the server https://17.174.4.4/ from the desktop, you will see that he is presenting a certificate in the name guzzoni.apple.com ( Didier Guzzonifrom SRI - one of the creators of this technology).
Since traffic is protected by https, you cannot listen to it with a sniffer. The guys at Applidium decided it was easiest to pick up a fake https server and dns server - and look at the requests from Siri. Of course, you can’t fake a real certificate guzzoni.apple.com , but you can try on behalf of your own certification authority to issue your own valid certificate on guzzoni.apple.com to a fake https server . Since iPhone allows you to add certificates from arbitrary certificate authorities to your phone, this method worked - and now Siri can successfully exchange commands with your own server!
After that, hackers were able to calmly deal with the Siri protocol, it uses unusual methods that do not meet HTTP standards. The title looks something like this:
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-e2012910921As you can see, the ACE method is used instead of the usual GET, “/ ace” is requested as the url, the Content-Length field is specified in almost 2 GB. The X-Ace-host field is somehow tied to a device identifier (GUID).
The request body itself is sent in binary form. It starts with 0xAACCEE. The developers suggested that the archived content comes next, that is, the data is transmitted in a compressed form. And so it turned out: the zlib archiver successfully recognized the archive in binary code (starting with the fifth byte after the AACCEE header).
In the unpacked data, binary code was again detected, but with text inclusions. Among the individual words, the attention of the developers was drawn by bplist00 . Obviously this is an indication of the plist binary. Having studied the data in more detail, the developers found several different fragments:
- Fragments starting with 0x020000xxxx are “plist” packets, xxxx corresponds to the size of the binary plist data that follows the header.
- Snippets starting with 0x030000xxxx are the “ping” packets that the iPhone sends to the Siri server to support the connection. Here xx corresponds to the serial number of the ping.
- Fragments starting with 0x040000xxxx are “pong” packets that the Siri server sends to the iPhone in response to pings. As you might guess, xx corresponds to the serial number of the packet.
The developers found that Siri sends audio fragments compressed by the Speex codec to the server , and also inserts the iPhone 4S device identifier everywhere. The program and the server exchange a huge amount of information on the slightest occasion. For example, when speech recognition is running, Apple servers send timestamps and a “level of trust” for each word.
For independent work with Siri protocol you can use a set of toolscreated by Applidium programmers.