- The server now uses HTTPS
- The certificate is in AppDataLocalAirVideoServerHDDataCertificate
- The private key seems to be PKCS#8 encrypted
- Its my understanding that to log traffic with Wireshark the password of the key would need to be determined by looking at the server binary.
- It might be worth trying to replace the certificate with a custom one which is unencrypted.
Using Fiddler, we can see part of what is going on:
POST /json-1.0 HTTP/1.1
Host: targaryen:45633
Proxy-Connection: keep-alive
Accept-Encoding: gzip, deflate
Content-Type: application/json
Content-Length: 246
Accept-Language: fr-fr
Accept: */*
Connection: keep-alive
User-Agent: AirVideoHD/100.02 CFNetwork/672.0.2 Darwin/14.0.0
{"method":"listTopLevelItems","params":null,"clientInfo":{"verification":"eaa874684601af36cf44f0eff34078375a660c2f","password":null,"deviceName":"Michael's iPad","clientId":"B4627F9E-4ED0-433A-895E-448C2439E228","version":100.02,"userName":null}}
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Length: 508
Content-Type: application/json
Date: Fri, 18 Oct 2013 20:04:02 GMT
{"clientInfo":{"clientId":"B4627F9E-4ED0-433A-895E-448C2439E228","deviceName":"Michael's iPad","password":null,"userName":null,"verification":"eaa874684601af36cf44f0eff34078375a660c2f","version":100.020},"errorCode":-5,"errorMessage":"Client verification failed.","method":"listTopLevelItems","params":null,"serverInfo":{"id":"62acfcfbb662f9235a453a642e61d4ded6f74f10","multiUserMode":true,"name":"TARGARYEN","serverPasswordSalt":"d18de988-37f8-11e3-8dc9-001bdc002bc8","timeDifference":0,"version":100.110}}
The server says “client verification failed”. It would appear that the clientInfo/verification key doesn’t pass a test. I initially assumed this to be some kind of hash on the request data, and that Fiddler was modifying it (true, see the Proxy-Connection header included above, and it might also mess with the request line)
Instead, the verification code derives from the certificate used by the server. You can see it change when restarting Fiddler, at which point Fiddler apparently generates a new certificate (with the iOS FiddlerCertMaker extension installed).
Given the correct verification id matching the certificate of the real server, it is possible to make Fiddler work by adding the following code into the OnBeforeRequest
function of the rules script:
var body = System.Text.Encoding.UTF8.GetString(oSession.requestBodyBytes);
body = body.replace('INCORRECT ID USED BY THE CLIENT', 'CORRECT ID USED BY THE CLIENT');
oSession.requestBodyBytes = System.Text.Encoding.UTF8.GetBytes(body);
Because the certificate used by the server is generated, the correct key the client has to use differs for each installation. Here’s a
working pair of certificate and verification key.
blog.elsdoerfer.name 
Did you get any further with this, or have any more information/insight?
LikeLike
Using the cert/key I uploaded above, you can use JSFiddler to see what the protocol is doing and write your own client; that part should be straightforward. That means asking the user to copy a specific cert into his computer though. The challenge to deploy your client widely would be to figure out how the client has to derive the verification key from the SSL certificate. That might be obvious, or they might have tried to hide it, I have no idea.
LikeLike
Hi! Good work! Can you, please, explain a little more, how is your verification key generated ?I try to generate my certificate and i can not understand how to find a verification key. Thanks!
LikeLike
Hello, great blog post! I have been trying to figure out the Air Video HD protocol as a sort of hobby and got stuck on the “verification” stuff. This blog post fills in a major gap in my knowledge. Thank you!
LikeLike