Closed fduncanh closed 2 years ago
Hers is the debug output for the failed connection to AirMyPC client
Here is the debug output for a successful connection to an Apple client.
this night's provisional end: "... Its the port, when you not using mDNS it uses the default port so it can not connect. We will add the change in the code and will send you a new installer soon. In meantime you can delete the directconnect entry and re enable the mDNS
Sincerely, AirMyPC Support
On 12/13/2021 2:44 AM, arararar wrote:
mDNS recognizes uxplay as "appletv2" the ip in the list is recognized as "appletv" without leading + same with the leading + ..."
@arararar get the AirMyPC guys to look at the debug traces for AIrMyPC and IPad in the preceding comments.
This is nothing to do with ports, it certainly does connect....
If it is just an issue of altering what kind of Apple TV server UxPlay describes itself to AirMyPC as, this is easy to fix with an option
@arararar
Its decryption. If the AirMyPC thinks uxplay is an ancient airplay1 device, and uses an old decryption protocol, that could be an explanation of the failure to decrypt.
If AirMyPc needs special ports, set them with the -p option.
@arararar
GOOD NEWS!
I found that the audio works with AirMyPC if I skip the step of the sha-512 hashing of the aeskey with the ecdh "shared secret". This was not done in the older protocol (apple have consistently encrypted more and more as time goes on).
I'm not sure yet what the older protocol for the video is. (The audio example is in shairplay, the parent of RPiPlay and the Grandparent of UxPlay, which is audio only, so I could look at it).
But at least this means that the issue is not the fairplay decryption of ekey to get the aeskey, which is reverse-engineered, but no-one understands... and would have been impossible to fix, probably.
AES decryption needs a 16-byte key and a 16-byte initial vector. for audio this is aeskey and eiv. For video its the same aeskey as audio, presumably now also not hashed. Just need the initial vector......
OK problem fixed.
I found that just one part of the protocol is dropped in the older version used by AirMyPC.
Then it works.
yehaaaw! youre the best man! gimme your paypal for coffee via private message!
fduncanh @.***> schrieb am Mo. 13. Dez. 2021 um 09:09:
OK problem fixed.
I found that just one part of the protocol is dropped in the older version used by AirMyPC.
Then it works.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/FDH2/UxPlay/issues/37#issuecomment-992207285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4NQUK26T3GO6QC53OKT33UQWS4TANCNFSM5J4PDU2A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@arararar UxPlay with fix that works with AirMyPC is now uploaded
UPDATED AGAIN! ( @arararar please note)
FIXED!!
The 16 byte AES key
aeskey
is obtained by FairPlay decryption of the 72 byteekey
received from the client. The (audio) initial vector (iv) also needed for decryption is obtained from the client as the 16 byteeiv
(you can see this in the debug outpu).In UxPlay for modern Apple clients,
aeskey
is then decrypted a second time by a sha-512 hash with the 32 byte shared secretecdh-secret
created in the inital pairing handshake. OMITTING THIS STEP MAKES AirMyPC WORK! (This is obviously an older protocol, apple keeps adding more and more encryption as time ghoes on...)We now have the aes (key,iv) pair for audio decription. The video (key, iv) pair are obtained by sha-512 hashing (AirPlayStreamKeyxxxx,AirPlayStreamIVxxxx) with the
aeskey
, where xxxx is the streamConnectionID (as text printed in%llu
format) received from the client. This part of the protocol is unchanged....