新年のご挨拶

2012年となりました。今年もよろしくお願いいたします。

昨年は、ネットから飛び出して、様々な方々とお会いし、活動の幅がぐっと広がった年でした。

Androidを中心に端末のセキュリティ、プライバシー関係をいろいろ手がけております。来年の抱負というわけではありませんが、今年はもう少し活動の場を広げて行こうと考えておりますので、雑誌、書籍の原稿のレビュー、執筆依頼等がございましたら @typex20 までご連絡を頂けると幸いです。

＜2011年の活動の軌跡＞

（１）書籍の原稿レビュー（一部）

GDD2011に参加しながら原稿のレビューに参加させて頂いた思い出深い書籍です。@vvakame さん、@eyasuyuki さんには大変お世話になりました。

法人向けの内容となっており、お値段も3万円と高価ですので、職場で購入されることをオススメします。絶賛発売中です。

Androidセキュリティ・バイブル 2012

（２）書籍の原稿レビュー

一昨年の2010年のABCで @tao_gaku さんからお声がけを頂いていたのですがお目にかかることが出来ず、一年越しのABC2011 Summerで@tao_gakuさんとリアルでお会いすることができました。それがご縁で、タオソフトウェアさんが執筆された以下の書籍の原稿レビューに参加する機会を頂きました。@tao_gaku さんには大変お世話になりました。

一般のアプリ開発者向けの内容となっており、お値段も3,000円とリーズナブル。絶賛発売中ですので、お買い求め頂けると幸いです。

Android Security 安全なアプリケーションを作成するために

http://www.impressjapan.jp/books/3134

 

 

app.tv系コンテンツアプリによる実行されている及びインストール済みアプリ情報の送信について

高木先生の以下のご指導のもと、ミログ社のAppLog、app.tvの検証を行いました。

自分自身では、（１）と（４）を確認することができました。（２）（３）については未検証です。

※優先順位順

(1)apptv系コンテンツアプリの履歴送信事実の証拠保全、（←今回、済み）

(2)他のAppReward組み込みアプリの履歴送信事実の証拠保全（←未検証）

(3)FriendAppの履歴送信事実の証拠保全（←未検証）

(4)AppLogの同意状態管理の脆弱性検証（←済み）

→　AppLogのオプトアウトの仕様の脆弱性について

 

このエントリでは、（１）の確認結果について説明します。

崎山さんこと @sakichan さんに、app.tv系コンテンツアプリの解析結果を教えて頂き、自分でも確認してみました。

※詳しくは、こちらを参照してください。 → 株式会社ミログのAndroidスパイアプリ問題について（崎山伸夫のBlog）

 

・app.tv系コンテンツアプリの起動→メールアドレス指定→アカウントマネージャー許可→ app.tv の利用許諾画面。ここで home ボタン押して放置すると、実行されているアプリ情報、インストール済みのアプリ情報がapp.tv 系の log.friend-app.com へ平文で送信される。

また、自分で確認したところ、app.tvの利用許諾画面で許諾した後でも、サーバに情報が送信されていることが確認されました。

つまり、ユーザの許可の有無に関わらず、サーバに情報を送信していることがわかります。

app.tv系は、https://api.androidappcredit.com/に情報が送信されるとばかり思い込んでいましたが、app.tvとFriendAppは根が同じなのですね。

 

・app.tvでいったん許諾してしまうとサーバが許諾結果を覚えてしまうらしく、アプリを再インストールしても許諾画面が表示されない。

 

以下は、実行されているアプリ情報、インストール済みアプリ情報を送信する際の通信ログです。

http://log.friend-app.com/al/log/activities のURLに実行されているアプリ情報をPOSTします。

http://log.friend-app.com/al/log/packages のURLにインストール済みアプリ情報をPOSTします。

ここでは実行されているアプリ情報が3回、インストール済みのアプリ情報が4回に分けられて送信されていることがわかります。

 

＜実行されているアプリ情報を送信＞

以下のように、カンマ区切りで実行されているアプリのパッケージ名がサーバに送信されます。

