アンタイ・フォレンジック伝道者の独り言

基本的にはデジタル・フォレンジックの技術について取り扱っていますが、記載内容には高確率で誤りが含まれる可能性があります。

sqlparse v.1.1 を試す

SQLite の削除データをパースするツール sqlparse v.1.1 を試してみたいと思います。

sqlparse v.1.1
https://github.com/mdegrazia/SQLite-Deleted-Records-Parser/releases/tag/v.1.1

コマンドライン、GUI、Python スクリプトが提供されていますが、今回は GUI 版を使ってみたいと思います。

f:id:hideakii:20140906145416p:plain

SQLite3 のテスト用データベースを FireFox の SQLite Manager を使って作成します。削除レコードの復元テストという観点から、DB設定で以下の設定を行います。

  • ページサイズは 512byte(全体サイズを小さくして目視しやすくする為)
  • Secure Deleteはオフ

テーブル sample を作成し、レコードを 6件ほど登録します。

ページ内のレコードが削除されたケースを想定し、4番目のレコードを削除してから、このDBファイルをsqlparseで処理してみます。

SQLite Managerからテスト用のデータベースファイルの sample テーブルを表示すると以下のようになっています。No 4のレコードがない状態です。

f:id:hideakii:20140906143546p:plain

バイナリエディタでデータベースファイルを開き、ページ内を確認すると、レコード4の残骸が残っていることを確認することができます。(削除の影響で値として 4 は消えてしまっていますが。。。)

f:id:hideakii:20140906143858p:plain

Secure Deleteの場合には該当レコード部分はゼロ埋めされますが、今回 Secure Deleteをオフにしてあるので、データを確認できました。

このデータをsqlparseで処理してみます。処理方法として、Formatted Output(strip non printable characters)と、Raw Outputを選択できます。

残念ながら、日本語文字列が入っている影響なのか、Formatted で処理してもヘッダ部分しか出力されない状況でしたので、Raw Output を使ってみた出力結果が下記になります。

Unallocated, Offset 530 Length 264
Data:

Free Block, Offset 930, Length 42
Data:
*Wsasasasakld;akd;skd;lsakd;sakd;lsak;l

 

バイナリエディタで発見した削除データ部分を検出していることが確認できます。 

次に、日本語文字列を含んでいるデータを Secure Deleteオフの状態で削除し、同じ処理を実施してみたいと思います。

 No 5 として登録していたレコードを削除します、HEX 内容を確認してみると以下の状況であることが確認できます。日本語文字列は UTF-8 ですので、ちょっと分かりにくですが、残っていることを確認できます。

f:id:hideakii:20140906144905p:plain

 sqlparseで処理してみます。RAW Outputで処理した結果を UTF-8 としてエディタで開き、該当レコード部分として出力されたのが下記になります。

Free Block, Offset 863, Length 109
Data:
m?これは日本語文字列のテストThis is japanese test. *Wsasasasakld;akd;skd;lsakd;sakd;lsak;l

  

 二つの削除レコードが連続しているため連結して表示されてきますが、日本語文字列も RAW の出力結果から確認できました。

ページごと削除された場合などはテストしていませんが、ページ内レコードの残骸を拾ってくれるのはかなり便利だと思います。

  • Formatted Output(strip non printable characters)は日本語が存在するとうまく動かない?
  • Raw Outputを選択し、UTF-8で出力結果を読めば日本語も確認できる
  • Secure DeleteがONの場合、ページ内で削除されたレコードの位置は特定するが、データ自体はない(削除レコードが存在している事は認識できる