January 1, 2026
“It’s (Not) Just A Text Message!”
"The aspects of things that are most important for us are hidden because of their simplicity and familiarity.”
-Ludwig Wittgenstein
Author’s Note: This article deals with a recently adjudicated case. The names and titles of the persons involved have been changed for discretion.
Text Messages: The Forensic Landscape
Of all the digital forensic bits and bytes we deal with on a routine basis, text messages top the list, surpassing even emails or documents. To be clear, all of us deal with a large amount of all three (as well as photos/videos), but the ubiquity of mobile devices, their consistent use in business and personal applications, the ease of text message communication and the cross-over between digital forensics and e-discovery involvement with text messages in particular make texts a huge part of what we deal with daily.
One issue that is common, albeit nuanced is, what is a “text message”? We use the term universally to describe iMessage, SMS, RCS, WhatsApp, Snapchat, Signal, etc., but in the collection phase, we may have to treat these very differently. As I’ve referenced in previous posts, it’s almost always a good idea to get a full file system collection for these artifacts, if for no other reason than “better safe than sorry”. It’s also evolved as the industry standard. But when talking to clients, it’s important to make the distinction, because some are cost-conscious, while others simply aren’t interested in getting anything other than their client’s (or opposing party’s) non-deleted text messages.
Another common question we face is “why does it cost so much to get text messages?” First, refer to the previous paragraph. Second, when conducting a full file system collection, the tools to do so are vastly more expensive, meaning the costs for clients to get that data is more expensive. That’s just a truism of business, and even though the government doesn’t necessarily have to worry about cost-benefit in every matter, it’s still part of the calculus. It’s interesting when I talk to clients about collecting text messages, they often don’t understand the nuances that go into the data behind a text message. They just see a text message, and maybe a date and time, so what’s the big deal?
One recent high-profile criminal case highlighted what the “big deal” is...
Troy’s Text Messages
Submitted for your approval: Troy is a relatively high-profile elected official. Through the course of seeking and voting for a particular political office, he allegedly may have voted in more than one and/or the incorrect jurisdiction, leading to multiple counts of felony election fraud. Troy was informed that his voting status was settled prior to the election by the general overseer of the election paperwork, the Registrar of the town in which he was voting. Being that Troy was well-known to the town officials and friendly with them, the Registrar sent him a text message with a picture of his new voter registration stating he was good to go on voting in their jurisdiction in the upcoming election. The accusations against Troy are that this was not the case, but Troy’s “smoking gun” was the text message from the Registrar telling him it was OK.
The Registrar produced text messages in the form of screen shots (more on that later) to support the claim that they never told Troy he could vote in that jurisdiction. The text message of utmost importance was also produced with a likely crucial bit of the message cut off the bottom of the screen shot and not included on the ensuing screen shot. It became a bit of a text message duel. So who was correct?
My role was to determine several important things. First, to collect the text messages from Troy’s devices in an appropriate and forensically sound manner. The second was to confirm the existence of the complete text message, which could help serve to exonerate Troy. Third was to conduct deeper analysis of the text message exchange to ensure nothing had been fabricated, altered, etc. It’s always a challenge to prove a negative in our field. Proving that something didn’t happen is not as simple as proving something did happen in the vast majority of circumstances.
There were complicating factors. Troy didn’t want to give up his iPhone for collection. Troy is also a registered Apple developer, which means he *could* theoretically be technically savvy enough to alter messages. It also meant he had beta versions of iOS on his device, which was not supported for full file system collection by Verakey. We also are forbidden to use Cellebrite Premium for collection in this case because it is a criminal defense matter.
The Analysis
There were only four primary messages at issue here. One was a picture message and the others were the brief text exchange immediately following that. They were both received by Troy’s i-Devices (synced across all devices). There were two brief replies from Troy, but nothing further on that date. Locating the logical existence of the messages was simple. We’ve all done it a thousand times. This alone proved that the screen shot produced by the Registrar may have been incomplete, and there was additional text in the message the followed Troy’s replies that could significantly help his claim of innocence in the case.
Proving that the messages were not fabricated or altered is another problem entirely. It’s certainly not infrequent that we have to dive into the various databases of the device to assist, augment or validate what our tools are telling us. That said, even the bird’s eye view of the database only tells us so much, and this one was a bit of a puzzle, because these messages didn’t initially appear in the database. This is a snapshot of how we normally view things in the SMS database:
Most of the time, we’re interested in date/time, rowID and content. Sure, there are other columns with potentially other probative data, but in the vast majority of cases, this is what we inspect, and this is what we expect our tools are pulling from to present in the conversation view.
Unfortunately, the entries for the relevant time in this case were blank – there was no content. Yet, Cellebrite was still pulling content into the conversation view but from where? And how did that content get to a different location in the database? Could this be a limitation of the type of collection (advanced logical)? Perhaps. But a full file system would still only pull the same database. However, Cellebrite was still reporting that the messages were present in the conversation view, so where were they if not in the database? And does this prove any manipulation or fabrication of the messages? More questions to answer.
Here are the relevant messages in conversation view:
The last message – “No Hurry… Congratulations [emojis] You’re Official!” was the proverbial smoking gun in this case. It also was nowhere to be found in the text column of the database. The other messages were found in the SMS.db. So where was the last message?
As often happens in digital forensics, the concentration of our work boils down to one or two pinpoint pieces of data. Email headers, dates, times, log files, etc. all generally get distilled down to no more than a few points that need to be analyzed and validated as much as possible. In this case, one text message.
Further inspection into the hex of the database revealed that this message does indeed exist, so at least Cellebrite wasn’t hallucinating . But in order to determine to our best ability whether or not it was fabricated or altered, we had to find out as much as we could about it. This led to the “attributed body” column, which when rendered as “human readable” isn’t anything of substance at all in the database view. But when the data in the column is converted to hex and subsequently ASCII, the body of the above message at the appropriate date and time:
With the message located in the appropriate place in the table with the correlating metadata, we can now get as close as possible to the conclusion that there is no evidence that the message was fabricated or manipulated by the user. Does that mean it’s impossible? No. But there’s no evidence on this device to conclude that it was.
It’s further interesting to note the limitations of the analysis tool here. It is normally simple to search the database for the text message, right? Even with a database with over 570,000 messages. But searching the table in this instance returned nothing, because the data isn’t in the table.
The Salient Points
There are a few obvious-(?), yet very important take-aways from this case:
1. Screen shots are horrible evidence. They lack critical metadata, they are unverifiable, they are very easy to fabricate and they almost never tell the entire story. I wrote about this several years ago in this article, but nothing has changed. In fact, it’s only gotten worse. If I had one DF/IR wish to wish for all involved in the handling of text messages as evidence, it would be to NEVER use screen shots as evidence. Period. Yes, I understand many courts accept it. I also understand that forensic collection, analysis and production of the messages can be costly. Regardless, screen shots are awful as evidence. And this case is one of many that helps demonstrate why.
Side note: Why no one (i.e., law enforcement) previously chose to collect these messages from either party in this case if they were to be used as evidence is perplexing. This case dealt with four felony charges and it was regionally high-profile and political in nature. The verdict made some national media outlets.
2. I think all of us who deal with mobile device evidence would agree that getting ahold of the data ASAP and in the most complete manner is paramount to success. That said, we are bound by the current limitations of our tools. Due to installation and use of a developer beta version of iOS in this case, a full file system wasn’t available, so an advanced logical collection had to be done. It wasn’t ideal, but it got what we needed (in this case).
3. This case dealt with a total of 4 relevant messages – a received picture message and another text (iMessage) immediately following, with one immediate reply from Troy’s iPhone. That’s all. And even distilling down the “smoking gun” in the case, that was a solitary message. If we can spend hours trying to confirm or refute the existence and validity of this message, imagine what happens in cases where only screen shots are produced and none of this work is conducted.
4. The time spent on this case was primarily to confirm the messages existence and shore up the argument that there was no evidence of manipulation or fabrication of the text messages. It was discovered that it is not simple (read: not impossible) to edit a received iMessage. The nuanced conclusion came that there was no evidence of fabrication, not that it was impossible to fabricate.
The ultimate outcome of this case was not ideal for Troy, but it was not due to lack of effort on our part.
Clients often want absolutes when it comes to digital evidence. There was a time when and analyst could get by saying, “the evidence speaks for itself”, and in *some* circumstances, this is still true. The more complex the data becomes and the more nuanced the circumstances, the less you can conclude with absolute certainty that something did or did not happen.
And just when you think you have done everything possible to come to that absolute conclusion, the evidence – or the circumstances – throw a curve ball.
About the Author:
Patrick Siewert served 15 years in full-time law enforcement and investigated hundreds of high-tech crimes to precedent-setting results, Patrick is a graduate of SCERS & BCERT and is a court-certified expert witness in digital forensics, mobile forensics and historical cell site location analysis. He has published dozens of articles and is cited in numerous academic papers. He was the Founder & Principal Consultant of Pro Digital Forensic Consulting, based in Richmond, Virginia (USA) and currently serves as Director of Digital Forensics and E-Discovery for a Nationwide (US) provider of DF/IR and e-disco litigation support services, while keeping in touch with the public safety community as a Law Enforcement Instructor in multiple disciplines.
Email: Patrick@ProDigital4n6.com
Patrick Siewert on LinkedIn: https://www.linkedin.com/in/patrick-siewert-92513445/
Patrick Siewert on X/Twitter : @RVA4n6
Pro Digital (old) blog site : https://prodigital4n6.blogspot.com/