手機實時提取SIM卡打電話的信令和聲音-(三、安卓提權與特權應用Mock Bluetooth)

Android中的應用，理論上來說都是平等的，即：如果我發現手機上有某個功能，那么按理來講，我開發一個新App，我也能夠具有獲得這個功能的能力。

嗯，理論上確實是這樣子，而且確實好像也沒錯。就比如“系統級”應用，你要是對應用做如下兩個步驟，你也是系統級應用：

1. Manifest中，加上android:sharedUserId="android.uid.system"
2. 找到你要安裝進去的手機的目標系統的platform密鑰來重新給apk文件簽名。

多簡單，分三步就可以把大象裝進冰箱了。同理，我發現手機上有某個功能，我只需要將自己的應用的shareUserId配得跟它的一樣，然后用跟它一樣的密鑰進行簽名，我們就可以在同一個手機中獲得跟它一模一樣的能力。是不是很簡單？這就是Android的魅力。

但是這套理論，對于開發者、特別是應用開發者來講，就是屁話。

我們一個普通應用，上哪找別人的密鑰？我也想讓思聰哥哥帶我發財，那人家愿意帶嘛？那個system_id也是扯，我不是專用的app的情況下誰會用系統的簽名？其它品牌的手機就放棄了？

為什么會有這樣的情況呢？我不動簽名、不動userid，能不能獲得同樣的能力呢？一般很難，這些關卡基本都是人為的，即這些能力的制作者它為了避免功能被別人濫用，它把判斷和封鎖，默認寫進了framework、provider等公開或非公開的入口中，只允許自己用。

但是Android確實是個好東西，我們不使用這種標準方法，從它的啟動原理入手，照樣可以有一些途徑獲得遠比正常途徑要高的等級和權限，某些可能會涉及ADB、可能會涉及廣播或其它應用，而且隨著Android版本的迭代，這些方式或者說預留的入口可能會逐步的關閉，也有可能會開出新的接口。這里面比較經典的應該要數拼多多，提權方式相當的靈活。值得業界內借鑒和學習。

Android應用在進行組件化、插件化的過程中，很多時候也是借鑒這些方式和方法，包括諸如對象路由、Activity界面欺騙、應用保活、hook鉤子等都與這些預留接口息息相關。

很多時候我們做非Root的普通應用，需要一定程度的提權的能力。正常情況來說，在高版本Android中，提權的目的，與App運行中彈出的授權框，目的或者說結果上是基本類似的。很多時候做應用，都是在提權/降權-彈框的抉擇中做權衡，即：如果一個功能它需要一定權限才能用，但它并沒有暴露到請求授權的區域，那我們就需要提權才能用；但下一個Android版本它公開出來了，請求授權后，允許了就能用，那就不再需要提權、普通應用就可以使用。

所以，隨著市場存量手機的Android版本的增多，品牌和型號的機器增多，應用開發者的適配，其實挺麻煩的，特別是我們本項目這種，想要去動傳統GSM電話的核心功能來說，常規方法需要適配的面，更加復雜。

扯太多都是虛的，主要是通過app_process 來進行的。安卓自帶的App也是通過這個來啟動的，這就給予我們動手分析的操作入口。詳情可參考下面兩篇文章，這些作者都是人才，每一個初學者階段的和實踐過的朋友，都可以借鑒借鑒它們的思想。如下：

《使用 app_process 來調用高權限 API》這篇是對提權的概覽式敘述，有幾點可能需要著重的關注：

1. SELinux：這個是雙系統當中，相當牛逼的一個用法，現在很多小米/Oppo/Vivo手機出廠就帶有雙系統，只是平時我們沒有用上。而且這個對我們本篇章分析的【Mock Bluetooth】的邏輯分析有幫助。
2. 繞過 context：這個是常規操作，而且是app_process所特有的能力。

感興趣的讀者可自行查閱。

https://haruue.moe/blog/2017/08/30/call-privileged-api-with-app-process/

《那些年Android黑科技②:欺騙的藝術》，這個作者的全系列文章，都值得看一看。列舉的案例都非常的經典，值得借鑒和學習。

https://www.jianshu.com/p/2ad105f54d07

經過前文的敘述和脈絡梳理，我們發現，要想實現預期的【手機實時提取SIM卡打電話的信令和聲音】，存在以下幾個核心的內容：

