MTPZ: Initial Analysis

Microsoft created a now-standardized protocol called the Media Transfer Protocol (MTP) based upon an earlier standard. MTP was designed to be used for digital media players so that hardware vendors didn’t need to bother writing their own drivers; they just needed to implement the MTP protocol on the hardware-side and the rest was taken care of by the computer’s operating system.

So when it was Microsoft’s turn to create their Zune media players (which are fantastic, honestly), they deemed it necessary to restrict access to the Zune’s media. That is, they extended MTP to include a proprietary handshake upon connection of the device in order to unlock it for synchronization. This protocol extension is known as MTPZ. If the software didn’t know how to complete the handshake, the Zune would remain locked and it cannot be manipulated via the MTP protocol. Perhaps it was necessary for Microsoft to restrict access to their DRM content. Regardless, what’s relevant to me is that on platforms without official Zune-capable software (e.g.: Linux), synchronization is impossible without the use of a different operating system.

And that’s a problem.

A problem? Or a blessing!

A problem. High five to all the Archer fans out there.

Evidently the first step would be to capture a few USB sessions of this handshake (which in my case occurred between the Windows Zune software and my Zune 8GB device), which was done using the wonderful USB Monitor by HHD Software. It’s possible to tell when the Zune has completed its handshake when it displays ‘connected’ on its screen, so I stopped capturing as soon as I saw this to capture as few extra bytes as possible. This was repeated three times for a total of three outbound session captures (to the Zune) and three inbound sessions captures (from the Zune).

Outbound:

Inbound:

What is of note here is that all of this data adheres to the MTP protocol; that is, this data can properly be split into correct MTP packets, with the packets containing the handshake data seeming to have the MTP type of WMDRMPD_* (see the MTP documentation in the libmtp project).

As seen in the outbound session, what is sent first seems to be information about what software is currently handling the Zune. This seems to be constant in every session I’ve inspected. A bit later, two pieces of data, which seem to be certificates, are sent to the device. Again, this is constant in every session (at least for the software used). At hex address 0x0003A7 up until 0x00043C is where the generated data lies. When observed in realtime, you can see that the software doesn’t send any more packets until it has received the next step of the handshake from the Zune.

Unfortunately, without yet knowing the format of the Zune handshake (I’ll have to disassemble something to find out), I can’t accurately say exactly what further is sent back and forth. Once I do, I’ll be sure to make a detailed post on said format.