

Cracking Siri - nolanbrown23
http://applidium.com/en/news/cracking_siri/

======
Xuzz
Using an almost amazingly simple procedure a few weeks ago, I worked a bit
with @tmm1 on figuring most of this out. We actually got custom commands
working via both proxy and on-device interposing based methods:
<http://mobile.twitter.com/tmm1/status/131520489049960449>

------
pflats
A little googling shows some interesting info about the ACE request/header.
From skimming, it looks like a header compression method for VOIP on
cell/lossy connections.

Slide deck: [http://www-rn.informatik.uni-
bremen.de/ietf/rohc/ace-033100-...](http://www-rn.informatik.uni-
bremen.de/ietf/rohc/ace-033100-aus.pdf)

Whitepaper: <http://w3.ualg.pt/~bamine/B3.pdf>

------
leoh
Looks like guzzoni.apple.com is named after Didier Guzzoni
(<http://www.ai.sri.com/~guzzoni/>), an employee at SRI.

He's also listed on an interesting Apple patent that was only filed a few
weeks ago, "INTELLIGENT AUTOMATED
ASSISTANT"(<http://www.wipo.int/patentscope/search/en/WO2011088053>).

Some very interesting implementation details there.

------
LeafStorm
I'm kinda wondering why Apple bothered using HTTP for something that really
doesn't use anything recognizable as proper HTTP. Was it just for HTTPS?

~~~
sjs
Probably so it'll work through strict proxies.

~~~
icebraining
Since it's HTTPS, those proxies can't see the traffic anyway, so as long as
they used SSL on port 443, they could use any protocol on top.

~~~
jodrellblank
They potentially can; commercial firewalls can man-in-the-middle HTTPS traffic
with a locally signed and organization-computer-trusted SSL certificate.

~~~
icebraining
Yes, you're right, in fact I found a few weeks ago that even Squid can do
that.

~~~
skeletonjelly
Fiddler also: <http://www.fiddler2.com/fiddler/help/httpsdecryption.asp>

Great for debugging third party https stuff.

------
jentulman
The question that springs to my mind is not 'how can I play with this?' but
'Are Apple bringing Siri to the desktop?', seeing as it appears there's
nothing specific to the 4S hardware in how this works.

I'd quite like to be able to add calendar entries or tweet without moving to
another application.

~~~
zach
Apple has clearly had a difficult time keeping up with early demand for Siri
services as it is.

I think keeping it limited to the 4S looks a lot more like a operational
necessity at this time.

Given that, If Siri appears on the Mac between major OS releases, I imagine it
might be only for new hardware (i.e. a Macbook Air with an exterior Siri
button and purple LED) at first as well.

Eventually (once they can scale Siri well enough), it could be released as a
modestly-priced Mac App Store app. I bet it would be more pricy than FaceTime
($0.99 US) though.

I presume that's what they'll end up doing for existing iOS customers, pegging
Siri for iPhone 4 and recent Touches at a price that keeps 4S customers
satisfied to get early access and/or "free" Siri for the life of their phone.

~~~
mkjones
What makes you think thy've had a tough time scaling with early demand? I'd
think that this scales horizontally pretty well, given that each request is
largely stateless and there's no interaction between users.

~~~
philwelch
> each request is largely stateless

Negative. Siri remembers the context of your conversation.

~~~
sovok
But according to this article, the server seems to only translate speech to
text, with the whole natural language processing and AI happening on the
device.

------
tamersalama
I wonder how Apple is taking all of this? Is Applidium risking their developer
license?

~~~
alastairpat
I would doubt it - there's nothing illegal about reverse-engineering a
protocol.

~~~
dfj225
Sure, but there's nothing illegal about Apple kicking someone out of the App
Store on a whim either.

Doesn't matter if you are breaking the law or not, plenty of legal apps get
rejected. Apple sets their own terms outside of US law.

~~~
alastairpat
Apple has to comply with its contract just as the developers do. I did just
check the agreement and either party can terminate with 30 days' notice for
any or no reason, so they could theoretically terminate.

Given this is completely out of the scope of the App Store or even the SDK
(contrast with the security researcher who got unapproved code executing),
however, I don't imagine Apple will feel the need to terminate. I guess we'll
just have to wait and see.

~~~
ugh
Apple usually avoids shitstorms or backpedals if they cause one – but
sometimes they don't.

It's not unreasonable to assume at Apple won't do anything but it's risky.

------
spraveen80
I didn't see anything in this article that mentions that the natural language
understanding is done in the cloud. May be I am missing something, but I don't
understand why everyone is jumping to the conclusion that the NLU is also done
in the cloud and downvoting other's comments that said so.

From what I've seen, Siri sends compressed audio to the cloud which translates
that to text. What happens to the text and how does that translate to action?
Where is this being handled? Is there any proof that this is done in the
cloud?

------
cjoh
It'd be interesting to see whether or not Apple changed the Siri protocol
since the acquisition. Was this originally how Siri worked when it was
independent?

Because Siri has roots in government contracting (it's named after SRI
International, and was originally funded by DARPA) I wonder if the roots of
the obfuscation start there rather than at Apple.

~~~
cbr
I don't see any obfuscation here, just a compressed binary encoding.

------
MatthewPhillips
Cannot upvote this enough. Stuff like this is the reason I read HN.

------
jakubw
I wonder if there are any characteristics about the microphone in Apple
devices that the servers could check the audio against to prevent this sort of
a thing. There should be a way to somewhat distinguish the device used to
record a stream given Apple's control over the devices on which Siri runs and
overcoming that would be hard enough for anyone to bother.

~~~
icebraining
Maybe, but what's the point? If you try to run a service on top of this,
you'll have to make so many requests that you'll either have your ID banned or
you'll need to buy so many iPhones that you might as well contract a speech-
to-text service to some company.

If you're just using it for personal reasons, why should Apple care?

~~~
jakubw
What I had in mind were not services but rather Siri clients for non-Apple
hardware, which I assume Apple would not be particularly happy about. When
Siri comes to iPads and Macs, owners of a much broader range of devices could
take an ID and use it, for instance, in an unofficial Siri client (should one
be created) on an Android device. But then again, I may be way overthinking
this.

~~~
hmottestad
Probably. Take note of the fact that OS X editions don't use a serial number.
You can very easily share them with friends and family and online. Same goes
for iWork, however some of the more expensive software does use SN.

If you already bought an iphone/mac/ipad (in the future) that has Siri, then I
don't think apple will care much if you use siri on other devices. However
what is really useful with siri is where it talks to the os layer and other
applications. That kind of integration isn't all that easy to do.

So if someone writes an app with the integration to the os and apps (calendar,
sms, phone, phonebook...) and decide to use Siri (illegally), then I think
they deserve a medal or soemthing for their hard work for porting the siri
front end to another platform.

------
pdenya
Really interesting. I'm curious what their tools look like but the github
repository the article links to is currently empty.

~~~
sjs
They're fixing it soon:
<https://twitter.com/#!/applidium/status/136175883055661057>

------
victoknight
<spolier> guess who doesn't verify the root CA. Think of all the fun to be had
with a Siri man-in-the-middle

~~~
ajross
Missing the point, I think. There's no security bug here. The application
isn't responsible for verifying the root CA in typical security models (though
some, like Chrome, do something similar -- that's how the compromised Dutch CA
was discovered). The idea is that the CA list is populated by your platform
vendor and you trust it.

