【ROM焼き】au IS01 root2　〜わたくし達も未来へ〜

http://www.724685.com/raku/index.htm

>>950
あぶない、アップデートの自動設定がオンになってた。

>>951
すみません。お手数おかけします。

>>951 さらに自己レス
よく考えたら、unyaffsでの展開結果オーナー情報などが欠落しますね^^;
再構築してる人はどうしてるのでしょうか？
調べてみます…。

つまり意地悪アップデートだったってこと？

OSバージョンアップはしません。
自分でやろうとするユーザーも妨害します。

ろくでもねえ！

>>954
http://hotfile.com/dl/89762758/19a0e8d/system.zip.html
結果をお知らせいただければ幸いです。

>>957
ありがとうございます。早速試してみます。

>>956
脆弱性を潰すのはメーカーとしては当然の動きだからなー。仕方ない。
この脆弱性は有用なツールを騙った文鎮化アプリを作成する余地を与えるものだし。
IS01ユーザーの8割はまともな使い方をしてないだろうから関係ないだろうが、
残りの2割は何のためらいもなくそういったツールを入れて起動してしまう。

まぁ、このスレにいる香具師らは絶対にアップデートを適用しないってのが必須条件ってこった。

EZweb.ne.jpなんて使ってないから関係ないな

>>957
微妙にサイズが大きいようですね。
error writing system_rw: No space left on device
とでて止まってしまいます。System領域は256MBですから、
それを若干オーバーしているようです。

お手数おかけしました。

>>961
　了解しました。

いま、mkyaffs2image で再構成したところ100MBほど小さくなりました。
yaffs2 のイメージの仕組みと dump_image , flash_image , mkyaffs2image の
関係がイマイチ分かっていないので、本スレ識者なら分かるかもですね。

私の方の最終目標はとりあえず、flash_image で焼ける system.img です。

>>962
それ、せっかくなので試させてもらってもいいですか？
ここまでいじったのであれば、なに入れても一緒ですから・・・

あーあー、未来へのトンネル爆破されたな

だったらまた掘ればいいだろ！？

何にも手伝えんので次スレ建てといたよー

【ROM焼き】au IS01 root3　〜穴は塞がれた。だが〜
http://hibari.2ch.net/test/read.cgi/smartphone/1292486295/

>>963
unyaffs で展開した system.img を
mkyaffs2image -f system system_rebuild.img
で再構築しただけのモノです。
再度、unyaffs で展開する事は出来ました。

http://hotfile.com/dl/89780979/4d5c852/system_rebuild.img.zip.html
とりあえず、ファイルは抽出できますので、問題は固め方と焼き方だと思います。。

>>927
文鎮化のリスクを最小化するために、recovery_kit v1.30を使ってroot化する際の、
現時点で最も確実な手順をまとめていただけませんか？

>>968
甘え過ぎ
少しは自分で努力しようよ

>>968
素直にわかりませんって言えや
その程度もわからん状態じゃやめたほうがよさげ

>>967
ありがとうございます。
今何故かダウンロード出来ないので、後ほど試させていただきます。

こちらでもリビルドしてみました。が、結果はダメでした。
私の使ったmkyaffs2imageには-fオプションはなかったので、
違うバージョンでしょうか。

mkyaffs2imageで作ったイメージをubinizeしてから書いたらどうだろう。

>>972
それは気づきませんでした。試してみます。

>>972
systemとuserdataはubiにはなっていませんので、やらないほうが良いかと思います・・
ubiファイルシステムが使われているのは、boot, recovery, iplの3領域のみです。

>>967
試してみましたが、残念ながらダメでした。
ISロゴが１回フラッシュするので、bootは正常に働いているものと思われますが・・・

>>974
goroh_kunさんありがとうございます。

system領域の書き込みにもコツがいるとは・・・・

ところで、一回ばらして組んだだけでなんで１００MBも差が出てくるんだろう・・・

エラー処理で甘い所があったので修正です。今回はソースを分離しました。
なぜか片方だけzipだとアップできなかったので7zにしてあります。中々アップ出来ず疲れた…

ttp://uploading.com/files/faff9af4/rachael-0.0.beta.2.7z/
ttp://uploading.com/files/m64ma8db/rachael-0.0.beta.2-src.zip/

パスはdeckardです。

system を書き込むにしても、
カーネルレベルでトレースしないと駄目ですかね…。

auスマートフォン「IS01」にBCCの内容が受信者に開示される不具合、
NTTドコモの「LYNX（SH-10B）」でも同様に発生
http://gigazine.net/news/20101216_kddi_is01_bcc/

これって、Ver2.2ならOKというより、アプリの問題ですね。
怖い。。

unyaffs 展開後のファイルの中身を見てみましたが途中で切れてますね。
CHUNK_SIZE と SPARE_SIZE がデフォルトと違うのでしょうか。
もう少し、見てみます。

