fp-setup Packets
Verschwiegener opened this issue · 13 comments
This isn't really an Issue, but i was wondering if anyone could explain to me how exactly the fp-setup Packets works.
Thanks in advance
no-one can understand it, but its reverse engineered in playfair omghax.c
see https://github.com/SteeBono/airplayreceiver/wiki/AirPlay2-Protocol
which is based on dsafa22's analysis
fp setup prepares (using data obtained in the pairing step) for the obfuscated fairplay (playfair) decryption of the (audio) AES key which happens later in the first SETUP call,.
The code is taken from shairplay
Okay thx, so no one really knows what kind of data is being send via the fp-setup Packet
shairplay called it the 164 byte "keymsg" used by playfair omghax.c (the 5th byte must be 0x03 for playfair support)
see lib/fairplay-playfair.c
Yeah i did See that in the code, the only Thing that i dont really understand is how exactly the AES-128 key is derived from the e-key and the keymsg that is send by the Client in the second fp-setup Packet
playfair converts 72 byte ekey into the first form of 16 byte AESkey. This is done "magically" by omghax.c. This was all that was done in AIrPlay1 (shairplay).
In AirPlay2 legacy protocol, the actual audio 16 byte AESkey is produced from the first (fairplay-decrypted) form by a sha-512 hash with the 32 byte shared ecdh_secret set up in pair_setup. The audio 16byte AES iv is just what is sent by the client, not encrypted.
The video 16 byte AESkey and iv are obtained from a sha-512 hash of keys constructed from streamConnectionID with the audio AESkey.
In RPiPlay, the hash of AESkey with ecdh_secret is done twice, once in raop_buffer.c for audio and once in mirror_buffer.c for video.I think this is from dasa22's old code. In UxPlay-1.44 the hash is moved back to be done in raop_handlers.h where it logically belongs. *-buffer.c no longer know about ecdh_secret.
This was done to support some older devices with an older protocol that omits the hash.
So if I understand it correctly, the eKey is an AES Key which is manipulatet by some Kind of magic.
And the AirPlay 2 Audio AES-Key i generated by a sha-512 hash using the ecdh-secret and the fairplay decrypted data of the first fp-setup, right?
@fduncanh could i reach you anywhere else, so that wie dont have to communicate via a github issue?
right. The magic in playfair is produced by some reverse-engineering.
The rest was found by dsafa22 by analysing a third-party app that had unhidden code, so is more understandable.
but the Client side isnt that good understood am i right?
Yes. That's Apple.
You might want to close this issue, and not really an issue in RPiPlay
I dont have any insights beyond the RPiPlay/UxPlay code base
Thank you for your help