[Android] カーネルのconfig

boot.imgを展開して見てきましたがカーネルの方にも着目してみたいと思います。

まずはここからextract-ikconfigをダウンロードして来て下さい。
textで開いてしまうと思うのでリンク先を保存で。
このextract-ikconfigはLinuxカーネルソースのscriptsディレクトリに入っている物ですが
たまに変更がかかるのでなるべく新しいものを使った方がいいですね。
使い方は

./extract-ikconfig boot.img-kernel.gz > config

configってファイルが出来るので中身を見て下さい。
Androidのカーネルをビルドする時には多くの機能の中から
何を取り入れるかを選択していくのですが
これはこのカーネルがどの機能を使えるようにしてあるかの一覧です。

このconfigがあってソースがあれば全く同じ物がビルド出来る事になるわけです。
（HTCのカーネルソースはここにありますねぇ）
そして例えばCONFIG_NFS_FSをyにしてやってビルドしたりするとAndroid端末から
ネットワークドライブのマウントが可能になったり、カスタムカーネル作りに足を突っ込む事になりますｗ

extract-ikconfigの良い所は自分が持っていない端末であってもboot.imgが入手できれば
configの内容を見られる事です。
ちなみに起動中の端末だとadbから

zcat /proc/config.gz

としても取得できます。

[Android] boot.imgを展開してみる その2

昨日の続きです。

boot.imgを展開するとこんなのが出て来ました。

boot.img-kernel.gz
boot.img-ramdisk
boot.img-ramdisk.cpio.gz

boot.imgの中にはboot.img-kernel.gzとboot.img-ramdisk.cpio.gzが入っていますが
昨日のunpack-bootimg.plがboot.img-ramdisk.cpio.gzを更に展開してくれた物がboot.img-ramdiskです。

このboot.img-kernel.gzがカーネルで
boot.img-ramdisk.cpio.gzは起動時にルートディレクトリに展開されるリソースです。
勘が良い人はboot.img-ramdiskの中身を弄ってやって、boot.imgに戻せば面白い事が出来るんじゃね？
と気付くと思いますが、それは又後の方で出て来ます。

昨日の記事の様にrecovery.imgを展開してみた人は中身が似通っている事に気付くはずです。
boot.imgはsystem.imgと組み合わせて起動する仕組みであるのに対し
recovery.imgはそれ単体で動作する仕組みになっています。

先に進む前にboot.imgを展開した時点で一部失われてしまった情報があります。
ちょっと退屈な話ですが、これを理解すればどんな機種のboot.imgでも触る事が出来る様になります。



これはHTC Sensationのboot.imgをバイナリエディタで開いてみた所ですが
（お勧めのバイナリエディタはStirlingです。ダウンロードはここから）
何やら意味有りげな文字列が並んでると思いませんか？
Andoroidをビルドする時にはmkbootimgと言うプログラムでboot.imgが作成されるのですが
こいつが「ANDROID!」の文字列から始まるboot headerを付与します
ここにboot headerが定義されたヘッダーがあります。コメントを読めば大体構成が理解できるのではないかと思います。

バイナリを読むのも面倒なので今回はboot headerの内容を表示するプログラムを書きました。
ここから取って下さい。パスワードは「android」
但し、cygwinが入っていないと動きません。
使い方は

./boot_img_hdr.exe boot.img

kernel_size : 3384784 kernel_addr : 0x48008000 ramdisk_size : 356028 ramdisk_addr : 0x49000000 second_size : 0 second_addr : 0x48f00000 tags_addr : 0x48000100 page_size : 2048 unused : 0x22c9b4 name : cmdline : console=ttyHSL0 androidboot.hardware=pyramid no_console_suspend=1

上記はHTC Sensationの結果ですが、ここで重要なのは「tags_addr」と「cmdline」です。
tags_addrはカーネルのphysical addrに当たる物でここのアドレスから起動が掛かります。
当然ですがここが間違っていると起動しません。
cmdlineは語意そのものですが、端末上だとadbで取得できる

cat /proc/cmdline

の一部です。
catの結果が長いのはbootloaderからのコマンドとboot.imgのコマンドが合わさったものになっているからです。

この二つがboot.imgを再作成する場合に必要となります。

[Android] boot.imgを展開してみる

さて、今回はAndroidのboot.imgを展開してみます。
俺はLinuxで作業していますが、WindowsでもCygwinを使うと同様のことが出来ます。

まずは、ここからunpack-bootimg.plを取得してきます。
boot.imgはClockworkModで取った物を使えば良いんですが
ついでに他の取得方法も書いておきますね。
busyboxがインストしてあることとbootバーティションのデバイス名を知っている事が条件です。
例えばHTC Sensationの場合はこんな感じ。
adbで

dd if=/dev/block/mmcblk0p20 of=/sdcard/boot.img

