Last edited: Sunday, November 16, 2003
Main MiniDisc page

This documents shows some USB logs from a NetMD download session, in order to figure out the protocol and use NetMD minidisc units under Linux.

Method

Several sets of USB transfer logs were taken, among them samples of 2 seconds of silence and of 2 seconds of a pure 1 kHz sine wave, recorded in SP/LP2/LP4 mode. By comparing these logs, it was determined what parts are constant and which parts are variable. USB transfers were recorded using USB snoopy under Windows 2000.

Also, some simple experiments were done using Xmd's 'raw' command line option.

Log analysis

All USB transfers related to download start with 00 18 00 08 00 46 f0 03 01 03. The bytes after that probably indicate some kind of sub-command.

Next a list of USB transfers, followed by my guess of what they mean
(transfers starting with 00 are from PC -> MD, transfers starting with 09 are from MD -> PC):

Sub-command 80

00 18 08 10 10 01 00 00 	
09 18 08 10 10 01 00 00 	
00 18 00 08 00 46 f0 03 01 03 80 ff 	
09 18 00 08 00 46 f0 03 01 03 80 00

My guess is that this indicates the start of a download session (command 81 is probably the complement of this command).

Sub-command 11

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 35 	
3b a3 00 00

Don't know what this is. This data seems to be always the same for a specific minidisc player. Looks like a unique ID for a specific minidisc player. Others people have found the following data

09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 1a
60 85 00 00

and

09 18 00 08 00 46 f0 03 01 03 11 00 01 00 00 08
2d cd 00 00

Sub-command 12

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 01 00 38 00 00 	
00 38

My guess is that this provides info about the PC to the MD. The data is the same for the silence sample as for the sine wave. This is probably the EKB (enabling key block), since 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.

Sub-command 20

00 18 00 08 00 46 f0 03 01 03 20 ff 00 00 00 xx 	
xx xx xx xx xx xx xx 	
09 18 00 08 00 46 f0 03 01 03 20 00 00 00 00 xx 	
yy yy yy yy yy yy yy

8-byte sequences xx and yy are different each time, even when downloading the same track. My guess is that keys/hashes are exchanged.
When running this command in Xmd, with xx = all zeroes, yy comes out different every time.

Sub-command 22

00 18 00 08 00 46 f0 03 01 03 22 ff 00 00 xx xx
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
xx xx xx xx xx xx xx xx xx xx xx xx xx xx
09 18 00 08 00 46 f0 03 01 03 22 00 00 00

32-byte sequence xx is different each time, even when downloading the same track. Submit some kind of hash???

Sub-command 28

00 18 00 08 00 46 f0 03 01 03 28 ff 00 01 00 10 	
01 ff ff 00 ww ww 00 00 yy yy zz zz zz zz 	

0f 18 00 08 00 46 f0 03 01 03 28 00 00 01 00 10 	
01 00 01 00 ww ww 00 00 yy yy zz zz zz zz

This sub-command seems to initiate the actual download.
The sequence 10 01 ff ff indicates an unspecified track number.
Bytes ww seem to indicate the kind of download: sp = 0x0006, lp2 = 0x9402, lp4 = 0xa800
Byte yy is also different and seems related to the length of the track: sp = 0x58, lp2 = 0x5a, lp4 = 0x5a
Bytes zz seem to indicate the length of the following BULK data.

Instead of the normal 0x09 response, the MD sends 0x0F as the first byte before the BULK data is sent.

*** BULK DATA ***

09 18 00 08 00 46 f0 03 01 03 28 00 00 01 00 10 	
01 tt tt 00 ww ww 00 00 yy yy zz zz zz zz xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx

The bulk data seems to start with a 0x18 length header:
SP data starts with 00 00 00 00 zz zz zz zz 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
LP2 data starts with 00 00 00 00 zz zz zz zz xx xx xx xx xx xx xx xx 00 00 00 00 00 00 00 00
LP4 data starts with 00 00 00 00 zz zz zz zz xx xx xx xx xx xx xx xx 00 00 00 00 00 00 00 00
where zz is the length of the rest of the BULK data. This corresponds to length zz of the 0x28 sub-command minus 0x18.

Finally, sub-command 0x28 is acknowledged by a 0x09 response. The 32-byte sequence xx in the response in different each time.

I've seen a case where track number tt was different from the one in the initial 0x28 sub-command.

Sub-command 48

00 18 00 08 00 46 f0 03 01 03 48 ff 00 10 01 tt 	
tt xx xx xx xx xx xx xx xx 
09 18 00 08 00 46 f0 03 01 03 48 00 00 10 01 tt 	
tt

Verify hash??? It takes quite a long time between request and response (several seconds), so apparently this command requires physical access to the disc. tt is the track number just recorded, same as in the 09 18 00 08 00 46 f0 03 01 03 28 response.

Sub-command 21

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

Thrash keys??? No data is exchanged with this command. This command may be the complement of the earlier command 0x20, that exchanged 8 byte sequences between PC and MD.

Sub-command 81

00 18 00 08 00 46 f0 03 01 03 81 ff 	
09 18 00 08 00 46 f0 03 01 03 81 00

End secure session??? This sub-command is probably the complement of sub-command 0x80.

Summary

Sub-command	Data to MD	Data to PC	Guessed function
80	-	-	Begin download session???
11	-	8 bytes constant	Unique player ID
12	40 bytes constant	-	Enabling key block (EKB)
20	8 bytes variable	8 bytes variable	Exchange random
22	32 bytes variable	-	Encrypted content key???
28	sample type and length	32 bytes variable track nr	Authentication??? + download start
48	8 bytes variable track nr	-	Authentication???
21	-	-	Discard random
81	-	-	End download session???

Experiments

Sub-command 0x80/0x81

Sub-command 0x80 causes the disc to spin up.
After issuing 0x80, 0x81 needs to be issued before 0x80 can be issued again.

Sub-command 0x11

Sub-command 0x11 is not accepted before sub-command 0x80 has been issued.

Sub-command 0x12

This command sends a 40-byte sequence. The slightest change in this sequence causes the MD to return with a 0x0A code (0x0A 18 00 08 00 46 f0 03 01 03 12 etc.)

Sub-command 0x20

Data returned from sub-command 0x20 is different every time.

0x20 can also be issued without any arguments:

00 18 00 08 00 46 f0 03 01 03 20 ff
09 18 00 08 00 46 f0 03 01 03 20 00 00 00 1d xx xx xx xx xx xx xx xx

where xx is again an 8-byte random sequence, again different every time.

Sub-command 0x20 can be issued at any time (no 0x80 command required).

Sub-command 0x22

Sub-command 0x22 can be issued without any arguments:

00 18 00 08 00 46 f0 03 01 03 20 ff
09 18 00 08 00 46 f0 03 01 03 20 00 00 00