iOS7 Support and Discussion

[plamoni]

UPDATE:

Thanks for everyone's continued interest in SiriProxy. I know lots of people are really excited to get it "up and running" with iOS7. Now that the software is public, you're welcome to discuss bugs/issues on on this forum. However, keep two things in mind:

1: Only public releases of iOS are supported by SiriProxy I don't have a developer account with Apple right now, so I'm not under NDA (I never had access to pre-release iOS7), but my understanding is that the pre-release versions of the software point to a different set of servers from the production versions. Therefore, you'll have a number of issues as guzzoni.apple.com is hard-coded in in several places (and is an integral part of the SSL MITM cert generation process). This being the case, I highly recommend upgrading to the public release (NOT the GM release from earlier this week) before you file any bugs with SiriProxy.

2: SiriProxy has no full time development staff At this point, I'm the sole developer on SiriProxy. ElvisImpersonator does an AMAZING job at supporting the SiriProxy developer community, but doesn't work on the core development. Both of us have full time jobs that keep us extremely busy and neither of us get paid to work on SiriProxy. It's a labor of love (one that you're free to participate in through pull requests!).

That being said, I am on call this week and Elvis has, um, left the building (he's traveling for work), so it might be a week or more before I even get a chance to do testing on iOS7. So, as with before: UPDATE TO iOS7 AT YOUR OWN RISK. There's no official support for iOS7 in SiriProxy at this time and I can't make any guarantees it will ever work on iOS7. As with any new release of iOS, Apple could (any may already have) put in measures to block SiriProxy from working.

Again, thank you for your continued interest in my project. SiriProxy started out as a fun short-term project that kept me busy while I was between jobs and has turned into much more than I ever would have expected. I will continue to try and keep things working as long as I can and I'm always every excited to see the awesome projects that you, the SiriProxy development community, create! Keep up the great work and thanks again!!!

-Pete

---

Original:

Okay, so I'm watching the WWDC right now and there's lots of change to Siri coming. This means two things:

1: NEW BETA -- NO DISCUSSION

There's a beta out today for developers. Please remember that as an Apple Developer, you must agree to an NDA regarding unreleased applications (e.g. iOS7). This means that you should refrain from discussion of changes to the Siri protocol or functionality until iOS7 is publicly released. Once it's out for the public we can start working on fixing whatever it might break. Please do not open issues regarding problems when using iOS7 until it is publicly released. Elvis and I will close these tickets.

2: SiriProxy might break with beta software

As mentioned, a new iOS might mean changes to the Siri protocol. The iOS6 changes were minimal and I was able to fix them pretty quickly. No promises for iOS7 or future software. Hopefully it's something I'll be able to work with, but don't go upgrading devices if SiriProxy is important to you.

Thanks everyone for your interest!

-Pete

[bgottsch]

@Franchie I've been having the same issues as you. The iPhone would disconnect from the SiriProxy and try to create a new connection. I haven't had much time lately, but what I think is the problem is either the MPTCP or the new way Siri operates in the iPhone. Most likely it is the new way Siri operates since I also experienced this problem with cellular disabled (Wi-FI only). Maybe the iPhone expects something new from the server that the proxy isn't sending and so it tries to reconnect. Therefore this is only my assumption until now. I think the next step is to see the traffic being sent and received by the iPhone and compare it to older versions of iOS.

[Franchie]

@bgottsch Thanks for the update! Glad to hear you're having the same kind of issues, at least it means I'm not completely crazy yet! I'm also testing in Wifi-only mode for the moment in an attempt to capture all packets, but I'm not observing anything special being sent back from Guzzoni that would indicate that sort of change. Maybe a timing requirement? It is also possible, though I agree largely improbable, that the MPTCP is what is causing the breakup. If the aim of MPTCP on the server-side is to reassemble packets, and vice-versa, then the iPhone might require special MPTCP headers in order to assemble them properly, whereas with Guzzoni they are all being sent through the same connection so that issue is avoided. Like you, I don't have much time, but next week I might be able to get my hands on a MPTCP-capable router, and do the necessary testing and sniffing then. I'll let you know of anything I uncover. Please keep me informed of any changes you find between iOS versions when you get the time!

[matt-]

I am seeing the same issues with some really simple TCP proxy type servers which made me thing it was an MPTCP problem. However I sat up a VPN (which does not support kernel MPTCP) then out to Apple, and everything worked fine. I was even able to sniff the (encrypted) traffic. So I thought maybe apple was disabling MPTCP over VPN so I did the same DNS changes on the VPN server and put a simple socket proxy in place and ran into the same reconnect issues.

With a very simple socket proxy server all the timing and tls and everything should be fine and managed by the client. Im still a little up in the air on this one.

[plamoni]

I ran into the same problems that Matt did. By stripping SiriProxy down to a simple SSL MITM machine, I was able to see traffic flowing in both directions, but the client would disconnect abruptly and for no reason I could see. If I have time, I'll see if I can do more research on MPTCP (http://tools.ietf.org/html/rfc6182 -- yuck). Apple is pretty well known for "driving" standards a bit by adding their own special features. So it wouldn't surprise me if they didn't follow the letter of the standard. But I imagine that there's something to be learned from understanding it.

Unfortunately, I think that if it turns out MPTCP is the issue, the only solution might be to require kernel-level MPTCP support to run SiriProxy. Which at this point might limit SP to people who are comfortable compiling their own kernels.

I'm actually a web developer by trade, so this super low-level stuff is really out of my comfort zone. But I'll do what I can as time permits.

[djeraseit]

I just pulled the latest git. Been wanting to try SiriProxy for the longest but started to pursue this project before finding out iOS 7 breaks it. Not to worry, we'll get through this if we all work together as a team. We need a place to upload trace files. Hopefully you have good documentation of your code!

[matt-]

Can you post a gist of your simple SSL MITM? If it works over that and works over my VPN I assume its not MPTCP and maybe client certs or something. If it does end up being an MPTCP issue maybe with something like packetfu can be used to send raw packets (with the extra MPTCP flags) to talk to the guzzoni server.

[djeraseit]

Update. I turned off cellular data on my iphone 5, pulled the sim card, kept wifi on and siri worked just fine. This is NOT an issue with MPTCP. The server name IS still GUZZONI. Get that out of your heads.

I connected my iPhone to wifi and changed the ip, dns, and router to static. It points to my desktop running wireshark that basically acts as a router with DNSmasq answering DNS requests.

While I don't have a wireshark trace to compare to 6.0, I observed the initial SSL handshake and I'm going to have to agree with matt on this one, I think it is a certificate issue. Unfortunately I exited my notepad with all my notes without saving changes but luckily I still have Wireshark open. I think the certificate needs to be regenerated to use stronger encryption.

I'll have something concrete in the next few minutes if I can get SiriProxy to load :) I hate ruby.

[djeraseit]

oh, and i think apple makes a call to their servers for people trying to reverse engineer their servers. just fyi if you want to try this. you might want to null route gs-loc.apple.com

[oliverlavery]

Interesting RE: certificate issue. I've heard desktop Safari dropped support for MD5 in certificates due to well known weaknesses. It's encouraging that the issue might be as simple as using better MitM certs.

[Franchie]

Hello, quick update. I had some time last night and installed a MPTCP-compatible kernel onto my Raspberry PI, and ran a simple proxy server on it. Unfortunately I'm still seeing the same cutoff behaviour from the iPhone. Regarding the ideas mentioned above, here are my thoughts;

• VPN connections, I believe, transmit packet-level data which effectively makes the VPN receiver MPTCP-compatible. Since installing a proxy on that server forces higher-level (non-MPTCP) parsing, it is not impossible that this is the distinguishing factor between the two connection methods, making it work for VPN and not for the proxy.
• For the weak SSL certs, I believe that if this were a problem, it would be rejected during the SSL handshake, and no data would be transferred from the phone (it wouldn't make sense otherwise!). This is not what we are seeing, since data is transmitted, only for the connection to be cut off later. For this reason, I still believe MPTCP is the way to go, but either my implementation is wrong, or Apple is not using exactly the same MPTCP standard as the one I use... Either way, the digging continues...

[gmanfredax]

any news?

[Franchie]

Personally I haven't had any free time lately (gotta concentrate on this thing called a "job"). I have extracted some traces from a standard transmission, and one for the connection via my proxy. In theory, by looking at the differences between the two we should be able to identify the various factors that are currently problematic. I'll see when I can get down to it...

[yanniks]

Take your time. I'm waiting. :-)

[matt-]

I now 100% agree it is an MPTCP issue (as well as changes to the API). I spun up a free micro instance on AWS with the MTCP kernel with haproxy to forward 443 to guzzoni.apple.com. Then I made a really basic proxy server locally to talk to this server and Siri worked as expected. This server can be used to rewrite the API. If you want to test with my server change guzzoni.apple.com to 54.200.217.221.

This is doing a really basic port forward and all the encrypted traffic should still be encrypted meaning I should not have access to it on my test server. All that said.. it is a server that you dont control so use at your own risk.

The other idea I am playing with is using PacketFu to pretend to be MTCP from user land. I think you should be able to proxy the raw socket (including the MTCP headers). This might actually work the one problem is that when the guzzoni.apple.com sends a reply, because the kernel is no longer managing the packet it automatically sends a RST. How ever I think you could overcome this with IP tables and blocking the outbound RST to the apple server with something like: iptables -A OUTPUT -p tcp --tcp-flags RST RST -s [guzzoni.apple.com ip] -j DROP

Enough rambling from me. Let me know if anyone else has ideas.

[elvisimprsntr]

@matt-

Since you seem to have had some success using a MPTCP kernel, I am considering trying to crete a MPTCP kernel image for the Raspberry Pi, but tell me if I am head in the right direction.

1. Start with the Debian Wheezy SD image: http://www.raspberrypi.org/downloads
2. Follow the instructions here: http://multipath-tcp.org/pmwiki.php/Users/AptRepository Or this only works for x86 Intel processors?
3. Or do I have to re-compile the kernel from the source: http://multipath-tcp.org/pmwiki.php/Users/DoItYourself

[JBX028]

Rpi is supported no ?

http://multipath-tcp.org/pmwiki.php/Users/AptRepository

On a Debian Squeeze for the newest release: deb http://multipath-tcp.org/repos/apt/debian squeeze main On a Debian Wheezy for the newest release: deb http://multipath-tcp.org/repos/apt/debian wheezy main Currently we only offer 64-bit Ubuntu-images. For Debian Squeeze/Wheezy 32 and 64-bit is supported.

[elvisimprsntr]

@JBX028

The way I read it is binaries are only available for x86-32 and -64 processors. I would test on a Vbox Linux Guest OS, but VBox has some issues running on Mac OS X Mavericks.

[matt-]

I found this: https://github.com/fduchene/mptcp-rpi

[elvisimprsntr]

@matt- I saw that too. That repo seems a bit stale.

[alexrmc92]

VirtualBox 4.3.2 should have fixed most of the Mavericks issues.

[elvisimprsntr]

@alexrmc92 Thanks.

[Franchie]

@matt- There's a slightly more recent repo by the same people at https://github.com/multipath-tcp/mptcp-rpi, but I believe the codebase is the same.

[adorin]

@elvisimprsntr I can upload a raspberry pi kernel compiled with MPTCP support if you need one. @plamoni Can you share your stripped down version of SiriProxy, please ?

[elvisimprsntr]

@davasiloaei @Franchie

Awesome! Can your post a GIST with the steps to recompile the RPi kernel and settings for MPTCP support? https://gist.github.com

I managed to get MPTCP running on Ubuntu 13 Server VBox guest, but other priorities prevented me from analyzing the protocol, http://multipath-tcp.org/pmwiki.php/Users/Tools

[adorin]

@elvisimprsntr I wrote a quick gist for Ubuntu 13 here: https://gist.github.com/davasiloaei/7301598 I hope I didn't forget anything important.

[mping]

Hi guys,

I've been following the discussion. I have a question: MPTCP should be only an issue if you iPad/Phone has 3G right? My iPad doesn't have 3g, I'm gonna do a MITM proxy and see what I can find later. Thanks!

[elvisimprsntr]

Here is an excerpt from a correspondence I had with with Prof. Oliver Bonaventure himself:

QUESTIONS

1. Since SiriProxy is written in Ruby, it can be used on multiple host OS systems (Linux, Mac OS X, Windows). In order to emulate Apples' Siri server and MPTCP, do we need to run a MPTCP Linux kernel? Or,

If you want to completely support MPTCP, yes Linux is the only option. However, there are some networks where MPTCP does not work and where the MPTCP option is removed by firewalls. You might try to see how SIRI reacts when it contacts a regular TCP server. If this does not work, I'd suspect that this could be due to the utilisation of certificates over SSL than due to the utilisation of MPTCP

1. Is there some way we can retain platform OS independence using some means to force Siri to not use MPTCP, without requiring a jailbreak, and revert to a single TCP connection?

In theory, if an MPTCP host contacts a TCP-only server, it will fallback to TCP immediately, but I do not have details about Apple's implementation of MPTCP

[Franchie]

@elvisimprsntr Thanks for the info, I was also cc'ed in that mail, don't hesitate to contact me if you feel so inclined. @matt- Your MPTCP proxy seems to be the only one that actually works for the moment, and I'd love to be able to reproduce it. Is your proxy just doing port forwarding, or is it actually receiving and resending data? In the first case I was able to get SIRI to work, but not in the latter case, the connection is still disconnecting randomly. If that is what you're doing, would you be able to share the code for it so that I can test it on my setup?

[djeraseit]

How does MPTCP come into play if you remove the SIM card and turn off cellular data?

[gmanfredax]

but with the latter kernel, and activating the wifi or network vpn on the iPhone, does it work?

[adorin]

I've been trying to proxy the connection with the iPad in airplane mode and it behaves the same way. I was using a simple MITM proxy and Siri just closed the connection before I could forward the response from guzzoni.

The weird thing is that I was getting the same behaviour on an MPTCP capable kernel too.

[kixm]

@davasiloaei hello, one question, please can you make and upload a compiled rasperry(raspbian) kernel with mptcp and 802.11s and B.A.T.M.A.N activated if possible, i don't get it. sorry

[adorin]

@kixm follow my instructions carefully and you should be able to compile it yourself. https://gist.github.com/davasiloaei/7301598

If something is unclear, I can assist you. But I won't compile a customized kernel for you.

[alexrmc92]

Do we have any solid evidence that MPTCP is the culprit and not just a big protocol change? Does mavericks have a MPTCP stack? I won't be by my mac until monday so i can't do any tests on it now.

[elvisimprsntr]

The bug fixes in iOS 7.1 look interesting. http://bgr.com/2013/11/18/ios-7-1-beta-download-release/

[matt-]

Its either MPTCP or a client side cert or something. If you create a really basic SSL server and redirect all the request / response to the apple Guzzoni SSL server it should work.. (not changing anything just sending it through). However in my tests it has not. You get stuck where the apple server sends RST packets and closes all your connections even thought you are serving all of the "protocol" level stuff exactly as is from the phone. So either apple is killing all non MPTCP connections (even if you are only using one truck of the connection MPTCP still has extra headers in the TCP stack) or its some other issue like a client side cert. .

[dwery]

Maybe we can check that by stripping the TCP options with the TCPOPTSTRIP iptables target (or something similar)

[oliverlavery]

Hmm. This still works fine manually sending requests to Guzzoni. No disconnect, clearly no client cert requirement. The server isn't dropping the connection for the older User-agent:

Shadow:~ oliver$ openssl s_client -connect guzzoni.apple.com:443
CONNECTED(00000003)
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/businessCategory=Private Organization/serialNumber=C0806592/C=US/postalCode=95014/ST=California/L=Cupertino/street=1 Infinite Loop/O=Apple Inc./OU=Siri/CN=guzzoni.apple.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF9jCCBN6gAwIBAgIQSZEWiH/aMGEboxmnJik+ATANBgkqhkiG9w0BAQUFADCB
vjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE4MDYGA1UEAxMv
VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBTR0MgQ0Ew
HhcNMTMwNzEwMDAwMDAwWhcNMTUwNzEwMjM1OTU5WjCCAQQxEzARBgsrBgEEAYI3
PAIBAxMCVVMxGzAZBgsrBgEEAYI3PAIBAhMKQ2FsaWZvcm5pYTEdMBsGA1UEDxMU
UHJpdmF0ZSBPcmdhbml6YXRpb24xETAPBgNVBAUTCEMwODA2NTkyMQswCQYDVQQG
EwJVUzEOMAwGA1UEERQFOTUwMTQxEzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNV
BAcUCUN1cGVydGlubzEYMBYGA1UECRQPMSBJbmZpbml0ZSBMb29wMRMwEQYDVQQK
FApBcHBsZSBJbmMuMQ0wCwYDVQQLFARTaXJpMRowGAYDVQQDFBFndXp6b25pLmFw
cGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK/Ap99Cux1+
0RdrFtI7kg6K4UpjIEk2Ih2u07/pQy/pnOD9KpVlaz1NwD3uzQSAi/DO8HORHl9+
PL/j9S/rs7AUxTVNpBLWMuHGPOfh1VBpo9xL0V1I1KlNHKtkD0/iSz1poekjQXXm
1oFYcH7Fts6WKuzDq3wOwS4YNnFbAYS0r+OHWauTm4XuYEC0y7vXoWPdNFaMMTJY
2F5PsdoKLS7PJ0Ej27snMDR4QpNoV3wLOjAzbJ/Av6eZv0t2MSwNm2VnorZ+YbrP
NmSiB1EvawnB9Mra5BXqWxaRsYRR3jtME0jYqFqDl6l2hCBcHbkjUCmZfYed5N5J
/0dzRN51NGkCAwEAAaOCAaUwggGhMBwGA1UdEQQVMBOCEWd1enpvbmkuYXBwbGUu
Y29tMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgWgMCgGA1UdJQQhMB8GCCsGAQUF
BwMBBggrBgEFBQcDAgYJYIZIAYb4QgQBMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH
FwYwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAd
BgNVHQ4EFgQU6pger8bO2dnjOhRkDKGscLpi0gcwHwYDVR0jBBgwFoAUTkPIHXbv
N1N6T/JYb5TzOOLVvd8wPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL0VWSW50bC1j
cmwudmVyaXNpZ24uY29tL0VWSW50bDIwMDYuY3JsMHYGCCsGAQUFBwEBBGowaDAr
BggrBgEFBQcwAYYfaHR0cDovL0VWSW50bC1vY3NwLnZlcmlzaWduLmNvbTA5Bggr
BgEFBQcwAoYtaHR0cDovL0VWSW50bC1haWEudmVyaXNpZ24uY29tL0VWSW50bDIw
MDYuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQCtfB9mMibP5tLBpSXHomoU71pfMrFW
+4bOeJWYo5y7JVTlQB5wmHzpJOTb4Mkcu5CxTwaevwNi4zi5K2qXAOm/ulQkP5FQ
ft7Mz14HjkpdXF4XEpO4iFySyaKUqMAb+KC+SO5BBC+E+C46fjbISjpGbdGfCNTd
jFwIhmHf1Up2eMnl81bFipIrEZ8WYyuEtadACDQe3UuybzZsgQqjcV2eWzpm7xdy
dgiDjM/fFDVTWfdY6BvfaXvfhZpXkvyI6blgf+uFF+z2kYSdSCz7DLf/IiPzlggk
+rTyKXeQfiaxd0XYUyLR9XT8U+jUKxgPzQAqk3b12otxjH1nPW960N5F
-----END CERTIFICATE-----
subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/businessCategory=Private Organization/serialNumber=C0806592/C=US/postalCode=95014/ST=California/L=Cupertino/street=1 Infinite Loop/O=Apple Inc./OU=Siri/CN=guzzoni.apple.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 3246 bytes and written 632 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 5F592DB0E9C4638547EC17C973497431C15DE3D341DEDE458B792D15966C6D14
    Session-ID-ctx: 
    Master-Key: 16724A60C02E3B9687C72E26DC183584A783AD1C6FAA9E5EEE775621B85BD1DAE0606E1CFF503F35FF7CBC15C381C794
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1384875129
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
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

HTTP/1.0 200 OK

And updating the user agent. Same thing, server seems happy:

Shadow:~ oliver$ openssl s_client -connect guzzoni.apple.com:443
CONNECTED(00000003)
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
[...snip...]
---
ACE /ace HTTP/1.0
Host: guzzoni.apple.com
User-Agent: Assistant(iPhone/iPhone5; iPhone OS/7.0/9A334) Ace/1.0
Content-Length: 2000000000
X-Ace-Host: 4620a9aa-88f4-4ac1-a49d-e2012910921

HTTP/1.0 200 OK

That connection stays open fine unless I send another request (which I'm assuming is a protocol violation). I don't know but this really seems like an application layer problem, not a transport layer one to me.

Has anyone middled the SSL and intercepted the app protocol up until the disconnect? It would be interesting to see what's being sent back and forth...

[oliverlavery]

Hey, is there a way to instruct Siri to use an outbound HTTP proxy?

[dwery]

@oliverlavery maybe it uses the system proxy. it makes sense. I'd try setting up a proxy in the system pref and, if it doesn't use it, block requests from the iPhone to guzzoni and see if it reverts to the proxy.

[TriceLaFleur]

Has anyone made any breakthroughs for getting siri proxy to work on iOS 7?

[TriceLaFleur]

Will it work if I just use Linux?

[fluke9]

I just looked at what i can see (yes i have the same issue, the apple server closes down violently), however if i paste a request with s_client it takes it fine.

I noticed one thing: X-Ace-Host: has now the first part of the dns record of the "cluster server" replied by akadns.

For example if you got the following dns response for guzzoni.apple.com: guzzoni.apple.com is an alias for origin.guzzoni-apple.com.akadns.net. origin.guzzoni-apple.com.akadns.net is an alias for mu21p01sa.guzzoni-apple.com.akadns.net. mu21p01sa.guzzoni-apple.com.akadns.net has address 17.130.16.4

Your X-Ace-Host will then be: X-Ace-Host: mu21p01sa:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

So what if the phone does not only send it in the X-Ace-Host header but in the payload too, and siriproxys fake dns facility will most likely only provide an a record, so it will have no/invalid data for its "cluster-server" and guzzoni or the phone closes down (wrong clusterservername in the response/request) ?

I tried to replicate that CNAME cascade using dnsmasq, but i could not do it so far, only works if i do an a record, might do my own dns proxy code to test.

Anyone got an idea how to test this even quicker ?

[adorin]

You can replicate the DNS by changing dns.rb like this:

match(/guzzoni\.apple\.com/) do |transaction|
  cname = 'origin.guzzoni-apple.com.akadns.net'
  transaction.respond!(Resolv::DNS::Name.create(cname), :resource_class => Resolv::DNS::Resource::IN::CNAME)
  transaction.append_query!(cname, Resolv::DNS::Resource::IN::CNAME)
end

match(/origin\.guzzoni-apple\.com\.akadns\.net/) do |transaction|
  cname = 'mu21p01sa.guzzoni-apple.com.akadns.net'
  transaction.respond!(Resolv::DNS::Name.create(cname), :resource_class => Resolv::DNS::Resource::IN::CNAME)
  transaction.append_query!(cname, Resolv::DNS::Resource::IN::A)
end

match(/mu21p01sa\.guzzoni-apple\.com\.akadns\.net/) do |transaction|
  transaction.respond!(server_ip)
end

# Default DNS handler
otherwise do |transaction|
  transaction.passthrough!(upstream) unless transaction.query.question.to_s.match /guzzoni/
end

Lookup:

$ dig guzzoni.apple.com @192.168.1.18
; <<>> DiG 9.8.3-P1 <<>> guzzoni.apple.com @192.168.1.18
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40473
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;guzzoni.apple.com.             IN      A

;; ANSWER SECTION:
guzzoni.apple.com.      16000   IN      CNAME   origin.guzzoni-apple.com.akadns.net.
origin.guzzoni-apple.com.akadns.net. 16000 IN CNAME mu21p01sa.guzzoni-apple.com.akadns.net.
mu21p01sa.guzzoni-apple.com.akadns.net. 16000 IN A 192.168.1.18

;; Query time: 7 msec
;; SERVER: 192.168.1.18#53(192.168.1.18)
;; WHEN: Sun Dec 22 17:12:54 2013
;; MSG SIZE  rcvd: 124

[martimarkov]

Can anyone tell me what is the status of SiriProxy for iOS 7?

[vitormhenrique]

if you read the messages, they are still working on it, asking it every single day does not make it faster or even help... they use their own spare time to work on this project, every body is excited and want the siriproxy working on iOS7... so patience, hopefully it will work someday, but, there is the chance that it won't work at all.

[Timvdv]

I appreciate it a lot that so many people are working on this. Since the IOS7 Jailbreak, will this speed up the development process?

Also I would like to help, but I'm no Ruby or DNS expert and I have no idea where to start.

[elvisimprsntr]

@Timvdv and everyone,

SiriProxy did not require a JB in order to add custom actions and responses. The objective is to continue to keep it that way. Any discussion or pull requests not consistent with that objective will simply be ignored or closed. Please keep in mind that Pete and others are working on it, but everyone has a regular full time job which often consumes the majority of our waking hours.

This is the time of year to spend precious time with family and friends. Your patience and understanding is greatly appreciated.

Have a safe and happy holiday.

Elvis

[martimarkov]

I just didn't want and understood all the comments as to what is the current progress. The problem should not be kept in one bug report but in many so that is more clean. I would love to help and I do have skills but if I had to read so many comments to get an ideas of what is not working... Well that is just not going to work for me as I tend to fix one problem at a time. For example it's really hard to have a complete understanding of what is not working in order to understand why and then try to fix it for new developer coming to this project as me. I have waited for some time hoping to have the project working at some point and use it with my jailbreak tweaks and I wanted to know what is the status.

I now know that the application is not working ATM but still don't know exactly why. So my suggestion is we make a wiki and or some sort of collaborative way to share our findings and structure them the same way as theiphonewiki. I can provide the hosting for all that but I would really love to see this project organised so that other people interested can get up to speed.

With all that said I will go through all the comments tomorrow and try to extract different problems and classify them. I just want to know if any one would be interested in a wiki or as I said already any other way to share the findings and have the up there on the web. If you do please suggest it to me so that I can set it up and put them all in one place.

I just want this want to help get this working as fast as we can. I can spend a lot of time on it as I guess others as well and it would be a shame to lose that because the way we share our findings is tons of comments in a bug tracker on a single ticket.

I'm not saying I'm right to say this is bad. This my own opinion and might be wrong. Also I don't want to turn this into an argument and spam the bug tracker. I'm just proposing an alternative hoping it might be beneficial for the project.

Thank You in advance, Marti Markov Studying Computer Science in the University of Southampton

On 23 Dec 2013, at 20:34, "vitormhenrique" notifications@github.com wrote:

if you read the messages, they are still working on it, asking it every single day does not make it faster or even help... they use their own spare time to work on this project, every body is excited and want the siriproxy working on iOS7... so patience, hopefully it will work someday, but, there is the chance that it won't work at all.

— Reply to this email directly or view it on GitHub.

[elvisimprsntr]

@martimarkov Thanks for your interest and enthusiasm. No need to host a separate Wiki when you can simply add on to this repo. Feel free to categorize and summarize the issues and attempts.

https://github.com/plamoni/SiriProxy/wiki/_pages