从android中的adb shell手动挂载SD卡

Question

我有一个Android 4.1手机(联想820).经过一些旨在对内部SD ram进行分区的更改(更改后,手机将不再安装外部 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)

Answer 1

我不敢相信2个月内没有人回复你？哇...多么懈怠!

好吧无论如何我想我应该填写一些信息并提出一些问题.1).您是否拥有root权限,或者是否从发布映像/固件中获取了系统vold？喜欢Linux超级用户权限？2).如果您具有root访问权限/超级用户权限,您是如何获得它的？我的意思是你用什么方法获得root访问权限？是通过一些脚本/二进制文件和已知的漏洞利用？或者它是通过root内核的方式闪现的？我问的原因是root访问不仅仅是root访问权限,因为大多数人都会相信; 有不同级别的root访问权限.例如,您可能拥有设备上用户的完全root访问权限,但是当您想要远程操作系统时,请从您喜欢的Linux发行版的命令行说,然后您可能会发现根访问并非完全被破解为是.如果您使用的是漏洞利用而不是内核,那么很可能您只有系统级别的root访问权限,并且PCB的ADB(android调试桥接器)将面临各种消息,例如"访问被拒绝","无法获得超级用户权限"或"adb不能在生产版本中以root身份运行"或类似的东西.发生这种情况的原因是因为与一些专门的开发人员内核不同,root通过漏洞利用不会使内核不安全.我建议你做一些关于不安全内核的内容,以及它是否适合你希望实现的内容.我之所以这么说是因为在某些设备上有一个不安全的内核并不理想,因为它可以触发一些不需要的系统标志(根据一些制造商的说法,这些标志是永久的和不可逆转的)并且用于对付开发人员不尊重保修或作为提取手段为设备提供高级维修服务的资金(无论您的开发人员是否希望突破发现......都会对设备造成损害？是sux).我认为你的设备应该没问题......？但我不是百分百肯定所以做一些研究.

如果你发现你不能运行一个不安全的内核,它不是世界末日,只需要更多的工作来获得你想要的东西,我将在稍后详细说明.

接下来您应该考虑的是当您到达设备所需的位置时,您希望做什么？你觉得那么远吗？如果是这样的话,你可能会意识到标准的Android控制台/外壳是相当惨淡和不适合的工具,可以做你在Linux计算机上一眨眼就能完成的所有伟大的事情; 这意味着您将需要一些支持工具,如"busybox"以及可能还有其他一些支持工具,例如,如果您正在处理某些数据库,您可能需要sqlite3,您可能需要实际的bash二进制文件来扩展您的贝壳有点.您还希望不仅可以查看这些二进制文件,还可以查看它们应该位于系统中的哪个位置以方便访问,否则您将厌倦在控制台中键入巨大的长路径以到达设备的某些区域喜欢你的SD卡.你会熟悉使用过Linux的符号链接,而Android只是Android的很多系统都使用像环境一样的应用程序.处理此问题时,可能会遇到一些障碍需要克服,因为系统已进行安全检查以尝试阻止不受欢迎的第三方入侵.这就是让大多数开发人员知道他们(和你的)个人数据受到保护的安全保障,但是当你想要进入设备的这些区域时,你需要正确设置工具.大多数Android修补程序使用修改后的恢复映像(或自定义的恢复映像 - 与自定义内核概念不太相似),允许它们在脱机时通过大多数带有嵌入式指令脚本,二进制和一个清单(研究签名和未签名的拉链为Android自定义恢复 - 我不会详细介绍,但它很重要).您实际上可以将所有工具打包到一个zip中,然后"闪存"将组件安装到您需要的系统区域中,并将相同的文件符号链接到其他各个位置.

让我们看看现在的一些例子 - 我们说你有root访问权限,因为你在你的设备上使用了漏洞而且安全内核仍然注意:secure kernel = ro.debugable=0在你的系统default.prop文件中(在启动时生成但未找到或位于大多数固件包).如果您想允许adb具有root访问权限,则需要更改该文件,特别是上面提到的行.可能还有其他要求,所以你应该看看你的设备需要什么,例如我正在修复的Galaxy Tab现在更旧,所以使用大容量存储而不是媒体传输协议,所以我需要告诉adb保持连接开放和稳定(与设备啮合时,不要超时和断开); 这恰好也可以通过default.prop文件完成.当您想要更改此文件时遇到困难; 大多数人反编译内核和ramdisk并直接编辑它并重新编译然后重新刷新到设备主要是因为adb目前显然没有root访问权限.您可以像这样从系统中提取文件:

adb pull default.prop default.prop

(多数民众赞成在您的PC发行环境路径上有adb)

这将带给你直率,只有问题是当你想要在改变它之后把它放回去可能相当困难.关于各种解决方案,我听到很多将它推送到SDcard /emmc/storage/sdcard0/default.prop或/tmp/default.prop,然后要求你使用终端模拟器,脚本管理器等设备上的"超级用户"或root explorer将文件放回原位并为其提供正确的权限.

在具有安全内核的设备上键入adb remount将允许您将整个系统重新安装为读写,您可以随意执行.如果不安全,你可能最终会做类似的事情

adb root
remount

或者您可能最终发现整个控制台没有超级用户权限,所以您需要将shell adb到设备shell(它或者您具有超级用户权限),然后执行您想要尝试的命令.

adb shell
su
mount -o rw /system
remount /system

我最近发现,您可以通过adb控制台和单一返回键获得相同级别的访问权限,如下所示:

adb shell su -c mount -o rw,remount /system

这将参数传递给单字符串adb shell - >超级用户访问 - >传递命令 - > mount as read-write - > remount命令 - >到系统分区.

如果您愿意,可以使用上述命令从控制台获取超级用户权限,并将字符串回显到default.prop文件,而无需反编译内核.

在我的情况下,我只是重复相同的命令几次,并用相同的内容覆盖default.prop只调整特定的变量,如下所示:注意第一行只使用1>所以这有效地擦除或覆盖default.prop文件,因此其余的行也需要遵循.我使用2> like >>因为这会附加到文件的以下行.

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之类的东西来过滤大型text/script/config文件的特定行,但是对于此示例,可能对于您的系统vold文件,这应该足够了.

我认为这应该足够(原谅双关语)ARM你有足够的信息是危险的:)请注意,在你弄乱系统之前,请确保你的设备有备份.它们与linux非常相似,但它们也非常不同!注意这个警告,请确保你直接放弃你的EFS分区!Efs包含设备IMEI号,这是你真的不想损坏或丢失的东西.我亲眼看到了可能发生的事情; 你甚至不需要意外地调用EFS分区来打破它....你只需要调用错误分区的显式路径就会出错,它可以消除你的IMEI!