±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35894
New Yesterday: 0 Visitors: 134

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

SQLite Write Ahead Log (WAL)

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
 
  

AlexC
Senior Member
 

SQLite Write Ahead Log (WAL)

Post Posted: May 04, 12 15:19

If you've dealt with any SQLite data, whether on a desktop or a mobile device recently, you may well have seen "-wal" files alongside the main database file. This is because of a journalling mechanism called "Write Ahead Log".

This mechanism affords us some new opportunities but also some potential pitfalls. I've written up my research as a blog here: digitalinvestigation.w...ahead-log/

Hope that's useful.  
 
  

mykulh
Member
 

Re: SQLite Write Ahead Log (WAL)

Post Posted: May 04, 12 22:32

Excellent work Alex, very interesting.
Just wondering though, if the database and the WAL files were separated (for example if only the db had been extracted from an image) without a checkpoint being reached would the database fail to open or revert to the original and now out of date data?

Best regards
Mike  
 
  

AlexC
Senior Member
 

Re: SQLite Write Ahead Log (WAL)

Post Posted: May 05, 12 03:51

Glad you enjoyed it, I mention that situation towards the end:

One behaviour which hasn’t been described in full so far is that a database file in WAL mode isolated from its associated “-wal” file is, in almost all circumstances, a valid database in its own right. For example, consider the test database above as it is at the end of Step 8. If the database file was moved to another directory, as far as the SQLite database engine is concerned this is a complete database file. If this isolated database file was queried, the data returned will be that which was present at the last checkpoint (in our test case, this would be the 3 live records present at the checkpoint performed in step 7).

This raises an important consideration when working with a SQLite database contained in a disk image or other container (eg. a TAR archive): if the database file is extracted from the image or container without its associated WAL files, the data can be out-of-date or incomplete. The other side of the coin is that the “full up-to-date” version of the data (viewed with the WAL present) may lack records present in the isolated database file because of deletions pending a checkpoint. There is, then, an argument for examining databases both ways: complete with WAL files and isolated as it may be possible to obtain deleted records “for free”.


So to answer the question - it should open but it'd behave as it was at the last checkpoint.  
 
  

mykulh
Member
 

Re: SQLite Write Ahead Log (WAL)

Post Posted: May 16, 12 18:05

Sorry Alex, must read and re-read before posting my random thoughts Smile

So I guess if you have a WAL file it might make sense to view the db with and without it to see what data is altered, added or removed.

Cheers
Mike  
 
  

AlexC
Senior Member
 

Re: SQLite Write Ahead Log (WAL)

Post Posted: May 16, 12 20:50

Exactly - if there have been deletions in the database (which are then represented as alterations in the WAL) viewing without the "-wal" file present might get you some deleted data "for free". It's just important to understand why that is, in case it doesn't tally with what you see if you view the data on, for example, a mobile phone or in a virtual environment.  
 

Page 1 of 1