The trick here was that Siri was asking for an HTTPS connection to a named
server, and you can't MitM that without having a signed cert for that server.
So they added a new CA to their local (jailbroken) iPhone platform data and
signed a cert for the Siri server.

~~~
jevinskie
And for anyone thinking about ways to fix that problem, the researchers could
have hooked SSL's read/write calls using a DYLD interposing library. Once you
get superuser access on the phone, you can't trust your code to be safe.

~~~
Xuzz
There is no jailbreak for the iPhone 4S (at least not publicly available), so
any hacks like this must be done from outside the device.

------
mbq
Anyway, this is a proof that siri is a pure cloud service and as such may work
even on 5-yo Sagem...

~~~
kmm
Not exactly. The text-to-speech is done in the cloud, but the hard part
(algorithmically speaking) is natural language processing, which apparently (I
don't know for sure) is still done on the phone.

I don't know what Apple's excuse is though, but limited processing power is
certainly not a problem.

~~~
coyotej
I think you have it exactly backwards - the iPhone 4S/Siri speech-to-
text/natural language processing are done in the CLOUD. The text-to-speech is
done on the phone itself. My (non-Siri of course) iPhone 4's Voice Command
stuff is COMPLETELY on the phone itself, and would do TtS of my contact list
and Artist names, etc.

~~~
watty
The article says, "The iPhone 4S really sends raw audio data". At least for
Siri, TtS occurs on the cloud - not sure where the text processing > API
occurs though.

~~~
coyotej
Sending raw data and _receiving_ raw data are NOT the same thing. It's been
clear that the iPhone 4S sends raw data to the cloud, based on people sniffing
the network shortly after release.

------
tucson
"Seems like someone at Apple missed something!"

What did Apple miss? (in other words: how could they avoid this, assuming they
wanted to avoid such crack)

------
achompas
I would LOVE to backward-engineer Siri's speech-analysis algorithms.
Confidence scores help, but it doesn't look like any other modeling data is
available?

~~~
cheald
That's all happening on the servers, so it's not the sort of thing you'll
really ever get access to.

------
mirkules
Is there a possibility to craft a Siri server reply with malicious code?
Shouldn't be too hard for the applidium guys to attempt (maybe even use a
fuzzer?)