大きなファイルを確認しましたが着信aacやmp4の類は展開されてました。
編集した、build.prop が途中から切れてましたので、
その辺をバイナリで確認しようと思います。

昔調査したasroot2について、再度調査してみた。
前は使えないと判断されたけど、再度試したところHTC Hero用のasroot2がIS01でも使えることが判明した。
ログはこちら。
http://codepad.org/Mj1UlYex

goroh_kun氏のdump_imageで素のIS01のsystem_rwをダンプしたところ、
256MBのimgが取れました。

試験機に書き戻そうとしたところ、

mtd: ECC errors (0 soft, 1 hard) at 0x00000000
　　〜
mtd: ECC errors (0 soft, 6 hard) at 0x0ffe0000
（しばらくして）
#

と出ます。これ、ハードエラーですかね？
ちなみに2度目はエラーなしで行きます。起動はできませんでした。

flash_imageにもなにか細工が必要なのかな・・・

>>951 のunyaffs ですが、ファイルが断片化していると正常に展開出来ない
みたいです。unyaffs のソースコードと、手元の dump_image をバイナリ
エディタで開いて追跡した結果です。
編集状態によるでしょうが、手元では/system/app/CapabilityService.apk が
build.prop の連続と見なされ展開できていません。

展開、再構築で100MBほど減ったのはそのような理由と考えられます。

工場出荷時のような断片化していないバイナリは展開できるのでは
ないでしょうか。

自前で/system構築する際と同様、tar で固めてバックアップするのが
よさそうです。

system に image で書けるにはほど遠い…。。。
一端、eraseして、ファイルシステムを再構築すれば良いのかもですが…。

>>983で得られたｉｍｇを、以下の方法で書き戻したところ、
mount_systemで弾かれなくなりました。

busybox cat /dev/zero > /dev/mtd/mtd10
busybox cat mtd10.img > /dev/mtd/mtd10

相変わらず起動はできませんが、一歩前進といったところでしょうか。

>>982
Pipeのアレ、前にカーネル逆アセして確認したけど対策されて無さそうだったので
動かないという報告が不思議だった。
これってカーネル空間で任意のコード実行だから、module_disable無効化できると思う。
01.00.10でも動くといいね。

>>987
insmod+ -f

>>988
言葉足らずでした。

goroh_kun氏の見つけた穴が塞がれるとinit.rcでmodule_disableが有効化されて
insmodが出来なくなる。
その場合に備えて別の方法があれば良いなと。
カーネル空間のメモリ書き換えが出来れば良いので、これが代替策として使えるかと。

NULLにデータをマップする必要があるので、別の方法でrootに権限昇格して、mmap_min_addrを0にする必要がある。
あと、何回かやらないと成功しない。

どうやら誤報っぽいです。
au公式のカーネルに戻したら、HTC Heroのasroot2が動かなくなりました。
カーネルを逆アセンブルして調査する必要がありそうです。

生のIS01を入手してきました。

早速、dump_image_staticでsystemとsystem_rwをダンプしたところ、
サイズが異なりました。

system : 276824064 byte
system_rw : 268435456 byte

この違いはなんでしょう・・・
ちなみにsystemはサイズオーバーでflash_image出来ません。

>>991 の件ですが、調査した結果、原因が分かりました。
pipe関連のexploitは、/proc/<pid>/fd以下にあるパイプへのリンクを参照します。
アクセスする際、proc_fd_access_allowed()で権限があるかどうかチェックされます。
チェックにはptrace_may_access()が使用されていて、これがLSMに引っかかり、アクセスができません。
別のアプローチがあるかもしれませんが、それについては調査中です。

しかし、arege_master氏のinsmod+があるので、これ以上の調査は不要かもしれません。

>>992
system と system_rw のサイズの違いは oob 領域の有無になります。
goroh_kun の dump_image では system、cache、userdata パーティションのみ
mtd_read_raw で、それ以外は mtd_read_data で読み取っています。

oobにあるデータは2048バイト毎にある64バイトの spare データです。
mkyaffs2image において、
-s <size> set the spare (NAND OOB) size. default: 64
で指定する部分が system には含まれています。

私も system 書き用のIS01を用意しましたので、実体験に基づく報告が
できるかとおもいます。（次からは次スレに書きます。）

>>994
自分の使っているmkyaffs2imageにはオプション指定がないので、
使っているバージョンかソースが違う可能性がありそうです。

ネットからバイナリを拾ってきたのですが、自分でビルドしたほうが良さそうですね。

次スレ立ってた
ttp://hibari.2ch.net/test/read.cgi/smartphone/1292486295/

んじゃ、埋め立てますか。

崩せ！

シャープの牙城を！

だが、塞ぐ！（ｷﾘｯ

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。