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:

3 thoughts on “Looking into the Air Video HD protocol”

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.