 |
| Now with attachment info! Catch the excitement! |
We recently noticed that while some commercial forensic tools show Windows Phone 8.10 MMS transaction information (eg Date, Phone number), they do not show or list the accompanying MMS file attachments. Welcome masochistic script monkey! May I take your "safe word"?
In Windows Phone 8.10, a user can send an MMS containing a picture (eg camera JPEG, PNG screen capture), a video (eg camera captured MP4), a Contact (via VCARD text) and/or a VoiceNote (via .AMR audio). These attachments are recopied/renamed/stored as weirdly named .dat files in various sub-directories (named "A" to "P") under Data:\SharedData\Comms\Unistore\data\7.
Received MMS are also stored as .dat files under the same location so it isn't immediately obvious what attachments go together and/or which were sent/received.
The main issue is finding a link between the MMS database transaction entries and the actual stored .dat file(s) which were sent/received.
There may be a more comprehensive link yet to be discovered, but the best link we've found so far is via the filesystem "Last Modified" timestamp of the .dat files and a timestamp found in the "Message" table of the store.vol database.
However, because file system modified times can vary by 1-2 seconds when compared to what is listed in the MMS database, we wrote two scripts - one to sort/print the filesystem's .dat attachment files in chronological order (wp8-1-mms-filesort.py) and a separate script (wp8-1-mms.py) to print the store.vol database MMS records in chronological order. The discerning simian analyst can then make the decision about which attachments go with which MMS based on the timestamp information, MMS total size, file types and individual file attachment sizes. Additionally, they can use the calculated SHA256 hash to locate any sent MMS files (received MMS files are initially stored only as .dat files).
The two scripts are available from my GitHub site and have been created/tested on Windows 7 PC running Python 2.7 using test data from a Nokia Lumia 530 running Windows Phone 8.10.
Background
The "store.vol" database is an ESE database located in Data:/USERS/WPCOMMSERVICES/APPDATA/Local/Unistore/ that contains 3 tables of interest for MMS:- Message (contains metadata of sent/received MMS)
- Recipient (contains sent MMS phone numbers)
- Attachment (contains metadata about sent/received MMS attachments)
These tables have weird combination numeric/letter strings used for their column/field names (eg "0037001f").
Therefore, throughout this blog post we will use alternative monkey monikers (eg Size, Flag, Filename0) to keep things sane.
Here's an overview of how the various tables and .dat files fit together.
Note: Due space constraints, this relationship diagram does NOT include every field from each table.
 |
| So, are you seeing anyone right now? Oh ... it's complicated? |
Every MMS will have a "Message" table entry. If it's a sent MMS, there will be a corresponding "Recipient" table entry (containing the Destination Phone number and Timestamp3).
Every sent/received MMS Message will have at least 2 "Attachment" table entries - one for a "smil" message layout XML file and one for each attached file (eg one for each picture).
Filename aliases (eg "FOT1234.jpg") for attached Images/Videos/Text/Voicenotes/VCARDs will appear in both the "smil" .dat file and in the corresponding "Attachment" table entry.
Each attachment's content will be stored in a separate .dat file with a similar filesystem "Last Modified" timestamp to the "smil" layout .dat file. This "Last Modified" timestamp will approximately equal the relevant MMS's Timestamp2 value in the "Message" table.
We recommend using OSForensics "ESEDB Viewer" to view "store.vol" as it seems to have more reliable search functionality (and possibly shows more table columns) than NirSoft's ESEDatabaseView.
It's one thing to view "store.vol" using a dedicated viewer but to script a solution (independent of third party libraries) we have to look at how each field of interest is stored in the raw hex.
For the "Message" table there are 2 variations of MMS record - one for Sent MMS and one for Received MMS.
Each Received MMS "Message" record looks like:
 |
| Received MMS format |
Each Sent MMS "Message" record (contains no phone numbers) looks like:
 |
