hijack-ramdisk考案の経緯

10:57

前回の投稿でXperiaはユーザーコミュニティが小さいということを書きましたが、GXの延命で重宝しているhijack-ramdiskにしても突然考案されたわけではなく、その手法自体は他の端末で使われていたものが元になっています。

Bootstrapの手法

オリジナルを辿れば、アイデアの元はClockworkMod Recoveryの開発で有名なKoushが2010年にMotorola Droid X用に作成した"Bootstrap"でしょう。hijack-ramdiskはシェルスクリプトですが、Bootstrapはカーネルモジュール(訂正:ただのバイナリでした)として作られています。処理の内容はほとんど同じで、/systemをカスタムROMで書き換えてしまう点も同じです。

KoushのBootstrapを更に洗練させた手法が、Hashcodeの"Safestrap"です。Safestrapは単体のmodというよりはTWRPのフォークとなっていて、XZDualRecoveryのような形でシステム起動中にプロセスをフックしてリカバリを起動します。そこから内蔵ストレージ内にパーティションを作成することで擬似的なマルチブートを可能にしています。ROMの初期イメージが提供されないような復旧の難しい端末上で、/systemを書き換えることなく安全にカスタムROMを使える点が"Safe"ということなんですね。

Hashcodeは開発者として私が目指したい姿でもあります。彼はブートローダーがロックされた多くのMotorolaデバイス向けにSafestrapと専用のカスタムROMを作成していますし、近年はAmazonのKindle Fire HD/HDXにもSafestrapが使われていました。(もっともKindleはLittle Kernelブートローダーの脆弱性が見つかって以降はアンロック出来るようになりましたが)

不遇なXperia?

常々疑問に思っているのは、三星、LG、Motoなどの端末は割と堅めのセキュリティがある割に、(例えばGalaxyはカーネルモジュールも署名されていると聞きます)それを回避する手法が生み出される一方、Xperiaはブートローダーの欠陥など致命的な脆弱性が見つかってもなかなか革新的な進展がありません。これは、S1BootをはじめSomcの実装が堅牢なのか、単に解析できるだけの人材がコミュニティにいないのか、よく分からないところです。(現に私のような弱小しかhijack-ramdiskを活用していませんし、Xperiaにはもっと開発の余地があると思います。)

私もhijack-ramdiskを洗練させたいと思っているのですが、何も無いところから進展させるのは難しいですね。それこそやる気を出せばせめてHashcodeのSafestrapを移植できそうなものですが、それをする人がいないのが辛いところです。

<参考>



関連する記事

次の記事
« 前の投稿
前の記事
次の投稿 »

6 コメント

Write コメント
匿名
AUTHOR
2016年1月4日 1:25 delete

なるほど。154氏が旗揚げした今がある意味スタート地点みたいなもんですね。
海外ではあまり人気端末でもないのはSONYの戦略に落ち度があるからでしょうかね?初期の段階で周回遅れなスペックだったのが痛い所。
少々割高でもハイスペックであればコアなユーザーが目を付けますし。
海外で三星くらい売れていればもっと色々なdevに解析されて発展していたでしょう。

Reply
avatar
匿名
AUTHOR
2016年1月5日 9:32 delete

Hashcode氏はお世話になってます..Kindle Fire HDにCM13がこないものか...
それはさておきhijack-ramdiskもXperia SPというある程度売れたらしい端末で開発された手法なので人気と直結しているのかもしれないですね...

Reply
avatar
赤星
AUTHOR
2016年1月13日 2:26 delete

旗揚げというほど大したものでもないですが、やる気のある人間がやるしかない現状ですからね。
Xperiaにも優秀なdevは多くいるのですが、アメリカ展開が弱いのも開発者不足に繋がっているかも知れません。

Reply
avatar
赤星
AUTHOR
2016年1月13日 2:29 delete

Kindle Fireシリーズは性能の割にやたらと安かったので私もよくroot関係の進捗を見ていましたが、初期のお通夜状態からよく現状まで盛り上がったなと思います。

Reply
avatar
匿名
AUTHOR
2016年1月13日 5:42 delete

当方Xperia Z1のLocked用ROMをビルドしてみたのですが、hijack-ramdiskのファイル差し替えがいまいちつかめてません。
Zのhijack-ramdiskをベースとし、/system/hijack/ramdisk.cpioをCyanogenMod側由来のファイルにし、overlay内をkernel.sinから展開したファイルにしたのですがこれだけで良いのでしょうか。こちらでもファイルを眺めて起動できるように頑張りますが教えていただければ。
またビルド時にkernelを一箇所だけ弄ってしまったのでその影響があるのかもしれません。

赤星氏はどこでhijack-ramdisk関連の情報を仕入れたのですか?XDAのスレッドのレスを追っていたのでしょうか、気になります。

Reply
avatar
赤星
AUTHOR
2016年1月17日 1:52 delete

hijack-ramdiskについて何か具体的な説明のあるスレッドというのはありませんね。簡単なシェルスクリプトなので、私が内容を自分で読んで色々と処理を追加しているだけです。

overlay以下はデバッグがしやすいように便宜的に作ってあるので、ストックのramdiskを単純に配置すれば良いわけではないです。ramdiskの配置よりもhijack.sh内のアンマウント処理の方が大切ですし、ブートしないときのデバッグがもっとも大変とも言えます。こればかりは自分で読んで理解してもらうしかないですね。

カーネルも使っているソースのビルド番号によりますが、基本的に手を加えてはいけません。ワーニングを無視する程度なら構いませんが、全てAndroidソース側で対処します。

Reply
avatar