Slave-in-the-Magic-Mirror
Slave-in-the-Magic-Mirror copied to clipboard
espes
iOS9
So i've managed to get iOS9 to negotiate and start sending data. The config record looks correct (non encrypted). But the video data makes no sense once decrypted.
It appears that the key must have changed.
I tried to find a decrypted version of the newest formware for apple TV but I can't seem to find one. Emulating thumb is not a problem if i can find the firmware.
Any ideas
I just updated the first post.
It works, the problem was I wasn't keeping the event port open. But the decryption key seems incorrect.
As a sanity check I checked the challenge/response from a log of ios9 and an appleTV and fed the same into the existing airtunesd and the results are different. ios9 still seems to accept them and sends the video data though.
I can only guess the decryption key must have changed.
There also seems to be data of type 5 every 30 video packets. I'm guessing it may be audio info since everything is now being sent over this one connection.
Type is: 1 config record Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 5 wtf 194 5 0 0.0 Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 0 Encrypted Video Data Type is: 5 wtf 25194 5 0 0.0
Strangely ios7 works with the same protocol, AND the video data still doesn't decrypt.
Hmm looks like i've hit a dead :( It seems ios9 is using a different key/encryption which probably needs the library from the new apple tv firmware. I don't think decryption keys are available for the new apple tv firmware tho?
Any ideas on your end? It's also possible the video format has changed but i doubt it.
Maybe the sochi firmware can handle this type of encryption. I'll have to setup qemu and find the entry points tho. Any chance you have the entry points already?
Oh i didn't know about unicorn! I'm attempting to decrypt an even newer firmware at the moment, will let you know how it goes. In the meantime here's a quick test vector for challenge 1 so you can check if it's generating with the new or old key.
46504c590301010000000004020003bb < 46504c5903010200000000820203d7ce93237c7d52efb40385eee64ed14616cad9dc49bdba930c1d8b359475f8d3da5a8356dbdd929eddb74e3a5e2b1e3c7e2587b9ba5a48f387484a4530f825d789440f15f9965d547d2bb51d45f1de0c58962bcbc0b8ca451793305a89aafbd60bf436272dd75fff777b2976112f8b373bac39e8175ac4a5b08e2f95cab6e47e
The current airtunesd returns this instead: 46504c5903010200000000820203879f7a3d3ce5a4c5db51176fa886babd9ca307a9626d8bbeee2ec31a2efdec3d9f5714833e2b3ffe6044b09a8c9946dfda0bceb86af01d27757f2f37ab366d138c0bd89b792d35695884089618460d4888ee0d09ed829b61a94f41e0f4cba1d49a2009130a64336ce44a030bca9960b9ba91511db91f4a3df46f246de2171f98
It's a special set of attributes in the bonjour message to skip it. Let me get to my computer and I'll post it in about half an hour.
Here you go: The real device sends 0x507FFFF7,0x1E but the following is sufficient to make the device connect AND skip the initial verify stages:
'features': u'0x507FFFF7',
'model' : u'AppleTV3,2',
'srcvers': u'220.68',
@kam187 when I change the attributes as you said above , no video data comes and logs below AirTunes: 172.16.8.93 - - [22/Oct/2015 16:11:39] "POST /fp-setup HTTP/1.1" 200 - AirTunes: 172.16.8.93 - - [22/Oct/2015 16:11:39] code 501, message Unsupported method ('TEARDOWN')
on iOS 9.0.2
It's not as simple as that. The protocol is totally different. If you're just expecting it to work it won't, a lot more work needs to be done yet.
The encryption has changed so we need to find the decryption key for the new firmware and then reverse that firmware to find the decrypt function :/
What would be useful is a packet capture of the newer protocol. Can you help with that?
Yeah sure Ill upload it when I get to my computer
In the mean time there's one on here too:
https://github.com/juhovh/shairplay/issues/43
Although it doesn't show the actual image data
Hmm a bit of an update. I've managed to debug through a commercial solution (took forever) to get me a decrypt key for a logged session but the resulting data has no valid NALU format :/
Any ideas?
I wonder if it's switched to AES-GCM mode, but i wonder what the authenticated tag is...
Anyway I'll try to debug and double check the key when I have time. The only other thing I can thing to do is try to debug the decryption part but the whole thing is heavily obfuscated :/. Probably the original AirPlay library embedded in there.
I've got hold of a airtunesd from version 190.9, it looks to have updated init/challenge/decrypt functions which i've identified.
It contains thumb code though so we need a better emulator - espes drop me an email I can pass it over if you want to have a go.
One more experiment, i sent a fake bonjour with features 0x527FFFF7 but pointing to a commercial airplay receiver. I traced the traffic and there was no pair verify as expected but the whole thing worked fine.
So that means (for now at least) we can ignore the pair verify and use this feature ID and concentrate on the init/challenge/decrypt.
More progress. I'm now able to load the library and run it. But the fp_init function seems to have changed. There's a call to GetFairPlayHWInfo which stores something at a pointer which now has to be passed into fp_init. Unfortunately GetFairPlayHWInfo is an external symbol and I don't have access to the full firmware :(
I've tried the usual stuff of mallocing an buffer and passing it in but it doesn't work :(
omg decryption key is verified, sending the NALU directly to VLC displays some garbled parts of the screen until it crashes.
That means the old format of LEN <NALU>, LEN, <NALU> has now changed to something else.
Can you show a screenshot ？
发自我的 iPhone
在 2015年10月30日，下午11:30，kam187 [email protected] 写道：
omg decryption key is verified, sending the NALU directly to VLC displays some garbled parts of the screen until it crashes.
That means the old format of LEN , LEN, has now changed to something else.
— Reply to this email directly or view it on GitHub.
@kam187 int _GetFairPlayHWInfo(int arg0) { rbx = arg0; _GetPrimaryMACAddress(rbx + 0x4, var_C); rax = var_C; if (rax == 0x0) { *(int32_t *)rbx = 0x6; } return rax; }
