Looking into the Air Video HD protocol

  • The server now uses HTTPS
  • The certificate is in AppData\Local\AirVideoServerHD\Data\Certificate
  • 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.

3 thoughts on “Looking into the Air Video HD protocol

  1. 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.

  2. 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!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>