12 ms·

As an author of an old root for Android, and of a modern generic custom ROMs, and other Android OS stuff: The title is, and forever will be wrong. When we say

by phh 3y ago

As an author of an old root for Android, and of a modern generic custom ROMs, and other Android OS stuff: The title is, and forever will be wrong. When we say you're root in Android, you're actually root. You can actually do whatever you want [1]. Magisk (the now modern "root" for Android) now includes stuff to even "edit" Java code, so even if it's hidden deep somewhere, you should still be able to access it. (Even if somehow it moves from Java to native code, we'll still find ways, don't worry) The fact that the author didn't manage to do it doesn't mean it's not possible. I could guess what's the author issue (I have two ideas in mind: 1. it requires stop;start to restart zygote, because zygote cached CAs, 2. it needs to switch to correct mount namespace before doing the commands), but I won't try it, I got tired of working on closed-source Android stuff. > More investigation is required and it's hard to know the full implications of that now, but for the many forks of Android like GrapheneOS & LineageOS, and for advanced device configuration tools like Magisk and its many modules, it probably spells trouble. I just don't understand this. GrapheneOS and LineageOS team have full source-code access. They can do whatever they please with it. (The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying) Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. (In my dreams I make a "OwnerDroid", an Android fork where the security model doesn't have the first line saying "the user is an enemy", but even though I developed some tiny bricks of it, the overall project would take a huge amount of work) [1] Except for some kernel-level protections, but GKI reduces that risk.

DistractionRect 3y ago
Armchairing here, but from a quick gloss over the article it seems like it should be quite easy to stub out: > this new approach reads certificates from /apex/com.android.conscrypt/cacerts, when it exists. Much like the how the current work arounds for safetynet, hiding root, and hiding magisk work, it should be possible to hide /apex/com.android.conscrypt/cacerts from select processes as needed to make it fail over to the old way.
pimterry 3y ago
The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools. Now, you can't do that. Of course, with full source code access anything is _possible_. You can absolutely build your own Android system images from scratch disabling all these modules to work around this, and it's certainly possible for GrapheneOS/LineageOS to handle that too - but it will create a bunch of new work, and diverging from Android's implementations of core components may mean more work in future. And for most affected users "first, build your own system image" is significantly beyond their comfort zone and level of time commitment. There will be other solutions eventually - it may be possible by digging through the namespacing and modifying the mounts of target processes individually to disable this, or there might be a way to somehow build & install your own APEX modules in a way that Android will trust, to replace the system module and thereby modify this directory, or who knows what else. There will certainly be per-process fixes possible with Frida, with hooks targeted to individual applications. More ideas welcome too :-D Despite all that though, it's still going to be a major problem that makes it harder for users to fully control their own devices.
- izacus 3y ago
  > The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools. Yes, and that was used for some horrifying security/privacy breaches that made this whole site preach about buying iPhones.
  - unethical_ban 3y ago
    Modifying system certificates is uncommon for the average user, but for techies and enterprise apps I imagine it's a lot more common. It's one thing for the OS to put dangerous things behind warnings, flags and prompts. It is another to cripple the OS.
moffkalast 3y ago
So to sum up: skill issue.
ASinclair 3y ago
If you can modify an init.rc then you can bind mount over the apex mount before the Zygote runs.
- phh 3y ago
  init could chose to launch every process in a new mount namespace, which would break this. I have no idea whether it does that, it probably doesn't, but my point is that as long as it's not released and open source, it's not worth looking at.
  - tux3 3y ago
    Even if you can look at the open-source code, it's still a maintenance nightmare to try to build on top of it, it just moves too fast. Much like any user could fork Chrome in principle and scratch their particular itch, but the sheer pain makes that not worth it except for motivated, organized teams I'm not sure reverse-engineering some Java bytecode is even the rate-limiting step at this point, I'm more demotivated by the knowledge that everything will break again with energy-sapping frequency
    - ASinclair 3y ago
      I'm in the unfortunate position that I'm in this maintenance nightmare at work. Though I solved this specific issue months ago. There will be many like it to come.
wink 3y ago
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. What about people who kinda gave up tinkering with custom ROMs because the state of the stuff that matters (root checks by your mandatory banking app, some Google stuff) is either not documented (good luck finding an overlap of "phone model" + "your local bank app" + custom ROM" as a tested and known-good thing). I'm all for freedom and choice, but I don't think unless you're willing to go through a couple of phones, a couple of days of work, or are a specialist in the first place, this is a reasonable way of action for average phone users. I know you said "power users", but I'm a power user with computers, my phones could be a lot dumber if I had my way - but it won't happen if we have to increasingly use them as MFA devices or be at the whim of corporations with a better lever (i.e. banks, I'm not changing my bank account 3 times until I find one with an app that works on a rooted phone...)
- fsflover 3y ago
  > What about people who kinda gave up tinkering with custom ROMs Such people should consider GNU/Linux phones, Librem 5 and Pinephone as an investment in the future.
- nilespotter 3y ago
  Just use the bank's PWA, you'll be fine. Or sandboxed play services in a separate GOS user.
  - aftbit 3y ago
    Outside of the USA, some banks require mobile apps. If you don't have a working attested phone in these countries, banking becomes decidedly 20th century.
  - vetinari 3y ago
    It is different issue than that. European banks are forced by EU's Payment Services Directive 2 (PSD2) to authenticate using MFA for any payment over 50 EUR. So what is the second factor? Your phone. Once you pair the app in your phone with your account, you can authenticate your actions using that phone, even if you are otherwise banking using the web app on your computer. Most banks also insist on using their apps, they don't allow generic second factors. Since their apps require Android with SafeNet or iOS, they pretty much enforce the Google/Apple duopoly. For now, there are other ways -- sms, which the banks are trying to phase out. So I imagine situation elsewhere will be very similar.
pjmlp 3y ago
Anything that isn't on standard Android that any non technical person uses, doesn't count, as that isn't what regular public uses.
diegoperini 3y ago
> I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. I 100% share your desire but this is wishful thinking imo. People tend to comply when given no other options.
squarefoot 3y ago
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. Or even ditch closed platforms for good. In other words: "Oh, PinePhone 2, where art thou?"
rollcat 3y ago
> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. Indeed, Android 5.0 has been that release for me. The redesign left the UI in a state of inconsistent mess, took away dark mode, made my otherwise perfectly performant Nexus 4 sluggish, broke apps... Custom ROMs were unfortunately not the answer, at least not for me - and TBH I doubt less technical users will appreciate the trade-offs. I've tried SailfishOS, been on Cyanongen/Lineage for a while, but ultimately if you want a device that just works, and works well... Everything is a compromise, might as well choose Apple.
jacquesm 3y ago
Sorry for your experience and thank you for all the work you did in this domain. But I'm afraid that custom roms will never be a mainstream thing no matter how much Google (or Apple) misbehaves. That's a hackers only thing and then only a very small fraction of the hackers.
pmontra 3y ago
> Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs I never owned a phone supported by any of the custom ROMs I investigated. Samsung Galaxy S2, Sony Xperia X Compact, Samsung A40. Except the first one, which was huge by the time and tiny nowadays, I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.
- phh 3y ago
  > Sony Xperia X Compact You can run custom ROM on it (the suupport is provided by Sony themselves), though maybe you need to actually build it yourself (which yeah not great, but you don't have to write the drivers, the build scripts and everything related yourself) > Samsung A40. You can run custom ROM on it (using Generic System Images) > I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones. Well, I am interested in those phones :P. I currently daily driver Asus Zenfone 9 (compact in nowadays standards, but not really compact), and Qin 3 Ultra (actually compact, usable one-handed). And I definitely run custom ROMs on it.
SenAnder 3y ago
> The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying That's a strategy to keep the competition busy just keeping up: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ If you ask "what competition (from Android forks)?", that means it's working.

by phh 3y ago

DistractionRect 3y ago

Armchairing here, but from a quick gloss over the article it seems like it should be quite easy to stub out: > this new approach reads certificates from /apex/com.android.conscrypt/cacerts, when it exists. Much like the how the current work arounds for safetynet, hiding root, and hiding magisk work, it should be possible to hide /apex/com.android.conscrypt/cacerts from select processes as needed to make it fail over to the old way.

pimterry 3y ago

The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools. Now, you can't do that. Of course, with full source code access anything is _possible_. You can absolutely build your own Android system images from scratch disabling all these modules to work around this, and it's certainly possible for GrapheneOS/LineageOS to handle that too - but it will create a bunch of new work, and diverging from Android's implementations of core components may mean more work in future. And for most affected users "first, build your own system image" is significantly beyond their comfort zone and level of time commitment. There will be other solutions eventually - it may be possible by digging through the namespacing and modifying the mounts of target processes individually to disable this, or there might be a way to somehow build & install your own APEX modules in a way that Android will trust, to replace the system module and thereby modify this directory, or who knows what else. There will certainly be per-process fixes possible with Frida, with hooks targeted to individual applications. More ideas welcome too :-D Despite all that though, it's still going to be a major problem that makes it harder for users to fully control their own devices.

izacus 3y ago
> The crux is that previously any user could modify these certs directly, even on vanilla OS images from Google themselves, without installing any tools at all - just by writing to disk - and that's both widely used and included in the setup guides for lots & lots of tools. Yes, and that was used for some horrifying security/privacy breaches that made this whole site preach about buying iPhones.
- unethical_ban 3y ago
  Modifying system certificates is uncommon for the average user, but for techies and enterprise apps I imagine it's a lot more common. It's one thing for the OS to put dangerous things behind warnings, flags and prompts. It is another to cripple the OS.

moffkalast 3y ago

So to sum up: skill issue.

ASinclair 3y ago

If you can modify an init.rc then you can bind mount over the apex mount before the Zygote runs.

phh 3y ago
init could chose to launch every process in a new mount namespace, which would break this. I have no idea whether it does that, it probably doesn't, but my point is that as long as it's not released and open source, it's not worth looking at.
- tux3 3y ago
  Even if you can look at the open-source code, it's still a maintenance nightmare to try to build on top of it, it just moves too fast. Much like any user could fork Chrome in principle and scratch their particular itch, but the sheer pain makes that not worth it except for motivated, organized teams I'm not sure reverse-engineering some Java bytecode is even the rate-limiting step at this point, I'm more demotivated by the knowledge that everything will break again with energy-sapping frequency
  - ASinclair 3y ago
    I'm in the unfortunate position that I'm in this maintenance nightmare at work. Though I solved this specific issue months ago. There will be many like it to come.

wink 3y ago

> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. What about people who kinda gave up tinkering with custom ROMs because the state of the stuff that matters (root checks by your mandatory banking app, some Google stuff) is either not documented (good luck finding an overlap of "phone model" + "your local bank app" + custom ROM" as a tested and known-good thing). I'm all for freedom and choice, but I don't think unless you're willing to go through a couple of phones, a couple of days of work, or are a specialist in the first place, this is a reasonable way of action for average phone users. I know you said "power users", but I'm a power user with computers, my phones could be a lot dumber if I had my way - but it won't happen if we have to increasingly use them as MFA devices or be at the whim of corporations with a better lever (i.e. banks, I'm not changing my bank account 3 times until I find one with an app that works on a rooted phone...)

fsflover 3y ago
> What about people who kinda gave up tinkering with custom ROMs Such people should consider GNU/Linux phones, Librem 5 and Pinephone as an investment in the future.
nilespotter 3y ago
Just use the bank's PWA, you'll be fine. Or sandboxed play services in a separate GOS user.
- aftbit 3y ago
  Outside of the USA, some banks require mobile apps. If you don't have a working attested phone in these countries, banking becomes decidedly 20th century.
- vetinari 3y ago
  It is different issue than that. European banks are forced by EU's Payment Services Directive 2 (PSD2) to authenticate using MFA for any payment over 50 EUR. So what is the second factor? Your phone. Once you pair the app in your phone with your account, you can authenticate your actions using that phone, even if you are otherwise banking using the web app on your computer. Most banks also insist on using their apps, they don't allow generic second factors. Since their apps require Android with SafeNet or iOS, they pretty much enforce the Google/Apple duopoly. For now, there are other ways -- sms, which the banks are trying to phase out. So I imagine situation elsewhere will be very similar.

pjmlp 3y ago

Anything that isn't on standard Android that any non technical person uses, doesn't count, as that isn't what regular public uses.

diegoperini 3y ago

> I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. I 100% share your desire but this is wishful thinking imo. People tend to comply when given no other options.

squarefoot 3y ago

> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. Or even ditch closed platforms for good. In other words: "Oh, PinePhone 2, where art thou?"

rollcat 3y ago

> Anyway, I hope that Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs. Indeed, Android 5.0 has been that release for me. The redesign left the UI in a state of inconsistent mess, took away dark mode, made my otherwise perfectly performant Nexus 4 sluggish, broke apps... Custom ROMs were unfortunately not the answer, at least not for me - and TBH I doubt less technical users will appreciate the trade-offs. I've tried SailfishOS, been on Cyanongen/Lineage for a while, but ultimately if you want a device that just works, and works well... Everything is a compromise, might as well choose Apple.

jacquesm 3y ago

Sorry for your experience and thank you for all the work you did in this domain. But I'm afraid that custom roms will never be a mainstream thing no matter how much Google (or Apple) misbehaves. That's a hackers only thing and then only a very small fraction of the hackers.

pmontra 3y ago

> Android becoming more and more user-hostile (and more specifically in this case power-user-hostile) will move more and more people to custom ROMs I never owned a phone supported by any of the custom ROMs I investigated. Samsung Galaxy S2, Sony Xperia X Compact, Samsung A40. Except the first one, which was huge by the time and tiny nowadays, I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones.

phh 3y ago
> Sony Xperia X Compact You can run custom ROM on it (the suupport is provided by Sony themselves), though maybe you need to actually build it yourself (which yeah not great, but you don't have to write the drivers, the build scripts and everything related yourself) > Samsung A40. You can run custom ROM on it (using Generic System Images) > I buy the smallest phone I can find. Apparently no ROM developer is interested in those phones. Well, I am interested in those phones :P. I currently daily driver Asus Zenfone 9 (compact in nowadays standards, but not really compact), and Qin 3 Ultra (actually compact, usable one-handed). And I definitely run custom ROMs on it.

SenAnder 3y ago

> The limitation being that Google breaks stuff at an incredible rate, and following is a bit annoying That's a strategy to keep the competition busy just keeping up: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ If you ask "what competition (from Android forks)?", that means it's working.