Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yes, Android 14 still allows modification of system certificates

g1a55er.net

Post reply on HN
Print view View original

71–80 of 89 posts

Re: Yes, Android 14 still allows modification of system certificates

#71

Post by matheusmoreira »

selfhoster11 wrote: post #68
matheusmoreira wrote: post #40

Earlier quoted context omitted.

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 imp…

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)

Yeah. If iOS gets sideloading support, it could get a Termux equivalent. If that happens, I'm sold.

Re: Yes, Android 14 still allows modification of system certificates

#72

Post by jeroenhd »

ungamedplayer wrote: post #52
jeroenhd wrote: post #19

Earlier quoted context omitted.

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'…

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.

Re: Yes, Android 14 still allows modification of system certificates

#73

Post by jeroenhd »

aqfamnzc wrote: post #58
jeroenhd wrote: post #25

Earlier quoted context omitted.

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 t…

Can you expand more on the Let's Encrypt issue? What do you mean by that?

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.

Re: Yes, Android 14 still allows modification of system certificates

#74

Post by shadowgovt »

JimDabell wrote: post #65
paulmd wrote: post #63

Earlier quoted context omitted.

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 mo…

> Apple honestly did a pretty good job. 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……

> 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.

Re: Yes, Android 14 still allows modification of system certificates

#75

Post by jeroenhd »

netheril96 wrote: post #57
jeroenhd wrote: post #25

Earlier quoted context omitted.

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 t…

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? Not rhetorical questions.

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.

Re: Yes, Android 14 still allows modification of system certificates

#76

Post by jeroenhd »

mvnuweucxqokii wrote: post #59
netheril96 wrote: post #57

Earlier quoted context omitted.

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? Not rhetorical questions.

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.

Re: Yes, Android 14 still allows modification of system certificates

#77

Post by Dylan16807 »

curiousgal wrote: post #66
Dylan16807 wrote: post #50

Earlier quoted context omitted.

It's quite doubtful it will keep 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.

But it does break them. That's what happens when you enable root, they break.

You have to use pretty shaky workarounds to trick them, and there is a known way to make those workarounds impossible.

Re: Yes, Android 14 still allows modification of system certificates

#78

Post by michaelmrose »

shadowgovt wrote: post #70
michaelmrose wrote: post #61

Earlier quoted context omitted.

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 grann…

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 diffe…

> 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.

Re: Yes, Android 14 still allows modification of system certificates

#79

Post by michaelmrose »

shadowgovt wrote: post #74
JimDabell wrote: post #65

Earlier quoted context omitted.

> Apple honestly did a pretty good job. 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……

> 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…

> 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?

Re: Yes, Android 14 still allows modification of system certificates

#80

Post by a_t48 »

TheHappyOddish wrote: post #69
a_t48 wrote: post #56

Earlier quoted context omitted.

Please, our mediocre AA gatcha game did nothing to you nor the overall jailbreaking ecosystem. Don’t you think that’s being a bit dramatic?

They definitely overdramatised the wording, but their point is valid - the 'normalisation by a thousand cuts' is a real phenomenom, and a bad one.

I'll agree with that, but on my side I wasn't faced with a whole lot of options either.
Post reply on HN