James Eichbaum is the founder of Elusive Data and has worked in digital forensics for many years as both a practitioner and an educator. His background includes extensive law enforcement casework involving mobile devices and application data. Prior to founding Elusive Data, James served as Global Training Manager at MSAB, where he developed and delivered advanced training in mobile and application forensics.
James, you’ve worked in digital forensics for many years, both as a practitioner and as an educator. What first drew you to the challenges of SQLite analysis?
My first real challenge with SQLite actually goes back to 2011, during a murder and arson investigation where I was tasked with recovering deleted SMS messages from an iPhone 3GS. At the time, there were no forensic tools that exposed that data. It was a practical investigative problem that needed to be solved.
The data I needed wasn’t visible in any tool. Thousands of deleted messages were sitting inside the sms.db database, but they had to be recovered manually. I ended up having to understand the database structure well enough to locate, parse, and reconstruct those deleted records myself in order to support the investigation and prosecution.
That experience stuck with me.
As time went on, I kept encountering similar situations. New and popular applications would appear before forensic tools supported them, or tool support would break after an app update. In those moments, there was no option but to go back to manual analysis.
Just as importantly, I also found situations where tool output didn’t quite match what was actually stored in the database, which made validation critical.
Those experiences shaped how I approached SQLite going forward — first as an examiner, and later as a trainer. As I began teaching examiners around the world, it became clear that this wasn’t an edge case. Understanding how SQLite databases manage data, how records change over time, how the write-ahead log works, and how content is increasingly stored inside BLOBs — including formats like Protocol Buffers — had become essential knowledge.
No matter how good our tools are, they can’t possibly keep pace with the sheer number of applications on the smartphone market. At some point, examiners need a fundamental understanding of how SQLite works so they can adapt, validate results, and explain their findings with confidence.
Many examiners will recognize that feeling of opening an app database and not knowing where to start. What do you see as the main challenge today?
The databases themselves have become incredibly complex. Take something like WhatsApp or the iOS Health app — you’re often dealing with hundreds of tables and dozens of relationships. Simply opening the database can feel overwhelming.
But the real challenge isn’t just the number of tables or columns — it’s what’s inside them.
You may encounter tables with dozens of columns, many of which store BLOB data. Those BLOBs could contain almost anything: binary plists, embedded images, gzipped Protocol Buffers, or other proprietary binary formats. To make sense of that data, examiners often end up exporting the BLOB and the plist inside it, and then finally extracting a JPEG or decoding a message structure.
That process quickly becomes fragmented. Investigators jump between tools, export data repeatedly, or — in some cases — make assumptions just to piece together what actually happened.
At that point, the problem isn’t technical capability — it’s comprehension. Understanding how all of these pieces relate to one another, and what they actually represent in the context of user activity, is where most examiners struggle today.
How important is visualization when trying to build that understanding?
It’s critical. And that became very clear to me through teaching. When I was explaining how SQLite works — how records are stored, how pages change, how the write-ahead log functions — I initially tried to do it the same way most of us were taught: slides, diagrams, and a lot of explanation. But it didn’t really click.
What made the difference was when I started drawing it out on a whiteboard. When students could see how pages were written, how frames were added to the WAL, and how changes accumulated over time, that’s when the “aha” moment happened. They weren’t memorizing concepts anymore — they were understanding behavior.
That experience fundamentally changed how I approached SQLite analysis going forward. Visualizing the schema, seeing tables as free-floating objects, understanding relationships at a glance, and being able to represent the WAL as a sequence of frames with an accompanying shared-memory index made the database feel intuitive rather than abstract.
SQLite Visualizer started as a way to capture that whiteboard moment digitally — a visual canvas for understanding how SQLite databases are structured and how they evolve over time. The WAL analysis component, in particular, was something I genuinely enjoyed building, because it allowed me to represent frames, pages, and state changes in a way that mirrors how SQLite actually behaves internally. The goal was never to hide complexity, but to make it visible — and therefore understandable.
You’ve recently demonstrated analysis of application data stored inside BLOBs, including fragmented JSON content. Is that becoming more common?
I would hesitate to call it common, but it is certainly a scenario examiners need to be prepared for.
Traditionally, when we think about BLOBs in SQLite databases, we think about things like images, binary plists, or serialized formats such as Protocol Buffers. What that recent example highlighted is that BLOBs don’t have to be purely binary — they can also contain structured text data, such as JSON, and that JSON may not exist neatly in a single record.
In the case I demonstrated, the content was stored as JSON using Markdown formatting, and portions of that JSON were spread across multiple records. From an examiner’s perspective, that creates a different challenge. You’re no longer just exporting a BLOB and decoding it — you may need to identify related fragments, reconstruct the data in the correct order, and only then interpret the content.
It’s a good reminder that with application databases, you rarely know what you’re going to encounter. BLOBs, in particular, can be unpredictable — they might contain images, plists, compressed data, or structured text split across records. In that sense, they really are like a box of chocolates: you don’t know what you’re going to get until you open them.
The important takeaway for examiners is not the specific format, but the mindset. You need to be ready to recognize what you’re looking at, adapt your approach, and validate what the application is actually storing — rather than assuming BLOBs all behave the same way.
Where does low-level analysis, such as hex examination, fit into this type of work?
Hex analysis is absolutely essential — but only when it’s done with context.
Most common hex viewers are designed to be generic. They’re built to open any binary file, which is useful, but they don’t understand SQLite. When you’re working with structured data, that lack of awareness becomes a limitation rather than a benefit.
What I found myself needing was a hex view that understood SQLite natively: page navigation, WAL frame navigation, the ability to right-click a pointer and jump directly to the referenced location, and immediate interpretation of things like varints, serial types, cell sizes, and record headers. I didn’t want to stop analysis to open a calculator, convert offsets, or manually decode values — I wanted the structure to be visible while I was examining the bytes.
When a hex view recognizes SQLite pages, records, freelists, and freeblocks, it stops being intimidating and becomes a powerful validation and recovery tool. It allows an examiner to confirm exactly what is stored on disk, reconstruct deleted records, and clearly explain what they are seeing.
That ability to validate is critical. We shouldn’t blindly trust what a forensic tool reports — just as I wouldn’t have trusted a radar gun without first checking it with a tuning fork. Hex examination gives you that ground truth. It’s what lets you say, with confidence, this is what the database actually contains, and this is how I know.
When hex analysis is purpose-built and structure-aware, it’s no longer something to avoid. It becomes one of the most valuable parts of SQLite analysis — and, frankly, one of the most satisfying.
Who do you see benefiting most from this approach to SQLite analysis?
Anyone who works with application data and needs to truly understand what they’re looking at — not just extract it.
That certainly includes law enforcement and private forensic laboratories, but it also applies to corporate investigators and educators. The common thread isn’t the role, it’s the requirement to explain findings clearly and defend how those findings were reached.
This approach becomes especially important when tools don’t decode an application as expected, or when results need to be validated. In those situations, examiners can’t rely on automation alone — they need to understand how the data is structured, where it came from, and what it actually represents.
Ultimately, this is about confidence. Confidence in the analysis, confidence in the results, and confidence when those results are questioned — whether that’s in a report review, during peer discussion, or in court. Knowing why the data looks the way it does makes all the difference.
Finally, what do you hope practitioners take away from this work?
That SQLite databases don’t need to be intimidating — but they do need to be understood.
When examiners take the time to learn how SQLite stores data, how records change over time, and where information can persist after deletion, analysis becomes far more than just extracting results. It becomes faster, clearer, and much easier to defend.
My hope is that practitioners walk away with confidence — not just in what their tools report, but in their own ability to validate those results and explain them clearly. Whether that explanation is in a report, during peer review, or in court, understanding the underlying structures makes all the difference.
At the end of the day, this work isn’t about memorizing formats or chasing every new application. It’s about developing a way of thinking that allows examiners to adapt, troubleshoot, and trust what they’re seeing — and to explain why they trust it.
To learn more about Elusive Data’s work, visit their website.