~~~
icebraining
Maybe, but then you need to manually add your own root CA to the iPhone, or
the cert verification will fail, so it's not a security issue.

~~~
defen
Might be a way to jailbreak the phone though, no?

~~~
aperiodic
Only if there's an exploitable bug in the Siri client.

------
jasonkolb
I love reading investigative coding stories. Always fun to take a peek into
secret--especially high-profile--code.

Thanks!

------
aritraghosh007
The remote server is located at apple-compu.car1.charlotte1.level3.net.

------
signa11
can the server-side be a watson like computer cluster ? just curious...

------
baconhigh
down for me :(

~~~
icebraining
Mirror: <http://pastehtml.com/view/be0jurgda.html>

------
hc5
> The iPhone 4S sends identifiers everywhere.

So if I'm reading this right, Apple is sending UDIDs over HTTP?

~~~
elliotanderson
From the article it looks like UDID's are being sent over HTTPS

------
Volpe
No one is at all concerned that this is a hack?

I know it's interesting stuff, but I'm curious what "rights" Applidium have in
publishing this information.

With this information, (if I'm not wrong) it wouldn't take long to simply DDoS
Siri...

Or port Siri to Android (effectively stealing IP).

(I have no bias either way, just pointing out, if someone figured out how to
reverse engineer dropbox, so you could use their space, without a dropbox
account, would we all be going "wow, this is so cool!" or would we be crying
out "this is such an irresponsible hack!")

~~~
modeless
Hacks are admired here, not condemned. Reverse engineering should always be
allowed. This information doesn't make it possible to DDoS Siri or port it to
Android as each request requires a unique iPhone ID; Apple can easily filter
out unauthorized requests.

~~~
Volpe
"As a result, we are able to use Siri’s recognition engine from any device.
Yes, that means anyone could now write an Android app that uses the real
Siri!"

Are they just lying then?

There demo said they got siri to work with no iphone involved (in the end).

Also... DDoS would still be effective, no? (the server still has to 'filter')

> Hacks are admired here

You sure about that? A lot of China-bashing happens here based around it's
'Hacking' of U.S targets, I've never seen admiration of such things.

~~~
modeless
They're not lying. Anyone could _write_ an Android app that uses Siri, but it
would require the ID from an iPhone to work, so _distributing_ it would be
problematic.

~~~
jrockway
Why would that be problematic? You write a server that provides clients with
an iPhone ID that hasn't been banned from using Siri yet, and then you make
the app contact that server to get the ID.

I'm sure Apple would send a nastygram, but they send nastygrams if you scratch
your phone and don't get it repaired quickly enough. There is no law against
telling other people your phone's serial number. There is no law against
sending an HTTP request to an HTTP server for non-malicious reasons. So
really, I don't see much of a legal problem.

~~~
modeless
Where would you get the valid IDs? You can't share the same ID between very
many users, or Apple will ban it. You can't buy an iPhone for every user of
your Siri app. iPhone users won't willingly give you their IDs. Are you going
to somehow obtain and use the IDs of unsuspecting iPhone users without their
permission? That is likely illegal and definitely will get you sued and booted
from Android Market.

~~~
jrockway
My guess is that Apple will ban an ID after a day or two. My other guess is
that you can just keygen the ID.

