Legacy pairing and pin-pair-start protocol (was Change the value of "SupportsLegacyPairing" from 1 to 0 results in the failure of decoding.) #176
Comments
|
Sorry, we dont know how to do non-legacy pairing. UxPlay only supports Legacy pairing. pyatv seems to have made some progress in the direction of understanding the AirPlay 2 protocols |
nenseso
changed the title
|
Closing because this is a feature not a bug .... It would be great if the more recent protocols could be supported, because Apple could withdraw support for "Legacy paring" at any time there is a major update of iOS. The difficulty is all the cryptography involved.... |
|
I tested that set old_protocol =true seems to be able to decrypt and a fast connection |
|
can you describe in more details what you managed to do? I discovered that this had to be skipped for a windows airplay emulator AirMyPc to work (a teacher was teaching a class where some pupils had iPad, others had microsoft surface devices with AirMyPc on those.) I always wondered why this worked. Are you reporting that if "supports legacy pairing" (features bit 27) is switched off and "old_protocol"=true, that UxPlay still works? |
|
My English is not good, hope you can understand. |
|
In short, don't use ecdh_secret for the key when using 0x527FFEE6 |
|
How do we know when to use 0x527FFEE6 instead of 0x5A7FFEE6 (bit 27 = 0) for "features"? Which software (other than AirMyPc) wants this? How does it tell this to UxPlay? |
|
I think AirMyPc ignores the features flag that it only uses one encryption method. |
|
@shuax are you suggesting that if bit 27 is switched off, and "old_protocol"=true, UxPlay will still always work with iOS and macOS clients, ? |
|
Yes, I am using my ipad for testing. I suggest not to use ecdh_secret when no pair message is received. |
|
which pair message do you mean? |
|
When bit 27 is false, there seems not call /pair-setup. |
|
I am testing and I agree with you so far. Very interesting But since things are working , is there any reason to change uxplay to use bit 27 = 0 ? The only problem case was the AirMyPC client, and that is fixed. |
|
set bit 27 = 0 connection will be much faster, I recommend this |
|
how much faster? Usually one just connects a few times at most? |
|
any easy initial thing would be to add code to test whether bit 27 was set, and switch off the hashing step if it is not. EDIT: I see the missing pair setup when bit 27 is not set. You are probably right to test for that. |
|
It will connect about 5 seconds before the modification, and it will connect 1 second after the modification. |
|
Interesting. some option for "fast connection without pairing" could be added |
|
In principle, pairing is supposed to allow multiple clients (up to 16) to connect simultaneously to AppleTv, each with a unique SessionID created in pair setup but we dont have the details for setting this and dont allow it. |
|
I just test SupportsLegacyPairing, and I don't know much about other knowledge. |
|
@shuax It's great that you are discovering new things about the protocol! |
|
I can corroborate that this works. In regard to "It will connect about 5 seconds before the modification, and it will connect 1 second after the modification." As we can see from wireshark recordings, the ios device doesn't actually send any messages to the server (apart from a possible mdns query?) for several seconds, until it finally makes the connection. If we change the FEATURES flags as shuax described, this delay is entirely gone. I think that the ios device must be generating some sort of encryption keys... but this shouldn't take 3-4 seconds. Possible hypothesis are that the fun "apple way" connecting all your devices together - it will attempt to use the internet to reach your other apple devices / icloud to see if there is a valid pairing key out there. Using MITMProxy it doesn't appear to be doing this, but I can't be sure. Someone with most likely an apple tv 2 (or 1?) will need to see if this delay exists on first pair. |
|
Yes I've tested. In the test I add (bool) comm->pairing_request_received initially false, and set it true if pair_setup takes place, to decide whether to do the hash. I can make this change for now, and decide later whether to change the features flag, or make some option for doing that. |
|
latest github is updated so bit27 can be switched off by uncommenting a line in lib/dnssdint.h (and commenting out the line above) Before making the final switch bit27 = OFF, I am thinking about whether to make another option to restore previous behavior. any thoughts on this? |
|
Updates to use @shuax 's find are tested and now in the github master branch, for a future UxPlay-1.65 release |
|
The choice to reset features bit 27 to "on" is now provided by an option "-pair" in the "testing" branch of UxPlay. This will probably be in UxPlay-1.67 when it is released, and might be useful if some newer protocols described in pyatv ever get implemented, like displaying a code on the screen, which need pairing. |
|
Are you trying to research pairing codes? This code may be useful. |
|
@shuax thanks! will take a look when I have time to see if any new features are in that code variant.
|
|
Possible sources of info for pin-pair-start protocol seem to be: serezhka/java-airplay-server#5 https://github.com/warren-bank/Java-AirPlay2-Receiver https://github.com/openairplay/AirPlayAuth Added (notes from Warren Bank ): |
fduncanh
changed the title
fduncanh
changed the title
I recently altered the 27th bit of the features field by modifying the value of "SupportsLegacyPairing" from 1 to 0. I achieved this by changing the following code:
to:
However, this modification resulted in the failure of decryption. I am seeking guidance on how to modify the code in order to ensure successful decryption. Can you please help me with this issue?
The text was updated successfully, but these errors were encountered: