DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
This document is based on [[atracdownload]] from the FreeMD repository. Also compare http://bertrik.sikken.nl/netmd/download.html

====== Downloading an ATRAC track to a NetMD unit ======

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. DISABLE TRACK PROTECTION FOR NEXT SESSION ====

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

This instruction tells the MD unit to not set the "protected" bit for following downloaded tracks. It is effective until reset with the same instruction, but having the last byte 00, or the end of the current session.

==== 2. START AUTHENTICATED SESSION ====

  => 00 18 00 08 00 46 f0 03 01 03  80 ff
  <= 09 18 00 08 00 46 f0 03 01 03  80 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
  <= 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:

<code>
Leaf ID
Leaf Key, eg
  K0010
Encrypted node keys, eg:
  E(K0010, KR), E(K0010, K0), E(K0010, K00), E(K0010, K001)
</code>

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

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


==== 5. SESSION KEY NEGOTIATION ====

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

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

==== 6. TRANSFER CONTENT ID AND ENCRYPTION 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

$m(1) ... $m(32) is DES encrypted using the session key negotiated in the previous step. The corresponding plain text is

  01 01 01 01 $c(1) ... $c(20) $k(1) ... $k(8)

where $c(1) ... $c(20) is the Content ID of the track to transfer (a kind of UUID to recognize the copyrighted work) and $k(1) ... $k(8) is the Key Encryption Key.

==== 7. TRANSFER TRACK DATA ====

  => 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 for LP2 and LP4 is the number of frames (of 96 bytes for LP4 or 192 bytes for LP2); $t$u$v$w is the number of bytes transferred through the bulk pipe. The number includes the packing overhead.

The meaning or $r$s for SP is not yet known.

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
     $m(0) ... $m(32)

The track number of the recorded track is returned in !t.

$m(x) is DES CBC encrypted by the session key (IV zero), and after decryption contains the concatenation of
  - An 8 byte value identifying the track (needed on check-in to verify which copyrighted work will be deleted and adjust the check-out counter)
  - Four padding bytes (seen as 00 00 00 00 or 01 01 01 01)
  - The 20-byte Content ID

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 $k(1) ... $k(8) $i(1) ... $i(8)

where $u$v is the block size (usually 3f00), $k(x) is the key for DES CBC encryption of the data in this block, and $i(x) is the IV for the DES CBC encryption. The key itself is DES **decrypted** by the key encryption key, i.e. you have to **encrypt** it to get the plain key.

This means for the total nr of bytes: len + ((len+0x3eff)/3f00)*24

==== 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 a simple authorization value: It's 0000000000000000 DES encrypted by the session key.

==== 10. FORGET SESSION KEY ====

  => 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. END AUTHENTICATED SESSION ====

  => 00 18 00 08 00 46 f0 03 01 03 81 ff
  <= 09 18 00 08 00 46 f0 03 01 03 81 00


===== Deleting a track (or checking it into the computer) =====

==== 1. START AUTHENTICATED SESSION ====

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

  => 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 TRACK DRM INFO/CONTENT ID/??? ====

  => 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. SESSION 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. TWO-STAGE DELETE ====

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

==== 7. FORGET SESSION KEY ====

  => 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. END AUTHENTICATED SESSION ====

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