突然消失するかもしれないブログ

”とつきえブログ”

OS X版WordPress公式アプリからテスト投稿

OS X版のWordpress公式アプリがリリースされたということでテスト投稿してみた。

情報源はこちら。

WordPress gets a Mac app alongside completely rebuilt, open-source WordPress.com

http://9to5mac.com/2015/11/23/wordpress-redesign-mac-app/

 

ブログの新設のお知らせ

2008年から4年にわたりwordpress.com一筋でブログを書いてきましたが、この度、独自ドメインを取得し、ブログを新設いたしました。

新しいブログは、「にーまるどっとこむ http://blog.2maru.com/ 」となります。

wordpress.comの「突然消失するかもしれないブログ」は、セカンドブログとして今後も継続していこうと思いますので、引き続きよろしくお願いいたします。

 

玄箱ProでDebian squeeze/wheezyのアップデートする際の注意点

2011/03/11の震災で1台目の玄箱Proが故障してしまい、1年近く自宅にサーバーのない生活をしてきましたが、あまりに不便なため、2台目の玄箱Proを引っ張り出すことにしました。

2台目の玄箱ProにはDebian wheezyを自前でインストールしていたのですが、aptitude update; aptitude full-upgradeを実行して最新の状態にアップデートしたところ、悲しいことに正常に起動できなくなってしまいました。。

ブート時のエラーメッセージを見ると、udevが延々とエラーメッセージを吐いており、原因を調べてみたところ、Linuxカーネルが古く、カーネルのコンフィグが足らないせいのようです。

非公式のDebianインストーラを使用している限り、またこのような悲劇が起こるので、何か他の良い方法がないか探してみたところ、Debian本家が正式に玄箱Proに対応していることが判明しました。

玄箱ProでDebianをインストールする公式ガイドがあり、以下のサイトに従ってDebian公式インストーラでDebianをインストールすれば良いようです。

http://www.cyrius.com/debian/orion/buffalo/kuroboxpro/

非公式のDebianインストーラで玄箱ProにDebianをインストールしてしまうと、Debian本家のバージョンアップに追従するのが辛くて挫折しがちになりますが、Debian公式のインストーラでDebianをインストールすれば、安心して最新の状態にバージョンアップすることができるかもしれません。

ということで、近いうちに時間を見つけてセットアップしようと思います。(つづく)

 

1つのユーザープロセスが搭載している物理メモリを使い切るとLinuxカーネルが落ちる件

昨年の夏、DevQuizのパズル問題を解くために、OS XとLinuxを酷使したのですが、

OS Xは高負荷時(メモリを使い切る)でもシステムが落ちないのに、Linuxは落ちる。

という症状に悩まされました。

計算プログラムを朝、しかけて、夜、結果を確認すると、OS Xの方は、Macがファンをぶんぶん回しながら計算を続けていましたが、VMware vSphereの仮想マシン上で動作するDebian6のLinuxの方は、確実にLinuxカーネルごと落ちてしまうのです。

(仮想マシン、ハイパーバイザ自体は生きている状態です。ハイパーバイザの仕組み上、仮想マシンに割り当てた以上の物理メモリが使われてしまうことはありません。)

自分が作っている計算プログラム、つまり、1つのプロセスで搭載している物理メモリを使い切ってしまうことが原因だということは想像がつくのですが、スワップも設定しているのに、なぜLinuxカーネルが落ちてしまうのか原因がわかりません。

(スワップ領域がSANのストレージ上にあるのでそれが原因とか、VMware vSphereが原因とか??)

今、流行の ”ビッグデータ” などを処理しようとすると、ある程度安定した分散環境が必要になるのですが、原因がつかめないとLinuxベースで安定した分散環境を構築できるのか、この先、不安です。

 

追記:2012/02/19 14:27

Linuxカーネルがフリーズする原因は以下のようにいくつかあるらしいので、切り分けしたいと思います。

(1)Linuxカーネル、ドライバ等にバグがある。

