rea-reverse

Inspect a SQLite Database Snapshot with REA

Written for REA 6.8.0Published by rea-reverseUpdated 3 min read
On this page

You have a SQLite file and need to know what it contains before handing it to an analyst or an agent. Start with a consistent snapshot, inspect its schema, and only then select a small set of columns. REA’s inspect-sqlite-database can do those steps without opening the source database in SQLite or running SQL supplied by the user.

This guide tests REA 6.8.0 with Node’s SQLite 3.54.0 on macOS. The sample contains invented device names, not production data. The package was invoked with Node 26.12.1; the observations below apply to that test, not to every REA release.

REA 6.8.0 requires Node 22.23.4 or later within the 22.x series, Node 24.22.1 or later within 24.x, or Node 26.12.1 or later. Check node --version before installing it.

Inspect a SQLite snapshot with REASilent walkthrough with English captions.

1. Make a snapshot and identify it

For an active database, use the application’s own backup procedure or SQLite’s backup API. Copying just the main file while writers are active can miss committed changes in the WAL; copying a database and its WAL separately also does not establish an atomic snapshot. Stop here if you cannot obtain a consistent copy.

For this demonstration we created a closed, standalone database:

sqlite3 inventory.sqlite <<'SQL'
CREATE TABLE devices (id INTEGER PRIMARY KEY, name TEXT NOT NULL, status TEXT);
INSERT INTO devices VALUES (1,'sensor-a','active'),(2,'sensor-b','offline'),(3,'sensor-c','active');
CREATE INDEX idx_devices_status ON devices(status);
CREATE VIEW active_devices AS SELECT id,name FROM devices WHERE status='active';
SQL
shasum -a 256 inventory.sqlite

Our file was 12,288 bytes, with SHA-256 82f820488f97f10ea4b3ecc343deb870c87de301cda30c004f7dc27fd7137ecc. Your hash can differ: SQLite version and creation details affect the bytes. Record the hash of your snapshot so the next person can identify the same input.

2. Inventory the schema

With REA 6.8.0 installed, run:

rea inspect-sqlite-database inventory.sqlite --format json

In our result, normalized_result.schema had scope inventory and completeness complete. It listed the ordinary table devices with three columns, the index idx_devices_status, and the view active_devices. The inventory gave columns_completeness: not_requested; it did not list individual column definitions. That distinction keeps a compact inventory from looking like a detailed schema.

For a cross-check, sqlite3 inventory.sqlite '.schema' showed the three CREATE statements above. We used it on our disposable sample, not as a recommendation to open an unknown live production file.

3. Select a table and sample rows

rea inspect-sqlite-database inventory.sqlite \
  --table devices --column name --column status --row-limit 2 --format json

The selected-table result included the three column definitions and these two rows, shortened here to their text values:

sensor-a  active
sensor-b  offline
returned_rows: 2
truncated: true
order: unspecified

There were three rows in the sample, so truncated: true matters. The observed two rows are not a promise about which rows a future call will return: the result explicitly says the order is unspecified. The JSON preserves each selected value’s type and, for text, its byte representation and encoding. Do not treat the display string as a page-offset-level forensic record.

Repeat --column in the order you need. A column selection without --table failed with columns requires an explicit table selection. Selecting active_devices as the table also failed: it is a view, while row sampling requires an exact ordinary-table name. The schema can list views without executing them.

4. Check the boundaries

The result includes the input SHA-256, provider version, an evidence ID and a limitations list. In this test, the source file’s SHA-256 stayed the same after inspection. REA states that it reads a private copy, but a check on one sample is not proof that every live database can be acquired consistently.

REA reads the valid database and WAL state available to its snapshot. It does not recover deleted records, include uncommitted or invalid WAL tails, decrypt an encrypted database, or perform a full integrity check. Views, triggers and virtual/shadow table rows are not executed. If you need a complete, ordered query or an integrity investigation, use the appropriate SQLite workflow on a controlled copy.

Next steps