いつの間にやら消えていたiPhoneのUSBテザリング設定を復活させる。

最近、iPhone 4SをUSBにさしてもなぜかUSBテザリングしてくれないなぁ？と思っていたら、割と有名な不具合のようで、あちこちのフォーラムサイトにいろいろ載ってました。

MacOS X Snow Leopard(10.6.8) + iPhone 4Sな自分には
https://discussions.apple.com/thread/4367664?start=0&tstart=0
のAppleUSBEtherHost.kext (2.2.0)を使う解決策がｷﾀ━(ﾟ∀ﾟ)━!でした。

AppleUSBEthernetHost.kext 2.2.0を落としてきて解凍して
suでrootになって

rm -r /System/Library/Extensions/AppleUSBEthernetHost.kext
mv /Users/<名前>/Downloads/AppleUSBEthernetHost.kext /System/Library/Extensions/
chmod -R 755 /System/Library/Extensions/AppleUSBEthernetHost.kext
chown -R root:wheel /System/Library/Extensions/AppleUSBEthernetHost.kext
find /System/Library/Extensions/AppleUSBEthernetHost.kext -type f | xargs chmod 644

iPod touch (第4世代)を家庭用のサーバーマシンにする。ついでに古いマシンと冗長構成にする。

大学院の時から使い続けているiPod touch 第2世代がそろそろ古くなってきたので
＆　きのうたまたまアキバでiPod touch 第4世代 64GBが13000円で売っていたので


購入。

