MOBILedit Export XML documentation

Who is this document for?

This document is a data specification for 3rd party developers

This document is an introduction to a specification of MOBILedit Forensic export XML. It describes the format and structure of the export XML, as well as additional rules that affect its appearance. It is primarily intended for third-party developers who will further process the export XML and import its data to their solutions such as databases or viewers of digital evidence.

Basic concepts

Data (e.g. contacts, messages, call logs) obtained from the device is referred to as items and a set of such items as a container. They usually have an almost identical tag name distinguished only by quantity, such as CONTACT and CONTACTS, MESSAGE and MESSAGES, CALL and CALLS. However, even items are such, only smaller, containers that contain information of various natures: texts, numbers, logical values, dates, addresses, etc. Gradually, the designations CONTAINER, ITEM, and PART have become established for this triad of data of various levels. The first two are represented in the XSD file by the abstract types CONTAINERTYPE and ITEMTYPE. PART (leaf in the XML tree) is expressed by its string value supplemented by various attributes. In the past, this simple data structure would suffice, but in modern devices with a large number of applications, there was a need to group them into even higher units (SOURCE and SOURCES tags). Also, various file systems are an essential part of them (FILESYSTEM, FOLDER, FILE tags, and others). And to ensure that the data is not completely passive, e.g. the IDENTIFIERPART, DATASOURCEPART tags take care of their activation (interconnection). Finally, the addition of the MEFEXPORT root tag and other auxiliary tags (e.g. PROPERTIES, PHONEPHOTO) created a comprehensive set used to describe all the information extracted from a physical device or other sources. It remains to add that the relationship between CONTAINER, ITEM, and PART is not always so one-way and there is a set of exceptions in their interconnection.

Brief description of XML

Although XSD allows great variability in the data structure, the generated XMLs show identical features, which can be described relatively easily. The introductory tag MEFEXPORT (root) contains a set of PROPERTIES with information about the case, the examiner, the device, and the application itself. The most important, however, is the SOURCE tag (currently just one), which accumulates a description of all device data (or alternative data source). SOURCE again first of all contains information about the device, including its image. This is followed by a description of all the files that are part of the export. These ones are divided according to the physical or logical storage into one or more FILESYSTEM (FILESYSTEM corresponds to the classic storage composed of FOLDER and FILES). Other tags represent various containers with global data (contacts, SMS, MMS, etc.) followed by data obtained by application analysis. Each application has its own SOURCE, which encapsulates its data and uses the same subtags as the SOURCE on the global level to record them. All applications are grouped in one SOURCES container.

More about files

All files and directories in the export are included under one or more FILESYSTEM tags. FILESYSTEM must contain exactly one FOLDER, which can already contain any number of other FOLDER and FILE tags. It is worth noting here that although FOLDER is of type ITEMTYPE, it contains other tags of ITEMTYPE type (FOLDER and FILE). The FILEPART tag is used where it is needed to link a specific file. Linking is done via the path attribute. Important tags of the ITEMTYPE type, which also use a link to the FILEPART file, are the so-called media files AUDIO, IMAGE, VIDEO and, surprisingly, DOCUMENT (the parent tag is always MEDIA). All of these must contain exactly one FILEPART tag. Another IMAGEPART tag has more options, it can be linked to both a file (FILE) and an image (IMAGE) via the path attribute. Just the IMAGE tag can contain other interesting data (e.g. width and height). The last of the important ones that contain FILEPART is the MESSAGEFILE tag, which is an attachment (even multiple) inserted into a message. If it is a physical location of files, then they are on the relative path to the export XML, this path is specified in the ‘files’ attribute of the MEFEXPORT tag.

Containers, items, parts, and others

Genuine containers derived from CONTAINERTYPE are: SOURCES, SOURCE, ACCOUNTS, ALARMS, AUTOFILLS, BOOKMARKS, BTPAIRINGS, CALLS, CELLTOWERS, CONTACTS, CONTAINER, CONVERSATIONS, COOKIES, CREDITCARDS, DOWNLOADS, EVENTS, FILESYSTEM, GROUPS, LOGITEMS, MEDIA, MEDIAFOLDER, MESSAGES, NETWORKS, NEWS, NOTES, NOTIFICATIONS, PAGES, PASSWORDS, PLACES, ROUTES, SEARCHES, TASKS, TRANSACTIONS, TYPEDTEXT

