DECEMBER 5, 2008

Multimedia Message System (MMS) MM1 Protocol

UPDATE: In Spring of 2010 BreakingPoint unveiled the pioneering Cyber Tomography Machine to help you with problems such as the ones described in this post. Read more.

In the most recent StrikePack we included an AppSim to support the Multimedia Messaging Service (MMS) MM1 protocol. MM1 is the 3GPP interface between the MMS User Agent, which generally resides on the Mobile Station (MS), and the MMS Center (MMSC), and is used for sending and retrieving Multimedia Messages to and from the MMSC and for managing the subscriber's Multimedia Mailbox (MMBox) on the MMSC. This is essentially how your cellular phone sends and retrieves picture or video messages.

Having worked for nearly my entire tenure at Sipera Systems with cellular protocols (focused on dual-mode VoIP phones), I was already familiar with the overall architecture but I had not had the opportunity while there to dig into the details of the MMS system. Overall, the MMS system encapsulates eleven different protocols, aptly named MM1 through MM11. The AppSim included in the most recent StrikePack implements some basic support for the first one, MM1.

MM1, as mentioned above, handles communication for sending and retrieval of media messages via the MMSC, which houses the user's MMBox. This communication protocol is request and response based and can be sent over either of two transports, the Wireless Session Protocol (WSP, cellular network) or HTTP (data network). Our AppSim currently only supports transport over HTTP as this is what is more likely to be found on a data network. In both cases, MMS Protocol Data Units (PDUs) are transported as a content-type of 'application/vnd.wap.mms-message'. If the message contains media, it is transported as a content-type of 'application/vnd.wap.multipart.related' and is structured per RFC-2387.

The bit about MM1 that I found rather interesting is that, intended to be used over cellular networks, a fairly diligent effort was made to reduce the size of messages as much as possible even though the protocol was seemingly based on the Internet Message Format (IMF, RFC-2822) which is a generalized text (specifically, 7-bit US-ASCII) data messaging format resembling SMTP messages or HTTP responses with single-line header fields and an optional body, or payload, portion. The size reduction is accomplished using a portion of the Wireless Application Protocol (WAP) standard called Wireless Session Protocol (WSP). The WSP protocol provides a utility for encoding well-known IMF headers into much shorter, binary representations usually consisting of a single 8-bit integer value called the 'Type' which represents the header name and a Type-specific value of one or more of six primitive data types of 'bit', 'octet', 'uint8', 'uint16', 'uint32' and 'uintvar' which represent the header's value.

'uintvar' is a variable length unsigned integer, itself with it's OWN special type of encoding which consists of taking your normal integer value of whatever size, splicing it up into groups of 7 bits and putting those into subsequent octets using the eighth and most significant bit of each octet as a 'continue' indicator to the decoder so that while decoding it knows the integer value continues with more data in the next octet. A pretty slick way to do it, but very much unreadable to a human on the wire and a bit of a pain to implement. I definitely had to dust off my bitwisdom to tackle that one.

Due to there apparently not being an existing Ruby library for encoding/decoding WSP, I essentially had to code most of this up myself from scratch using the specification and a few example pcaps. Because each header and it's value has it's own, often unique encoding, even for only the headers that we currently support it was a fairly tedious task and required quite a bit of testing and bug fixing. Luckily Wireshark does have a dissector for MMS (filter for mmse) and was able to lend a hand parsing the development AppSim's output as I built it. This code is essentially what translates the header setting values that our users provide to the AppSim into the proper binary-encoded header block of data used in the configured action's associated message on the wire.

The BreakingPoint MMS-MM1 AppSim currently supports four actions equating to two types of MM1 messages; Raw Request, Raw Response, Raw Body Request, and Raw Body Response. The first two require only that the user upload two files, each containing the message to be sent's raw header data and raw body data. These are ideal for use in replicating messages from a source pcap or other data capture. The second two require the user upload a single file, the message to be sent's raw body data and have a number of settings which when configured will generate a properly encoded MM1 header to append the supplied raw body data to.

Look for AppSims for both WSP and the remaining MMS protocols (MM2-MM11) in future StrikePack updates!