手机实时提取SIM卡打电话的信令和声音-(三、安卓提权与特权应用Mock Bluetooth)

手机实时提取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应用提权

扯太多都是虚的，主要是通过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是一款蓝牙模拟软件，它能够帮助用户在没有实际蓝牙设备的情况下，模拟出蓝牙连接、数据传输等场景，以便进行软件开发、测试等相关工作。该软件由国内一家专注于移动开发工具的公司开发，具有简洁易用、功能丰富等特点。

Mock Bluetooth听名称其实也是虚拟蓝牙，，只是它跟上一种方案不同，它是使用软件模拟的方式，在SELinux安全系统中，创造一个受控的空间进行新蓝牙设备的创建。创建后也可以直接连接本手机蓝牙，连接后与正常的蓝牙通信无异。

我们尝试过寻找关于它的源码和其它历史信息，找不到。毕竟是商用版的软件，不开源也很正常。逆向工程也看不出太多的内容。只能说安装包，在Root的手机中，安装后试用了一下，使用和连接，觉得也还可以。

哪位读者或大佬，对这块有研究的可以补充一下信息，大家一起共同探讨和学习。

《mock bluetooth蓝牙模拟最新版下载v1.0.6》，此处是一个下载安装页面。有兴趣可以试试，安装和运行环境还挺苛刻的，一般的手机装了还用不了。仅供参考。

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

• 总结

挨了解锁BootLoader一记暴击之后，我们对这种需要解锁、需要Root后才能用的方案，敬而远之。怎么说呢，知识储备吧。至少方案和原理路线逐步清晰，而且对手机系统的改动也越来越小。慢慢来，继续往前的无人区探索，胜利的曙光已经能看得到了。

---

上一篇：手机实时提取SIM卡打电话的信令和声音-(二、Android提取声音经典案例)

下一篇：手机实时提取SIM卡打电话的信令和声音-(四、辅助外设与商用SIM通话方案)​​​​​​​