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.
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.
> 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.
"Just by writing to disk" omits the part where you needed to unlock the bootloader (wiping data), flash a custom recovery, install a superuser implementation and remount /system as writable (or used an overlay do fake it). The only thing that seems to be changing is where and how these certs are stored, so the procedure will be exactly the same apart from the last step, which was never the hard part. By the time you set up a phone for root access, needing one extra app or overlay to add CAs is barely an inconvenience.
No - the system cert installation works out of the box on Google's own official emulators, for both AOSP & 'Play Services' editions (but not Play Store). Ditto for Genymotion, Bluestacks, etc.
Zero root setup required in those cases, until now. Create the emulator, adb shell, su, mount tmpfs, write your CA certificates.
You can script it and do the whole process in <1 second on a fresh device.
Emulators are a whole different story, I didn't realise that's what you were talking about. But emulators are a very niche use-case and they're already running modified images, so they could easily include a way to write certs. The most important (at least from my perspective) uses of custom CAs are done on real devices though, which have always needed a lot of work to modify, so little changes there.
> 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.
But can you uninstall the root certificates of an adversarial government (i.e., your own)? Is it now necessary that the chain of trust includes entities you don't trust?
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
> 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...)
Magisk and Shamiko together have been working well for me to hide root from Google Pay/my bank app for the past year or so (fingers crossed, ymmv). Highly recommend the experience of having a rooted phone though, it's a nice feeling controlling your device, especially being able to control the traffic and just like... run unix utilities natively. I really wish it was something I didn't have to spend so much effort achieving but it has been worth it. I find the experience of using a device I don't have full control over beyond irritating.
Presumably as an April Fools' joke, LineageOS added an undismissable notification informing users that, "You might be a victim of software counterfeiting"
Removing it requires updating to another build or rebooting into recovery and changing a setting using terminal via setprop .
instructions: Okay I finally managed to solve the LineageOS Settings"You might be a victim of counterfeiting" april fools joke. Here are the steps to how I solved it 1. Boot in to TWRP-recovery 2. Open Terminal under the advanced tap 3. Type the following "setprop persist.lineage.nofool true" in the terminal 4. Reboot the phone and voila :)
It made me realise that these huge and reputable Android ROM developers will still treat your phone like a toy, and are therefore completely untrustworthy.
3. You can't use trusted SIM services such as e-signature with custom ROMs. I have an e-signature embedded into the cryptographic module of my SIM card, and no custom ROM can use that, because they can't provide a secure pipe from SIM to antenna, and that's a deal breaker.
Uh, that doesn't make sense to me. Could you provide some details? The point of SIM card is that there is no user-controlled software in the path between SIM card and antenna. So if the pipe from SIM to antenna was secure before custom ROM, it's still secure after it.
In my e-signature workflow, I initiate the process from outside. So, a network provider notification comes in, I accept it, check a fingerprint presented, enter PIN, and hit send. So, there are couple of screens and a keyboard is presented to me.
When I used a custom ROM, I never received the notification, IIRC. Even carrying the relevant bits from the official ROM didn’t matter. It never worked, crippling tons of things at the end.
If used or reflashed the stock ROM, things have returned to normal.
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.
Banks have no clue about 2FA/ MFA, they will happily put the bank app and the custom TOTP generator/ "key"-app on the same phone or, as a fallback, send SMS to the same phone the bank app is on. So in reality, it's at best 1.5FA because when the phone is owned, the user already lost. And it is really hard to not have the banking app on the phone with many institutions. Some institutions now put the TOTP generation into the same app too. Oh and there are limits on the user name and password-length that make it easier for attackers to crack, in some cases (in Germany) the password can be exactly 5 characters long and the username tends to be the debit card number by default.
In many ways, this is really cumbersome, not really secure and on top of everything else adding a false sense of security. Less advanced customers are either somewhat secure but then the product is barely usable or they can realistically use the service but the security is so-so.
> Banks have no clue about 2FA/ MFA, they will happily put the bank app and the custom TOTP generator/ "key"-app on the same phone or, as a fallback, send SMS to the same phone the bank app is on.
This. My bank in France, BNP, does that. Every so often, when I connect to the app on the phone, it says something similar to "in accordance with <some regulation> a strong authentication must be made every <number> of sign-ins". You're presented with only one button that says something like "ok". You press it, and you're in business.
This is after requiring me to type in my pin, which must be precisely 6 digits, and some sequences are forbidden, so you can't type 1234 or similar. It doesn't seem to interact with the secure enclave in any way.
If this number of sign-ins is reached while I'm on a PC (which is the most likely), it'll send a confirmation request on the phone, so at least it works there. When paying online, I'll also get a confirmation request on the phone app.
On my professional account, with the same bank, the situation used to be exactly the same. But a few months ago, they switched away from that to sending a confirmation code via SMS for bank transfers. Credit card payments still have the app confirmation request.
My bank wants me to type a code received in the app into a number field a little bit lower on the screen in the same app. They consider this a second factor. Of course it's nothing but busywork and security theater.
They do? My bank is very explicit about "don't ever run the front-end and the second factor on the same device". Perhaps it's a German thing, with all our Datenschutz fundamentalism that will happily consider even IP addresses PII?
My experience is with select German and Czech banks and/ or "Sparkasse" which is a kind of savings bank used very often by private citizens. These tend to have better mortgage options in some cases but are quickly inconvenient if you have an unusual (digital/ SaaS) business or any kind of special requirements, like if you want to transfer larger sums of money into other countries with a decent exchange rate.
> "don't ever run the front-end and the second factor on the same device"
This is required in some cases, probably unless you apply for the physical hardware token generator which costs extra. You must apply for the 2FA-app initialization through the banking app that you are supposed to run on the same phone. In both cases, it is basically impossible to have a backup. Also, the banking app and the banking key app are supposed to have a separate PIN/ short password or a biometric login. Of course, the biometric approach has all kinds of problems in legal challenges (e.g. something you know is protected differently to something you are). Also, something you know cannot be easily obtained while you are asleep. Also, you probably don't want to use your password manager on your mobile phone - so there you are, typing a generated password to log into the key/ 2FA app for security theater. If there wasn't the banking app right next to the key app, the bank could probably just use something like FreeOTP+ or Google Authenticator without reinventing the wheel, also enabling backups in the process and skipping sending physical mail with the initial setup tokens. But that would be too straight forward and not "enterprise" security or whatever.
The situation in Czechia is more or less similar. The banks tend to belong to the same banking groups so the underlying infrastructure might be similar even though Czechia still does not have the Euro/ SEPA.
Of course they do. But they need to balance security with end user experience.
And since security for a bank is about risk management they can offset this risk in other areas to compensate e.g. additional processes for activities involving larger amounts of money.
I don't know where you're from, but here in austria most banks offer 'cardTAN' as an alternative to mobileTAN. I always assumed cardTAN is a thing everywhere...
edit: with cardTAN you get a OTP/TAN 'calculator' into which you put your smartcard to generate TANs on the fly.
I use it because to me this feels more like a real second factor, when I use my mobile for banking.
Same here in NL, for now. But: banks are pushing their apps hard, to the point where every authentication you have to manually switch - again - to indicate that you want to use the token generator and not their app (never mind cookies and so on, those are only for the marketing department, when for once they could actually use them to store your preferences).
And there will likely be a time when the bank simply cuts access to the cardTAN system and only allow their apps. Screw them because that means I have to use a smartphone, which I really do not want. The cardTAN system has been very good so far in preventing fraud, once the phone is the token it suddenly gets a lot more complicated and less secure.
The DACH world is specific in many things... but I've seen cardTAN outside it. In Slovakia, Tatra banka does use this system. I guess being part of Raiffeisen explains it.
That used to be the universal way here (Belgium) before the banks went all in with apps. I'm not sure wether typing a challange/response into a browser is inherently more secure than a phone app.
For those wondering about 2FA with these apps, factor 1 is "something you own" namely that particular phone/sim, and factor 2 is "something you know", your PIN.
You can still use cardTAN, but the app is way more convenient, especially with QR.
My French bank, CIC, sold me a Digipass scanner+pin authentication device. Adding yet another device to the usual kit bag won't make it very popular but an option independent from Google/Apple exists and I guess that its non-existence wouldn't fly for long with regulatory authorities.
The authors of the PWAs would need to opt-in to this.
We distribute LOB banking apps as PWAs to our customers. In no reality would I consider incorporating this into our tech stack. We use PWAs and avoid native apps precisely to maximize compatibility across arbitrary IT policies in our various customer installs.
I don't know if our customers want to use linux, windows, android or apple. I don't WANT to know anymore. I just want to target a common API (HTML5), add some bandaids for iOS/Safari (usually after WWDC each year) and move on with life. Throwing DRM and platform constraints into the mix sounds like I might as well go back to native (I won't).
We are one of the few vendors that will actually get into a heated argument and push back against customers over FUD security crap like this. If a prospect insists that we add some draconian DRM to our product stack, I would make it very clear to leadership that I do not think we should do business with that customer on technical grounds.
If you find yourself in a situation where you need to trust the client implicitly, then you have catastrophically failed in the rest of your design.
I appreciate what you do if you really do deliver that, but plenty of FIs are happy to mandate things like Trusteer Rapport and I would anticipate that sector to jump onto WEI just as fast as media companies will. It's going to be sold to execs as a zero operational cost lightswitch solution to preventing account hijacks.
Up until about a year ago one major core provider had been using the password 'money' for all their client accounts, many of which were domain admins since that is a 'just make it work' button and they cannot actually tell you what privs their service accounts need. When we asked the clients to press them on it, we determined via cracking that they had changed it to 'monet' as a workaround. The standards for excellence are SO LOW.
> that they had changed it to 'monet' as a workaround
> The standards for excellence are SO LOW.
I'm 99% sure I know which vendor you are referring to.
Almost everything in fintech is a hacky mess. This is our competitive advantage. Doing the barest-acceptable thing makes us look like rockstars compared to every other vendor in the space.
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.
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.
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.
> 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.
> 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.
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.
> 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.
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.
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
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.
> 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?"
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.