TL; DR:这是一个关于可移植,面向开发人员的生根过程的最终步骤的问题,该步骤适用于所有Android机器。它不基于任何漏洞利用-作为开发人员,我们在法律和道德上都可以对自己的机器进行操作。如果我得到了答案并设法在Debian中使用chroot,我将撰写一篇简洁的博客文章,为所有希望root访问其平板电脑的同胞开发者详细介绍该过程的所有步骤-不想信任可疑来源“一键式root”对他们的机器(僵尸网络成员?)知道什么......唯一的依赖关系将是机器的内核源(制造商有义务提供)和引导分区映像( boot.img),这是制造商提供的无线更新中99%的时间,或者可以作为独立的可刷新映像单独下载。我在新的Android平板电脑上的空闲时间。

我几乎完全成功-创建了一个面向开发人员的可移植流程,以实现在Android 5.0.2平板电脑上的扎根。

但是还缺少一件事-我无法执行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,



然后我更改了initrd图像/default.prop包含:ro.secure=0ro.debuggable=1
由于制造商的initrd.img缺少它,我还从https://android.googlesource.com/platform/system/extras/+/master/su/编译了su.c并将结果放置/sbin/su下的二进制文件,确保将其设置为SUID根目录(chmod 04755 /sbin/su)。

之后,如先前文章第2集所述,我打包了新内核和新initrd,并从自己的映像启动:

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


我现在已经实现了根:

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%确信自己是root-不仅是因为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格式化的第二分区。

我也无法chroot到我可爱的debootstrap -ed Debian: br />是因为SELinux吗?

我不知道-我是新来的(非常w-一个星期大)到SELinux。我以为,当您进入睡眠状态(getenforce报告为“宽松”)时,它就不再干扰...

显然,我错了。沿着兔子洞往下走,我们又去了...

是因为我的过程上下文吗?

还记得id返回了...“ uid = 0(root)gid = 0(root)... context = u:r:shell:s0“

我可以更改该上下文吗?作为root和所有人,我可以离开shell吗?如果是的话,转到什么地方?

第一个问题的答案是runcon:但是,什么环境允许我使用mountchroot

在我的主机上阅读了有关SELinux的更多信息后,我在/sepolicy的根目录上解析了initrd.img文件: >
root@K01E_2:/ # chroot /data/debian/ /bin/bash                             
chroot() fail
Operation not permitted


好,有很多可能性!特别是那个kernel似乎很有希望:

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


该死的。 />任何建议最欢迎...

#1 楼



不是SELinux-那是一场疯狂的追赶(getenforce返回“ Permissive”意味着SELinux确实不在图中)。 >
罪魁祸首-在内核源代码中添加了许多printk以跟踪chrootmount的故障之后-原来是功能。更具体地说,Android的“功能范围集”-您可以通过manman 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 :-)

哦,“ Root checker”也起作用-我剪断了“ su.c”,因此平板电脑中的每个人都可以成为root:

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;
  //}


现在它可以正常工作了,我必须使其正常工作-即仅允许我的termuxTerminal Emulator用户调用suchroot,而不要让所有人及其祖母进入:-)

评论


这个根方法不是需要能够刷新自己的内核吗?为此,需要解锁的引导程序。在这一点上,您最好只是闪过一个自定义恢复并以此方式获得root权限。

–1110101001
2015年10月3日在22:05

@ 1110101001对于引导程序:显然,是的。对于自定义恢复:我的平板电脑还没有这样的东西-我现在可以创建一个,尽管;-)

– ttsiodras
2015年10月4日,9:53

@ 1110101001:还有一件事-您说“具有闪存功能”-我还没有将启动映像刷新到平板电脑,我只是从它启动:fastboot boot my.img。我相信生根社区将其称为拴系生根:-)当然,如果愿意,我可以闪一下。

– ttsiodras
2015年10月4日在10:24