Tag Archives: siri explain

Siri binary data, how to process

Apple's new personal assistant Siri was cracked by Applidium few months ago. The data format was explained by them in detail.

Just for a personal interest, I try to make a java version of siriproxy based on the information they provided. Turns out there are much more details into it.

How iphone send voice packages
First of all, Siri convert voice data in to the codex Speex data format. Which is a public available library and there are java/c libraries that deals with it. For people who are interested in collecting the data and do some dictation on their own. They can simply write some code to build voice recognition models on a java proxy.(work the same as siri proxy).

Then, the speex data packets are packaged in to CFPropertyList. There are also c libraries to read binary data and convert into the property list too. I haven't find a java library, but if comes to that, I'll just write one myself.

Then this property list of binary data is compressed using zlib. and sent to the guzzoni.apple.com server.

When you write code to build a proxy to intercept the packages between iphone and apple server. You'll find that iphone first some few lines of headers of a "ace" request, not http request!.
Then it start to send a bunch of binary packages, each with various length.

How to read the data iphone sent out
before the binary data, there is this ACE header immediatly follows the 4 or 5 lines of ace header. which look like this

ACE /ace HTTP/1.0
User-Agent: Assistant(iPhone/iPhone3,1; iPhone OS/5.0.1/9A405) Ace/1.0
Content-Length: 2000000000
X-Ace-Host: xxxxxxxxxxxxxxxxxxxxxxx

Then there is an empty line, which means there is two bytes of carriage return and line feed, "/r/n" immediately after the X-Ace-Host:xxxxxx...

To unzip the binary data using zlib. One important thing to know is, the header of the first package is universal to all follow up packages. which means, in java, if you write something like this.

while (line= read from iphone){
decompressor d= new decompressor();

it will most likely not work. you have to look all packages as a whole when you unzip it.

decompressor d= new decompressor();
while (line= read from iphone){

Then binary data starts. The binary data start with a 4 bytes of ace header. it should always look like 0xAACCEE, the 4th byte doesn't really mean anything. So to unzip the binary data, start from 5th byte. In java socket programming, a InflaterInputStream is a handy thing to use. It automatically convert the InputStream of iphone to InflaterInputStream, and anything it spits out is unzipped data.

There are two types of data in the unzipped data. One is a "ping" package, it doesn't mean anything except it's a small packages (usually few bytes) send to apple to keep connection alive.. The 5 bytes header for this is 0x030000xxxx(in hex), the xxxx means the length of the package follows the 5 bytes header.

Another type is Property List. The list contain the iphone 4S identification key, the voice packages and etc. The 5 bytes header for this is 0x020000xxxx.

One very important thing to know about the xxxx is that, it's only 2 bytes, but it's very easy to get confused when calculating the length. Because every packages are one after another, if the length of 1st package is wrong, then you won't find the 2nd package.

The LSD and MSD is here to play a big part. While your machine reads from left to right, in each byte, the representation is tricky.
For example: if you see a xxxx as 0x00EC, it does not mean that it's E(15x16)+C(13), it actually means the opposite. it means C(13x16)+E(15).Because the C is actually the most significant digit. It's very important to check if your machine is reading this way.

If you successfully convert the binary data into property list, you can extract the iphone 4S certifications and save for your iphone 4 just like siriproxy.

If you see 0x0123, it's not 1x256+2x16+3, it's actually 1x16^3+3x16+2. Of course, in many systems a simple convert is enough, but just to make sure you know that this might cause problem. In java a Short.parsebyte(0x0123) works nicely to know the length of the packages.