Genuine items derived from ITEMTYPE are: ACCOUNT, ALARM, AUTOFILL, BOOKMARK, BTPAIRING, CALL, CELLTOWER, CONTACT, ITEM, CONVERSATION, COOKIE, CREDITCARD, DOCUMENT, DOWNLOAD, EVENT, FOLDER, FILE, GROUP, LOGITEM, AUDIO, IMAGE, VIDEO, MESSAGE, MESSAGEFILE, NETWORK, NEWSITEM, NOTE, NOTIFICATION, PAGE, PASSWORD, PLACE, ROUTE, SEARCH, TASK, TRANSACTION, WORD

Genuine parts derived from character string are: ADDRESSPART, BOOLPART, CAMERABALLISTICSPART, DATASOURCEPART, DATEPART, DATETIMEPART, DURATIONPART, ENUMPART, FILEPART, GENDERPART, GEOPART, IDENTIFIERPART, IDREFERENCEPART, IMAGEPART, NUMBERPART, RECURRENCEPART, TEXTPART, TIMEPART, THUMBNAILPART, URLPART

Individual containers are specialized for certain items. For which, it is already known by their name (e.g. TASKS for TASK). However, there are also various other data that do not correspond to any specific container. In this case, the general CONTAINER is used, the data in it are marked as ITEM. Unfortunately, there is currently no easy way to programmatically recognize what type of data it is.

In order not to isolate the data in their containers, they are linked together by references. There are two tags for this: IDENTIFIERPART and IDREFERENCEPART. What type of binding it is, can be decided according to the attribute "type", e.g. if type is "account", the linked tag is ACCOUNT. However, not all values of the type attribute may be clear, so it is important to verify the target item (or items). In addition, it may not always be valid.

Data sources

Each ITEMTYPE obtained by analyzing a particular file should list that file using the DATASOURCEPART. Pairing with a physical file is the same as other links to the file system, i.e. via the path attribute. There can be more links, they can also be hierarchized in a simple way.

A few notes on the use

Over the years of use, it has crystallized additional rules that are not and cannot be recorded in the XSD file. They are:

• The application SOURCE tag no longer contains any other SOURCE.

• The binding of the data item (ITEMTYPE) with the corresponding ACCOUNT tag is done via IDREFERENCEPART (type = "account"), any other variants even valid according to XSD are inadmissible.

• The GROUP tag contains references (IDENTIFIERPART, type = "participant") to its members (CONTACT and GROUP), not the other way around.

• The CONVERSATION tag contains references (IDENTIFIERPART, type = "participant") to its members (CONTACT, GROUP, and ACCOUNT).

• The MESSAGE tag contains (if known) a reference (IDREFERENCEPART, type = "conversation") to its conversation (CONVERSATION), the opposite approach is no longer used.

• The MESSAGE tag contains (if known) references (IDENTIFIERPART) to the items involved. The type is "from", "to" or a general "participant". Other types of messages may use other variants, e.g. "cc", "bcc", etc.

• The CALL tag follows similar rules like MESSAGE.

• Do not mix different reference parts (IDENTIFIERPART vs. IDREFERENCEPART) for the same situations e.g. MESSAGE to its CONVERSATION.

Explanation of table items

Occurrence indicators

Data types

Containers in detail - attributes and nested tags

All red values in the table are inherited from CONTAINERTYPE.

For dtp and cnt, see the table of data types and the table of occurrence indicators in the legend section.

¹⁾ “forensic” if data were obtained by file analysis

²⁾ sorting flag

³⁾ this is the real name of the attribute

⁴⁾ MEFEXPORT and PROPERTIES are not genuine ITEMTYPE tags, but they have a very important function in our XML tree

⁵⁾ the "reference" attribute is no longer used

¹⁾ MEFEXPORT and PROPERTIES are not genuine ITEMTYPE tags, but they have a very important function in our XML tree.

²⁾ ACCOUNT, ALARM, AUTOFILL, BOOKMARK, BTPAIRING, CALL, CELLTOWER, CONTACT, ITEM, CONVERSATION, COOKIE, CREDITCARD, DOCUMENT, DOWNLOAD, EVENT, FOLDER, FILE, GROUP, LOGITEM, AUDIO, IMAGE, VIDEO, MESSAGE, MESSAGEFILE, NETWORK, NEWSITEM, NOTE, NOTIFICATION, PAGE, PASSWORD, PLACE, ROUTE, SEARCH, TASK, TRANSACTION, WORD

³⁾ unused combination

Items in detail - attributes and nested tags

All red values in the table are inherited from ITEMPTYPE.

¹⁾ ADDR, BOOL, etc. are abbreviations for the individual parts described above

²⁾ MESSAGEFILE must contain at least one FILEPART or one URLPART

³⁾ PROPERTIES is not genuine ITEMTYPE, but includes most of the PART tags

Parts in detail - attributes

XSD file structure specification

The following XSD file describes the structure of MOBILedit export XML format. Feel free to download it here.