(2)ハードウェアに不具合がある。(メモリモジュールにエラーがあるなど)

(3)仮想実行環境に不具合がある。

 

(2)(3)に問題がないことがわかれば、kexec+kdumpで(1)Linuxカーネル、ドライバ等の不具合を探っていくことになります。

 

※参考

第2回 減り続ける利用可能メモリ……そしてついにリブート!

http://www.atmarkit.co.jp/flinux/rensai/tantei02/bangai02c.html

「Linuxが落ちる原因,遅い理由はこうして突き止める」――VA Linux Systems Japan 高橋浩和氏

http://itpro.nikkeibp.co.jp/members/ITPro/oss/20040427/1/

Linuxでクラッシュダンプを採取(1) ~ kexec + kdump を使ってみる ~

http://dsas.blog.klab.org/archives/50558228.html

 

OS X LionでのDNS不調の原因について

最近、自宅でも会社でも、OS X Lionを使っていると、突然、DNSで名前解決ができなくなるという症状が頻発するのですが、ある程度、切り分けできたようなのでメモ。

 

・同一環境下(DNSサーバとしてGoogle Public DNSを参照)でOS X LionとWindows7を使っているが、症状が出るのはOS X Lionの一部のソフト。

・具体的には、OS X Lionでシステム環境設定のネットワークに依存しているソフト。

Apple純正のソフト(Safariなど)、Chrome、夜フクロウなど。

※Firefoxは独自に自前で名前解決を行っているせいか症状は起きない。

・ソフトを再起動しても症状は解決せず、しばらく放置するか、Wi-Fiを切って入れ直すと症状が改善することがある。

・Linux上に立てているSquid経由で通信する、dnsmasq経由で名前解決をすると症状が起きない。

 

試しにOS X上にdnsmasqをMac Portsでインストールして、ローカルのDNSサーバを経由してGoogle Public DNSを参照するようにしたところ、いまのところ全く症状が出なくなりました。

ちなみに、dnsmasqを自動立ち上げするには、以下のplistのDisabledキーをtrueからfalseに変更するだけです。

/Library/LaunchDaemons/org.macports.slapd.plist

変更前:<key>Disabled</key>    <true/>

変更後:<key>Disabled</key>    <false/>

 

Google Public DNSは人気があるそうで、負荷が高い時にクエリーに応答するまでに長い時間がかかってOS X Lion側のリゾルバの処理がタイムアウトしてしまうのかもしれません。また一度タイムアウトしてしまうと、リゾルバのDNSキャッシュをフラッシュしないと、しばらくの間?、正常に名前解決ができなくなるようです。

dscacheutil -flushcache

 

ということで、同じ症状に悩んでいる方は、dnsmasqを導入することをオススメします。

 

このブログは、、

どうやら、このブログは、突然消えたり、復活したりすることもあるようです。

ということで、これからもよろしくお願いします。

 

新年のご挨拶

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

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

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

<2011年の活動の軌跡>

(1)書籍の原稿レビュー(一部)

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

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

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

h_195360.jpg

(2)書籍の原稿レビュー

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

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

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

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

3134B.gif

 

 

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

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

自分自身では、(1)と(4)を確認することができました。(2)(3)については未検証です。

※優先順位順

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

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

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

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

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

 

このエントリでは、(1)の確認結果について説明します。

崎山さんこと @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が含まれていることがわかります。

NewImage

実行中のアプリ情報の送信(リクエスト)

実行中のアプリ情報の送信(レスポンス)

 

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

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

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が含まれていることがわかります。

NewImage

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

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

追記: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&#8221;,
“update”:”https://api.applogsdk.com/v2/device/update&#8221;},
“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と異なり、とても大変です。

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

(1)システム共通のプロキシーの設定が行えない。

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

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

 

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

 

(方法1)ポートフォワーディングを使う

参考:

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

NewImage

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

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

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

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

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

 

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

(あとで書く)

参考:

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

 

 

%d人のブロガーが「いいね」をつけました。