MTPZ: Initialization, Part 1

It’s been a while, but at least some progress has been made. Hopefully during this absence of posts,
you haven’t forgotten about the basic rules of programming.

So here’s a question: before you can use an instance of a class, what must you do first?

Initialization?

That’s right. Before the client software (for this project, I’m looking at the Windows Phone 7 Connector application
for Mac OS X) can do any interfacing with the device, it must initialize itself to be ready for communication. This
post goes into the first part of what is done.

First and foremost, there are two blocks of data, 640 bytes and 708 bytes long, that are loaded into memory and
subsequently have a function applied to both of them. Right off the bat, this seems like decryption, but at that point
there really is no way to be certain. Peeking into that function, the following 16 bytes are loaded into memory:

000000

B1 CE 71 1C 1E 1B 46 87 84 A0 84 90 D5 96 22 16

..q...F.......".

Another function is then applied to these 16 bytes. Fortunately, the nature of this function was easy to discover,
as it referenced a constant array which, according to Google, is the AES substitution box.
These 16 bytes are indeed the decryption key used in the AES algorithm. This key is then expanded,
resulting in the following decryption key:

As per AES, the first round of decryption uses the input key exactly, which is why the first 16 bytes of the expanded
key are the same as the unexpanded key. However, Microsoft goes off book at this point, calling the AES routine InvMixColumns
on the key, where it normally would not be used. This leads us to our final expanded key:

Microsoft can be entertaining at times; under the presence of a debugger, the application actually uses the first expanded key (without
the InvMixColumns) as the decryption key instead, which effectively prevents it from synchronizing. Oh well, no harm done.

Decryption

So we have the decryption key; now we have to actually decrypt. The data to be decrypted:

From here, the decryption routine seems to be the standard AES decryption with the exception of InvMixColumns.
That is, the round key is added at the very beginning. Then, the rows are shifted, the bytes substituted, and the next round key added in a loop. The loop has
10 iterations, after which the final round key is added, resulting in the decrypted data.

If you didn’t notice, the first decrypted blocks are a byte-for-byte match with what is sent to the device in the USB sessions that I captured.
As always, these seem to be certificates provided by the client software to show the device that it is indeed a valid client.

The second block is more interesting as this is the first time I have seen it. The first three bytes, RSA, show that this has something
to do with RSA public key encryption. How this is used is still unknown.

What makes me happy to say is that I’ve managed to implement everything I have described above in my own C# code, which, besides making me feel
awesome, is hopefully an indication that this project is viable.

In the next part, I will go over what the software then does with these two decrypted blocks.