There are ways to bypass any of these restrictions imposed by the Android system, even if they were real. Android ships with eBPF, so you just need root.
"Just" is doing a lot of work there. Getting root isn't always possible or easy, depending on your device manufacturer. And if you do manage to get root, your phone will likely stop passing SafetyNet, and you'll lose access to a bunch of apps that you may care about. SafetyNet can be spoofed in some situations, but not all, and even when spoofing does work, it all seems very brittle to me.
Yes, of course, you can do this, but let's not pretend there aren't trade offs.
Yeah. Android has become as hostile as Apple devices due to hardware remote attestation. Might as well buy an iPhone at this point. Only reason I didn't is I discovered the existence of Termux which turned into something of an Android killer app for me. Who knows what Google's gonna kill next though? Termux is already incompatible with the official store due to system call restrictions. Maybe it'll be straight up impossible to run it in a future version of Android.
I bought an iPhone a year ago for this exact reason. Both are user-hostile platforms now, so I might as well pick one that respects my attention more and treats me more acceptably. In addition, it looks like a near-future version of iOS will allow sideloading, which would make iOS an overall better mobile OS than Android.
Sent from my iPhone (after 13 years of using Android)
In the context of "changes to Android 14", "just" is right. Android has required root access for modifying random apps since before Android 6, and that's only because many apps didn't bother implementing certificate pinning (which was already known advice at that point).
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.
Do you have any kind of docs on doing this. I want to get some stats from a game I'm playing and think that the server fudges the number to keep whales happy.
Any quality documentation on how to do this would be great.
https://httptoolkit.com/blog/frida-certificate-pinning/ has a detailed blog on it. Frida receives updates all the time, so the exact commands and scripts don't always work with the latest version, but you can start there.
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.
I've now confirmed that if you pay money for the game, you -automatically- get exactly 12% more damage than someone who hasn't, and it appears to drop 1% a day over time.
Not much I can do with that data, other than sleep in comfort knowing that its the case.
Perhaps it's worth writing a quick blog about it? If this system wasn't documented before you purchase anything, you may even be able to get the attention of certain game review websites.
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!
"Yes, of course, you can do this, but let's not pretend there aren't trade offs."
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.
> Are there some words in the parent comment that "pretend there aren't tradeoffs"
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.
Including everything I could possibly ever want an Android device for, like my bank's 2FA program.
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)
Yup. When I updated my company's secure development requirements, and compared them to others, I was confronted with a lot of choices that would increase security somewhat, but at the expense of user control of their own devices, like refusing to function if the device was jailbroken, or requiring the use of the system keyboard only (which is also an accessibility problem).
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.
When I worked on iOS games, I ended up having to ban all jailbroken devices. I didn’t like doing it, but basically - every cheater we found was using a jailbroken phone, the number of non cheaters with jailbroken phones was tiny, and it would have basically taken up all my time to deal with cheaters rather than implement fun features. I’d have just ignored them if it wasn’t for the fact that they made the leaderboards look really fake.
As much as I want to agree with you, I can't blame Google here. Corporate security departments have bought into the idea that mobile is different and you can't trust the user with root.
Google has little choice but to provide them with the tools to detect root access.
As far as I've understood, the safetynet fix makes use of a feature which only exists for comparability reasons, so that old devices don't get locked out entirely. When there aren't enough old devices around anymore, it will likely stop working.
Well people keep saying this for years now. When it stops working we'll make statements like "root breaks access to Netflix and Banking apps". But since it doesn't at the moment, everything is good.
You do have to unlock the bootloader to root a device, hence wiping the data, but that doesn't matter if it's the first thing you do when you get the phone.
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).
Everything in the category "the user owns the device" is tricky.
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.
"Easily, but there's a big scary warning that the person asking you to do this might be trying to hack you" is still "easily". That obviously seems more consumer friendly than either extreme.
I don't think you deserve the downvotes, this is exactly right and is incredibly frustrating. Programmers, and increasingly folks who don't consider themselves to be writing malware, have no concept of a thing that should never be done by an application and only by the end user. If it's possible to do I should be allowed to do it! If they didn't want me doing it they should have stopped me! The amount of guides on the internet not targeted toward developers that teach users to go through the "create an application" flow and grant some random app access to their account in a more privileged way than would be allowed by the app itself is embarrassing for our industry. "Just add this configuration profile!", "Just paste in your API key."
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.
I agree with you in theory, but in practice half the population are never going to become security experts and it's impractical to force them to learn through necessity. If a hacker can get root on your smartphone, they can probably get access to your bank account (and the 2FA), your email, your private/intimate photos, your medical issues, your sexual secrets, and so on. A smartphone is far higher stakes than anything else which has come before it.
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.
> 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.
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.
Apple honestly did a pretty good job. You can sideload your own code with a free developer account, but you have to jump through some minor hoops to get “developer” mode set on your account (I went through this to get the tvOS 17 beta). And the app signing expires in 7 days, so it’s really painful for a normal user who isn’t actually developing and testing an app to use like that for a long term thing.
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).
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.
> 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
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.
> 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?
In the event that fantasy scenario plays out, there's no winners period; if Android complied, they'd still get to sell, and if they didn't they'd end up on the black market alongside the Pinephones.
None of this category of openness matters if the government turns to oppression.
> 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.
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.
> 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.
> 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.
Sometimes oppression could come from a central authority, and sometimes it can come from a rampant criminal element taking advantage of exploitable human behavior.
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.
This use case is well served by a non admin user as opposed to a machine where Dell is the root user. Furthermore what you desire for your grandmother is liable to be imposed on the rest of us if we want the privilege of banking or Netflix and in many cases grossly abused especially in less free countries including ours should we in the US fall into fascism.
You would build chains for millions of people so that granny will have to give scammers her money some less convenient way.
I think that really overstates the risk scenario. If we're going to descend into hyperbole, let's turn it around... If a free and open device is so important, won't some smart hacker always come along to build one? I'd rather my grandmother have an easy life and trust that Neo will be around to save the technorati eventually than make life easier on people who already know how to hack things they want to behave differently at the cost of my grandmother's sense of ease and well-being.
> If a free and open device is so important, won't some smart hacker always come along to build one?
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.
I mean... Netflix is clearly part of the larger control scheme in the scenario where the country is fascist, even as it is currently constructed. For everyone else, there'll be BitTorrent through VPN and good ol' fashion swapping of hard drives of bootlegs.
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.
I recently got tired of trying to hack together a sane workflow on the windows computers in the lab at my university, so installed nix-on-droid and gotty on my phone.
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.
That's not necessarily specific to iOS. Certificate pinning is usually done inside an app, not at the OS level. An app can choose to ignore the system certificate store and, for example, pin the cert used to talk to its private API. This is possible both on iOS and Android.
iOS is even easier than Android to add system certificates and can be done without rooting or jailbreaking the device unlike android. cert pinning is done by the apps not the system.
Android apps could also do certificate pinning with the same effect though? In this case there isn't any difference between Android and iOS in functionality.
You can, but that's not the system certificate store.
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.
What's the practical difference between system store and user store? Do some apps or system operations only trust the system store and not the user store?
The user store is a certificate store that the user can add certificates to. It used to be the case that by default apps would get certificates from both stores if they asked the system for certificate authorities to validate against, with the option to opt out of specific stores, but this changed years ago. Now apps need to opt into loading user configured certificate authorities.
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.
I don't know the difference between the user and system store, but I do know that apps can choose not to trust certs installed by the user and instead only trust their own that they bring with them. Was frustrated to find this when I was trying to MITM an app to see what it was up to on the wire.
Apps used to trust the user store by default, but that changed back in Android 7. Now they only trust the system store by default and need to opt into also loading the user store. So, it's not that they look at the stores and pick one, it's that the user store has effectively been disabled for most apps (browsers usually work, thankfully). Even Firefox for Android will only use the user store if you go through a five step process to open the hidden settings.
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.
Android 7 lacked the Let's Encrypt root certificate, and could only use the Let's Encrypt protected sites because their original root CA was cross signed by another CA.
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.
https://github.com/gojue/ecapture