jp.co.vfp.andapp.doga.vap.yuruani,com.android.launcher,org.proxydroid,com.android.vending,jp.co.vfp.andapp.doga.vap.akagi,jp.co.neoreeves.andapp.doga.neoreeves.misawakichi

実行されているProxyDroidが含まれていることがわかります。

実行中のアプリ情報の送信（リクエスト）

実行中のアプリ情報の送信（レスポンス）

 

＜インストール済みのアプリ情報を送信＞

同様に、カンマ区切りでインストール済みのアプリのパッケージ名がサーバに送信されます。

android,android.tts,com.adamrocker.android.input.simeji,com.android.bluetooth,com.android.browser,com.android.calculator2,com.android.certinstaller,com.android.contacts,com.android.defcontainer,com.android.development,com.android.htmlviewer,com.android.launcher,com.android.livewallpaper.microbesgl,com.android.magicsmoke,com.android.mms,com.android.musicvis,com.android.nfc3,com.android.packageinstaller,com.android.phone,com.android.protips,com.android.providers.applications,com.android.providers.calendar,com.android.providers.contacts,com.android.providers.downloads,com.android.providers.downloads.ui,com.android.providers.drm,com.android.providers.media,com.android.providers.settings,com.android.providers.subscribedfeeds,com.android.providers.telephony,com.android.providers.userdictionary,com.android.server.vpn,com.android.settings,com.android.setupwizard,com.android.soundrecorder,com.android.spare_parts,com.android.systemui,com.android.vending,com.android.vending.updater,com.android.voicedialer,com.android.wallpaper,com.android.wallpaper.livepicker,com.applogsdk.tweak,com.awwa,com.brainworks.contacts,com.cw.milogtest,com.google.android.apps.books,com.google.android.apps.genie.geniewidget,com.google.android.apps.googlevoice,com.google.android.apps.maps,com.google.android.apps.uploader,com.google.android.backup,com.google.android.calendar,com.google.android.camera,com.google.android.carhome,com.google.android.deskclock,com.google.android.email,com.google.android.feedback,com.google.android.gallery3d,com.google.android.gm,com.google.android.googlequicksearchbox,com.google.android.gsf,com.google.android.inputmethod.latin,com.google.android.latinimetutorial,com.google.android.location,com.google.android.marvin.kickback,com.google.android.marvin.soundback,com.google.android.marvin.talkback,com.google.android.music,com.google.android.onetimeinitializer,com.google.android.partnersetup,com.google.android.street,com.google.android.syncadapters.calendar,com.google.android.syncadapters.contacts,com.google.android.tag,com.google.android.talk,com.google.android.voicesearch,com.google.android.youtube,com.google.earth,com.hamatz.app.clairvoyance,com.noshufou.android.su,com.svox.pico,com.tf.thinkdroid.sg,jp.co.milog.appcredit,jp.co.milog.apptv,jp.co.neoreeves.andapp.doga.neoreeves.misawakichi,jp.co.vfp.andapp.doga.vap.akagi,org.proxydroid

愛用させて頂いているSimejiが含まれていることがわかります。

インストール済みのアプリ情報の送信（リクエスト）

インストール済みのアプリ情報の送信（レスポンス）

追記：2011/10/10 08:46

崎山さんがキャプった通信ログは以下から参照できます。通常のhttpで平文なので、WireShark等で読めるようです。

apptv アカギアプリの利用許諾に同意しない場合にとれたパケットキャプチャを公開してみます。binaryのままだからWireSharkとかで読んでね

http://dl.dropbox.com/u/2985145/packets-without-accepting-tos-of-apptv

 

AppLogのオプトアウトの仕様の脆弱性について

ミログ社が提供しているAppLogのオプトアウトの仕様の脆弱性が懸念されていたため、AppLogのオプトアウトを行うためのミログ社公式アプリである「AppLogCancel（旧称AppLog Opt-out）」の通信内容を以下の方法で解析を行った。

Androidのhttpsの通信をスニファーする方法（暫定版）

このAPIは端末とサーバ間で何ら認証を行っておらず、第三者がANDROID_IDを収集し、上記のリクエストをサーバに行えば、不正にオプトアウトの状態を変更することができることが確認できた。

