You haven't said what operating system you are using but I strongly suspect that there will be plenty of pages from your database thrown around by the OS itself in various caches/pagefiles etc. all of course outside of the ability of SQLite to prevent.
Getting at these cached pages is not difficult (and I write software to do this) but it does require low level access to the device (my clients would normally have an image of the system). Given the DB schema it is relatively straight forward to search for and "carve" these pages and put the recovered records into a new blank database. This might be a level of access you are not concerned with - I guess that all depends on how sensitive sensitive is :) Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786 http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit -Forensic Toolkit for SQLite email from a work address for a fully functional demo licence On 22 April 2015 at 13:50, Simon Slavin <slavins at bigfraud.org> wrote: > Dear folks, > > I have a setup where an app creates a single-user SQLite database by opening > a connection, uses it for a number of complicated things, closes the > connection, then deletes the database before quitting. The data which goes > into this database is highly sensitive and it's very important that my app > deletes all files which might contain this data (journal, temp index, etc.) > before my application quits. > > For the purposes of this question, you can assume SQLite version 3.8.0 or > later, that my app never crashes (because I am JUST THAT GOOD), and that if a > file is deleted using remove()/unlink() the disk space it was in is not > recoverable, e.g. it is immediately overwritten with random bits and other > anti-forensic stuff. You can also assume that if a fault is caused by a bug > in the operating system, or by malfunctioning hardware, or by the user > resetting the hardware while my app is running, that's not my problem. > > I used to solve this problem by creating a special folder to contain the > database. After the connection to the database was severed it would delete > the folder. This worked perfectly. Unfortunately an update to the > underlying operating system means that my app is allocated one folder to work > in and cannot create subfolders. The good parts of this change are that no > other app can access files stored in that folder, and that the 'temp folder' > is a subfolder of this folder. > > So my procedure has changed to this: > > 1) Set the journal mode to DELETE > 2) Do a SELECT command because sometimes this forces (1) to happen. > 3) Close the database connection, checking the value returned > 4) Delete the database file > 5) Generate an error if database file still exists > 6) Quit > > The operating system guarantees that if an app quits or crashes, all its file > handles are closed and all pending deletes for those files happen. > > Assuming no hardware/OS faults is it possible for any other SQLite-created > files to still exist ? Journal ? Temp index ? Shared memory ? Anything ? > > I have read <https://www.sqlite.org/tempfiles.html>. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
