提问人：Merc 提问时间：3/21/2014 更新时间：6/4/2014 访问量：44905
在android中从adb shell手动挂载SD卡
Mount an SD card manually from adb shell in android
问：
我有一部安卓 4.1 手机（联想 820）。经过一些旨在对内部 SD 内存进行分区的更改（更改后，手机将不再安装外部 SD 卡。我擅长 Linux，但在今天之前我从未见过 Android shell。
我很想知道以下步骤：
- 获取代表 SD 卡的可用设备列表
- 手动挂载 SD 卡 -- mount 命令不会像它所说的那样工作 -- 你如何挂载东西？
can't read /etc/fstab - 在启动时安装SD卡
我的 /etc/system/vold.fstab 有：
dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-msdc.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-msdc.1/mmc_host
Mount 现在是：
rootfs on / type rootfs (ro,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/secure type tmpfs (rw,relatime,mode=700)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/emmc@android on /system type ext4 (ro,relatime,nobarrier,noauto_da_alloc,commit=1)
/emmc@usrdata on /data type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@cache on /cache type ext4 (rw,nosuid,nodev,noatime,nodiratime,discard,nobarrier,noauto_da_alloc)
/emmc@protect_f on /protect_f type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/emmc@protect_s on /protect_s type ext4 (rw,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
答：
15赞
Jarmez
6/4/2014
#1
我不敢相信 2 个月没有人回复你？哇。。。多么懈怠！
好吧，无论如何，我想我应该给你填写一些信息，并问一些问题。 1）. 您是否获得了root访问权限，或者您是否从发布映像/固件中拉取了系统vold？喜欢 Linux 超级用户权限吗？ 2）. 如果您拥有root访问权限/超级用户权限，您是如何获得的？我的意思是你用什么方法来获得root访问权限？是通过一些脚本/二进制文件和已知的漏洞吗？还是通过生根内核闪现的？ 我问的原因是，root访问不仅仅是大多数人所相信的root访问;有不同级别的root访问权限。例如，您可能在设备上拥有完全的root访问权限，但是当您想远程操作系统时，例如从您最喜欢的Linux发行版的命令行中，您可能会发现root访问权限并不是它的全部。如果您使用了漏洞而不是内核，那么很可能您只有系统级的root访问权限，并且ADB（android调试桥）到您的PC将面临各种消息，例如“访问被拒绝”，“无法获得超级用户权限”或“adb无法在生产版本中以root身份运行”或类似内容。 发生这种情况的原因是，与一些专门的开发人员内核不同，通过漏洞利用 root 不会使内核不安全。 我建议你做一些关于什么是不安全内核以及它是否适合你希望实现的目标的阅读。我之所以这么说，是因为在某些设备上，具有不安全的内核并不理想，因为它会触发一些不需要的系统标志（根据某些制造商的说法，有些是永久性的和不可逆的），并且用于对付开发人员，以不履行保修或作为为设备提供高级维修服务的资金的一种手段（无论您是开发人员是否希望取得一些突破性发现......是否造成设备损坏？哪个 sux）。我认为您的设备应该没问题...？但我不是 100% 确定，所以做一些研究。
如果你发现你不能运行一个不安全的内核，那不是世界末日，它只是需要更多的工作来获得你想要的东西，我稍后会用例子来详细说明。
您可能应该考虑的下一件事是，当您到达设备中/设备上想要的位置时，您希望做什么？你有没有想过那么远？如果是这样，您可能会意识到标准的 Android 控制台/shell 相当惨淡，并且设备不足，无法在 Linux 计算机上眨眼间完成您能够完成的所有伟大事情;这意味着您将需要一些支持工具，例如“busybox”以及其他一些工具，例如，如果您正在处理某些数据库，您可能需要 SQLite3，您可能需要实际的 bash 二进制文件来扩展您的 shell。您不仅要查看这些二进制文件，还要查看它们在系统上的位置以便于访问，否则您将厌倦在控制台中键入巨大的长路径以到达设备的某些区域，例如SD卡。使用Linux的符号链接会很熟悉，Android也不例外，只是Android的许多系统都使用类似容器的环境作为应用程序。在处理这个问题时，可能会有一些障碍需要克服，因为系统有安全检查，试图阻止不需要的第三方的入侵。这就是大多数开发人员知道他们（和您的）个人数据受到保护的原因，但是当这是您并且您想进入设备的这些区域时，您需要正确设置您的工具。大多数 Android 修补匠使用修改后的恢复映像（或自定义映像 - 与自定义内核概念没有太大区别），允许他们在离线时修改系统，主要通过带有嵌入式指令脚本、二进制文件和清单的简单 zip 文件（用于 Android 自定义恢复的研究签名和未签名 zip - 我不会详细介绍，但这很重要）。您基本上可以将所有工具打包到一个zip中，然后“闪存”，将组件安装到您需要的系统区域，并将相同的文件符号链接到其他各个位置。
现在让我们看一些例子 - 假设你有root访问权限，因为你在你的设备上使用了漏洞，但仍然有安全的内核注意：安全的内核=在你的系统default.prop文件中（在启动时生成，在大多数固件包中找不到或位于）。如果你想允许 adb 拥有 root 访问权限，您将需要更改该文件，特别是我上面提到的那一行。可能还有其他要求，因此您应该查看您的设备需要什么，例如，我目前正在修复的Galaxy Tab较旧，因此使用大容量存储而不是媒体传输协议，因此我需要告诉adb在与设备接合时保持连接打开和稳定（而不是超时和断开连接）;这恰好也是通过 default.prop 文件完成的。
当您要更改此文件时，困难就来了;大多数人对内核和 ramdisk 进行反编译，然后直接编辑，然后重新编译然后重新刷写到设备上，主要是因为 adb 目前显然没有 root 访问权限。您可以像这样从系统中拉取文件：ro.debugable=0
adb pull default.prop default.prop
（如果您的 PC 发行版环境路径上有 adb，那是）
这会带来直截了当的你，只是问题是当你想在改变它后把它放回去时，它可能相当困难。各种解决方案都是关于的，我听到很多将其推送到SD卡/emmc/storage/sdcard0/default.prop或/tmp/default.prop，然后要求您作为设备上的“超级用户”使用终端模拟器，脚本管理器或root资源管理器之类的东西将文件放回原位并赋予其正确的权限。
在具有安全内核的设备上键入 adb remount 将允许您以读写方式重新挂载整个系统，并且您可以随心所欲地执行操作。但是，如果没有安全感，您最终可能会做类似的事情
adb root
remount
或者，您最终可能会发现您的整个控制台都没有超级用户权限，因此您需要将 adb shell 放入设备 shell（它或您拥有超级用户权限的地方），然后执行您要尝试的命令。
adb shell
su
mount -o rw /system
remount /system
我最近发现，您可以通过 adb 控制台上的一行和单个返回键获得相同级别的访问，如下所示：
adb shell su -c mount -o rw,remount /system
这会将单字符串 adb shell -> superuser access -> pass command -> mount as read-write -> remount command -> 中的参数传递到系统分区。
如果您愿意，您可以使用上述命令从控制台获取超级用户权限，并将字符串回显到 default.prop 文件中，而无需反编译内核。
就我而言，我只是重复了几次相同的命令，并用相同的内容覆盖了default.prop，只是根据自己的喜好调整了特定变量，如下所示： 请注意，第一行仅使用 1 个>因此这有效地擦除或覆盖了 default.prop 文件，因此其余行也需要跟随。我使用 2 个>，就像 >> 一样，因为它附加到文件的下一行。
adb shell su -c echo ro.secure=1>default.prop
adb shell su -c echo ro.allow.mock.location=0>>default.prop
adb shell su -c echo ro.debuggable=1>>default.prop
adb shell su -c echo persist.sys.usb.config=mass_storage,adb>>default.prop
adb shell su -c echo persist.service.adb.enable=0>>default.prop
这对于 4 或 5 行代码来说是相当快速和有效的，但是当您重写具有许多行测试的大文件时，这是不切实际的。您可能希望在 bash 脚本中查看带有循环函数的 grep 之类的东西，以过滤大型文本/脚本/配置文件的特定行，但是对于此示例以及可能对于您的系统 vold 文件，这应该就足够了。
我认为这应该足以（请原谅双关语）为您提供足够的信息以使其变得危险:) 在这一点上，请确保您已经备份了设备，然后再弄乱系统。它们与 linux 非常相似，但它们也非常不同！注意这个警告，确保你立即备份你的EFS分区！！Efs包含设备IMEI号码，这是您真正不希望损坏或丢失的东西。我亲眼目睹了可能发生的事情;您甚至不需要意外调用 EFS 分区来破坏它......您只需要在调用错误分区的显式路径时出错，它就可以消除您的IMEI！
评论