収集したログはこちらを参照のこと。 → AppLog Opt-outのサーバAPIの通信ログ（Evernote）

AppLogのオプトアウトをするにはサーバに以下のURLをPOSTする。

https://api.applogsdk.com/v2/device/update

パラメータは、以下の2つ。

・android_id
・device[log_allowed]（device%5Blog_allowed%5D）

android_idは、Androidが提供している端末を識別するためのIDである、ANDROID_IDがセットされる。

また、device[log_allowed] = 1（ログ収集を許可） or 0（ログ収集を不許可） である。

AppLogSDKが組み込まれたアプリはログ収集の許可状態を確認するためにサーバに以下のURLをGETする。

https://api.applogsdk.com//v2/device

パラメータは、以下の3つ。

・android_id（上記と同様）
・developer_id（アプリ開発者を識別するためのID？）
・application_id（アプリを識別するためのID？）

サーバからは以下のレスポンスを返してくる。

{“device”:{“log_allowed”:true},
“notification”:{“enable”:false},
“promotion”:{“interval”:86400},
“collect”:{“interval”:60},
“url”:{“edit”:”https://api.applogsdk.com/v2/device/edit”,
“update”:”https://api.applogsdk.com/v2/device/update”},
“log”:{“interval”:21600},”ads”:{“interval”:2419200}}

AppLogSDKが組み込まれたアプリが、ユーザにログ収集の同意確認画面を表示されるのは、”notification”:{“enable”:true} の場合であるため、第三者に不正にオプトアウトの状態を変更されると、ユーザにログ収集の同意確認画面を表示することなく、ログ収集を行うことが可能である。

 

ログを確認すると、Date: Sun, 09 Oct 2011 13:53:41 GMT、つまり、日本時間の10/9（日）22:53では、AppLogのサーバの脆弱性のある動作を確認できたが、その2時間後の10/10（月）0:52では、ANDROID_IDを変更しても、常に、{“device”:{“log_allowed”:false}, ”notification”:{“enable”:false}の値が返ってくるようになった。

恐らく、上記の脆弱性の指摘に気づいて、サーバの設定を変更し、ログ収集を一時的に止めたものと推察される。

 

Androidのhttpsの通信をスニファーする方法（暫定版）

Androidのhttpsの通信をスニファーする方法（暫定版）です。

現在、某アプリの解析が忙しいので簡単な図による説明だけです。

あとでまとめます。m(_ _)m

尚、https/sslによる通信は、端末やサーバに不具合などの脆弱性が無い、端末やサーバを改造されたりしなければ、一般的に覗き見されることはありません。

ここに記載した内容は、Androidのアプリのhttpsの通信を解析することを目的とした、技術的なノウハウをまとめたものです。

Androidでhttps通信をスニファーするのは、iPhone、Windows Phoneと異なり、とても大変です。

理由は、以下の通りです。

（１）システム共通のプロキシーの設定が行えない。

（２）ルート証明書を変更することができない。（追加や削除を行うにはroot権限が必要）

（３）iptablesによるポートフォワーディングを行うことができない。（root権限が必要）

 

ということで、方法は２つあります。

 

（方法１）ポートフォワーディングを使う

参考：

技術 / Android / Emulator(AVD)の証明書ストアに証明書を追加する

・（１）実機からミログ系の検体アプリ、（２）ProxyDroid（透過型プロキシアプリ）を抜き出して、（３）エミュレータにインストールします。

・（４）ProxyDroid（Linuxのiptablesを使います）でAndroidの通信を外部PCで動作するBurp Proxy（非透過型プロキシ）に転送する設定を行います。

・（５）Burp ProxyのオレオレCA証明書をエミュレータに設定します。（６）Burp Proxyで特定ホスト名のサーバ証明書を返すように設定します。

これで、Burp Proxyでhttpsの通信をスニファーできます。

尚、Android Marketは実機のみで使え、正規の方法ではエミュレータでは使えないので、いずれにせよ実機は必要です。実機／エミュレータ共に正規の方法ではルート証明書を変更することができないので、エミュレータでもイメージの改造が必要です。

 

（２）AndroidのSSLのライブラリで証明書のチェックを無効化するように改造する

（あとで書く）

参考：

AndroidアプリケーションのSSL通信をプロキシで解析する(1)

 

 

applog検出アプリの動作原理と安全性について

総裁こと、村上福之氏が「applog検出アプリ」という素晴らしいアプリを開発されました。

Android Marketから入手可能となっています。

Applogがあなたの端末にインストールされてないかどうか調べるツールを作りました
（ITmedia オルタナティブ・ブログ）

追記：2011/10/05 13:03

applog検出ツールのソースコード公開します。
（ITmedia オルタナティブ・ブログ）

「applog検出アプリ」のソースコードが公開されました。

追記：2011/10/08 14:55

「通報君Z」（@hamatz 先生作）がリリースされました。

紹介文によると、

「最近話題の個人情報収集をするようなお行儀の悪いアプリがインストールされていないか？を検出する為のアプリです。クレイジーワークスの村上総裁が公開されていたAppLog 検出アプリを機能拡張し、ブラックリスト型で登録されているコンポーネントを含むアプリを検出します。ユーザの皆様からも、ブラックリストの更新について情報提供頂けますと幸いです。」

とのことです。

AppLog SDK及びapp.tv SDK（AppLogSDKと同等の機能を持っている）が組み込まれたアプリの検知と削除を行ってくれるアプリです。

最新版のv1.1以降でないと、app.tvシリーズのアプリを検知することができないのでご注意ください。

v1.0で、applogシリーズのアプリを検知することができます。
v1.1で、app.tvシリーズのアプリを検知することができるようになりました。

本アプリは「（ミログ社のapplogシリーズ、app.tvシリーズに限らず）同じことをする人達は一網打尽にするためのブラックリスト形式」になっているとのことです。

はまっつ先生に感謝。

 

※AppLogとは、ミログ社によって提供されているログ収集サービス及びアプリに組み込むための開発キットです。

以下、抜粋です。

http://www.applogsdk.com/ja/developer_sdk

AppLogSDKとは、アンドロイド端末におけるアプリケーションの利用情報を取得、送信する技術です。取得したアプリケーション情報は、端末における広告配信の最適化など、端末のユーザー体験の向上 に利用する事を目的とし、個人情報に該当する情報は送信されません。

 

「applog検出アプリ」の動作原理は以下の通りです。

（１）PackageManagerにAndroid端末にインストールされているパッケージ（アプリのこと）を問い合わせて、各パッケージ（アプリ）から ”com.applogsdk.ui.WebDialog” というActivityが含まれているかをチェックします。

（２）もし、パッケージ（アプリ）内に ”com.applogsdk.ui.WebDialog” というActivityが含まれていれば、そのアプリにはAppLogが組み込まれていると判断します。

 

尚、「applog検出アプリ」のAndroidManifest.xmlには、一切の<uses-permission>が含まれていない（つまり、全くpermissionが付与されない）ため、このアプリの安全性については問題ありません。

具体的には「applog検出アプリ」が通信を行ったりすることはできません。

以下に「applog検出アプリ」のAppLog検出部分をJava言語にディスアセンブルした結果を載せておきます。onCreate()のメソッド内ですべての処理を行っています。

（ありがとうございます！(^_^) ＞ 総裁）

注意事項：

・Forward-LockのかかっていないAndroidアプリケーション（.apkファイル）は、Android端末のrootをとらなくても簡単に抜き出すことができます。

（Forward-Lockがかかっている場合は、rootが必要です。）

・また、リバースエンジニアリング対策が行われていないAndroidのアプリケーション（.dexファイル）は、簡単にディスアセンブルすることができます。

 

 

Mac OS XでMicrosoft Officeを駆使するにはマウス選びが重要

OS X 10.7.1 Lionで、旧バージョンのMicrosoft Office 2008を使っています。

Windows版のPowerPointでは、複雑な図を編集していてもなんら問題なく快適に作業が行えるのに、なぜかOS X版では、オブジェクトをマウスで選択しただけなのに勝手に動いてしまう、画面をスクロールしていまう、ページが変わってしまうなど、不可解な現象が起きます。

OS X版のPowerPointで長時間作業をしているとストレスが溜まります。

これまでずっと、Windows版に比べてOS X版のPowerPointの出来が悪いから上記のような症状が起きると思っていたのですが、そうではありませんでした。

Apple製のマウス（Apple Wireless Mighty Mouse, Magic Mouse）のチャタリングが原因だったのです。

ちなみに、LogicoolのVX Nano Cordless Laser Mouse for Notebooks（M-RCJ134）では上記のような現象は全く起こりません。

長らく、OS X版の不可解なPowerPointの挙動に悩まされて、MacでMicrosoft Officeを使うのを避けてきましたが、これで本格的に仕事の資料作成をMacで行うことができるようになりそうです。(^_^)

 

深刻なMacBook離れが加速中。。

タイトルは釣り。(^_^;)

2011年8月末に新MBA（Core i7 1.8GHz、メモリ4GB、SSD256GB）を購入しました。

MBA（MacBook Air）があまりにも快適なので、これまでメインで使っていた初アルミMacBookの使用頻度が激減してしまいました。

MBAはSSDなので、HDDに比べてストレージの読み書きが速く、アプリの起動速度だけでなく、アプリが実行中にストレージを読み書きする際のパフォーマンスまで劇的に改善されるため、アプリがサクサク動きます。

また、MBAは、薄くて軽いので家中を気軽に持ち運びできるし、バッテリーもフル充電の状態で軽く2時間以上は持つので、ケーブルレスで快適に使えます。

唯一の欠点はメモリが4GBしか搭載できないこと。VMware Fusionを快適に使うには、メモリは8GB欲しいところです。

GDD2011のDevQuizのスライドパズルのsolverプログラムをMBAで実行したときは、CPUの冷却ファンがぶんぶん回って故障するのではないかと心配になりました。。

MBAは実装密度が高いので、放熱を考えると、長時間、連続して高負荷の処理を行う用途には向かないと思います。そう考えると、現状のスペックは理にかなっているのかもしれませんが。

ということで、ちょっとお高いですが、MBAの購入してよかったと思います。

P.S

@brzm505 さんのアドバイスで、MBAという素晴らしい製品に出会うことができました。いつもありがとうございます。(^_^)ノ

 

 

ThinkPadT42でDebian：Debian 6の電源管理の謎について

Linuxでの電源管理は、伝統的に、acpid, acpi-support-base, acpi-supportで行われているようですが、Debian 6のグラフィカルログイン環境では、gnome-power-managerによって電源管理が行われるようです。

つまり、acpiの設定をいくら行っても、gnome-power-managerの設定を行わないと反映されないというわけです。

Debian/etch で Gnome Power Managerをつかってサスペンドする の情報によると、

従来の場合は、すべてacpidで電源管理の処理が行われます。

(acpiのイベント)

=> acpid でフック

=> イベント種別から /etc/acpid/events 以下の設定でスクリプトを選択

しかし、グラフィカルログイン環境では、acpidで処理された後、gnome-power-managerで電源管理の処理が行われるようです。

(acpiのイベント)

=> acpid でフック

=> acpi-support パッケージにより、キーイベントに変換され、/dev/inputXに渡される。

=> Xサーバ君がキーイベントを受ける

=> gnome-power-manager がキーイベントを受け取り？、    ディスクトップのユーザ設定に応じて処理を決めて、    サスペンド／ハイバネーションの要求を〜する。

ということで、Debian 6でgnomeのグラフィカルログイン環境での電源管理は、acpidだけではなく、gnome-power-managerでも管理されているということを理解する必要があります。

詳しくは以下をご覧下さい。

ThinkPadT42でDebian：リッドクローズドモードで使う

 

ThinkPadT42でDebian：リッドクローズドモードで使う

Debian 6をインストールしたThinkPad T42はサーバとして使用したいので、液晶画面は閉じた状態でも電源がONの状態で使える、リッドクローズドモードの設定を行います。

Debian 6のグラフィカルログインには落とし穴がある。

Debian 6をグラフィカルログイン環境でインストールすると、ログイン後の状態では液晶画面を閉じてもサスペンドしないのに、ログイン前の状態のログイン画面で液晶画面を閉じるとサスペンドしてしまう、という現象が起きます。

原因は、gnome-power-managerというプロセスです。

ログイン前の状態では、gdm3のユーザIDである、Debian-gdm（UID=106）でgnome-power-managerが実行されますが、ログイン後の状態ですは、ログイン時のユーザIDで実行されます。

gnome-power-managerは、”電源管理の設定”というアプリケーションで設定した設定ファイルを参照しますが、Debian-gdm（UID=106）には、その設定が反映されていないのが原因です。

では、どうすれば、Debian-gdm（UID=106）にも電源管理の設定を反映させることができるのかと言うと、”電源管理の設定”のウィンドウの下に「デフォルト値」にする」というボタンがありますので、これをクリックします。

”デフォルト値にする”のボタンの意味は、システム全体で共通の設定値を設定するということです。

”電源管理の設定”は、gconfによって設定ファイルを保存しており、システム全体で共通の設定値として保存した場合は、以下のファイルに設定値が保存されます。

○デフォルト値が保存される場所

/etc/gconf/gconf.xml.defaults/%gconf-tree.xml

ちなみに、各ユーザの個別の設定値は、ログインしたユーザIDのホームディレクトリ配下の ~/.gconf/apps/gnome-power-manager/%gconf.xml に保存されます。

すると上記のように、”lid_ac”が”blank”、つまり、液晶画面が閉じられた時は、サスペンドせずに液晶画面をブランク（液晶画面の電源をOFFにして真っ暗）にするという設定になります。

これで、ログイン前の状態のログイン画面で液晶画面を閉じてもサスペンドしなくなります。

めでたし、めでたし。

 

 

ThinkPadT42でDebian：Debian 6のインストール

ThinkPad T42に最後の一働きをしてもらうため、Debian 6 squeezeをインストールしてみました。

Pentium-M 1.8GHz、メモリ2GBなのでできることは限られますが、それでも玄箱Pro（ARM9 400MHz, メモリ128MB）に比べれば快適です。

（１）Debian 6のインストールCDイメージ（isoイメージ）をDLする。

ThinkPad T42はUSBメモリからブートすることができないので、Debian 6のインストールCDイメージ（isoイメージ）をDLし、CD-R、ないしは、DVD-Rに焼いて、そのメディアからブートします。

http://www.debian.org/distrib/netinst#smallcd

今回は、上記のネットワークから必要なファイルを適宜DLしながらインストールする”小さなCD”というイメージを使いました。

これならCD-R、あるいは、DVD-R一枚で済みます。焼いたメディアは緊急用のメンテナンスディスクとしても使えるので、インストールが終わったら大事にとっておきましょう。

最近のLinuxのディストリビューションは64bit版がメインになっているため、DLするときは、64bit版（amd64）ではなく、32bit版（i386）のイメージが必要です。（ThinkPad T42のPentium-Mは、32bit CPUです。）

※ちなみに、ThinkPad T42で間違って64bit版（amd64）のイメージでブートしてみたところ、途中まではブートしますが、ハングアップしてしまいます。。

ThinkPad T42のCD/DVDドライブがへたっている場合は、外付けのUSB CD/DVD-ROMドライブからでもブートできます。

（２）光学メディアからブートする。

ThinkPad T42のBIOSの設定で、起動順が、HDDよりも先に、内蔵のCD/DVD-ROMドライブ、外付けUSB CD/DVD-ROMドライブが来ていることを確認して、いよいよインストールを開始します。

（３）インストールする。

ネットワークから必要なファイルを適宜DLしながらインストールするので、通信状況やサーバの状況によって変わってきますが、インストールが完了するのに結構時間がかかるので、気長に待ちましょう。

P.S

玄箱Proでは、開発版の次期Debian 7 wheezyを使用していましたが、アップデートが頻繁に行われるため、追従するのが大変なので、今回はおとなしくリリース版のDebian 6にしています。(^_^;)