Most active commenters
  • bri3d(5)

←back to thread

436 points kennedn | 13 comments | | HN request time: 0.684s | source | bottom
Show context
201984 ◴[] No.45252931[source]
Are techniques like using Frida and mitmproxy on Android apps still going to be possible after the signing requirement goes into effect next year?
replies(3): >>45253290 #>>45254332 #>>45255348 #
bri3d ◴[] No.45253290[source]
Overall: yes, but it will get much harder for apps which need attestation, which is sort of the point, for better or for worse. As far as I know you'll still be able to OEM unlock and root phones where it's always been allowed, like Pixels, but then they'll be marked as unlocked so they'll fail Google attestation. You should also be able to still take an app, unpack it, inject Frida, and sideload it using your _own_ developer account (kind of like you can do on iOS today), but it will also fail attestation and is vulnerable to anti-tampering / anti-debugging code at the application level.
replies(1): >>45254373 #
josteink ◴[] No.45254373[source]
So for people with any practical needs what so ever (like banking): No.

At this point Android isn’t meaningfully an open-source platform any more and it haven’t been for years.

On the somewhat refreshing side, they are no longer being dishonest about it.

replies(4): >>45254712 #>>45254817 #>>45255119 #>>45258788 #
1. bri3d ◴[] No.45254712[source]
I don't think any vendor should be solving for "I want to do app RE and banking on the same device at the same time;" that seems rather foolish.

These are sort of orthogonal rants. People view this as some kind of corporate power struggle but in this context, GrapheneOS, for example also doesn't let you do this kind of thing, because it focuses on preserving user security and privacy rather than using your device as a reverse-engineering tool.

There is certainly a strong argument that limiting third-party app store access and user installation of low-privilege applications is an anticompetitive move, but by and large, that's a different argument from "I want to install Frida on the phone I do banking on," which just isn't a good idea.

The existence of device attestation is certainly hostile to reverse engineering, and that's by design. But from an "I own my hardware and should use it" perspective, Google continue to allow OEM unlock on Play Store purchased Pixel phones, and the developer console will allow self-signing arbitrary APKs for development on an enrolled device, so not so much has changed with next year's Android changes.

replies(3): >>45254815 #>>45255136 #>>45255358 #
2. KetoManx64 ◴[] No.45254815[source]
GrapheneOS strongly recommends that you do not do it, but it will not stop you if you want to. You can root and leave your bootloader unlocked or create a custom user signed image with root support included. Plenty of user written guides out there how to do so.
replies(2): >>45254861 #>>45256121 #
3. bri3d ◴[] No.45254861[source]
> You can root and leave your bootloader unlocked

That's Google, not GrapheneOS.

4. 3abiton ◴[] No.45255136[source]
What I don't get is, if I am using my bank website on linux (with full root ability), it's still almost nearly the same as having the app on Android. The argument of "we lock it down to protect you makes 0 sense to me"
replies(2): >>45255229 #>>45255315 #
5. machinate ◴[] No.45255229[source]
They usually don't let you deposit checks via web app.
replies(1): >>45256737 #
6. bri3d ◴[] No.45255315[source]
* Your bank (and Google) want to deal with as little fraud as possible.

* Market forces demand they provide both a website and an Android app.

* If both platforms are equally full of fraud, have the same features, and both have similar use, they cut out half the fraud even if they can only make one or the other fraud proof.

* But it isn't like that in reality: in reality, something more like 80% of their use and 90% of their fraud comes from mobile devices, and so cutting off that route immediately reduces their fraud-load by a lion's share.

Ergo, locking down the app is still in everyone's best interest, before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)

And this isn't just a weird theory / ivory tower problem: Device Takeover banking fraud on Android is _rampant_ (see Gigabud/GoldDigger).

replies(1): >>45255351 #
7. Wowfunhappy ◴[] No.45255351{3}[source]
Why does most fraud come from locked down mobile devices and not open Windows/Linux PCs?

If it's true that 90% of fraud comes from mobile despite all of the restrictions, what that tells me is that locking down devices doesn't actually prevent fraud.

---

> before we even get into the mobile app having features the desktop one does not (P2P payments, check deposit, etc.)

I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.

Actually, back when jailbreaking iOS was still actually feasible, I recall the Chase app doing exactly that. The app worked fine, but it wouldn't let me deposit checks, I had to go to a branch for that. A bit annoying, but I can mostly understand that one.

replies(1): >>45255721 #
8. franga2000 ◴[] No.45255358[source]
> But from an "I own my hardware and should use it" perspective, Google continue to allow OEM unlock on Play Store purchased Pixel phones, and the developer console will allow self-signing arbitrary APKs for development on an enrolled device [...]

But that's not really using it, is it? If the process of getting access to do whatever I want on my smartphone makes it cease to be a viable smartphone, can you really count that as being able to use it?

It's like if having your car fixed by a third party mechanic made it not street legal. It is still a car and it does still drive, but are you really still able to meaningfully use it?

And before anyone jumps on my metaphor with examples of where that's actually the case with cars, think about which cases and why. There are modifications that are illegal because they endanger others or the environment, but everything else is fair game.

9. bri3d ◴[] No.45255721{4}[source]
> If it's true that 90% of fraud comes from mobile despite all of the restrictions

Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.

> I think it would be reasonable to disable those specific features on mobile while leaving the rest of the app accessible.

I agree with you in an idealist sense; it would be awesome to be able to use GrapheneOS and have 80% app functionality instead of 0% app functionality. I also completely understand why nobody does it; supporting what's probably <0.001 (if not lower)% of legitimate users in exchange for development time and fraud risk isn't a particularly appealing tradeoff. If I were in a situation to advocate for such a trade-off, I probably would, but I don't think it's evidence of a sinister conspiracy that nobody does that.

replies(1): >>45256234 #
10. easyKL ◴[] No.45256121[source]
Locking the bootloader is important as it enables full verified boot https://grapheneos.org/install/cli#locking-the-bootloader
11. Wowfunhappy ◴[] No.45256234{5}[source]
> Statistics on mobile vs. desktop banking will really shock you; the mobile usage penetration is easily well upwards of 90% in many markets. There's also a skewed distribution for fraud-vulnerable users and scenarios.

But if my goal was to commit fraud, wouldn't I go to wherever it was easiest to commit fraud? The actual market penetration of each platform shouldn't matter.

replies(1): >>45256391 #
12. dsymonds ◴[] No.45256391{6}[source]
It's usually done in bulk, so the overall payoff is the combination of value and number of targets, but the effort is typically sublinear with the targets. Something easier to attack but relatively low in number is not as juicy as something a bit harder (where the effort is mostly a one-off up-front rather than per target) but having many, many more targets.
13. jrockway ◴[] No.45256737{3}[source]
It's unclear what device attestation does here. You can print a fake check and take whatever picture you want. If it's using dead pixels or something as a device fingerprint, you get those dead pixels. You can also fake dead pixels, of course. Authenticating the phone's OS doesn't authenticate the camera, or what the camera's looking at. It's a signal, maybe, but the weak link in "a napkin with the right numbers and scribble on it is a money transfer" is probably not whether someone has root on the device that's taking a picture of the napkin.