more protocols: shuffle/repeat, check in/out
Marcus Brinkmann <[email protected]>
| Newsgroups | gmane.comp.audio.netmd.devel |
|---|---|
| Message-ID | <20030111180015.GC1737@ulysses> |
(repost because it didn't make it to the archive due to the problems last
week)
Hi,
First, I have found a new function that lets you set shuffle/repeat mode
in the player over the USB link. Don't ask me how I found it :) This is
motivating, since this is the first functionality we found that does not
exist is OpenMG beside flashing the EPROM. This means that we can expect
further functions to exist. It would be tremendously interesting to have
insight into the firmware of the player. I would hope to find features like
Sound setting, selection of recording mode, enter recording mode from line
in (Kim C said he did it by accident), and of course also track split/join.
At least if I were to design NetMD, I would surely include all these
features, so let's hope for the best.
However, and now I come to the second part, there is hardly any progress on
the check in/out feature. I think for now we have to stick with documenting
it as good as we can. There is heavy encryption involved, and it is not
something you can solve within meals. I am not sure if I would even try.
Best progress is probably made by cracking OpenMG, which is difficult and
probably illegal to do, or by disassembling/tracing the program, which is
equally difficult and probably illegal, too. Just by merely looking at the
device and what it spits out if you send garbage at it there is probably no
way to do it. Interestingly, the question here is not what key is used.
All keys that are meaningful used are probably available to us (on your hard
disk, in the protocol). The issue is finding the algorithm used to link the
keys and data together.
Anyway, here is some of the new information I got. Gathering this data is a
time consuming task, and it is not too difficult either. There should be
plenty of interested people here with lots of spare time who don't have the
coding or math skills to solve the download problem, but finding new
commands or details about the protocol only requires time and patience.
Below are the changes to the latest version of my document.
Devices
========
[The following new device is supported (from the mailing list archive):]
Sony MZ-N10 0x54c 0xc6
Playback Status
===============
Type B
00 18 09 80 01 03 30 88 02 00 30 88 05 00 30 88 06 00 ff 00 00 00 00 00
09 18 09 80 01 03 30 88 02 00 30 88 05 00 30 88 06 00 10 00 00 08 00 00
00 06 88 06 00 02 xx yy
[The following new playback status is known:]
56 ff recording (over USB)
Unknown 10
==========
[These sequences are used by OpenMG Jukebox at startup, probably to test for
compatibility with other players... the 02 at the beginning is odd. Note
that for my player, Sony MZ-N707, the last three commands return 0c when
used with 02, but not when used with 00. This means that in general, the
first byte can be significant, even if it isn't for all commands].
=> 02 18 41 ff 00 00 20 10 01 00 00
<= 08 ...
=> 02 18 41 ff 00 00 20 10 01 00 01
<= 08 ...
=> 02 18 42 ff 00 00 20 10 01 00 00 00 00 00 00 00
<= 08 ...
=> 02 18 c1 ff 60 00
<= 08 ...
=> 02 ff b2 70
<= 08 ...
=> 02 18 d1 ff 01 00 00 00 88 08 01 00 00
<= 0c ....
=> 02 18 d1 ff 01 00 00 00 88 08 01 80 00
<= 0c ....
=> 02 18 d1 ff 01 00 00 00 88 08 01 c0 00
<= 0c ....
[The following new command was found when trying the above last three
commands with 00 instead 02:]
Playmode
========
=> 00 18 d1 ff 01 00 00 00 88 08 $p $q 00
<= 09 18 d1 ff 01 00 00 00 88 08 $p $q 00
$p$q
00 00 none
00 80 Repeat
00 c0 Repeat 1
01 00 Shuffle
01 80 Shuffle Repeat
NOTE: There might be other combinations with equal effect. I only listed
the most straightforward of each.
NOTE: Shuffle 1 or Shuffle Repeat 1 wouldn't make much sense, right?
NOTE: Programming mode is unknown.
Recording
=========
Loading music from the computer to the player
=============================================
1. ???
=> 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. ???
=> 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.
3. ???
=> 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
4. ???
=> 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
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 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
$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 encrypted parameter or
signature.
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 21 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. ???
=> 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. ???
=> 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. ???
=> 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. ???
=> 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. Deletion
=> 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
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org [email protected]
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
[email protected]
http://www.marcus-brinkmann.de/