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 版を使ってみたいと思います。
SQLite3 のテスト用データベースを FireFox の SQLite Manager を使って作成します。削除レコードの復元テストという観点から、DB設定で以下の設定を行います。
- ページサイズは 512byte（全体サイズを小さくして目視しやすくする為）
- Secure Deleteはオフ
テーブル sample を作成し、レコードを 6件ほど登録します。
ページ内のレコードが削除されたケースを想定し、4番目のレコードを削除してから、このDBファイルをsqlparseで処理してみます。
SQLite Managerからテスト用のデータベースファイルの sample テーブルを表示すると以下のようになっています。No 4のレコードがない状態です。
バイナリエディタでデータベースファイルを開き、ページ内を確認すると、レコード4の残骸が残っていることを確認することができます。（削除の影響で値として 4 は消えてしまっていますが。。。）
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 ですので、ちょっと分かりにくですが、残っていることを確認できます。
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の場合、ページ内で削除されたレコードの位置は特定するが、データ自体はない（削除レコードが存在している事は認識できる