dd if=デバイス名 of=出力ファイル名

こんな感じですね。

この方法は単純なパーティションダンプなので、
ClockworkModで取得した物に比べてファイルサイズが大きくなります。
当然ですがhbootやsystemもこの方法でダンプできますし、
用途不明なパーティションの中身を調べるのにも使えます。

boot.imgとunpack-bootimg.plを同じディレクトリに置き、カレントディレクトリで以下の様に入力しますが
確かCygwinをディフォルトでインストしただけではcpioが入らなかった気がしますので
setup.exeを使ってパッケージを追加して下さいね。Utilsカテゴリーの中にあります。

./unpack-bootimg.pl boot.img

Cwdパッケージが無いと警告が出ますが気にしないで下さい。
中身が出ましたか?
recovery.imgも同様の方法で展開出来るので見比べてみると面白いですよ。

つづく…

[Android] コマンドプロンプトって使いにくくね？

今日はちょっと横道にそれた話です。

windowsでadbを使って作業をしていると、コマンドプロンプトって非常に使いにくいと思いませんか？
俺は説明上必要な時意外はCygwinというLinuxエミュレーターを使っています。
良くCygwinをお勧めすると馬鹿にされる事が多いですが、
Androidは弄りたいけどLinuxをインストするまでの事はしたくないと思っている人にとっては有用なツールだと思います。
Android関連のツール類にはPerlやShellスクリプトが多いのですが、これを入れて置けばwindowsでも使えるようになります。
今後の記事にはこの辺りの言語を使用した物が出て来ますので入れておくと良いかと思います。
以下、セットアップについて記載します。

先ずここからsetup.exeを取って来て実行します。



次へで進めて、Install from Internetを選択します。





ここのRoot DirectoryにはCygwinのルートディレクトリを入力します。
ここがLinuxで言う/になります。



Local Package DirectoryはCygwinの資源を保存しておくディレクトリです。
後の方で出てきますがインストするパッケージ毎にtarが保存されます。
実行環境とここでディスク容量は結構喰いますので注意してください。



学校や職場等、proxy経由でネットアクセスしている場合はここの設定を変えます。
普通はDirect ConnectionでOK。



ここではCygwinの取得元を選択します。
どこでも構いませんが場所によって配布されているバージョンが異なる場合があるので注意して下さい。



ここではインストするパッケージを選択します。
ディフォルトでは最低限必要なものだけが対象となっているので任意追加して下さい。



俺は既にインスト済みなのでちょっと表示が異なりますが、Newの欄にバージョンナンバーが表示されているのが対象となります。
また、setup.exeで後からパッケージを追加することも出来ます。

これでちょっと待っているとインストが完了します。
Cygwinの標準ターミナルを使っても良いのですが、俺はPoderosaを使っています。
これは職場でも使っているターミナルなのですが、telnetやsshも使えてCygwinにも繋げる優れものです。
タブ分割出来るので左がUNIXで右がCygwinみたいな感じで使っています。
インストする場合は ここ から取って来てください。



起動したら左上にCygwinマークがあるので、ここを押せば繋がります。



うーん。UNIXチックでとても良いですねぇ。

[Android] bootとrecovery

boot.imgとrecovery.imgは非常に似かよった構成をしています。
内容的にはカーネルとramdiskイメージ。

端末の起動がかかるとカーネルイメージがロードされ、ramdiskがルートディレクトリ上に展開されます。
そして、init.rcの内容によってシステムプロセスが順次立ち上がって行くわけですが
通常bootとrecoveryではここに記載されている内容が異なっています。
要は二種類の起動イメージが用意されていて、どちらから起動されるかによってモードが変わるわけです。

次回からこいつらの中身を見ていきますが、windowsだとちょっとした下準備が必要になります。

[Android] apkの中身を見てみる その3

昨日の続きです

・assets

アプリ用の外部プログラム等が入っている所。
入れる物に縛りは無いので設定ファイルなんかが入っている場合もあります。
ROM Managerの場合はbusyboxとかが入っていますね。

・libs

ROM Managerにこのディレクトリは存在しませんが
アプリ用のライブラリが入る場所です。
AndroidのアプリはJavaで作られていると書きましたが
高速化を図る為、Cで作られたライブラリが使用できます。

・smali

これもapkをzip解凍した時には無かったディレクトリですが
このアプリの肝、Javaのクラスファイルに当たるclasses.dex
を逆コンパイルしたソースが入っています。
Javaとアセンブラを足した様なsmaliという言語で出力されます。
又、こいつの事を「逆アセンブラする」と説明しているサイトが多々ありますが
classes.dexはマシン語じゃありませんし、出力もアセンブリコードではないので誤りです。
（でも、smaliの作者は「逆アセンブラ」と記載しているんですよねｗ）

