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