db-wal

The Easiest way to look at it is in a hex viewer.

Chris Weber

The Easiest way to look at it is in a hex viewer.

Chris Weber

You could "Look" at a WAL file this way but making sense of it would be fun )

More info on the structure of a wal file (and a suggestion on how to deal with the data within) here

http//sandersonforensics.com/forum/content.php?197-Forensic-examination-of-SQLite-Write-Ahead-Log-%28WAL%29-files

I've read your papers on WAL files and Sqlite.db and I'm very impressed by them. You are right a hex viewer it is not the easiest, but it is free. The first thing that popped into my head was the mmssms.db-wal which I usually use a hex viewer to quickly go through and carve important messages out of if I need to. But for other wal files it would not be the right tool for.

Im pretty sure that if you have the sqlite database the wal file relates to (i.e. if you have database.db and database.db-wal) you can open the main database and the records in the wal file get written into the main database. You can do this with almost any sqlite viewer, i use sqlite spy.

This can cause deletions in the main database, but if you extracted it form a forensic image of UFED/XRY dump you could always re-extract a copy of just the database and open that in a viewer so you can compare any differences.

Hi minime

You are of course correct in stating that if you open a DB for whcih a WAL file is present then the relevant WAL content will be written to the DB.

One issue that you correctly mention is that the corresponding records are written back to the database and the records that previously existed in the DB are lost. This of course works at a page level and not a record level - the end result is the same though.

This method has a number of drawbacks that mean that you will quite probably miss evidence.

As you rightly state any records that currently exist in the DB that are modified/deleted by the content of the WAL file will be lost, although you can get at these by deleting/renaming the WAL before you open the DB and doing a table by table and record by record comparison with a DB that you have allowed the WAL to update.

But there are more subtle and possibly more important issues.

When a WAL file is written a number of changed pages from a DB are written to the WAL and at various points in time (not important for this discussion) the WAL is "played" and the content written to the main database and the process starts again.

The first problem, from a forensic view point, is that multiple copies of the same page can, and do, appear in the WAL. So each time a page in the DB is modified a new copy is appended after the last valid record. Opening the WAL as you suggest will just get the last of these pages and any records in the previous instance of the page from earlier in the WAL will be lost.

The second issue is that when a WAL is played the old content of teh WAL is not deleted, the WAL header is just updated and on a subsequent database write the first changed page is written at the start of the WAL file and each new page appended after the previous. What this means in practice is that the current WAL normally partially overwrites one or more previous WALs. Opening the main database and allowing the WAL to be replayed will *never* get these old pages from previous WALs back.

It is for the reasons above that I suggest the route used in the article referred to earlier.

Similar issues exist with SQLite journal files. Both WALs and journals are discussed in these articles along with a method of bypassing the issues I raise.

http//sandersonforensics.com/forum/content.php?197-Forensic-examination-of-SQLite-Write-Ahead-Log-%28WAL%29-files

http//sandersonforensics.com/forum/content.php?208-Dealing-with-records-found-in-SQLite-Rollback-Journals

Paul,

While there is a chance that records may be missed, mostly for the reasons you stated, in a lot of cases simply viewing with an Sqlite browser will get you what you need.

For instance, a lot of the times I end up digging through these databases is when I end up with keyword hits in the database or the WAL/journal file. So in these cases if exporting the WAL/journal file and opening the database shows me the record with the keyword hit in then all is good.

It may not always be enough, but it is a good starting point.

if your case is such that you can search for a particular keyword and ignore the records around it then that's absolutely fine.

We all have our own methods that may vary from case to case but it is important that we understand the limitations of them and when we need to go further.

Paul thanks! Amazing paper!
Also thanks all.
I am studiing all the db of contact. I suspect that lot of numbers are lost, only the name and surname.
thanks

I have one question in this topic … so
if there are no deleted data in mmssms.db-wal then why mmssms.db has 4kb and mmssms.db-wal size is 1 119kb ?
Is there realy nothing interesting ?