このコードを弄ればアプリの改造が出来るのですが
smaliの言語仕様に関する情報が殆ど入手出来ないので
自力で解析する必要があります。
Javaが書けてアセンブラのレジスタの考えを知っていれば何とか解るかな？

ディレクトリをのぞくとa.smaliとか良く意味の分からないソースが大量にありますが
AndroidManifest.xmlに記載されていない内部的に使用するクラスは名前解決が出来ないので
こんないい加減なクラス名になってしまうんです。
規模の大きなプログラムは追っていくだけで大変なので余り触りたくないですね。

・apktool.yml

apktoolの処理結果が出力されるファイルっぽいですね。
展開時にフレームワークを使用したかどうかとかが載っています。


ここで話が出たのでフレームワークに関する事もちょっと記載しておきます。
このapktookはアプリだけじゃなくてsystem配下のapkも展開できるのですが
（apk + odexの構成になっているリソースの場合は当然ながらsmaliは出力されません）
物によってframework-res.apkの中身を参照している場合があります。
apktoolではこいつらを正常に展開する為にframework-res.apkを事前登録しておく事を
install-frameworkと表現しています。

端末のframework-res.apkを引っこ抜いて来て

apktool.bat if framework-res.apk

同様にHTC系のapk場合はcom.htc.resources.apkを参照している場合があります。

端末のframework-res.apkを引っこ抜いて来て

apktool.bat if com.htc.resources.apk

展開時にエラーになる場合は試してみると良いかも。


apktoolで展開したapkをリコンパイルする手順もさらっと記載しておきます。

apktool.bat b 出力apk名 元ネタディレクトリ名

これに電子署名を付ければOKですが、物によって上手く行かない場合もあります。
ここいら辺は他の詳しいサイトを見て下さい。

[Android] apkの中身を見てみる その2

日はapktoolを使ってapkの中身を見てみましょう。

先ずはapktool1.4.1.tar.bz2とapktool-install-windows-r04-brut1.tar.bz2と取って来ます。
このファイルはLinuxのアーカイブなので、tar,bzip2が解凍出来るアーカイバを使って下さい。
aapt.exe,apktool.bat,apktool.jarが出てくると思うので一緒の場所においてPATHを切ります。
後、javaはインストしてPATHが通っている事が前提です。

では、コマンドプロンプトで以下の様に入力します。

apktool.bat d com.koushikdutta.rommanager-1.apk

com.koushikdutta.rommanager-1というディレクトリが出来ましたか？
中身はこんな感じになっていると思います。

com.koushikdutta.rommanager-1 ┳ AndroidManifest.xml 　 ┣ apktool.yml 　 ┣ assets 　 ┣ res 　 ┗ smali

前回、zipで解凍したのと構成が違っているのに気付きましたか？
では、内容について説明していきます。

・AndroidManifest.xml

UIとプログラムの関連性等を記載したファイルで全てのアプリが持っています。
最初の方のmanifestタグにandroid:versionName属性がありますが、これがこのアプリのバージョンナンバーで
ここが変更されたものがマーケットに登録されるとアップデートが掛かる様になっています。
下の方のuses-sdkタグのandroid:minSdkVersion属性はこのアプリの最低動作OSバージョンを表しています。
ここでは4ですからAndroid 1.6ですね。ここのバージョンはAndroid SDKのEmuのバージョンと同じです。
minSdkVersion以下のスペックの端末でマーケットに繋いだ場合はフィルターが掛かり見えなくなります。
その下のuses-permissionはマーケットで表示されるアプリの権限が記載されています。
ここに権限の記載が無い場合はプログラム内で該当の機能を使おうとしても使用できません。

・res

このアプリで使用する画像や文言等のリソースが入っています。
drawableディレクトリには画像が入っていますね。
drawable-xxxは端末の解像度によって画像を使い分ける場合に使用します。余り使わないかな。

layoutディレクトリに入っているxmlはこのアプリのUIの定義です。一つのxmlが一つのUIに該当します。

valuesディレクトリにはこのアプリで使用する文言が入っています。
values-ja等は言語リージョンを切り替えた時に使用される文言です。
もし使っているリージョン用のファイルが無い場合はvalues内の文言が使われる事になります。
HTC Sensation等、日本で発売されていない端末でも日本語表記が可能なのはOSのapkの中に偶々values-jaがあるからです。
又、英語表記のアプリでも自分で翻訳した文章でvalues-jaを作ってやると日本語化出来ます。
大抵のアプリではarrays.xmlの中にセレクトボックスの選択肢が入っていて、その他はstrings.xmlに入っている構成になっていますが
作者が勝手にファイルを追加出来るのでアプリ毎に異なります。

xmlディレクトリには慣例的にアプリの設定画面のUI設定を入れます。

