memo:Xperiaのkernelのdisassemble
flashtoolでftfを作る過程でできます。kernel_ほにゃらら.sin
(ftfがすでにある場合は、7-Zipでばらせば中に入ってます)
root取得済みなら端末のbootパーティションをdumpしてもいいかな？
2. kernel.sinからのzImageの取り出し
DooMLoRD氏のunpack-kernelsin.plでzImage と ramdiskに分割。
3. zImageからImageへの変換
zImageは自己展開型で、解凍ルーチン+gz圧縮されたkernel imageになっている。
バイナリエディタ等で解凍ルーチン部分を削って、gunzipで展開する。
(gzipのmagicは、0x1f8bなのでそれを検索して、それ以前を削る)
4. disassemble
arm-linux-androideabi-objdump -D -b binary -m arm --adjust-vma=0xc0008000 piggy > kernel_asm.txt
こんな感じでおｋ。
かなり巨大になるので、シンボル情報から調べたい関数のアドレスがわかっていれば、
--start-address=開始アドレス --stop-address=終了アドレス
指定を付ければよい。
CWM for Xperia GX/SX ver0.8のころ
やっとこ情報処理技術者試験終わってひとだんらく。
ちがう意味でもおわた感ですがｗ
100%rootが終わって、次はCWMだーなのですが、
ごろーさんも私もとりあえず、
kenjidctさんのCWM Recovery for 2012 Xperiaが
動かないものかーとinit周り書き換えたりしてがんばったり
したわけだったのですが、動かず。
私はずーとinit起動でがんばってたわけですが、
recovery起動直後に画面まっくら、
後続のscriptが起動してきてるから
どうもrecoveryがこけてるらしい。
ごろーさんの方は直接起動方式に切り替えて、
一瞬画面が出るがダメ、みたいな状況。
で、ごろーさんは自前でCWMビルド→
CWM for GX ver0.5リリース
よっしゃ、SXでどや？と思ったら…、
複眼でござる。。。
ごろーさんはSX持ってないので、わかりまへんと…。
うーむ、むむむー。
ということで、自分でやってみることに。
とりあえず、CM-icsブランチベースでやってみる。
まずね、バージョンがわからなかったデス！
icsのCWMてバージョンいくつよー？
て、Makefileに直書きでしたわｗ
奇しくもごろーさんのver0.5のとCWMのバージョンは6.0.1.2で一緒でした。
まーもともとは、CWMをベースにメニューアプリ書こうと思って、
DLしてたソースだったので、まー偶然です。
で、最低限のconfigだけしてビルドしてみる。
まー、とりあえず、recoveryはできた。そんな感じ。
もともとramdiskはごろーさんのをそのまま使うつもりだったので、
recovery本体作れる程度にしか環境を整えていないというｗ
で、ver0.5のrecoveryを差し替えて動かしてみたのだがー、
まっくら！
かわってねーｗ
このころは、adbもつながらなけりゃ、straceしかけてもからっぽーみたいな。
recovery本体が落ちてるってこと以外わからん！ｋｓｇ！
で、この辺からやっとソースをちゃんと読み始める。
まー画面もログも全然出てなかったので初期化処理周りを中心に
printfでデバッグログを仕込むという原始的手法でがんばる。
どうも「set_active_framebuffer」で落ちてるっぽい？
ソースをよく見る…、？！
！！！
「vi.yres_virtual = vi.yres * PIXEL_SIZE;」
なん…、だと？
これでは画面バッファを４面分とるではないかー、２面しかつこてへんのに～。
で、これの前にframebufferの初期パラメータとるだけのプログラム書いて、
CWM起動前の状態がどうか確認してたのですが…、
少なくともSXでは３面分しかバッファ持ってないのです。
そらあかん、落ちてとーぜんやーということで直します。
→「vi.yres_virtual = vi.yres * 2;」
なんというかやるせない修正です。ただのバグ対。。。
いやまーいーんだけど、動いたしー。ふぅ。
でまーこの後なんやかんやCWMのconfig周りをソースを読み読みおべんきょして
ごろーさんのver0.5とほぼ同じかたちにもってくわけす（フォント以外ｗ）
configまわりをやる前に、ごろーさんが元にしたソースが
CMのNozomi(Xperia S)向けのソースをベースにしてたことがわかって、
CMのgithub見てみたらばアレですね。
android_device_sony_nozomi は、android_device_sony_fuji-commonも見ないとダメなんですが、
BoardConfigCommon.mkを見ると、
「TARGET_RECOVERY_PIXEL_FORMAT := "BGRX_8888"」
？！
！！！
BGRX_8888なんてないよ！
RGBX_8888やRGBA_8888ならあるけど！
結局これじゃ、RGB_565 になってるよ～。
ぇー、じゃー色が一見正しいのはなんでだーおもたら、
gr_flip_32なんて色変換ルーチンわざわざ追加してある！
なんというかもう。。。ふぅ。
で、これを書いてる現在CMのgithub見てみると既に
android_device_sony_blue-commonがありますなー、
今からやるならこれベースでいいですよ。たぶん。見てないけど。
fuji-commonの「TARGET_RECOVERY_PIXEL_FORMAT := "BGRX_8888"」が
bule-commonでは「TARGET_RECOVERY_PIXEL_FORMAT := "RGBX_8888"」に
直ってrecovery.cもvi.yres_virtual = vi.yres * 2;になってるのは確認しましたがｗ
あと、決定キーがcameraキーに割り振られてますなー。
まーTX向けだろーからそれでいいのか。
で、話はもどって、出来上がったrecoveryをごろーさんに渡して
GXでの動作確認を依頼してたのですが、
ごろーさんのノートPCの環境移行やらなんやらで
結構放置プレーされてましたよ？
そしてごろーさんの手でver0.8とさくっと公開されたのでした。
まーあれです。なぜver0.8なのかはー、
ごろーさんの気分だったデス。
で、ごろーさんからひとこと
「フォントちーさい」
次回に続く。
CWM前夜
rayを使い始めてから、やはりこのぐらいコンパクトな端末がよい！と思っていて、
この夏にやっとコンパクトモデル(SX)が来る！ということで待ち構えていました。
ただまぁ、日本発のモデルだし、GXはともかくSXはglobalモデルキャンセルされちゃったし、
ガラケー機能満載だし、bootloader unlockもないだろうし、
カスタムは当然、日本人ユーザが中心かつ制約が多い中、にならざるをえないだろう、と。
で、まー、ちっとは役に立てるかも知らんし、制限環境下で色々やるのは、
結構楽しいもんだ、とゆーわけで、珍しく…というか初めて発売日に購入して
触り始めたのでした。
root化については、直前にgoroh_kunさんが公開されていた手法が使えるはずだー
とは思っていましたが、goro_tsukiyamaさんがさっそくGXでやって
バッチを公開してくれていたので、それはさくっと使わせてもらいました。
ただまぁ、/systemをrwマウントするとrebootしてしまうという問題があったわけですが。
んでその頃はみなreboot問題に頭を悩ませていました。
大方の予想はkernelでなんかやってるのだろうと。
kernelソースが出てこないと手が出せないんじゃないかと、そんな感じでした。
で、実際kernelソースが出てきて見てみると…、
ぇーと、なんにもしてないね？
いや、全部みたわけじゃないけども、とりあえずシステムコールのmountはふつーだ。
システムコールをフックしてる気配もない。じゃーなによ？
どれか監視用のプロセスがいるわけ？
そういえば、そもそも、rwでremountして即時再起動するわけじゃなかったしな、
というか、その隙がなければ/systemにsuとかつっこめないわけで…。
んじゃー、ふつーに/proc/mounts(実際には/proc/[pid]/mounts)を
一定間隔で監視してるわけだ？
ということで、確かファイルシステム監視するコマンドあったべーと思って
探したらばありましたinotifywaitコマンド。しかもandroid用バイナリが落ちてました。
ラッキーってことで、/proc配下をリカーシブで監視したところ、
いましたよ、/system/bin/ricがっ！
で、まー、init中で起動されていて自動再起動されるので、ramddiskを書き換えられない以上、
ricを無害なものに差し替えるしかないってことで、1時間sleepするスクリプトに差し替えた
わけです。
というわけで、やったこと自体は大したことではないです。
こういうのは大抵、予測と検証の繰り返しでして、
まー、たまたま割りと安易な方法で見つけてしまった。そんなもんです。
で、リブート問題が解決できたので、次はCWMだねーってことで、次回に続きます。