From XMMS2
This technical note describes the Remote Audio Access Protocol (RAOP) as used in
Apple iTunes to stream music to the Airport Express (ApEx). Although RAOP is not
documented, it is quite simple to analyze. RAOP is based on the Real Time Streaming
Protocol (RTSP) but with an extra challenge-response based authentication step. The
description of RAOP here is partly based on previous reverse-engineering efforts
[1, 2, 3]. I also independently analyzed RAOP by analyzing the network packets
exchanged observed between an iTunes client (v6.0.4) and ApEx (firmware v6.3). Please
note that my understanding of the authentication step differs from [2] and is based
on packet analysis and [3].
ApEx Discovery:
Discovery protocol from the Bonjour protocol suite. This is a very simple exchange
involving the respective MDNS TXT service records of ApEx and iTunes services.
RAOP:
RAOP uses two channels for streaming music: a control channel which uses RTSP and
a data channel for sending the raw data. Upon startup, iTunes initiates a RTSP
connection to the Airport on port 5000. This exchange is shown below:
Traffic from iTunes to ApEx:
OPTIONS * RTSP/1.0
CSeq: 1
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
Apple-Challenge: X/GmLMLuFvgWf8Y1bQuUug
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 1
Public: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, GET_PARAMETER, SET_PARAMETER
Apple-Response:
fUG5XtwIbJDWcpYX7p81z7bYfWD7UKa9VkIQk40szRYT0kP8VJ+30l7YRdvwR2hMxUtjoDDIjqFdDiSu50
SfxfEtnquj7nFyR8gqJKnXNnpgegBaaFatoCLHTaH7Nc5H4yH/MQ2qrHtJ/5i+R7ElCd29xaC31r/wfDYg
xMy2YmoeaRnvudSUOURHsOO8mEbJYfNp1rC2+W7EGwYyN/QQ98/kREUPO1et2qz7THEUs0n22ql/2VA88E
gpyDsQMNIuUdOXdjrH1Moqz+yG0KmKJyP8WoehJPhfW1da4YJSW2qAahQZRgJ7x7M3KUGEhzut8pf6CP/U
1FRJqj7KFMTwTg
Audio-Jack-Status: connected; type=analog
As can be seen the iTunes client provides its version number and a randomly generated
22-byte cryptographic “challenge“ to the ApEx in the Apple-Challenge parameter.
The ApEx replies with a response (Apple-Response) which is the challenge encrypted
using the private key stored in the ApEx. iTunes verifies this value using its public
key part of the assymmetric key-pair. Note that this step is performed by iTunes to
verify if it is talking to a real ApEx. The connection is tore down after this exchange.
iTunes then establishes another RTSP connection to ApEx on the same port (5000) wherein
it provides a randomly generated AES key (rsaaeskey) with an Initialization Vector
(aesiv) to the ApEx. The AES key is encrypted using the public key by iTunes. The
ApEx verifies that it is talking to iTunes by decrypting the AES key using its private
key. Note that the public key part has been recovered using reverse-engineering and is
publicly available [3]. This exchange is shown below:
Traffic from iTunes to ApEx:
ANNOUNCE rtsp://10.0.1.2/3233609434 RTSP/1.0
CSeq: 1
Content-Type: application/sdp
Content-Length: 563
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
v=0
o=iTunes 3233609434 0 IN IP4 10.0.1.2
s=iTunes
c=IN IP4 10.0.1.1
t=0 0
m=audio 0 RTP/AVP 96
a=rtpmap:96 AppleLossless
a=fmtp:96 4096 0 16 40 10 14 2 255 0 0 44100
a=rsaaeskey:HSyPEnWds0b2Qoc1733RyWmInqHXn61V8UarTBW+cwPrSV4DqP8kChGxGnJ9QJAyQQvTcuVhL
J2MCGP2ddANQWeguvxJfyIZuM9bwX4ZA3FgWWF6QOTyDVy7ppK587Mh1Y6+GYujTdMZ6ukbC3thXmC5PyipVI
EOR3By9AJGpVTWR8LpG5dcuwkXbzlrmqr4IT7bsffpAm/5wzqkOlcrNiI/QcYqC0jZ744mNAkQIQqijVR/IoO
F6o4KpvwUIXIlhPJm87m4ghTLuXEqDhtdcmKza/uRmOl0KwcHkS/ON4WgvgiuHzlMML8pVDBKeAY1R6x2sGxs
GWTWOE3FsMFM/w
a=aesiv:EBqQ4XNBST+PpC28SX1oXA
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 1
Audio-Jack-Status: connected; type=analog
Next, the ApEx tells iTunes which port to use for the data connection (server_port, typically 6000):
Traffic from iTunes to ApEx:
SETUP rtsp://10.0.1.2/3233609434 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record;control_port=0;timing_port=0
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 2
Session: 8090DBF0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record;control_port=0;timing_port=0;server_port=6000
Audio-Jack-Status: connected; type=analog
Next, we show a typical exchange of RTSP sequence and timestamp numbers in a control packet:
Traffic from iTunes to ApEx:
RECORD rtsp://10.0.1.2/3233609434 RTSP/1.0
CSeq: 3
Session: 8090DBF0
Range: npt=0-
RTP-Info: seq=49770;rtptime=1068774379
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 3
Audio-Jack-Status: connected; type=analog
The next exchange shows how the volume parameter is adjusted - for more details see [1]:
Traffic from iTunes to ApEx:
SET_PARAMETER rtsp://10.0.1.2/3233609434 RTSP/1.0
CSeq: 4
Session: 8090DBF0
Content-Type: text/parameters
Content-Length: 20
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
volume: -15.000711
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 4
Audio-Jack-Status: connected; type=analog
And finally the shutdown of the session:
Traffic from iTunes to ApEx:
TEARDOWN rtsp://10.0.1.2/3233609434 RTSP/1.0
CSeq: 6
Session: 8090DBF0
User-Agent: iTunes/6.0.4 (Macintosh; N; PPC)
Client-Instance: 99BB1C4A4056F46D
DACP-ID: 99BB1C4A4056F46D
Active-Remote: 4294936225
Traffic from ApEx to iTunes:
RTSP/1.0 200 OK
CSeq: 6
Connection: close
Audio-Jack-Status: connected; type=analog
Please note that raw data is exchanged betweeen iTunes and ApEx on the data
channel (port 6000) while this control signalling is taking place.
References:
[1] http://www.cocoadev.com/index.pl?RemoteAudioOutputProtocol
[2] http://www.cocoadev.com/index.pl?AirTunesEncryption
[3] http://www.nanocrew.net/software/justeport/