| Sent MMS format |
The important "Message" fields are colour highlighted in the diagrams:
- Msgid (Unique id number for each "Message" entry.)
- Flag (Sent (33 decimal) / Unread(0) / Read(1). Draft MMS are stored using a different Message record format which contains "IPM.MSG" (instead of "IPM.MMS") and their Flag is set to 41 decimal. They will not be discussed further in this post.)
- Size (Total MMS size in bytes. This will help when there are multiple file attachments per MMS.)
- Timestamp2 (File system Last Modified time (approximate). For sent MMS, this corresponds to the time of creation/last update and not the time actually sent.)
- Timestamp3 (Sent/Received time common to both "Message" / "Recipient" tables.)
- Phone0/Phone1/Phone2/Phone3 (Phone number for received MMS. These tend to be set to the same value when present. Sent message phone numbers have to be obtained from the "Recipient" table.)
Each "Recipient" table record looks like:
 |
| Recipient format |
Where X represents a number of bytes that we don't really know/care about. All strings are null-terminated UTF-16-LE encoded. Timestamps are LE 8 byte integers representing the number of 100 ns intervals since 1 JAN 1601 (MS FILETIME). The string "@.SMS" is actually "x40x01x53x00x4dx00x53x00x00x00" in hex.
Each "Recipient" table record should correspond to a sent SMS/MMS. Our ass-umption here is that it's impossible to simultaneously send both SMS and MMS with the same Timestamp3 value. So if we find a "Recipient" table entry which has a Timestamp3 value that also occurs in a "Message" table "Sent Record", we can ass-ume that it is a sent MMS. Sent SMS have an "IPM.SMStext" value set instead of "IPM.MMS" in the "Recipient" table.
The important "Recipient" fields are:
- Msgid (Unique id number for each "Message" entry.)
- Timestamp3 (Sent/Received time common to both "Message" / "Recipient" tables.)
- DestPhone (Destination Phone number string.)
Each "Attachment" table record looks like:
 |
