Modern applications rarely keep evidence in one simple place. A single app may use SQLite for structured records, RealmDB for object data, LevelDB for key-value storage, IndexedDB for browser-based state, and additional files for caches, media, configuration, timestamps or synchronization.
For investigators, this changes the work that happens after extraction. A parsed view can be a useful starting point, but the examiner may still need to understand where a finding came from, how it was stored and whether the interpretation can be checked against the source.
That is the wider app-data problem. The evidence is often there, but it may be distributed across several storage formats and supporting files. A source-backed workflow helps investigators move from decoded output to a clearer understanding of what the data means.
SQLite remains a foundation for app-data investigations
SQLite remains one of the most important storage formats in digital forensics because it is embedded directly into so many applications and platforms. It can hold messages, timestamps, contact data, settings, media references, location records, application state and many other forms of user activity.
In forensic work, SQLite knowledge is valuable because relevant evidence may appear in more than the visible table view. A finding can be supported by the main database, WAL frames, freelist pages, freeblocks, overflow pages, BLOBs, raw database pages or byte offsets.
This is why SQLite is often the starting point for deeper app-data work. Understanding SQLite helps investigators move from decoded output to source-level validation: where the value came from, how it was recovered and what the underlying structure supports.
RealmDB changes the shape of the evidence
RealmDB is used by some modern applications because it gives developers a mobile-focused, object-oriented way to store data. From an examiner’s point of view, that can feel different from working with traditional relational tables.
Instead of thinking only in rows and columns, the investigator may need to understand objects, properties, relationships, internal identifiers and application-specific structures. The important question remains the same: what does the stored data represent, and how does it connect to user activity?
RealmDB analysis can therefore benefit from the same forensic habit used in SQLite work: keep the interpreted value connected to the source structure that supports it.
LevelDB and IndexedDB often appear in browser-based and cloud-connected workflows
LevelDB is a key-value store. IndexedDB is a browser-side database API for structured client-side data. Both can appear in investigations involving browsers, web applications, Electron-style desktop apps, sync workflows and cloud-connected user activity.
These stores may contain local state, cached objects, identifiers, queue data, user activity, application settings or sync-related information. What matters is context. A key-value pair or stored object may be useful on its own, but it becomes stronger when the examiner can explain how it fits into the application’s workflow.
This is where app-data forensics becomes broader than simply opening a database. Different storage formats require different ways of navigating, validating and explaining the data.
A parser view is only part of the investigation
Forensic tools are essential. They help examiners move quickly through large datasets and surface artifacts that would be difficult to find manually. But modern apps change often, and no parser can cover every application, schema change, storage format or deleted structure immediately.
When an app is unsupported, partially parsed or updated in a way that changes the storage model, investigators may need to look below the decoded view. They may need to ask where the value was stored, whether the source supports the interpretation and whether another reading is possible.
Common reasons to look beyond the parsed view
- Apps can change faster than parser support.
- Unsupported apps may still contain important evidence.
- Different storage formats need different validation methods.
- Deleted or historical data may sit outside the normal parsed view.
- A finding is stronger when it remains connected to its source.
Provenance keeps the finding connected to the source
Provenance is the connection between a forensic finding and the source artifacts that support it. In practical terms, it helps answer questions such as: which file produced this result, which structure contained it, how was it interpreted and can the examiner check it against the source?
In SQLite, provenance may point to a database page, record, WAL frame, freelist page, freeblock, overflow page or byte offset. In RealmDB, LevelDB or IndexedDB, the path may look different, but the principle is the same: the interpretation is easier to trust when the source context is preserved.
This is useful for reporting, peer review and quality assurance. It also helps when different tools show different results, or when a finding is important enough that the examiner needs to explain how it was reached.
Where Elusive Data Firefly fits
Ontwijkende Datasprinkhaan is a forensic workspace for app-data investigations. It is built around the idea that the interesting work often begins after extraction: recovering what remains, interpreting it in context, validating findings against the source and carrying that context into reporting.
The goal is not to replace the extraction tools investigators already rely on. Extraction platforms do important work. Firefly supports the work that often follows: understanding modern app-data stores, keeping findings connected to their source artifacts and making it easier to explain what the data means.
Firefly takes the source-backed approach beyond SQLite and into broader app-data formats such as RealmDB, LevelDB, IndexedDB and Apple Biome / SEGB. The common thread is provenance: faster work, clearer interpretation and a path back to the source when a finding needs to be reviewed.
Questions that help guide app-data review
When working with modern app data, a few practical questions can help keep the investigation grounded. They are simple questions, but they help connect the decoded result to the source context behind it.
- Which file or store produced this finding?
- Is the value current, historical, cached, deleted or reconstructed?
- Which structure supports the interpretation?
- Can the source be checked directly?
- Does the report preserve enough context for review?
Those questions help investigators move from decoded data to source-backed findings that can be explained with confidence.
Continue reading
For more on the thinking behind the workspace, read the idea behind Elusive Data Firefly or visit the Elusive Data Firefly page.
If you want to build a stronger foundation in SQLite analysis, see the SQLite Forensics Training or the SQLite Forensics On-Demand course.
