sqlparse v.1.1 を試す(2)
引き続き、sqlparse v.1.1 のテストを行ってみます。
昨日はページ内の削除レコードを検出する部分を試したわけですが、ページ内での上書きが発生した場合やページ再利用時にどうなるかテストしてみます。
まず、昨日と同じくサンプルのデータベースファイルとテーブルを作成します。下記は5件のレコードが存在しているリーフページです。
Secure Deleteがオフの状態で、このテーブル内のデータ 5件を全て一括削除してみます。
この状態であれば、Sqlpaeseで処理すると以下のように削除レコードを検出してくれます。
Type Offset Length Data
Unallocated 520 504 T#hogehoge005C#hogehoge0042#hogehoge003!#hogehoge002#hogehoge001
現在、ページ内には過去のレコード5件が残っていますが、この状態のまま新規にレコードを作成すると、以下のように過去のレコードが上書きされていきます。（1件だけレコードを追加）
この状態でも、Sqlpaeseで処理すると以下のように削除レコードを検出してくれます。
Type Offset Length Data
Unallocated 522 486 T#hogehoge005C#hogehoge0042#hogehoge003!#hogehoge002
次は若干トリッキー？なことをしてみます。レコード2はとても長い文字列を入れていますので、1レコードには収まりませんので、別のページが割り当てられた状態になります。
部分的に別ページにデータが存在する状態で、このレコードを削除してみたのが下記の状況です。
青い線の下にあるページ内には文字列が存在していることを目視であれば確認できますが、sqlparseで処理した結果は下記です。
Type Offset Length Data
Unallocated 524 298 6
Free Block 839 169 ?port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139port139por
Free Block 839 の位置は青い線より上の部分にあり、ページが再利用されている青い線より下にあるデータは拾えてないことが分かります。
仕様を詳しく確認していないのですが、ページが別用途で再利用されていたりする場合には、そのページ内にレコードが残っていても検出しないかもしれません。
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 版を使ってみたいと思います。
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の場合、ページ内で削除されたレコードの位置は特定するが、データ自体はない（削除レコードが存在している事は認識できる
雑談： 転職して一カ月
前職を 7/31 付で退職してから、新たな会社に入ってやっと一カ月が経過しました。
劇的に変わった事といえば日々スーツになった事がありますが、仕事内容としては今のところまだまだ見習い状態です（笑）
転職したことをご報告していなかった方々に急に遭遇する機会も多く、若干ビックリされてしまう事もありますが、元気にお仕事させていただいております。
新たに覚える必要がある技術的な項目も多く、自分の不得意なところも良く分かってきた部分もありますが、やりがいのあるお仕事ですので焦らずじっくり取り組んでいかないといけないと、二ヶ月目突入前にちょっと考えている今日この頃です。
Android の自動バックアップ（写真や動画）
Android のバックアップについては下記 URL で説明されていますが、写真や動画、については自動バックアップの設定を行う事ができます。
データをバックアップ、消去する
https://support.google.com/nexus/answer/2819582?hl=ja自動バックアップのオン/オフを切り替える
https://support.google.com/plus/answer/1647509写真アプリを開き、 メニュー アイコン/ボタン> [設定] > [自動バックアップ] の順にタップし、[オン] または [オフ] を切り替えます。
この写真アプリの自動バックアップを有効にしている場合、自動的に写真がバックアップされますが、この内容は Google+ 側で確認する事ができます。
Android で設定している Google のアカウントで Google+ にアクセスし、左上のプルダウン メニューから「写真」を選択します。
次に検索のウインドウにあるプルダウンメニューから「自動バックアップ」を指定するか、直接 #AutoBackup を入力して検索すると、自動バックアップによりアップロードされた写真などを確認することができます。
複数のデバイスを使っている場合には、それら全ての自動バックアップされた画像が表示されますので、場合によっては現在使っていない端末で過去に自動バックアップされたものが含まれていたりするケースもあります。
Google+ で自動バックアップした画像ファイルをダウンロードする事ができますが、この時に「写真をダウンロード」の選択肢として、①元の写真、②補正済み、のいずれかを選択する事になります。この時、補正済みの写真をダウンロードすると、端末にあるオリジナルの写真とはファイルサイズなどが異なる状態でダウンロードされる事が分かります。
自動的に補正がかかっているケースでは、意識せずにダウンロードすると補正された写真のほうがダウンロードされることになるので注意が必要です。
（対象をチェックしておいてから）自動補正を適用⇒オフ、とし元に戻してからダウンロードすることで元のファイルサイズの画像をダウンロードする事が可能になります。
補正の影響は、データツール⇒データをダウンロード⇒データコピーのダウンロード、でアーカイブを作成してバックアップを取る場合にも影響します。自動補正したままアーカイブを作成すると、アーカイブに含まれる写真は補正された状態のものになります。補正を先に解除し、それからアーカイブを作成すれば元サイズの画像がアーカイブされる事になります。
なお、ファイルサイズはだいたい同じ様なサイズになると思いますが、EXIF が変更されていますので同じにはなりません。また、ハッシュ値も当然ですがオリジナルとは一致してきません。エクスプローラのプロパティでみると分かりますが、元の場所のプログラム名が Google になるなど、EXIF 値がオリジナルと異なった状態で保存されているようで、ハッシュ値による同一確認がそのままではできませんね。
Android のマルチユーザと adb backup (2)
Android のマルチユーザー機能に関連して「制限付きプロフィール」というユーザーを作成する事ができます。このユーザーは、Owner と同じ Google アカウントなどを使用しつつ使えるアプリケーションを制限したりする事ができます。ぺレンタルコントロールなどで使うケースを想定している機能のようですね。
制限付きプロフィール
https://support.google.com/nexus/answer/3175031?hl=ja何が制限されて、何が許可されるのか？
Android 4.3の制限付きプロフィールを試す
http://internet.watch.impress.co.jp/docs/column/shimizu/20130903_613668.html
制限付きプロフィールのユーザーを追加すると、まず（Ownerアカウントについて）画面ロックを有効にするように求められます。 制限付きプロフィールのユーザーがOwner側のユーザーにアクセスできない様にする為だと推測していますが、単純にユーザーを追加した場合には求められないんですよね＞画面ロックの有効化
制限付きプロフィールでは、許可したアプリケーションが利用可能になる仕組みになっているので、ここでは例えば LINE を Owner 側の設定から許可して、制限付きプロフィールで使った場合に、どこにデータが置かれるかを確認してみます。
root@generic_x86:/data/user/11/jp.naver.line.android/databases # ls -l
ls -l
-rw-rw---- u11_a52 u11_a52 16384 2014-07-20 19:18 NewBadge.db
-rw------- u11_a52 u11_a52 8720 2014-07-20 19:18 NewBadge.db-journal
-rw-rw---- u11_a52 u11_a52 16384 2014-07-20 19:18 cafecache.db
-rw------- u11_a52 u11_a52 8720 2014-07-20 19:18 cafecache.db-journal
-rw-rw---- u11_a52 u11_a52 311296 2014-07-20 19:18 naver_line
-rw------- u11_a52 u11_a52 12824 2014-07-20 19:18 naver_line-journal
データとしては/data/user 配下に 11 という番号で新規のフォルダが作成され、その配下にデータベースファイルが配置されている状況です。
この時点では、まだ LINE を制限付きプロファイルでは実行していませんので、Owner アカウント側ので DB がコピーされている状況に見えます。
※LINE 自体が制限付きプロフィールの環境化で使えるのか未確認です、検索してみると制限付きプロフィールではうまく動作しないアプリケーションもあるようですね。
制限付きプロフィールについても、データの保管場所はユーザ用のフォルダが /data/user 配下に作成され、そこに置かれています。
このパスにあるデータは、adb backup の対象範囲外になりますので、制限付きプロフィールを使っている場合にも、追加したユーザと同じくバックアップはかなり難しい状況になるという事ですね。
なお、マルチユーザー環境におけるAndroid のバックアップ設定については、現状では Owner アカウントしか設定できない仕様のようです。追加したユーザーでは「バックアップとリセット」も使えないと。
データをバックアップ、消去する
https://support.google.com/nexus/answer/2819582?hl=ja
複数のユーザーで 1 台のタブレットを使用している場合、[バックアップとリセット] オプションが表示されるのは、タブレットの所有者のみです。
Android のマルチユーザと adb backup (1)
AVD 上の Android でマルチユーザーを設定し、adb install コマンドで LINE をインストールしてみました。Owner と新しいユーザーの両方から LINE アプリケーションを起動する事ができますが、それぞれアプリケーションデータの保管場所は異なっています。
最初の Owner アカウントで LINE を実行すると以下二つのフォルダ配下にデータベース関連のファイルが存在している事を確認できます。
/data/data/jp.naver.line.android/databases
/data/user/0/jp.naver.line.android/databases
追加したユーザーのデータのデータベース関連ファイルは下記フォルダ配下になります。
/data/user/10/jp.naver.line.android/databases
作成した順番に 10,20 と番号が付与されるようですが、Owner については /data/data 配下と /data/user/0 配下の両方にデータがある事になりますが、/user/0 は /data/data へのリンクになっています。
新しく作成したユーザーでアプリケーションをインストールした場合、そのアプリケーションは Owner のアカウントからは見えません。とはいえ、アプリケーションのフォルダ自体は /data/data 配下に作成されてはきます。
追加したユーザーがインストールしたアプリケーションが、pm list packages コマンドで確認できるか試してみたのですが、別ユーザーでインストールしたアプリケーションはパッケージリストの中に表示されませんでした。この為、マルチユーザの端末については pm list packages でインストールされているアプリケーションを全て把握するのは難しそうです。
マルチユーザ環境で adb backup コマンドを実行した場合ですが、基本的にはシングルユーザーでバックアップ対象としている範囲だけをバックアップするようです。
まず、adb backup を実行した際の確認画面が、追加ユーザーでログインしている状態では表示されません。Owner アカウントでログインしている場合にはバックアップの確認画面が表示されます。
次にバックアップされるデータですが、例えば adb install でインストールした LINE は、apps\jp.naver.line.android としてバックアップされます。しかし、これは Onwer アカウント側のデータのみで、追加しているユーザーがある /user/10 配下のデータはバックアップに含まれていません。
また、追加ユーザーでインストールしたアプリケーションは、/data/data 配下にフォルダはありますが、バックアップにはこのフォルダが含まれてきません。
adb backup で -shared を指定した場合、/shard/0 としてバックアップが取れ、Ownerアカウントでは見えなかった Download フォルダ配下も取れているのですが、AVD 上での動作ですので実機でも同じ動作となるのかが分かりません。
adb backup コマンド自体はマルチユーザー環境を想定していないようですので、タブレットでマルチユーザーが使われている場合には、adb backup では不完全なバックアップしか取れない状況です。
マルチユーザーのAVDを作成する
手元の Android 端末（Xperia Z Ultra）は、マルチユーザーに対応していませんので、マルチユーザー環境で adb backup がどの様に動作するかテストできません。
その為、SDK の Android Virtual Devie（AVD)を使い、エミュレータ上にマルチユーザー環境を作成してテストしてみたいと思います。
Android Virtual Device(AVD) Manager を起動し、AVD の作成メニュー上で Device は Tablet を指定しておきます。手元では 10.1"WXGA(Tablet)(1280x800:mdpi) を選択しました。マルチユーザーはタブレット用のもので、一定のサイズ以上でないと使えないようですが、テスト目的ですので素直に Tablet と書いてある項目を選択しています。
作成した AVD を起動し（言語は日本語へ変更）設定 の項目を確認してみると、肝心の「ユーザー」の項目が見当たりません。
少し検索してみると、どうやらデフォルトではユーザー数が 1 に設定されているようで、設定を変更してあげる必要があるようです。
Android:エミュレータでマルチユーザ機能を確認する
http://yuki312.blogspot.jp/2013/02/android.html
上記の内容を参考に、adb shell から下記のコマンドを実行したところ、設定⇒ユーザーが選択できるようになりました。（下記では 4ユーザーを指定しています）
root@generic:/ # setprop fw.max_users 4
setprop fw.max_users 4
後はユーザーを追加すれば、ホーム画面上で Owner 以外のユーザーが選択できるようになります。
エミュレータ上の端末ですので、adb shell から root 権限でアクセスできますので、フォルダ構造の確認などは容易です。マルチユーザーのフォルダ構造については下記URLがとても参考になります。
マルチユーザ対応 Android 4.2以降の内部ストレージと外部ストレージ (4.4対応を追記)
エミュレータには Google Play がありませんので、adb install コマンドで APK ファイルを指定してインストールする事になります。
例えば LINE の APK を adb install コマンドを使いインストールすると、両方のアカウントから LINE アプリケーションが見える状況になります。（個別のユーザーに対してだけ adb install でアプリケーションのインストールを実行するという事はできないようです）
Android_ID の確認と LINE のリストア
adb backup でバックアップしたアプリケーション（例えば LINE）のデータを、adb restore で（エミュレータ上の仮想Androidへ）リストアすると、アプリケーションがエラーで起動しなくなります。
この点について、Android_ID が異なる影響を受けるといった情報もありますので、Android_ID について検索した内容をメモしておきたいと思います。
[Android]端末識別子Android_IDを変更する[要ROOT]
http://uchidak.net/change_android_id
上記URLの内容によりますと、data/data/com.android.providers.settings/databases/settings.db ファイル内に Android_ID が定義されているということです。
このファイルへのアクセスには root 権限が必要になるという事で、例えば adb backup -system コマンドでバックアップを作成してたとしても apps\com.android.providers.settings フォルダ配下に settings.db は含まれていません。
エミュレータ上のAndroidのsettings.db を確認してみたところ、secureテーブル内にandroid_id の項目があり、以下のような値が入っている事が確認できました。
"25","android_id","b80a6ca83c6effe6"
これを別の値に切り替えてみました。エミュレータ上のAndroidですので、以下のコマンドで変更されたandroid_id を確認できます。（値は適当です）
root@generic:/ # settings get secure android_id
settings get secure android_id
5cb098378611129e
contentコマンドを使い adb shell content query --uri content://settings/secure でも確認することができますね。（いずれのコマンドも、root権限がなくても実機で同様にandroid_idを確認できます）
Google Playには実機上でこの値を表示してくれるアプリケーションもあるようですね。
ANDROID_ID
http://developer.android.com/reference/android/provider/Settings.Secure.html#ANDROID_ID
さて、android_id を実機と同じに設定した状態(かつ、ネットワークは切断した状態）で、adb backup で作成した LINE のアプリケーションバックアップを、adb restore コマンドからリストアしてみたところ、LINE アプリケーションがクラッシュせずに起動する事ができました。
とはいえ、エミュレータ上の Android にはスタンプのデータなどが無いようで、トークのメッセージは読めますが、スタンプや画像は×マークのアイコン表示となり確認する事はできませんね。
追加で、LINE アプリケーションの機能を使って作成したトーク履歴のバックアップをエミュレータ上の Android にリストアしたところ、バックアップデータ内に含まれていた画像と、恐らく有料ではないスタンプはリストアされ表示できていました。
ここまでのテストで、バックアップデータを実機ではない環境で読むことが可能なことは分かりましたが、実機で読める場合にはもちろんその方が簡単ですね。
第4回 Androidにおけるセキュリティ設計と動作（後編）
http://thinkit.co.jp/story/2012/03/09/3467/page/0/2
Android で LINE のバックアップをリストアする
adb backup を使えばアプリケーションのバックアップを取ることができ、バックアップしたデータは adb restore コマンドを使うことでリストアできます。
通常はバックアップを取得した実機へバックアップデータをリストアする事になりますが、いま使っている実機環境はそのままにしておき、別の Android 端末へリストアできれば便利ではないでしょうか？
Android SDK には Android Virtul Devicesという機能で仮想的な Android デバイスを作成し、エミュレータとして使う事ができます。この仮想 Android マシンにバックアップデータをリストアできれば、実機はそのままで、別環境上でバックアップデータの内容を読むことができるかもしれないと考えたわけですが、結論から言えばそうは問屋が卸さないという状況です。
adb backup コマンドで一括作成したバックアップファイルは android backup extractor に添付されている adb-split.sh スクリプトを使うことでパッケージ単位に分割できます。
例えば LINE であれば、jp.naver.line.android.ab というファイルに分割してくれますので、このバックアップファイルだけをエミュレータにリストアすれば良いという事になります。
しかし、実際にリストアしてみたところ、LINEの起動段階でエラーになってしまいアプリケーションを起動する事ができません。LINE の APK ファイルを adb install でインストールし、LINE アプリケーションがエミュレータ上で起動する事は確認できるのですが、adb backup で作成したバックアップをリストアするとエラーにより起動できなくなるのです。
少し調べてみたところ、どうやら Android ID という機器に固有の番号？による認証が入っているようで、その情報が一致しないことでアプリケーションがエラーになるようです。
【要root】LINEを丸ごとリストアする方法
http://reindex.hotcom-web.com/archives/252Titanium BackupでAndroid IDだけを復元する方法
http://androidpeenats.blogspot.jp/2013/05/titanium-backupandroid-id.html
理論的には、Android ID をバックアップし、それをエミュレータの Andorid へリストすればいけそうに思えますが、そもそも実機側で Android ID をバックアップする必要があります。
Android ID を root なしでバックアップできるのか？という点が未確認ですので、もし root なしでバックアップが可能であり、かつエミュレータにリストアできれば少し進展させる事ができるかもしれませんね。
Android で LINE のバックアップを作成する(2)
LINE の標準機能によるトークのバックアップですが、［すべてバックアップ］を使ってバックアップを取ってみたいと思います。
バックアップの選択で[すべてバックアップ]を選択した場合、画面上に以下のようなメッセージが表示されます。
トーク履歴ファイルが”/LINE_Backup/LINE_Android-backup-chat-93391111516.zip”にバックアップされました。メールに送信しますか？
この時にメール送信を選択すると更に下記の注意メッセージが表示されます。
トーク履歴をLINE専用ファイル形式でメール送信します。音声・動画メッセージの一部は再生できない可能性があります。
ここで確認をタップすると、取り扱うアプリケーションの選択画面になりますので、例えば GMAIL などを選択すれば ZIP ファイルを添付ファイルとして送信する事ができます。
さて、手元の Android は 4.4.2 なのですが、バックアップを実行したのち PC に接続して内蔵ストレージにある LINE_Backup フォルダを表示しても肝心のバックアップファイルが見当たりません。
これも Android 4.4 からの制限に引っかかっているものか、アプリケーション側の問題なのかは切り分けできませんが、少なくとも手元ではメール送信などで外部へ送らないとバックアップが出来ないようです。
見えてない可能性を考え、adb backup を -shared オプション付きでバックアップしたところ、adb backup で取得したバックアップファイルのLINE_Backup フォルダ配下には ZIP ファイルが存在していました。
念のため adb shell コマンドで確認してみたところ以下の状況でした。
shell@C6833:/sdcard/LINE_Backup $ ls -l
ls -l
-rw-rw---- root sdcard_r 87804 2014-07-17 12:41 LINE_Android-backup-chat-93391111516.zip
ファイルは存在しているが、MTPモードでのアクセスでは見えないという状況ですのでパーミッションによるものでしょうか？、もしくは手元のOS環境での問題かもしれませんが。
検索してみたところ、デバイスを再起動すると見えるようになるという情報がありましたので、試しにデバイスを再起動してから Windows に接続したところ ZIP ファイルを見ることができました。
Issue 38282: Android MTP support does not show recent files until the device is rebooted
https://code.google.com/p/android/issues/detail?id=38282
また、Facebook のほうで知ったのですが、com.android.providers.media/databases/external.db でファイル情報が管理されていて、この更新が追いついてないと？、不整合が発生するらしいです。
バックアップしたZIPファイルは、LINE 独自の形式で読めないという事のようですが、image フォルダに作成される 47.thumb といったファイルは、中身としては JPEG ヘッダになってますので、拡張子を JPG に変更すれば普通に表示できるようですね。
チャットメッセージのほうはファイル形式が不明ですので、リストアしないと読むのは難しそうです。
また、バックアップを作成したアカウントでなければリストアする事ができないようですので、その点でも注意が必要でしょうか。
トーク履歴をバックアップ（保存）するには？
http://help.line.me/line/android/categoryId/10000336/pc?lang=ja［トーク履歴］を消しちゃった！復元できる？相手側も自分とのトーク消える？
http://linenavi.net/use/why_6/機種変・トラブル対策に！LINEのトーク履歴をバックアップ＆復元する方法（Q&A付き)
http://did2memo.net/2013/02/14/naver-line-talk-backup-and-restore/
