

Our example below shows our WAL file after a checkpoint has occurred and then three new pages have been updated – pages 5, 7 and 2. SQLite determines what is current by means of the salt value and to do this it ensures that the salt value changes for each checkpoint. When a checkpoint occurs then the WAL file is not deleted, rather the next set of pages are written from the start of the WAL file. At this point, each page will be written back to the main database in order so only the last version of page 7 in our example would be seen by an investigator using SQLite to write a WAL file.

So a WAL file can contain multiple differing copies of a page.Ī checkpoint occurs when the WAL files reach 1000 pages (this is configurable in SQLite) or when the programmer forces one. So if pages 3, 7, 9, 32, 4 are updated (in that order) and the salt is 1234 then the WAL file will look as follows. SQLite writes a value known as a Salt to the WAL file header, this salt is also written to each frame header for each page in the WAL file (the page header and page data itself are known as a frame). SQLite will see the existing WAL file in the same folder as the main database and will assume that an error has occurred (application/computer crash) and will automatically checkpoint the WAL file and add the changes to the main database. So to incorporate a WAL file just open the main db in SQLite. So from a forensic viewpoint, the existing database is an older version of the data and when the WAL is checkpointed you see the current version. WAL files are a form of cache whereby data that is written to an SQLite db is first written to the WAL file (when this is enabled) and then at a later time (known as a checkpoint) the SQLite data is written into the main database.

At a very basic level, WAL files are easy enough to incorporate into a parent SQLite database – you just need to open the parent database in SQLite. In order to maintain database integrity, SQLite often makes use of WAL files. I will go into a little detail regarding the format and usage of a WAL file, some of the forensic implications of recovering data and present two methods for recovering the data without missing or overwriting existing records.
#Db browser for sqlite write changes how to#
This article describes how WAL files work and how to deal with them forensically – the steps are very straight forward with the Forensic Toolkit for SQLite and the article takes you through them. So by opening the database and committing the WAL you are potentially overwriting/missing valuable evidence. records from a previous database transaction if you like records from previous WAL files. You may not be aware though that the WAL can contain multiple copies of the same page (each with different data/records) and that there can also be a sort of WAL “slack” i.e. I am sure that you are aware that when an SQLite database is opened if there is an associated WAL file then the pages in this WAL are automatically written to the main database, thus overwriting records, and the WAL file is reset.