| Attachment format |
Where X represents a number of bytes that we don't really know/care about. All strings are null-terminated UTF-16-LE encoded.
Filename0 has been observed to start with "<cidText" or "<cidSmil" or "<cidImage" or "<cidVideo" or "<cidAudio" or "<cidVCard". It has also been seen in the form "<123>" - where "<123>" represents a 3 digit number that increases with each "Rowid". MMS using the "<123>" alias format also had the fixed alias value of "<0000>" for the "smil" layout files.
Draft SMS/MMS do not use the "<>" method of enclosing aliases so cannot be found in the same manner.
The important "Attachment" fields are:
- Msgid (Unique id number for each Message entry.)
- Size (Attached file's size in bytes. There can be multiple file attachments per MMS. Adding all the "Attachment" sizes for a given "Msgid" should equal the "Message" table's size for that same "Msgid".)
- Filename0 (Alias enclosed by "<" and ">" characters. We can use it to identify MMS attachment entries (eg "<cidImage_FOT1234.JPG>").)
- Filename1 (Alias used in "smil" files. eg "FOT1234.JPG".)
- Filename2 (If it's a sent MMS, this will be the actual source Filename (eg WP_20151203_001.JPG). If it's a received MMS, this is typically set to the same value as Filename1.)
- Filetype (Description of the type of file.)
The Filetype values have been observed as:
- "application/smil" (for the MMS layout)
- "text/plain" (for the MMS text content)
- "image/jpeg" and "image/png" (for attached camera/screenshot images)
- "audio/amr" (for attached VoiceNotes)
- "video/mp4" (for attached camera videos)
- "text/x-vcard" (for attached Contacts)
It's been briefly mentioned above but the last piece of the banana is that MMS .dat files are stored under "Data:\SharedData\Comms\Unistore\data\7". One .dat file is required for each sent/received file. Additionally, every MMS has a "smil" XML layout file which lists an alias to the attached file(s) (eg <img src="FOT1234.JPG" region="Image"/>). We can also find that alias mentioned in a corresponding "Attachment" table entry for that MMS.
Here's an example "smil" .dat file:
<smil><head><layout><region id="Text" height="50%" width="100%" left="0" top="50%" fit="scroll"/><region id="Image" height="50%" width="100%" left="0" top="0" fit="meet"/></layout></head><body><par dur="5000ms"><img src="FOT1234.JPG" region="Image"/><text src="Text_0.txt" region="Text"/></par></body></smil>
The "text src" consistently seems to be set to "Text_0.txt". During testing we did not try sending multiple images in the same MMS with each image having it's own accompanying text. However, we suspect that each text entity would then get its own "text src" element and unique alias (eg "Text_0.txt", "Text_1.txt"). With our current understanding, determining the order of these multiple texts would be difficult but we can still retrieve the text content.
Note: "Data:\SharedData\Comms\Unistore\data\7" has been observed to also contain Draft MMS (text content) and Received Email attachment .dat files.
Attached files for Draft MMS (eg pics) do not appear to be stored in .dat files under that directory. Editing a Draft MMS should update the "Last Modified" filesystem time on the .dat files.
You might also have noticed that the constant 0x07000000 value appears in each of the above records. Coincidentally(?), 7 is also the rowid corresponding to the "SMS" row in the "Store" table. This kinda makes sense as both SMS and MMS are grouped together under the same Messaging menu on a Windows Phone 8 device.
It seems there is a "Store" table row for each potential store location on the phone (eg Outlook, SMS, ExternalStore, OneDrive etc).
Scripting and Testing
wp8-1-mms-filesort.pyAssuming the analyst has already exported the contents of "Data:\SharedData\Comms\Unistore\data\7" (eg using AccessData FTK Imager), we can write a Python script to create a clickable HTML table (sorted by "Last Modified" time) of .dat attachments. The script can also output the same data to a Tab Separated Variable (TSV) output file for importing into an analysis spreadsheet.
Here's the help for wp8-1-mms-filesort.py:
c:\Python27\python.exe wp8-1-mms-filesort.py
Running wp8-1-mms-filesort.py v2015-11-24
Usage: wp8-1-mms-filesort.py -i inputfiledir -t output.tsv (Optional) -o output.html (Optional)
Options:
-h, --help show this help message and exit
-i DIRNAME Input Directory To Be Processed
-t OUTPUTTSV Output Tab Separated Variable (TSV) filename (Optional)
-o OUTPUTHTML Output HTML filename (Optional)
The script walks through each input directory and looks for filenames ending in "73701.dat". It then retrieves that file's "Last Modified" time and stores the filename and timestamp for later display.
For each of the stored filenames, the script reads the file contents and attempts to calculate what type of file it is, the file size, the SHA256 Hash of the file and if it's a "smil" file, it will list any file aliases used. It then prints the file information sorted chronologically by "Last Modified" time to the command line (SHA256 Hashes are NOT printed to command line) and/or HTML and/or TSV.
By grouping the .dat files by "Last Modified" time, it should make it easier to decide which .dat files belong together.
Here is some redacted example output:
c:\python27\python.exe wp8-1-mms-filesort.py -i 7 -t fsop.tsv -o fsop.html
Running wp8-1-mms-filesort.py v2015-11-24
Parsed 57 files
Mod. Timestamp Filename Size(bytes) Type Comments
... [REDACTED]
2015-12-01T04:02:08 7\c\40000002000000073701.dat 7302 AMR
2015-12-01T04:02:08 7\d\40000003000000073701.dat 186 <smil> aud = P__4987.amr
2015-12-01T04:03:08 7\f\40000005000000073701.dat 893237 MP4
2015-12-01T04:03:08 7\g\40000006000000073701.dat 366 <smil> video =P__CD04.mp4
2015-12-01T04:05:04 7\h\40000007000000073701.dat 104 VCARD
2015-12-01T04:05:04 7\i\40000008000000073701.dat 386 <smil> VCARD present
2015-12-01T04:07:04 7\j\40000009000000073701.dat 366 <smil> video =P__BC3E.mp4
2015-12-01T04:07:04 7\k\4000000a000000073701.dat 899422 MP4
2015-12-01T04:08:20 7\l\4000000b000000073701.dat 186 <smil> aud = P__7C25.amr
2015-12-01T04:08:20 7\m\4000000c000000073701.dat 5702 AMR
2015-12-02T20:30:20 7\n\4000000d000000073701.dat 616 <smil> img = FOTDAD6.JPG, text = Text_0.txt
2015-12-02T20:30:20 7\o\4000000e000000073701.dat 624866 JPEG
2015-12-02T20:30:20 7\p\4000000f000000073701.dat 50 Unknown
2015-12-02T22:26:42 7\b\50000001000000073701.dat 52 Unknown
2015-12-02T22:26:42 7\c\50000002000000073701.dat 616 <smil> img = FOTEB94.jpg, text = Text_0.txt
2015-12-02T22:26:44 7\a\50000000000000073701.dat 571938 JPEG
2015-12-03T02:57:10 7\f\50000005000000073701.dat 38303 PNG
2015-12-03T02:57:10 7\g\50000006000000073701.dat 22 Unknown
2015-12-03T02:57:10 7\h\50000007000000073701.dat 616 <smil> img = FOT348F.png, text = Text_0.txt
2015-12-03T02:59:48 7\i\50000008000000073701.dat 616 <smil> img = FOT3070.png, text = Text_0.txt
2015-12-03T02:59:48 7\j\50000009000000073701.dat 48870 PNG
2015-12-03T02:59:48 7\k\5000000a000000073701.dat 18 Unknown
Note1: Type "Unknown" Types possibly indicate MMS message text files
Note2: Not all .dat files may belong to an MMS message (eg Received Email Attachments, Drafts)
Finished processing MMS .dat files ... Exiting ...
The corresponding output TSV looks like:
Mod. Timestamp Filename Size(bytes) Type SHA256 Hash Comments
2015-12-01T04:02:08 7\c\40000002000000073701.dat 7302 AMR CAE79982FCAD00B09707FB24FAB0D226E54E4B2DB85F926B34166B5DC7D3DBDD
2015-12-01T04:02:08 7\d\40000003000000073701.dat 186 smil 30614CF3267AD6C53B714E528F474B61C47CD10058CCB5838ACA55BA7E69C5C0 aud = P__4987.amr
2015-12-01T04:03:08 7\f\40000005000000073701.dat 893237 MP4 DC8200239F601FA8B14783BD97DDCE55E094CEA5E23D01DD3F4832A6F87A7CE2
2015-12-01T04:03:08 7\g\40000006000000073701.dat 366 smil 68A4069FB3AF78B3C045D830FCF03E964AE043E2276AD059C00A9BBFF30CEB76 video = P__CD04.mp4
2015-12-01T04:05:04 7\h\40000007000000073701.dat 104 VCARD C1DF9E80CDCB9140D2FFC427B6896BB2E67EF8F989068E6F9CCAF367D947D29B
2015-12-01T04:05:04 7\i\40000008000000073701.dat 386 smil C56C8A12E8E5E2536161B6AF52C3A20F244603F31CDF637B86B6F4AA74087A91 VCARD present
2015-12-01T04:07:04 7\j\40000009000000073701.dat 366 smil 77AEC99255C3234D2B0A1EAA5DD935D4C694255C6F4A4C821FCF0C62AC43DCE9 video = P__BC3E.mp4
2015-12-01T04:07:04 7\k\4000000a000000073701.dat 899422 MP4 D2DA77B80DC689460829C6B0F554BC0778348EA149DED1242E80787F005958D3
2015-12-01T04:08:20 7\l\4000000b000000073701.dat 186 smil 2EF5F8BEBC9C03665DB666539F1F9CB595CF543C541537E8EB104A81C60659AE aud = P__7C25.amr
2015-12-01T04:08:20 7\m\4000000c000000073701.dat 5702 AMR 50AD1A3004E4C1541F507B38DB867A9186237612FF312FDF7E2BE4370617F3E6
2015-12-02T20:30:20 7\n\4000000d000000073701.dat 616 smil AA2382E8BC8DEA7A7176F21C5FD58C4E52E54608404DE437B1C3299AF0206192 img = FOTDAD6.JPG, text = Text_0.txt
2015-12-02T20:30:20 7\o\4000000e000000073701.dat 624866 JPEG 4BA420B740F5C8DEF862690566195CE620C2495406CDD8383362713A2A38E562
2015-12-02T20:30:20 7\p\4000000f000000073701.dat 50 Unknown E2E39EA85A25B1C02FB287049F1179B51DED480B99896B4E8E70F773BD2D7158
2015-12-02T22:26:42 7\b\50000001000000073701.dat 52 Unknown 7DE34A123DA5F220CD6346F8CE852036C255A4FE4C81C130EB465AC6378193C0
2015-12-02T22:26:42 7\c\50000002000000073701.dat 616 smil 144753D485039158AB10A06D86A6D421983EC12D708E992A8DA408B079917020 img = FOTEB94.jpg, text = Text_0.txt
2015-12-02T22:26:44 7\a\50000000000000073701.dat 571938 JPEG 139A1E26E6D317F1BBC1C36A7B98AFD3875351B6254B4AEB336F684841F23759
2015-12-03T02:57:10 7\f\50000005000000073701.dat 38303 PNG D4DAA620FCF32FA0198CAE17AD55B3F847243617F034C4A0BB88356853C77662
2015-12-03T02:57:10 7\g\50000006000000073701.dat 22 Unknown 1BDA3B8EF697CC23E5299068695114F67F7B03C0DD7A4BFEB72F553088AB4009
2015-12-03T02:57:10 7\h\50000007000000073701.dat 616 smil D28199571A7C838C52206E4DA69D4C2A02A44B851B57DF739DBE2E35F8B6C696 img = FOT348F.png, text = Text_0.txt
2015-12-03T02:59:48 7\i\50000008000000073701.dat 616 smil 4E2D452A0190125D1D44062DEB300B3E00FC2FD0F33E55392A12CCFC3925188E img = FOT3070.png, text = Text_0.txt
2015-12-03T02:59:48 7\j\50000009000000073701.dat 48870 PNG 3360CD0D57820536D86841DCA94453049B6C4B3D95A3D3B25B91B4CD5ABD50E7
2015-12-03T02:59:48 7\k\5000000a000000073701.dat 18 Unknown 094D1EA6F14A289EC08AF1F85CE1B55A2D95937915A67061FFA85DFCD4284B37
Note1: "Unknown" Types possibly indicate MMS message text files
Note2: Not all .dat files may belong to an MMS message (eg Received Email Attachments, Drafts)
Apologies for the Blogger formatting - this is why we didn't print the SHA256 hash to the command line!
And here's what the corresponding HTML output looks like in a web browser:
 |