こいつが2年以上サーバに使ってたほう。彼女との交際期間よりなｇ(ry

構築したときのメモは→ http://plog.web-hack.org/2011/02/ipod-touch-iphone-php.html

んで、こっちが新しいの。
カメラがついてたり。iOS 6だったり。

・・・。
ん、、iOS 6???

JailBreakできねーじゃん！！！！

しかたがないので、tethered jailbreakで我慢。

蛇足：
　ソフマップさん、頼むからiOS 5.1で初期化処理やってください。
　Jailbreakなんて例外にしても、マップがあれだと、価値が半減ですよ。
　そもそも、iOS 6のっけると動作がモッサリしてるし。

で、

iPod touchをサーバにしていて、不安定になったりしてrebootかけた、ってことは
ここ2年以上一度もないわけだが、
だけども、やっぱりクラッシュしてしまうと（Just Bootをいちいち手元でやってあげないと）サーバとしての機能が果たせないということになるのは困る。

よって、古いiPod touchも残しつつ冗長構成をとることに。


ちなみに、うちはプライベートIPしか振ってくれないマンションゆえ、
OpenVPNとさくらVPSをつかって、ちょっと特殊なネットワーク構成にしていて、

　[web-hack.org]
　　　↓
さくらVPS上の鯖　…192.168.123.1
↓　　↓　　↓　　↓
○　　○　　○　　○　…192.168.123.0/24

構築方法は→http://plog.web-hack.org/2011/11/vpsopenvpnipod-touchweb.html

こういうネットワーク構成を前提に説明をすすめます。
以降の作業は、さくらVPS上の鯖でのものです。（新旧iPod touch側は同じHTTPサーバを２つ用意するだけなので、省略）

apache2の下記のモジュールを有効化。

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http

そんで、/etc/apache2/sites-available/defaultに

<VirtualHost *:80> 
    ServerName web-hack.org

    <Proxy balancer://web-hack/>
        BalancerMember http://192.168.123.10/
        BalancerMember http://192.168.123.18/
    </Proxy>

    ProxyPass / balancer://web-hack/
    ProxyPassReverse / balancer://web-hack/
</VirtualHost>

って書く。
192.168.123.10が古いiPod touch
192.168.123.18が新しいiPod touch

これで、あとは

sudo /etc/init.d/apache2 restart

とやるだけで、簡易ロードバランサのできあがり。


なんか

balancer://web-hack/

を

balancer://web-hack

と書いてしまうと、よくわからない

[Mon Dec 24 23:33:21 2012] [warn] proxy: No protocol handler was valid for the URL /favicon.ico. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

みたいなエラーが出ます。けっこうはまりました。

Android(4.0以降)にはグローバルプロキシ設定が隠れているようだ。

最近、Galaxy Note(GT-N7000)にCyanogenMod 10を導入していろいろソースを見たりいじったりしてるわけですが、
たまたまなんだか気になるものを発見したのでメモ。

あれ？プロキシ設定あるよ？

まあ、なにもしなくてもWifi設定からできるけど、あれって「ブラウザでしか使えまへん」って思いっきり書いてあるし。
こっちはどうなんでしょう？
（そのうちtcpdumpとって見てみます）

以下、自分のEvernoteにメモってたことそのままコピペｗ
------------------------

ICSくらいからAsIsでメニュー自体は実装されているようだ。

ただ、動きが保証できていないのか、非表示にされてる。

packages/apps/Settings/src/com/android/settings/WirelessSettings.java

    158         // Enable Proxy selector settings if allowed.

    159         Preference mGlobalProxy = findPreference(KEY_PROXY_SETTINGS);

    160         DevicePolicyManager mDPM = (DevicePolicyManager)

    161                 activity.getSystemService(Context.DEVICE_POLICY_SERVICE);

    162         // proxy UI disabled until we have better app support

    163         getPreferenceScreen().removePreference(mGlobalProxy);

    164         mGlobalProxy.setEnabled(mDPM.getGlobalProxyAdmin() == null);

163, 164行目をコメントアウトすると、メニュー自体は見れるようになる。

そして、ConnectivityManagerがわにGlobalProxyをセットするルートもあるようだ。

packages/apps/Settings/src/com/android/settings/ProxySelector.java

    257         ProxyProperties p = new ProxyProperties(hostname, port, exclList);

    258         // FIXME: The best solution would be to make a better UI that would

    259         // disable editing of the text boxes if the user chooses to use the

    260         // default settings. i.e. checking a box to always use the default

    261         // carrier. http:/b/issue?id=756480

    262         // FIXME: If the user types in a proxy that matches the default, should

    263         // we keep that setting? Can be fixed with a new UI.

    264         ConnectivityManager cm =

    265                 (ConnectivityManager)getActivity().getSystemService(Context.CONNECTIVITY_SERVICE);

    266 

    267         cm.setGlobalProxy(p);

もっと根っこをみていくと、単純なDBセットのようだ。

frameworks/base/services/java/com/android/server/ConnectivityService.java

   2806             ContentResolver res = mContext.getContentResolver();

   2807             Settings.Secure.putString(res, Settings.Secure.GLOBAL_HTTP_PROXY_HOST, host);

   2808             Settings.Secure.putInt(res, Settings.Secure.GLOBAL_HTTP_PROXY_PORT, port);

   2809             Settings.Secure.putString(res, Settings.Secure.GLOBAL_HTTP_PROXY_EXCLUSION_LIST,

   2810                     exclList);

------------------------

ということは・・・・

ルートハックさえしてしまえば

ごにょごにょっ

ってやって、書き換えれちゃうわけですね。

ただ、下記のようなソースコメントがあるくらいなので、どのくらいまともに動くのかは…使ってみないとわからんですね。

＞   162         // proxy UI disabled until we have better app support

:追伸:

一応検証したので。

プロキシ設定のUIから、DBに設定値が行く事は確認した。

adb shell 'echo "select * from secure;" | sqlite3 /data/data/com.android.providers.settings/databases/settings.db'

129|global_http_proxy_host|hoge-hoge.org

130|global_http_proxy_port|8080

131|global_http_proxy_exclusion_list|abc.com

ただ、tcpdumpを取ってみると、反映はされていない。３G/Wifi環境ともに

・Facebook

・Google Talk

・Google Play

・マピオン

どれも直接接続しに行ってる。すくなくとも4.1.2では。

全然グローバルじゃねえ！！！

っていう結果でした。

遠くのビルドサーバでビルドしたapkを手元のPCにつないだスマホにadb pushしよう

最近はやりのAndroidですが、ICS以降、ビルドの要件がめっちゃ高くなりました。
早い話が、CPU、メモリが潤沢にあるPCでしかビルドできません。

ビルドサーバを用意して、手元のノートPCで細かいデバッグをやる、というのがよくあるスタイルですが、
ソースをアップして成果物をSFTPでダウンロードして・・・　というのも面倒ですよね。

ようするに、ビルドサーバーのコンソールで作業していて、その流れでadb push hoge.apk /system/app/ ってやったら、手元のスマホにpushされるようにしたいんですね。
（SSHFSを使うっていう裏技もありますが、これじゃあWindowsでは使えません）


とりあえず手元のMacbookAirにGalaxyNexusつないで、ビルドサーバとはSSH接続、ってのを仮定してすすめます。
その3ステップ

1. MacbookAirで

adb devices

これでMacbookAir:5037=>GalaxyNexus:5037というルートができます。

2. MacbookAirからビルドサーバへログイン

ssh build.server.hoge.jp -R 5037:localhost:5037

これでビルドサーバ:5037=> MacbookAir:5037というルートができます。

3. SSHでログインしたシェルで

adb devices

これで、MacBookAir側のGalaxyNexusが出てきますね。はい。完了です。
あとはadb push なりなんなり。

adb logcatとかもできますが、ネットワーク越しにログがぜーんぶ流れることになるので、logcatはMacBookAirローカルでやりましょう。

パケットキャプチャをしてわかった。LINEは危険。

ケータイの開発現場の話なので、多くは語れないが、
今日、すこし解析をしていてこれはどうなんだ？？と思った件を。メモ。

　標的はAndroidのLINEはアプリ。


1. LINEを入れていると、電池もちが悪くなる件

LINEって、なんかAppleのiMessageみたく、SNSやってるような画面ありますよね。

こんなやつ。（http://news.ameba.jp/image/20120723-287/ から拝借させていただきましたm(_ _)m）

チャットやってる最中にリアルタイムに相手からのメッセージが飛んでくる仕組みは、
まあなんとなくわかりますよね。チャットサーバー的なものにコネクション張りっぱなしにしておいて、受け取ってるんでしょうね。

では、
アプリ画面を閉じてる時ってどうなってると思います？

メール通知みたいな感じでLINEのメッセージを届ける仕組みはどうなっているのか？

rootハックした端末で、tcpdumpをとってみてみました。

なんと、HTTPのKeep-Aliveで実現されているんですね。
ようするに、Android端末はDeepSleepに入っていないんですよ。


まあ、ただ、LINE開発者もちゃんと考えてはいて、多少の考慮はされています。


Keep-AliveのTimeoutが何回か続くと、その後はAlarmManagerのRTC_WAKEUPにゆだねて、5分に1回のポーリングをする動作に切り替えて、Keep-Aliveをやめるようにはなっています。


2. あれ、HTTPって、セキュリティ的に大丈夫なんだっけ・・・？

で、一番の問題は電池の問題じゃなくて、ココ

＞なんと、HTTPのKeep-Aliveで実現されているんですね。

でピンときた人もいるかもしれない。

そう、メッセージの内容が盗聴できる！

(2012.10.16 写真追加)

tcpdump -n -s 0 -w /data/local/tmp/line.pcap
（チャット、送信！）
Ctrl+c

と、かなり狙った手順ではありますが、
キャプチャ結果を見ると、どうみても暗号化されてないのがわかります。
その気になれば、盗聴も改ざんもできそうです。

ちなみに、Wifi通信だと、平文っぽくはありませんでした。なんらかの暗号化がされているようです。平文通信なのは、3Gの時だけのようです。


んにしても、「そんな、盗聴されたら会話が丸見えだなんて！」と思う人は多々いるでしょう。

あまり世の中には知られてなさそうだったので、細々とでも、ここのブログで発信してみます。