ここでapktoolで展開したresディレクトリにはvaluesが入っているのに、
zip解凍しただけの物には入っていない事に気付いた人はお目が高いです。
実はresources.arscの中にまとまって入っているんです。


長くなるのでつづく・・・

[Android] apkの中身を見てみる

今日はapkの中身を見てみようと言うお話です。

まずは題材を選びますが、多分みんな入れているであろうと言うことでRom managerにしますよ。
/data/appからcom.koushikdutta.rommanager-1.apkをPC上に引っこ抜いてきます。
余談ですがアプリには一意のIDが付いていると以前書きました。
Rom Managerの場合にはcom.koushikdutta.rommanagerとなります。
このIDは作者が勝手に付けるもので、多分かぶらないだろうなと言う考えのもと作ります。
普通はプログラムのjavaメインクラス名と同じものになります。

では中身を見てみますが実はapkはzipファイルです。まずは普通に解凍してみます。
AndroidManifest.xmlをテキストエディタ見てみると辛うじて読めそうだけど文字化けしていますねぇ。
中身を弄ろうとすると、ただ解凍しただけでは余り意味がありません。
でも、この状態も大切なのでどんなファイルがあるかを何となく覚えておいて下さいね。
次はapktoolを使ってファイルの中身を見ていきましょう。

[Android] systemディレクトリの構成

今日はsystemディレクトリの構成についてのお話です。

スマフォのsystem下は大体こんな感じになっていると思います。

system ┳ app
　　　 ┣ bin
　　　 ┣ etc
　　　 ┣ fonts
　　　 ┣ framework
　　　 ┣ lib
　　　 ┣ media
　　　 ┣ usr
　　　 ┗ xbin

この構成はLinuxを踏襲していて、内容物には暗黙のルールがあります。

・app

プリインストアプリが入っている場所です。
ここのアプリは「アプリケーションの管理」からアンインスト出来ません。
apkを消してやれば可。

・bin

C言語で作られた実行モジュールが入っている場所です。
ここに物を突っ込んだり書き換える場合は
パーミッションを755にしないと不具合がでます。

・etc

設定ファイルが入っている場所です。

・fonts

フォントが入っている場所です。

・framework

OSの核となるjavaプログラムが入っている場所です。

・lib

C言語で作られたライブラリが入っている場所です。
ここのリソースはbin,frameworkのプログラムが参照を行っています。

・media

OSで使用する動画、音声ファイル等が入っている場所です。

・usr

ここのディレクトリはLinuxでも明確な定義はなくて何でもありって感じです。
本来はOSに絡まないユーザー寄りのリソースを入れる所なのかな？
でもHP-UXだとほとんどのライブラリは/usr/libにあったりするし…
良く分かりませんな。
Androidだとハードキーのマッピング定義等が入っています。

・xbin

ここはextra binなのかな？
独自の実行プログラムを入れる場所なんだろうと思う。
なので自分で何か突っ込む時はいつもここにしています。
bin同様、パーミッションを755にします。


何か思ったより面白く無かったね。うん。

[Android] systemディレクトリの構成

今日はsystemディレクトリの構成についてのお話です。

スマフォのsystem下は大体こんな感じになっていると思います。

system ┳ app
　　　 ┣ bin
　　　 ┣ etc
　　　 ┣ fonts
　　　 ┣ framework
　　　 ┣ lib
　　　 ┣ media
　　　 ┣ usr
　　　 ┗ xbin

この構成はLinuxを踏襲していて、内容物には暗黙のルールがあります。

・app

プリインストアプリが入っている場所です。
ここのアプリは「アプリケーションの管理」からアンインスト出来ません。
apkを消してやれば可。

・bin

C言語で作られた実行モジュールが入っている場所です。
ここに物を突っ込んだり書き換える場合は
パーミッションを755にしないと不具合がでます。

・etc

設定ファイルが入っている場所です。

・fonts

フォントが入っている場所です。

・framework

OSの核となるjavaプログラムが入っている場所です。

・lib

C言語で作られたライブラリが入っている場所です。
ここのリソースはbin,frameworkのプログラムが参照を行っています。

・media

OSで使用する動画、音声ファイル等が入っている場所です。

・usr

ここのディレクトリはLinuxでも明確な定義はなくて何でもありって感じです。
本来はOSに絡まないユーザー寄りのリソースを入れる所なのかな？
でもHP-UXだとほとんどのライブラリは/usr/libにあったりするし…
良く分かりませんな。
Androidだとハードキーのマッピング定義等が入っています。

・xbin

ここはextra binなのかな？
独自の実行プログラムを入れる場所なんだろうと思う。
なので自分で何か突っ込む時はいつもここにしています。
bin同様、パーミッションを755にします。


何か思ったより面白く無かったね。うん。