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

好吧无论如何我想我应该填写一些信息并提出一些问题.

1).您是否拥有root权限,或者是否从发布映像/固件中获取了系统vold？像Linux SuperUser权限？

2).如果您具有超级用户权限/超级用户权限,您是如何获得它的？我的意思是你用什么方法获得root访问权限？是通过一些脚本/二进制文件和已知的漏洞利用？或者它是通过root内核的方式闪现的？

我问的原因是root访问不仅仅是root访问权限,因为大多数人都会相信;有不同级别的root访问权限.例如,您可以作为设备上的用户具有完全root权限,但是当您想要远程操作系统时,请从您喜欢的Linux发行版的命令行说,然后您可能会发现根访问并非完全被解析为是.如果您使用的是漏洞利用而不是内核,则很可能您只有系统级别的root访问权限,并且PCB的ADB(android调试桥接器)将面临各种消息,例如“访问被拒绝”,“无法获得超级用户权限”或“adb不能在生产版本中以root身份运行”或类似的东西.

发生这种情况的原因是因为与某些专门的开发人员内核不同,root通过漏洞利用不会使内核不安全.

我建议你做一些关于不安全内核的内容,以及它是否适合你希望实现的内容.我之所以这么说是因为在某些具有不安全内核的设备上并不理想,因为它可以触发一些不需要的系统标志(根据某些制造商的说法,这些标志是永久的和不可逆转的)并且用于对付开发人员不尊重保修或作为提取手段为设备提供高级维修服务的资金(无论您的开发人员是否希望突破某些发现……都会对设备造成损害？是哪种？)我觉得你的设备应该没问题……？但我不是百分百肯定所以做一些研究.

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

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

让我们看看现在的一些例子 – 我们说你有root访问权限,因为你在你的设备上使用了漏洞而且安全内核仍然注意：在你的系统default.prop文件中安全内核= ro.debugable = 0(在启动时生成未找到或位于大多数固件包中).如果您想允许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中的参数 – >超级用户访问 – >传递命令 – >以读写方式挂载 – > remount命令 – >到系统分区.

如果您愿意,可以使用上述命令从控制台获取超级用户权限,并将字符串回显到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之类的内容来过滤大型text / script / config文件的特定行,但是对于此示例,可能对于系统vold文件,这应该足够了.

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