On Wed, Apr 22, 2015 at 8:14 AM, Simon Slavin <slavins at bigfraud.org> wrote:

>
> On 22 Apr 2015, at 2:07pm, Paul Sanderson <sandersonforensics at gmail.com>
> wrote:
>
> > You haven't said what operating system you are using
>
> Sorry, but I can't.  However, the OS is strongly oriented towards security
> paranoia.  As long as the proper OS calls are used to delete files and
> release memory, you can assume that they are unrecoverable, with all the
> stuff a forensic expert would hate.  The same is true of any caching done
> at OS level or below (e.g. device drivers, storage which automatically
> manages sector usage, etc.).
>
> > This might be a level of access you are not concerned with - I guess
> > that all depends on how sensitive sensitive is :)
>
> You got it.  But the platform (OS and hardware) is specially designed for
> this.  As you suspected I'm concerned only at the level of filespace which
> is still in use.
>
> Simon.
>

?Well, it is difficult, if not completely impossible to say without knowing
the OS involved. But since you indicated "strongly oriented towards
security paranoia", I am certain that it cannot be from Microsoft. If it is
a POSIX compliant, perhaps what you could do is create a "temporary"
(mktemp) file of "appropriate" size. Now create an encrypted filesystem
into that file. Mount this filesystem "somewhere". Make it the current
directory. Create all your databases inside it.?

# Example in Linux
cd /somewhere
tfile=$(mktemp -p .) #create temporary file
dd if=/dev/zero of=${tfile} bs=1024 count=1048576 # 1 gig
mkdir tempfs
sudo mount ${tfile} tempfs #mount the temporary file system
rm ${tfile} #remove temp file while leaving it mounted
cd tempfs #make tempfs the working directory
... do sqlite3 program(s) here
cd ..
sudo umount tempfs #unmount, which will remove inode as well


?Of course, I don't know if your OS can do the above because you can't say
anything about it. Also, I showed this as a shell script, but you could do
the equivalent in your application program before initializing the SQLite
environment. If you want/need to, you could do the unlink() (rm command)
_after_ terminating the the SQLite environment, unmounting the filesystem,
and overwrite the file contents before doing the unlink() to delete it.?

?In any case, even if you can't do exactly the above, perhaps it will spark
some other idea for you.

-- 
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

Reply via email to