-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Airplay to Apple TV With TVOS 10.2 is broken #377
Comments
Thanks for the heads up. I will look into it, but I am not very optimistic about being able to solve it. Looks like it might be a hard nut to crack. I also don't have a ATV 4th gen, though perhaps testing on a 3rd gen with Device Verification enabled is good enough. I will add a few warnings to the docs about upgrading to tvOS 10.2. |
I'm not very happy with Apple right now. My Apple TV auto updated and by the time I realized daapd doesn't work with 10.2, they've apparently stopped signing signing 10.1.1, so I can't downgrade. Unbeliebly annoying to be unable to stream to my Apple TV for the foreseeable future. |
Maybe this project could get some help by Beamer, AirParrot or DoubleTwist? They have managed the verification-process. |
Yes, might be worth a try. However, I'm still prevented from doing much about this as I don't have a new ATV. So even if I got the procedure spelled out, I couldn't implement it. If some ATV owner wants to take a crack at this it would be a blessing. I am trying to borrow an ATV, though. I'm also thinking that perhaps the verification is like the Remote pairing? It would certainly be lucky if it was. |
Today I realized that I can manually enforce the encryption on my ATV v3: This can also be used for the analysis/implementation! I'm not sure if the procedure is equal to the Remote-pairing, but this might be possible. |
I got my hands on a ATV3 to see if I could figure out how to do the device verification. So far no luck. It does seem to be based on SRP, so I made this little program for testing that implements the basic flow: https://github.com/ejurgensen/atv_verification (see pair.c) It currently fails to verify at step 3. The proof which is calculated is apparently incorrect. The possible reasons for that are numerous - for instance I am not sure where exactly the username that is used is supposed to come from. I just copied the one I could see being sent. It is also an open question if SHA1 is the correct hashing algorithm to use. I see that Airfoil has also now cracked the nut, and they also mentioned that no secret keys are needed. So it is clearly doable. I'm hoping the force of open source will show, and someone will take a stab at this. |
Hey there, please check my "AirplayAuth"-, project committed today.
It's a fully working java library :-)
Am 26.05.2017 12:41 vorm. schrieb "ejurgensen" <notifications@github.com>:
… I got my hands on a ATV3 to see if I could figure out how to do the device
verification. So far no luck. It does seem to be based on SRP, so I made
this little program for testing that implements the basic flow:
https://github.com/ejurgensen/atv_verification
It currently fails to verify at step 3. The proof which is calculated is
apparently incorrect. The possible reasons for that are numerous - for
instance I am not sure where exactly the username that is used is supposed
to come from. I just copied the one I could see being sent. It is also an
open question if SHA1 is the correct hashing algorithm to use.
I see that Airfoil has also now cracked the nut, and they also mentioned
that no secret keys are needed. So it is clearly doable. I'm hoping the
force of open source will show, and someone will take a crack at this.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#377 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZmMD6wTvKc28O82-exQLqzzkm3u-Vsks5r9gODgaJpZM4M-BKO>
.
|
@ejurgensen Here's the link: https://github.com/funtax/AirPlayAuth The username doesn't matter, I'm randomly generating it.. you just have to store your username with the eddsa-keypair for later authentication (that's why I'm simply putting them together into a string and split them later when used). Step 3 is indeed the hardest one: Follow my code here step by step. Hope it helps, congrats on your work! |
Wow, the force of open source materialized, and it did so pretty quickly! Seems very impressive what you have done. I haven't looked at it yet, but will asap. I can't begin to imagine how you found about the custom modifications to SRP. I'm not that strong with Java, so I might get back to you with some questions. |
Gladly I was able to reverse-engineer/decompile another closed-source
software nearly to its source code which was not written in Java, and
create a small test-app written in their language with their libraries.
Then I could call their code within my code via HTTP and go through it step
by step.
I cannot imagine this could have been done without any leaks from Apple
within this short time. PairSetup3 and PairVerify seem to be too complex to
me, to be reverse-engineered without any leaked information in such a quick
time.
Feel free to contact me in case of questions - I'm not using your project
but maybe I can help somehow.
2017-05-26 10:13 GMT+02:00 ejurgensen <notifications@github.com>:
… Wow, the force of open source materialized, and it did so pretty quickly!
Seems very impressive what you have done. I haven't looked at it yet, but
will asap. I can't begin to imagine how you found about the custom
modifications to SRP.
I'm not that strong with Java, so I might get back to you with some
questions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#377 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZmMNjP8ra28vSb-PmPrECxPzg3DNbBks5r9ombgaJpZM4M-BKO>
.
|
I started working on this and thanks to your awesome work funtax I expect to fix this in forked-daapd within a few weeks. It seems I will need to add a dependency to something like libsodium to get EdDSA, so that is a pity. Those Apple customizations are really weird. I especially wonder what the point of this one is: In most cases it just increases the rightmost byte by one, except if it wraps around in which case it proceeds left? And btw, why lengthA and B - aren't they always equal? |
Hey @ejurgensen I have reversed another (obfuscated!) program and this was the line I didn't understand on the first go. Leaving it out didn't work so I just copied it 1:1 into Java-code. On the first view, yes, one variable seems to be obsolete. For the edDSA-stuff, search for "ed25519 supercop" which is the essence of this library. |
Thank you so much! You did a really great job! @funtax I’m trying to port your implementation in Java to Objective-C. For the edDSA-stuff I use ed25519, as you suggested. Please take a look at my code. |
@ViktoriiaKh I love to see how this is growing, that's exactly what I hoped for. In doPairVerify2WithData() line 482+483 the aesKeyStr + aesIVStr must be "Pair-Verify-AES-Key" and "Pair-Verify-AES-IV" instead of "..-Setup-.."" as in PairSetup3-step. Good chance that it's working then. Ps. I will remove Objective-C off my "languages I like to learn"-list ;-) |
@funtax thank you very much!!! |
@ViktoriiaKh I'm happy to read this 👍 @ViktoriiaKh & @ejurgensen In case you like to "chat" about anything related to this via e-mail, type the java-package-Webaddress into your browser and follow it until you reach the corresponding app on Google-Play and use the support-address there. I just don't want to publish mine here ;-) |
Could someone with the latest ATVv4 capture the TXT-records of the device (.raop.tcp.local)? I have no ATVv4 here and would like to use the version-part to determine if authorization is required. Maybe @anjo03 ? |
@funtax deviceid = <43383a36 393a4344 3a33383a 36413a30 43>; To determine whether a device verification is enabled I use the following code (I have reverse-engineered one application with AirPlay support):
|
@ViktoriiaKh Awesome, would be super great if this is working. I darkly remember that the values haven't changed when I switched the protection on/off.. maybe it was buffering and I have to check this again. |
@ViktoriiaKh Can you double-check your solution somehow? "sf" for raop is the same as "flags" for "airplay": With verification enabled: Without verification (disabled): |
@funtax I went to the country for the weekend and I do not have my ATV on hand at the moment. I'll be back in two days. I'll double-check everything and write you as soon as I can. |
@ViktoriiaKh No problem, thanks anyway :) Happy casting! |
I'm a bit behind you guys, but now I also have my C version working and in a clean(ish) state. Once again kudos for some excellent work, @funtax. I also peeked at your ObjC version @ViktoriiaKh and that was also great guidance. For the purpose of future inclusion in forked-daapd I brought it down to a single .h and .c file, where I included only the srp stuff required for the verification. I decided to go with libsodium, mainly because I didn't feel like including thousands of lines of crypto code in forked-daapd that I don't comprehend. I guess openssl is getting the required 25519 crypto stuff too, so then I can drop the libsodium dependency and just rely on openssl. Now the next part is getting the verification flow built into forked-daapd, so I will also have to figure out when to enable pairing, like you discussed above. Right now my idea is to not use the TXT, but to do something like this: Do I know the device and have an auth key for it? Then verify with the device. If not, try OPTIONS, and if I get an access denied response, initiate pairing. Shouldn't that work? I also haven't really tried actually streaming anything to the device yet - I wonder if some crypto will be required for that? I think I read somewhere about ChaCha being used. |
Hey @ejurgensen , I'm happy to read your update! Once your have "pair-verified" your TCP-connection, you don't need to change anything else - just use that authenticated connection for the further communication. "pyATV" reworked my template into Python.. maybe this might help you or anyone else somehow: I'm looking forward to your work 👍 |
Yes I noticed, but I will be streaming directly to the device, not just giving a link to external media. I am thinking that perhaps the whole point of Apple's change in 10.2 is protecting that link against eavesdropping? Maybe they need to guarantee to iTunes content providers that the entire chain is DRM'ed? Otherwise I don't really get the point of it all. But maybe there is none... |
Uhh, okay that's something I don't know. I didn't had to implement any new for the realtime audio-transmission (as done as in iTunes), so I'm thinking positive that it's also not required in your case :) |
Hah, I didn't ever read what this project is meant for. |
Cool, that's a great relief! |
@funtax I’ve examined the TXT-records associated with the AirPlay and RAOP services on two Apple TVs (2nd and 4th generation), and the check whether the device verification is enabled works for me. Here are the results for AppleTV2,1: _airplay._tcp With verification enabled:
With verification disabled:
_raop._tcp With verification enabled:
With verification disabled:
|
My ATV3 (_raop._tcp):
Now I will try enabling, then disabling and waiting a while (and with no restarts). |
Thank you @ViktoriiaKh & @ejurgensen, that's really interesting! But for my case it's done via the simple am-matching :) |
Oh no, another cat 'n mice challenge :( Seems like the receivers that support Fairplay, re-use Apple's binaries (sometimes via remote-access) to do the handshake. I hope we can also get this challenge done. |
Really bad news, especially now that the other challenge was just solved. Apple sure is doing its best at promoting Chromecast. I thought Fairplay relied on Apple ID? Perhaps that is not so? If it does, then how does it work if neither the sender nor the receiver is logged in via Apple ID? |
Hello, guys!
The curious thing is that even device verification is not required. |
… 10.2 (fix for issue #377) - also change how speakers are saved/retrieved from the db - add generic authorization methods in outputs.c and player.c - let filescanner read *.verification files (containing PIN) - configure options to enable and disable, since libsodium is required
Good, that's really a relief. Strange if they are abandoning verification again - perhaps poor user feedback on 10.2? Do you have an idea how iTunes determines if should use text/parameters or application/x-apple-binary-plist for SET_PARAMETER requests? That is, if it ever uses the latter - I only have a ATV3 to test with, and iTunes is using text/parameters towards it. |
The issue should now be fixed, so that forked-daapd now supports device verification (see README for instructions). This is with a lot of thanks to the work of @funtax. |
Hey all. First of all: Thanks for all your hard work and effort of making this work!!! Maybe my setup is wrong somehow, but the initial verification works flawlessly, but after a restart/crash of the forked-daapd daemon, I need to re-verify the Apple TV again and again. Any idea why? |
Yes, forked-daapd saves speaker settings (incl auth keys) when it exits. I didn't change that here, but I probably should. The current behavior means settings are lost if forked-daapd crashes. Of course, it shouldn't be crashing, so please open an issue on that (with steps to reproduce if you can). Little workaround: If you verify and restart before the crash then the key will be saved, and you won't need to verify again. |
Thank. It works and makes sense as you describe it.
Sendt fra min iPhone
… Den 24. jun. 2017 kl. 12.26 skrev ejurgensen ***@***.***>:
Yes, forked-daapd saves speaker settings (incl auth keys) when it exits. I didn't change that here, but I probably should. The current behavior means settings are lost if forked-daapd crashes. Of course, it shouldn't be crashing, so please open an issue on that (with steps to reproduce if you can).
Little workaround: If you verify and restart before the crash then the key will be saved, and you won't need to verify again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Closing, should be fixed with 44fad55 |
I am unable to pair with an ATV4. My log says:
I included the password in the config file and set the AirPlay authentication to password. While trying to install the latest version from github, I also got some errors during
Or does this only apply for the freebsd script, which is not necessary on my debian system anyway? |
For pairing with an ATV4 you should not put a password in the config file. Please check the instructions here: https://github.com/ejurgensen/forked-daapd#airplay-devicesspeakers Thanks for notifying about the install error. It should be fixed now. |
It wasn't clear that I have to use the PIN method and that the password version does not work for tvOS 10.2 anymore. I got it working know using the PIN / Code setup. Thanks for the support! |
For those interested, pairing with Apple TV implemented in nodejs: https://github.com/marcklefter/node-appletv-pairing.git |
TVOS 10.2 requires Device Verification, which cannot be turned off anymore.
Since forked-daapd does not support Device Verification I am not able to stream music to my Apple TV anymore. I can see that Airparrot has found a work-around. Is it possible for you to update forked-daapd to reenable this feature again? Thanks in advance
The text was updated successfully, but these errors were encountered: