重要な要約:これは、すべてのAndroidデバイスで動作する移植可能な開発者中心のルーティングプロセスの最後のステップに関する質問です。これは搾取に基づくものではありません。これは開発者として、私たちが自分のコンピュータに対して法的、倫理的に許可されていることです。答えを得てDebianでchrootを管理すると、タブレットへのルートアクセスを望み、疑わしいソース「One」を信頼したくないすべての開発者のために、このプロセスのすべてのステップを詳しく説明する簡潔なブログ投稿を投稿します。 「keyroot」が自分のコンピュータ(ボットネットメンバー?)にどのような影響を与えるのか、神は知っていますが…唯一の依存関係は、そのコンピュータのカーネルソース(メーカーが法的に提供する義務がある)とブートパーティションイメージ(boot.img
)です。 %の場合、シチュエーションメーカーが提供するワイヤレスアップデートに含まれているか、スタンドアロンのフラッシュ対応イメージとして個別にダウンロードできます。
1週間が過ぎ、私は新しいAndroidタブレットの仕事にすべての自由時間を費やしました。
私はほぼ完全に成功しました。 Android 5.0.2 タブレットをルーティングするための移植可能な開発者中心のプロセスを作成します。
しかし、1つ欠落しています。 chrootはできません。 (私はdebootstrap
-ed Debianを実行する必要があります!)
今まで何をしたのか
- まず、タブレットのカーネルソース(製造元から提供)に小さなパッチを作成してから、独自のカーネルをコンパイルしました。変更の確認を無効にしました。SELINUX強制モード。具体的には...
存在するsecurity/selinux/selinuxfs.c
:
...
if (new_value != selinux_enforcing) {
/* Commented out by ttsiodras.
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
*/
audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
"enforcing=%d old_enforcing=%d auid=%u ses=%u",
new_value, selinux_enforcing,
次に、次のものを
/default.prop
含めるようにinitrdイメージを変更しました。ro.secure=0
ro.debuggable=1
メーカー
initrd.img
に欠けているのでsu.c
コンパイルもしました。https://android.googlesource.com/platform/system/extras/+/master/su/生成されたバイナリを下に配置します/sbin
。 SUIDルート()に設定されていることを確認してくださいchmod 04755 /sbin/su
。
その後、説明したように、新しいカーネルと新しいinitrdをパッケージ化しました。過去の投稿の2番目のエピソードで- 私のイメージから起動します。
adb reboot boot-loader ; fastboot boot myboot.img
だからあなたはルートですか?
はい、最初は成功したようです。
$ adb shell
shell@K01E_2:/ $ id
uid=2000(shell) gid=2000(shell) groups=1004(input),1007(log),1011(adb),
1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),
3003(inet),3006(net_bw_stats)
context=u:r:shell:s0
shell@K01E_2:/ $ ls -l /sbin/su /sbin/_su
-rwxr-xr-x root root 131 2015-10-03 10:44 su
-rwsr-xr-x root root 9420 2015-10-03 01:31 _su
(the _su is the binary I compiled, set to SUID root, and "su" is
a script I wrote to tell "su" to add me to all these groups...)
shell@K01E_2:/ $ cat /sbin/su
#!/system/bin/sh
export PATH=/system/bin:$PATH
exec /sbin/_su 0,0,1000,1028,2000,2001,1004,1007,1011,1015,\
1028,3001,3002,3003,3006
これでrootアクセス権があります。
shell@K01E_2:/ $ su
root@K01E_2:/ # id
uid=0(root) gid=0(root)
groups=1000(system),1004(input),1007(log),1011(adb),
1015(sdcard_rw),1028(sdcard_r),1028(sdcard_r),2000(shell),2001(cache),
3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)
context=u:r:shell:s0
私はルートだと100%確信しています。単にid
そう言ったからではなく、一般的なプロセスでは絶対にできないこともできるからです。
root@K01E_2:/ # ls -l /dev/block/platform/msm_sdcc.1/by-name/boot
lrwxrwxrwx root root 2015-10-03 10:47 boot -> /dev/block/mmcblk0p16
root@K01E_2:/ # dd if=/dev/block/mmcblk0p16 of=/dev/null bs=1M
16+0 records in
16+0 records out
16777216 bytes transferred in 0.569 secs (29485441 bytes/sec)
さて、いよいよタブレットで生のパーティションを読み取れるようになりました!
SELinuxは実際に「down、dog」モードになっています。
root@K01E_2:/ # getenforce
Permissive
しかしそこにはまだ私ができないこと:
root@K01E_2:/ # mkdir /my_mnt
root@K01E_2:/ # mount -t ext4 /dev/block/mmcblk1p2 /my_mnt
mount: Operation not permitted
つまり、外部SDカードのEXT4-fs形式の2番目のパーティションをマウントできません。
debootstrap
私も私の素敵なDebianにルートを変更することはできません:
root@K01E_2:/ # chroot /data/debian/ /bin/bash
chroot() fail
Operation not permitted
SELinuxのせいですか?
わかりません。私はSELinuxを初めて使用します(とても新しいです。使用してから1週間しかありません)。私の考えでは、あなたがそれを眠らせると(getenforce
「許し」と見て)、もはや邪魔しないようです...
明らかに私は間違っていた。私たちはまたウサギの洞窟に落ちました...
私のプロセスコンテキストが原因かもしれませんか?
返すことを忘れないでくださいid
... "uid=0(root) gid=0(root)...コンテキスト=u:r:シェル:s0」
この背景を変更できますか?ルートとして出発できますかshell
?それでは、何を選ぶべきですか?
最初の質問に対する答えは次のとおりですruncon
。
shell@K01E_2:/ $ runcon u:r:debuggerd:s0 /sbin/su
root@K01E_2:/ # id
uid=0(root) gid=0(root)... context=u:r:debuggerd:s0
わかりましたが、どのような背景が私がmount
そうすることを可能にしますかchroot
?
SELinuxの詳細を読んでください。ホストに戻り、/sepolicy
ルートディレクトリのファイルを解析しましたinitrd.img
。
linuxbox$ $ sesearch -A sepolicy | grep chroot
allow init_shell init_shell : capability { chown sys_chroot ...
allow init init : capability { chown dac_read_search sys_chroot ...
allow kernel kernel : capability { chown dac_override sys_chroot ...
allow asus-dbug-d asus-dbug-d : capability { chown sys_chroot ...
...
まあ、可能性はたくさんあります!特にkernel
有望に見えるものは次のとおりです。
shell@K01E_2:/ $ runcon u:r:kernel:s0 /sbin/su
root@K01E_2:/ # id
uid=0(root) gid=0(root)... context=u:r:kernel:s0
root@K01E_2:/ # chroot /data/debian/ /bin/bash
chroot() fail
Operation not permitted
くそー。
誰が私を止めていますかchroot
?
どんな提案でも歓迎します...
答え1
私がchrootingすることを誰がブロックしていますか?
これはSELinuxではありません。これは不気味な追撃戦です(getenforce
「Permissive」に戻ることは、SELinuxが実際にもはや絵にないことを意味します)。
犯人は - 失敗をprintk
追跡するためにカーネルのソースコードにかなりの量を追加した後 - 次のようなことが判明しました。chroot
mount
能力。より具体的に言えば、Androidの「能力境界セット」です。これに関するすべての内容はman
()で読むことができますman 7 capabilities
。以前は見てみようとしたことがないことを認めます。日常のUNIXタスクではこれに依存していますが、わかりません。 ..Linuxボックスで直接試してみてください。
$ getfattr -d -m - /sbin/ping
getfattr: Removing leading '/' from absolute path names
# file: sbin/ping
security.capability=0s......
願いより? PingはもはやSUIDルートではありません。情報を使用します。ファイルシステムの拡張属性に保存生のソケット層へのアクセス権があることに注意してください(したがって、ICMP操作、つまりIPレベルで実行できます)。
とにかく、私は「私の能力を放棄すること」を中断した私の核心の外科的ポイントである - 間違いなく不快な「すべて行進するようにしておく」方法で - 次のように外れました( security/commoncap.c
)。
static long cap_prctl_drop(struct cred *new, unsigned long cap)
{
if (!capable(CAP_SETPCAP))
return -EPERM;
if (!cap_valid(cap))
return -EINVAL;
// ttsiodras: come in, everyone, the water's fine!
//cap_lower(new->cap_bset, cap);
return 0;
}
これは、機能が決して失われないことを意味します。実際には非常に安全な構成です:-)
$ adb shell
shell@K01E_2:/ $ su
root@K01E_2:/ # chroot /data/debian/ /bin/bash
root@localhost:/# export PATH=/bin:/sbin:/usr/bin:/usr/sbin:\
/usr/local/bin:$PATH
root@localhost:/# cat /etc/issue
Debian GNU/Linux 8 \n \l
こんにちは私の素敵なDebian :-)
ああ、そして「ルートチェッカー」も動作します。私のタブレットの誰もがルートになるように「su.c」を切り取りました。
int main(int argc, char **argv)
{
struct passwd *pw;
uid_t uid, myuid;
gid_t gid, gids[50];
/* Until we have something better, only root and shell can use su. */
myuid = getuid();
//
// ttsiodras - Oh no, you don't :-)
//
//if (myuid != AID_ROOT && myuid != AID_SHELL) {
// fprintf(stderr,"su: uid %d not allowed to su\n", myuid);
// return 1;
//}
これでうまくいったので、うまくいくはずです。つまり、すべての人と祖母は含まれておらず、私とユーザーだけがtermux
電話Terminal Emulator
できるようにする必要su
があります。 :-)chroot