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.

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.

=> 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

=> 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).

=> 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?

=> 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

Part of the Enabling Key Block used by the device. 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), that is the root key encrypted by a key the device has in its DNK. And 0ff4… is some unknown thing from the EKB 00010001.ekb, probably a digital signature. 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.

=> 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)

$m is a nonce from the host and !m is a nonce from the device. These two 8-byte-values are concatenated to form a 16-byte value. The Retail MAC without padding of that value, using the root key of the EKB transferred as key for the MAC will be the session key.

For "Retail MAC" aka "CBC-MAC-Y" aka "ISO/IEC 9797-1, algorithm 3" see google. It basically is standard DES CBC-MAC for all but the last blocks, while the last block is encrypted using 3DES-CBC. The initial IV is zero.

 
=> 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

=> 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

=> 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

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

=> 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

=> 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

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

=> 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

=> 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

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

=> 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

=> 00 18 00 08 00 46 f0 03 01 03 40 ff 00
   10 01 00 $t
<= 00 18 00 08 00 46 f0 03 01 03 40 00 00
   10 01 00 $t $m(1) ... $m(8)

$t is the track to check in or delete.

=> 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)

=> 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

=> 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