Cracking Siri(applidium.com) |
Cracking Siri(applidium.com) |
Slide deck: http://www-rn.informatik.uni-bremen.de/ietf/rohc/ace-033100-...
Whitepaper: http://w3.ualg.pt/~bamine/B3.pdf
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.
Especially when you are a startup, building the perfect protocol isn't your biggest concern. Being able to reuse already existing components like load balancers and connection libraries allows you to get your MVP out sooner.
That's how tools like Corkscrew can tunnel SSH (and practically any other TCP-based protocol) over an HTTPS connection.
I'd quite like to be able to add calendar entries or tweet without moving to another application.
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.
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.
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?
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.
If you're just using it for personal reasons, why should Apple care?
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.
There is no bug. This is what SSL will do, when you install additional certificates.
(Oh, and it's a fun way to find new web services to play with.) :-)
edit (because I can't reply): It does show a big warning and you have to enter the device unlock code to do this, so it should be reasonably safe.
I don't know what Apple's excuse is though, but limited processing power is certainly not a problem.
> The iPhone 4S really sends raw audio data. It’s compressed using the Speex audio codec, which makes sense as it’s a codec specifically tailored for VoIP.
There are three parts to Siri:
1. Speech-to-text (parent has it backwards but that's what he means, obviously)
2. Text-to-intent (referred to by parent as NLP)
3. Intent-to-API calls
Obviously, (1) happens in the cloud and (3) happens on the device. It is still unclear where (2) happens but if the cloud service only responds with text, it seems that (2) happens on the device.
And (2) is still a hard problem by itself.
What did Apple miss? (in other words: how could they avoid this, assuming they wanted to avoid such crack)
Thanks!
So if I'm reading this right, Apple is sending UDIDs over HTTP?
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!")
That's really gross, and exactly the kind of design choice Apple never makes.
http://www.ifixit.com/blog/blog/2011/11/09/little-sister-sir...
This means that Siri won't provide optimum experience (pick the phone to ear and Siri is ready to take the command) for iPhone4 and older versions.
But this is the future and I want my jetpack/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.
You're asking that on a site called 'Hacker News' if I'm not mistaken. It is indeed a 'hack', a clever and skilled exploration of technology carried out with perfectly good or neutral intent.
My initial post (which has been down voted out of existence) is a valid point.
I don't actually care whether Apple get hacked or not. I was curious what people thought of publishing a 'hack/crack' like this.
Lots of rationalising going on, but to me it still seems wrong. I'd hate people to leverage my work (even for 'personal use') without my permission. Interesting how 'hackers' are happy to hack other peoples stuff, but cry out when it's their own stuff getting hacked.
In the United States, reverse engineering is entirely lawful. It is even made explicitly clear in the DMCA that reverse engineering is allowed. Which part are you specifically worried the most about?
> With this information, (if I'm not wrong) it wouldn't take long to simply DDoS Siri...
This is just scaremongering. Knowing an IP address is enough to DDoS a server. Are you suggesting that it's somehow unethical to independently publish the location of a publicly-available server? Are you also going to indict the DNS server that gave it to them?
> Or port Siri to Android (effectively stealing IP).
Theft relates to physical property. I'm not sure what would be stolen here as Apple still controls the Siri server and requires a unique iPhone 4S ID to be used. Again, though, reverse engineering for the purpose of interoperability is legal in the United States. There's no way to frame this as stealing.
> (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!")
This is a red herring. Your proposed situation suggest a security vulnerability of some kind wherein Dropbox hypothetically allowed someone access without paying. No such vulnerability to Siri was found; all requests to the Siri server were made using a valid phone id and returned valid, official responses.
The only thing that's unclear to me is if the anti-circumvention portion of the DMCA extends to technology used but not created by the author e.g. Apple did not create SSL but they use it to secure transmission - does this make spoofing an SSL certificate an instance where the DMCA's anti-circumvention law would come into play?
Any competitor's jealous of Siri aren't learning too much to find out that the client uses HTTP, compression, and binary payloads in what it sends over the wire to the Siri service - the magic is server-side. The client has to communicate with the service somehow.
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.
And yes, we are going to help each other improve the security of our systems. If we don't, someone malicious will.
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.
It's not unreasonable to assume at Apple won't do anything but it's risky.
Negative. Siri remembers the context of your conversation.
When the proxy failed, they "ressorted (sic) to using tcpdump on a network gateway". They eventually had to "setup a custom SSL certification authority, add it to our iPhone 4S, and use it to sign our very own certificate"
On the other hand, I'm pretty sure Siri doesn't have to communicate with your company's internal servers (and my paranoia already suggests a malicious IT department, reckless — and probably illegal — as that would be), so the code should, in my opinion, accept only specific CAs.
Great for debugging third party https stuff.
http://www.readwriteweb.com/archives/dear_iphone_users_your_...
(I hope the app store magical-vetting-code is smart enough to ensure the new hit app "Somewhat Annoyed Birds" isn't capable of fishing around in the phone for the Siri ID and sending it back to the developers website along with the high score you just got...)
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.
Got it! :)
"The iPhone 4S sends identifiers everywhere. So if you want to use Siri on another device, you still need the identfier of at least one iPhone 4S. Of course we’re not publishing ours"