1. RIL框架中確實可以提取或攔截信令，但無法操作聲音。
2. 聲音部分的邏輯，主要依賴【Android 音頻策略】。
3. Android音頻策略中，常用的輸入輸出設備有HDMI，聽筒，揚聲器，3.5mm圓孔耳機，USB耳機，藍牙耳機等。
4. 想要Root或刷自定義的ROM固件，解鎖BootLoader是大問題。

我們針對輸入輸出的音頻設備進行逐個分析，發現：

1. HDMI口，大部分手機都不預留此物理接口，實現此功能的都是通過USB轉換。
2. 聽筒/揚聲器，就是我們此次提取和攔截的目標。
3. 3.5mm圓孔耳機，傳輸的是模擬音頻信號，可以用來充電、接電話、傳數據，理論上，這個口可以利用起來實現本文的目標。但有部分新手機已取消3.5mm圓孔耳機接口。
4. USB耳機，同3.5mm圓孔耳機，使用專用設備插入可實現本文的目標。
5. 藍牙耳機，藍牙接口有標準的HF協議和HFP協議，擴展性良好。

因此，從這個角度來看，若不動手機的操作系統和專用硬件，直接可實現我們需求的音頻通道有：HDMI、USB耳機、藍牙耳機。

其它幾個通道中，聽筒/揚聲器的聲音需要調整操作系統，類似“小愛通話”。3.5mm圓孔耳機默認傳不了手機號碼，需要專用定制設備做數據的調制/解調。

于是，我們就選取了適配性最廣的藍牙耳機方案來舉例，下面這兩個做法，都是基于藍牙方案中，模擬一個新的藍牙設備，讓它跟手機自帶的藍牙進行連接，然后讀取/寫入藍牙數據的方式。

那么理論上，HDMI、USB耳機也應該會有相對應的方法，模擬一個新設備，然后去連接手機自帶的HDMI、USB耳機設備。實現軟件和手機系統之間的數據通信。

注意：這兩種方式都需要在解鎖BootLoader之后，才能做進一步操作。

《Android7/10/11 系統實現虛擬藍牙與APP通訊》，這篇文章，應該算是最簡潔的方案，什么RIL架構、什么Android 音頻策略，統統不需要改。只需要簡單改幾個frameworks和packages/apps的文件，一下子就搞定了需求目標，堪稱最簡潔有效的方案。有點類似力大磚飛，世界上飛行最快的人造物體是被核爆轟上天的井蓋。

當然它也有幾個缺點：

1. 占用了手機藍牙，手機通話是默認會從藍牙通道播出。
2. 改動了framework，也就意味著要重新燒錄ROM固件。而且是每次修改都需要更新ROM。

有興趣的讀者可以對照著進行使用，看看通話時的反饋和音質效果。

https://blog.csdn.net/CGTAIHYQ/article/details/124864049

Mock Bluetooth是一款藍牙模擬軟件，它能夠幫助用戶在沒有實際藍牙設備的情況下，模擬出藍牙連接、數據傳輸等場景，以便進行軟件開發、測試等相關工作。該軟件由國內一家專注于移動開發工具的公司開發，具有簡潔易用、功能豐富等特點。

Mock Bluetooth聽名稱其實也是虛擬藍牙，，只是它跟上一種方案不同，它是使用軟件模擬的方式，在SELinux安全系統中，創造一個受控的空間進行新藍牙設備的創建。創建后也可以直接連接本手機藍牙，連接后與正常的藍牙通信無異。

我們嘗試過尋找關于它的源碼和其它歷史信息，找不到。畢竟是商用版的軟件，不開源也很正常。逆向工程也看不出太多的內容。只能說安裝包，在Root的手機中，安裝后試用了一下，使用和連接，覺得也還可以。

哪位讀者或大佬，對這塊有研究的可以補充一下信息，大家一起共同探討和學習。

《mock bluetooth藍牙模擬最新版下載v1.0.6》，此處是一個下載安裝頁面。有興趣可以試試，安裝和運行環境還挺苛刻的，一般的手機裝了還用不了。僅供參考。

https://www.cr173.com/soft/1568897.html

挨了解鎖BootLoader一記暴擊之后，我們對這種需要解鎖、需要Root后才能用的方案，敬而遠之。怎么說呢，知識儲備吧。至少方案和原理路線逐步清晰，而且對手機系統的改動也越來越小。慢慢來，繼續往前的無人區探索，勝利的曙光已經能看得到了。