Yes, Android 14 still allows modification of system certificates
g1a55er.net
g1a55er.net
It's all been slowly cooking for a decade, yet people will still claim "but you can still do it with root, so it's as free as before!" (or some other ridiculously complicated workaround with lots of nasty side-effects)
These are tempting choices, but they go a lot further than, for example, requiring only modern TLS ciphersuites to be used to communicate with my servers. They dictate the state of your entire device, and no one app or company should have that power, unless you work for the company and they issue you the device -- but even then, modern MDM/MAM can and should sandbox company apps from the rest of the device.
Google has little choice but to provide them with the tools to detect root access.
Some of the entities that want it do have pull.
And while for years the alternatives have been almost nonexistent, we do have at least two now : PinePhone and Librem 5.
You have to use pretty shaky workarounds to trick them, and there is a known way to make those workarounds impossible.
Features though? Maybe I don't realize all the great things I'm missing out on since I've only ever used rooted phones since I got my first Android device many years ago.
As for apps, I've only heard of certain games (I don't play games on my phone) and banking apps (thankfully mine doesn't care, though I'd rather use a desktop web interface for financial stuff).
Yes, of course, you can do this, but let's not pretend there aren't trade offs.
Alternatively, you can use ADB + Frida to pull an APK from the device, inject a binary, and inject code at runtime using Javascript or Python. That's much easier for intercepting traffic than messing with certificate stores or eBPF ever was in my opinion.
Any quality documentation on how to do this would be great.
As a concept, Frida works by running a gadget on the phone (as root, or as part of an app) and a client on another device (or the same device, I suppose, if you're using a terminal emulator on Android).
To install the gadget, you either download the right binary and execute it on the phone as root, or use a tool like https://github.com/ksg97031/frida-gadget to inject the gadget into an APK.
Then, use Frida (https://frida.re/docs/Android) to connect to the gadget and load any script you want. There are a bunch of scripts that can be used to patch out certificate validation, or to exclusively use a certificate authority of your choice, or you can write your own.
You can download scripts and run them directly, or you can run Frida with a command line flag to open up a remote debugging port; you can connect to that port from the Chrome dev tools and get an interactive code execution prompt. From there, you can patch out Java methods, load native binaries, patch memory, whatever you want. It's a really powerful tool for debugging and reversing applications you don't have the source for.
Not much I can do with that data, other than sleep in comfort knowing that its the case.
There are plenty of pay2win games out there, but if the game doesn't tell you that paying will give you an unfair advantage /or what advantage you're getting, exactly) I'd consider that worth reporting on, especially if the game has a decently large following!
Are there some words in the parent comment that "pretend there aren't tradeoffs". Is it that he did not include a warning about "SafetyNet". What would this "pretending" look like.
Losing access to "a bunch of apps you may care about" seems to be dependent on an assumption: that the reader cares about certain unnamed apps. Yet we cannot even name these apps. We cannot know what apps a user cares about unless the user tells us. I know Android users that do not use any apps that rely on SafetyNet.
Nor do we know what device manufacturer the reader may be dealing with. It might be one where it's relatively easy to the computer owner to have root privileges.
Perhaps we can refrain from making assumptions about readers.
Yes. They quoted it! "you just need root". Especially the word just. That kind of phrasing implies that it's not flat-out impossible on many devices and that it doesn't break major functionality.
"I know users that don't use that feature" is praising with faint damnation.
Sent from my iPhone (after 13 years of using Android)
Anyone know why there is an aarch64 nocore but not an x86_64 nocore.
For a lot of users, "It's really hard to break" is a value-add. Every capacity the user has to modify permissions is an opportunity for an attacker to compromise a device. You can see an example of this in web browsers these days, where sites have to `log` a big scary "Don't paste anything someone tells you to paste into here" message into the built-in developer tools because no matter how many safety features get added to the browser security model, the dev tools can bypass them.
It is definitely important that the purchaser knows what kind of phone they're getting (whether it's easy or hard to crack open all the layers of its protection model), but "The phone's protection model is easily broken by the owner" as a universal absolute applied to all devices should be considered harmful.
Isn't installing your own OS on your general purpose computer a trivial out? Shall we likewise disable that ability on all general purpose computers?
We have to balance defending against both.
> Shall we likewise disable that ability
Not on all computers, no. But I should have the option of buying my grandmother one which is very, very hard for someone to convince her to give them admin rights.
You would build chains for millions of people so that granny will have to give scammers her money some less convenient way.
I'd rather not.
This just isn't how the universe works at all. We both grew up in the era roughly analogous to the early era of flight with 100 bad designs competing for most incompetent and are now moving into the an era of commercial jets and here you are arguing that planes wont make a difference in war.
If you build an ecosystem where essential services like logging into your work, watching netflix, and banking require you to use locked down devices in which the OEM could be forced to build ANY restriction into the device but mostly use it to keep you from trivialities in the US and Europe you wont notice you've built a tool suitable for any oppression nor will you notice until the frog is well boiled.
We have the bones of damn near total control in terms of difficult to root devices, remote attestation to ensure you actually are using such a device, AI to analyze data at scale. The difference between the tools we have now and 1984 is that the telescreen didn't sit in your pocket nor was Big Brother literally listening 100% of the time to 100% of the people.
We are describing a literal system you could roll out without inventing anything purely based on existing technology and if you too live in the US then we are doing so in a country that has at least a 1 in 3 chance of descending into a fascist state.
It's being worked on with web attestation.
If you want more than that, you can pay $99 for a real developer account and that will let you sign apps for up to a year. And that’s a sufficient barrier that Facebook can’t be like “you have to sign up for a dev account if you want to use Facebook!” and expect the average user to just blindly comply.
Cause that’s the problem with the EU approach, it works ok when it’s only the EU, but Facebook really wants to bypass those permissions (they’ve already bribed users to install dev credential builds that have full permissions, so they could datamine more effectively), and the moment they can lever open the app-review process with “third party app stores” is the moment the “doesn’t work on iOS, please sideload the native app” banner goes up on Facebook.com.
It doesn’t have to be financial but the only alternatives would be some kind of credential verification thing like looking at your LinkedIn or a college transcript or a GitHub account to validate that you’re actually a bona fide developer and not just grandma who got an iTunes gift card to install the spyware build (real example from Facebook).
https://techcrunch.com/2019/01/30/apple-bans-facebook-vpn/am...
They did. Over here, there are regular news articles and warnings from the government as yet more Android users get conned into installing fake banking app APKs that let attackers steal all their money. It’s always the same news article and the same warning – only Android users affected.
Elsewhere in this thread, people are saying that you can’t protect people from themselves… but Apple seem to be doing a good job of it. When was the last time a side-loaded IPA stole bank credentials from iPhone users?
I personally think that Apple should be a little more open. Having some sort of developer mode with plenty of warnings would be better. But the idea that Apple’s approach doesn’t improve security in meaningful ways to the average user is wishful thinking based more in ideology than what actually happens in the real world.
Precisely my point. I think there are benefits to both locked-down devices and open devices, and both are desirable. If Android is transitioning towards more constrained-by-default, (a) that's smart given it's working so well for their largest competition, and (b) it opens the field wider for the truly open-stack phones to gain users. Win-win.
Microsoft couldn't break into this market for billions of dollars. Open phones breaking in because android becomes more locked down is a complete fantasy.
What do you do when oppressive governments insist that your now constrained environment implement some of their suggestions with the alternative to compliance being your local yokels go to prison and the alternative to having local yokels is that you aren't allowed to sell there?
None of this category of openness matters if the government turns to oppression.
Like clockwork, here’s today’s article:
> The victims would then contact the “sellers” via the platforms or messaging app WhatsApp. Following this, the “sellers” would send a uniform resource locator (URL) link for the victims to download an Android Package Kit (APK) file, an app created for Android’s operating system.
https://www.channelnewsasia.com/singapore/android-malware-sc...
> DBS, UOB become latest banks to restrict access if unverified apps are found on customers' phones
> They are the latest banks in Singapore to do so – after OCBC and Citibank – amid a spate of malware scams targeting users of Android devices.
> DBS said on Tuesday (Sep 26) that its new anti-malware tool for Android phones seeks to prevent scammers from fraudulently logging into customers’ accounts by restricting app access if it detects potential risks.
> “For now, it appears (that) scam vulnerability by malware is a major issue and therefore, it is appropriate to strike the balance in favour of protection for now. If this changes over time, then we may be willing to revisit the situation,” he said.
https://www.channelnewsasia.com/singapore/dbs-uob-anti-scam-...
> The elderly man, who wanted to be known only as Mr Loh, lost about $70,000 to scammers who siphoned money from his DBS and POSB credit card and bank accounts after infecting his Android phone with malware.
> The seller texted Mr Loh on WhatsApp and instructed him through voice messages to download a third-party app called Grab&Go on his phone.
https://www.straitstimes.com/singapore/74-year-old-man-loses...
The moment you allow users to add custom root certs ad blocker apps are going to ask users to add one for "advanced" network level ad blocking. You can't win with this crap. Nobody considers themselves a "not advanced" user so no amount of warning will ever work. Have you ever tried doing something, saw some warning that said this was for advanced users in your way to do the thing, and stopped? Me neither.
That doesn't seem all that much work. Hardening things like that should be a dedicated job, but of course it doesn't "create value" so it's mostly left to rot until it's a source of bad PR.
"It's really hard to break" should not be conducive to the dumbing down of the populace. Enabling power users is therefore more desirable.
And importantly, the two do not have to be mutually exclusive.
To be clear, I think our right to have a smartphone we control is an absolute. It's extremely important. I would march on the street to protect that right. But I'm equally protective of my right to have a smartphone I cannot control no matter what button I press. I'm glad for devices like the iPhone where the manufacturer works damn hard to make sure that it's always under the manufacturer's control.
I havent needed it on recent androids due to WFH and spending more time on my laptop, but back when I was flying more for work, I was much more into my phone.
Cant remember if it was my motorolla or nexus, but I felt like I had a full fledged laptop in my pocket back then.
Meanwhile, one of the straws that broke the camels back for Windows was the insane difficulty/impossibility of remove bloatware/malware that comes preinstalled with windows 11. In 2023, its mind boggling to think you have easier access to modify a cellphone OS than a desktop OS.
Now I just open a tab to my phone's IP address and benefit from the big screen and full sized keyboard while still having exactly the tools I'm used to having elsewhere. When I get home and want to resume work on beefier hardware, I just push from my phone, pull from my desktop, and I'm just where I left off, except now with more resources.
You have to be a bit austere about your tool choices to make the similarity happen (sorry VSCode), but it feels like a bit of a superpower just the same.
EDIT: thanks for people clarifying that pinning is done by Apps and not by IOS.
It's a good feature for security (stalkerware remains a huge problem) but it does suck from a reverse engineering standpoint.
Android has two certificate stores (the user store and the system store). The user store can be altered through the method you linked. The system store used to be part of the system image (you could always disable certificates, of course) and will now be moved to an APEX location that Google can update (to prevent the Let's Encrypt issue in the future).
To alter the system store, you need root access. At the moment it's just a matter of dropping a file with the right name and encoding at /etc/system/cacerts (through Magisk style overlays, or by modifying the system image) but that will change soon.
Not rhetorical questions.
Some apps do certificate pinning, which basically only validates certificates against a specific certificate authority and completely defeats any system certificate store.
You can MitM these apps by injecting code to bypass their restrictions. The eBPF methid linked above works, or you can use Frida in root or rootless mode to inject a variety of existing scripts to defeat certificate validation. This is a lot more involved than installing a certificate authority, but it'll work if you want to reverse an app.
The system store, located in /system/etc/cacerts, is baked into the system image and can't be altered without root. The user store, located under /data, can be updated from the phone's settings.
The system store is now the default store all apps use to validate certificates, unless they pack their own certificate authorities. Many apps doing certificate pinning will do that as well, which prevents them from being MitM'd without injecting code into them.
The cross signed CA certificate expired, so that solution stopped working. This meant that every app that connects to sites with LE certificates ran into HTTPS validation issues.
For browsers and other apps that opt into the user certificate store, the solution was simple: download the new Let's Encrypt CA and import it into the user store.
However, the system store, which all apps default to, couldn't be altered, because they were part of the ROM. That meant that every app that chose not to opt into the user-provided certificate store broke on Android 7 once the cross sign certificate authority certificate expired.
Many app developers don't know about these stores (or, let's be honest, about the details of HTTPS) and other apps explicitly chose not to opt in. Before the expiration of LE, the user store was used almost exclusively for MitM attacks; some by nation states like Kazakhstan, some by people reverse engineering apps, others by stalkerware. There are apps that have to work with MitM interception for certain businesses (for example, because of regulations regarding secrets) but those will usually be aware of the issue and provide an opt-in if they want to keep that customer.
That's why Google opted to make the user store opt-in in the first place. This broke the workflow of people like me, who run their own internal CA, against better judgement, for stuff like home lab servers.
So, in short: a security measure combined with manufacturers dropping support for their phones after ridiculously short amounts of time meant that Android 7 users couldn't access tons of apps and websites.
The MITM attacks by manipulating the keys was a godsend
Invaluable debugging tools
We need some new tact, pro-user AND pro-security - those are often seen as in conflict with each other.
or can you add your own for every domain or something?