| HTML Output from "wp8-1-mms-filesort.py" |
When we click on an HTML file link, we can view that attachment more readily. However, for the HTML links to work, the HTML file must be in the same directory as the extracted "7" directory.
In this example HTML output, we have the .dat files from a sent MMS containing two pictures (saved from the web) and a text set to "Funny? Don't remember that".
 |
| Sent MMS with text and 2 pictures |
When we click on the first row's file link (not circled) and open it via Notepad we see the text:
Funny? Don't remember that
Clicking on the "smil" file's link (circled in orange) and opening it via Notepad looks like:
<smil><head><layout><region id="Text" height="50%" width="100%" left="0" top="50%" fit="scroll"/><region id="Image" height="50%" width="100%" left="0" top="0" fit="meet"/></layout></head><body><par dur="5000ms"><img src="FOT66CB.jpg" region="Image"/></par><par dur="5000ms"><img src="FOT9241.jpg" region="Image"/><text src="Text_0.txt" region="Text"/></par></body></smil>
This tells us that there are 2 images (FOT66CB.jpg, FOT9241.jpg) and a text message associated with this MMS. To determine if this MMS is sent/received and/or the sent/received time and/or the phone number, we can process "store.vol" using the second script (wp8-1-mms.py).
Clicking on the JPEG link (circled in green) displays this picture in the browser:
 |
