atracdownload
This file is from the FreeMD repository which is currently offline. A wikified version is at atracdownload-wiki
Sony NetMD Protocol
===================
All upload commands start with:
00 18 00 08 00 46 f0 03 01 03 $o ff
This is a standard AV/C frame for a vendor defined opcode, where the
company ID is 080046 = Sony (same as for MAC addresses, for example).
The f0 03 01 03 is unknown. $o is a sub-command. ff seems to be a
place holder for an internal return value or error code. It's
normally set to 00 on return, but I have seen 92, too, for some
protocol violation.
The music upload is described in some detail in US patent 7228568.
Loading music from the computer to the player
=============================================
The first two commands do not return any data from the device to the
host. When issueing the second command, the disc spins up. The
patent says that there is a request to start authentication command
before any other command. Thus, I labeled them accordingly, but it's
a wild guess.
1. REQUEST TO START AUTHENTICATION (?)
=> 00 18 00 08 00 46 f0 03 01 03 2b ff 00 01 00 00 01
<= 09 18 00 08 00 46 f0 03 01 03 2b 00 00 01 00 00 01
2. SPIN UP DISK (?)
=> 00 18 00 08 00 46 f0 03 01 03 80 ff 00 00 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 80 00 00 00 00 00 00
NOTE: You hear head movement (disc spinning up).
3. REQUEST FOR LEAF ID
=> 00 18 00 08 00 46 f0 03 01 03 11 ff 00 00 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 21 cf 06 00 00
Three other devices return always:
<= 09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 35 3b a3 00 00
<= 09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 1a 60 85 00 00
<= 09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 08 2d cd 00 00
This seems to request and return a unique device ID. According to the
patent, this should be the leaf ID in a hierarchical tree of
encryption keys. Each device contains a unique encryption key which
corresponds to a leaf node in that tree, and the shared encryption
keys for all nodes from the leaf to the root node of the tree. All
these keys together are called the Device Node Key (DNK). The keys
are labeled K<path> where path is a binary number describing a path
through the tree. For example, device 0010 has the keys KR (root),
K0, K00, K001, K0010 (==leaf key).
So the DNK of a device is:
Leaf ID
Leaf Key, eg
K0010
Encrypted node keys, eg:
E(K0010, KR), E(K0010, K0), E(K0010, K00), E(K0010, K001)
More details on the tree is contained in the EKB.
Bad cryptography note: In the DNK, all but the leaf keys are stored
encrypted by the leaf key. D'oh. What the hell, can't hurt, can it?
4. TRANSFER EKB
=> 00 18 00 08 00 46 f0 03 01 03 12 ff 00 38 00 00
00 38 00 00 00 01 00 00 00 09 00 01 00 01 00 00
00 00 01 ca be 07 2c 4d a7 ae f3 6c 8d 73 fa 60
2b d1 0f f4 7d 45 9c 72 da 81 85 16 9d 73 49 00
ff 6c 6a b9 61 6b 03 04 f9 ce
<= 09 18 00 08 00 46 f0 03 01 03 12 00 00 38 00 00
00 38 00 00
Enabling Key Block. Same for all PCs and all devices as far as I know.
"parts of this data is also found in a file in C:\Program Files\Common
Files\Sony Shared\OpenMG\Ekb The 16-byte block starting with 01 ca be
.. is identical to the contents of bytes 0x58-0x67 in file
00010001.ekb. The 24-byte block starting with 0f f4 7d .. is identical
to the contents of bytes 0x08-0x1f in file 00010001.ekb."
(http://bertrik.sikken.nl/netmd/download.html)
The EKB is simply a content-specific root key KR', encrypted by a key
from the DNK set, ie, one of the keys known by the device (for example
K0). The further up the key is in the hierarchy, the more devices can
decrypt the EKB and use the content-specific root key.
In this case: 01ca... is Enc(K000000010,KR) And 0ff4... is some
unknown thing from the EKB 00010001.ekb. Maybe the encrypted version
number. See tools/dump-ekb.py for more info on EKBs.
Note: According to the patent, an EKB can be used to renew device keys
(Key Renewal Block), but I doubt that this is implemented for NetMD
devices.
5. authentication ???
=> 00 18 00 08 00 46 f0 03 01 03 20 ff 00 00 00
$m(1) ... $m(8)
<= 09 18 00 08 00 46 f0 03 01 03 20 00 00 00 00
!m(1) ... !m(1)
Send and return differ, and differ in each run.
6. TRANSFER ENCRYPTED CONTENT KEY ?
=> 00 18 00 08 00 46 f0 03 01 03 22 ff 00 00
$m(1) ... $m(32)
<= 00 18 00 08 00 46 f0 03 01 03 22 00 00 00
7. End search and start recording
=> 00 18 00 08 00 46 f0 03 01 03 28 ff 00 01
00 10 01 ff ff 00 $p $q 00 00 $r $s $t $u $v $w
<= 0f 18 00 08 00 46 f0 03 01 03 28 ff 00 01
00 10 01 ff ff 00 $p $q 00 00 $r $s $t $u $v $w
ffff is a placeholder for the track number (indicated by 10 01).
$p$q is the format, 0006 for SP, 9402 for LP2 and a800 for LP4. $r$s
is an unknown value proportional to the file size. $t$u$v$w is the
size of bytes transfered.
The player returns _twice_ from this command. First it just echoes it
with the first byte being 0f. This indicates the player is ready to
accept the data. From there, you can get the record mode and end
position with the playback status and position calls. Now you are
expected to transfer the data on endpoint 2 of the interface in bulk
mode. After you did this, the player will return again:
<= 09 18 00 08 00 46 f0 03 01 03 28 ff 00 01
00 10 01 00 !t 00 $p $q 00 00 $r $s $t $u $v $w
The track number of the recorded track is returned in !t.
NOTE: We don't know how $p$w is calculated.
NOTE: The data is split into blocks of 3f00 bytes each (except the
last one), and each one has a header:
00 00 00 00 00 00 $u $v $m(1) ... $m(8)
where $u$v is the block size (usually 3f00) and $m(x) is unknown
(possibly a key).
This means for the total nr of bytes: len + (len/3f00)*16 + 16
8. TOC Edit
=> 00 18 08 10 18 02 03 00
<= 09 18 08 10 18 02 03 00
Write track title.
=> 00 18 08 10 18 02 00 00
<= 09 18 08 10 18 02 00 00
9. Commit
=> 00 18 00 08 00 46 f0 03 01 03 48 ff 00
10 01 00 $t $m(1) ... $m(8)
<= 09 18 00 08 00 46 f0 03 01 03 48 00 00
10 01 00 $t
$t is the track number. $m(x) is possibly some Integrity Check Value.
10. ???
=> 00 18 00 08 00 46 f0 03 01 03 21 ff 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 21 00 00 00 00
11. ???
=> 00 18 00 08 00 46 f0 03 01 03 81 ff 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 81 00 00 00 00
Deleting a track (or checking it into the computer)
===================================================
1. START
=> 00 18 00 08 00 46 f0 03 01 03 80 ff 00 00 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 80 00 00 00 00 00 00
NOTE: You hear head movement.
2. REQUEST FOR LEAF ID
=> 00 18 00 08 00 46 f0 03 01 03 11 ff 00 00 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 21 cf 06 00 00
3. TRANSFER EKB
=> 00 18 00 08 00 46 f0 03 01 03 12 ff 00 38 00 00
00 38 00 00 00 01 00 00 00 09 00 01 00 01 00 00
00 00 01 ca be 07 2c 4d a7 ae f3 6c 8d 73 fa 60
2b d1 0f f4 7d 45 9c 72 da 81 85 16 9d 73 49 00
ff 6c 6a b9 61 6b 03 04 f9 ce
<= 09 18 00 08 00 46 f0 03 01 03 12 00 00 38 00 00
00 38 00 00
4. Get hash id for a track
=> 00 18 00 08 00 46 f0 03 01 03 23 ff 10 01 00 $t
$t is the track to check in or delete.
5. Key negotiation?
=> 00 18 00 08 00 46 f0 03 01 03 20 ff 00 00 00
$m $n $o $p $q $r $s $t
<= 09 18 00 08 00 46 f0 03 01 03 20 00 00 00 00
!m !n !o !p !q !r !s !t
6.
=> 00 18 00 08 00 46 f0 03 01 03 40 ff 00
10 01 00 $t
$t is the track to check in or delete.
<= 00 18 00 08 00 46 f0 03 01 03 40 00 00
10 01 00 $t $m(1) ... $m(8)
=> 00 18 00 08 00 46 f0 03 01 03 40 ff 01
10 01 ff fe
<= 00 18 00 08 00 46 f0 03 01 03 40 00 01
10 01 ff fe $m(1) ... $m(8)
7. ???
=> 00 18 00 08 00 46 f0 03 01 03 21 ff 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 21 00 00 00 00
8. ???
=> 00 18 00 08 00 46 f0 03 01 03 21 ff 00 00 00
<= 09 18 00 08 00 46 f0 03 01 03 81 00 00 00 00
Probed:
=======
D1
00 18 d1 ff 00
00 18 d1 ff 00 XX
00 18 d1 ff 00 XX XX
00 18 d1 ff 00 00..1b XX XX
00 18 d1 ff 00 00 00 00 XX XX 00 00 00
atracdownload.txt · Last modified: 2010/06/08 08:26 by megadiscman