search

AOSPAlliance / android-prepare-vendor

Set of scripts to automate AOSP compatible vendor blobs generation from factory images
25 stars 10 forks source link

Do we really need carrier binary blobs in "Full" configurations? #44

Open CaseyBakey opened 3 years ago

CaseyBakey commented 3 years ago

Hello there,

Since I'm digging a little into this project while trying to add "full" configurations for blueline/crosshatch and bonito/sargo for API-29, I stumbled upon some binary blobs that were already declared in previous API versions.

For example, I'm talking about:

    "system/priv-app/OemDmTrigger/OemDmTrigger.apk",
    "system/priv-app/SprintDM/SprintDM.apk",
    "system/priv-app/SprintHM/SprintHM.apk",
    "system/priv-app/VerizonAuthDialog/VerizonAuthDialog.apk"

and the corresponding permission files.

Being from Europe, I can't be less concerned about Verizon/Sprint.

After a quick look inside those apps (thanks to jadx), they all seem to be link to the same technology/protocol I didn't heard about before called OMA DM.

To be able to achieve this "management", the given permissions to these apps are pretty invasive imho.

I don't even know if it's really usefull/needed for a US Pixel owner to be able to use his device on those carriers.

I don't know what you're thinking about this, but I think we should get rid of them, or at least put them in a separate list that would only be included if a new apv argument (to determine) will be given.

Less attack surface, less unknown priviledged blob running on our phones.

Cheers.

P.S.: I'm already running my daily driver without those -> obviously no trouble so far.

sdh4 commented 3 years ago

I think they are necessary. I was not able too get my phone to work in a base configuration with Verizon. US providers are notoriously picky. See for example https://opendevelopment.verizonwireless.com/content/dam/opendevelopment/pdf/OpenAccessReq/Reqs-LTE_OTADM_Oct2018.pdf for information on the OMA DM requirements.

My AOSP 10 full configuration for Walleye https://github.com/sdh4/android-prepare-vendor/blob/10-sdh4/walleye/config.json works fine with Verizon in the US.

They could obviously be separated out into different config(s). I don't know enough about how they are used to understand how much they would contribute to attack surface. Are they even active unless a SIM from the corresponding carrier is inserted?

chirayudesai commented 3 years ago

See #28 - the vendor.xml mentioned there refers to some/all of these blobs, and is needed for additional functionality on certain carriers, such as VoLTE or Wi-Fi Calling.

@sdh4 are either of those working for you on Verizon?

sdh4 commented 3 years ago

VoLTE works no problem on Verizon with my full branch on Pixel 2 with my full branch mentioned above (still based on Android 10). Not sure about Wi-Fi Calling; I think Verizon generally programs phones to avoid it even when enabled, and that logic is probably still pulled in. I am not able to call over Wi-Fi in airplane mode. On Wed, 2020-11-11 at 16:01 -0800, Chirayu Desai wrote:

See #28 - the vendor.xml mentioned there refers to some/all of these blobs, and is needed for additional functionality on certain carriers, such as VoLTE or Wi-Fi Calling. @sdh4 are either of those working for you on Verizon?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.