| Indeed! |
Clicking on the JPEG link (circled in red) displays this picture in the browser:
 |
| Do you Mind?! |
Ah, what's the point in blogging if we can't share pictures of toilet trained monkeys?!
Ahem, continuing on ...
wp8-1-mms.py
Assuming the analyst has already exported "Data:/USERS/WPCOMMSERVICES/APPDATA/Local/Unistore/store.vol", we can write another script (wp8-1-mms.py) to list MMS information for correlation with the output of wp8-1-mms-filesort.py. Essentially, wp8-1-mms.py prints out the information for every MMS attachment (sorted by Timestamp2).
Here's the help for wp8-1-mms.py:
c:\Python27\python.exe wp8-1-mms.py
Running wp8-1-mms.py v2015-11-14
Usage: wp8-1-mms.py -s store.vol -o output.tsv(Optional)
Options:
-h, --help show this help message and exit
-s STOREFILE store.vol file
-o OUTPUTFILENAME Output Tab Separated Variable filename (Optional)
Finding all MMS attachments requires searching "store.vol" for a slight variation of the Filename1 alias used in the "smil" file (eg "<cdImage_FOT1234.jpg>" instead of "FOT1234.jpg", "<123>" instead of "cid:123").
Note: It is thought that the "cid:123" style of alias operates in a similar manner to the "FOT1234.jpg" alias but we have not been able to generate the "cid:123" alias during testing.
Fortunately, we can generalise this to a search for a group of letters starting with "<cid" and/or a group of digits enclosed by "<" and ">". Once we have found a list of these hits, we can retrieve that "Attachment" row's values (Filename0, Filename1, Filename2, Type, Size) and store them in a dictionary (creatively called "attachments") keyed by "Msgid" for later use.
Similarly, we can find all "Recipient" table entries by searching for the "@.SMS" pattern mentioned earlier. We store the retrieved row data (Timestamp3, DestPhone) in another dictionary (called "recipients") keyed by "Msgid" for later use.
Next, we search for "Message" table entries by searching for the "IPM.MMS" pattern and store the retrieved data (Timestamp3, Timestamp2, Phone, Flag, Size) in a dictionary (called "mmsdict") keyed by "Msgid". If we don't find a Phone number in the "Message" record (ie Sent MMS), we use the retrieved "Msgid" to obtain the "DestPhone" number from the "recipients" dictionary populated earlier.
Finally, we can iterate through the "mmsdict" for each "Msgid" and retrieve the corresponding "attachments" info - there will usually be multiple attachments for each MMS dict entry.
The output will be printed to the command line (looks a bit cramped) and/or TSV file (optional).
Here's a redacted sample of the wp8-1-mms.py command line output. For brevity, we've edited the output to highlight the corporate fatcat/toilet monkey MMS message sent earlier. The command line output is pretty cramped so we recommend outputting to TSV.
c:\python27\python.exe wp8-1-mms.py -s store.vol -o store-op.tsv
Running wp8-1-mms.py v2015-11-14
Opening store.vol...
Processing Attachment table ...
57 Attachment "<cid" hits found in store.vol
0 Attachment "<d+>" hits found in store.vol
57 Total Attachment hits found in store.vol
Attachment ASIZE ERROR! at offset 0x12004c ... skipping this hit
Attachments sorted by msgid ...
===================================
[REDACTED]
No. Attachments = 4
msgid = 48 : (u'<cidText_0>', u'Text_0.txt', u'Text_0.txt', u'text/plain', 52)
msgid = 48 : (u'<cidSmil>', u'Smil.txt', u'Smil.txt', u'application/smil', 742)
msgid = 48 : (u'<cidImage_FOT66CB.jpg>', u'FOT66CB.jpg', u'Monkey throwing poo by SheriffBean on DeviantArt.jpg', u'image/jpeg', 37397)
msgid = 48 : (u'<cidImage_FOT9241.jpg>', u'FOT9241.jpg', u'Lolcats Funny Pictures Of Cats With Captions.jpg', u'image/jpeg', 34529)
[REDACTED]
Processed/Stored 56 out of 57 Attachment hits
Processing Recipient table ...
55 Recipient hits found in store.vol
[REDACTED]
Recipients sorted by msgid ...
===================================
[REDACTED]
msgid = 42 : ('2015-11-11T19:36:25', u'+12345678900')
msgid = 48 : ('2015-11-15T21:47:53', u'+12345678900')
msgid = 49 : ('2015-11-15T21:51:32', u'+12345678900')
[REDACTED]
Processed/Stored 54 out of 55 Recipient hits
Processing Message table ...
19 IPM.MMS Message hits found in store.vol
MMS sorted by msgid ...
===================================
[REDACTED]
msgid = 48 : ('2015-11-15T21:47:53', '2015-11-15T21:47:52', u'+12345678900', 33, 72720)
[REDACTED]
Processed/Stored 19 out of 19 Message hits
Printing finalized table sorted by Timestamp2 ...
===================================================
Timestamp2 Msgid Timestamp3 Phone Flag TotalSize Type Filesize Filename0 Filename1 Filename2
[REDACTED]
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 text/plain 52 <cidText_0> Text_0.txt Text_0.txt
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 application/smil 742 <cidSmil> Smil.txt Smil.txt
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 image/jpeg 37397 <cidImage_FOT66CB.jpg> FOT66CB.jpg Monkey throwing poo by SheriffBean on DeviantArt.jpg
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 image/jpeg 34529 <cidImage_FOT9241.jpg> FOT9241.jpg Lolcats Funny Pictures Of Cats With Captions.jpg
[REDACTED]
Finished processing store.vol ... Exiting ...
Looking at the "finalized table" results at the end, we can see that each attachment's Timestamp2 values are all equal to 2015-11-15T21:47:52. This does not correspond with our earlier results from wp8-1-mms-filesort.py (where the JPEG files had different "Last Modified" times to the "smil" and text files). Perhaps the Timestamp2 values in store.vol were written before the actual .dat files were written around the 52-53 second boundary?
Anyway, this shows that there can be some discrepancy between the .dat files "Last Modified" times and the Timestamp2 values recorded in "store.vol". Hence the need for a meat based decision maker!
We can also see that we can use the Msgid (eg 48) to group common MMS attachments together.
Timestamp3 is a common value to both "Message" and "Recipient" tables and seems to be the timestamp quoted for sent/received MMS by commercial forensic tools.
The Type value of 33 indicates that this is Sent MMS.
The TotalSize figure of 72720 equals the sum of each attachment's Filesize (52 + 742 + 37397 + 34529 = 72720).
Filename1 is the alias used for each attached file in the "smil" layout file (eg FOT66CB.jpg, FOT9241.jpg).
We can see that for saved pictures which were then sent via MMS, the original filename appears in Filename2 (eg "Monkey throwing poo by SheriffBean on DeviantArt.jpg").
By using the Filename1 alias, Timestamps and individual file sizes, we should be able to match these store.vol results with the previous .dat results.
That is, there are 4 files listed from store.vol (Text_0.txt, Smil.txt, FOT66CB.jpg, FOT9241.jpg) which have corresponding matches in the HTML output table produced by wp8-1-mms-filesort.py.
For a given attachment, you might not find a file with the Filename2 name on a Windows Phone 8.10 device/SD card as it could be a received file and the Filename2 string was actually sourced from the sender.
In this case, the file will only exist as a .dat file (assuming it was not re-saved locally after reception).
Alternatively, after sending an MMS attachment, the user may delete it from the phone or it might have been sourced from an SD card. For a file stored on an SD card/another device, we should be able use the SHA256 hash calculated from the relevant .dat file to help confirm the external file's identity.
And here is the more conveniently formatted TSV output file contents from wp8-1-mms.py ...
Timestamp2 Msgid Timestamp3 Phone Flag TotalSize Type Filesize Filename0 Filename1 Filename2
[REDACTED]
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 text/plain 52 <cidText_0> Text_0.txt Text_0.txt
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 application/smil 742 <cidSmil> Smil.txt Smil.txt
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 image/jpeg 37397 <cidImage_FOT66CB.jpg> FOT66CB.jpg Monkey throwing poo by SheriffBean on DeviantArt.jpg
2015-11-15T21:47:52 48 2015-11-15T21:47:53 +12345678900 33 72720 image/jpeg 34529 <cidImage_FOT9241.jpg> FOT9241.jpg Lolcats Funny Pictures Of Cats With Captions.jpg
Blogger formatting strikes again! Basically the TSV output is the same as the command line output but its easier to import into a spreadsheet.
For shiggles, the wp8-1-mms.py script was run against a Lumia 520 / Windows Phone 8.0 store.vol but it seems that the store.vol offsets used are different and so the script did not work as intended.
It is ass-umed this script will work with other Windows Phone 8.10 devices however because Monkey has to believe he didn't waste his time with some one-off scripts ... grrr!
Also please note that on Windows Phone 8 devices, the displayed Messaging timestamps do not list the seconds (only hours/minutes). So while we can say that Timestamp3 is accurate to the minute, we cannot definitively claim its accuracy in seconds.
Some Final Thoughts
The wp8-1-mms.py store.vol script relies on searching the table records for unique markers (eg "IPM.MMS", "@.SMS", "<cid") and then reading/storing the surrounding field values. That's why we can extract data without knowing the entire structure of each database record.We could have used a third party library to query the store.vol database directly but this means users would have to install that library on their analysis PCs (which are usually isolated from the Internet). For those interested, Jon Glass has blogged about Python coding using Joachim Metz's libesedb and Alberto Solino's Impacket ESE libraries here.
Be aware there may be more .dat files than MMS attachment entries in "Data:\SharedData\Comms\Unistore\data\7" (eg Received email attachments and/or Draft text). Not every .dat file may have a corresponding MMS.
GPS and other EXIF metadata can be present on sent/received images/videos (depending on the sending phone's settings and/or if the original file had embedded metadata). This can help an analyst decide if a picture was originally taken with the target device and/or the time/location of the picture.
This post only looked at allocated MMS - deleted MMS is an area for further research. Upon MMS deletion, "Message" / "Attachment" / "Recipient" entries should be deleted/overwritten from "store.vol". However, ESE .log transaction files and/or pagefile.sys may still contain enough information from deleted MMS to recreate the "store.vol" records. Recovering the .dat file content and linking it to a MMS transaction would be more complicated however.
Sending a Location (via Messaging) does not utilize the "Attachment" table so these cannot be retrieved by the scripts in this post.
For Location messaging, an "IPM.SMStext" record entry is made in the "Message" table and it has a Windows Phone URL string in the content column ("0037001f"). Analysts can browse to that URL and view a map centered on the sent Location. This map also has a timestamp and what appears to be an accuracy radius.
The URL format looks like:
http://www.windowsphone.com/l1/ZZZ
Where ZZZ = 13 character random code. Both of our test samples had 13 character codes starting with "CI" but your mileage may vary.
Theoretically, it should be possible to scan a store.vol (or pagefile.sys) for these types of URL and if found, they can tie a device to a specific location and time (assuming you can prove they were sent SMS).
And so finishes another glorious Windows Phone 8.10 post! For some reason, the phrases "One trick monkey" and "One off scripts" seem to be reverberating in monkey's caffeine addled brain ... Good! ;)
