The proper method for inquiring after the properties of things is to deduce them from experiments.
~ Isaac Newton
Quick note: The images in this post are watermarked by Gillware Digital Forensics, now known as Tetra Defense.
Testing is the way to figure out YOUR favorite artifacts.
This is a test. This is only a test.
In saying “only,” I’m certainly not implying that testing isn’t important. Testing is one of the most powerful, yet least talked-about or taught techniques in digital forensics. Testing is the way to find the answers to how things work. It’s the way to discover the answers when Google doesn’t have them (or just gets sort of close). In digital forensics, and in particular, smartphone forensics, testing is no longer an optional skill, but rather one we all need to know how to use.
You might even say that testing is a subject of great “gravity” in our field.
In the past couple of posts, I’ve been talking about my favorite artifacts. As I showed in last month’s installment, in which I talked about smartphone user dictionary files, I went into detail about my first encounter with the artifact in question and showed how I came to discover that particular artifact.
The fact is, which artifact is “my favorite” is generally based on whatever casework I’m currently doing and what I need to find out. I could cover a thousand artifacts but never hit on the one artifact you want to know more about. But if you start to incorporate testing into your daily practice, that won’t matter because you’ll have the key to finding out for yourself and verifying what you find in your research. In other words, when you start testing, you’ll start building your own list of “My Favorite Artifacts.”
A Timely Example of My Favorite Artifact: MobileSMS.plist
Right now, I am working on a case in which I need to know how long various users had set their iPhones to keep their text messages. Over a dozen iPhones and backup files were submitted to us for analysis, all of different models and all running different versions of iOS.
This is not a common request. In fact, in over 20 years of doing digital forensics, this is the first time I’ve been asked to answer this particular question. Message retention is not a setting that forensic tools automatically parse for us, so actually answering this question would take more elbow grease and in-depth examination than many of the other questions we’re commonly tasked with answering.
All of this makes this scenario a perfect example to demonstrate the power of testing!
This Is Only a Test
Test phones are a “must have” for mobile forensics practitioners. Without test phones, there just isn’t a way to find answers to all of the various questions that might arise. After all, you don’t want to risk testing something on an indispensable piece of evidence, lest you end up inadvertently destroying something you need to have preserved.
I started at the beginning with some good old-fashioned research. I looked at a freshly-factory-reset iPhone to see what the options were for text message retention. There were three options: “Forever,” “1 Year,” and “30 Days.”
Then I checked my bookshelf. A search of the indexes of “Practical Mobile Forensics: Second Edition,” “iPhone Forensics,” “Learning iOS forensics,” and “OS Internals: Security and Insecurity” revealed no quick answers.
I next turned to the Internet where I dug up the 2016 BlackBag Tech blog post “Are the Messages Being Automatically Deleted?” This helpful write-up contained information about an artifact called MobileSMS.plist, but it didn’t answer the specific question I had. It did, however, lead me to the name of the artifact that stores, among other things, the user setting for how many days SMS messages should be kept before deletion–exactly what I was looking for.
I had plenty of test phones to experiment on, and now I knew which rabbit hole I needed to jump down. It was time to discover what would soon become one of my favorite forensics artifacts.
Now I had an idea of which specific artifact I needed to focus on in testing. The next step was to use the scientific method to figure out what would happen to the MobileSMS.plist file under various conditions.
As a refresher, the scientific method is a pretty simple six-step process. Here’s how I applied it to the MobileSMS.plist message retention question:
- Make an Observation: The file that holds information about how long the user wants messages to be kept is the MobileSMS.plist file.
- Form a Question: What changes happen to the MobileSMS.plist file when the user changes the retention setting?
- Form a Hypothesis: There will be at least one value in the MobileSMS.plist file (probably KeepMessageForDays mentioned in the BlackBag blog post) that changes when the user settings are changed.
- Conduct an Experiment: Use a freshly-reset test phone to check the default settings. Then change the settings to all of the various possible options. Image the phone in its default state, then image it after each change is made so that a comparison can be made of the MobileSMS.plist file in each state.
- Analyze the Data and Draw a Conclusion: Document what the changes were and nail that artifact down!
What I found out about the MobileSMS.plist artifact:
I started with a freshly-factory-reset test iPhone running iOS 11.1.2. (Remember that with any iOS version, artifact locations and behavior could potentially be different. Therefore, you might have to repeat testing for different versions.) I looked at the default setting for how long to keep messages and found that the default setting was “Forever.”
Below are screenshots showing how to navigate to the setting:
Instructions on how to find message retention settings on an iOS device
Without making any changes to the settings, I used Physical Analyzer to do an “Advanced Logical 1” extraction from the device. Here’s what the MobileSMS.plist file located at /mobile/Library/Preferences/com.apple.MobileSMS.plist looks like (kudos to Cellebrite for recently adding in a great .plist viewer to their tool!):
A closer look at MobileSMS.plist
There are some potentially interesting values there, but notice the conspicuous absence of the entry “KeepMessageForDays.” Interesting! If the default value for message retention has never been altered, apparently this entry isn’t present.
Change settings to Keep Messages for 30 Days:
I then changed the message retention setting to keep messages for “30 Days.”
The phone shows a notification indicating that this change will cause the deletion of messages older than 30 days. Good to know. I again used Physical Analyzer to do an “Advanced Logical 1” extraction from the device and looked at the MobileSMS.plist once more. Here’s what I found this time:
Observing the changes in MobileSMS.plist
After changing the setting from default, the KeepMessagesForDays value shows in the MobileSMS.plist file. And, there’s another new entry named KeepMessagesVersionID that appears with a value of 1. It’s a new artifact that led me to develop a pretty obvious new hypothesis. I posited that this value was related to me changing the default value for how long to keep messages one time. All of a sudden, I found myself testing more than one thing.
Change settings back to default:
Next, I changed the message retention setting back to the default setting, “Forever.”
This is because I wanted to know what the change would be in the KeepMessageForDays value, which didn’t previously exist when the phone was in its default state. Here’s what I found:
Observations of the way MobileSMS.plist changes as I alter its conditions continue
When the user resets the settings back to the default (Forever), the KeepMessageForDays value becomes 0. And notice that our KeepMessagesVersionID value ticks up to 2 with the second change of the setting.
Change settings to Keep Messages for 1 Year:
I next changed the settings on my test iPhone to keep messages for “1 year.”
Again, I got the deletion notification, telling me that this would permanently delete messages over a year old:
I did yet another “Advanced Logical 1” extraction from the device and looked at the MobileSMS.plist file yet again.
It’s beginning to feel like Groundhog Day, isn’t it? But here’s what I found this time:
Yet another round of testing MobileSMS.plist to learn of its secrets
When the retention setting is set to keep messages for one year, the KeepMessageForDays value becomes 365. And our KeepMessagesVersionID ticks up to 3 corresponding to the 3rd change of the setting.
So, in summary now we know:
Remember, It’s “Only A Test”
I opened this post talking about testing. Hopefully, you’ve seen that testing doesn’t have to be a complex and high-stress thing. With a test phone, a solid toolset, a little time, and a bit of research, we now know a whole lot more than we used to about the MobileSMS.plist file. The steps I walked through here are really all it takes to find and explore your favorite artifacts.
“I’ve got a great notion that force is a changer of motion. Let’s put it this way: f = ma
The rest is just sweat and devotion.” ~ Unknown