Android手机Root授权原理细节全解析


首先关于Root的方式,这里不做详解,可以有很多漏洞,比如利用uid溢出后归为0,得到Root权限,然后操作文件系统等。
 
手机Root后,最重要的是,给手机安装了su程序和superuser apk。 su一般被安装在/system/xbin 或者 /system/bin 下面,su文件的权限如下:
 
# ls su -l
ls su -l
-rwsr-sr-x    1 root     root         26336 Aug  1  2008 su
 
这里可以看到,su的Owner和Group分别为Root,Root。 Other用户具有exeute权限,另外,su设置了suid和sgid,这个非常重要,后面会详述,这个使得Su进程可以提升自身的EUID。
 
我们这里以RootExplorer为例,看是如何申请和提升权限的:
 
首先,ps一下,可以看到root explorer的信息,这里第一列是UID,更加准确的,应该是EUID。
app_73    1143  103   301620 39944 ffffffff 400194c4 S com.speedsoftware.rootexp
lorer
 
这里可以看到,Root Explorer的EUID=10073(App Base是从10000开始的)
 
然后,Root Explorer通过Runtime方式,使用shell 命令行运行了“su”, 所以,会有一个Root Explorer启动的sh:
 
app_73    1159  1143  764    376   c003e454 4001cf94 S /system/bin/sh
 
default情况下,进程的UID是继承的,这里sh的PPID是1143,说明是RootExplorer启动的。
 
RootExplorer通过类似下面的代码运行“su”:
p = Runtime.getRuntime().exec("su");   

所以,1159  PID的sh会启动su,这里需要注意的是,su进程的Real UID是10073,因为继承自parent,但是,其EUID却提升为了ROOT,这就是由于SUID被设置的原因。 由于su进程的EUID是ROOT,所以导致了su可以做很多高权限的事情。

su会通过:

sprintf(sysCmd, "am start -a Android.intent.action.MAIN -n com.koushikdutta.superuser/com.koushikdutta.superuser.SuperuserRequestActivity --ei uid %d --ei pid %d > /dev/null", g_puid, ppid);
  if (system(sysCmd))
   return executionFailure("am.");

启动SuperUser Request Activity来询问用户是否授权当前应用,如果否的话,则su将return 结束, 否则su会继续运行。

得到用户许可后(通过sqlite和SuperUser Request Activity交流用户许可),su会将自己的Real UID也设置为ROOT:

 if(setgid(0) || setuid(0))
  return permissionDenied();

由于su的EUID是ROOT,所以su有权限执行以上代码,执行完后su进程的Real UID,effective UID都变成了ROOT。 这里为什么要同时提升Real UID的权限,后面会说明。

然后,su会启动一个额外的sh来运行用户的指令:

char *exec_args[argc + 1];
 exec_args[argc] = NULL;
 exec_args[0] = "sh";
 int i;
 for (i = 1; i < argc; i++)
 {
  exec_args[i] = argv[i];

 }
 execv("/system/bin/sh", exec_args);
 return executionFailure("sh");


 这里非常关键的代码是execv! 这里没有使用fork,而是直接使用execv,这将导致不会创建新的进程运行sh image,而是直接在当前su的进程空间load并执行sh image。 所以,return executionFailure("sh"); 正常情况下是永远不会被执行的,执行完execv后,就开始直接sh的代码了。

  • 1
  • 2
  • 下一页

相关内容