從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訪問權限，因為你在你的設備上使用了漏洞，但是安全內核仍然需要注意： ro.debugable=0 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！